Governance of the Interoperability Framework for Rail and Intermodal Mobility

Contract No. H2020 – 730844

GOVERNANCE OF THE INTEROPERABILITY FRAMEWORK FOR RAIL AND INTERMODAL MOBILITY

D3.2 Final Report on Regulatory Environment

Due date of deliverable: 30/04/2018

Actual submission date: 12/12/2018

Leader/Responsible of this Deliverable: UIC

Authors: John Lutz, Vytautas Kinderis, Yves Amsler, Paolo Umiliacchi, Delphine Grandsart, Marco Comerio, Alessandra Berto, Riccardo Santoro, Petra Jurankova

Reviewed: Y

Document history

Revision Date Description 0 16/03/2017 First draft (to be completed) 0.1 13/04/2017 Abstracts and extracts included. Inputs from OLTIS and TELESTE integrated. 0.2 26/04/2017 Inputs from CEFRIEL 0.3 18/05/2017 Input from Data notation and modelling. Ed. 10 March 2016. Public deliverable D 3.4.1 published by the European research project C4R - CAPACITY FOR RAIL (CNC, CEFRIEL) Figures captions and index added Small changes, integration and review made by CNC 0.4 13/06/2017 UITP contribution on SIRI and ITxPT added (Guido di Pasquale) Introduction on TransModel, CEN/TS 28701 and IRS 50405 added by CNC OLTIS contribution on FSM added 0.5 28/06/2017 Review, agreed with the WP Leader, according to comments from UITP (Yves Amsler) Additional changes from CNC 0.6 04/08/2017 New contributions from UITP and CNC

IFG-WP3-D-UIC-015-02 Page 1 of 153 12/12/2018

Contract No. H2020 – 730844

0.7 29/08/2017 Final contribution from UITP integrated by CNC 1 06/12/2017 Inputs from IATA and further comments from UITP (Yves Amsler) 2 12/12/2018 Final version after TMC approval and quality check

Project funded from the European Union’s Horizon 2020 research and innovation programme Dissemination Level PU Public X CO Confidential, restricted under conditions set out in Model Grant Agreement CI Classified, information as referred to in Commission Decision 2001/844/EC

Start date of project: 01/11/2016 Duration: 24 months

IFG-WP3-D-UIC-015-02 Page 2 of 153 12/12/2018

Contract No. H2020 – 730844

TABLE OF CONTENTS

1. EXECUTIVE SUMMARY ...... 7 2. Introduction ...... 11 Methodology ...... 11 Document Content and Structure ...... 11 3. Regulatory impact on the Interoperability Framework...... 13 Understanding the IF Assets ...... 13 The IF Asset Manager and regulatory compliance ...... 14 The Regulatory Challenge ...... 15 Applicability to the IF ...... 16 4. European Regulatory Framework...... 17 RAIL Directives ...... 18 Regulations on Passenger Rights ...... 20 4.2.1 (Air) Common Rules on Compensation and Assistance ...... 22 4.2.2 (Air) Carrier liability in the event of accidents ...... 25 4.2.3 (Air) Common rules for the operation of air services ...... 26 4.2.4 (Air) Community list of air carriers subject to an operating ban ...... 27 4.2.5 (Air) Code of Conduct for computerised reservation systems...... 28 4.2.6 Rail ...... 29 4.2.7 Bus and Coach ...... 33 4.2.8 Maritime and Inland Waterway ...... 35 4.2.9 Liability of carriers in the event of accidents by sea ...... 38 4.2.10 Associated legislation on consumer protection ...... 39 Regulation on provision of EU-wide multimodal travel information services ...... 40 Regulations on Persons with Reduced Mobility (PRM) ...... 43 4.4.1 Rights of disabled persons and persons with reduced mobility when travelling by air 44 4.4.2 Rail passengers’ rights and obligations ...... 46 4.4.3 Rights of passengers in bus and coach transport ...... 48 4.4.4 Rights of disabled persons and persons with reduced mobility when travelling by sea or inland waterway ...... 50

IFG-WP3-D-UIC-015-02 Page 3 of 153 12/12/2018

Contract No. H2020 – 730844

Technical Specifications for Interoperability (TSI) ...... 51 4.5.1 Telematics Applications Freight (TAF-TSI) ...... 52 4.5.2 Telematics Applications Passenger (TAP-TSI)...... 54 4.5.3 Accessibility of the Union's rail system for persons with disabilities and persons with reduced mobility (PRM TSI) ...... 57 Regulatory Framework on Personal data protection ...... 60 4.6.1 General Data Protection Regulation (GDPR) ...... 61 4.6.2 ePrivacy Regulation ...... 64 4.6.3 Security of Network and Information Systems (the NIS Directive) ...... 65 4.6.4 Intellectual Property right ...... 67 5. Standardisation ...... 78 Background ...... 78 Standardisation vs Specifications ...... 78 Standardization Documents ...... 78 Relevant Standards and Specifications in the Rail Sector ...... 96 5.4.1 W3C ...... 96 5.4.2 Other Organisations Creating Specifications that are applicable to the IF ...... 98 5.4.3 Specifications that are recommended to be used by the IF Assets ...... 102 5.4.4 IRS 50405 ...... 102 5.4.5 railML ...... 106 4.3.3.1 Full Service Model (FSM) ...... 109 4.3.3.2 RailTopoModel - Railway infrastructure topological model (RTM) ...... 110 4.3.3.3 Open Travel Alliance (OTA) ...... 111 4.3.3.4 Open API for distributed journey planning (CEN) ...... 112 4.3.3.5 UIC 918 ...... 113 Relevant standard and specifications in the Public Transport ...... 115 5.5.1 Introduction ...... 115 5.5.2 Regulation documents ...... 115 5.5.3 Standardisation documents ...... 115 4.3.3.6 TRANSMODEL ...... 130 EN/TS 16406:2013 ...... 136 Public transport — Open API for distributed journey planning ...... 140 Specification documents ...... 145 GTFS (General Transit Feed Specification) ...... 145

IFG-WP3-D-UIC-015-02 Page 4 of 153 12/12/2018

Contract No. H2020 – 730844

GTFS-Realtime ...... 146 GTFS-Flex ...... 148 OSPT Alliance ...... 149 Matka.fi data and API ...... 149 6. Conclusions ...... 151

IFG-WP3-D-UIC-015-02 Page 5 of 153 12/12/2018

Contract No. H2020 – 730844

TABLE OF FIGURES

Figure 1 The IF Technology Assets...... 13 Figure 2 Passenger Rights ...... 20 Figure 3 - Relationship to other Regulations ...... 55 Figure 4 Corresponding TSI Parameters ...... 58 Figure 5: Software development process ...... 73 Figure 6: Different possibilities of reserving exclusive right ...... 75 Figure 7 Classification of services ...... 81 Figure 8 TRDP within OSI layers ...... 82 Figure 9 TCMS functional approach ...... 83 Figure 10 TCN architecture ...... 85 Figure 11 Communication infrastructure overview...... 86 Figure 12 Communication and application layers ...... 89 Figure 13 General abstract model ...... 90 Figure 14 General conceptual model ...... 90 Figure 15 High-level functional breakdown...... 93 Figure 16 Test methods ...... 94 Figure 17 railML file – example “operating period” (Excerpt) ...... 108 Figure 18NeTEx Parts ...... 119 Figure 19 An example of a simple bus timetable for a linear route modelled in NeTEx ...... 123 Figure 20ITxPT test bench ...... 128 Figure 21 ITxPT governance ...... 129 Figure 22 ITxPT Label ...... 129 Figure 23 Transmodel areas to the SIRI and NeTEx CEN standards ...... 131 Figure 24 CEN/15331 Parts ...... 137 Figure 25 Classes and attributes of the GTFS specification ...... 146 Figure 26 The GTFS-Flex model ...... 148 Figure 27 Regulation Environment ...... 151 Figure 28 Regulatory Impacts by Asset Category ...... 152 Figure 29 Standards Impacts by Asset Category ...... 153

IFG-WP3-D-UIC-015-02 Page 6 of 153 12/12/2018

Contract No. H2020 – 730844

1. EXECUTIVE SUMMARY

A positive policy environment, with commercial realities considered, will facilitate the acceptance and implementation of effective governance for the underlying Interoperability Framework (IF) Assets. To best enable a governance framework that defines the proper rules for administration, process and change management, this deliverable identifies the interactions of the regulatory environment, standardization bodies and industry initiatives that will impact the use of new semantic technologies that can deliver a seamless customer experience. The work so far was carried out based on the survey of available information sources as well as well as interaction with other projects and focus groups that are impacted by the Regulatory and Standards environments. Some key regulatory provisions considered for analysis and input were:

 Passenger rights (all applicable regulations for all modes of transportation): integration of booking and ticketing paves the way to integrated service contracts, therefore homogeneous (information on) compensations in case of delays, or substitution means in case that one travel “leg” should be unavailable. Additionally, aspects of Consumer Protection and Liability were also considered in this context.  Accessibility-related (PRM – all applicable regulations for all modes of transportation): Analysis of the related information and regulatory requirements for the non-discriminatory provision of transport services, where the integration of successive modes is considered.  Telematics Applications - Rail (Telematics TSIs for Rail Passenger and Freight): Analyse the Technical Specifications for Interoperability regarding requirements for Open and Private data provision concerning Operations, Service Disruptions, Timetables, Reservation/Ticketing, etc.  Personal data protection and Privacy: Analyse the legal background requirements regarding privacy and personal data protection along all steps of the multimodal travel chain. This is mostly applicable to the users of the IF Assets who will develop new products and services. Recommendations will be given for the application of such Regulations.

The result of the analysis is presented in the concluding part of the present report, and sorts out:

 current rules and regulations that shall be followed by the IF, in order to be compliant, especially, with European policies, and

 Standards that should be adhered to by the IF, for it to be embraced by implementors.

A “spinoff” from the analysis is the list of rules and regulations to be observed by implementors, but not directly affecting the IF. This “spinoff” has been developed under this deliverable.

IFG-WP3-D-UIC-015-02 Page 7 of 153 12/12/2018

Contract No. H2020 – 730844

Abbreviations and Glossary Acronym Definition

ADR Alternative Dispute Resolution CCM Change Control Management

CEN European Committee for Standardisation (French: Comité Européen de Normalisation)

CENELEC European Committee for Electrotechnical Standardisation (French: Comité Européen de Normalisation Électrotechnique)

CER Community of European Railway and Infrastructure Companies

CIRSRT Computerised Information & Reservation System for Rail CIV Convention Internationale pour le transport des Voyageurs CJEU Court of Justice of the European Union COTIF Convention concerning International Carriage by Rail CRS Computerised Reservation System EC European Commission ESO European Standardisation Organisation

ETSI European Telecommunications Standards Institute

EU European Union EUPL European Union Public Licence ERA European Union Agency for Railways

FOSS Free/Open Source Software

FSF Free Software Foundation

GNU GNU's Not Unix (operating system)

IATA International Air Transport Association

ICT Information and Communication Technologies

IEEE Institute of Electrical and Electronics Engineers

IF Interoperability Framework as established under Shift2Rail IP4

IF Assets The Interoperability Assets are the components that will be developed under Shift2Rail IP4 that will be reused for future development.

IM Infrastructure Manager

IP Intellectual Property

IFG-WP3-D-UIC-015-02 Page 8 of 153 12/12/2018

Contract No. H2020 – 730844

IPR(s) Intellectual Property Right(s)

IPRED IPR Enforcement Directive

ISO International Organisation for Standardisation

IT Information Technology ITS Intelligent Transport Systems MS Member State NeTEx Network and Timetable Exchange NFC Near Field Communication NEB National Enforcement Body NSO National Standardisation Organisation OTA Open Travel Alliance

ODR Online Dispute Resolution OSI Open Source Initiative OWL Web Ontology Language PCT Patent Cooperation Treaty PRM Persons with Reduced Mobility Regulation (EC) No 1107/2006

PSC Public Service Contract R&D Research and Development

RISC Railway Interoperability and Safety Committee (RISC)

RU Railway Undertaking

SIRI Servie Interface for Real Time Information

SME(s) Small and Medium-sized Enterprise(s)

SDO Standards Developing Organisation

SDR Special Drawing Right TAF-TSI COMMISSION REGULATION (EU) No 1305/2014 of 11 December 2014 on the technical specification for interoperability relating to the telematics applications for freight subsystem of the rail system in the European Union and repealing the Regulation (EC) No 62/2006

TAP-TSI Commission Regulation (EU) 2016/527 of 4 April 2016 amending Regulation (EU) No 454/2011 on the technical specification for interoperability relating to the subsystem ‘telematics applications for passenger services’ of the trans-European rail systems

TFEU Treaty on the Functioning of the European Union TSI Technical Specifications for Interoperability for the trans-European Rail Network

IFG-WP3-D-UIC-015-02 Page 9 of 153 12/12/2018

Contract No. H2020 – 730844

UIC International Union of Railways (French: Union Internationale des Chemins de Fer)

UITP International Association of Public Transport (French: Union Internationale des Transports Publics)

UNCRPD United Nations Convention on the Rights of Persons with Disabilities UNIFE Association of the European Rail Industry (French: Union des Industries Ferroviaires Européennes)

WS WebService XML eXtensible Markup Language

XSD XML Schema Definition

WIPO World Intellectual Property Organization

WSDL Web Service Definition Language

DCAT-AP Data Catalogue Vocabulary (DCAT) Application Protocol

API Application Programming Interface

SGML Standard Generalized Markup Language

W3C World Wide Web Consortium

IFG-WP3-D-UIC-015-02 Page 10 of 153 12/12/2018

Contract No. H2020 – 730844

2. INTRODUCTION

This final deliverable presents an analysis of some of the most relevant Regulations and Standards and Industry Initiatives that will impact the governance rules of the Interoperability Framework Assets. It has a focus on the transport and public administration domains, but also considers Regulations and Standards that are applicable to end-users of the Assets (i.e. developers of products and services as well as future IP4 development.) This document is produced within WP3 of the H2020 project GoF4R1 (Governance of the Interoperability Framework for Rail and Intermodal Mobility).

This deliverable addresses the actual ‘State of the Art’ of the Regulatory Environment – namely, those Regulations and Standards that must be considered for establishing the governance rules for the IF Assets. The objective is not to present a comprehensive overview of EU legislation and standards in the transport or data privacy sectors, nor is it meant to comprise a complete legal catalogue of the existing laws and standards. It does, however, present the pertinent rules, regulations and standards that need to be taken into consideration for IF Asset compliance.

The final deliverable will take into consideration the possible future evolution of Regulations and Standards as well as providing a set of recommendations to be considered by end-users (and further development projects) with the IP4 Technologies, particularly supporting the Travel Companion.

METHODOLOGY

The methodology used to create this final report was based on desk research that had been collected from different written sources (e.g. EU and national legislation, standardisation documents, research projects, etc.) and from the interaction with the ST4RT, Co-Active and ATTRACkTIVE partners. Furthermore, interaction and collaboration with the IT2RAIL partners and IP4 ecosystem was necessary to define the applicable scope for the governance of the IF Assets. Specific attention has also been given to the current and up-coming European regulatory framework. The interaction with the GoF4R and IT2RAIL partners has been supported by (but not limited to) formal and informal collaboration meetings.

The analysis of the collected information had been done with the help of the project partners, who have indicated, to the best of their knowledge, the relevance of each project regarding the GoF4R activities.

It is foreseen to conduct personal interviews with key Stakeholders within the Commission, the European Union Agency for Railways and other relevant Standards bodies and has be undertaken for the final analysis contained in this Deliverable 3.2 (Final Report on the Regulatory Environment).

DOCUMENT CONTENT AND STRUCTURE

The body of the deliverable is a synthesis of the research that was conducted, with only the most relevant Regulations and Standards directly applicable to the Interoperability Framework. Others which indirectly impact the Interoperability Framework within the wider context of a European seamless travel and Multi-Modal Travel Information are presented in Annex I of GoF4R Deliverable

1 http://www.gof4r.eu/

IFG-WP3-D-UIC-015-02 Page 11 of 153 12/12/2018

Contract No. H2020 – 730844

D4.12. Annexes of the current deliverable contain supplemental research on topics that can be taken into consideration. The document and Annexes will be updated after consultation with WP5 and other stakeholders and will contain recommendations for future developers of the products and services which will use the IF.

Annexes have been added that contain the more extensive baseline research that has been conducted during the development of this deliverable. Those annexes are as follows:

Annex I Introduction to Standardisation

Annex II Passenger with Reduced Mobility Rights

Annex III Antitrust Legislation, parts 1 and 2

Annex IV Passenger Rights in Railway and Inland Water Transport (European and Slovakian)

The main body of the deliverable comprises:

Chapter 2 – Regulatory Impact on the Interoperability Framework: addressing the IF Assets, their composition, and their relationship between the Assets and their potential users.

Chapter 3 – Regulatory Environment: addressing the various Directives, Regulations and TSIs that relate directly to the IF Assets and their Governance. Each entry will address the scope, geographic coverage, stakeholders impacted, IF Assets that may be impacted (and how) and Governance implications.

Chapter 4 – Standardisation: addressing the various standards bodies and industry conventions that will be used by or relate directly to the IF Assets and their Governance. Where relevant, each entry will address the scope, geographic coverage, stakeholders impacted, IF Assets that may be impacted (and how) and Governance implications.

Chapter 5 – Conclusions and next steps

2 IFG-WP4-D-CEF-036-03 D4.1 - INITIAL SEMANTIC INTEROPERABILITY TECHNOLOGY MARKET WATCH

IFG-WP3-D-UIC-015-02 Page 12 of 153 12/12/2018

Contract No. H2020 – 730844

3. REGULATORY IMPACT ON THE INTEROPERABILITY FRAMEWORK

UNDERSTANDING THE IF ASSETS

To do a fair analysis of the Regulatory impact on the IF, it is first necessary to understand the composition and purpose of the IF Assets that will need to be governed.

The fundamental objective of the IF is to provide the ability for heterogeneous systems to perform coordinated computational tasks distributed over a network. This entails that:

 The computational assumptions, purpose and intent of data, however they might be exchanged and whatever their format, must be “understood” by systems, i.e. both the data and their interpretation (or “semantics”) must be available to machines. The interpretation must be automated without the need to embody it in computer code. There must be no need, therefore, to adapt computer code to work with any given data exchange mechanism or data representation of business concepts, phenomena or events.  There must be minimal, possibly zero, need to move data before it is actually needed, and then only of the data that is actually needed for a given computational tasks

The IF developed within Innovation Programme 4 of Shift2Rail (IP4 - IT Solutions for Passenger Services) and its ‘Lighthouse Project’ IT2Rail realises the objective by providing specific tools and technologies that allow different actors engaged in transportation to describe explicitly and to share the semantics of their interactions. These tools and technologies are collectively called the “IF Assets” and provide the means to interpret the variety of data formats and protocols into information understandable by myriad proprietary business applications. enable developers to provide seamless mobility Figure 1 The IF Technology Assets services, foster the development of multi-modal travel services.

The following list contains a description of those assets:

 Ontologies: formal specifications of shared conceptualizations of specific domains (or a part of them). An example is the IT2Rail ontology that is an OWL specification of the set of concepts and relationships among them that the IT2Rail partners have proposed as a conceptualization of the transportation domain.

IFG-WP3-D-UIC-015-02 Page 13 of 153 12/12/2018

Contract No. H2020 – 730844

 Web Service Descriptors: metadata descriptions of the functionalities offered by specific Web services and their binding information. An example is a Travel Expert service descriptor that contains a pointer to the WSDL specification of the Travel Expert Web service and the specification of the offered functionalities each described by a name, required/optional parameters, output, supported passenger categories and WS security protocol.

 Business Rules and Processes: inference rules and processes that characterize a specific standard and/or a system adopting it. An example is the business process enabled by the Full-Service Model (FSM) specification where the booking of a railway ticket is articulated into three main steps named offering, pre-booking and booking.

 Schemas and Mappings: are schemas or mappings between schemas/ontologies aiming at supporting the technical interoperability between services/systems in the transportation domain adopting different standards. Examples are the UIC918 suite of standards in XSD Schema and its mappings against the IT2Rail ontology.

 Data Sets: data sets associated with their semantics, i.e. “annotated” semantic graphs, providing certain specific information of the transportation domain that needs to be shared by all actors engaged in distributed computational task, e.g. coding conventions used for common objects, such as Stop Places, by different systems or transportation modes. This asset type presents two levels to be managed and governed: the semantics of the dataset and the data included into the dataset. An example of this asset type is a NeTEx dataset containing Stop Places of a specific transportation mode and it is described by means of a DCAT-AP metadata description annotated with the common ontology.

To promote the market uptake of the IF, the governance must create confidence amongst the diverse relevant actors (IF assets customers and end users) by assuring stability, usability, update and by providing free, non-discriminatory access to the IF Assets. GoF4R aims at defining the governance of the IF to promote a large acceptance of the semantic web for transportation, thus encouraging the market uptake of the IF and boosting innovation while removing the barriers for new actors to enter the mobility market.

THE IF ASSET MANAGER AND REGULATORY COMPLIANCE

To be widely accepted the IF Assets should be accessible, usable, stable and updated as much as possible, and the workflow for versioning, review and publication should be managed. One of the objectives of the IF governance process that GoF4R will be to define a workflow that can be applied to each asset type.

Under the Shift2Rail Lighthouse project IT2RAIL, a tool has been established to manage and publish these assets. The IT2Rail Semantic Assets Manager, fully described in IT2Rail D1.2 “Semantic Web Service Registry”, is the component devoted to governing the process of maintaining a shared repository of the mentioned asset types. It is an organized collection and storage of these assets, enhanced by tools to support a workflow process for review, versioning, approval and publishing of the assets. In more details, in the IF tools each asset extension contains a core component allowing business logic of an asset type to be altered with the use of several call-back methods, comprehending in particular the asset manager which is used to override the existing methods to

IFG-WP3-D-UIC-015-02 Page 14 of 153 12/12/2018

Contract No. H2020 – 730844

handle the CRUD (create, read, update and delete) business logic of an asset type. One of the objective of the IF governance process that GoF4R will define concerns the design of this workflow that can be different for each asset type.

The following part of the document provides an overview of the existing regulation; it shall be noted, however, that most of it covers aspects not applying to the IF, such as the data exchange and the rights and duties of the involved actors. GoF4R specifically addresses the rules and processes which need to be applied to the functioning of the Asset Manager. Therefore, the asset manager respects all existing rules, regulations, laws and expectations that relate directly or indirectly to the IF assets.

For instance, it is imperative for the rail sector that the published base Ontologies be fully aligned with the semantic content of the TAF and TAP TSI technical documents3 as published by the European Union Agency for Railways (ERA). It will be up to the Governance structure to assure that the Assets are compliant with myriad Regulations concerning Interoperability, Open Data, Copyright, Data Privacy, Anti-Trust and applicability of Standards.

THE REGULATORY CHALLENGE

According to W3C, “To be effective and implementable, rules, regulations, laws and expectations need to align with the technology to which they are intended to apply. However, new technologies often allow novel communication means, where the causality, responsibility, speed of access, and distribution policies are widely different from those available in non-Internet communication. A mismatch of governance and actual usage often leads to mandated requirements which cannot be easily and consistently interpreted.”4

Provided that it complies with European legislation applying to the various modes of transport, to be effective, the IF governance framework must match the technology and address only those obstacles that are within its authority (i.e. pertaining to the Assets, themselves.) The rationale behind GoF4R is to develop a lean framework based on a full analysis of how this technology will be used and by whom. It is essential that the governance framework does not include new mandatory requirements that could hinder the expected market uptake of the IF.

Regulatory requirements such as privacy, copyright, accessibility and open data were considered in the analysis, with attention to making the IF components available and easy to deploy. The governance model and processes, as proposed, will create the environment for potential market uptake well beyond the lifecycle of the project by creating confidence in the quality and sustainability of the IF Assets.

3Technical Documents for the TAP-TSI Baseline Version 1.3.0, http://www.era.europa.eu/Document- Register/Pages/TAP-TSI-Technical-Documents.aspx 4 Larry Masinster, W3C Editor’s Draft (https://www.w3.org/2001/tag/doc/governanceFramework-2012-07-19.html)

IFG-WP3-D-UIC-015-02 Page 15 of 153 12/12/2018

Contract No. H2020 – 730844

APPLICABILITY TO THE IF

This deliverable will undertake to identify those pertinent Regulations and Standards which directly impact the governance of the IF Assets and develop compliance recommendations for Users of those Assets when deploying the IF in new products and services.

IFG-WP3-D-UIC-015-02 Page 16 of 153 12/12/2018

Contract No. H2020 – 730844

4. EUROPEAN REGULATORY FRAMEWORK

The Regulatory Framework that was considered in this deliverable comprises an analysis of those Regulations that have a direct impact on the IF and its assets. This chapter specifically addresses the Regulations and Technical Specifications for Interoperability (TSIs) that must be considered for developing the governance model, rules and processes applying to the European interoperable rail network. Below is a list of definitions of the elements comprising our research for the Regulatory Environment:

Directive

A “Directive” is a legislative act that sets out a goal that all EU countries must achieve. However, it is up to the individual countries to devise their own laws on how to reach these goals. One example is the EU consumer rights directive, which strengthens rights for consumers across the EU, for example by eliminating hidden charges and costs on the internet and extending the period under which consumers can withdraw from a sales contract.5

Regulation

A Regulation is generally defined as “A rule of order having the force of law, prescribed by a superior or competent authority, relating to the actions of those under the authority's control.6” Its application is mandatory within a certain domain and geographic area. Regulation can support legislation.

TSI

Technical specifications for interoperability (TSIs) mean the specifications by which each subsystem or part of subsystem is covered in order to meet the essential requirements and to ensure the interoperability of the European Community's high speed and conventional rail systems.7

In Europe, a Regulation is a kind of EU wide legislation which is mandatory in all Member States without modification – e.g. REGULATION (EU) 2016-2338 concerning the opening of the market for domestic passenger services by rail, while a Directive is another kind of EU legislation which provides a certain flexibility to Member States in the transposition of the legislation in their national legislation – e.g. DIRECTIVE (EU) 2016/797 on the Interoperability of the rail system within the European Union. A directive and in this case its relevant TSIs (Technical Specifications for Interoperability) leave the responsibility to Member States to define within certain guidelines the scope of application of the TSIs. For example, metro and tram/light rail are excluded from the scope of the TSI, but Member State can also exclude some parts of the mainline rail infrastructure or some regional/local rail rolling stock (and reversely some Member States can apply some TSIs to metro and/or tram/light rail lines).

5 https://europa.eu/european-union/eu-law/legal-acts_en 6 http://legal-dictionary.thefreedictionary.com/Government+regulation 7 http://www.era.europa.eu/core-activities/interoperability/pages/technicalspecifications.aspx

IFG-WP3-D-UIC-015-02 Page 17 of 153 12/12/2018

Contract No. H2020 – 730844

RAIL DIRECTIVES

The main directive related to railway transport in Europe is the Directive on Interoperability, the DIRECTIVE 2008/57/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 17 June 2008, amended by Commission Directive 2011/18/EU, on the interoperability of the rail system within the Community. In its Annex II, the Directive identifies the subsystems of the railway system:

(a) structural areas: — infrastructure, — energy, — control-command and signalling, — rolling stock; (b) functional areas: — traffic operation and management, — maintenance, — telematics applications for passenger and freight services.

For each subsystem (with the exception of maintenance), a specific Technical Specification for Interoperability (TSI) has been prepared, according to requirements defined in the Directive itself. They are now part of the regulatory framework. Especially relevant to GoF4R is the TAP (Telematic Applications for Passenger) and the TAF TSI (Telematic Applications for Freight). The reason that Freight is mentioned here is that the TAF TSI specifically deals with the operational solutions (i.e. Train delays, schedules, etc. that feed passenger information systems relying on the IF.

Some additional TSIs refer to specific aspects like Persons with Reduced Mobility.

The Directive also defines the Essential Requirements which need to be fulfilled. They include general requirements and requirements specific to each subsystem.

The essential requirements related to Telematic Applications for Freight and Passenger are:

Technical compatibility

The essential requirements for telematics applications guarantee a minimum quality of service for passengers and carriers of goods, particularly in terms of technical compatibility.

Steps must be taken to ensure:

- that the databases, software and data communication protocols are developed in a manner allowing maximum data interchange between different applications and operators, excluding confidential commercial data,

- easy access to the information for users.

Reliability and availability

The methods of use, management, updating and maintenance of these databases, software and data communication protocols must guarantee the efficiency of these systems and the quality of the service.

IFG-WP3-D-UIC-015-02 Page 18 of 153 12/12/2018

Contract No. H2020 – 730844

Health

The interfaces between these systems and users must comply with the minimum rules on ergonomics and health protection.

Safety

Suitable levels of integrity and dependability must be provided for the storage or transmission of safety-related information.

Requirements relevant to GoF4R have been highlighted.

In 2019, Directive 2008/57/EC will be finally repealed and replaced by the new Directive:

DIRECTIVE (EU) 2016/797 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 11 May 2016 on the interoperability of the rail system within the European Union

This directive fully excludes “urban rail” from its scope of application, while before it was only optional for Member States. As regard the European interoperable rail network, the envisaged subsystems are the same, apart from splitting the control-command and signalling subsystem:

— trackside control-command and signalling,

— on-board control-command and signalling,

The essential requirements are basically the same, but it is worth to mention the new essential requirement Accessibility, which is also relevant to GoF4R. In general, the requirement states:

The ‘operations’ and ‘telematics applications for passengers’ subsystems must provide for the necessary functionality required to facilitate access for persons with disabilities and persons with reduced mobility on an equal basis with others by way of the prevention or removal of barriers, and by way of other appropriate measures.

In the case of the Telematics Applications for Passenger services, it states:

Appropriate steps must be taken to ensure that telematics applications for passenger subsystems provide for the necessary functionality required to ensure accessibility for persons with disabilities and persons with reduced mobility.

This new essential requirement will have an impact in the revised version of the TAP TSI and possibly on the PRM TSI. The following new requirement related to the Rolling Stock subsystem about Safety is also relevant:

Passengers must be given easily understandable and comprehensive information about rules applicable to them both in railway stations and in trains.

IFG-WP3-D-UIC-015-02 Page 19 of 153 12/12/2018

Contract No. H2020 – 730844

REGULATIONS ON PASSENGER RIGHTS

Due to the distinct characteristics of the different transport modes and their markets, both for the industries (differences in company size, revenues or number of routes) and passengers (differences in length, price and conditions of the trip), the precise contents of these rights vary, but the typology of rights guaranteed by the existing regulations for transport by air, rail, sea and inland waterway and bus and coach are comparable, although with specific provisions for local public transport. A European Vision for Passengers: Communication on Passenger Rights in all transport modes provides an overview of the rights that apply to all modes:

1 Right to non-discrimination in access to transport 2 Right to mobility accessibility and assistance at no additional cost for disabled passengers and passengers with reduced mobility (PRM) 3 Right to information before purchase and at the various stages of travel, notably in case of disruption 4 Right to renounce travelling (reimbursement) when the trip is disrupted 5 Right to the fulfilment of the transport contract (rerouting or rebooking) in case of disruption 6 Right to get assistance in case of long delay at departure or at connecting points 7 Right to compensation 8 Right to carrier liability towards passengers and their luggage 9 Right to a quick and accessible system of complaint handling 10 Right to full application and effective enforcement of EU passenger rights.8

Currently, EU passenger rights apply independently to each transport mode under a single contract of carriage. Passenger rights are not guaranteed if a disruption occurring during one segment of the journey affects the next leg of the trip, if the latter is operated with another transport mode – even if the passenger has booked the whole trip as a single contract. BEUC, the European Consumer Organisation, has listed the following problems as most common regarding multimodal journeys:

 Missed connections due to delays that occurred in the first segment of the trip;  Lack of assistance for passengers in cases of missed connections; Figure 2 Passenger Rights  Consumers are not sure who to complain to in case something goes wrong during their multimodal journey;

8 COM(2011) 898 final: A European Vision for Passengers: Communication on Passenger Rights in all transport modes

IFG-WP3-D-UIC-015-02 Page 20 of 153 12/12/2018

Contract No. H2020 – 730844

 Problems with checking-in after changing the mode of transport;  Timetables not matching and not adapted to the passenger’s change of transport mode;  Lack of cooperation or sufficient exchange of information between operators responsible for different segments of the multimodal journey;  Lack of efficient cooperation between the national authorities dealing with the enforcement of passenger rights;  Lack of information that is complete allowing consumers to easily compare different offers (total cost of the trip, its duration, possibility to cancel or modify the trip etc.);  Often information on travel schedules and fares provided to consumers is not complete.9

In addition, assistance to passengers with a disability or with reduced mobility is not guaranteed during multimodal connections. The EC acknowledges these issues and is therefore examining different policy options to better protect passengers in the EU when using multimodal transport:

Option 1: Self-regulation (“codes of good conduct” or “codes of good practices”) Option 2: Soft laws, guidance and recommendations Option 3: New legislative instrument defining the respective scope of application of modal passenger rights Regulations in case of multimodal transport Option 4: New rules specific to multimodal journeys (legislative instrument).10

9 BEUC (2017): Multimodal journeys. How to make sure passengers are better protected? 10 An impact assessment study was launched in 2016, followed by an open public consultation and a targeted consultation of professional stakeholders.

IFG-WP3-D-UIC-015-02 Page 21 of 153 12/12/2018

Contract No. H2020 – 730844

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) N° 261/2004 Air11 Europe (28 MS + Iceland, Norway, Switzerland) Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders Regulation 261/2004 establishes minimum rights for passengers when they are denied boarding against their will or when their flight is cancelled or delayed.

The Regulation applies to flights departing from any airport situated in the EU, and to flights from a third country to an EU airport, if operated by an EU carrier.12

It contains the following provisions:

Information: Passengers have the right to be informed on their passenger rights13 and the contact details of the National Enforcement Bodies (NEB)s.

Denied boarding, delay or cancellation: If passengers are denied boarding14 or their flight is cancelled, they have the right to choose between re-routing or a refund. In case of long (at least 5 hours) delays, passengers may also opt for a refund. A refund must be paid within 7 days and, where relevant, includes a free journey back to the initial departure point. Re- routing should be offered under comparable travel conditions at the earliest opportunity or at a later date of the passenger’s convenience at no extra cost. In some cases, (delay of two hours or more, depending on flight distance15) passengers may be entitled to additional

11 COM (2013) 130 final: Where a part of the journey is carried out, in accordance with a contract of carriage, by another mode of transport or by helicopter, this Regulation shall apply for the whole journey and the part of the journey carried out by another mode of transport shall be considered as a connecting flight. 12 Provided that passengers have a confirmed reservation and present themselves on time for check-in. The Regulation does not apply to passengers that travel for free or at a reduced fare not (in)directly available to the public; or if passengers have already received benefits (compensation, re-routing, assistance) under relevant law of a non-EU country. 13 A printed or electronic notice must be clearly displayed at the airport check-in desk and be shown at check-in kiosks in the airport and online. If passengers were denied boarding, their flight was cancelled, or they experienced a delay of more than 2 hours at departure or arrive with a long delay at their final destination, the operating carrier must give them a written notice describing the rules for compensation and assistance. 14 The carrier must first call for volunteers to surrender their seats in exchange for benefits. If there are not enough volunteers, the carrier may deny boarding to passengers against their will. 15 2 hours or more (flights of 1.500km or less), 3 hours or more (intra-EU flights of more than 1.500km and all other flights between 1.500 and 3.500km) and 4 hours or more (all other flights)

IFG-WP3-D-UIC-015-02 Page 22 of 153 12/12/2018

Contract No. H2020 – 730844

assistance such as meals and refreshments, access to communication (two free phone calls, telex or fax messages, or e-mails) and, if necessary, accommodation.16

Compensation: In addition, passengers may be entitled to a financial compensation of between €250 and €60017 – depending on flight distance and length of delay – if they are denied boarding, if the flight was cancelled or if it arrives more than 3 hours late at the final destination.18 There will be no compensation if the cancellation (or long delay) is due to extraordinary circumstances (e.g. bad weather), if passengers were informed at least 2 weeks beforehand or if the carrier offered them an alternative flight with a similar schedule.

Upgrading and downgrading: If an air carrier places a passenger in a lower class than indicated on the ticket, the passenger is entitled to reimbursement of part of the ticket price.19 If a passenger is placed in a higher class, he/she may not be charged extra.

Complaints: Passengers should first contact the airline or airport (and submit an air passenger rights EU complaint form). If the issue is not resolved, they can contact the NEB. If needed, they can also pursue the matter through alternative dispute resolution or in court.

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

The Commission Communication of 11 April 2011 showed how the provisions of the Regulation were being interpreted in various ways, due to grey zones and gaps in the text, that enforcement varied between Member States, and that it is difficult for passengers to assert their individual rights. The proposal for an amendment (2013) introduces the following changes:

 Better definition of ‘extraordinary circumstances’  Right to compensation in case of long delays (cf. Sturgeon case)  Time threshold for compensation (cancellation or long delay) increased to 5 hours for intra- EU flights and to 5/9/12 hours depending on the distance for extra-EU journeys  Right to re-routing (after a delay of 12 hours) on other carriers or transport modes, if needed  Single time threshold for the right to care (2 hours for flights of all distances)

16 The right to accommodation includes transport to and from the airport and the place of accommodation. 17 250€ for all flights of 1.500km or less; 400€ for all intra-EU flights of more than 1.500km and all other flights between 1.500 and 3.500km; 600€ for all other flights. These amounts may be reduced by 50% if the delay in arrival (after re- routing) does not exceed 2 hours (flights of 1.500km or less), 3 hours (intra-EU flights and all other flights between 1.500 and 3.500km) or 4 hours (all other flights). The Regulation provides no deadline to pay compensation. 18 The CJEU (Sturgeon case) has ruled that passengers whose flight arrival is delayed by at least three hours also have a right to compensation – even though Regulation 261/2004 did not explicitly include compensation for delays. 19 Reimbursement – 30% of the ticket price (flights of 1.500km or less), 50% (intra-EU flights of more than 1.500km and other flights between 1.500 and 3.500km), 75% (all other flights) – must be paid within 7 days.

IFG-WP3-D-UIC-015-02 Page 23 of 153 12/12/2018

Contract No. H2020 – 730844

 Missed connecting flight: right to care and (in case of a single contract) compensation  Rescheduling with a notice of less than 2 weeks: similar rights to delayed passengers  Right to disembark after 5 hours of tarmac delay  Partial ban of the ‘no show’ policy (denied boarding to passengers who do not take the outward journey of a return flight)  Right to information about a disruption as soon as that information is available  Promotion of out-of-court complaint handling (ADR)  Extension of the role of NEBs to monitor compliance with Regulation 2027/97 (and the Montreal Convention): claims for delayed, lost or damaged baggage  Enhanced coordination and exchange of information between NEBs  Right to information, at reservation, about the airline’s complaint handling procedures  Promotion of electronic means to submit complaints  Deadline for airlines to respond to complaints set at 2 months  Airlines may limit the cost of accommodation in case of major disruptions to three nights and 100€/night per passenger – except for PRM  No obligation to provide accommodation in case of flights of less than 250km on aircrafts with max. 80 seats (other than connecting flights) – except for PRM  Obligation for airports and airlines to set up contingency plans to optimise care and assistance to stranded passengers  Obligation for airlines to correct spelling mistakes free of charge up to 48h before departure  Right to full compensation for loss of or damage to mobility equipment (by compelling air carriers to automatically offer the option to make a special declaration of interest – for free)  More transparency with regard to baggage allowances (at booking and at the airport)  Measures with regard to the carriage of musical instruments  Liability limits are adapted in accordance to general price inflation.

The proposal is currently being examined by the EU legislature. In the meantime, the Commission has issued Interpretative Guidelines (2016) to facilitate and improve the application of the Regulation in the short term and to promote best practices, taking into account case-law that has had a decisive impact on the interpretation of the Regulation.

Impacts and Considerations for the Governance of the IF Assets The Regulation does not have a direct impact on the IF Assets as it affects the carriers and those providers who must comply with the terms of the legislation. Therefore, it is the users of the IF Assets who need to be cognisant of the terms within the Regulation. This applies to carriers, entrepreneurs, ticket vendors and service providers who will be using the Assets (including new IP4 development.) It may be possible to codify and publish the rules as a part of the data sets. The aforementioned stakeholders will be responsible for making sure that they are in compliance with the terms and eventual updates to the Regulation.

IFG-WP3-D-UIC-015-02 Page 24 of 153 12/12/2018

Contract No. H2020 – 730844

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) N° 889/2002, amending Air Europe (28 MS + Iceland, Norway, Council Regulation (EC) N°2027/92 Switzerland) Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders Regulations 889/2002 and 2027/92 deal with air carrier liability in the event of accidents:

Liability towards passengers: There are no financial limits to liability for passenger injury or death. For damages up to 100 000 SDRs, the carrier cannot contest claims. Above that amount, it can defend itself by proving it was not negligent or at fault. The carrier must make an advance payment to cover immediate economic needs.

Liability in case of delays: The carrier is liable for damage in case of delay unless it took all reasonable measures to avoid the damage or it was impossible to take such measures. Liability is limited to 4 150 SDRs for passenger delay and 1 000 SDR for baggage delay.

Liability towards luggage: The carrier is liable for destruction, loss or damage to baggage up to 1 000 SDRs: for checked baggage even if not at fault, unless the baggage was defective; for hand luggage only if at fault. If travelling with expensive items, passengers may, for a fee, request a higher compensation limit. To do this, they should make an advance declaration to the airline at the latest when they check in.

Complaints: To file a claim for lost or damaged luggage, passengers should write to the airline within 7 days, or within 21 days of receiving their luggage if it was delayed. Actions to claim damages must be brought to court within two years.

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

MS are not required to establish NEBs to ensure the correct application of this Regulation (contrary to other passenger rights regulations). However, the proposal for an amendment (2013) foresees that the role of NEBs that currently monitor compliance with Regulation 261/2004 should be extended to include claims for delayed, lost or damaged baggage. The proposed amendment also introduces the following changes:

IFG-WP3-D-UIC-015-02 Page 25 of 153 12/12/2018

Contract No. H2020 – 730844

 Right to full compensation for loss of or damage to mobility equipment for passengers with a disability or PRM (by compelling air carriers to automatically offer the option to make a special declaration of interest – at no additional cost)  Liability limits adapted in accordance to general price inflation.

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) N° 1008/2008 Air Europe Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders Regulation 1008/2008 defines common rules for the operation of air services in the EU. It regulates the licensing of Community air carriers and the pricing of intra-Community air services. Article 23 deals with information and non-discrimination.

Non-discriminatory contract conditions: When buying a ticket, passengers may not be charged a higher price because of their nationality or where they are buying the ticket from.

Pricing: The published fare shall include the applicable air fare as well as any taxes, charges, surcharges and fees that are unavoidable and foreseeable. The final price shall at all times be indicated and details must be given on its components. Optional price supplements shall be communicated clearly at the start of the booking process and their acceptance by the customer shall be on an ‘opt-in’ basis.

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

IFG-WP3-D-UIC-015-02 Page 26 of 153 12/12/2018

Contract No. H2020 – 730844

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) N° 2111/2005 Air Europe Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders Regulation 2111/2005 provides rules on the establishment of a Community list of air carriers which, for safety reasons, are subject to an operating ban in the Community; and on informing air passengers of the identity of the air carrier operating the flights on which they travel.

Ticket sellers, tour operators and travel agents must inform passengers which airline is planned to be used for their travel when they make their bookings. Passengers must be informed of any changes as soon as possible and, at the latest, at check-in or when boarding. They are entitled to reimbursement or re-routing if the airline is placed on the banned list after they make their booking.

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

IFG-WP3-D-UIC-015-02 Page 27 of 153 12/12/2018

Contract No. H2020 – 730844

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) N° 80/2009 Air (+rail) Europe Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders Regulation 80/2009 sets out a harmonised Code of Conduct for computerised reservation systems (CRS) to ensure fair competition and protection of consumers’ rights. It applies to air transport (and rail transport when combined with a flight) and addresses the following key points:

 System vendors may not attach any unfair or unjustified conditions on airlines or on their own subscribers; or prevent an airline from using other reservation systems.  System vendors must display available services and fares in a non-discriminatory way and load and process data provided by airlines with equal care and timeliness.  They must clearly indicate the extent of a capital holding they have in an airline or vice versa.  They must clearly indicate in the display airlines that are banned from operating in the EU.  The Regulation also prescribes that personal data may only be processed for the purposes for which they were given (i.e. making a reservation or issuing a ticket).20

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

In 2009, the Commission adopted an explanatory note explaining how it interprets the concept of a ‘parent carrier’ which may have a decisive influence on the running of the system vendor's business.

20 Computerised air ticket reservation systems – Summary of Regulation (EC) 80/2009

IFG-WP3-D-UIC-015-02 Page 28 of 153 12/12/2018

Contract No. H2020 – 730844

Associated Legislation and Conventions The Montreal Convention (Convention for the unification of certain rules for international carriage by air, 2001) applies to all international carriage of persons, baggage or cargo. Regulation N° 2027/97 lays down the obligations of Community air carriers in relation to liability in the event of accidents to passengers. Regulation (EC) N° 889/2002 amends Council Regulation (EC) N° 2027/97, aligns it with the provisions of the Montreal Convention and extends the application of the Convention’s rules to air services provided within the territory of a Member State.

Passengers who travel by air as part of a package trip enjoy additional rights under Directive (EU) No 2015/2302 on package travel and linked travel arrangements.

The EC has encouraged airlines and airports to prepare voluntary commitments21 to improve their quality of service.

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) N° 1371/2007 Rail Europe (28 MS + Iceland, Norway, Switzerland) Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders EU rail passenger rights generally apply to all rail journeys within the EU. National governments can decide to exempt domestic rail services (regional, urban, suburban transport) and international services that start or finish outside the EU. Nonetheless, certain provisions are mandatory for all kinds of railway services within the EU.22

It contains the following provisions:

21 Airport Voluntary Commitment on Air Passenger Service – Airline Passenger Service Commitment on Air Passenger Service 22 MS may grant an exemption: to purely domestic railway traffic (for a period of five years, which may be renewed twice); to urban, suburban and regional services; to rail services of which a significant part is operated outside the EU (for a period of five years, which may be renewed). During the first five years of application, MS granted extensive exemptions and only small improvements are expected in the near future (COM (2015) 117 final). The following provisions apply to all railway traffic within the EU: rules on availability of tickets, through tickets and reservations (Art 9); liability of railway undertakings for passengers and their luggage (Art 11); minimum level of insurance for railway companies (Art 12); right to transport of PRM (Art 19); information on accessibility of rail services (Art 20(1)); and obligations on passengers' personal security (Art 26).

IFG-WP3-D-UIC-015-02 Page 29 of 153 12/12/2018

Contract No. H2020 – 730844

Information: Passengers have the right to be informed on their passenger rights, contact details of the NEBs and conditions of access for PRM and disabled persons. Passengers must also be informed comprehensively on applicable transport conditions, both pre-journey (general contract conditions, fastest trip and lowest fares, facilities for PRM, possibility to take bicycles, services on board, first and second class, possibility to file complaints and to reclaim lost luggage, information on disruptions and delays) and during the journey (services on board, next station, main connecting services, delays, security and safety issues).

Non-discriminatory contract conditions: When buying a ticket, passengers may not be charged a higher price because of their nationality or where they are buying the ticket from.23 The Regulation also specifies how railway undertakings shall distribute tickets24 and which information should be included on the ticket and luggage registration voucher. In order to provide information and to issue tickets, railway undertakings and ticket vendors should use CIRSRT (Computerised Information and Reservation System for Rail Transport).

Delay or cancellation: If a train is delayed or cancelled, passengers have the right to adequate and timely information.25 In case of a delay at arrival of more than 1 hour, passengers have the right to choose between re-routing – at the earliest opportunity or at a later date of their choice, under comparable conditions, at no extra cost – or a refund (sometimes in full, sometimes only for the part of the journey not made). A refund, where relevant, includes a free journey back to the initial departure point. Passengers must also be offered additional assistance such as meals and refreshments26 and, if necessary, accommodation. At the request of the passenger, the railway undertaking shall certify on the ticket that the service has been delayed, cancelled or has led to a missed connection.

Compensation: If passengers decide to continue their journey in spite of delay, or accept alternative transport, they may be entitled to a financial compensation of 25% to 50% of the ticket price – depending on the length of delay.27 If they were informed of a delay before buying the ticket, they will not receive compensation. The CJEU has ruled that the exception of ‘force majeure’ does not apply for rail.28

23 This is not explicitly mentioned in the rail passenger rights Regulation (contrary to other modes), but (direct or indirect) discrimination on grounds of nationality is contrary to article 18 TFEU. 24 I.e. at least via one of the following: ticket offices or selling machines; telephone, Internet or any other widely used IT; on board trains. For PSC services: at least via one of the following: ticket offices or selling machines; on board trains. Tickets should be offered on board, unless this is not possible for reasons relating to security, antifraud policy, compulsory train reservation or reasonable commercial grounds. Where available, through tickets and reservations should be offered. 25 They must be informed of a delay or cancellation as soon as possible. 26 In relation to the waiting time, and provided that they are available or can reasonably be provided 27 25% in case of a delay of 1-2 hours, 50% in case of a delay of more than 2 hours. Passengers with a travel pass or season ticket may also request compensation for recurrent delays. Carriers may introduce a minimum threshold to pay compensation (that may not exceed 4EUR). Compensation must be paid within 1 month in vouchers and/or other services (if conditions are flexible) or, in money if the passenger requests it. 28 However, the Commission is examining the possibility to give the rail sector the same treatment as other modes, i.e. not to compensate passengers for delays caused by extraordinary circumstances.

IFG-WP3-D-UIC-015-02 Page 30 of 153 12/12/2018

Contract No. H2020 – 730844

Liability towards passenger and luggage: If a passenger is injured or killed in a train accident, they (or their dependants) are entitled to compensation, with an advance payment within 15 days cover immediate needs.29 If registered luggage is lost or damaged during the trip, passengers have a right to compensation, unless it was inadequately packed, unfit for transport or had a special nature.30 If a passenger is killed or injured in a train accident, they (or their dependants) are entitled to compensation for lost or damaged hand luggage (registered or not).31 In other cases, the carrier is not liable for loss of or damage to hand luggage, unless the passenger proves it is due to the fault of the carrier.

Complaints: Passengers should first contact the railway company, who must have a complaint handling system in place.32 If the issue is not resolved, they can contact the NEB. If needed, they can also pursue the matter through alternative dispute resolution or in court.

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

The Report on the Application of Regulation 1371/2007 (COM(2013) 587 final) concluded that the overall application of the Regulation is satisfactory, but that the extensive use of exemptions is a serious obstacle to fulfilling its objectives and that enforcement is lagging behind in some MS.

The EC envisages to revise the rights of railway passengers and started the process by issuing the Regulation proposal 2017/0237 as a draft. The current proposal aligns rail with general aspects of passenger rights on other modes and addresses five main issues:

 Uniform application of the rules (long distance domestic and cross-border urban, suburban and regional services can no longer be exempted)  Information (improved information on passenger rights, e.g. by printing it on the ticket; passengers using connected services must be informed whether these rights apply to the whole journey or only to each segment separately) and non-discrimination (discrimination on the basis of nationality or residence is explicitly prohibited)  Strengthening the rights for persons with disabilities or reduced mobility (mandatory right to assistance, full compensation for loss or repair of mobility equipment, provision of information in accessible formats, disability awareness training for rail staff)

29 The carrier is not liable if the accident is caused by circumstances not connected with the operation of the railway or by the behaviour of a third party, which the carrier could not avoid; or due to the fault of the passenger. The amounts of damages are to be determined in accordance with national law. 30 If they can prove the value: up to 1.300EUR per piece; if they can’t prove the value: 330EUR per piece 31 Up to a maximum of 1.500EUR 32 The carrier has to notify the passenger within 1 month of receipt of the complaint; and has to provide the passenger with a final reply within 3 months of receipt of the complaint.

IFG-WP3-D-UIC-015-02 Page 31 of 153 12/12/2018

Contract No. H2020 – 730844

 Enforcement, complaint-handling procedures and sanctioning (clear deadlines for complaint handling and responsibilities/competences of NEBs)  Proportionality and legal fairness (a "force majeure" clause: railway companies will not be obliged to pay compensation in case of delays caused by natural disasters).

The Commission's proposal must now be examined and shall be amended – following the normal EU process for EU legislation - before adoption by the European Parliament and the Council (i.e. the EU Member States)33.

Associated Legislation and Conventions Regulation (EU) N°1371/2007 builds on the existing system of international law contained in Appendix A, "Uniform rules concerning the Contract for International Carriage of Passengers and Luggage by Rail (CIV)" to the Convention concerning International Carriage by Rail (COTIF) of 9 May 1980, as modified by 1999 Protocol. Except where MS decide to opt for derogations, the Regulation extends the scope of this Convention, which makes reference only to international railway services, to domestic and urban, suburban and regional rail passengers' transport services, provided by railway undertakings34 licensed in accordance with Directive 95/18/EC.35

More detailed requirements regarding the provision of travel information are set out in the technical specifications for interoperability (TSIs) referred to in Regulation (EU) N° 454/2011.

Passengers who travel by rail as part of a package trip enjoy additional rights under Directive (EU) No 2015/2302 on package travel and linked travel arrangements.

33 Cf. https://ec.europa.eu/transport/themes/passengers/news/2017-09-28-european-commission-modernises-european- rail-passenger-rights_en 34 Most urban rail operators are not “railway undertakings” and are not licensed, so they are not covered by the legislation. 35 Council Directive 95/18/EC of 19 June 1995 on the licensing of railway undertakings

IFG-WP3-D-UIC-015-02 Page 32 of 153 12/12/2018

Contract No. H2020 – 730844

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EU) N° 181/2011 Bus and Coach Europe (28 MS + Iceland, Norway, Switzerland) Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders Regulation 181/2011 covers the rights of passengers travelling by bus or coach. These rights mainly apply to regular (i.e. provided at specified intervals, along specified routes, with predetermined stopping points) long-distance (more than 250km) bus and coach services starting or finishing in an EU country. Some rights apply to all regular services.36 Some also apply to ‘occasional services’.37 MS can decide to exempt (for 4 years, may be renewed once) purely domestic regular services and regular services where a large part of the route – including a scheduled stop – is outside the EU.38 Most local bus services (by far the largest part of bus services) have to follow public service obligations and are exempted from this legislation: they have to cope with the rules of Regulation 1370/2007 on public passenger transport services by rail and by road.

It contains the following provisions:

Information: Passengers have the right to adequate information throughout their travel. This includes the right to be informed on their passenger rights and the contact details of the NEBs, and on conditions of access for PRM and disabled persons.

Non-discriminatory contract conditions: When buying a ticket, passengers may not be charged a higher price because of their nationality or where they are buying the ticket from. For long-distance trips (more than 250km), the carrier shall issue a ticket to the passenger (which may be in electronic format), unless other documents give entitlement to transport.

36 Non-discriminatory transport conditions; PRM access at no additional cost, financial compensation for loss or damage to mobility equipment; travel information and information on passenger rights; complaint handling mechanism; NEBs 37 Non-discriminatory transport conditions; provision of a ticket or entitlement; compensation and assistance in case of death, injury, loss or damage caused by accidents; financial compensation for loss or damage to mobility equipment. Occasional services are services where the group of passengers is constituted on the initiative of the customer or the carrier himself, provided that the service starts or finishes in an EU MS. 38 COM (2016) 619 final: In 2015, 12 MS were applying exemptions of the first type; 13 MS were applying exemptions of the second type. These exemptions have expired on 28 February 2017 at the latest, and may be renewed once.

IFG-WP3-D-UIC-015-02 Page 33 of 153 12/12/2018

Contract No. H2020 – 730844

Delay or cancellation: If a (long-distance) bus/coach service is delayed or cancelled, passengers have the right to adequate and timely information.39

If a long-distance service (more than 250km) is cancelled, if departure is delayed for more than 2 hours, or in case of overbooking, passengers have the right to choose between re- routing – at the earliest opportunity under comparable conditions, at no extra cost – or a refund. A refund, where relevant, includes a free journey back to the initial departure point.40 If a long-distance journey (more than 250km) was scheduled to last more than 3 hours and departure is delayed by at least 90 minutes, or cancelled, passengers are also entitled to additional assistance such as meals and refreshments41 and, if necessary, accommodation.42

Compensation: If a long-distance service (more than 250km) is cancelled, if departure is delayed for more than 2 hours, or in case of overbooking, and the carrier fails to offer passengers the choice between re-routing or a refund, they have the right to claim not only a refund but also a compensation worth 50% of the ticket price.43

Liability in case of accidents: In case of injury or death resulting from a bus accident during a long-distance journey (more than 250km), passengers (or their successors) have a right to compensation. Passengers are also entitled to compensation if their luggage or other belongings are lost or damaged in a bus accident on a long-distance journey. For PRM, compensation for loss of or damage to wheelchairs or other mobility equipment will cover the full cost of replacement or repair. In case of accidents, where necessary, the carrier also has to provide immediate assistance: first aid, food, clothes, transport and accommodation44. Compensation in the case of accidents is not automatic; it must be claimed in national courts. Conditions and amounts are governed by national law.

Complaints: Passengers should first contact the carrier, who must have a complaint handling system in place.45 If the issue is not resolved, they can contact the NEB. If needed, they can also pursue the matter through alternative dispute resolution or in court.

39 They must be informed of a delay or cancellation no later than 30 minutes after the scheduled time of departure. The estimated departure time must be communicated as soon as that information becomes available. In case of a missed connection, the carrier or terminal should inform passengers of alternative connections. 40 This provision does not apply if passengers have an ‘open ticket’ with no specified departure time, except for passengers who have a season ticket or travel pass. In those cases, payment shall be proportional to the full cost of the pass or ticket. Reimbursement shall be made within 14 days – in money, unless the passenger agrees to another form of reimbursement. 41 In relation to the waiting time, and provided that they are available or can reasonably be provided 42 Carriers are not obliged to provide accommodation if the delay was caused by severe weather conditions or natural disasters. They may limit accommodation to 2 nights, at a maximum rate of 80EUR per night. 43 Compensation must be paid within 1 month. 44 Accommodation may be limited to 2 nights and a maximum of 80EUR per passenger per night. 45 The complaint must be sent to the carrier within 3 months; the carrier then has to notify the passenger within 1 month of receipt of the complaint; and has to provide the passenger with a final reply within 3 months of receipt of the complaint.

IFG-WP3-D-UIC-015-02 Page 34 of 153 12/12/2018

Contract No. H2020 – 730844

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

In January 2016, the Commission consulted various organisations representing passengers and the industry to evaluate the application of the Regulation. Passengers’ representatives regretted the extensive use of exemptions (which makes it very difficult for passengers to know which rights they have in which MSs) and the fact that most of the Regulation’s provisions apply only to long-distance regular services (which accounts for only a very small part of regular bus and coach journeys). The Report on the implementation of Regulation 181/2011 (2016) concluded there was no need for any amendments of the Regulation, but that the current Regulation should be applied more effectively.46

Associated Legislation and Conventions Passengers who travel by bus or coach as part of a package trip enjoy additional rights under Directive (EU) No 2015/2302 on package travel and linked travel arrangements.

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) N° 1177/2010 Water Europe (28 MS + Iceland, Norway, Switzerland) Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

46 COM(2016) 619 final

IFG-WP3-D-UIC-015-02 Page 35 of 153 12/12/2018

Contract No. H2020 – 730844

Scope and Stakeholders Regulation 1177/2010 covers the rights of passengers when travelling by sea and inland waterway.

With some exceptions47, the Regulation applies to passenger services where the port of embarkation is in a MS, passenger services from a port in a third country to an EU port if operated by an EU carrier, and cruise services48 with a port of embarkation in the EU.

It contains the following provisions:

Non-discriminatory contract conditions: Carriers shall issue a ticket to the passenger (which may be in electronic format), unless other documents give entitlement to transport. When buying a ticket, passengers may not be charged a higher price because of their nationality or where they are buying the ticket from.

Delay or cancellation: If the ship is delayed or cancelled, passengers have the right to adequate and timely information.49 In case of a cancellation or a delay at departure of more than 90 minutes, they must be offered a choice between re-routing – at the earliest opportunity under comparable conditions, at no extra cost – or a refund. A refund, where relevant, includes a free journey back to the initial departure point.50 Passengers will also be offered additional assistance such as meals and refreshments51 and, if necessary, accommodation.52 Such assistance is not due if the passenger is informed before purchasing the ticket or if the cancellation or delay is caused by the fault of the passenger.

47 The Regulation does not apply to small ships that can carry up to 12 passengers and/or have no more than 3 crew members, most historical ships, excursion and sightseeing ships other than cruises, and services that cover a distance of less than 500m one way. In addition, MS may exempt – provided that the rights of passengers are adequately ensured under national law – seagoing ships of less than 300 gross tons operated in domestic transport until 17 December 2014 and for an indefinite period of time passenger services covered by public service obligations, public service contracts or integrated services. However, none of the MS have made use of these exemptions (COM(2016) 274 final). 48 Cruise ship passengers have no right to re-routing and reimbursement in case of cancelled or delayed departures and no right to compensation in case of delay in arrival. 49 They must be informed of a delay or cancellation no later than 30 minutes after the scheduled time of departure. The estimated departure and arrival time must be communicated as soon as that information becomes available. In case of a missed connection, the carrier or operator should inform passengers of alternative connections. 50 The refund must be made within 7 days, in cash, by electronic bank transfer, bank order or bank cheque; or, if the passenger agrees, in vouchers and/or other services if the conditions are flexible. 51 In relation to the waiting time, and provided that they are available or can reasonably be provided 52 Accommodation may be offered on board or ashore (it then includes transport to and from the port terminal). The carrier is not obliged to offer free accommodation if the cancellation or delay is caused by weather conditions endangering the safe operation of the ship; and The carrier may limit the total cost of accommodation ashore to 80EUR per night per passenger, for a maximum of 3 nights.

IFG-WP3-D-UIC-015-02 Page 36 of 153 12/12/2018

Contract No. H2020 – 730844

Compensation: In case of a delay on arrival of at least 1 hour, passengers may be entitled to a compensation of 25% resp. 50% of the ticket price53 (depending on the length of the delay and the length of the scheduled journey). If the delay is caused by weather conditions or extraordinary circumstances, if the passenger is informed before purchasing the ticket, or if the cancellation or delay is caused by the fault of the passenger, compensation is not due.

Complaints: Passengers should first contact the carrier or terminal operator, who must have a complaint handling system in place.54 If the issue is not resolved, they can contact the NEB. If needed, they can also pursue the matter through alternative dispute resolution or in court.

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

The Regulation requires Member States to designate national enforcement bodies (NEBs) to enforce it and to lay down effective, proportionate and dissuasive penalties in their national law to sanction operators that breach it. Passengers may submit complaints about alleged infringements to the NEB. Where a MS has decided to exempt certain services, it will need to ensure that a comparable mechanism of enforcement of passenger rights has been put in place.

In its Report on the Application of Regulation 1177/2010 (2016), the Commission considers that overall implementation of the Regulation is satisfactory and that at this stage, no amendments are needed, even though the level of application varies significantly between MS and between carriers.55

Impacts and Considerations for the Governance of the IF Assets The Regulation does not have a direct impact on the IF Assets as it affects the carriers and those providers who must comply with the terms of the legislation. Therefore, it is the users of the IF Assets who need to be cognisant of the terms within the Regulation. This applies to carriers, entrepreneurs, ticket vendors and service providers who will be using the Assets (including new IP4 development.) It may be possible to codify and publish the rules as a part of the data sets. The stakeholders will be responsible for making sure that they are in compliance with the terms of and eventual updates to the Regulation.

53 25% if the delay in arrival exceeds 1-2-3-6 hours in case of a scheduled journey of up to resp. 4-8-24-more than 24 hours; 50% if the delay in arrival exceeds 2-4-6-12 hours in case of a scheduled journey of up to resp. 4-8-24-more than 24 hours. Passengers with a travel pass or season ticket may also request compensation for recurrent delays. Carriers may introduce a minimum threshold to pay compensation (that may not exceed 6EUR). Compensation must be paid within 1 month in vouchers and/or other services (if conditions are flexible) or in money if the passenger requests it. 54 The complaint must be sent to the carrier within 2 months; the carrier has to notify the passenger within 1 month of receipt of the complaint; and has to provide the passenger with a final reply within 2 months of receipt of the complaint. 55 COM(2016) 274 final

IFG-WP3-D-UIC-015-02 Page 37 of 153 12/12/2018

Contract No. H2020 – 730844

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) N° 392/2009 Water Europe Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders Regulation 392/2009 covers the rights of passengers travelling by sea in the event of accidents. The Regulation applies to all carriers in international carriage, and certain types of domestic carriage – provided that the ship is flying the flag of a MS or is registered in a MS; or the contract of carriage has been made in a MS; or the place of departure and/or arrival is in a MS.

It covers liability of the carrier in respect of passengers, their luggage and their vehicles, as well as mobility equipment, in the event of (shipping and non-shipping) accidents.

It contains the following provisions:

Information: The carrier must inform passengers on their rights in the event of accidents, prior to or on departure.

Liability towards passengers: In the case of injury or death resulting from an accident at sea, passengers (or their successors) have a right to compensation, except if the incident is due to extraordinary circumstances beyond the carrier’s control. In case of a non-shipping accident, the passenger has to prove that it was caused by the carrier’s fault or neglect.

Liability towards luggage: In case of luggage (cabin luggage, vehicles, other luggage) being lost or damaged in an accident at sea, passengers are entitled to compensation. For PRM, compensation for loss of or damage to wheelchairs or other such equipment will cover the full cost of replacement or repair. In case of a shipping accident, compensation is not due if the carrier proves that it occurred without his fault or neglect. In case of a non-shipping accident, the passenger has to prove that it was caused by the carrier’s fault or neglect.

Advance payments: Passengers have a right to receive an advance payment from the carrier to cover immediate needs in case of injury or death caused by shipping accidents.

Complaints / claims: Claims for loss or damage during accidents at sea can be brought to court within 2 years. The passenger must inform the carrier in writing of damaged or lost luggage as soon as possible, at the latest within 15 days of disembarkation or delivery.

IFG-WP3-D-UIC-015-02 Page 38 of 153 12/12/2018

Contract No. H2020 – 730844

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

Associated Legislation and Conventions Regulation 392/2009 incorporates certain provisions of the 1974 Athens Convention (as amended by the 2002 Protocol) relating to the carriage of passengers and their luggage by sea. Carriers have the right to limit their liability for accidents in accordance with the International Convention on Limitation of Liability for Maritime Claims (1976), as amended by the 1996 Protocol.

Passengers who travel by ship as part of a package trip enjoy additional rights under Directive (EU) No 2015/2302 on package travel and linked travel arrangements.

When buying goods and services anywhere in the EU (in this case, meaning the 28 MS + Iceland, Liechtenstein and Norway), consumer rights apply.56

Some provisions are also relevant with regard to travel services.

The Package Travel Directive (Directive 2015/2302) rules on package travel and linked travel arrangements cover not only traditional package holidays, but also give protection to consumers who book other forms of combined travel, such as flights plus hotel or car rental put together on a website or through linked websites.57

The following legislation on consumer rights may also be relevant:

 Consumer Rights Directive (Directive 2011/83/EU)  Consumer Sales and Guarantees Directive (Directive 1999/44/EC)  Unfair Contract Terms Directive (Council Directive 93/13/EEC)  Price Indication Directive (Directive 98/6/EC)  Unfair Commercial Practices Directive (Directive 2005/29/EC)

56 https://europa.eu/youreurope/citizens/consumers/shopping/index_en.htm and https://ec.europa.eu/info/consumers_en provides an overview 57 Cf. https://ec.europa.eu/info/live-work-travel-eu/travelling-within-eu/package-travel-and-timeshare/package-travel- and-timeshare-policy-information_en for an overview

IFG-WP3-D-UIC-015-02 Page 39 of 153 12/12/2018

Contract No. H2020 – 730844

 Misleading and comparative advertising Directive (Directive 2006/114/EC).

With regard to dealing with infringements of existing (Passenger and Consumer) rights regulations, the following legislation is relevant:

 Consumer Protection Cooperation Directive (Directive 2006/2004)  Injunctions Directive (Directive 2009/22/EC).

In case of complaints or problems, consumers have a number of different options: informal dispute resolution, out-of-court procedures and formal legal action. The following EU legislation is relevant in this context:

 Alternative Dispute Resolution (Directive 2013/11/EU)  Online Dispute Resolution (Regulation 524/2013)  Small Claims Procedure (Regulation 861/2007).

REGULATION ON PROVISION OF EU-WIDE MULTIMODAL TRAVEL INFORMATION SERVICES

Regulation/Standard/Convention Mode Geographic Applicability

Commission delegated regulation - All Europe (28 MS + Iceland, C(2017)3574 Norway, Switzerland) Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders

The Commission Delegated Regulation (EU)58 (released on 31st May 2017) focuses on the priority action “provision of EU-wide multimodal travel information services” mentioned in the Directive 2010/40/EU59. It establishes the specifications necessary to ensure the accessibility, exchange and update of static and dynamic transportation data for the provision of multimodal information services in the European Union.

58Commission Delegated Regulation (EU) C (2017) 3574 Final supplementing Directive 2010/40/EU of the European Parliament and of the Council with regard to the provision of EU-wide multimodal travel information services. Available at: https://ec.europa.eu/transport/sites/transport/files/c20173574-multimodaltravelinformationservices- delegatedregulation.pdf

59 Directive 2010/40/EU of the European Parliament and of the Council of 7 July 2010 on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport. Available at: http://eur- lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:207:0001:0013:EN:PDF

IFG-WP3-D-UIC-015-02 Page 40 of 153 12/12/2018

Contract No. H2020 – 730844

A by-product of the EU Digital Single Market Strategy, the Delegated Regulation establishes the necessary requirements to make available accurate and timely information across borders. Its objective is to “ensure the accessibility, exchange and update of travel information and traffic data and distributed journey planning for the provision of multimodal information services in the EU… The relevant stakeholders include transport authorities, transport operators, travel information service providers, infrastructure managers and transport on demand service providers, etc.”

The objective is to support the interoperability and quality of multimodal information services across Europe. As such, it shall provide the framework to supply easily accessible and reliable information for travellers.

The relevant interoperability frameworks underpinning the Delegated Regulation include Directive 2007/2 EC60 (INSPIRE Directive) which creates a EU-wide spatial data infrastructure to share information related to transport networks and the TAP-TSI, which is addressed in chapter 4.5.2.

Impacts and Considerations for the Governance of the IF Assets

There are two main policy aspects that need to be taken into consideration related to the IF Assets:

 Data Exchange: Where stakeholders continue to use national and/or proprietary formats for exchanging data, which hinders interoperability and system integration. The move toward legislation and industry-level standardisation must be considered, namely the use of TAP TSI for railways, INSPIRE for spatial data, Priority action ‘B’ for road and IATA for aviation. These standards, datasets and schemas must be included as IF Assets and should be monitored and updated continuously.

 National Access Points: The Regulation calls for the establishment of National Access Points:

- (Article 3.1) “Each Member State shall set up a national access point. The national access point shall constitute a single point of access for users to at least the static travel and traffic data and historic traffic data of different transport modes, including data updates, as set out in Annex I61, provided by the transport authorities, transport operators, infrastructure managers or transport on demand service providers within the territory of a given Member State.”

- (Article 4.4) “APIs that provide access to static travel and traffic data listed in Annex I via the national access point shall be publicly accessible allowing users and end-users to register to obtain access.”

60 Available at: http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1520958059859&uri=CELEX:32007L0002 61 Annex 1 of Commission Delegated Regulation (EU) …/... supplementing Directive 2010/40/EU of the European Parliament and of the Council with regard to the provision of EU-wide multimodal travel information services. Available at: https://ec.europa.eu/transport/sites/transport/files/c20173574-multimodaltravelinformationservices-delegatedregulation-annex.pdf

IFG-WP3-D-UIC-015-02 Page 41 of 153 12/12/2018

Contract No. H2020 – 730844

- (Article 3.4) “Transport authorities, transport operators, infrastructure managers or transport on demand service providers shall provide the metadata in order to allow users to discover and use the datasets made accessible through the national access points”.

In its Article 4 on Accessibility, exchange and re-use of static travel and traffic data, the Regulation makes reference to several specifications and standards that shall have to be applied:

- (Article 4.1): Transport authorities, transport operators, infrastructure managers or transport on demand service providers shall provide the static travel and traffic data and historic traffic data listed in point 1 of Annex I, of the different transport modes by using: a) for the road transport, the standards defined in Article 4 of Commission Delegated Regulation (EU) No 2015/962; b) for other transport modes, the following standards and technical specifications: NeTEx CEN/TS 16614 and subsequent versions, technical documents defined in Commission Regulation (EU) No 454/2011 and subsequent versions, technical documents elaborated by IATA or any machine-readable format fully compatible and interoperable with those standards and technical specifications; c) for the spatial network the requirements defined in Article 7 of Directive 2007/2/EU. - (Article 4.2): The relevant static travel and traffic data listed in point 1 of Annex I that are applicable to NeTEx and DATEX II shall be represented through minimum national profiles. - (Article 4.3): Transport authorities, transport operators, infrastructure managers or transport on demand service providers shall provide the static travel and traffic data through the national access point in the required formats in line with the following timetable: a) for the travel and traffic data set out in point 1.1 of Annex I for the comprehensive TEN-T network, by 1 December 2019 at the latest; b) for the travel and traffic data set out in point 1.2 of Annex I for the comprehensive TEN-T network, by 1 December 2020 at the latest; c) for the travel and traffic data set out in point 1.3 of Annex I for the comprehensive TEN-T network, by 1 December 2021 at the latest; d) for the travel and traffic data set out in points 1.1, 1.2 and 1.3 of Annex I for the other parts of the Union transport network, by 1 December 2023 at the latest.

In its Article 5 on Accessibility, exchange and re-use of dynamic travel and traffic data, the Regulation makes reference to several specifications and standards that shall have to be applied:

1. (Article 5.1): Where the Member States decide to provide the dynamic travel and traffic data of different transport modes listed in point 2 of Annex I through the national access point, transport authorities, transport operators, infrastructure managers or transport on demand service providers shall use:

IFG-WP3-D-UIC-015-02 Page 42 of 153 12/12/2018

Contract No. H2020 – 730844

a) for the road transport the standards defined in Articles 5 and 6 of Commission Delegated Regulation (EU) 962/2015, b) for the other transport modes: SIRI CEN/TS 15531 and subsequent versions, technical documents defined in Commission Regulation (EU) No 454/2011 or any machine-readable format fully compatible and interoperable with those standards or technical documents. - (Article 5.2): The relevant travel and traffic data referred to in point 2 of Annex I applicable to SIRI and DATEX II shall be represented through minimum national profiles determined by Member States accessible through the national access point.

GoF4R will use the National Access Points as a use case in WPs 4 and 5 in order to publish the related datasets and manage the NAP access requirements.

REGULATIONS ON PERSONS WITH REDUCED MOBILITY (PRM)

People with a disability and PRM should get the same opportunities for travel as anyone else, at no extra cost

Persons with a disability and PRM can’t be stopped from buying a ticket, making a reservation or getting on board of an airplane, train, bus, coach or ship because of their disability or reduced mobility – unless it is physically impossible or there are security concerns.

Disabled travellers or travellers with reduced mobility are generally62 entitled to assistance, free of charge:

 getting on and off the train / bus / coach / airplane / ship  on board during the journey  at the airport, bus terminal, port or station before and after the journey.

In order to receive the necessary assistance, they should contact the transport company and explain which kind of assistance they need:

1. at least 48 hours before the journey when travelling by plane, train or ship 2. at least 36 hours before the journey when travelling by bus or coach.

Transport companies are not obliged to provide help with eating, taking medication etc. If a passenger with a disability needs this type of help, the carrier might require that they be accompanied by another person. In some cases, this companion may travel for free or at a reduced price.63

Associated Legislation and Conventions In its Charter of Fundamental Rights, the EU has considered the accessibility of people with disabilities to be a fundamental right (Articles 21 and 26).

62 With some exceptions or other provisions in some cases, especially for local public transport. 63 Cf. https://europa.eu/youreurope/citizens/travel/transport-disability/reduced-mobility/index_en.htm

IFG-WP3-D-UIC-015-02 Page 43 of 153 12/12/2018

Contract No. H2020 – 730844

The EU has also ratified the United Nations Convention on the rights of persons with disabilities (UNCRPD).

The proposal for a European Accessibility Act aims to improve the functioning of the internal market for accessible products and services by removing barriers created by divergent legislation. It does not cover every product of service but focuses on computers, telephones, televisions, media services, transport, banking services, e-books and e-commerce.

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) N° 1107/2006 Air Europe Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders Regulation 1107/2006 covers the rights of disabled persons and persons with reduced mobility when travelling by air.

The Regulation applies to flights from and within the European Union (EU), as well as to flights from a third country to the EU, if operated by an EU carrier. It contains the following provisions:

Right to access to transport without any discrimination: Air carriers, ticket vendors and tour operators may not refuse to accept a reservation or embark persons with a disability or reduced mobility – unless this is strictly necessary to comply with safety requirements established by law (to meet these safety requirements, the carrier may request the person to be accompanied by someone to assist them), or if the aircraft is physically too small. In case of denied boarding, the person must immediately be informed of the reasons and has the right to reimbursement or re-routing (the right to re-routing or a return flight conditional upon safety requirements). Reasonable efforts must be made to offer an acceptable alternative.

Right to information: This includes the right to be informed on conditions of access for PRM and disabled persons. This information must be available in appropriate, accessible formats.

Right to special assistance: Disabled persons and PRM have the right to assistance, free of charge, getting on and off the plane, during the flight and in airports before and after the

IFG-WP3-D-UIC-015-02 Page 44 of 153 12/12/2018

Contract No. H2020 – 730844

flight.64 To get the best assistance, they should contact the airline, ticket seller or tour operator at least 48 hours before the trip65 and present themselves at an agreed time ahead of the departure time at a designated point.

Right to compensation for loss or damage to mobility equipment: If mobility equipment or assistive devices are lost or damaged while being handled at the airport or transported on board, the passenger shall be compensated according to international and national law.

Complaints: In case of problems while travelling, persons with disabilities or PRM should tell the airport or the air carrier concerned. If they are not satisfied with their reply, they can contact the NEB in the country where the incident happened.

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

In 2012, the European Commission published guidelines on the interpretation of the regulation. These addressed practical problems and uncertainties that remained for both air carriers and passengers with a disability or reduced mobility.

The Semantic terminology contained in the PRM Regulation must be included in the Ontology(ies) for future use by applications for booking, traveling, etc.

64 The annexes to Regulation 1107/2006 list the types of assistance to be provided by airports and air carriers. Airlines do not have to provide help with eating, drinking, taking medication or using the toilet during the flight. If such assistance is needed, they may request that the person with a disability / reduced mobility be accompanied. It is recommended (but not obligatory) that such a companion travels for free or at a significantly discounted rate. 65 Even if they have not done this, reasonable efforts should be made to provide assistance (SWD(2012) 171 final – Interpretative Guidelines on the application of Regulation 1107/2006). It is important to note that the Regulation does not impose an obligation to provide evidence of disability or reduced mobility.

IFG-WP3-D-UIC-015-02 Page 45 of 153 12/12/2018

Contract No. H2020 – 730844

Associated Legislation and Conventions The proposal for a revision of Regulation 261/2004 and 2027/97 adds the right to full compensation for loss of or damage to mobility equipment (by compelling air carriers to automatically offer the option to make a special declaration of interest – at no additional cost).

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EU) N° 1371/2007 Rail Europe (28 MS + Iceland, Norway, Switzerland) Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders Regulation 1371/2007 covers the rights of passengers – including the rights passengers with a disability or reduced mobility – when travelling by rail. National governments can decide to exempt domestic rail services (regional, urban, suburban trains) and international services that start or finish outside the EU. Certain provisions are mandatory for all kinds of railway services within the EU provided that the transport services are operated by railway undertakings.66

Chapter V contains the following provisions:

Right to access to transport without any discrimination: Railway undertakings, ticket vendors and tour operators may not refuse to accept a reservation or to provide a ticket to persons with a disability or reduced mobility, nor may they require such persons to be accompanied by another person – unless this is strictly necessary to comply with the company's access rules. In case of denied boarding, the person must immediately be informed of the reasons and has the right to reimbursement or re-routing. Reasonable efforts must be made to offer an acceptable alternative. Tickets and reservations shall be offered to disabled persons and PRM at no extra cost.

Right to information: This includes the right to be informed on conditions of access for PRM and disabled persons. This information must be available in appropriate, accessible formats.

66 MS may grant an exemption: to purely domestic railway traffic (for a period of five years, which may be renewed twice); to urban, suburban and regional services; to rail services of which a significant part is operated outside the EU (for a period of five years, which may be renewed). The following provisions apply to all railway traffic within the EU: right to transport of PRM (Art 19); information on accessibility of rail services (Art 20(1)).

IFG-WP3-D-UIC-015-02 Page 46 of 153 12/12/2018

Contract No. H2020 – 730844

Right to special assistance: Disabled persons and PRM have the right to assistance, free of charge, getting on and off and changing trains, on board and at the station before and after the journey. In unstaffed stations, accessible information should be displayed on the nearest staffed station and available assistance. To get the best assistance, the disabled person or PRM should contact the railway company, ticket seller or tour operator at least 48 hours before the trip (where the ticket permits multiple journeys, one notification shall be sufficient) and present themselves at an agreed time (not more than one hour) ahead of the departure time at a designated point. Even if they have not done this, railway undertaking and station manager should still make all reasonable efforts to help them.67

Right to compensation for loss of or damage to mobility equipment: Where a railway undertaking is liable for loss of, or damage to mobility equipment or other specific equipment used by a disabled person or PRM, no financial limit is applicable.

Complaints: In case of problems while travelling, persons with disabilities or PRM should tell the station authorities or the railway company concerned. If they are not satisfied with their reply, they can contact the NEB in the country where the incident happened.

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

The EC envisages to revise the rights of railway passengers. The Regulation proposal 2017/0237 intends to strengthen the rights for persons with disabilities or reduced mobility (mandatory right to assistance, full compensation for loss or repair of mobility equipment, provision of information in accessible formats, disability awareness training for rail staff).

The Semantic terminology contained in the PRM Regulation must be included in the Ontology(ies) for future use by applications for booking, traveling, etc.

Associated Legislation and Conventions Railway undertakings and station managers should take into account the needs of disabled persons and persons with reduced mobility, through compliance with the PRM TSI.

67 This is, contrary to other modes, not explicitly mentioned in the rail passenger rights Regulation, but is included in the Interpretative Guidelines (COM(2015) 4089 final).

IFG-WP3-D-UIC-015-02 Page 47 of 153 12/12/2018

Contract No. H2020 – 730844

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EU) N° 181/2011 Bus and Coach Europe (28 MS + Iceland, Norway, Switzerland) Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders Regulation 181/2011 covers the rights of passengers – including the rights of disabled passengers and passengers with reduced mobility – when travelling by bus and coach. For bus, most provisions apply to services operated on more than 250 km long lines. In addition, MS may exempt domestic regular services from these provisions, provided that the level of protection of disabled persons and PRM under national rules is at least the same as under the Regulation.

Chapter III contains the following provisions:

Right to access to transport without any discrimination: Carriers, travel agents and tour operators may not refuse to accept a reservation, provide a ticket or take on board persons on the grounds of their disability or reduced mobility – unless this is strictly necessary to comply with legal health and safety requirements, or where the infrastructure cannot guarantee safe transport. In such cases, coach and bus companies must allow PRM to be accompanied – free of charge – by a person of their choice to assist them. In case of denied boarding, the person must immediately be informed of the reasons and has the right to reimbursement or re-routing. Reasonable efforts must be made to offer an acceptable alternative. Tickets and reservations shall be offered to disabled persons and PRM at no extra cost.

Right to information: This includes the right to be informed on conditions of access for PRM and disabled persons. This information must be available in appropriate, accessible formats.

Right to special assistance:68 MS are required to designate bus and coach terminals where passengers with disabilities or reduced mobility may receive appropriate assistance. Disabled persons and PRM have the right to assistance, free of charge, at such designated terminals and on board buses and coaches. They have to notify the ticket seller at the time of reservation of any special needs in terms of seating. For any other assistance they should notify the carrier or terminal operator at least 36 hours in advance and present themselves at an agreed time (not more than one hour) ahead of the departure time at a designated

68 These rights only apply to long-distance journeys (more than 250km).

IFG-WP3-D-UIC-015-02 Page 48 of 153 12/12/2018

Contract No. H2020 – 730844

point. Even if they have not done this, the carrier and terminal operator still have to make all reasonable efforts to help them to board, alight and travel.

Right to compensation for loss of or damage to mobility equipment: Where a carrier or terminal operator has caused loss of or damage to mobility equipment, they have to pay a compensation corresponding to the replacement value or the costs relating to its repair. They must also make every effort to rapidly provide (temporary) replacement equipment.

Complaints: In case of problems while travelling, persons with disabilities or PRM should tell the terminal authorities or the bus company concerned. If they are not satisfied with their reply, they can contact the NEB in the country where the incident happened.

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

The Semantic terminology contained in the PRM Regulation must be included in the Ontology(ies) for future use by applications for booking, traveling, etc.

Associated Legislation and Conventions Regulation (EC) N° 661/2009 stipulates the accessibility requirements that all new buses and coaches shall fulfil in order to authorize their sale, registration or putting into service within the EU.

IFG-WP3-D-UIC-015-02 Page 49 of 153 12/12/2018

Contract No. H2020 – 730844

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) N° 1177/2010 Water Europe (28 MS + Iceland, Norway, Switzerland) Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas and Data Sets Products and Rules Mappings Services

Scope and Stakeholders Regulation 1177/2010 covers the rights of passengers – including the rights of disabled passengers and passengers with reduced mobility – when travelling by sea and inland waterway.

Chapter II contains the following provisions:

Right to access to transport without any discrimination: Carriers, travel agents and tour operators may not refuse to accept a reservation, to provide a ticket or to embark persons on the grounds of their disability or reduced mobility. Tickets and reservations shall be offered at no extra cost under the same conditions as to other passengers. Carriers can ask persons with a disability or PRM to be accompanied by another person if necessary for safety reasons, or because of the way the ship or the port infrastructure are designed. This companion will travel for free. In case of denied boarding, the person must immediately be informed of the reasons and has the right to reimbursement or re-routing. Reasonable efforts must be made to offer an acceptable alternative.

Right to information: This includes the right to be informed on conditions of access for PRM and disabled persons. This information must be available in appropriate, accessible formats.

Right to special assistance: Disabled persons and PRM have the right to assistance, free of charge, getting on or off a ship, changing ships, on board and at the port. They have to notify the ticket seller at the time of reservation of any special needs in terms of accommodation, seating, assistance, or if they need to bring or medical equipment. For any other assistance they should notify the carrier or terminal operator at least 48 hours in advance and present themselves at an agreed time ahead of the embarkation time at a designated point. Even if they have not done this, the carrier and terminal operator still have to make all reasonable efforts to help them to board, disembark and travel.

Right to compensation for loss of or damage to mobility equipment: Where a carrier or terminal operator has caused loss of or damage to mobility equipment, they have to pay a

IFG-WP3-D-UIC-015-02 Page 50 of 153 12/12/2018

Contract No. H2020 – 730844

compensation corresponding to the replacement value or the costs relating to its repair. They must also make every effort to rapidly provide (temporary) replacement equipment if needed.

Complaints: In case of problems while travelling, persons with disabilities or PRM should tell the port authorities or the carrier concerned. If they are not satisfied with their reply, they can contact the NEB in the country where the incident happened.

Governance Rules and Change Management Processes Follows the normal EU Regulatory change management Process and has limited impact on the IF Assets.

The Semantic terminology contained in the PRM Regulation must be included in the Ontology(ies) for future use by applications for booking, traveling, etc.

Associated Legislation and Conventions The following EU legislation also regulates several aspects of the accessibility of persons with disability or reduced mobility to ships: Directive 2009/45/EC on safety rules and standards for passenger ships, Directive 1999/35/EC on a system of mandatory surveys for the safe operation of regular ro-ro ferry and high-speed passenger craft services and Directive 98/41/EC on the registration of persons sailing on board passenger ships operating to or from ports of the Member States of the Community.

TECHNICAL SPECIFICATIONS FOR INTEROPERABILITY (TSI)

The Technical Specifications for Interoperability (TSIs) are specifications that are maintained by the ERA. They consist of the rules, procedures and data definitions to ensure the interoperability of the European high-speed and conventional Rail system.

Of interest to GoF4R are the two TSIs for Telematics Applications:

 TAP-TSI: applications for passenger services, including systems providing passengers with information before and during the journey, reservation and payment systems, luggage management and management of connections between trains and with other modes of transport;

 TAF-TSI: applications for freight services, including information systems (real-time monitoring of freight and trains), marshalling and allocation systems, reservation, payment

IFG-WP3-D-UIC-015-02 Page 51 of 153 12/12/2018

Contract No. H2020 – 730844

and invoicing systems, management of connections with other modes of transport and production of electronic accompanying documents.69

Although GoF4R (and IP4 in general) is limited to Passenger-related technology development, the TAF-TSI plays a key role in defining the operational processes and data exchange that must be implemented by the mainline rail stakeholders to comply with the Regulations (urban rail is excluded from the scope of the TSIs). These data, when combined with that of the TAP-TSI comprise a core base of the semantic definitions comprising the IF Asset “Ontology.” This is also the case with the PRM TSI, contained in this chapter.

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) No 1305/2014 Rail Europe

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Scope and Stakeholders This TSI concerns the Telematic Applications subsystem for freight services and falls under 1(b) of Annex II to Directive 2001/16/EC - interoperability of the trans-European conventional rail system.

It states that the commercial operation of trains, wagons and Intermodal units throughout the Trans- European rail network requires efficient interchange of information between the different Infrastructure Managers, Railway Undertakings and other service providers. Performance levels, safety, quality of service and cost depend upon such compatibility and interchange as does, in particular, the interoperability of the Trans-European conventional rail system.

The technical specification for interoperability also has an impact on the conditions of use of rail transport by users. In this respect the term users is understood to mean not only infrastructure managers or railway undertakings but also all other service providers such as wagon companies, Intermodal operators, customers and application developers.

It ensures the efficient exchange of information between IMs and RUs by defining the process rules, messaging formats and data definitions to achieve technical compatibility between legacy applications systems of the stakeholders. The functional areas of the TAF-TSI which must be contained in the IF are as follows:

69 European Commission, Transport and Mobility, https://ec.europa.eu/transport/modes/rail/interoperability/interoperability/telematic_applications_en

IFG-WP3-D-UIC-015-02 Page 52 of 153 12/12/2018

Contract No. H2020 – 730844

 Reference Files (Codified, unique Reference points for Stations and for Company identification)  Train Running Information and Train Delay Cause (for use in applications that feed Passenger Information Systems)  Train Forecast (for use in applications that feed Passenger Information Systems)  Service Disruption (for use in applications that feed Passenger Information Systems)  Train Transport Identifier (for use in applications that feed Passenger Information Systems)

Governance Rules and Change Management Processes The Regulation itself is undergoes the normal Regulatory change management system. However, the Technical Documents, administered by the ERA, undergo periodic review and publication. The pertinent technical document for the TAF-TSI is ERA-TD-105: TAF TSI - Annex D.2: Appendix F - TAF TSI Data and Message Model, Version 2.070. The annexes to this document are in the form of an XSD (W3C Schema) that contains the baseline data definitions and corresponding datatypes and references required for data exchange under the TAF-TSI regime.

During the current deployment phase of the TAF-TSI, modifications must be made to the technical document in order to adapt to changing technology and business need. The Change Management is handled by the ERA under the auspices of the joint TAP-TAF Change Control Management (CCM) Working Party which meets semi-annually. This Working Party is comprised of members from the Representative Organisations, the ERA, Member State Representatives and invited experts, such as the UIC.

The XSD comprising the Technical Document is issued for publication periodically depending on need and is approved through the Railway Interoperability and Safety Committee (RISC). The current version is Baseline 2.1.

Impacts and Considerations for the Governance of the IF Assets The Regulation, particularly the Technical Document(s), has a direct impact on the content and composition of the IF Assets by:

 Defining the content of the baseline IF Ontology  Possibly defining Web Services for publication as an IF Asset  Publishing the baseline version 2.1 XSD as an IF Asset  Possibly publishing mapping between the TAF-TSI version 2.1 XSD and legacy application formats as IF Assets  Possibly publishing enhanced datasets as IF Assets

GoF4R must consider the CCM process when developing its own rules for Change Management and validation. It must consider how to best synchronise its own published content with that of the current Technical Documents that are in force.

70 http://www.era.europa.eu/Document- Register/Documents/ERA_Technical_Document_TAF_D_2_Appendix_F_v2_0.pdf

IFG-WP3-D-UIC-015-02 Page 53 of 153 12/12/2018

Contract No. H2020 – 730844

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) No 527/2016 Rail Europe

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Scope and Stakeholders This TSI concerns the Telematic Applications subsystem for Passenger services and falls under Directive 2008/57/EC of the European Parliament and of the Council of 17 June 2008 on the interoperability of the rail system within the Community.

Whereas the TAF-TSI mostly concerns data exchange for operational purposes, the TAP-TSI aims to include more information and processes that will enhance the passenger experience. As stated in the Regulation, the exchange of computerised and harmonised data will make it possible to increase transparency and will make it easier to plan, reserve and make journeys by train in Europe. It will also strengthen passengers’ protection and enhance informed consumer choice by making it possible for rail companies and ticket vendors to fulfil their obligations under Regulation (EC) No 1371/2007 on rail passengers’ rights and obligations71.

As seen in the figure below, the TAP links directly other pertinent Regulations by fulfilling some of the necessary requirements.

71 http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32007R1371&from=EN

IFG-WP3-D-UIC-015-02 Page 54 of 153 12/12/2018

Contract No. H2020 – 730844

Passengers’ Rights Regulation Interoperability Directive1 Extracts (EC) No 1371/2007 2008/57/EC

Establish a Computerised Information & . Implement applications for passenger Reservation System for Rail Transport, services, for instance: providing customers, amongst others, with: - Systems providing passengers with . Pre-journey customer information, e.g. information before and during journey - Time schedules and conditions for the - Reservation and payment systems fastest trip and lowest fare . Develop databases, software, data

- Accessibility, availability protocols in a manner allowing maximum . Information during the journey data exchange between different - On-board services applications and operators - Next station, delays, connecting services

Figure 3 - Relationship to other Regulations

The purpose of this TSI is to define procedures and interfaces between all types of actors to provide information and issue tickets to passengers via widely available technologies. It should include the exchange of information for the following aspects: systems providing passengers with information before and during the journey, reservation and payment systems, luggage management, issuing of tickets via ticket offices, ticket selling machines, on board trains, telephone, Internet or any other widely available information technology, management of connections between trains and with other modes of transport.72

It ensures the efficient exchange of information between stakeholders by defining the process rules, messaging formats and data definitions to achieve technical compatibility between legacy applications systems of the stakeholders. In addition to the functional areas of the TAF-TSI mentioned in the preceding chapter, the functional areas of the TAP-TSI which must be considered for the IF are as follows:

 Retail Reference Files (Codified, unique Reference points for Stations, Bus Stops and for Company identification)  Exchange of Timetable data  Exchange of Tariff data  Handling of information on contact details of the railway undertaking  Handling of information concerning conditions of carriage  Handling of information concerning carriage of registered luggage  Handling of information concerning carriage and assistance of persons with reduced mobility (PRM)  Handling of information concerning the carriage of bicycles  Handling of information concerning the carriage of cars

72 Official Journal of European Union, (5) L123/11, 12.5.2011, http://eur-lex.europa.eu/legal- content/EN/TXT/PDF/?uri=CELEX:32011R0454&from=EN

IFG-WP3-D-UIC-015-02 Page 55 of 153 12/12/2018

Contract No. H2020 – 730844

 Handling of availability/reservation  Handling of security elements for product distribution  Delivery of the product to the customer after its purchase (fulfilment)  Handling of information provision in the station area  Handling of information provision in the vehicle area

Governance Rules and Change Management Processes The Regulation itself undergoes the normal Regulatory change management system. However, the Technical Documents, administered by the ERA, undergo periodic review and publication. The pertinent technical documents for the TAP-TSI Baseline Version 1.3.0 are:

1. Directory of passenger code lists for the ERA technical documents used in TAP TSI (1.3.4.pdf) and (1.3.4.xsd); 2. ERA Technical Document TAP B.1 (v 1.2.0) Computer generation and exchange of tariff data meant for international or foreign sales – open time tickets; 3. ERA Technical Document TAP B.2 (v 1.2.0) Computer generation and exchange of tariff data meant for international and foreign sales – integrated reservation tickets (IRT); 4. ERA Technical Document TAP B.3 (v 1.2.0) Computer generation and exchange of data meant for international or foreign sales – special offers; 5. ERA Technical Document TAP B.4 (v 1.3.0) Implementation guide for EDIFACT messages covering timetable data exchange; 6. ERA Technical Document TAP B.5 (v 1.3.0) Electronic reservation of seats/berths and electronic production of travel documents - exchange of messages; 7. ERA Technical Document TAP B.6 (v 1.2.0) Electronic seat/berth reservation and electronic production of transport documents - transport documents (RCT2 standard); 8. ERA Technical Document TAP B.7 (v 1.2.0.pdf) and (v 1.3.0.xsd) - International rail ticket for home printing; 9. ERA Technical Document TAP B.8 (v 1.2.0) Standard numerical coding for Railway Undertakings, Infrastructure Managers and other companies involved in rail-transport chains; 10. ERA Technical Document TAP B.9 (v 1.2.0) Standard numerical coding of locations; 11. ERA Technical Document TAP B.10 (v 1.3.0.pdf) and (v 1.3.0.xsd) - Electronic reservation of assistance for persons with reduced mobility - exchange of messages; 12. ERA Technical Document TAP B.30 (v 1.2.0); Schema - messages/datasets catalogue needed for the RU/IM communication of TAP TSI.

In addition to the Technical Documents listed above, TAP shares a common dictionary with the TAF, that is in the form of an XSD (W3C Schema), containing the baseline data definitions and corresponding datatypes and references required for data exchange under the TAF-TSI regime. The current baseline in 1.2.

During the current deployment phase of the TAP-TSI, modifications must be made to the technical document in order to adapt to changing technology and business need. The Change Management is handled by the ERA under the auspices of the joint TAP-TAF Change Control Management (CCM) Working Party which meets semi-annually. This Working Party is comprised of members from the

IFG-WP3-D-UIC-015-02 Page 56 of 153 12/12/2018

Contract No. H2020 – 730844

Representative Organisations, the ERA, Member State Representatives and invited experts, such as the UIC.

The Technical Documents are issued for publication periodically depending on need and are approved through the Railway Interoperability and Safety Committee (RISC).

Impacts and Considerations for the Governance of the IF Assets The Regulation, particularly the Technical Document(s), has a direct impact on the content and composition of the IF Assets by:

 Defining the content of the baseline IF Ontology  Possibly defining Web Services for publication as an IF Asset  Publishing the baseline version 2.1 XSD as an IF Asset  Publishing the baseline 1.3 Technical documents as IF Assets  Possibly publishing mapping between the TAF-TSI version 2.1 XSD and legacy application formats as IF Assets  Possibly publishing enhanced datasets as IF Assets

Regulation/Standard/Convention Mode Geographic Applicability

REGULATION (EU) No 1300/2014 Rail Europe

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Scope and Stakeholders As described by the ERA, “this TSI covers the aspect of “Accessibility for Persons with Reduced Mobility” for the Infrastructure, the Rolling Stock and, to a minor extent, the Telematics Applications

IFG-WP3-D-UIC-015-02 Page 57 of 153 12/12/2018

Contract No. H2020 – 730844

for Passenger subsystems as defined in Directive 2008/57/EC73. The objective of this TSI is to enhance the accessibility of rail transport to persons with reduced mobility including persons with disabilities. This includes the accessibility of the public areas of stations and of Rolling Stock. This also includes the functional and operational rules related to the provision of assistance to passengers.”74

Although this TSI broadly addresses specifications for infrastructure and rolling stock, it specifically provides for the provision of supplying information and assistance to Persons with Reduced Mobility, considering the public use of that infrastructure and rolling stock. Thus, there is a direct linkage to the TAP TSI for the provision of such information. The table below addresses the corresponding parameters of each TSI that must be considered.

PRM TSI Parameter TAP TSI Parameter Station accessibility Assistance to Handling of information concerning board and alight the train carriage and assistance of persons with disabilities and persons with reduced mobility Access and reservation Handling of availability/reservation Customer information Handling of information provision in the vehicle area

Figure 4 Corresponding TSI Parameters

In addition to the relationship with the TAP TSI, the PRM also cites specific requirements for providing PRM-related data in the following Infrastructure and Rolling Stock Registers:

 Infrastructure register: The characteristics of the infrastructure that must be recorded in the “register of railway infrastructure” are listed in the Commission implementing decision 2011/633/EU6.75

 Rolling Stock register: The characteristics of the rolling stock that must be recorded in the “European register of authorised types of vehicles” are listed in the Commission implementing decision 2011/665/EU7.76

These Registers are maintained by ERA and contain pertinent data that is described in defined formats, with defined coding. The PRM data described in these Registers can be referenced (or

73 Directive 2008/57/EC of the European Parliament and of the Council of 17 June 2008 on the interoperability of the rail system within the Community (OJ L 191, 18.7.2008, p. 1) 74 http://www.era.europa.eu/document-register/documents/draft_prm_tsi_version_2.0.pdf 75 Commission Implementing Decision 2011/633/EU of 15 September 2011 on the common specifications of the register of railway infrastructure (OJ L 256, 1.10.2011, p. 1–25) 76 Commission Implementing Decision 2011/665/EU of 4 October 2011 on the European register of authorized types of railway vehicles (OJ L 264, 8.10.2011, p. 32–54).

IFG-WP3-D-UIC-015-02 Page 58 of 153 12/12/2018

Contract No. H2020 – 730844

published) by the IF Assets for use by the Stakeholders. Most importantly, the semantic objects contained in the PRM shall be included in the reference Ontology, at a minimum.

Another important Parameter of the PRM TSI that is closely related to the IF is contained in Article 7 of the Regulation, regarding the Inventory of Assets specifically related to PRM which states:

1) Each Member State shall ensure that an inventory of assets is established and implemented with a view to:

a) Identifying barriers to accessibility; b) Providing information to users; c) Monitoring and evaluating progress on accessibility.

2) The Agency shall set up and run a working party in charge of making a proposal for a recommendation as regards the minimum structure and content of data to be collected for the inventories of assets. The Agency shall submit a recommendation to the Commission, including on content, data format, functional and technical architecture, operating mode, rules for data input and consultation, and rules for self-assessment and designation of the entities responsible for data provision. In order to identify the most viable solution, the recommendation shall take into account the estimated costs and benefits of all the technical solutions considered. It shall include a proposal for the timing of the establishment of the inventories of assets.

3) On the basis of the recommendation referred to in paragraph 2, chapter 7 of the Annex shall be updated in accordance with Article 6 of Directive 2008/57/EC… 77

Impacts and Considerations for the Governance of the IF Assets The Regulation, particularly the Technical Document(s) as maintained by ERA, has a direct impact on the content and composition of the IF Assets by:

 Defining the content of the baseline IF Ontology  Possibly publishing the datasets for the Inventories of Assets and Registers  Possibly publishing enhanced datasets as IF Assets

77 http://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32014R1300&from=EN

IFG-WP3-D-UIC-015-02 Page 59 of 153 12/12/2018

Contract No. H2020 – 730844

REGULATORY FRAMEWORK ON PERSONAL DATA PROTECTION

Although it is not envisioned at this juncture to publish any personal data within the IF Assets themselves, further development of applications based on those Assets (including further development within IP4) necessarily have to store and process some amounts of personal data. This section provides an overview of the applicable legislation concerning the processing rules for personal information and lay the groundwork for recommendations to be made for developers and other users of the IF. .

The European Union, since its inception, has taken a very strict stance on the protection of personal data. As seen in Article 16 (ex Article 286 TEC) of the Treaty on the Functioning of the European Union (TFEU), the following principles are outlined:

1. “Everyone has the right to the protection of personal data concerning them”;

2. “The European Parliament and the Council, acting in accordance with the ordinary legislative procedure, shall lay down the rules relating to the protection of individuals with regard to the processing of personal data by Union institutions, bodies, offices and agencies, and by the Member States when carrying out activities which fall within the scope of Union law, and the rules relating to the free movement of such data. Compliance with these rules shall be subject to the control of independent authorities.”78

Several Directives have been issued since the TFEU concerning data privacy. These Directives provide the legal framework for the act, without imposing any solution for their enactment. It is therefore up to the individual Member States to enact national legislation to comply with the Directive. This is quite different from Regulations, which become law with no need for the Member States to enact implementation measures.

Subsequently, the relevant EU framework was established comprising the following legislation, with Directive 95/46/EC as the overriding Directive in this regard:

Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data79;

Regulation (EC) No 45/2001 of the European Parliament and of the Council of 18 December 2000 on the protection of individuals with regard to the processing of personal data by the Community institutions and bodies and on the free movement of such data80;

Directive 2002/22/EC of the European Parliament and of the Council of 7 March 2002 on universal service and users' rights relating to electronic communications networks and services (Universal Service Directive)81;

78 http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:12012E/TXT 79 http://ec.europa.eu/justice/policies/privacy/docs/95-46-ce/dir1995-46_part1_en.pdf 80 https://edps.europa.eu/data-protection/our-work/publications/legislation/regulation-ec-no-452001_en 81 http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2009.337.01.0011.01.ENG

IFG-WP3-D-UIC-015-02 Page 60 of 153 12/12/2018

Contract No. H2020 – 730844

Directive 97/66/EC of the European Parliament and of the Council of 15 December 1997 concerning the processing of personal data and the protection of privacy in the telecommunications sector has been repealed in 2002 by Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002 concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications;82

Directive 2009/136/EC of the European Parliament and of the Council of 25 November 2009 amending Directive 2002/22/EC, Directive 2002/58/EC and Regulation (EC) No 2006/200430.83

Regulation/Standard/Convention Mode Geographic Applicability

Regulation (EC) 2016/679 General European Citizens with Global reach

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Scope and Stakeholders Due to the quickly changing ICT environment and evolution of the internet, the new GDPR was enacted in order to create a strong and coherent data protection framework. Its goal is to harmonise data protection laws across Member States and ensure a common Regulatory framework. The GDPR will come into force on 28th May 2018 and will completely replace Directive 95/46/EC. As a Regulation, it becomes directly binding for the Member States as written.

In the preamble (10) of the Regulation, the GDPR states:

“In order to ensure a consistent and high level of protection of natural persons and to remove the obstacles to flows of personal data within the Union, the level of protection of the rights and freedoms of natural persons with regard to the processing of such data should be equivalent in all Member States. Consistent and homogenous application of the rules for the protection of the fundamental rights and freedoms of natural persons with regard to the processing of personal data should be ensured throughout the Union. Regarding the processing of personal data for compliance with a legal obligation, for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller, Member States should be allowed to maintain or introduce national provisions to further specify the application of the rules of this Regulation. In conjunction with the general and horizontal law on data protection implementing Directive 95/46/EC, Member

82 http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A31997L0066 83 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:337:0011:0036:en:PDF

IFG-WP3-D-UIC-015-02 Page 61 of 153 12/12/2018

Contract No. H2020 – 730844

States have several sector-specific laws in areas that need more specific provisions. This Regulation also provides a margin of manoeuvre for Member States to specify its rules, including for the processing of special categories of personal data (‘sensitive data’). To that extent, this Regulation does not exclude Member State law that sets out the circumstances for specific processing situations, including determining more precisely the conditions under which the processing of personal data is lawful.84

The Regulation applies to organisations located within the EU but it will also apply to organisations located outside of the EU if they offer goods or services to, or monitor the behaviour of, EU data subjects. It applies to all companies processing and holding the personal data of data subjects residing in the European Union, regardless of the company’s location.85

Article 6 of the Regulation sets out the conditions for Lawfulness of processing:

Processing shall be lawful only if and to the extent that at least one of the following applies:

 the data subject has given consent to the processing of his or her personal data for one or more specific purposes;  processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;  processing is necessary for compliance with a legal obligation to which the controller is subject;  processing is necessary in order to protect the vital interests of the data subject or of another natural person;  processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;  processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.86

Furthermore, the GDPR leads to a new concept in European data protection law: “pseudo anonymisation” – i.e. making data neither anonymous nor identifying in directly manner. The GDPR defines ”Pseudo anonymization” as “the processing of personal data in such a way that the data can no longer be attributed to a specific data subject without the use of additional information set, the “additional information” must be “kept separately and subject to technical and organisational measures to ensure non-attribution to an identified or identifiable person.” Practically, it is a privacy- enhancing technique where directly identifying data is held separately and securely from processed data to ensure non-attribution.

This aspect is relevant also taking into consideration the data shared in the European interoperability framework. Pseudo anonymisation implies, in detail, the separation of data from direct identifiers so that the connection to an identity is not possible without additional information that is considered

84 http://ec.europa.eu/justice/data-protection/reform/files/regulation_oj_en.pdf 85 EUGDPR.org, https://www.eugdpr.org/gdpr-faqs.html 86 http://ec.europa.eu/justice/data-protection/reform/files/regulation_oj_en.pdf , I 119/35

IFG-WP3-D-UIC-015-02 Page 62 of 153 12/12/2018

Contract No. H2020 – 730844

separately. Pseudo anonymisation , particularly in the transport data management of the European Interoperability Framework, may significantly decrease the risks associated with data elaboration, while maintaining the data’s utility. GDPR creates incentives for controllers to realize collection of pseudonymize data. Although pseudonymous data are not exempt from the Regulation altogether, the GDPR loosens several requirements on controllers that use this specific technique.

Pseudo anonymisation is not on its own a sufficient technique to exempt data from the scope of the Regulation. GDPR also states that data which have undergone pseudo anonymisation, which could be attributed to a natural person using additional information, should be considered to be information on an identifiable natural person” (i.e., personal data). Thus, pseudo anonymisation is not intended to preclude any other measures of data protection. The Regulation recognises the ability of pseudo anonymisation to help protect the rights of individuals while also enabling data utility. Thus GDPR allows controllers who pseudonymise personal data to obtain a relevant margin to process the data for a different purpose than the one for which they were gathered. Much research has been carried out about the extent to which pseudonymised data can be reidentified. This issue is of critical importance because it determines whether a processing operation will be subject to the provisions of the Regulation. The key distinction between pseudonymous data, which is regulated by the GDPR, and anonymous data, which is not, is whether the data can be reidentified with a sensible effort.

The GDPR introduces pseudo anonymisation into European data protection law, as a means of protecting the rights of individuals while also allowing controllers to benefit from data utility. Although pseudonymised data still falls within the scope of the Regulation, some provisions are entwined in order to stimulate controllers’ usage of this technique. Thus, controllers that pseudonymise their data sets will find it easier to be allowed to exploit personal data for different purposes and for scientific and historical research, as well as meeting the Regulation’s data security and data by requirements of design.

Impacts and Considerations for the Governance of the IF Assets If the IF contains any datasets that include personal information, then the Asset Manager must be in compliance with the terms of the Regulation or else be subject to significant penalties. However, it is the users of the IF Assets that will be heavily impacted. The following provisions introduced in this legislation will have a direct impact on the developers of products and services such as the Travel Companion that is envisioned in IP4. The most notable provisions that need to be taken into account are:

1. The Right of Access (Article 15) which gives the EU citizen the right to get access to their personal data and information about how these personal data are being processed.

2. Right to erasure (Article 17) gives the citizen the right to choose ‘to be forgotten,’ and have their personal data erased, without undue delay, as long as they have they met the legitimate criteria as stipulated in the Article.

3. Data portability (Article 20) gives the citizen the right to freely transfer their data from one processing system to another.

IFG-WP3-D-UIC-015-02 Page 63 of 153 12/12/2018

Contract No. H2020 – 730844

Regulation/Standard/Convention Mode Geographic Applicability

The (new) ePrivacy Regulation will repeal General European Citizens with Global reach the (current) ePrivacy Directive (Directive 2002/58/EC).

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Scope and Stakeholders

One of the most important types of e-records, that should be involved in e-Privacy management issue, is the Passenger Name Record (PNR) which is the travel record for passengers, used mostly by airline and travel agency databases. PNR information can take into consideration Passenger’s full name, Date of birth, home and work address, telephone number, e-mail address, passport details, credit card details or method of payment, the names and personal information of emergency contacts, as well as details on any special meal requirements or seating preferences or any other similar requests. Databases of PNR data are usually managed through a centrally hosted system, within a specific international reservation system. The sharing of passenger data amongst multiple data controllers and processors may lead to relevant privacy risks, on the basis that not all of these actors may apply or guarantee the same adequate privacy preservation policies. Moreover, by collecting and correlating information like “special meal requirements” or “seating particularities” or even by “efficient” use of the same individual’s name (profiling), inferences may be made about such sensitive issues as religion or health conditions of the passengers.

The risk to privacy related to PNR processing has recently been deliberated by the EU Court of Justice (CJEU). CJEU’s Opinion 1/15 was issued on 26 July 2017 and was in relation to the lawfulness of EU’s PNR Agreement with Canada. Specifically, CJEU adjudicated that the processing of PNR data generally pursues a different objective from that which was intended as collected by air carriers, and thus requires a different legal basis.” It also requested stricter adherence to the data protection right: PNR processing, as performed today, is an intrusive type of personal data processing elaboration due to the fact that PNR data may reveal considerable detail about an individual, such as their travel habits, relationships, and financial situation, which may also include sensitive information.

The importance of passenger data (today, PNR) processing in the fight against terrorism is unquestionable particularly considering the sensitiveness of the airports, railway stations as focal point of passenger transit of the European intermodal framework. Apparently, however, PNR

IFG-WP3-D-UIC-015-02 Page 64 of 153 12/12/2018

Contract No. H2020 – 730844

processing is considered by the CJEU to be so risky for the protection of fundamental rights that careful scrutiny needs to be made to relevant regulatory text. In summary, while e-records, such as the PNR, are important data for the smooth operation of the service providers, they do not provide sufficient privacy to the end users. Different transport service operators may only require access to defined subsets of the e-record in order to offer their services aiming at improving the transport service customization. In addition, sensitive personal information contained in the e-record may be relevant for third parties for undesired purposes, such as identity theft, unsolicited marketing (spam) etc. A cancelled or completed trip does not erase the record since copies of the PNRs may be retained indefinitely by airlines, and travel agencies or for post trip requirements or to meet local legal requirements. It is important to safeguard and protect such on-line info and therefore, more research needs to be done in terms of preserving and protecting the privacy of the sensitive personal data contained in existing e-records, whilst preserving the efficiency of online operations and services.

Impacts and Considerations for the Governance of the IF Assets

If the IF contains any datasets that include personal information, then the Asset Manager must be in compliance with the terms of the Regulation or else be subject to significant penalties. However, it is the users of the IF Assets that will be heavily impacted. The following provisions introduced in this legislation will have a direct impact on the developers of products and services such as the Travel Companion that is envisioned in IP4.

Regulation/Standard/Convention Mode Geographic Applicability

Directive 2016/1148 General European Citizens with Global reach

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Scope and Stakeholders

The Directive on Security of Network and Information Systems defines the inputs for the spread of a relevant common environment of network and information systems security in the European Union.

This challenging goal considers the following relevant aspects:

 Enhancing cyber security proficiency in each nation of the EU.

IFG-WP3-D-UIC-015-02 Page 65 of 153 12/12/2018

Contract No. H2020 – 730844

 Enhancing cooperation activity that has a specific relation with the cyber security amongst EU member states.  Developing and pushing the establishment of specific security measures and incident reporting constrains for Operators of Essential Services (OESs) in Critical National Infrastructure (CNI) and Digital Service Providers (DSPs).

In particular, the NIS Directive has been adopted by the European Parliament on 6 July 2016, and entered into force in August 2016. EU Member States must transfer it into national laws no later than May 2018, and in the following six months, each nation must identify the OESs to which it applies. Practically, Member States must define their own rules regarding financial penalties and must take the measures needed to guarantee its implementation. It is necessary to underline how it applies only to providers of essential services to customers based in the European Union.

Transport has been considered for the NIS as one of the most relevant sectors because of their significant technical focus on Information and Communication Technology (ICT). Therefore, for the Interoperability Framework Governance it is necessary to take into consideration the implementation of NIS on the Critical National Infrastructure of transport (in particular ICT infrastructure) as it will impact cyber security protection conditions for the European intermodal framework and related governance requirements.

Further consideration must be given to how the implementation of the Directive impacts sensitive points of intermodal transport (railway stations, airports, ports, parking area, metro stations). The Directive will provide incentives for the investment in cyber security solutions on the critical transport infrastructure in order to implement prevention and detection of malicious intrusion and identify unusual patterns of data traffic in order to avoid unauthorized take-over of the control of the transport systems.

The main subjects of interest in the Directive that enter in force are the OESs, namely public or private entities that match all of the following base conditions:

 Operators offering a service that is relevant for the society and the economy.  Services provided specifically depend on NIS.  Incidents to the network and information systems of that service could have significant effects on its relevant provision.

Each Member State must acknowledge the OESs no later than November 2018.

Considering the Directive transport applications, organisations that provide both essential and non- essential services – such as airports – security requirements will only be valid pertaining to the essential services. The NIS Directive provides a strict definition of interested transport providers for which security requirements would be implemented (NSI Annex 2):

 Air carriers (freight and passenger air transport)  Maritime carriers (sea and coastal passenger water transport companies and sea and coastal freight water transport companies)  Railways (infrastructure managers, integrated companies and railway transport operators)  Airports  Ports

IFG-WP3-D-UIC-015-02 Page 66 of 153 12/12/2018

Contract No. H2020 – 730844

 Traffic management control operators  Auxiliary logistics services (warehousing and storage, cargo handling and other transportation support activities)

Finally, it is necessary to note that the NIS incident reporting requirements in the Directive not only pertain to “cyber security” but also include any incident concerning the network and related information system security that is considered to guarantee essential services which may be part of the reporting activity.

Specifically, power failures, hardware failures, malware, intrusions and viruses must be considered.

Regulation/Standard/Convention Mode Geographic Applicability

Directive 200/31/EC General European Citizens

Directive 2001/29/EC

Directive 2009/24/EC

Regulation 207/2009 (EC)

Directive 89/104 and Regulation 40/94

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Scope and Stakeholders Intellectual property rights (IPR) protect intangible assets, allowing creators and inventors to profit from their creative and innovative activities. Intangible assets account for more than half the value of companies, and their importance is growing.

In a world where EU companies are increasingly competing on innovation, creativity and quality, intellectual property is a powerful tool for growing the competitiveness of all companies.

The achievement of the internal market entails eliminating restrictions on freedom of movement and distortions of competition, while creating an environment conducive to innovation and investment. In this context, the protection of intellectual property is an essential element for the success of the internal market. The protection of intellectual property is important not only for promoting innovation and creativity, but also for developing employment and improving competitiveness.

IFG-WP3-D-UIC-015-02 Page 67 of 153 12/12/2018

Contract No. H2020 – 730844

However, without effective means of enforcing intellectual property rights, innovation and creativity are discouraged and investment diminished. It is therefore necessary to ensure that the substantive law on intellectual property, which is nowadays largely part of the acquis communautaire, is applied effectively in the Community. In this respect, the means of enforcing intellectual property rights are of paramount importance for the success of the internal market.

EU Action Plan In July 2014, the Commission adopted the Communication 'Towards a renewed consensus on the enforcement of Intellectual Property Rights: An EU Action Plan’ according to which the Commission seeks to re-orientate its policy for intellectual property enforcement towards better compliance with intellectual property rights by all economic actors.

According to the Parliament, the key objective should be to ensure the effective, evidence-based enforcement of IPR, which plays a key role in stimulating innovation, creativity, competitiveness, growth and cultural diversity.

Ensuring fair remuneration for creators should as well be a crucial element of the EU Action Plan. To that end, the Parliament, inter alia, stated that all actors in the supply chain have a role to play in the fight against IPR infringement and should be involved in this process.

Furthermore the Parliament stressed the importance of ensuring the application of due diligence throughout the supply chain, the need for operators in the industry to exchange information about platforms which provide access to content that infringes IPR, the importance of sector-based agreements and good practice guides to combat IPR infringements, the involvement of organised crime in international IPR-infringing activities.

Moreover, Parliament’s resolution emphasised the importance of improving civil enforcement procedures for SMEs and individual creators as regards IPRs and called on the Commission to adapt the EU legislative framework regarding IPR infringement to the internet environment

On 29 November 2017, the Commission adopted a comprehensive package to address the issues identified in the Action plan comprising:

A Communication, 'A balanced IP enforcement system responding to today's societal challenges';

A Communication providing guidance and clarifying certain provisions of the IPR enforcement Directive to ensure a more homogenous interpretation in Europe;

An evaluation report and study on the Directive on the enforcement of IPR;

A Communication, 'Setting out the EU approach to Standard Essential Patents';

An Overview report on the functioning of the Memorandum of Understanding on the sale of counterfeit goods via the internet.

DIRECTIVE 2004/48/EC At international level, all Member States, as well as the Community itself as regards matters within its competence, are bound by the Agreement on trade-related aspects of intellectual property (the

IFG-WP3-D-UIC-015-02 Page 68 of 153 12/12/2018

Contract No. H2020 – 730844

TRIPS Agreement), approved, as part of the multilateral negotiations of the Uruguay Round, by Council Decision 94/800/EC and concluded in the framework of the World Trade Organisation.

The TRIPS Agreement contains, in particular, provisions on the means of enforcing intellectual property rights, which are common standards applicable at international level and implemented in all Member States. This Directive should not affect Member States' international obligations, including those under the TRIPS Agreement.

It emerges from the consultations held by the Commission on this question that, in the Member States, and despite the TRIPS Agreement, there are still major disparities as regards the means of enforcing intellectual property rights. For instance, the arrangements for applying provisional measures, which are used in particular to preserve evidence, the calculation of damages, or the arrangements for applying injunctions, vary widely from one Member State to another.

In some Member States, there are no measures, procedures and remedies such as the right of information and the recall, at the infringer's expense, of the infringing goods placed on the market.

In Europe, where the issue has demonstrated wide differences in IP enforcement options across the Member States, the Enforcement Directive 2004/48/EC from 2004 – also known as IPRED – represents one central piece of legislation.

The Directive was initiated to overcome the existing fragmentation of the internal market in the area of IP litigation and to approximate legislative systems to ensure a high, equivalent, and homogenous level of protection and civil enforcement of IP rights within the EU. The Directive aims to provide a level playing field by requiring minimum harmonisation.

Directive 2004/48/EC on the enforcement of intellectual property rights provides for a minimum but standard set of measures, procedures and remedies allowing effective civil enforcement of intellectual property rights. The objective of IPRED is to bring national legislative systems closer together to ensure a high, equivalent and homogeneous level of protection in the internal market. The evaluation of the Directive has demonstrated that the measures, procedures and remedies set out in IPRED have effectively helped to better protect IPR throughout the EU and better deal with IPR infringements in civil courts. The Directive has led to the creation of a common legal framework where the same set of tools is to be applied across the Union. In this respect, it has achieved the objective of approximating the legislative systems of the Member States for the civil enforcement of IPR. However, the measures, procedures and remedies set out in the Directive are not implemented and applied in a uniform manner among the Member States. This is because, since the Directive provides for minimum harmonisation (i.e. Article 2 explicitly allows national legislation to provide for means that are more favourable to rightholders), there is no uniform interpretation of the Directive’s provisions and there are differences in national civil law proceedings and judicial traditions. Thus, the EU legal framework for civil enforcement of IPR could benefit from the clarification of certain aspects of the Directive allowing a more consistent and effective interpretation and application. This being said, it is also clear that the scope of IPRED, even if properly applied, is limited to regulating measures, procedures and remedies available for the civil enforcement of IPR.

IFG-WP3-D-UIC-015-02 Page 69 of 153 12/12/2018

Contract No. H2020 – 730844

INTELLECTUAL PROPERTY PROTECTION IN EUROPE

The EU is very well aware of the importance of IPR protection. Therefore, the European Union Intellectual Property Office (EUIPO87) was founded in 1994. Formerly known as the Office for Harmonization in the Internal Market (OHIM), it underwent some reforms and since March 2016 it has been known by its current name. The EUIPO works in partnership with national and regional European IP offices, user groups, the European Commission, the European Parliament and other international organisations and it is responsible for registration of the EU trade mark (EUTM) and the registered Community design, two unitary IPRs valid across all the 28 Member States.

As concerns the innovation activities, the four major IPRs are patents, trade marks, design rights and copyrights. Patents are by far the most important IPR related to innovative activity. They protect the exploitation of inventions that are “new, involve an inventive step (non-obviousness) and are capable of industrial application”, they normally grant the owner of the patent the right to exclude third parties from exploiting the patent. Trade marks “provide exclusive rights to any sign (e.g. words, letters, numerals, figurative elements, and logos), or any combination of signs, that enables people to distinguish the goods or services of one undertaking from those of other undertakings”. It has been shown empirically, that trade marks, as a means for commercialisation, are linked to innovation and interact in complex ways with patents. Design rights (referred to in some jurisdictions as design patents) “prevent third parties from making, selling or importing articles bearing or embodying a design which is a copy, or substantially a copy, of the protected design, when such acts are undertaken for commercial purposes”. Finally, copyrights protect the expression of original literary and artistic works, which in some jurisdictions now includes the protection of software too. It is especially the latter aspect that makes copyright important for innovation activity.

A particular focus is related to the EU IPR protection related to the Database and software development

EU IPR PROTECTION-DATABASES In the EU, a “database” consists of a collection of independent works, data or other materials arranged in a systematic or methodical way and individually accessible by electronic or other means.

 Original databases can be protected by copyright.

 Copyrighted databases must be original “intellectual creations”.

 Copyright is the highest level of protection that can be obtained by databases in the EU.

 The owner of the database is the person who creates it.

87 For more information, see https://euipo.europa.eu

IFG-WP3-D-UIC-015-02 Page 70 of 153 12/12/2018

Contract No. H2020 – 730844

Sui generis protection

 Non-original databases – which do not meet the requirements for obtaining copyright protection – can be protected in the EU by a specific EU database right known as the sui generis database right.

 Sui generis databases do not need to be an “intellectual creation”, but they must show that there has been “qualitatively or quantitatively a substantial investment in either the obtaining, verification or presentation of the contents” of the database.

 The owner of a sui generis database is the person who creates the database, that is to say, the person undertaking the initiative of creating the database and assuming the associated investment risks.

 Some examples of protected non-original databases include telephone listings or compilations of legislation.

Requirements for obtaining protection of a database

 To obtain copyright protection, databases must be original intellectual creations. In the EU, databases which, by reason of the selection or arrangement of their contents, constitute the author‘s own intellectual creation shall be protected as such by copyright.

 No other criteria shall be applied to determine their eligibility for copyright protection.

Sui generis right

 To obtain sui generis protection it is required that a substantial investment is made in obtaining, verifying and presenting the contents of the database.

 Substantial investment is understood as a financial and/or professional investment, which may consist in the deployment of financial resources and the expending of time, effort and energy in obtaining and collecting the contents.

Territorial protection

Copyrighted databases

Copyright protection arises automatically in all states which are party to the Berne Convention, which include all EU Member States. Because of the national scope of copyright, there can be some nuances among national laws.

Sui generis databases

This is a purely EU right with no equivalent at international level. Only creators of databases who are nationals of a Member State or who have their habitual residence in the territory of the EU can benefit from this right.

IFG-WP3-D-UIC-015-02 Page 71 of 153 12/12/2018

Contract No. H2020 – 730844

Scope of protection

Copyrighted databases

Protection is conferred to the structure of the database and not to its contents. That is, a reward is given to the efforts made in selecting and arranging the contents, rather than in creating them. However, an individual item of the contents may enjoy separate copyright protection if it complies with the applicable legal requirements (e.g. a photograph included in a database).

The author of a database has the exclusive right to carry out or to authorise its reproduction, adaptation (e.g. translation), distribution, communication, as well as the reproduction, distribution or communication of the results of any adaptation.

Sui generis databases

Unlike copyright databases, the sui generis database right protects the contents of a database. The owner of a sui generis database has the right to prevent the extraction and/or re-utilisation of the whole or of a substantial – qualitative or quantitative - part of the contents of the database:

The right to prevent extraction:

The term “extraction” refers to the permanent or temporary transfer of the whole or of a substantial part of the contents of the database to another medium, by any means or in any form. It implies that some degree of choice or individual appreciation of the content to be extracted is made.

The right to prevent reutilisation:

The term “reutilisation” consists of making available to the public the whole or a substantial part of the contents of the database by any form of distribution, including the renting/lending of the database, online or through other means.

Duration of protection

Copyrighted databases: In the EU, the term of protection corresponds to the life of the author plus 70 years after his death.

Sui generis databases: The term of protection is 15 years from the end of the year in which the making of the database was completed or in which the database was first made available to the public.

IPR MANAGEMENT IN SOFTWARE DEVELOPMENT Software, or computer programs, is a complex asset. At the boundary between pure creations of the mind and technical inventions, multiple intellectual property rights can protect it. The intangible nature, diversity of uses, and the various related means available in order to create value with software also has an impact on such a complexity.

Intellectual property is an essential tool to secure value generated by software. However, the means to create such value can vary considerably depending on the exploitation scheme chosen and the related ecosystem for which the use of software developments are intended. Business models are then formalised in a contract which usually takes the form of licence agreements, imposing specific

IFG-WP3-D-UIC-015-02 Page 72 of 153 12/12/2018

Contract No. H2020 – 730844

usage rules on third parties intending to exploit the software. Licensing therefore plays an essential role for value creation through intellectual property management.

Along with this international legal context, each country has its own copyright law, and this whole system evolves through judicial interpretation or through legislative intervention at national and EU level, which usually seeks harmonisation. To complete the legal framework and subject to legal compliance, parties can regulate the terms of software-related agreements, such as distribution licences, collaboration, employment, etc.

IPR AND SOFTWARE DEVELOPMENT

What is understood by software or computer program is, in fact, a set of different objects that can include source code, compiled code or executables, interfaces, documentation and even preparatory design work. But protection can apply differently; for example, underlying ideas and algorithms, as well as interfaces, are not protected.

Computer programs are usually considered to be sequences of instructions written to perform specific tasks in relation to a machine. They can either be embedded in dedicated hardware or be completely versatile code, allowing for data treatments independently of using a specific operating system.

Developing software is essentially a creative task, relying on the coding and development abilities of a developer. However, this creative task relies on the translation of functional purposes meant to be achieved by the software.

Figure 5: Software development process

Indeed, a typical software development process starts with the identification of a need, which can be met by a computer (step 1). All the different aspects of the need are thoroughly examined by an analyst in a more or less formal way (step 2). This leads to the formulation of a functional answer in the form of a technical solution, which might include potential patentable elements (step 3). This solution is then translated into a creation of the mind: the source code, i.e. the human-readable version of a computer program (step 4). This source code is then converted into a machine-readable binary executable through a process known as compilation (step 5). This executable application can

IFG-WP3-D-UIC-015-02 Page 73 of 153 12/12/2018

Contract No. H2020 – 730844

then be distributed in a given market and be identified by users through the use of a dedicated brand distinct from that of potential competitors (step 6).

Thus, multiple IPR are – or can be – generated in the development of software, as illustrated in Figure 1.

Table 1: Types of IPR

Copyright protection applies automatically, once the software starts to be written and the rights are associated to the person who writes the software, who can claim authorship rights. If the software is developed in a professional context, the employer is entitled to exercise all the associated economic rights, unless it is otherwise specified in a contract. The employer is then identified as the right holder or the owner of the program. If there is no employer, all the rights are associated with the author, except if there are agreements specifying other conditions. Originality is an essential requirement of copyright law, this is why new functionalities need to be well dated and documented. In the Directive the originality concept is defined as the “author’s own intellectual creation”.

The notion of author in software can be simple in the case of only one writer. However, this notion can become less simple in contexts where there are different actors and different roles. For example there can be parts of the code that have been updated and rewritten by different persons, but the former authors are still part of the author’s list. In other situations, persons external to the project can propose code to correct a bug or to add new functionalities, and this code will be adapted by other

IFG-WP3-D-UIC-015-02 Page 74 of 153 12/12/2018

Contract No. H2020 – 730844

developers to be integrated into the main code. Note that when different authors employed by different entities participate in development of the software, the entity‘s percentage of ownership derives from the percentage of the corresponding authorship.

SOFTWARE LICENSING The intellectual property system grants a set of exclusive rights to the owner of intangible assets, such as inventions, brands or designs. This exclusivity allows the owner to exclude others from using its IP assets and, consequently, to grant third parties the rights, more or less extended, to exploit them.

It is clearly stated in the Directive: the running, loading, reproducing, translating or arranging of a computer program can only be done upon the corresponding (written) authorisation. This is why software is distributed under licences. Licences can only be granted by the software owner (i.e. the right holder).

Licensing is a fundamental means of exploiting IPR. It consists of a contract by which a licensor grants a licensee an authorisation to use an identified asset under certain conditions. Licensors can either be the owners of the IPR or act under a mandate from the actual owners.

Licences, sometimes named end-user licence agreements or software licence agreements, are the contracts between the licensor and the licensee (the purchaser of the licence), and establish the rights granted under the licence. In the case where you find a computer program which does not include any licence or without any other legal mention, the default legal context that applies is “All rights are protected”, and means that no one can run, load, etc, the software (except the rightsholders).

When granting a licence, licensors are free to determine the extent of exclusive IPR granted on the assets concerned and conversely the rights reserved for themselves. This is also true for software licensing, involving either software as a whole or just a component. The following figure schematically illustrates the different possibilities of reserving such exclusive rights.

Figure 6: Different possibilities of reserving exclusive right

IFG-WP3-D-UIC-015-02 Page 75 of 153 12/12/2018

Contract No. H2020 – 730844

4.4 FREE/OPEN SOURCE SOFTWARE

Free and Open Source licences fall within the framework of “none” to “some” exclusive IPR reserved. These licences deal with various IPR: they all provide for copyright protection and some for patent and/or trade mark protection as well. Clearly, such licences rely on intellectual property and are in no way opposed to such rights.

In 1985, Richard Stallman publishes the GNU manifesto and launches the Free Software Foundation (FSF88), a movement that establishes other ways to deal with software, based on the user‘s liberty concept. This movement creates the free software definition:

“A program is free software if the program‘s users have the four essential freedoms:

 The freedom to run the program as you wish, for any purpose (freedom 0).

 The freedom to study how the program works and change it so it does what you want it to do (freedom 1). Access to the source code is a precondition for this.

 The freedom to redistribute copies so you can help your neighbour (freedom 2).

 The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.”

In 1998, the Open Source Initiative (OSI89) was launched around the concept of open source software. Despite what some may think, the concept of open source software is not just about access to the source code. The distribution terms of open source software must comply with ten different criteria (known as the Open Source Definition), where the first one is as follows:

“Free Redistribution: The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.”

As one can understand from the definitions, these two movements correspond to very different philosophies, but are sometimes confluent in common goals as, for example, software quality.

A computer program falls within the category of free and/or open source software if the licence complies with the conditions established in the definitions. Most of the licences used in this kind of software make it both “free” and “open source” so there is no real legal distinction between these two concepts, despite the philosophical aspects. However, many members of the software development community prefer not to adopt one or the other philosophy, this is the reason why the term Free/Open Source Software (or FOSS) is widely used.

88 For more information, see https://www.fsf.org/ 89 For more information, see https://opensource.org/

IFG-WP3-D-UIC-015-02 Page 76 of 153 12/12/2018

Contract No. H2020 – 730844

It is common to find a “non warranty clause” in free/open source licences in order to indicate that the software is provided “as is”, and that the developers have no liability with respect to the (bad) use of the software. Another kind of clause is the “reciprocity clause”, where the licensor asks the licensee to respect some conditions, such as keeping initial copyright information in derivative work or to release derivative work under the initial work’s licence. This last example corresponds to the strong Copyleft clause that can be found in the General Public Licence (GPL licence) developed by the FSF.

There are usually other kinds of business models associated to free/open source software, as it is possible to sell support, or to provide customisations or additional functionalities under different licences.

Companies can also invest in free/open source software following different collaboration models, for example by engaging its own staff in the collaborative development effort. By doing this, the company can make an external software product evolve to reach its own goals, while assisting the development community as a whole.

One of the most important reasons to invest in these developments is that the collaborative model usually produces more reliable and of higher quality software. Indeed, users can detect bugs and signal them, or even propose correction code. The developers can validate and integrate the proposed code in the main version of the software or find corrections otherwise. The production of new versions is thus faster and the dissemination mechanism is shorter than in software produced inside one company with more traditional development models.

EUROPEAN COMMISSION FREE/ OPEN SOURCE SOFTWARE POLICIES In 2004, the European Commission decided to distribute its own produced software under a licence that grants all Free (or Open Source) freedoms and created the European Union Public Licence (EUPL) to be adapted to European copyright law and terminology. The EUPL has been certified by the OSI since 2009 and has been recently updated to a new version 1.2 to extend coverage to data and documents (among other works) and to be compatible with a wider range of other open source licences.

Free/open source software has been present in the European Commission open access policies at least since 2012 and is integrated in its strategic vision: Open innovation, open science, open to the world. It appears in the funding of the H2020 Work program ICT 2016-17 as a way to increase use and effectiveness of EU-funded projects.

IFG-WP3-D-UIC-015-02 Page 77 of 153 12/12/2018

Contract No. H2020 – 730844

5. STANDARDISATION

BACKGROUND

In general, the European Union has made proposals for improving standardisation within the internal European market through Directives. However, in 2012, for the first time the EU adopted a Regulation on European Standardisation, the Regulation (EU) 2025/201290.

Standardisation is normally applied on a voluntary basis. When standardisation is developed from a mandate given by the EU to the European Standards Organisations (ESO)s for facilitating the application of EU legislation, the relevant standards are qualified as “harmonised standards”. A harmonised standard is also applied on a voluntary basis, but when quoted in a TSI, application becomes mandatory within the same scope as the one of the TSI. This is also the case of the TAF and TAP-TSI, whereas the Technical Documents referenced in Chapter 3 are also mandatory.

It has to be noted that the European Union publishes every year its “Annual Union work programme for European standardisation” as a “Communication from the Commission” which is a policy document expressing its own thinking with no mandatory authority and which has no legal effect (for 2017 see footnote 91).

STANDARDISATION VS SPECIFICATIONS

Standards, in the proper meaning of such term, can only be produced by organisations, which received a specific authorisation for doing such task, so becoming Standardisation Organisations. They can operate within a defined geographical area (where the standards they publish have validity) and in a specific domain (competence).

A Standards Organisation is a neutral party with a specific process and procedure for adoption. Standards are normally used as a basis for coherent implementation.

Specifications, on the other hand, can be developed by an entity (normally an Industry-specific representative organisation) and are viewed as working documents. There is little difference in the content of a Standard or Specification – the main difference is in how they are produced and validated.

STANDARDIZATION DOCUMENTS

This CENELEC standard series defines the structure and technologies of an on-board Train Communication Network (TCN). Its main elements are:

 the Train Backbone which is the bus connecting the vehicles of a train,

90 http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2012:316:0012:0033:EN:PDF 91 http://eur-lex.europa.eu/legal-content/EN/TXT/DOC/?uri=CELEX:52016DC0357&rid=1

IFG-WP3-D-UIC-015-02 Page 78 of 153 12/12/2018

Contract No. H2020 – 730844

 the Consist Network which is the communication network interconnecting on-board communication devices (end devices) in one Consist (being a train set, a set of coaches, a single vehicle or a group of vehicles),

 the Interfaces (e.g. "Gateways" for the connection between different communication technologies on Consist Network level or "Nodes" being devices on the Train Backbone, which may act as a gateway between Train Backbone and Consist Network) so as to achieve compatibility between Consist Networks and Train Backbones.

The purpose of this part of the IEC61375 series is to create a general model that describes in a functional way the remote control of TCMS functions like “provide access and egress”. The document makes direct reference to part IEC61375-2-3, which covers data transmission on the Ethernet Train Backbone (ETB) and specifies the functions between the consists concerned (e.g. locomotives, multiple units and driving trailers) including the rules to set up the necessary data telegrams for transmission and process.

The technologies defined by EN 61375 are:

 for the system level:

o the GA – General Architecture (EN 61375-1),

 for the Train Backbone:

o the WTB - Wired Train Bus (EN 61375-2-1 and EN 61375-2-2),

o the ETB - Ethernet Train Backbone (EN 61375-2-5),

o the BTG – On-board to Ground communication interface (prEN 61375-2-6),

o the Communication Profile (EN 61375-2-3),

o the Application Profile (TS 61375-2-4),

 for the Consist Network:

o the MVB – Multipurpose Vehicle Bus (EN 61375-3-1 and EN 61375-3-2),

o the CCN – CANopen Consist Network (EN 61375-3-3),

o the ECN – Ethernet Consist Network (EN 61375-2-3).

For some of the technologies, EN 61375 contains procedures for conformance testing (EN 61375- 2-2 and EN 61375-3-2). More conformance testing procedures can be developed in the future.

In general, the standard series contains detailed considerations for the interworking of different network technologies on the level of the "Train Backbone" as well as of the "Consist Network".

Applications of any type can communicate each other over the network irrespective of their position in the train and with no need to care about the communication protocols and mechanisms.

IFG-WP3-D-UIC-015-02 Page 79 of 153 12/12/2018

Contract No. H2020 – 730844

EN IEC 61375-2-3

Title

Electronic railway equipment - Train communication network (TCN) - Part 2-3: TCN communication profile ed. 2015

Abstract:

EN IEC 61375-2-3:2015 specifies rules for the data exchange between consists in trains. The aggregation of these rules defines the TCN communication profile. The objective of the communication profile is to ensure interoperability between consists of the said trains with respect to the exchange of information. For this purpose it defines all items which are necessary for communication interoperability:

- an architecture with defined train directions related to different train views;

- a common functional addressing concept;

- common communication protocol for data exchange between functions;

- a set of services for train communication control.

The annexes cover the following subjects:

• Annex A (normative) Train Real-Time Data Protocol (TRDP);

• Annex B (normative) Safe Data Transmission (SDTv2);

• Annex C (informative) Train Real-Time Data Protocol Configuration (TRDP);

• Annex D (informative) Access to End Device (ED) Statistics;

• Annex E (informative) Service Interface;

• Annex F (normative) Communication profile conformance test guideline.

• Annex G (informative) SNMP Management Information Base (MIB).

This European standard was issued in 2015 without the Annex ZZ because no assessment was done at that time.

A corrigendum was issued in 2016.

An addendum was issued in 2017 which attached the Annex ZZ following the positive assessment of the CEN/CENELEC consultant.

Both corrigendum and addendum are now included in the EN IEC 61375-2-3.

IFG-WP3-D-UIC-015-02 Page 80 of 153 12/12/2018

Contract No. H2020 – 730844

Extracts

The EN IEC 61375-2-3 proposes a logical train architecture which defines a train as composed of services and the information exchanged between the services and between user and services.

Services can be classified in:

• Operational services, as defined in this part of EN IEC 61375 series and in IEC 61375-2-4.

• Multimedia services, as defined in EN IEC 62580.

Subject of this part of the standard are ETB control services and shared ETB system services. Operational services are defined in IEC 61375-2-4.

The following Figure 7 shows the service classification.

TCMS Application Multimedia and Telematic Application

Interface Interface Interface s e c i e v r c i e s v r e S

c e i a i S v

r d l e e o r S t m

i n t S l o u M C

M C B T T E

multimedia section specific framework

Common ETB Framework

ETB

IEC 61375-2-5

IEC 61375-2-3

IEC 61375-2-4

IEC 62580

Figure 7 Classification of services All the services use functions, protocols, and definitions from a common ETB framework, which is defined within clause 5 of EN IEC 61375-2-3.

IFG-WP3-D-UIC-015-02 Page 81 of 153 12/12/2018

Contract No. H2020 – 730844

For multimedia services, a multimedia specific framework may be added which provides multimedia specific functions, protocols, and definitions. The definition of the multimedia specific framework is not within the scope of this document.

The services use the train real-time data protocol (TRDP) which offer the exchange of TCN process data and TCN message data over ETB. The TRDP is executed by a TRDP layer which is placed on top of the TCP/UDP transport layer, see the following figure. This layer may optionally be extended by a safety layer which provides safe end-to-end data transmission of safety critical process data and message data between any two end devices in the network.

END DEVICE END DEVICE

Application Application safety TRDP safe data safety layer transmission protocol layer

other TRDP TRDP protocol TRDP other

TCP/UDP TCP/UDP IP IP Ethernet Ethernet

TCN

Figure 8 TRDP within OSI layers

All the TCMS functions, which offer and/or use TRDP services are logically (virtually) addressed according to the following schema:

trn://[email protected]

scheme user part host part

The label ‘fctdev’ identifies the logical device which is implementing the addressed service function. “Logical” device means that it is not known how this device is implemented, e.g. it could be a single physical device implementing the function or the function could be distributed over several physical devices.

The label “consist” identifies the consist within a train, where the function is located.

IFG-WP3-D-UIC-015-02 Page 82 of 153 12/12/2018

Contract No. H2020 – 730844

IEC TS 61375-2-4

Title

Electronic railway equipment - Train communication network (TCN) - Part 2-4: TCN application profile

Abstract:

IEC TS 61375-2-4:2017(E) applies to the applications in trains, i.e. it covers the application profile for functions belonging to the Train Control and Monitoring System (TCMS). The application profile is based on the TCN communication system for the data communication between consists of the said trains. This document provides for a data interface with parameters and addressing of TCMS functions based on the communication profile laid out in IEC 61375-2-3. This document is applicable in rolling stock requiring interoperable coupling and uncoupling. This part of IEC 61375 may be additionally applicable to closed trains and multiple unit trains when so agreed between purchaser and supplier.

This Technical Specification was published in 2017 and was not submitted to the parallel vote in CENELEC.

For the time being there is an official cooperation with UIC for improving the text extending the specification to all the functions of the TCMS.

When the improved text will be ready it will be submitted to parallel vote in CENELEC and in case of approval it will become a European norm.

The concept of the functional approach to TCMS is summarised in Figure10.

Driver Function- Function- (led operation) (leading operation) interface interface

Function Function control control Cab Cab (operation) (operation) Comm Comm proxy Train backbone proxy communication Function Communication- Communication- Function process interface interface process

ETB 7 6 5 4 3 2 1 1 2 3 4 3 2 1 > > > > 4 3 2 1

consist consist consist consist Figure 9 TCMS functional approach In order to understand better the functional approach, an example of a common situation, when operating a train, is given:

IFG-WP3-D-UIC-015-02 Page 83 of 153 12/12/2018

Contract No. H2020 – 730844

One of the train’s driver cabs on either end is the activated cab in the leading vehicle. In this cab the train driver is controlling the train’s movement by actuating e.g. the traction lever. The command, generated by moving the traction lever on the driver’s desk, sampled, and received by one traction function (called “Function control”) and propagated throughout the train via the Train backbone to all other traction functions via the “Comm proxy” controlling locally the specific traction subsystems. These processes, which are controlling the traction subsystems in each consist or vehicle are called “Function process”.

EN IEC 61375-2-6

Specifically the part 61375-2-6 of this standard series covers the specification of the communication between the on-board subsystems and the ground subsystems.

This part covers the specification of the communication between the on-board subsystems and the ground subsystems. The communication system, interfaces and protocols are specified as a Mobile Communication function, using any available wireless technology. This part provides requirements in order to:

1. select the wireless network on the basis of QoS parameters requested by the application;

2. allow TCMS and/or OMTS applications, installed on-board and communicating on the on-board communication network, to have a remote access to applications running on ground installations;

3. allow applications running on ground installations to have a remote access to the TCMS and/or OMTS applications installed on-board.

This part specifies further requirements which allow the applications running on-board and the applications running on ground to connect each other applying the virtual/functional addressing mechanism specified by IEC 61375-2-3 and exchanging application data sets produced or consumed by the on-board functions implemented in the devices attached to the TCN network.

Furthermore this document covers the security requirements in order to grant the access only to authenticated and authorised applications and to allow encryption of exchanged data.

The communication system, interfaces and protocols are specified as a Mobile Communication function, using any available wireless technology. This document does not cover the specification of the radio technologies and protocols relevant to the wireless communication between train and ground.

The communication of safety related data between on-board applications and ground applications are out of the scope of this standard as well as Internet connectivity service for passengers.

The standard follows the ISO-OSI model.

By providing a general-purpose link between the on-board network (specified in other parts of this standard series) and the ground network, this standard allows any on-board application to exchange information with its ground counterpart, with no need for each application to include its own private and custom data link to ground. Applications will share an existing (possibly multiple) radio link,

IFG-WP3-D-UIC-015-02 Page 84 of 153 12/12/2018

Contract No. H2020 – 730844

whatever it is, much in the same way as they share a common wire or optical fibre in the on-board or ground networks.

Extracts

The overall communication infrastructure can be separated into the train on-board communication network and the off-board (ground) communication system.

The train on-board communication network is defined in IEC61375 part 1 as a hierarchical structure with a train backbone for the communication along the train and subordinated consist networks for inner-consist communication, see the following figure.

consist consist

train backbone

MCG Node MCG Node Node

< consist network < consist network consist network

Figure 10 TCN architecture There exist various architectures of ground communication systems which can vary from country to country and from operator to operator.

For the specification of the on-board to ground communication, the architecture of the ground communication system is irrelevant as long as the essential requirements of the IEC 61375-2-6 are fulfilled.

The MCG connects the on-board communication network to the ground communication system as shown in the following figure.

IFG-WP3-D-UIC-015-02 Page 85 of 153 12/12/2018

Contract No. H2020 – 730844

WAN Infrastructure

Wayside Internet Client (ED) Intranet Firewall DB

Application Wayside Ground System (DMZ) Server Client (ED)

Wayside DB Communication Gateway (WCG) RADIUS Server WAN Infrastructure Firewall Router Intrusion Detection Remote Access System DB Server (IDS) DDNS Server Firewall Mobile Area Network Infrastructure

Provider Network WLAN Infrastructure

Access Point WLAN Network Access Point Radio tower

E LT W S/ L T A UM N S/ ground side PR /G M GS

on-board / train side MCG

Consist

Figure 11 Communication infrastructure overview

61375 series Governance inputs

The 61375 series was prepared at international level by IEC TC9 WG43; nevertheless CENELEC TC9X considered the series of interest for the European standardisation, consequently IEC TC9 and CENELEC TC9X agreed on applying the parallel voting.

In order to support the coordination with IEC TC9 WG43, CENELEC TC9X set up, about 10 years ago, the mirror working group CLC TC9X WG15.

IFG-WP3-D-UIC-015-02 Page 86 of 153 12/12/2018

Contract No. H2020 – 730844

An official liaison was set up between IEC TC9 WG43 and CLC TC9X WG15.

This last WG was setting up a liaison with CEN TC278 in order to exchange information on the ongoing activity of standardisation in the ITS (Intelligent Transport System).

TCNOpen Initiative (governance inputs)

TCNOpen is an open source initiative which the partner railway industries created with the aim to build in collaboration some key parts of new or upcoming railway standards, commonly known under the name TCN (Train Communication Network), IEC 61375 series, allowing electronic devices to exchange information while operating aboard the same train.

Core partners include Bombardier, CAF, Siemens, Toshiba, Unicontrols (see www.tcnopen.eu).

TCNOpen follows the Open Source scheme, as the software is jointly developed by participating companies, according to their role, so as to achieve cheaper, quicker and better quality results. The project is hosted in Sourceforge.

Companies, wishing to join the initiative, become part of the TCNOpen Interest Group and can collaborate in the specification, development and test of standard components or simply use them following an Open License Agreement. From the 5 initial partners, another 49 observers could join the initiative so far, with additional requests coming often.

The license agreement follows two different schemes:

 The TRDP Source Code (except the TRDPSpy source code) is subject to the terms of the Mozilla Public License, v. 2.0 (MPL). See: https://www.mozilla.org/en-US/MPL/2.0/

 The TRDPSpy Source Code Form is subject to the terms of the GNU General Public License (GPL). See: http://www.gnu.org/licenses/gpl.html

These schemes can be taken into consideration in order to distribute some parts of software related to the Interoperability Framework, which can be critical in order to ensure interoperability.

EN IEC 62580 series

The CNELEC standard series aims at defining requirements in order to ensure interoperability between on-board multimedia and telematics subsystems (OMTS). The general objective is so to achieve compatibility between subsystems in the same vehicle and between subsystems on-board of different vehicles in the same train.

The multimedia and telematic system is composed of but not limited to:

A - Video surveillance/CCTV

B - Driver and crew orientated services

C - Passenger orientated services

D - Train operator and maintainer orientated services

IFG-WP3-D-UIC-015-02 Page 87 of 153 12/12/2018

Contract No. H2020 – 730844

It is assumed that communication within and between the subsystems is made possible by an on- board communication network and a train-to-ground communication link, as specified in the EN 61375 standard series.

The EN 62580 standard series originally envisaged to have a first part related to the general architecture and four parts addressing the four possible subsystem categories.

However, only Part 1 – “General Architecture” has been published, while Part 2 – “Video surveillance/CCTV services” (related to Category A) will be published by IEC as a Technical Specification.

The other parts are at an earlier stage, with only Part 4 - Passenger orientated services (Category C) having already produced a draft working document.

EN IEC 62580-1

The EN 62580-1 standard specifies the requirements related to:

 the boundary between the OMTS and the on-board communication system, as described by the IEC 61375 series

 the methodology to describe an OMTS in terms of abstract model

 the general principles and the basic requirements to specify the services provided/needed by each category

 the approach to ensure interoperability between services

This part gives guidelines for:

 OMTS classification

 functional breakdown structuring

 system breakdown structuring

 formal specification of an OMTS

This part is applicable to any type of train, e.g. open trains, multiple unit trains and closed trains.

The standard EN 62580-1 includes high-level requirements in order to provide a common basis for the specification of the multimedia and telematic subsystems within each of the envisaged categories. Therefore it includes a general architecture, as well methodology and guidelines to be followed in the preparation of the specific additional parts of the EN 62580 standard series.

Communication aspects, although needed by the addressed subsystems, are not part of the scope, as they are dealt with by the EN 61375 standard series.

IFG-WP3-D-UIC-015-02 Page 88 of 153 12/12/2018

Contract No. H2020 – 730844

The envisaged architecture follows a peer-to-peer Service Oriented Approach (SOA), which allows interoperability between applications at the level of Web Services. Messages are formatted according to XML (or optionally ASN.1). The possibility to follow a semantic approach based on an Ontology is included as well.

The envisaged methodology, which should be applied in order to define the other parts of the series, includes five steps:

1) definition of use cases

2) system breakdown (including identification of components and interfaces)

3) functional breakdown (defining a hierarchy of functions)

4) abstract modelling (limited to functions and interfaces relevant to interoperability)

5) definition of services (including service messages and data interchanged)

The issue of interoperability is covered, also considering the case of subsystems on different consists, which can be coupled and uncoupled.

Extracts

The general architecture, described by EN IEC 62580-1, is the basis of On-board MultiMedia Subsystems (OMTS) and is specified in terms of services.

The main benefit of the service approach is to decouple applications from communication aspects, so as to assure that applications compliant with IEC62580 series are compatible with the protocols compliant with IEC61375 series irrespective of possible amendments of the two series of standards.

The above concepts are shown in the following figure.

Figure 12 Communication and application layers

IFG-WP3-D-UIC-015-02 Page 89 of 153 12/12/2018

Contract No. H2020 – 730844

Each category of OMTS are described using a single model which is able to express the basic behaviour of the subsystem. Details which are too close to product implementation or can put unneeded constraints on future evolution of OMTS should be avoided.

The OMTS are specified by an abstract model based on functional breakdown of the main OMTS function, the interactions and behaviour of the functions obtained from the breakdown, their interfaces and the related offered and/or requested services.

This concept is illustrated by the following figure.

Figure 13 General abstract model

The concepts used in the OMTS abstract model according to Figure 9 above and the relationships between them are captured in the conceptual model depicted in the following figure.

Figure 14 General conceptual model

IFG-WP3-D-UIC-015-02 Page 90 of 153 12/12/2018

Contract No. H2020 – 730844

Semantic technology aspects

Ontology

A structure of concepts or entities within a domain, organized by relationships; a system model.

Note 1 to entry: an ontology is a methodology which allows to specify knowledge within a specific domain in terms of concepts and the relationships which occur between them, so as to unambiguously define the meaning of each concept within a certain context. An Ontology can be implemented using a semantic formal language which is machine-interpretable, building a model of the knowledge domain which can be automatically processed by computers

Definition of multimedia services, based on XML and XML Schema only, will leave some problems unsolved:

[1] how to describe not only the syntax of contents but also its meaning (semantics);

[2] how to express data in a non-ambiguous form which can turn them into well-defined information;

[3] how to allow automatic elaboration of information based on its meaning;

[4] how to ensure consistency between information defined in different applications (developed differently in time and space).

A more complete and self-consistent representation of information can be offered by means of Ontology. The specification of the ontology is not covered by the IEC 62580 series.

Information Exchange Format 2 – IEF2

When Information Exchange Format 2 is chosen, data are expressed by means of a formal semantic language, e.g. Ontology Web Language (OWL) representing a common Ontology.

The Ontology may be used as a reference in order to define the contents of messages, for interfaces implemented according to the Information Exchange Format 2 (IEF2).

Contents may be defined using a semantic formal language based on XML (e.g. using the OWL language). Therefore, IEF2 differs from IEF1 as: a) Messages are still encoded in XML, but following a semantic language b) Messages embed their meaning (Ontology references) within their contents

ANNEX E (informative) includes a brief introduction to Ontology and OWL.

EN 50463 series

This CENELEC Standard defines a complete set of requirements for an Energy Measurement System (EMS) on board trains. It describes the primary purpose of the EMS, which is to measure energy consumption for billing purposes and provide compiled energy billing data (CEBD) to a DCS (Data Collection System). The EMS may also be used for other applications such as energy

IFG-WP3-D-UIC-015-02 Page 91 of 153 12/12/2018

Contract No. H2020 – 730844

management, driving advisory systems, etc. In addition, this European Standard also describes the primary purpose of a DCS and its interactions with an EMS and settlement system.

The standard includes five parts,

— Part 1: General; it gives general system requirements for the complete Energy Measuring System and common requirements for all devices implementing one or more functions of the EMS.

— Part 2: Energy measuring; it deals with voltage and current measurement as well as energy calculation, so completely describing the Energy Measurement Function. It considers energy both consumed from and supplied to the contact line. All relevant metrological aspects are covered in this part. Conformity assessment arrangements are also specified in this part.

— Part 3: Data handling; it specifies how to compile data in order to produce, store and send them in a form suitable for billing purposes (Compiled Energy Billing Data). It includes the Data Handling System (DHS) on-board and basic requirements for the Data Collecting System (DCS) on-ground. Conformity assessment arrangements are also specified in this part.

— Part 4: Communication; this part includes interfaces, protocols and procedures necessary for the EMS to exchange data between its functions and with other units. It includes the on board to ground communication service and covers the requirements necessary to support data transfer between DHS and DCS. Conformity assessment of the communication services are included in this part as well.

— Part 5: Conformity assessment; scope of this part is the conformity assessment procedures for the EMS. It also covers re-verification procedures and conformity assessment in the event of the replacement of a device of the EMS.

Communication aspects and related interoperability issues are dealt with in Part 4, which is specific to the EMS but includes concepts general enough to be useful for other applications.

EN 50463-4

The scope of EN 50463-4 is to deal with the communication services.

EN 50463-4 applies to the on board and on board to ground communication services, i.e. it covers the data communication using digital interfaces:

a) between functions implemented within the EMS;

b) between EMS function and other on board subsystems;

c) between EMS and ground communication services.

The on board data communication services of the EMS are covering the data exchange between functions of the EMS and the data exchange between EMS and other on board units, where data are exchanged using a communication protocol stack over a dedicated physical interface or a shared communication network.

IFG-WP3-D-UIC-015-02 Page 92 of 153 12/12/2018

Contract No. H2020 – 730844

The radio link itself, between train and ground, is outside the scope of this standard: any suitable radio link solution, including its software interface, can be used.

The on board to ground communication services are covering the wireless data communication between the DHS and the on ground server.

Furthermore, this document includes conformity assessment requirements.

The specified protocols are mainly based on 61375-2-6 (see 2.3.1), but when a network compliant with this standard is not available, a “dedicated solution” can be used alternatively. The possibility to have more than one protocol can create a problem of interoperability: this has been solved deciding that the ground part of the system (DCS) must be able to understand all protocols.

Data format and structures rely on an XML schema, which is completely specified within the standard itself. UML diagrams are also used in order to better explain the data structures.

Extracts

The following figure illustrates the functional structure of the EMS, the main sub-functions and the structure of the dataflow and is informative only. Only the main interfaces required by this standard are displayed by arrows.

Since the communication function is distributed throughout the EMS, it has been omitted for clarity. Not all interfaces are shown.

Figure 15 High-level functional breakdown The EMS is an on-board subsystem and a metrological instrument at the same time, consequently the conformity assessment plays a crucial role. The following figure shows test methods to be carried out for the conformity testing. As shown by the figure, there are three different levels which the assessment is applied to: EMS device level, EMS integration level and EMS installation level.

IFG-WP3-D-UIC-015-02 Page 93 of 153 12/12/2018

Contract No. H2020 – 730844

Device Device EN 50463-1 D B C Device Device Conformity A E EN 50463-2 Report documentation Assessment EN 50463-3 Documentation EN 50463-4

EMS Equipment Type A C B EN 50463-1 EMS Integration Design EMS D E EN 50463-5 Review Integration Documentation Design Review Integration Design Review Report

EMS Equipment Type A C EMS B EMS Integration type test EN 50463-1 Integration EN 50463-5 documentation E Type Test D Report Integration Type Test

EMS Equipment Type + Traction unit type A B C EMS EMS Installation design review Installation EMS Conformity D E EN 50463-1 documentation Design Review EN 50463-5 Assesment Report File Installation Design Review

EMS Equipment Type + Traction unit type A C EMS B EMS Installation Type Test EN 50463-1 Installation E Documentation D EN 50463-5 Type Test Report

Installation Type Test

Figure 16 Test methods The test methods include design review and type testing for each level.

Data structures

As an example of the mandatory data structures, the following extract from the XML schema is here included:

IFG-WP3-D-UIC-015-02 Page 94 of 153 12/12/2018

Contract No. H2020 – 730844

Optional data structures and data structures for board to ground communication are defined as well. For example, for an event:

IFG-WP3-D-UIC-015-02 Page 95 of 153 12/12/2018

Contract No. H2020 – 730844

Governance inputs

The series was prepared by CENELEC TC9X WG11 following a request for standardisation sent by ERA to CENELEC in order to have consistency between the relevant part of the ENE TSI and Rolling Stock TSI.

ERA and CENELEC TC9X carried out the work setting up the following coordinated working structure:

CENELEC TC9X WG11: working group in charge of preparing the EN 50463 series.

ERA Energy Meters Working Party: working group in charge of preparing the clauses, relevant to energy meters on board of trains, to be included in the “ENERGY SUB-SYSTEM” and “LOCOMOTIVES AND PASSENGER ROLLING STOCK” technical specification for interoperability.

In order to assure a perfect consistency and time synchronisation between the activity in CENELEC TC9X WG11 and ERA Energy Meters Working Party, governance was introduced which required the ERA officers in charge of the energy meters to participate to the CENELEC TC9X WG11 working activity and vice versa.

The issues were eventually discussed and solved by the ERA and TC9X officers in dedicated meetings.

RELEVANT STANDARDS AND SPECIFICATIONS IN THE RAIL SECTOR

The main entities with direct applications for the IF are:

Regulation/Standard/Convention Mode Geographic Applicability

W3C standards for: General Global 1. Semantic Web 2. XML 3. Web of Services Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

IFG-WP3-D-UIC-015-02 Page 96 of 153 12/12/2018

Contract No. H2020 – 730844

Scope and Stakeholders The main reference for all web issues is the World Wide Web Consortium (W3C)92, which is an international open community that develops open specifications93 to ensure the long-term growth of the Web. W3C operates under a Code of Ethics and Professional Conduct.

W3C is the main body for defining the architecture and underlying standards for interoperability of the World Wide Web (www). As described on their website, “W3C standards define an Open Web Platform for application development that has the unprecedented potential to enable developers to build rich interactive experiences, powered by vast data stores that are available on any device. Although the boundaries of the platform continue to evolve, industry leaders speak nearly in unison about how HTML5 will be the cornerstone for this platform. But the full strength of the platform relies on many more technologies that W3C and its partners are creating such as the Semantic Web stack, XML, and a variety of APIs.

W3C develops these technical specifications and guidelines through a process designed to maximize consensus about the content of a technical report, to ensure high technical and editorial quality, and to earn endorsement by W3C and the broader community. “94

Some of these technology standards are used exclusively to power the IF and provide the basis for the underlying technologies are used by the IF Assets. Furthermore, the products and services that will be developed under IP4 and outside application developers will use the W3C standards as a basis for development. The most pertinent W3C specifications in the context of the IF are:

Semantic Web

Semantic Web technologies are the backbone for the development work that is being applied in IP4. These technologies make it easier for computers to communicate seamlessly (and discover data) over networks or enterprises, by making data ‘machine readable.’ This is achieved by ‘Linking’ data. The components of the Semantic Web suite of [de facto] standards are as seen below.

RDF: Linked data must be defined in Resource Description Framework (RDF) and published. The RDF will make your data ‘discoverable’ to machines with the application of the other semantic web technologies.

OWL: The Web Ontology Language (OWL) provides a structured way to build vocabularies and semantic repositories (called ‘Ontologies’) for the Semantic Web. Clear, semantic definition helps data integration by eliminating ambiguities found using natural language. This Ontology structure comprises the basis for the IF Asset ‘Ontology.’

SPARQL: In order to discover data found on the Web (or in a database) the Protocol and RDF Query Language (SPARQL) is used. Using SPARQL, Web Data can be extracted by

92World Wide Web Consortium: www.w3.org 93 http://www.w3.org/TR/ 94 https://www.w3.org/standards/

IFG-WP3-D-UIC-015-02 Page 97 of 153 12/12/2018

Contract No. H2020 – 730844

using the triple stores (structured, semantic definitions) as defined in the RDF, as described above.

Additional standards which will be applied to the IF Assets are:

XML: The Extensible Markup Language (XML) is a simple text-based format for representing structured information: documents, data, configuration, books, transactions, invoices, and much more. It was derived from an older standard format called SGML (ISO 8879), in order to be more suitable for Web use.95

All published resources in the IF Asset ‘Schemas and Mappings’ will be published according to the W3C Standards.

Web of Services: Web of Services refers to message-based design frequently found on the Web and in enterprise software. The Web of Services is based on technologies such as HTTP, XML, SOAP, WSDL, SPARQL, and others. The IF Assets will be using the above- mentioned technologies for deployment. These will be applied in the Webservice Asset.

There are other entities which are developing specifications, open standards or inputs for standards and which are not officially recognised within the International Standardisation Organisations, the European Standardisation Organisations and the National Standardisation Organisations. These entities are developing, coordinating, promulgating, revising, amending, reissuing, interpreting, or otherwise producing technical specifications that are intended to address the needs of a group of affected adopters. These specifications can be seen as “de facto” standards. Sometimes these de facto standards are useful inputs for standardisation. In such cases, a cooperation liaison can be set up between these entities and official Standardisation Organisations.

For the rail sector and public transport, the main associations which impact standardization activities are the following:

UIC The UIC, French acronym which stands for “Union Internationale des Chemins de fer”, is the International Union of Railways, an international body of the railway undertakings (mainline transport operators), infrastructure managers and regional rail associations.

The mission is to promote rail transport at world level with the objective of optimally meeting current and future challenges of mobility and sustainable development. Furthermore, the mission includes the promotion of interoperability and, as a SDO, the preparation of IRS (International Railway Solution) technical documents for railways.

UIC has an official strategic liaison with IEC and ISO for cooperation in the preparation of IEC and ISO standards.

95 https://www.w3.org/standards/xml/core

IFG-WP3-D-UIC-015-02 Page 98 of 153 12/12/2018

Contract No. H2020 – 730844

Examples of cooperation areas are the on-board train communication network and on-board multimedia. www.uic.org

UITP The UITP, French acronym which stands for “Union Internationale des Transports Publics”, is The International Association of Public Transport.

UITP is a non-profit advocacy organization for operators and public transport authorities, as well as for the manufacturing industry and all other public transport stakeholders (academics, consultants...). Located in Brussels, the association was founded in 1885 and represents an international network of 1,400 member companies located in 96 countries. UITP covers all modes of passenger public transport e.g. metro, tramway, light rail, regional and suburban railways, bus and waterborne transport (and taxi).

UITP cooperates mostly with CLC TC9X, CEN TC256 and CEN TC278 at European level.

In the European Union, UITP brings together more than 400 urban, suburban and regional public transport operators and authorities from all member states and is consequently recognised as a key interlocutor for the European regulators and standardisation bodies, e.g. as a rail representative association and especially through its “Urban Rail Platform” created jointly with UNIFE (see below) and with the participation of the European Commission. www.uitp.org

UNIFE UNIFE, based in Brussels, is the organisation representing the European Rail Industry since 1992. All segments of the rail supply industry are represented in the membership: system integrators, railway infrastructure supply companies, rolling stock as well as subsystem and signalling suppliers and engineering companies joining under the UNIFE umbrella to collaborate on common challenges and issues facing the rail supply industry. UNIFE’s purpose is to represent its members’ interests at international and EU level. An example of inputs for standards produced by UNIFE are the TECRECs (Technical Recommendations), which sometimes evolved into CEN-CENELEC TR and/or TS. www.unife.org

OTIF OTIF, the Intergovernmental Organisation for International Carriage by Rail, was set up on 1 May 1985 as a consequence of the Convention of 9 May 1980 (COTIF). Its predecessor was the Central Office for International Carriage by Rail which was set up in 1893. It is the oldest international organisation in the sector. It now has 50 Member States, including one Associate Member (Jordan). The Organisation has its headquarters in Berne, Switzerland, and has legal personality under international law and in the national laws of its Member States.

OTIF develops unified railway regulations to connect Europe, Asia and Africa. It uses simple and effective tools to promote, improve and facilitate international carriage by rail.

OTIF provides legal and technical interoperability for international carriage by rail. It works in close partnership with the European Union, the European Union Agency for Railways, the International Rail Transport Committee (CIT), the International Union of Railways (UIC), the Organization for Co-

IFG-WP3-D-UIC-015-02 Page 99 of 153 12/12/2018

Contract No. H2020 – 730844

operation between Railways (OSJD) and the United Nations Economic Commission for Europe (UNECE).

Its basic legal instrument is the Convention concerning International Carriage by Rail (COTIF 1999) and its seven Appendices. The Protocol of 3 June 1999 (Vilnius Protocol) modified the COTIF, which objective is to develop the uniform legislation applying to the carriage of passengers and freight in international through traffic by rail, e.g. the contracts of carriage for the international carriage of passengers and goods (CIV and CIM uniform rules, respectively). The CIV Uniform Rules (“RU CIV 1999”) entered into force on 1 July 2006 in 33 Member States of OTIF and also became de facto applicable in Greece and Belgium. The CIV/CIM Uniform Rules apply to about 270,000 km of rail routes and on several thousand kilometres of shipping routes, inland waterways and (in domestic carriage) road. Since the ratification of the Vilnius Protocol by the European Commission in 2011, the Committee of Technical Experts of OTIF must help ensuring consistency between the COTIF rules and the Technical Specifications for Interoperability (TSIs) and certification procedures established by the European directives. www.otif.org

Other organisations or “platforms” worth mentioning are:

- OSPT Alliance aiming (among the others) to define a new open standard for secure cost- effective, and flexible transit fare collection solutions through a global, multi-provider community. In particular, its CIPURSE open standard provides an advanced foundation for developing highly secure, interoperable, and flexible transit fare collection solutions. It is built on proven standards, including ISO 7816, AES-128, ISO/IEC 14443-4 for securing multiple payment types.

- CNA, Calypso Networks Association, is dedicated to extend the partners cooperation and guarantee the evolution of Calypso specifications and their promotion on a global scale. Calypso is a set of technical specifications describing a fast and secure contactless transaction between a terminal and a portable device; it corresponds to the level 3 in the ticketing transaction layers scheme, which is really the heart of a transaction, on which the performances and reliability of a whole ticketing system rely. It is where the security, the efficiency and the speed of a transaction are defined. It is based on two patents, Session and Ratification, invented by Calypso founders. Calypso technology represents a coherent aggregation of its specifications with the use of all existing standards at the levels of the communication interface, of the card mapping and file organization, of the card data structure.

- STA, the Smart Ticketing Alliance which is a platform for cooperation and a coordinated approach for establishing ticketing interoperability for the Public Transport sector; This includes the establishment of a trust scheme that mirrors the schemes used in the mobile phone industry, banking sector and with other stakeholders. Founding members were UITP, Calypso, ITSO, AFIMB and VDV eTicket Service. STA considers it is essential that public authorities and users can be confident in the quality of contactless communication between contactless readers and fare media. Certification is the appropriate means to give trust. The STA certification program established by STA consists of a Group of Certification Bodies (STA GCB) bringing together certification bodies authorized to certify compliance of transportation and acceptance media with the CEN technical specification TS 16794 about contactless communication. The objective of the STA Group of Certification Bodies is to establish a common approach to conformity certification and the technical equivalence of certification

IFG-WP3-D-UIC-015-02 Page 100 of 153 12/12/2018

Contract No. H2020 – 730844

carried out by the STA Group of Certification Bodies’ members. The members will work collectively to achieve these aims but remain independent certification bodies being responsible for their own decisions and for the control of their different certification marks. The STA Group of Certification Bodies (STA GCB) works as a platform to ease mutual recognition between the member certification bodies (and the testing laboratories for product testing) and to limit the costs of those agreements. A primary goal of the STA GCB is to ensure that the certification bodies and the associated testing laboratories operate on a common basis.

- GlobalPlatform, presented as the standard developer for Secure Digital Services and Devices, has the goal to develop specifications, which are today highly regarded as the international de facto standard for enabling digital services and devices to be trusted and securely managed throughout their lifecycle. GlobalPlatform protects digital services by standardizing and certifying a security hardware/firmware combination, known as a secure component, which acts as an on-device trust anchor. This facilitates collaboration between service providers and device manufacturers, empowering them to ensure adequate security within all devices to protect against threats. GlobalPlatform specifications also standardize the secure management of digital services and devices once deployed in the field. Altogether, GlobalPlatform enables convenient and secure digital service delivery to end users, while supporting privacy, regardless of market sector or device type. Devices secured by GlobalPlatform include smartphones, tablets, set top boxes, wearables, connected cars, other Internet-of- Things (IoT) devices and smart cards.

- ORACLE corporation, developing the first autonomous database cloud and managing the Java Card Platform providing an open, interoperable environment enabling the development and deployment of portable trusted identity services to individuals and personal devices;

- IETF, the Internet Engineering Task Force, develops and promotes voluntary Internet de facto standards, in particular the specifications that comprise the Internet protocol. The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It follows open and well-documented processes (e.g. RFC 2026 (BCP 9)).

- NFC Forum provides specifications which help the ecosystem harmonize today’s diverse contactless technologies for Near Field Communications (NFC). NFC is a standards-based short- range wireless connectivity technology that makes life easier and more convenient for consumers around the world by making it simpler to make transactions, exchange digital content, and connect electronic devices with a touch. NFC is compatible with hundreds of millions of contactless cards and readers already deployed worldwide. NFC technology enables short-range wireless interaction between consumer electronics, mobile devices, personal computers, electrical appliances, and NFC- compatible tags.

- IEEE ‘The world's largest technical professional organization for the advancement of technology’ through publications, conferences, technology standards, and professional and educational activities, and technology standards.

IFG-WP3-D-UIC-015-02 Page 101 of 153 12/12/2018

Contract No. H2020 – 730844

The IRS 50405 – Railway Application – Rolling Stock – Specification “Diagnostic Data Transmission from railway vehicles” is an International Railway Solution published by UIC on September 2016.

The IRS are structured in a General Part and some Application Parts, to be prepared in order to address current needs of the railway community.

The General Part is valid worldwide while each Application Part is valid for a specific railway application.

For the time being only the General Part is published as IRS 50405.

The document was prepared by RSF, the Rolling Stock Sector – Sector Expert Team 8 “Data Communication” in order to specify common contents and formats for diagnostic data transmission from railway vehicles to ground.

This document replaces the foreseen UIC 559 which was prepared as a draft but never published.

The document specifies the structure of the information to be transmitted to ground from the train in order to support train operation and to improve train maintenance.

Universal and functional contents, which can be used by most of the operators, are described in detail using XML (Extensible Mark-up Language) schema and XML files.

The contents refer to data specified by UIC 556 – Information transmission in the train (train bus) and UIC 557 – Diagnostics on passenger rolling stock.

Related support documents

The Rolling Stock Sector – Sector Expert Team 8 “Data Communication” prepared some support documents with the aim to improve comprehension of the subject matter.

The support documents are available for the UIC members as downloadable files from UIC website www.uic.org/ and are reported in the following list:

 XML Schema;

 Empty XML file, based on XML Schema;

 3 XML files filled by SNCF, DB, Trenitalia with data serving as an example;

 An html stylesheet for presentation on web browser;

 UML model.

Governance inputs from Cooperation UIC-IEC

UIC and IEC have a cooperation agreement which has the aim to coordinate the publications issued by IEC and UIC.

IFG-WP3-D-UIC-015-02 Page 102 of 153 12/12/2018

Contract No. H2020 – 730844

In the frame of this agreement, a Strategic Liaison Group (SLG) was set-up, with meetings held on a 6-monthly basis between Officers of IEC/TC9 and UIC Standardisation Platform with the following tasks:

- Present and explain work programs of both IEC and UIC;

- Identify the areas, the priorities and the standardisation work of mutual interest keeping a cohesive system view and propose a Program of Work of mutual interest to the Partners;

- Review areas of cooperation of the past years and the work of the SLG Subgroups, additional Subgroups may be proposed;

- Review process for the cooperation between UIC and IEC.

A possible area of cooperation is TCMS and the involved relevant publications are:

 UIC publications:

o UIC 556 - Information transmission in the train (train bus);

o UIC 557 - Diagnostics on passenger rolling stock;

o IRS 50405 - Railway Application – Rolling Stock – Specification “Diagnostic Data Transmission” from railway vehicles

 IEC publications:

o IEC 61375-2-3

o IEC 61375-2-4

o IEC 61375-2-6

UIC 918 XML

The UIC 918 series covers information exchange relating to:

• Reservation in trains (e.g. seats, couchettes);

• Availability information;

• Reservation on ferry;

• Timetable information;

• Tickets (travel documents);

• Listing.

IFG-WP3-D-UIC-015-02 Page 103 of 153 12/12/2018

Contract No. H2020 – 730844

UIC Leaflet 918-1 describes the regulations and procedures to be observed when exchanging messages between a RU that issues travel tickets and reservation tickets and the electronic system of the RU which manages the necessary data for the issue of these tickets, in particular the inventories of seats available for reservation. It is supplemented by the following three very important leaflets:

• UIC Leaflet 918-0 which deals with the general arrangements for electronic seat reservation and the electronic preparation of travel documents;

• UIC Leaflet 918-2 which describes the standard RCT2 that applies to all the travel documents prepared electronically (the only people allowed access to this Leaflet are the correspondents whose names are on the list held by the UIC Passenger Department)

• UIC Leaflet 918-4 which defines the necessary data in the messages relevant to electronic ticketing, in case of : (i) a ticket check (ticket is used or partially used), (ii) an endorsement/annotation (if the carrier was not able to fulfil a part of the contract), (iii) an after sales operation (when the ticket is cancelled/modified at a desk). Since some data can be optional, bilateral agreements have to be made, defining which info of the list, defined in the standard as being optional, needs to be shared.

UIC 918 XML is the XML version of the binary messages that were created by the UIC and that have then been incorporated in the Technical Document B.5 of the TAP TSI. 918.1 XML is at the moment a proprietary standard of UIC, that could possibly in future be incorporated in an extended version of TAP TSI

Here we focus on the element “ReservationRequest” schema in order to be compared to the similar schema proposed by FSM (see above). This schema supports to define XML message with the following structure:

 Requestor: identified by the attributes RequestingSystem and SendingSystem and by the element Terminal (that is identified by Type, Number, Country and, in case, TravelOfficeOrganization).

 Dialogue: identified by the attributes ApplicationVersion, DialogueId and the Boolean Test and by elements DispositionElement (contains information about the requesting system which must be quoted back unchanged by the replying system) and RequestDate (date on which the request is issued. The date is defined in the time zone of the requesting system)

 SeatRequest: identified by the optional Boolean attribute IndividualTicketing and by the following series of elements:

o RequestedTrain: identified by the attribute AcceptDifferentTrain, SequenceId and JourneyId and by the element Train (a code), DepartureDate, DepartureStation (identified by a Context (918), CountryCode and LocalCode) and ArrivalStation (identified by a Context (918), CountryCode and LocalCode).

o Passengers: number of passenger

o Class: class type

IFG-WP3-D-UIC-015-02 Page 104 of 153 12/12/2018

Contract No. H2020 – 730844

o Smoker: number

o CoachType: enumeration

o CompartmentType: enumeration

o Contingent: enumeration (description of the group)

o TravelersWithCar: number

o PositionOfPlaces: enumeration

o PositionOfCompartment: enumeration

o Tariff: TariffCode and Context (918) and Passengers (i.e., NumberOfPassengerType).

o AdditionalMeals: identified by the attribute Type and the element NumberOfMeals and TimeOfMeal.

An example of response to the previous message is given by an XML message based on the “ReservationReply” schema with the following structure:

 Requestor: same as the request.

 Dialogue: same as the request.

 Allocation: identified by the attribute SequenceId and optionally by the Boolean attributes IndividualTicketing, TrainChanged, StationChanged, DateChanged. Moreover, it is identified by the elements Reference (AllocatingSystem and LocalReference) and SeatAllocation that is further identified by:

o AllocatedTrain: identified by DepartureStationName, ArrivalStationName, Category (with Context and Code), Train (a code), ServiceBrand (with Code, Abbreviation and Description), DepartureDateTime and ArrivalDateTime.

o Passengers: see request

o Class: see request

o CoachNumber: number

o CoachType: see request

o CompartmentType: see request

o Contingent: see request

o OverbookedPlaces: identified by OverbookedPlacesType and NumberOfPassengerType.

IFG-WP3-D-UIC-015-02 Page 105 of 153 12/12/2018

Contract No. H2020 – 730844

o TravelersWithCar: see request

o AllocatedPlaces: each place is identified by Place and Code.

o BookedOffer: identified by the attribute Type and the element Price (Amount and PartialPrice) and Supplements (Number and Type).

o Meals: identified by the attribute Type and the elements Number, DateTimeOfMeal and Price.

o NegativeReply: identified by the attributes SequenceId and ReplyCode and, in case, by the elements AlternativeService, AlernativeTrain and AlternativeSystem.

railML is a data exchange format developed by a consortium of railway companies, academic institutions and consultancy firms. Formed in 2002, the railML.org project aims to continuously develop this format in order to facilitate its use in a wide range of railway applications.

The project started as a partnership between the Fraunhofer Institute for Transportation Systems and infrastructure (FhG-IVI) and the Swiss Federal Institute of Technology’s Institute for Transportation Planning and Systems (Nash, Huerlimann, Schütte, & Krauss, 2004), and is currently coordinated by a small independent team. railML.org conferences are held twice a year and supplemented by specialized working group meetings (railML.org, 2012). At time of writing the officially published version of railML is 2.2, with version 3 under development (see the following Table).

Sub-schema 0.x 2002 1.0 2005 1.1 2007 2.0 2009 2.2 2013 3.x 2015

Interlocking Elements Ready for added daily use

Infrastructure/ First test, Elements Total re- use cases added or- microscopic ganisation

Infrastructure/ First test, Ready for Small Elements Total re- use cases daily use changes added or- macroscopic ganisation

Rolling stock First test, Ready for Elements Small Elements Small use cases daily use added changes added changes

Timetable First test, Ready for Elements Total re- Elements Small use cases daily use added or- added changes ganisation

IFG-WP3-D-UIC-015-02 Page 106 of 153 12/12/2018

Contract No. H2020 – 730844

railML is published as a series of XML schemas holding sub-schemas, each of which encompasses a particular field of railway application:

 Common concepts and objects, sometimes not mentioned separately;

 Timetable (TT);

 Rolling stock (RS);

 Infrastructure (IS), both macroscopic and microscopic;

 Interlocking, from railML 3 on.

The current release of the data model (railML 2.2) focuses on information that has proven value in the railway operation planning process, but provides extension points for other topics or data of special interest.

COMMON SCHEMA

The common schema allows the definition of metadata using the well-known Dublin Core vocabulary, e.g. information about the application, which generated the data set. Furthermore author, date, identifier, and ‘other’ miscellaneous information may be given.

TIMETABLE (TT) AND ROSTERING SCHEMA

The timetable and rostering schema supports various operational concepts, amongst others the coupling of trains. The rolling stock for a timetable has to be defined in the RS schema. All levels of granularity are supported by the same TT concept, allowing at minimum a name for the train material as well as defining a detailed combination of locomotives and wagons with track effort curves and seat places. This enables both passenger and freight transport services to be defined according to the same schema.

Time restrictions may be defined in a flexible way enabling both fixed and on-demand services. Cascading restrictions allow for general time periods for the whole timetable, further constrained at regular service level. Pre-defining holiday periods enables flexible pre- and post-holiday services that are required by freight trains engaged in multi-day journeys via closed terminals on those special days.

Figure 13 shows an excerpt of a railML file with holiday and operating period settings for a schedule.

The TT schema is based on a railway infrastructure defined within the IS schema. At minimum operational points have to be provided, e.g. declaring its name. If more information is available, lines with mileages link those operational points. At the most detailed level, a fine-grained microscopic track network at switch level is offered. All those usage models are supported by the same timetable concept containing placeholders for detailed IS references if they are available.

IFG-WP3-D-UIC-015-02 Page 107 of 153 12/12/2018

Contract No. H2020 – 730844

Figure 17 railML file – example “operating period” (Excerpt)

INFRASTRUCTURE (IS) SCHEMA

The infrastructure schema defines properties and structures for railway facilities. Key concepts are:

 Network topology with operational points and lines (‘macroscopic’ graph in railML);

 Track topology with switches, crossings and track sections (‘microscopic’ node and edge);

 Operation and control elements, such as signal, balise, axle counter, level crossing;

 Civil engineering structure, e.g. bridges, tunnels;

 Track capability in form of ‘change point’, e.g. line speeds, gradients, presence and kind of electrification;

 Further concepts to model infrastructure visualisation at simulator software.

RailML 2.2 is intended to define macroscopic graphs the same way as microscopic nodes and edges. This concept built a robust foundation for a long time, where an infrastructure model is exchanged along with an appropriate timetable.

Since railway asset management moves into the focus of railML infrastructure development, the approach had to be changed in order to save both microscopic and macroscopic infrastructure data tightly coupled within one file. This movement is based on the platform-independent UIC

IFG-WP3-D-UIC-015-02 Page 108 of 153 12/12/2018

Contract No. H2020 – 730844

RailTopoModel and leads to railML 3 in form of XSDs for real XML file exchange. Final railML 3 is not available so far, but its mockup schemas seam already promising.

ROLLING STOCK (RS) SCHEMA

The rolling stock schema allows the representation of locomotives, multiple units, and passenger and freight wagons at various levels of detail. Factors such as propulsion type, braking ability, and mechanical traction losses can also be captured along with many other attributes allowing trains to be physically modelled in great detail.

As a basic concept, each rolling stock unit that may be coupled outside of a workshop is defined as a single ‘vehicle’ or as instance of a vehicle family. A composition of ‘vehicles’ is called a ‘formation’ – best known as a ‘train’. But in the railML context a ‘train’ is used for the timetabling perspective. The ‘formation’ is referred from within the timetable for each ‘train’.

4.3.3.1 Full Service Model (FSM) Regulation/Standard/Convention Mode Geographic Applicability

FSM Rail/Multimodal Europe and Global http://www.cer.be/full-service-model- fsm

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Scope and Stakeholders The FSM Initiative is an IT-Framework developed by ticket vendors and railways to facilitate online distribution services. The goal of the FSM (Full Service Model) initiative is to ease online services distribution in order to guarantee the benefit of the travelers. In detail the initiative can contribute to the innovative definition of door-to-door travel solutions. With this particular scope, ticket vendors and railways have realized an Open-IT-framework (taking into consideration IT specifications) that can be embedded in already existing IT-systems of distribution. When implemented, FSM can work as an adapter and enable data sharing between different distribution systems.

Through the FSM, ticket vendors and railways have the final scope to complete the different array of individual bilateral solutions needed to finally realize the connection between distribution systems. FSM interests the entire value chain of distribution services taking into consideration the after sales processes. It covers all businesses offering travel services and the travel distribution services.

IFG-WP3-D-UIC-015-02 Page 109 of 153 12/12/2018

Contract No. H2020 – 730844

In particular FSM Initiative has realized an API (Application Programming Interface) that permits Distributors and Rail Service Providers (RSPs) to make us of the common Sales and After-Sales interactions. RSPs may be rail carriers or firms that are not specifically carriers but offer to the market IT services for carriers

FSM APIs is designed to work with the already existing systems realized by Distributors and RSPs. The FSM API will not need to substitute the implemented APIs, that RSPs are able to provide to Distributors, especially if the on-going APIs have functions that are outside the scope of FSM. RSPs and Distributors could opt the utilization of a ‘hybrid’ model, where the FSM API is used for specific elements of the distribution process and existing proprietary APIs are taken into consideration for other aspects.

Impacts and Considerations for the Governance of the IF Assets GoF4R must consider the FSM process when developing its own rules for Change Management and validation.

4.3.3.2 RailTopoModel - Railway infrastructure topological model (RTM) Regulation/Standard/Convention Mode Geographic Applicability

RTM Rail Global

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Scope and Stakeholders The aim of RailTopoModel is to offer a global graphical description of railway networks and related events to support and ease the development of several business activities directly related to the rail sector. Firstly, its goal is to guarantee that this particular model will provide in the present and in the near future a relevant help to the business necessities. To obtain this result the model will need to take into consideration the following aspects:  The model provides a topological description of the iron connections that are completely linked and can be showed with a scheme. It provides the display of track locations considering the whole array of level detail, from corridors down to tracks  The model guarantees that data will be aggregated and disaggregated, while operating connections between detail “scales”, the scope is to finally obtain that data consistency is maintained across all scales  The model ensures that all the permitted routes are identified, based on network topology and other available info, for example events (such as track possessions), power supply basic elements, signalling assets

IFG-WP3-D-UIC-015-02 Page 110 of 153 12/12/2018

Contract No. H2020 – 730844

 The model provides a multiple referencing system in order to ensure consistency during the transformation between two referencing systems. Relevant cases of implementation are the following: o Linear referencing-using mileposts and “rail addresses” o positioning-using geographic reference systems o Scheme coordinates  The model organises and geographically locates “point”, “linear” and “areal entities” This model is structured with the idea to be updated with new elements to assist business uses as they will be developed.

Impacts and Considerations for the Governance of the IF Assets

GoF4R must consider the RailTopoModel process when developing its own rules for Change Management and validation.

4.3.3.3 Open Travel Alliance (OTA) Regulation/Standard/Convention Mode Geographic Applicability

OTA Multimodal Global

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Scope and Stakeholders The Open Travel Alliance (OTA) is a self-funded, non-profit organization that includes most of the major airlines, car rental companies, hoteliers, suppliers of leisure, travel agencies, GDSs, technology providers, and other parties that work on the creation and implementation of broad industry and open specifications of e-business. OTA mission is to engineer specifications for solving the problems inherent with connecting multiple systems within the complex travel distribution arena. Its activity comprehends the creation of electronic message structures to facilitate communication between the disparate systems in the global travel industry. These specifications generate a shared e-business language and are intended to push on the development of systems that can create innovative collections of services to meet in a better way the requests and specific expectations of travellers and the travel sector at large.

Impacts and Considerations for the Governance of the IF Assets

GoF4R must consider the OTA process when developing its own rules for Change Management and validation.

IFG-WP3-D-UIC-015-02 Page 111 of 153 12/12/2018

Contract No. H2020 – 730844

Regulation/Standard/Convention Mode Geographic Applicability

CEN/TS 17118:2017 Multimodal Europe

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Scope and Stakeholders This Technical Specification, developed by TC 278 (Intelligent transport systems) WG 3 (Public transport), defines a schema for establishing an Open API for Distributed Journey Planning (OJP) 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.

Schema XSD files are available to facilitate work by those wishing to implement the standard described in the published Technical Specification.

The OJP initiative was born to answer the exigence to exchange accurate and timely information about public transport (PT) services and to implement systems able to provide Multi-modal information for longer-distance journeys.

Several systems have been developed to answer to this requirement, based on different architecture, but he nature of the enquiries sent between the systems, and the content of the responses sent in return, were essentially the same. This suggested that it would be possible to define a single Open Journey Planning API to support all distributed journey planning systems.

OJP allows a system to engineer just one interface that it can make available rather than having to engineer separate APIs for each bipartite exchange arrangement that may be required with other systems.

The establishment of Open APIs has been enabled by an increasingly standardised Public Transport sector, applying the principles set out in the “Public Transport Reference Data Model” (Transmodel) EN standard, and its related implementation Standards and specifications.

Impacts and Considerations for the Governance of the IF Assets

The ITS Directive Delegated Regulation for provision of EU-wide multimodal travel information services, discussed in chapter 4.3, is the legal framework for travel data access and distributed journey planning in Europe. This initiative provides the necessary requirements to make EU-wide multimodal travel information services accurate and available across borders. One of the key requirements concerns linking travel information services for distributed journey planning. Upon

IFG-WP3-D-UIC-015-02 Page 112 of 153 12/12/2018

Contract No. H2020 – 730844

request, travel information service providers shall provide to another information service provider ‘routing results’ based on static, and where possible, dynamic information. The ‘routing results’ shall be based on:

 the enquirers start and end points of a journey along with the specific time and date of departure or arrival, or both;  possible travel options along with the specific time and date of departure or arrival, or both, including any possible connections;  the handover points between travel information services;  in case of disturbances, alternative possible travel options along with the specific time and date of departure or arrival, or both, and any connections, where available.

The Delegated Regulation recommends that the CEN OPEN API standard for distributed journey planning is used by local, regional and national travel information service providers.

This Standard must be considered for the IF Governance and the associated Schema(s) data shall be published in the Asset Manager. The change management processes of the standard shall be considered so that the published data are synchronised. Furthermore, any datasets published shall be in the correct format.

4.3.3.5 UIC 918 Regulation/Standard/Convention Mode Geographic Applicability

UIC Leaflet 918 (Suite) Rail Global

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Scope and Stakeholders UIC Leaflet 918-0 contains the general regulations for the electronic reservation of seats/berths and the electronic production of travel documents. It is supplemented by the following two leaflets:

 UIC Leaflet 918-1 which deals with the procedures for exchanging reservation messages,  UIC Leaflet 918-2 which describes the RCT2 standard applicable to all the transport documents produced electronically

IFG-WP3-D-UIC-015-02 Page 113 of 153 12/12/2018

Contract No. H2020 – 730844

The specifications contained in these leaflets enable a railway undertaking (RU) to reserve seats/berths in an inventory which is managed by another RU and to issue travel documents (in particular, reservation tickets and combined tickets) produced electronically from data transmitted by the electronic system of another RU.

The set of UIC 918 Leaflets is widely used throughout the European railway industry and by third parties who are in the distribution chain. These leaflets, which define industry-adopted coding structures and data exchange formats, provide the interoperability basis for data exchange as defined the TAP-TSI. The content of these leaflets, therefore, are also contained in the ERA technical documents as described in the previous chapter Telematics Applications Passenger (TAP-TSI).

Impacts and Considerations for the Governance of the IF Assets

WP5 has adopted a use case for the IF Governance concerning the semantic transformation of reservation request/response messages between systems utilising different standards. This particular use case considers the translation of messaging between the FSM formats used by the multimodal travel industry and the UIC 918 formats used by the European railway community. It is evident that FSM has completely different semantics from UIC 918, but their interconnection is essential to allow some railways/ticket vendors to start using FSM without losing the ability of exchanging reservations with those still using UIC 918.

In most cases there is no one-to-one correspondence between a message in UIC 918 specification and a message in FSM. For instance, one single FSM message can request a booking for a journey of two segments, i.e. on two consecutive trains, and this should necessarily be converted in two UIC 918 reservation messages, one per each train. On the reverse side, one UIC 918 reservation request completes the sales transaction, while the FSM workflow, even in the simple case of direct booking, requires at least the two steps of pre-booking and confirmed booking.

If one wants to build a system capable of interconnecting a partner “speaking FSM” with a partner “speaking UIC 918”, it needs something much more complex than a simple message converter, it needs a logic (therefore lines of code) capable of knowing both workflow rules, storing messages, creating intermediate messages and completing the transaction on basis of intermediate answers.

The analysis of the governance of the IF that GoF4R will perform should therefore consider the problem of knowing both UIC 918 and FSM workflow rules.

This use case will aid WP5 in determining the proper rules and processes to apply to the following IF Assets, based on a real-world example:  Reference Ontology: by identifying Change Management procedures that will include the semantic references for the UIC 918 and FSM standards  UIC 918 and FSM XSD Schemas: by developing procedures and rules for publishing and maintaining the current schemas and mappings  Lookup and Master Data (e.g., dataset containing country codes used in UIC 918 messages): by developing procedures and rules for publishing and maintaining the Master Data  UIC 918 and FSM workflow rules: by applying the Business Rules and Processes contained in the 918 Potential barriers of use may concern IPR.

IFG-WP3-D-UIC-015-02 Page 114 of 153 12/12/2018

Contract No. H2020 – 730844

RELEVANT STANDARD AND SPECIFICATIONS IN THE PUBLIC TRANSPORT

The public sector has already widely adopted the use of open interfaces and common data structures for providing and building passenger information systems. There are still many local and proprietary implementations, but those are all based on commonly known open data formats and structures. The trend seems to be that the cities have locally developed their own systems and are now gradually moving to unified nationwide systems.

Public Transport includes by itself several transport means (busses, trams, light rail, etc.), sometimes managed by different operators, and therefore is intrinsically oriented to a multi-modal approach, in order to provide a better service to citizens.

The relevant regulatory framework is consequently common to other modes as well, as it is described in chapter 6.

Most relevant documents are hereinafter listed:

 Directive on Intelligent Transportation Systems (see 6.2.1.3)

 Commission Delegated Regulation (EU) No 886/2013 (see 6.2.1.4)

 Commission Implementing Decision (EU) No 2016/209 (see 6.2.1.6)

 GDPR - REGULATION (EU) 2016/679 (see 6.2.2.2)

CEN/EN 12896 – TRANSMODEL Regulation/Standard/Convention Mode Geographic Applicability

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

This standard produced by CEN/TC 278 defines the Public Transport Reference Data Model based on:

IFG-WP3-D-UIC-015-02 Page 115 of 153 12/12/2018

Contract No. H2020 – 730844

- the Public Transport Reference Data Model published 2006 as EN12896 and known as Transmodel v5.1, updated and modularised in 2016 as Transmodel v6.0 Part 1 to 3, about data structure (reference to be used e.g. in selling points when used in back-office)

- the model for the Identification (of location) of Fixed Objects for Public transport, published 2009 as EN 28701 and known as IFOPT, which has been later repealed and replaced by Transmodel v6.0 – Part 2 (Public Transport Network)

- incorporating the requirements of

o EN15531-1 to 3 and TS15531-4 and 5: Service interface for Real-time Information relating to public transport operations (SIRI),

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

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

o Driver Scheduling (day-type related driver schedules),

o Rostering (ordering of driver duties into sequences according to some chosen methods),

o Driving Personnel Disposition (assignment of logical drivers to physical drivers and recording of driver performance).

IFG-WP3-D-UIC-015-02 Page 116 of 153 12/12/2018

Contract No. H2020 – 730844

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.

Transmodel v5.1 concerns mainly the needs of urban bus, trolleybus, tramway and light rail, a lot of aspects of the metro.

Transmodel v6 extends the data model to take into account heavy rail requirements.

The Transmodel – Part 2 (Public Transport Network) (the former IFOPT - Identification of Fixed Objects in Public Transport) defines a model and identification principles for the main fixed objects related to public access to Public Transport (e.g. stop points, stop areas, stations, connection links, entrances, etc.), in particular:

- to identify the relevant functions which need a unique identification of fixed objects especially for the Passenger Information domain in a multi-modal, multi-operator context;

- to identify the main fixed objects related to the Public Transport system, choosing a certain viewpoint, i.e. considering a certain level of detail ("granularity") of the given description taking into account the needs of the identified functions;

- to give a typology of these objects together with definitions;

- to present relationships between the identified Public Transport objects;

- to unambiguously describe these objects through their main properties (attributes);

- to describe how to locate these objects in space through coordinates and through the link to topographic objects with a clear separation between the "Public Transport layer" and the "topographic layer" described in its turn by geographic objects;

- to enable the assignment of data administration (responsibility for data maintenance) of each fixed object.

IFG-WP3-D-UIC-015-02 Page 117 of 153 12/12/2018

Contract No. H2020 – 730844

Geospatial location referencing techniques of PT objects (e.g. use of satellites, roadside equipment for positioning) or representation techniques on maps (projections) are outside the scope of this standard.

CEN/TS 16614- SIRI Regulation/Standard/Convention Mode Geographic Applicability

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

This CEN Technical Specification deals with Public transport - Network and Timetable Exchange (NeTEx). NeTEx is dedicated to the exchange of scheduled data (network, timetable and fare information) and therefore is using XML. It is based on Transmodel V5.1 (EN 12896), IFOPT (EN 28701) and SIRI (CEN/TS 15531-4, CEN/TS 15531-5 and EN 15531-1, EN 15531-2, EN 15531-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).

As regards functional domains, NeTEx covers only a subset of Transmodel; the Network Topology, Timing Information, Vehicle Scheduling and Fare Information domains, whereas the full scope of Transmodel is broader, including in addition: Operations Monitoring and Control, Fare Management (sales, validation, control), Management Information and Statistics, Driver Management, Driver Scheduling, Rostering, and Driving Personnel Disposition. 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.

NeTEx specification is divided into three parts. Part 1 describes the fixed Network (stops, routes, lines, etc.); Part 2 is mainly focused on Timetables and Part 3 covers Fare data.

NeTEx deliverables comprise (i) a CEN Specification document, (ii) a data model in the standard UML modelling language and (iii) an accompanying XML schema providing a formal electronic description that can be used by data processing software.

IFG-WP3-D-UIC-015-02 Page 118 of 153 12/12/2018

Contract No. H2020 – 730844

Whereas TAP/TSI uses optimized flat files that aggregate different fare conditions and prices into a small number of records with dense semantics, NeTEx uses a parameterized approach, with discrete atomic elements that may be combined in many different ways and a ready-made library of almost all known fare conditions. This gives a high level of reuse, and richer semantics, that is, the ability to capture more complex conditions and additional types of fare - but requires a greater effort to understand in the first place.

As mentioned, NeTEx is primarily dedicated to data exchange, i.e. an XML message format and a protocol are specified. The content model of the NeTEx message structure is based upon the NeTEx physical data model and is derived directly from Transmodel, the CEN Public Transport Reference Data Model developed at a conceptual level and independent of an implementation in any specific technology (http://transmodel-cen.eu/).

The overall approach for the definition of fares within NeTEx Part 3 follows the approach used by Transmodel V5.1, namely the definition of access rights rather than of just products. This approach, used in Transmodel V5.1 (Fare Collection data model) to specify the access rights related to the urban public transport (for all urban modes) has been extended to cover access rights for long- distance rail.

NeTEx will facilitate interoperability between IT systems of involved PT parties by:

 Introducing common architectures for message exchange;  Introducing a modular set of compatible services for real-time vehicle information;  Using common data models and schemas for the messages exchanged for each service;  Introducing a consistent approach to data management.

Figure 18NeTEx Parts

IFG-WP3-D-UIC-015-02 Page 119 of 153 12/12/2018

Contract No. H2020 – 730844

NeTEx Part 1 NeTEx Part 1 (ref: Representing Public Transport Networks in NeTEx- white paper – available at: http://netex-cen.eu/wp-content/uploads/2015/12/06.NeTEx-Network-WhitePaper_1.08.pdf). The main linear patterns used to define the spatial structure of a Public Transport Network are: ROUTE, JOURNEY PATTERN, TIMING PATTERN and SERVICE PATTERN.  A ROUTE is an ordered list of located ROUTE POINTs defining one single path through the road (or rail) network. A ROUTE may pass through the same ROUTE POINT more than once. ROUTE LINKs may be used to specify attributes of a link.  A JOURNEY PATTERN is defined as an ordered list of SCHEDULED STOP POINTs (i.e. points where passengers can board or alight from vehicles) and TIMING POINTs (i.e. points against which the timing information necessary to build schedules may be recorded) on a single ROUTE, describing the pattern of working for public transport vehicles. A JOURNEY PATTERN may pass through the same point more than once. Again links (SERVICE LINKS, TIMING LINKS etc.) can be used to provide a link based representation if needed.  The sequence of TIMING POINTs of a JOURNEY PATTERN determines a TIMING PATTERN and the sequence of SCHEDULED STOP POINTs (of a JOURNEY PATTERN) determines a SERVICE PATTERN

NeTEx Part 2 NeTEx Part 2 (ref: Representing Timetables in NeTEx- white paper – available at: http://netex- cen.eu/wp-content/uploads/2015/12/09.NeTEx-Timetable-WhitePaper_1.05.pdf) covers conventional representation for the core timetable, corresponding to that found in various national standards:

 A simple timetable is made up of one or more SERVICE JOURNEYs; each journey describing a scheduled journey departing at a specific time. A journey is made up of two or more CALLs, each describing arrival and or departure times at a SCHEDULED STOP POINT in sequence, along with any other information relating to a visit to a particular stop, such as notices, platforms, display headings, accessibility of the service, etc. Validity conditions as to when a particular journey runs are normally specified in terms of DAY TYPEs types which can be separately resolved to an actual calendar date.  The journeys are grouped explicitly in a TIMETABLE FRAME, which sets global validity conditions and other defaults for all SERVICE JOURNEYs in the timetable. The frame provides a container to hold the journeys and other timetable related elements for exchange. Timetable frames can themselves be grouped in a COMPOSITE FRAME with other types of frame, for example SERVICE FRAMEs (with stop and route details), SERVICE CALENDAR FRAME (with DAY TYPEs and OPERATING DAYs) and/or FARE FRAMEs (with price details) in order to create complete and coherent self-contained data sets. DAY TYPE is used to specify the days on which a given service runs; the temporal constraints on the DAY TYPE can be specified by VALIDITY CONDITIONs that specify the day of week, holiday operation, etc.

NeTEx has many additional features to represent additional aspects of timetables that are found in different circumstances:

IFG-WP3-D-UIC-015-02 Page 120 of 153 12/12/2018

Contract No. H2020 – 730844

 To represent frequency based services; an additional types of service journey, the TEMPLATE SERVICE JOURNEY, is provided. The frequency may be specified either as an interval such as “every five to ten minutes’” (using a HEADWAY JOURNEY GROUP) or as a regular “clock-faced” e.g. “at 05, 25 and 45 minutes past the hour” (using a RHYTHMICAL JOURNEY GROUP). Use of a separate template component clarifies the distinction between the operational view of the timetable (which still involves individual SERVICE JOURNEYs running at specific times in operational blocks) from the passenger view, which is condensed down to a single entry with a frequency.  PT services will often be planned so as to connect with other services, and information on these connections may be included in passenger information using the SERVICE JOURNEY INTERCHANGE element. The representation can describe interchange times and whether a connection is advertised, guaranteed (i.e. will wait a certain time) and other operational constraints. Additional complex conditions about managing journey interchanges can be specified with INTERCHANGE RULEs.  Long distance rail may involve vehicle journeys that join or split; this can be modelled by the additional use of JOURNEY PART elements, to represent each segment of the journey which can be combined as JOURNEY PART COUPLEs to indicate a joined segment of the journey. TRAIN & COMPOUND TRAIN ELEMENTS can be used to describe the corresponding train makeup implications (i.e. which carriages go where) so that meaningful passenger information can be provided. The TRAIN NUMBER element allows the correct public identifier used for each journey to be provided, despite any intricacies of joining or splitting or international operation.

The operation of modern PT networks typically involves the use of computer based systems to plan and optimize the provision of services. Planning systems represent (and may need to change) not just the timetable element but also the various elements from which the timetable is built. NeTEx allows such data to be exchanged, as well as the resulting timetables. The relationship of such elements to the timetable are:

 The central timetable element is the VEHICLE JOURNEY (a generalization of SERVICE JOURNEY), which is a combination of a number of different tactical components: (a) the ROUTE and related JOURNEY PATTERN and SERVICE PATTERN, which dictate the route and sequence of stops (POINTs IN SEQUENCE) to be followed; (b) the TIMING PATTERN, and JOURNEY TIMINGs, which give the timing points and times needed to cover each link of the journey, and (c) the TIME DEMAND TYPE, which specifies the part of day that the journey is taking place, e.g. ‘weekday’, ‘rush hour’, etc. and so which set of timings should be used. Thus given a starting time and a SERVICE PATTERN it is possible to integrate information from the other components and automatically compute a sequence of CALLs with PASSING TIMES at each stop.  The planning of services may also involve the optimisation of groups of journeys in driver and vehicle scheduling systems, to create work periods for each VEHICLE TYPE. Such periods are described as BLOCKs, worked from a PARKING POINT to another, composed of sets of VEHICLE JOURNEYs. BLOCKs may be coupled (building COMPOUND BLOCKs, representing the work of a vehicle during the time it is coupled to another vehicle) or separated for a while, building BLOCK PARTs, i.e. the parts of a BLOCK corresponding to the different JOURNEY PARTs of the VEHICLE JOURNEYs in a BLOCK.

IFG-WP3-D-UIC-015-02 Page 121 of 153 12/12/2018

Contract No. H2020 – 730844

 A DEAD RUN is another type of VEHICLE JOURNEY, an out of service journey that send out vehicles and retrieve them back to their depots, these may be included to support operational and real-time systems.

Figure22 shows a simple bus timetable for a linear route modelled in NeTEx. The example originates from a national PT database in Slovenia.

 The timetable includes two ROUTES (outbound – “Briga to Nova sela” and inbound – “Nova sela to Briga”) belonging to one LINE (id=K66, “Kočevje – Petrina”) with transport MODE “bus”.  The timetable includes three stop points (SCHEDULED STOP POINTs) (Briga, Banja Loka and Nova sela) in each DIRECTION (i.e. Briga smer Petrina, Briga smer Kočevje).  The timetable aggregates two SERVICE JOURNEYs (i.e. specific passenger carrying VEHICLE JOURNEYs), each following its own SERVICE PATTERN (boarding/alighting status). Each SERVICE PATTERN refers to a SERVICE JOURNEY PATTERN to derive the exact order of nodes, i.e. SCHEDULED STOP POINTS for its ROUTE; this is reflected in the timetable as the sequence of CALLs.  Each SERVICE JOURNEY also refers to a TIME DEMAND TYPE, which defines a set of vehicle running times for links between stop points for a given TIMEBAND and DAY TYPE. The given TIME DEMAND TYPE is used to calculate the planned vehicle arrival and departure times for each SCHEDULED STOP POINT at the given time of day; the result is included in the CALLs.  A reference to DAY TYPE, which has property values “Everyday” and “AnyHoliday”, defines operating days for the timetable.NeTEx Part 3

IFG-WP3-D-UIC-015-02 Page 122 of 153 12/12/2018

Contract No. H2020 – 730844

Figure 19 An example of a simple bus timetable for a linear route modelled in NeTEx

IFG-WP3-D-UIC-015-02 Page 123 of 153 12/12/2018

Contract No. H2020 – 730844

NeTEx Part 3 NeTEx Part 3 (ref: Representing Fares in NeTEx- white paper – available at: http://netex-cen.eu/wp- content/uploads/2015/12/10.NeTEx-Fare-WhitePaper_1.04.pdf ) is concerned with data for the following purposes:

1) To describe the many and 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.). 2) To describe the fare products that may be purchased having these fare structures and to describe the conditions that may be attached to particular fares, for example if restricted to specific groups of users, or subject to temporal restrictions. These conditions may be complex. 3) To allow actual fare 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 however to exchange various parameters required for pricing calculations that are needed to explain or justify a fare, and each price may indicate their derivation from another price using a named method. 4) To include the attributes and the text descriptions necessary to present fares and their conditions of sale and use to the public. The conditions are in a machine readable form that an application program may utilize.

NeTEx covers only certain of the “upstream” processes of fare management sufficient to provide passenger information on fares; it is not concerned with reservation and ticketing processes. Fares range from the extremely simple – say a simple flat fare for anyone for the whole network, to the excruciatingly complex; for example, ones that depend on the route taken, time of travel, length of travel, the type and number of users, time of purchase, method of purchase, amount of other travel made in a given period, and payment method. NeTEx can describe even very complex fares, using a uniform set of elements applicable to any mode of transport. The essence of the NeTEx approach is to break the description of fares down into a number of separate, reusable elements, which can be combined flexibly to create a huge range of different fares.

The Relation of NeTEx to GTFS Google’s General Transport Feed Specification (GTFS) [G1] is a widely used format for distributing timetables to third parties. The NeTEx and GTFS formats should be considered as complementary, covering different stages in the data management process, and different workflows: NeTEx is “upstream”, GTFS is “downstream”. NeTEx differs from GTFS in that it has a much wider scope, and that it is intended for use in multi-sourced back office use cases under which data is generated, refined and integrated (requiring the exchange of additional elements used to construct the timetable), rather than just for provisioning journey planning systems (the prime purpose of GTFS).

GTFS covers stops, lines, and timetabled journey information (Gtf trips) sufficient to answer basic journey planning queries. It supports only a few simple types of fare product. GTFS data identifiers are specific to each data set and require registration of an identifier with Google.

IFG-WP3-D-UIC-015-02 Page 124 of 153 12/12/2018

Contract No. H2020 – 730844

As well has having a much richer fare model, sufficient to cover complex urban and rail products, NeTEx covers many other aspects of Public Transport Information apart from timetables (e.g. network descriptions, interchanges etc.) as well as supporting a richer timetable model for export, one that can include journey patterns, timing patterns, joined journeys, train makeup, connection timings, etc. This makes it able to exchange the component data sets used to build timetables and other operational data sets as well as the resulting timetables themselves. NeTEx includes the additional information needed to provision real-time systems (such as destination displays) and to link to operational systems (such as blocks). It also includes versioning and validity condition mechanisms to support the repeated peer-to peer integration of many data from many different parties. Because it uses XML, NeTEx is able to package a complete data set as a single coherent document that can be managed and validated.

GTFS uses a traditional flat file format; this is compact and efficient but requires multiple files to describe the different types of element and thus additional rules for naming and packaging the files as a zip. Custom written tools are needed to interpret and process the data.

It is possible to generate a full GTFS data set from NeTEx but not vice versa. The NeTEx UML includes a GTFS mapping package which shows how each GTFS element may be populated from the corresponding NeTEx element.

EN 13149 series This CEN standard addresses Public transport - Road vehicle scheduling and control systems. It has been developed by TC 278: Intelligent Transport Systems. The following parts have been published so far:

Part 1: WORLDFIP definition and application rules for onboard data transmission

Part 2: WORLDFIP cabling specifications

Part 3: WorldFIP message content

Part 4: General application rules for CANopen transmission buses

Part 5: CANopen cabling specifications

Part 6: CAN message content

Part 7: Network and System Architecture

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

IFG-WP3-D-UIC-015-02 Page 125 of 153 12/12/2018

Contract No. H2020 – 730844

Part 8: Physical layer for IP communication

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 8 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. 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. Based on open technology, it gives the possibility to operators and organizing authorities to use public transport data anywhere in Europe through common mechanisms, standard rules and protocols.

Part 9: Services Specifications (not published)

Part 9 of the 13149 series specifies in detail the profiles of basic, generic and specific Services. Part 9 specifies the services based on the in part 7 defined SOA and enhances an interoperable communication system on PT vehicles. It can be especially relevant to the GoF4R project. It specifies in detail the Profiles of basic and generic Services as well as profiles of specific Services.

Potential references for GoF4R and IF Governance

ITxPT Association

The IT architecture developed in the European Bus System of the Future (EBSF) project has paved the way to cost effective deployment of digital systems on board public transport vehicles

The standard is a pillar of the ITxPT Association, which has been set up by its Founding Members together with UITP, the International Association for Public Transport, following their agreement to further cooperate on the implementation of a working standard for plug-and-play IT-systems applied to public transport. An integrated test-bench offers services to specify, test, qualify and showcase IT solutions.

The mission of the ITxPT Association is to support the deployment of standards and practices for onboard plug-and-play IT-systems for public transport and the relevant back-office features. The ITxPT Initiative leads a joint effort to feed, support, promote and contribute to the evolution of the standard TS13149 parts 7/8/9. It works closely with the CEN/CENELEC standardization groups like CEN/TC278/WG3 by providing returns of experiences from technical implementations from the field deployments.

The IT architecture for Public Transport specifications has been established to provide PT operators and PT authorities recommendations and requirements to implement an open and fully interoperable IT systems architecture for PT applications. ITxPT defines the interoperability of onboard IT systems on 3 levels:

IFG-WP3-D-UIC-015-02 Page 126 of 153 12/12/2018

Contract No. H2020 – 730844

 Hardware level: installation rules, connectors, etc. (ref TS13149-8)  Communication protocol level: interface between systems, modules, declaration of service, etc. (ref TS13149-7)  Service level: list of services, format of the service, format of data etc. (best practices/recommendations, next work item) (ref TS13149-9) ITxPT recommends the use of back-office IT systems compliant with related standards:

 SIRI: Service Interface for Real Time Information, for exchanging real-time information about public transport services and vehicles  NeTEx: Network Exchange, for exchanging Public Transport schedules and related data The Technical Specifications in the 13149 series provide rules for data communication systems on- board public transport vehicles. Part 8 together with part 7 and part 9 describes a complete solution parallel to, but independent of, parts 1-3 and part 4-6. Public Transport (PT) vehicles have an increasing array of information and communications systems, including ticket machines, Automated Vehicle Location (AVL) systems, destination displays, passenger announcement systems, vehicle monitoring systems etc. Other systems are beginning to be included such as advertising screens, tourist guides, Wi-Fi “hotspots” and infotainment. These systems may be provided by a number of different suppliers, and may need to be integrated. For instance a ticket machine may need location information to update fare stages; next-stop and destination information may be drawn from schedule information held in the ticket machine; and location systems may be used to drive signal priority requests. In addition, equipped PT vehicles will often have communications facilities to enable voice and/or data to be exchanged with the intermodal transport control system centre, other PT vehicles, PT infrastructure, and roadside devices (for instance in requesting priority at traffic signals). Many types of communication channel are used, including public and private wireless communication networks. Without a clear technology framework, integrating these systems would require complex technical discussions every time a device is procured. A large number of current and future communication networks will use the Internet Protocol (IP) as a core network technology. Existing parts of TS13149 are not consistent with an IP network and do not support the use of associated protocols. This makes it difficult for integrated on-board systems to use modern networks efficiently. If an IP approach is adopted, the PT vehicle begins to look like a local area network (LAN) of connected systems. In this context it is relevant to define a hardware network which makes use of IEEE 802 technologies – these are much the most widespread basis for IP LANs worldwide. The parts 7 to 9 will describe this adaptation. This will facilitate: - high quality intermodal passenger services based on intermodal PT information, - integration of new PT services, - lower cost, lower risks and a smoother onboard integration of PT equipment, - more efficient operation and maintenance of onboard PT equipment, and - more efficient development of PT components. 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 standardisation bodies. Interfaces to such equipment or safety-critical networks can be provided through dedicated gateways.

IFG-WP3-D-UIC-015-02 Page 127 of 153 12/12/2018

Contract No. H2020 – 730844

The ITxPT members are divided into three groups: strategic members, principal members and associated members.

The ITxPT Initiative Members will have access to the ITxPT platform to test their devices and applications in real operational conditions, supporting the uptake of this plug-and-play solution. By limiting the risks during the integration stage, these tests will facilitate the deployment process in operation.

The ITxPT Initiative Members cooperate with the purpose of:

 Support the ITS purchasers e.g. Public Transport Operators and Public Transport Authorities with the necessary specifications in order to achieve certified Plug and Play functionality when they purchase IT-systems for Public Transport use  Share experience and best practices of the plug-and-play standard for public transport  Support the evolution of the working standard towards its adoption within international common mechanisms, standard rules and protocols  Maintain in operating conditions the test bench and implementing new evolutions and implementations  Specify, test, qualify and showcase IT solutions on the test bench  Cooperate in dedicated Working Groups and contribute to the Initiative's Members knowledge and expertise  Coordinate the Initiative's Members submissions to the standardization process  Provide a common strategy and implement policy actions on ITxPT issues

Figure 20ITxPT test bench As of 4 May 2016, Information Technology for Public Transport (ITxPT) has been officially incorporated by the Belgian Ministry of Justice as an AISBL (association internationale sans but lucratif, eng. international non-profit association) under Belgian law.

IFG-WP3-D-UIC-015-02 Page 128 of 153 12/12/2018

Contract No. H2020 – 730844

The bodies of the Association are:

- the Executive Board, which is the body in charge of the management of the Association - the General Assembly, which is the body in charge of the general direction of the Association - the Secretary General.

Figure 21 ITxPT governance The Executive Board grants a license to use the ITxPT label for commercializing an On Board Module if it complies with the standards developed by the Members of ITxPT.

The rules and compliance criteria underpinning the standards are regularly updated and made public by ITxPT through the official standardization bodies and / or other communication means like the ITxPT website.

The Executive Board selects an Exploitation Manager, which is an organization contracted by ITxPT to perform all operational and technical tasks related to the Compliance Service. The Exploitation Manager technically assesses the compliance with the standards on the Test & Integration Platform.

Figure 22 ITxPT Label In order to perform the technical work, ITxPT has established ten working groups made up by strategic and principal members. Working Groups are:

• WG#1 – Use cases • WG#2 – Tenders

IFG-WP3-D-UIC-015-02 Page 129 of 153 12/12/2018

Contract No. H2020 – 730844

• WG#3 – Validation of compliance for vehicles • WG#4 – Acceptance tests tools • WG#5 – FMS need collection • WG#6 – Additional protocols (MQTT and others) • WG#7 – Additional IP services • WG#8 – Security • WG#9 – Over the air protocol • WG#10 – SIRI/NeTEx – Transmodel Support Group

The overall activities and specifications development is governed by the Technical Committee, which is made up of representatives of the Executive Board.

Regulation/Standard/Convention Mode Geographic Applicability

Transmodel-CEN European Reference Public Europe Data Model for Public Transport Transport

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Transmodel has been developed for decades under the aegis of CEN (Comité Européen de Normalisation). The CEN Transmodel standard is a conceptual model which names and represents PT info concepts for a wide set of functional areas, and which can be used to compare and understand different models.

TRANSMODEL CONCEPTUAL MODEL Transmodel project outputs have previously been used both to underpin a number of CEN concrete data standards, such as CEN SIRI and CEN NeTEx, and also to rationalise national standards to allow for harmonisation and interoperability.

The following picture maps the Transmodel areas to the SIRI and NeTEx CEN standards.

IFG-WP3-D-UIC-015-02 Page 130 of 153 12/12/2018

Contract No. H2020 – 730844

Figure 23 Transmodel areas to the SIRI and NeTEx CEN standards

TRANSMODEL COMMON CONCEPTS Topological descriptions of the spatial structure of a public transport network are generally built with points. Thus, an entity POINT is defined as the most basic entity of the network model. A POINT represents a 0-dimension node of the network. It marks the location of bus stops, parking places or other types of POINTs.

Between two POINTs of any type, a LINK may be defined to store spatial information (e.g. the distance a vehicle will cover crossing this link). LINKs represent 1-dimensional connections between POINTs. There must be no LINKs without one limiting POINT at each end. Two relationships between the POINT and the LINK entity specify the limiting POINTs of a LINK. A LINK is oriented from its start POINT to its end POINT.

Transmodel makes it possible to represent the network either as a graph of points or of arcs.

An ordered set of POINTs or LINKs is called a LINK SEQUENCE. These are the generic building blocks of the Public Transport network model. Their specialisations represent concrete special Public Transport objects, like scheduled stop points, routes, service links, etc.

IFG-WP3-D-UIC-015-02 Page 131 of 153 12/12/2018

Contract No. H2020 – 730844

The LINK SEQUENCE Model defines a set of POINTs and/or LINKs making up a path through a network.

It allows a path to be described as a sequence of points, a sequence of links, or both; both views are relevant for different use cases. Specialisations of LINK SEQUENCEs are for example ROUTE, JOURNEY PATTERN, TIMING PATTERN etc. and represent concrete Public Transport paths (Point and Link Sequence Model).

Transmodel defines a generic GROUP OF ENTITIES as a set of ENTITies, grouped together according to a functional purpose (PURPOSE OF GROUPING).

A concrete example of a use of such grouping is a STOP AREA, that is a grouping of stops known to the public by a common name (Generic Grouping Model).

Other types of sets of entities than groupings are FRAMEs (Generic Version Frame Model) or LAYERs (Generic Layer Model).

A ZONE is a two-dimension object used in the network description (e.g. administrative area, tariff zone, flexible transport zone). ZONEs are classified according to a TYPE OF ZONE.

A ZONE may be defined by a GROUP OF POINTS belonging to the ZONE. For instance, a TARIFF ZONE used to define a zonal fare structure in a zone-counting or zone-matrix system may be composed of a set of stop points. A ZONE may also be defined as a geometric area, bordered by a LINK SEQUENCE (a polygon). In such a case, this LINK SEQUENCE has to be a closed one (i.e. the first and last POINTs IN LINK SEQUENCE must be a view of the same POINT). A ZONE may be recursive, and include other smaller ZONEs (Generic Zone Model).

A TYPE OF POINT is defined as an entity to describe common roles played by a number of POINTs. Each POINT is functionally classified as being of one or more types, according to the specific information needs of a particular functional domain. Certain TYPEs of POINTs are regarded as important enough to be additionally represented by a separate concept. The most important of these are: the SCHEDULED STOP POINT, TIMING POINT, ROUTE POINT.

Other explicitly defined types are specialisations of the TIMING POINT: RELIEF POINT, PARKING POINT, GARAGE POINT (Vehicle & Crew Point Model) or points specifically dedicated to operations control: TRAFFIC CONTROL POINT, ACTIVATION POINT, BEACON POINT (Activation Model).

It is often necessary to define a group of objects of different types in a simpler representation, omitting the details. For instance, a train station composed of tracks, platforms, vending machines, etc., or a depot composed of halls, parking areas, lanes, maintenance facilities, etc., are viewed in some layers as single POINTs. This is described by the entity COMPLEX FEATURE (named by analogy with the GDF standard and usual GIS wording). A COMPLEX FEATURE is composed of one or more SIMPLE FEATUREs. A SIMPLE FEATURE is identical to an instance of either a POINT, a LINK, or a ZONE.

IFG-WP3-D-UIC-015-02 Page 132 of 153 12/12/2018

Contract No. H2020 – 730844

A COMPLEX FEATURE usually combines elements of different kinds such as POINTs, LINKs, ZONEs (each of them not necessarily of the same type), and even other COMPLEX FEATUREs. It should not be mixed up with a group of elements (e.g. GROUP OF POINTS), combining elements of one single type only, for example one GROUP OF LINKs may be all LINKs in a tunnel, which is not a COMPLEX FEATURE (Generic Feature Model).

Topological ENTITIES used for describing a transport network can be grouped into different LAYERs. Each LAYER is associated with a one and only one LOCATING SYSTEM, and the entities belonging to the LAYER have a position within this LOCATING SYSTEM. Examples of layers include:

 Infrastructure layer: describes road or rail network.  Route layer: describes route topology.  Service layer: describes network of stops served by routes.  Timing layer: describes location of timing points and times between them.

(Generic Layer Model).

The accessibility of a site is described using an ACCESSIBILITY ASSESSMENT: this allows to express the accessibility either in terms of suitability for specific USER NEEDs – for example wheelchair, hearing impaired, vision impaired, lift-averse, etc. – using a SUITABILITY element, or in terms of ACCESSIBILITY LIMITATIONs, i.e. description of the limitations of a site to support a specific need, for example Wheelchair, Step free, Escalator free, Lift free or both.

A PLACE is defined as a geographic place of any type which may be specified as the origin or destination of a trip. A PLACE may be of dimension 0 (a POINT), 1 (a road section) or 2 (a ZONE).

The PLACE model defines topographically significant places that a transport model may wish to describe.

It also allows the description of the possibility of connecting between them. ACCESS indicates the physical (spatial) possibility for a passenger to access or leave the public transport system. This link may be used during a trip for:

 the walking movement of a passenger from a PLACE (origin of the trip) to a SCHEDULED STOP POINT (origin of the PT TRIP), or  the walking movement from a SCHEDULED STOP POINT (destination of the PT TRIP) to a PLACE (destination of the trip) (Generic Place Model).

Transmodel takes into account a variety of Public Transport MODEs (characterisation of the public transport operation according to the means of transport (bus, tram, metro, train, ferry, ship)). A distinction is made between VEHICLE MODE and ACCESS MODE. The concept of MODE is refined into SUBMODE, a variant of a MODE, as for instance international or domestic rail (rail being the MODE).

IFG-WP3-D-UIC-015-02 Page 133 of 153 12/12/2018

Contract No. H2020 – 730844

In Transmodel, a DAY TYPE is defined as a combination of various different properties a day may have, and which will influence the transport demand and the running conditions (e.g. traffic flow for buses).

Any single condition that is relevant to the demand will be recorded as a particular PROPERTY OF DAY. For example, “workday”, “Sunday”, “school holiday”, “market day” would each be a PROPERTY OF DAY. A workday during school holidays, which is a market day, would be a DAY TYPE, formed with the combination of those three PROPERTIES OF DAY.

The day of operation, considered from the point of view of the transportation process control, is described by the entity OPERATING DAY. The time limits of an OPERATING DAY will often deviate from the official date. One day of operation covers for instance the period from 2.00 a.m. to 1.59 a.m. the day after, the period from 0.00 to 1.59 on the second day being assigned to the operational day which started the day before.

The production planning requires that a DAY TYPE is assigned to each OPERATING DAY, which is frequently referred as a “transportation calendar” or – in The Conceptual Model – as a SERVICE CALENDAR

A TOPOGRAPHIC PLACE is a type of PLACE providing the topographical context when searching for or presenting travel information, for example as the origin or destination of a trip. It may be of any size (e.g. County,City, Town, Village) and of different specificity (e.g. Greater London, London, West End, Westminster, St James’s). A TOPOGRAPHIC PLACE may be located within one or more COUNTRies. TOPOGRAPHIC PLACEs may overlap. They may also be contained inside another TOPOGRAPHIC PLACE.

ADDRESS is the descriptive data associated with a PLACE that can be used to describe the unique geographical context of a PLACE for the purposes of identifying it. May be refined as either a ROAD ADDRESS, a POSTAL ADDRESS or both (Topographic Place Model).

Transmodel defines a generic concept EQUIPMENT that specialises into

 INSTALLED EQUIPMENT, an item of equipment either fixed (PLACE EQUIPMENT) or on board i.e. associated with vehicles (ACTUAL VEHICLE EQUIPMENT). PASSENGER EQUIPMENT may be either fixed or on-board. INSTALLED EQUIPMENT is materialised as opposed to a service (LOCAL SERVICE) considered as an immaterial equipment.  PLACE EQUIPMENT is described in a very detailed way through a range of concrete classes (cf. Part 2: Waiting & Luggage Equipment, Passenger Service Equipment, Ticketing Equipment, Access Equipment, Sign Equipment Models)

The VEHICLE entity is used to describe the physical public transport vehicles available for short- term planning of operations and daily assignment (in contrast to logical vehicles considered for resource planning). Each VEHICLE must be classified as of a particular VEHICLE TYPE.

The VEHICLE TYPE Model represents a description of VEHICLES through their properties.

IFG-WP3-D-UIC-015-02 Page 134 of 153 12/12/2018

Contract No. H2020 – 730844

TRANSMODEL and EU-Wide Multimodal Travel Information Services

The regulation (EU) 2017/1926 on the Provision of EU-Wide Multi-modal Travel Information Services adopted on 31/05/2017 is supplementing Directive 2010/40/EU with regard to the provision of EU- wide multimodal travel information services and complements the two previous Regulations.

The regulation establishes the specifications necessary to ensure the accessibility, exchange and update of static and dynamic transportation data for the provision of multimodal information services in the European Union.

The Regulation stipulates in its Article 3 on National Access Points:

- (Article 3.1) that “Each Member State shall set up a national access point. The national access point shall constitute a single point of access for users to at least the static travel and traffic data and historic traffic data of different transport modes, including data updates, as set out in Annex I, provided by the transport authorities, transport operators, infrastructure managers or transport on demand service providers within the territory of a given Member State.”

- (Article 3.4) that “Transport authorities, transport operators, infrastructure managers or transport on demand service providers shall ensure that they provide the metadata in order to allow users to discover and use the datasets made accessible through the national access points”.

In its Article 4 on Accessibility, exchange and re-use of static travel and traffic data, the Regulation makes reference to several specifications and standards that shall have to be applied:

- (Article 4.1): Transport authorities, transport operators, infrastructure managers or transport on demand service providers shall provide the static travel and traffic data and historic traffic data listed in point 1 of Annex I, of the different transport modes by using: d) for the road transport, the standards defined in Article 4 of Commission Delegated Regulation (EU) No 2015/962; e) for other transport modes, the following standards and technical specifications: NeTEx CEN/TS 16614 and subsequent versions, technical documents defined in Commission Regulation (EU) No 454/2011 and subsequent versions, technical documents elaborated by IATA or any machine-readable format fully compatible and interoperable with those standards and technical specifications; f) for the spatial network the requirements defined in Article 7 of Directive 2007/2/EU (INSPIRE Directive). - (Article 4.2): The relevant static travel and traffic data listed in point 1 of Annex I that are applicable to NeTEx and DATEX II shall be represented through minimum national profiles. - (Article 4.3): Transport authorities, transport operators, infrastructure managers or transport on demand service providers shall provide the static travel and traffic data through the national access point in the required formats in line with the following timetable: e) for the travel and traffic data set out in point 1.1 of Annex I96 for the comprehensive TEN-T network, by 1 December 2019 at the latest;

96 PART-2016-155167V2 Annex.

IFG-WP3-D-UIC-015-02 Page 135 of 153 12/12/2018

Contract No. H2020 – 730844

f) for the travel and traffic data set out in point 1.2 of Annex I for the comprehensive TEN-T network, by 1 December 2020 at the latest; g) for the travel and traffic data set out in point 1.3 of Annex I for the comprehensive TEN-T network, by 1 December 2021 at the latest; h) for the travel and traffic data set out in points 1.1, 1.2 and 1.3 of Annex I for the other parts of the Union transport network, by 1 December 2023 at the latest. - (Article 4.4): APIs that provide access to static travel and traffic data listed in Annex I via the national access point shall be publicly accessible allowing users and end-users to register to obtain access.

EN/TS 16406:2013 Regulation/Standard/Convention Mode Geographic Applicability

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

This CEN Technical Specifications deals with Intelligent transport systems - Public transport - Indirect Fulfilment for Rail.

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

The architecture shows only the link for the exchange of usage information between carrier, fulfilling equipment and checking equipment. For a more detailed description the standard refers only to the UIC leaflet 918-4. No additional information about how to implement these messages for the usage data exchange is given.

97 ERA Technical Document B5: Electronic reservation of seats/berths and electronic production of travel documents - exchange of messages, is an annex of the TAP TSI.

IFG-WP3-D-UIC-015-02 Page 136 of 153 12/12/2018

Contract No. H2020 – 730844

CEN/15331 series - SIRI The Technical Specification “Public transport – Service Interface for Real-time Information relating to public transport operation (CEN/TS 15531)” was first published in 2006 in 3 parts and became a CEN Technical Standard in 2007. Two further parts extended it in 2011. Since 2013, part 1 to 3 are published as draft European Standard (prEN 15531 rev) that are intended to supersede the CEN/TS 15531 documents of 2007. SIRI provides a framework for specifying communications and data exchange protocols in order to exchange real-time information related to public transport operations. SIRI is designed as a modular and expansible standard that uses XSD schemas.

Figure 24 CEN/15331 Parts SIRI specifies several functional modules, based on ‘use cases’ identified in Annex B of Part 1 (Table 3-4), which are taken in part 3 to 5 presenting functional service interfaces in order to exchange data. For each of these functional services, SIRI defines purposes, capability and permission matrices, service requests, their related elements and provides examples.

Public transport services rely increasingly on information systems to ensure reliable, efficient operation and widely accessible, accurate passenger information. These systems are used for a range of specific purposes: setting schedules and timetables, managing vehicle fleets, issuing tickets and receipts, providing real-time information on service running, and so on.

The Service Interface for Real Time Information (SIRI) specifies a European interface standard for exchanging information about the planned, current or projected performance of real-time public transport operations between different computer systems.

 SIRI comprises a carefully modularised set of discrete functional services for operating public transport information systems. Services cover planned and real time timetable exchange; vehicle activity at stops; vehicle movement; and information to assist in the provision of reliable connections between vehicles.  SIRI aims to incorporate the best of various national and proprietary standards from across Europe and deliver these using a modern XML schema and TransModel terminology and modelling concepts.  All SIRI services are provided over a standardised Communications layer, based on a Web Services Architecture. The Communications layer upholds a consistent approach for all the

IFG-WP3-D-UIC-015-02 Page 137 of 153 12/12/2018

Contract No. H2020 – 730844

functional services to Security, Authentication, Version Negotiation, Recovery/Restart, and Access Control/Filtering. To support different operating requirements, two main patterns of interactions are supported: an immediate Request/Response protocol; and an asynchronous Publish/Subscribe protocol. The Publish/Subscribe can be further elaborated with a fetched delivery interaction to optimise the use of bandwidth. SIRI is extensible and it is expected that additional services will be added over time using the same communications bearer.

SIRI’s modularisation allows an incremental approach: only the subset of services actually required needs to be implemented for a particular application. The expectation is that users may start with just one or two services and over time increase the number of services and the range for supported options. Similarly Suppliers may extend their support for SIRI in their products incrementally.

SIRI takes a ‘joined’ up look at all real-time information services, data, data models, transport, and mediation. Considering the whole context is important because for efficiency, real-time services are often only exchanging real-time changes to data, requiring precision about the underlying model assumed by the participants.

A Web Services Discovery process is defined allowing data providers to make the capabilities of their services known to other interested parties.

SIRI currently comprises the following functional services:

 The Production Timetable Service  The Estimated Timetable Service  The Stop Services (Stop Timetable and Stop Monitoring)  The Vehicle Monitoring Service  General Messaging Service SIRI is intended to be used to exchange information between servers containing real-time public transport vehicle or journey time data. These include the control centres of transport operators and information systems that utilise real-time vehicle information to operate the system, and the downstream systems that deliver travel information to the public over stop and onboard displays, mobile devices, etc.

 SIRI uses on eXtensible Markup Language (XML) to define its messages. A careful separation is made between Transport (how the data is transported) and Payload (the domain data exchanged), so that SIRI messages may be exchanged as either XML documents with http POST or using Simple Object Access Protocol (SOAP). A Web Service Definition Language (WSDL) binding is also defined for the latter.  The payload model is wrapped in a Mediation layer, also described with XML, that both provides common management functions and also formally describes as policies the parameterised aspects of mediation or exchange behaviour or that can be carried out by a service.  CEN TransModel terminology and relationships are followed in the underlying PT application data model.

IFG-WP3-D-UIC-015-02 Page 138 of 153 12/12/2018

Contract No. H2020 – 730844

SIRI is designed for efficient operation in a wide variety of contexts. It can be used both for the bulk pipelining of large amounts of data between different computer systems, and for lower traffic ad-hoc queries.

SIRI uses a consistent set of general communication protocols to exchange information between client and server. The same common patterns of message exchange are used in all the different functional interfaces. Two well-known specific patterns of client server interaction are used: 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. This can be much more efficient for some types of communication as the client does not need to poll to detect changes to the data; rather the notifying service triggers a data exchange only when it detects an event. The SIRI Publish/Subscribe Protocol prescribes particular mediation to filter the number of messages returned, for example, only creating updates if real time predictions change by more than a certain threshold from a previous value.

SIRI takes a consistent approach to handling common functions needed for all services, such as subscription management, recovery and restart, version negotiation, access control (which clients may use which functions), capability discovery, and error handling.

All optional features are explicitly parameterised as named capabilities and the schema includes a configuration profile that a client system can use to automatically detect the capabilities of another system. This makes it possible for suppliers to create adaptive systems that adjust their behaviour automatically to optimise.

The relation of SIRI to NeTEx As NeTEx is developed as a complementary format to SIRI, the revised version of SIRI includes references to NeTEx (see section 3.7). SIRI refers to “Transmodel V5.1: EN 12896: 2006 Road transport and traffic telematics – Public transport – Reference data model”, wherever possible, which is also a basis for NeTEx. (prEN15531-1, 2013).

IFG-WP3-D-UIC-015-02 Page 139 of 153 12/12/2018

Contract No. H2020 – 730844

Public transport — Open API for distributed journey planning Regulation/Standard/Convention Mode Geographic Applicability

EU Directive 2017/1926 Publictransport Europe mode

Scope of Application to the Interoperability Framework Assets

Ontologies WebService Business Schemas Data Sets Products and Rules and Services Mappings

Introduction

The Technical Specification Public transport — Open API for distributed journey planning98 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.

The EC Delegated Regulation (related to the ITS Directive) (EU) 2017/1926 on the provision of EU- wide Multimodal Travel Information Services (see below section 6.3.7) provides the necessary requirements to make EU-wide Multimodal Travel Information services accurate and available across borders. It establishes the specifications necessary to ensure the accessibility, exchange and update of travel and traffic data and distributed journey planning for the provision of multimodal information services in the European Union. The Delegated Regulation recommends the use of the Open API standard in relation to the requirements specified in Article 7 'Linking Travel information Services'.

This Technical Specification (WI 00278374) is tightly aligned with the terminology and definitions established in the Transmodel, IFOPT (now integrated into Transmodel v6), SIRI and NeTEx standards.

The availability of accurate and timely information about public transport (PT) services has been an increasing expectation over the past decade or more and systems have been developed to assist in the compilation and delivery of such information making best use of the rapid advances in information technology (IT) capabilities. Multi-modal information systems typically have started with an urban or regional focus to meet the information needs of those making relatively local journeys – whilst information requirements for longer-distance journeys have been delivered primarily by mono-modal information systems from the rail and airline industries.

However there have been some pioneering systems over the past 10 years that have extended these models, notably:

98 2017-01; TC 278 WI 00278420; CEN/TC 278 Secretariat: NEN Public transport.

IFG-WP3-D-UIC-015-02 Page 140 of 153 12/12/2018

Contract No. H2020 – 730844

 EU-Spirit in Northern Europe  JourneyWeb in Great Britain  DELFI in Germany

These three systems employed different architectures that collated data from multiple sources in order to be able to offer information about longer-distance journeys that involved travel in the area of more than one regional information system in a single transaction. This technique of bringing information together from two or more information systems when necessary is referred to as "distributed journey planning".

The ability to extend such systems to wider applications has been greatly enhanced through the way in which public transport data is now increasingly standardised by following the principles set out in the "Public Transport Reference Data Model" (Transmodel) EN standard, and its related implementation Standards and specifications.

An Open API for distributed journey planning (OJP)

A review of EU-Spirit, JourneyWeb and DELFI found that, whilst the architecture of each of these systems was different, the nature of the enquiries sent between the systems, and the content of the responses sent in return, were essentially the same. This suggested that it would be possible to define a single Open Journey Planning API to support all distributed journey planning systems.

The Open Journey Planning API (OJP) will therefore allow a system to engineer just one interface that it can make available widely (to authorised users or openly as they so choose) rather than having to engineer separate APIs for each bipartite exchange arrangement that may be required with other systems.

However existing journey planning systems (and probably some that will be developed in the future) may require their own specific APIs. The intention of the OJP is to provide an opportunity for just one universal channel to exchange information to lower-volume users – once created then there is little reason not to allow as many users of this API as may wish to use it.

The public transport information tensions

The greatest use of public transport (in terms of the number of passenger journeys) happens in urban areas where frequent and regular services cater for the needs of relatively short-distance journeys.

Usage then declines as journey distances get longer – with inter-regional and international journeys comprising the smallest number of public transport journeys.

However the need for information about PT services is least in areas with frequent and regular services, where passengers quickly get to know about the services they rely on for most of their journeys – and therefore their need to check information systems is relatively infrequent. Longer distance journeys, however, are made less often and for a variety of reasons there is a much greater need to obtain information for such journeys before setting off. So the need for information is greatest for the very journeys that are made least often. It is difficult to make a business case to provide information systems geared specifically to the needs of the longer-distance travellers, therefore.

IFG-WP3-D-UIC-015-02 Page 141 of 153 12/12/2018

Contract No. H2020 – 730844

Instead it becomes important to find ways of meeting the information needs of those passengers by using information collated and delivered primarily for the much larger group of those making short- distance journeys.

The distributed journey planning systems mentioned above were a measured response to these tensions, allowing data to be shared across multiple systems in different ways to ensure that someone wanting to plan a journey anywhere in (for instance) Germany could go to their own regional journey planner which collected relevant information from other regional planners in order to satisfy a particular enquiry. In Great Britain Transport Direct provided a national journey planning service collating data from the 11 regional traveline journey planners. And in the Baltic area EU- Spirit collated information from several sources to allow international planning between several European states. In Slovenia a proposal to extend the national journey planning system to a multi- national distributed system was included in the SIJPRIS service, although to date it has not yet been implemented.

Over time technology and techniques have allowed these particular systems to drive greater efficiencies as regional systems have been able to merge into ones covering larger areas. This has reduced the complexity of the distributed journey planning process within the areas covered by these systems. The moves to open data have also enabled larger "consolidated" datasets to be used in journey planners (notably Google Transit, or Traveline's national journey planner in Great Britain) – but these are systems offering much less rich information than that from the more local or regional systems, and the data on them is often less timely than is possible on the local and regional systems.

Taking all these factors into account there remain advantages in the distributed journey planning model notwithstanding the trends towards travel information systems that are designed to cover ever larger areas. Key points would appear to be that distributed systems are sharing the most up to date information from the local authorised source in a way that cannot be achieved with systems that collate data for much larger areas. This is particularly important in areas where local public transport market is deregulated (as has been the case in most of Great Britain since 1986) where bus services can change on any date of an operator's choosing rather than there being only one or two service change dates each year from which any changes of services are known well in advance (as is the case in many other parts of Europe).

In the foreseeable future distributed journey planning will continue to provide an effective mechanism for extending the geographical scope of any journey planner with a minimum of effort – so long as there is a single standardised API as proposed in this Technical Specification which will ensure that only one API would need to be engineered to allow standard questions to be asked of other systems, and to allow answers to standard questions from other systems to be sent in response.

For the enquirer there is one other important advantage of distributed journey planning – and that is that the questions can be asked, and answers read, within a layout that the user is familiar with – and in their own natural language.

Distributed journey planning architecture beyond scope Distributed Journey Planning depends not just on there being an available API for the exchange of data.

IFG-WP3-D-UIC-015-02 Page 142 of 153 12/12/2018

Contract No. H2020 – 730844

It also requires the system responding to an end-user's enquiry to be able to work out what enquiry to send to one or more other information systems, and how to merge the responses with data from its own repositories in order to create one or more seamless journey plans for the enquirer. There are several different approaches to the "architecture" for distributed journey planning – and these are beyond the scope of this Technical Specification. The following paragraphs, however, outline some of the key considerations that any implementation of distributed journey planning will need to take into account.

The distributed journey planning approach

One of the key considerations for building a distributed journey planning system is to define what supporting data (metadata) is required and where it is to be held. At its simplest the process of making an enquiry typically has several stages: a. An enquirer goes to his home system and composes an enquiry expressing the location of the start and end points in their own terms or as permitted by the user interface; b. The enquirer's home system seeks to match the enquirer's locations to locations understood by the journey planner, and then converting them into terms (perhaps geographic coordinates) that can be understood by the home and other distributed journey planning engines; c. The home system establishes what questions it needs to ask and from what journey planning systems (both its own and those of one or more distributed partners) it needs to ask for information that it does not already have in its own databases; d. The home system then collates the information received in response to the questions asked of the different systems to create a seamless and efficient journey plan which it can then deliver to the enquirer.

In some systems the home system does not itself undertake the distributed journey planning. Instead the home system passes that task to a separate distributing journey planning system which completes the process and returns the answers to the home system.

For the enquirer it is important to make the process as simple and efficient as possible – so the process of matching locations with system gazetteers can be a critical one. Ideally the enquirer should be able to specify a location as a station or stop name, a topographic place, a street address, a postcode (if this covers a meaningful small area), and possibly Points of Interest. Such data for locations within the geographical scope of the home system is likely to be held already – but if the location is outside that geographical scope where does the equivalent data come from? – and how does the home system know that it needs to find data for a distant location?

Distributed or centralised approaches

So one of the key considerations for building a distributed journey planning system is to define what supporting data (metadata) is required and where it is to be held. Somehow the home system needs to be able to recognise that a requested origin or destination is not in its own geographical area – and once it has done that it also needs to recognise which system(s) will be able to provide journey planning answers for that location. One way of managing this would be for a network of distributed journey planning systems to share a central repository of gazetteers (indexes of geographical entities – localities, addresses, stops & stations, etc.) to resolve these questions (and probably to go on to

IFG-WP3-D-UIC-015-02 Page 143 of 153 12/12/2018

Contract No. H2020 – 730844

make the necessary enquiries of the relevant journey planning systems) before handing back the information to the originating home system. This would be a centralised model for handling journey enquiries that required the distributed service. Alternatively each participating system could hold gazetteer data for all the participating systems' areas – and the enquiry process could then work on a peer-to-peer decentralised basis. To get an efficient approach it is necessary to consider all required support data – not only the gazetteers, but also how access to the timetable data for long- distance PT services (notably trains, coaches, ferries and flights) can be achieved in a way that allows it to be used in the creation of the effective journey plans.

The basis for the Open API

Recent work in Germany's IP-KOM research project has brought together the lessons learned from various information systems (including EU-Spirit, JourneyWeb and DELFI) and developed the TRIAS schema to support future information systems in Germany. Because this work has brought together the experience of the three long-standing distributed journey planning models, it was decided that it should form the basis of the proposed standard Open API for distributed journey planning. This Technical Specification is based, therefore, on the experiences from EU-Spirit, JourneyWeb and DELFI systems and on the TRIAS schema developed in Germany with appropriate extensions to meet the full requirements for Distributed Journey Planning.

A number of existing European Standards and Technical Specifications also underpin the work – notably Transmodel, IFOPT, SIRI and NeTEx.

The Open API will depend on the consistency of data from all sources that comes from the implementation of the existing European standards for public transport information.

Other possible uses for the Open API

Whilst the Open API is intended primarily to support distributed journey planning, experience of such APIs to date has shown that they can also be used for other purposes. For instance they can be used for communication between personal journey planning apps and a journey planning service (without any distributed journey planning requirement). Or they can be used to enable a park-and- ride planner to combine car journey planning with public transport journey planning, connecting the two modes at the park-and-ride car parks. Or they can support the use of taxis as a mode to access public transport in areas where conventional public transport does not exist or is very sparse. A standard Open API will provide many opportunities to use and re-use public transport and associated data in the delivery of innovative information services.

Therefore the assets produced by IT2Rail should be faced to the content of the Open API as regards:

 the Glossary – terms and definitions and explanation of terms (and extension terms) used in OJP schema; the Symbols and abbreviations; the Use cases; the Key tasks for Distributed Journey Planning; other possible tasks for a Distributed Journey Planning system;  the System Architectures, Metadata and Data;  the OJP Services;  the OJP – Interface Description;  Annex A (informative) - A distributed approach to journey planning across Europe;

IFG-WP3-D-UIC-015-02 Page 144 of 153 12/12/2018

Contract No. H2020 – 730844

 Annex B (informative) Lessons from experiences of Distributed Journey Planning to date.

SPECIFICATION DOCUMENTS

This chapter describes other relevant standardization bodies and/or standards that are relevant to GoF4R but are not covered in previous sections.

GTFS (General Transit Feed Specification)

General Transit Feed Specification (GTFS) started as a side project of Google employee Chris Harrelson in 2005, while implementing transit data application into the Google Maps. Later with the help of TriMet (Tri-County Metropolitan Transportation District of Oregon), GTFS was born.

Information can be found from https://developers.google.com/transit/gtfs/

GTFS defines a common, open data format for public transportation schedules and associated geographic information. GTFS "feeds" let public transit agencies publish their transit data and developers write applications which consume that data in an interoperable way.

A GTFS feed is composed of a series of text files collected in a ZIP file. Each file models a particular aspect of transit information: stops, routes, trips, and other schedule data. A graphical representation of the files in terms of classes and attributes is shown in Figure 27.

The text files are formatted as CSV, which makes them harder to cross check than XML based formats. However this makes them simple to use, especially for relatively small transport networks.

Knowles & Miller proposed a Transmodel based XML schema for exchanging transit stop and timetable data, which would be fully compatible and interoperable with both Google’s GTFS and Transmodel based data sets. In particular as GTFS ought to be enhanced to cover further more complex capabilities, Transmodel can be used to guide and validate the design, drawing on many years of industry experience. (Knowles & Miller, Transmodel for google, 2008).

Trip planning tools like Google Transit (http://maps.google.com/transit) or OpenTripPlanner (http://www.opentripplanner.org/) rely on up-to-date GTFS data integrating transit stops, routes, schedules and fare information into their routing algorithms. Although the GTFS feeds were originally designed only for the use in Google Transit, the specification is widely used as import format in other applications. (AWT Consortium, 2014).

IFG-WP3-D-UIC-015-02 Page 145 of 153 12/12/2018

Contract No. H2020 – 730844

Figure 25 Classes and attributes of the GTFS specification

Here, we report examples of route and trip feeds.

Route feed: route_id,route_short_name,route_long_name,route_desc,route_type

17,A,Mission,"The ""A"" route travels from lower Mission to Downtown.", 3

Trip feed: route_id,service_id,trip_id,trip_headsign,block_id

17,WE,AWE1,Downtown,1

17,WE,AWE2,Downtown,2

GTFS-Realtime GTFS-realtime is a feed specification that allows public transportation agencies to provide application developers with real-time updates about their fleet. This feed is an extension to GTFS.

IFG-WP3-D-UIC-015-02 Page 146 of 153 12/12/2018

Contract No. H2020 – 730844

GTFS realtime is designed for ease of implementation, good GTFS interoperability, and a focus on passenger information.

The specification currently supports the following types of information:

 Trip updates: Delays, cancellations, changed routes;  Service alerts: Stop moved; unforeseen events affecting a station, route or the entire network;  Vehicle positions: Information about transit vehicles including location and congestion level. Updates for each information type are provided in a separate feed. Feeds are served via HTTP and updated frequently. The file itself is a regular binary file (unlike GTFS), so any type of webserver can host and serve the file (other transfer protocols may be used as well). Alternatively, web application servers could also be used which, in response to a valid HTTP GET request, return the feed.

Open access to GTFS-realtime data is not common in Europe yet.

A trip update (e.g., "Bus X is delayed by 5 minutes") consists of one or more updates to vehicle stop times, which are referred to as StopTimeUpdates. These can be supplied for past and future stop times; they are linked to a GTFS stop_sequence or a GTFS stop_id. The update can provide an exact timing for arrival and/or departure at a stop in StopTimeUpdates using StopTimeEvent. This should contain either an absolute time or a delay (an offset from the scheduled time, in seconds).

A service alert (e.g., "Station Y is closed due to construction") represents higher level problems with a particular entity and are generally in the form of a textual description of the disruption. It is composed of time range, entity selector, cause and effect. The time range represents the entire time that the alert is useful for the passenger to see. The entity selector allows specifying exactly which parts of the network this alert affects, selecting any of the following:

 Agency: Affects the whole network  Route: Affects the whole route  Route type: Affects any route of this type, e.g. all subways.  Trip: Affects a particular trip  Stop: Affects a particular stop The cause of the alert is specified selecting between Unknown cause, Other cause, Technical problem, Strike, Demonstration, Accident, Holiday, Weather, Maintenance, Construction, Police activity and Medical emergency.

The effect on the specified entity is declared selecting between No service, Reduced service, Significant delays (insignificant delays should only be provided through Trip updates), Detour, Additional service, Modified service, Stop moved, Other effect (not represented by any of these options) and Unknown effect.

A vehicle Position (e.g., "This bus is at position X at time Y") is used to provide automatically generated information on the location of a vehicle, such as from a GPS device on board. It is composed of position, congestion level, occupancy status and vehicle stop status. Position contains the location data (latitude, longitude and optionally bearing, odometer and speed) within Vehicle Position. The congestion level allows specifying the congestion level that the vehicle is currently experiencing selecting between the following categories: Unknown congestion level, Running smoothly, Stop and go, Congestion and Severe congestion. The occupancy status allows specifying

IFG-WP3-D-UIC-015-02 Page 147 of 153 12/12/2018

Contract No. H2020 – 730844

the degree of passenger occupancy for the vehicle selecting between the following categories: Empty, Many seats available, Few seats available, Standing room only, Crushed standing room only, Full and Not accepting passengers. The Vehicle stop status gives more meaning to the status of a vehicle in relation with a stop that it is currently approaching or is at. It can be set to any of the following values: Incoming at (i.e., the vehicle is about to arrive at the referenced stop), Stopped at (i.e., the vehicle is stopped at the referenced stop) and In transit to (i.e., the referenced stop is the next stop for the vehicle).

GTFS-Flex GTFS-flex is a proposed/prototype extension to the General Transit Feed Specification. GTFS-flex would add the capability to model various Demand-Responsive Transportation (DRT) services to GTFS, which currently only models fixed-route public transportation. Figure 26 shows the GTFS- Flex model.

Figure 26 The GTFS-Flex model

The modification to GTFS proposed by GTFS-Flex are:

 The existing GTFS assumes that stops are served in an order, defined by stop_sequence. In order to describe a point-deviation service, GTFS-Flex offers the capability to override this assumption.  A key concept in flexible services is the idea of a service area or zone. These zones are used to define the region where demand-response operation is in effect.  Flexible routes can use service areas and zones in a variety of ways. Some routes provide demand-response services with a single fixed zone, while others offer regions of flexible services along an otherwise fixed route, while yet others use combinations of the two. To support this flexibility in GTFS, GTFS-Flex allows a provider to associate service areas with particular stop-time entry.

IFG-WP3-D-UIC-015-02 Page 148 of 153 12/12/2018

Contract No. H2020 – 730844

 Many transit systems allow riders to board or alight from a transit vehicle at any location along a route. Alternatively known as “flag stop”, riders can flag down a vehicle at locations other than fixed stops. GTFS-Flex proposes to use the continuous stops field in Stop Times that can have the following non-negative integer values: 0 or blank (Normal stop behaviour along route), 1 (Continuous stopping behaviour from this stop-time to the next stop-time in the trip’s sequence).  Demand-responsive transportation services have parameters for request requirements and expected or maximum travel times. GTFS-Flex proposes to extend the Trip file with drt_max_travel_time (maximum travel time for a demand-responsive passenger travel leg on the trip), drt_avg_travel_time (average or expected travel time demand-responsive passenger travel leg on the trip) and drt_advance_book_min (minutes of advance time necessary before travel to make booking request).

OSPT Alliance The OSPT (Open Standard for Public Transportation) Alliance aims to help the transit community in moving towards the next generation of secure, cost-effective, and flexible fare collection solutions through a global, multi-provider community. Members are system integrators, and reader and terminal manufacturers as well as various public transportation bodies.

OSPT’s goal is to define a new open standard for secure transit fare collection solutions, while providing industry education, creating workgroup opportunities, and catalyzing the development and adoption of innovative fare collection technologies, applications, and services. OSPT is aiming to achieve global ecosystem of transit operators, transit consultants and integrators, technology solution providers, and government agencies to stimulate development and delivery of next- generation fare collection solutions.

CIPURSE is one of the open standards created by OSPT.

More information can be found from http://www.osptalliance.org

Matka.fi data and API Matka.fi data and API is free route and time table data source and it is provided by the Finnish Transport Agency (FTA). Any developed applications and/or services must support public transport use and public transport information provision. Development and testing as well as commercial use of interfaces is free of charge.

The timetable and route data can be accessed by three ways:

• Kalkati.net formatted XML national database dump file, which includes the whole Matka.fi stop, route and timetable information in a single file. • GTFS national database dump api.matka.fi/data/gtfs.zip • Routing etc. APIs at Digitransit

IFG-WP3-D-UIC-015-02 Page 149 of 153 12/12/2018

Contract No. H2020 – 730844

The content of the matka.fi database covers timetables and routes for buses, trains, local public transport and air traffic.

More information can be found from http://developer.matka.fi/pages/en/home.php

IFG-WP3-D-UIC-015-02 Page 150 of 153 12/12/2018

Contract No. H2020 – 730844

6. CONCLUSIONS

In the analysis above, the relevance of regulations, standards, industry conventions, etc. has been checked individually against:

• the Interoperability Framework Assets, namely ontologies, web services, business rules, schemas & mappings, data sets, and

• products & services expected to use the IF.

Standards and industry conventions are not regulations in the strict sense, but not abiding by certain widespread standards or specifications would compromise the adoption of the interoperability framework. These de facto standards are therefore to be considered in what is termed, broadly, as the “regulatory environment”.

Early in the research, it was noted that some Regulations, Standards and industry Conventions relate directly to the IF Assets (TAP-TSI, W3C, etc.), while most Regulations are related to the services and products that will be developed using the IF Assets (Data Privacy, Anti-Trust, etc.). The analysis confirmed this, and also showed that the ontologies will be systematically impacted: true to the Latin saying “nemo censetur ignorare legem” 99 applicable in Europe, the analysis reveals that the The fine line between Regulations affecting the IF Assets and those affecting IF Asset Users is not easily drawn.

Figure 27 Regulation Environment Ontologies, web services, business rules, schemas & mappings are integral parts of the IF Assets; any regulation (or standard, etc.) affecting these is relevant to the IF Assets as a whole.

Products & services, if based on the IF Assets, are the responsibility of the asset user(s), therefore having no direct impact on the IF Assets themselves.

99 (EN) Nobody is thought to be ignorant of the law

IFG-WP3-D-UIC-015-02 Page 151 of 153 12/12/2018

Contract No. H2020 – 730844

A “grey zone” is represented by data sets. It is not foreseen at this moment to publish any data set with any personal or confidential information (personal details, credit card information, etc.) in the Asset Manager. This information will be used and persisted in future product development in IP4 and beyond, such as the Travel Companion. However, we understand that “Data Sets” include both data definitions (metadata) and actual data (values). Whenever a regulation affects Data Sets, it may prescribe metadata, in which case the IF Asset Manager must address compliance. Therefore, the governance should only assure that the specific metadata requirements have been fulfilled. It may also place certain restrictions (or provide guidelines) on data content of the datasets, if such content comes under the jurisdiction of certain Regulations (i.e. data privacy, etc.)

The summary table below lists the components of the Regulatory Environment and indicates their respective relevance to IF Assets:

Figure 28 Regulatory Impacts by Asset Category As evidenced in the above analysis, most of the Regulatory framework will have a direct impact on the content and composition of the Semantic definitions as contained in the Reference Ontology(ies). This means that the Governance must consider the rules, processes and workflows necessary to add the Regulatory semantic content. Also evidenced in the above analysis, most of the Regulatory framework specifically impacts the Datasets and Products and Services which fall mostly under the responsibility of the IF Asset Users.

As detailed in 2.1, IF assets aim to allow the diverse actors of the transport system and related services to share the semantics of their operations with a minimal impact on the underlying data. Since the ontology provides the terms and logical inferences that associate semantics with the

IFG-WP3-D-UIC-015-02 Page 152 of 153 12/12/2018

Contract No. H2020 – 730844

underlying standards, the Governance structure must concentrate on the maintenance of the Ontology.

On the other hand, analysis showed that the body of Standards and Industry Conventions have a significant impact on most, if not all, of the IF Assets. As seen in the table below, the IF Assets must conform to the following Standards and Conventions if they are to be widely adopted in the marketplace by potential users.

Business Schemas and Products and Type Name Ontologies WebService Data Sets Rules Mappings Services Standard Web of Services (RDF, OWL, SPARQL, XML) 1 1 1 1 Convention Full Service Model 1 1 1 1 1 Convention RailTopoModel 1 1 1 1 1 Convention Open Travel Alliance 1 1 1 1 1 Standard Open API for distributed Journey Planning 1 1 1 1 Convention UIC 918 Suite of Messaging and formats 1 1 1 1 1

Figure 29 Standards Impacts by Asset Category It is important that the Governance considers not only the Standard/Convention (Format, metadata definitions, semantics, etc.); Governance must also consider how to apply version control and change management aspects to the pertinent Asset.

IFG-WP3-D-UIC-015-02 Page 153 of 153 12/12/2018