TD 2.1 - Adaptable communications for all railways

The development of a new Communication System (TD 2.1) aims to overcome the shortcomings in the current European Train Control System (ETCS) and Communications-Based Train Control (CBTC) and deliver an adaptable train-to-ground communications system usable for train control applications in all market segments, using packet switching/IP technologies (GPRS, EDGE, LTE, Satellite, Wi-Fi, etc.). The system will enable easy migration from existing systems (e.g. GSM-R), provide enhanced throughput, safety and security functionalities to support the current and future needs of signalling systems, and be resilient to interference and open to developments in radio technology. Backwards compatibility with ERTMS will be ensured.

Implementation within IP2 projects


WP03 - Adaptable Communication System

This work package will provide the starting activities for an adaptable IP communication system based on standard technologies with enhanced throughput, safety and security functionalities to take advantage of new technologies, supporting the current and future needs of signalling systems (like ATO – Automatic Train Operation) and voice services.

WP1 - Project Management

WP1 will provide an effective and efficient management and work process of the project during the contractual period. It ensures a consistent high quality both of the work to be performed and the reports to be produced. Further, it deals with the administrative and financial management of the project.

WP2 - Scenario Building

The main objectives of this WP2 are to:
  1. Analyse the current scenario of the T2W communication system from a multidisciplinary standpoint.
  2. Build foreseeable scenarios of future T2W communication system.
  3. Specify a sound market proposition fitting with TO-BE scenarios.
  4. Refine afore-mentioned techno-economic proposition.

WP3 - Business Viability Analysis

The main objectives of the WP3 are to:
  1. Provide a neat and up-do-date picture of the market structure in the European railway sector (AS-IS scenario).
  2. Identify market trends that are expected to shape the portfolio of TO-BE scenarios.
  3. Gain a deep understanding of the main actors needed to successfully implement advanced radio technologies in the railways domain according to the ‘network as a service’ tenet.
  4. Formalize and validate the offerings (i.e., value propositions) underpinning the techno-economic proposition.
  5. Design and validate robust business models needed to make the techno-economic proposition sustainable over time.
  6. Validate from the quantitative standpoint the business sustainability of the techno-economic proposition in a mediumterm perspective.

WP4 - Technical Viability Analysis

The main objectives of this WP are to:
  1. Analyse the performance requirements of current and future communication technologies in the railway sector, with respect to certain key parameters of the transmission such as data capacity, bandwidth or connectivity quality.
  2. Analyses of possible tomorrow’s wireless communication candidates and suggest technical scenarios for a future adaptable communication.
  3. Verify the conditions under which the requirements and concepts are satisfied by scenario communication candidate(s).
  4. Evaluation of a Quality of Service Vector for a Data Packet Switched IP based Radio Network.
  5. Feasibility study whether the new communication technology can meet the established requirements for data and voice transmission.

WP5 - Outreach & Networking

The main objectives of this WP are to:
  1. provide the basis of engaging with stakeholders through a stakeholder identification, analysis and interaction process.
  2. interact efficiently with identified External Stakeholder receiving their inputs and feedback.
  3. spread as widely as possible the salient findings of the proposal to the external stakeholders and communities.
  4. implement a broad range of dissemination activities that will increase the awareness of a range stakeholder category.
  5. to establish and maintain mechanisms for effective fine-grained exploitation strategy beyond the grant period.
  6. ensure the outcomes of the project are converted in comprehensible for target audience information.
  7. encourage the exploitation of the results in order to obtain the maximum social-economic benefits.

WP03 - Adaptable Communication

The objectives of this work package are to cover the definition, development and test of prototypes and demonstrators for the adaptable communication system in response to ETCS and CBTC system requirements, cover operational voice services as well as supporting enhancements of the signalling system foreseen by other TDs and other railway communication needs (critical video, critical data). During the start-up activities for TD2.1, the communication requirements were analysed, collected and documented, the definition and specification of the adaptable communication system was done, and the prototype development activities were started.

The second phase of TD2.1 work to be carried out in the projects, foresees the finalisation of the prototype development and the testing and integration of prototypes into demonstrators, with the aim to validate the concepts and demonstrate the capabilities of the adaptable communication system for different rail market segments.

WP1 - Applications requirements and railway scenarios

This WP will provide the general requirements for the emulation work to be carried out in the other technical WPs (in particular, WP2 and WP3). The requirements to be provided cover three different aspects:
  • An IP-layer characterization of railway services based on radio communications· A description of the potential perturbations that may affect the performance of the radio communications systems in railways.
  • An applicability analysis of channel models available in the scientific literature and in other research projects as well.

WP2 - Possible Emulation solutions and models impairments

The WP will first define how the different Radio bearers will be emulated and connected to the applications at IP level in order to perform communication performance assessment. We will define the radio access emulation tool architecture taking into account requirements such as: flexibility, availability of the equipment among the partners, easy to use devices, etc. WP2 will consider different technical solutions to emulate the Air Gap and to interface the radio emulators to the communication systems and to the applications. Activities of WP2 will continue with the modeling of the IP impairments e.g. packet delay, packet loss, bandwidth etc. as perceived at the application layer. Models will be inserted in the IP level emulator. Parameters of the derived models will be accessible and tunable/programmable in the emulator by means of a proper interface and/or a configuration file.

WP3 - Emulation tool development

This WP covers the development of the radio access emulation tool. It will start in parallel of WP2, when the solutions for emulation will be identified, and when the first radio channels will be selected in WP1. The objectives of WP3 will be:
  • To develop and implement the different building blocks of the radio access emulation tool;
  • To validate the tool with the experimental assessments of the IP parameters in different railway radio channels, corresponding to different environments and interferences identified in WP1;
  • To support the integration of the Radio access emulation tool with the S2R-CFM-IP2-01-2018 project. 

WP4 - Dissemination

Dissemination, communication andexploitation activitiesuptake of the results by the stakeholders

WP5 - Project management

Project-, Risk-, and Cooperation- Management aspects addressed in this WP. It coordinates and ensures that all activities are in line with the project work plan and that all objectivesFinancial and administrative coordination

TD 2.2 - Railway network capacity increase

Automatic Train Operation (ATO) (TD 2.2). The aim is to develop and validate a standard ATO up to GoA3/4 over ETCS, where applicable, for all railway market segments (mainline/high speed, urban/suburban, regional and freight lines).

Implementation within IP2 projects


WP04 - ATO over ETCS

This WP will address Automatic Train Operation over ETCS (European Train Control System). It will start from the current experience in urban applications and some existing main line applications in order to address all the market segments of Main Lines: High Speed Line, Low Traffic/Regional Lines, Urban/Suburban, Freight) and to extend these applications from fenced systems (urban rail) to open systems (single EU Railway Area).

The WP shall:
  • Focus on GoA2 starting from inputs from Ten-T 3rd call (ATO over ETCS - Technical Interoperability Requirement for GoA2); the operation concepts updated according to the results of the European NGTC project and existing standard IEC 62290-2;
  • Perform the feasibility study and preliminary design for GoA3 and GoA4 solutions (incl. IEC 62267).

WP3 - Automatic driving technologies for railways

The main target of WP3 is to identify which automatic driving technologies from the automotive sector, and from other application fields different from the railway, are the most suited for the implementation in the rail sector for ATO. To achieve this target, the following objectives can be identified:
  • State of the Art of all the technologies for automated driving in the automotive sector and other application fields considering technologies that are already on the market or in the development phase;
  • Identification of the basic implementation characteristics of the automotive sector that are compliant for the implementation in the railway sector;
  • Identification of the operation conditions that are required for the different grade of automation in ATO (e.g. driverless or unattended operations);
  • Selection of the candidate automated driving technologies to be assessed for the rail sector.

WP03 - “ATO up to GoA4” Specification

This is done in two steps associated to two separate activities:
GoA2 specification (quick win)
GoA3/4 specification (preliminary and built upon GoA2)
These specifications will be submitted to ERA  
Task 3.1 – Technical Coordination and System Integration (Leader: ALS, Participants: SMO, STS, AZD, BTSE, CAFS, DB, SBB, MERMEC, NR, TD, TRV, SNCF-R)
ALS as technical leader will carry out the overall WP coordination supported by the task leaders.
Task 3.2 – GoA2 Specification (Leader: ALS, Participants: SMO, STS, AZD, BTSE, CAFS, DB, SBB, MERMEC, NR, TD, TRV, SNCF-R)
In the context of X2Rail-1, the majority of GoA2 functions have been specified in order to perform interoperability tests on two Reference Tests Benches. In addition, the System Requirement Specification and Interface Specification have been submitted as draft to and accepted by ERA.
The purpose of this activity is to update GoA2 specification in order to take into account:
- the results from interoperability tests performed in X2Rail-1 (Return on Experience);
- Safety assessment performed on the current specification;
- Possible new operational requirements primarily related to freight.
A Traceability Matrix between the Operational Concept and Specifications will be produced.
Updated GoA2 specification will be submitted to ERA
GoA2 specification contain:
- The Operation Concepts (Passenger and Freight) specified by the Users team members
- The System Requirement Specification
- And the interface specifications compliant with the architecture defined in the Operation Concept documents
The required FFFIS specifications shall specify the interchangeability and interoperability (Plug&Play).
Fully finalised FFFIS (Plug&Play) specifications will be delivered on the condition that underlying critical technology, relevant for that function/interface implementation, has reached the necessary level of maturity and is ready for product integration.
Task 3.3 – GoA3/4 Specification (Leader: ALS, Participants: SMO, STS, AZD, BTSE, CAFS, DB, SBB, MERMEC, NR, TD, SNCF-R)
In the context of X2Rail-1, preliminary specification for GoA3/4 solution will have been delivered.
It includes:
- Operational Concept including, Needs and Missions, Operational Context Definition, Actors definition, Uses Cases definition, Operational scenarios, Logical Architecture;
- System Requirement Specification including Functional Break down Structure, Functional Requirements, allocation to Logical Blocks, Interfaces Specifications (FIS level).
- Fully functional and vendor independent reference model.
The purpose of this activity is to complete GoA3/4 specification. This includes:
- Completion of Operational Concept (includes GoA1/2);
- Completion of System Requirement Specification;
- Physical Architecture Specification including allocation of Logical Blocks to Physical Blocks and interfaces specification (agreed FFFIS level to ensure agreed Plug&Play);
- Safety analysis of GoA3/GoA4 system in order to identify safety and non-safety relevant building blocks.
- Security analysis.
The required FFFIS specifications shall specify the interchangeability and interoperability (Plug&Play).
Fully finalised FFFIS (Plug&Play) specifications will be delivered on the condition that underlying critical technology, relevant for that function/interface implementation, has reached the necessary level of maturity and is ready for product integration.
This activity will ensure alignment with the GoA1/2 System Requirement Specification" to ensure a separate independent system is not developed. This activity includes the specification of obstacle Detection system which will also be delivered to and used by IP5 (ARCC project) and SMART-2 project. Joint meetings are foreseen.
This activity includes the interface specification with the Rolling Stock. This will be done jointly with IP1 (CONNECTA project). Joint meetings are foreseen.
For localisation principles, we will refer to the results of TD2.4 (Positioning).
This activity includes specific review and update of the GoA3/4 specification considering Freight application.
This WP will provide when needed the required expertise to support WP2 in the execution of its task 2.4

WP04 - “ATO up to GoA4” Development

The following companies will develop ATO prototypes:
ALS    STS    BT    CAFS    TD    AZD
These companies will:
- develop an ATO on-board prototype (TRL 6-7) considering different type of trains (electric or diesel/electric) and different type of operation (High Speed Line, Low Traffic/Regional Lines, Urban/Suburban);
- develop an ATO trackside prototype (TRL 6-7);
- develop or integrate obstacle detection and environment sensors
The ATO prototypes will include:
- Passenger Exchange, door opening/closing, safe departure
- Incident & Emergency detection and management
- Localisation.
- Remote Control supporting degraded modes
These prototypes need to be compliant with the functional and vendor independent reference specification and will be used to demonstrate agreed interoperability and agreed interchangeability of the prototypes provided by different suppliers.
Task 4.1 – Technical Coordination and System Integration (Leader: ALS, Participants: SMO, STS, AZD, BTSE, CAFS,  TD, TRV)
ALS as technical leader will carry out the overall WP coordination supported by the task leaders.
Task 4.2 – GoA3/4 Protype Development (Leader: ALS, Participants: STS, AZD, BTSE, CAFS,TD)
The companies mentioned above will develop their prototypes in compliance with the functional and vendor independent reference specification
All of them envisage to develop trackside and on-board part of the GoA3/4 ATO. The hardware platform will be partner specific; but all of them will comply with the functional and performance requirement delivered by WP3.
Task 4.3 – “Obstacle detection” and “environment sensors” development (Leader: ALS, Participants: STS, AZD, BTSE, CAFS, DB, TD)
The companies mentioned before will develop prototypes for obstacle detection and environment sensors .
Based on the specifications developed in Task 3.3, obstacle detection prototypes will include FFFIS (Plug & Play) Interface to ATO-OB.
The use of this “plug&play” interface is making the “obstacle detection” solution independent from the used technologies. At the present stage, the technologies considered by the different partners mentioned above are not declared. But, as much as possible, they envisage to use diverse technologies achieving the same functional requirement and compliant with the FFFIS interface.
Obstacle detectors developed in the context of WP4 will be used for “factory IOP tests” and “Pilot tests” as well. They will also be proposed to IP5 TD5.1.3. members in order to be tested in a specific freight environment.
Task 4.4 – GoA3/4 Reference Tests Bench (Leader: ALS, Participants: STS)
It is required to perform fully functional tests in order to demonstrate that the interoperability rules, interfaces specification and conformity with the functional and vendor independent reference specification are respected;
This task includes:
- development of upgraded Reference Test Bench;
- validation of the modified interoperability and interchangeability platform test bench;
- specification of the operational scenarios to be tested (including high speed, passenger and freight specific scenarios).
ALS and STS will develop Reference Test Benches.
This WP will provide when needed the required expertise to support WP2 in the execution of its task 2.4

WP05 - “ATO up to GoA4” Tests

It includes:
- The development or upgrade of Reference Test Benches required to perform interoperability tests in factory;
- Factory interoperability tests involving the prototypes developed by the different suppliers;
- On-site tests on Pilot Line and Pilot train involving the prototypes developed by the different suppliers in compliance with the functional and vendor independent reference Specification delivered in D3.2.
Task 5.1 – Technical Coordination and System Integration (Leader: ALS, Participants: SMO, STS, AZD, BTSE, CAFS, DB, SBB, MERMEC, NR, TD, SNCF-R, DB, TRV)
ALS as technical leader will carry out the overall WP coordination supported by the task leaders.
Task 5.2 – GoA3/4 Factory IOP tests (Leader: ALS, Participants: STS, AZD, BTSE, CAFS, DB, SBB, NR, TD, SNCF-R)
The aim of this activity is to perform interoperability and interchangeability tests as specified in operational scenarios defined in WP4. It includes the validation of AoE requirements (up to GoA3/4) using different ATO-OB  and ATO-TS prototypes;
The prototypes will include ATO-OB and ATO-TS. Common implementation with other TD functionalities (e.g. Satellite Positioning) will be analysed and performed in case feasible.
It is required to perform fully functional tests in order to demonstrate that the interoperability rules, interfaces (FFFIS (Plug & Play)) and conformity with the fully functional and vendor independent reference Specification are respected.
Task 5.3 – GoA3/4 Pilot tests (Leader: ALS, Participants: STS, AZD, BTSE, DB, SBB, NR, TD, SNCF-R, SZ)
The aim of this task is to validate AoE using pilot train and pilot line.
The S2R members will:
- host AoE prototypes on a pilot line and manage full functional pilot tests in order to demonstrate the overall functionality, interchangeability and interoperability of “ATO up to GoA4” solution.
- upgrade of 1 pilot train with AoE.
- upgrade of 1 pilot line with AoE.
- perform interoperability tests in accordance with operational scenarios.
- provide a remote driving pilot line demonstration.
This WP will provide when needed the required expertise to support WP2 in the execution of its task 2.4

TD 2.3 - Moving Blocks

Moving Block (TD 2.3) aims to improve line capacity by decoupling the signalling from the physical infrastructure, and removing the constraints imposed by trackside train detection, thereby allowing more trains on a given main line, especially for high-density passenger services. The system is to be compatible with existing ERTMS system specifications, and will enable progression towards CBTC functionalities for urban applications.

Implementation within IP2 projects


WP05 - Moving Block

The objective of the Moving Block Work Package is to define a high capacity, low cost, high reliability signalling system, based on Moving Block principles, which is applicable across all railway market segments. High Capacity is based on the use of Moving Block principles, which permits decoupling of the infrastructure from train performance parameters. Low Cost is achieved by the reduction in the use of trackside train detection and line-side signals. High Reliability is achieved as a consequence of the reduction in trackside equipment associated with trackside train detection and line-side signals.

The Work package will principally develop moving block operational and engineering rules, system specifications, a safety and security analysis and an application analysis.

WP2 - Safety analysis of Moving block signalling system

The main objective of the WP2 is to examine the safety level of a Moving Block system in view of complete removal of trackside detection.
  1. To prepare a model of the moving block signalling system suitable for Hazard Analysis;
  2. To define system use cases to be analysed;
  3. To identify hazards derived from possible system errors and faulty states in main operative conditions.
  4. To assess the resulting risk level derived from identified hazards (risk qualifying);
  5. To evaluate resulting safety level of a Moving Block signalling system operating without trackside train detection;
  6. To define Safety Related Application Conditions (operational procedures to be applied in normal or degraded conditions, according to GoAx, operational maintenance activities).

WP04 - Moving Block

The overall objective of the Moving Block Technical Demonstrator is to continue the work of defining a high capacity, low cost, high reliability signalling system, based on Moving Block principles, which is applicable across all railway market segments. High Capacity is based on the use of Moving Block principles, which permits decoupling of the infrastructure from train performance parameters. Low Cost is achieved by the reduction in the use of trackside train detection and line-side signals. High Reliability is achieved as a consequence of the reduction in trackside equipment associated with trackside train detection and line-side signals.

Within this Work Package, the objectives are as follows:
  1. To define the approach required for the testing of a Moving Block Signalling System
  2. To develop the deliverables from X2Rail-1 which define the Specifications for a Moving Block Signalling System.
  3. To provide Demonstrations of Moving Block Signalling Systems
  4. To investigate alternative future architectures for Moving Block Signalling Systems

WP1 - Operational Analysis of Train-Centric Signalling

Identify Operational procedures for Moving Block and Virtual Coupling signalling, which ensure safe train separation, especially in particularly critical areas such as stations and junctions.
  • Evaluate the Moving Block Operational and Engineering Rules and give recommendations for easier applications of Moving Block signalling systems or their evolution to a different traffic management approach. 
  • Highlight the impact to traditional signalling systems With these recommendations the impact on the existing signalling systems will be elaborated.

WP2 - Approaches for Testing Moving Block Signalling

  • Elicit supplier (product level testing), railway undertakings (system level operational testing) and railway safety agency (system level safety testing) functional requirements for the verification and validation of current and future moving block signalling systems (ETCS L3, CBTC, etc.);
  • Review existing work in the area of railway signalling product, system and safety simulation and testing, while also reviewing best-in-class related safety critical system testing and hardware-in-the-loop testing in other sectors (e.g. flyby- wire aero-engine control, autonomous automotive applications);
  • Develop an operational concept and testing strategy for the verification and validation of moving block signalling systems that draws on best practice and meets all stakeholder requirements;
  • Define an extensible architecture for testing moving block signalling systems;
  • Define interfaces for the different components in the testing architecture (e.g. simulation software, automated test routines, virtual and hardware signalling system components, comms. simulations, movement simulation, interfaces to other systems – joining lines, depots, etc.);
  • Develop example routines for automated testing.

TD 2.4 - Fail-Safe Train Positioning

Safe Train Positioning (TD 2.4) aims to develop a fail-safe, multi-sensor train positioning system (applying Global Navigation Satellite Systems (GNSS) technology to the current ERTMS/ETCS core and possible introducing an add-on for fulfilling the scope). It will enable the use of other new technologies (e.g. inertial sensors) or sensors (e.g. accelerometers, odometer sensors), to boost the quality of train localisation and integrity information, while also reducing overall costs, in particular by enabling a significant reduction in all trackside conventional train detection systems (balises, track circuits and axle counters).

Implementation within IP2 projects


WP1 - Introducing GNSS technology in the railway sector

The main overall target of WP1 is to analyse and transfer the applicable requirements and solutions from the Aviation domain to the railway domain, in particular for the application of Fail-Safe Train Positioning to Moving Block Signalling.

WP3 - Fail-Safe Train Positioning (including satellite technology)

The objective of WP3 is the development of a fail-safe, multi-sensor train positioning system by applying GNSS technology to the current ERTMS/ETCS core and by using new technologies (e.g. inertial measurement units) or of other on-board existing sensors (e.g. accelerometers, odometer sensors). This Fail-Safe Train Positioning will be specified, developed and verified to guarantee the backward compatibility with existing ERTMS systems and the key ERTMS interoperability requirements. The application of this Fail-Safe Train Positioning aims to boost the quality of train localization and integrity information, while also reducing overall costs, in particular by enabling a significant reduction in all track-side conventional train detection systems (balises, track circuits, axle counters, etc.).

WP1 - Project Management

The objectives of this WP are:
  • to ensure efficient coordination of the project together with the Technical Management Team;
  • to coordinate the technical work of the various WPs in order to keep the alignment with the overall objectives of the project;
  • to ensure efficient management of common consortium activities;
  • to ensure efficient overall administrative and financial management of the project;
  • to manage the internal and external communication, assessing and reporting on the progress made to EC and to partners;
  • to perform risk management, defining the risk mitigation strategies in order to achieve the complete project objectives in time;
  • to achieve a stringent collaboration with S2R-CFM-IP2-01-2018 call since beginning of the project to align objectives and maximise results.

WP2 - Railway Scenarios Requirements and Test Cases Definition

WP2 will define the requirements for railway regarding GNSS use, as well as the test cases for the performance evaluation. Global performances of the GNSS-based system are strictly related to railway scenarios that will determine required performances (e.g. MOPS) and are impacted by environmental factors (e.g., canyoning, multipath, interferences) affecting GNSS performances. Keeping in mind the ERTMS context of GATE4Rail (and the related S2R projects), which basically implies that GNSS is to be considered as a technological mean to implement virtual balises, the different market segments (main lines, regional urban/suburban and freight lines) will be addressed."

WP3 - Methodology Development of the GNSS Characterization in the Railway

The objective of WP3 is to define a comprehensive methodology and the associated tools able to characterise the GNSS performance into the railways application scenarios defined in WP2 in the framework of a VB detection in ETCS/ ERTMS context.
The developed methodology will allow to evaluate the effects of global and local GNSS faults on the properties of some Fail-Safe Train Positioning components (e.g. due to local effects as multipath, radio frequency interference, spoofing or global effects as satellite clock/ephemeris failure or multiple ones).
GNSS technologies are influenced by global as well as local hazards. By definition, global hazards will be shared by a large panel of users and are today well defined by global systems. Local hazards are caused by the infrastructure or vegetation around the track that creates blockages or multipath but also by interferers (intentional as well as nonintentional) that can degrade accuracy, availability and integrity of the GNSS solution.
Based on the state of the art, the methodology has to identify:
  • which effects of the railway environment have to be taken into account (local and global) and simulated in order to cover the main events that can occur during an operational scenario;
  • which parameters have to be tested to consider the effect of the receiver processing to deal with these effects;
  • which raw data will be used to process the PVT solution.
In addition to the methodology, the main tools and simulation blocks (as shown in the Virtualized Simulation and Verification Infrastructure architecture in Figure 1 12) required for implementing the virtualized test-bed required to support the characterization of GNSS in the railway will be defined.
Thus, the main goal of this WP will be to determine:
  • what are the main simulation blocks required for assessing the GNSS performance in the railway operational environment and then the end impact on virtual balise detection, considering the real train mission profiles.
  • the definition of the high level interfaces between the different blocks of the virtualized simulation and verification infrastructure, that will first simulate the GNSS behaviour in the rail scenarios of interest (selected in WP2) in nominal and fault conditions (considering the impact of the railway local environment on GNSS (signal blockage, multipath, foliage attenuation, EMI and intentional interferences (jamming, spoofing and meaconing (direct and network))) taking into account the main real operational ETCS phases (Start of Mission, Full Supervision and Staff Responsible), and then also its effect on PVT up to the VB detection.
This WP will be strictly related to WP4 (fully dedicated to design and test of the virtualized test-bed) and to WP5 (devoted to the development of the concept and methodology, together with the definition of the main tools, for automated update test environment) activities in order to realise a modular test-bed, reducing the need for re-assessments due to the upgrade so maintaining the simulation and testing environment in line with the latest evolutions such as: changing the hardware due to obsolescence or product enhancements; changing the software due to new functionality, upgrade of specifications.

WP4 - Geo-distributed Verification Infrastructure Set-up

The objectives of this WP are:
  • to identify the functional and operative requirements of the geographically distributed simulation and verification infrastructure, in terms of main blocks and interfaces among them, able to exploit the features of partners GNSS and ETCS/ERTMS laboratories;
  • to design, development and testing of the interfaces among the different the geo-distributed simulation and verification infrastructure connecting GNSS labs (GUIDE, M3SB, IFSTTAR and RDL) and ETCS/ERTMS ones (CEDEX). The design and development of the main modules of the GATE4Rail architecture will start from the tools already available in each GATE4Rail laboratory and taking into account the WP3 main outputs. The performance of the GATE4Rail virtualized simulation and verification infrastructure will be assessed considering the use cases and test cases defined in WP2.
This WP will be related to WP3 (where the main simulation GATE4Rail blocks together their respective tools, and the high level interfaces among these blocks will be defined), WP5 (devoted to the development of methodology, together with the definition of the main tools, for automated update test environment) activities and WP6 (fully devoted to development of methodology and tools, for integration, automated test repetition and evaluation). This WP shall rely on state on the state of the art of past and on-going projects, in which a virtualized simulation GNSS test-bed environment in the ERTMS context has been set for GNSS performance analysis (RHINOS), or a standard architecture for the lab testing has been defined in rail environment (including the interface specifications for connection between real equipment and lab tools and among different labs for remote testing together with ad hoc software tools for supporting automated lab testing (VITE)).
The activities of this WP will be carried out and strictly linked to X2Rail-2 WP3 and X2Rail-1 WP6.
At the end of WP, a final demo with the aim to test a real ERTMS equipment running over a specific line in Italy and in Spain will be performed to verify and assess the lab results. The GNSS will be simulated in nominal and fault conditions and the ERTMS OBU will be tested in a real operational mode.
This demo will show the functionalities and tools defined for automated update of test environment continuous integration, automated test repetition and evaluation defined in WP5 and WP6, respectively, taking into account the safety requirements from assessors as BVI

TD 2.5 - On-board Train Integrity

Train Integrity (TD 2.5) aims to specify and prototype an innovative on-board train integrity solution, capable of autonomous train-tail localisation, wireless communication between the tail and the front cab, safe detection (SIL4) of train interruption and autonomous power supply functionality without the deployment of any fixed trackside equipment. This functionality will be developed for those market segments (e.g. freight and low traffic lines) lacking such a function.

Implementation within IP2 projects


WP4 - On-board Train Integrity

The on-board train integrity (OTI) designed in WP4 will have the main goal to autonomously verify the completeness of the train, while train is in operation. If the train tail is advancing coherently with the front of the train and the distance between the first and the last pieces of rolling stock remains unchanged it means that all is working correctly. Otherwise, the on-board system will detect the loss of train integrity, will apply the defined actions and will inform the Radio Block Center (RBC).

The OTI system will also contribute to implement the concept of Moving Block delivered by on-board equipment. This will be a significant advantage not only in terms of capacity and shorter headways, but also in terms of removal of track infrastructures, reduction of maintenance costs and resiliency.

WP2 - TECHNICAL COHERENCE

The main objectives of this WP, regarding the activities linked with the IP2 TD 2.5 and TD 2.10, are to:
  1. Coordinate the technological and scientific orientation of the project and effectively deal with all technical risks and issues as they arise;
  2. Liaise with the relevant activities within the S2R JU concerning IP2 TD2.5 and TD2.10;
  3. Define the overall Functional Requirements;
  4. Collect the System Requirements of the “On-board Train Integrity solution” and “Trackside Energy Harvesting device for Object Controllers”;
  5. Write the requirements coming from the Engineering Rules and Maintenance needed for the overall System

WP3 - Communication Solutions

The overall objectives of WP3 are to investigate and develop methods of checking the integrity of a train, and design, simulate and prototype wireless communication platforms for sending information on and off board the train. The specific objectives are to:
  • Investigate the state of the art of train integrity and develop new and improved methods;
  • Define a SIL4 capable, secure and versatile network infrastructure allowing the wireless communication of information along a train in motion/operation;
  • Define a reliable and secure network infrastructure tor track-site communication capable of being powered by energy harvesting;
  • Keep a strong link to the findings from WP4 (Energy Harvesting Solutions) during all activities to guarantee seamless operation of all systems without relying on grid power;
  • Incorporate methods for car identification during train reassembly;
  • Establish interfaces to existing on and off train systems to allow a seamless integration into existing infrastructure

WP4 - Energy Harvesting Solutions

The activities of this WP are are linked to IP2 TD 2.5 and TD 2.10, the main objectives of this WP are:
  1. Provide a survey and analysis of energy harvesting technologies available or in development that could be capable of a reliable energy supply to on-board and trackside train integrity and signalling systems. Each energy harvester technology must be analysed in the context of an appropriate energy storage and power management solution. Consideration must be given to the environment and mounting locations of each technology and the possibility of sufficient power to deliver additional functionality in addition to train integrity such as derailment detection, hazardous cargo monitoring and train consist information during train composition.
  2. Analyse and develop the proposed on-board energy harvester, power storage and management solutions (available or new technologies) for potential compatibility with OTI solutions under development, according to the output of WP2.
  3. Develop or adapt the on-board solution that best meets these requirements, and work with WP5 to validate the developed solution.
  4. From the output of WP6 (economic model) and WP2 (technical requirements) identify energy harvesting solutions (including power storage and management) that can deliver safe and reliable power for trackside signalling functions.
  5. Develop the selected solutions as prototypes, and working with WP5 (testing) continue to develop and prove the solution(s) to deliver a prototype system capable of supporting trackside signalling applications.

WP5 - Prototype Development, Validation and Testing of the Proposed Solutions

The core objective of this call is to deliver energy harvester and antenna technologies that can provide energy and efficient radio communication to support on-board information transfer (including On Train Integrity (OTI)) and energy for trackside signalling functions. The objective for this work package is to integrate the energy harvesting and communication technologies selected and developed in previous work packages into prototypes, and test those prototypes to demonstrate/validate the effectiveness of the proposed solutions.
The specific objectives of this WP are as follows:
  • Develop integrated prototypes and test installations to enable testing of energy harvesting and communication technologies for the OTI system, as well as trackside energy harvesting technologies.
  • Develop detailed test scenarios for testing both the on-train and trackside prototypes.
  • Perform tests in laboratories and/or controlled environment.
  • Perform tests under conditions relevant to real operational conditions.
  • Analyse the performance of the proposed solutions

WP06 - On-Board Train Integrity: laboratory and validation activities completion

Task 6.1 - WP Technical Coordination (Leader: STS)
This task includes general coordination activities.
Task 6.2 – Laboratory and validation activities (Leader: CEIT; Partners: ALS, STS, AZD, BTSE, CAFS, DB, DLR, INDRA, MERMEC, NR, OBB, RAILENIUM, SNCF-R , SMO)
This task includes the following activities:
•    Complete laboratory testing activities with mock-ups and related validation tools for freight and regional lines, with the support of new technologies developed in X2Rail-2;
•     Complete laboratory testing activities related to adaptation of existing technologies for wireless communication suitable to NLOS situations, energy harvesting solutions and related energy storage;
•    Review of the FSM formal models with the partners responsible for the implementation to determine the relevant parameters to target for performance analysis;
•    Update the formal models developed to the different architectures/technologies investigated;
•    Perform the comparative study of the various investigated solutions using simulation and formal verification techniques (statistical model-checking);
•     Complete the RAMS analysis my means of conducting reliability, availability, maintainability, and safety (RAMS) studies in conformity with RAC (Risk Acceptance Criteria) guideline by ERA and CENELEC 50126 standard.
•     Complete the analysis of cost and benefit for the OTI from the X2Rail-2 project, considering further scenarios with regards to a) economic advantages when removing infrastructure elements for train integrity monitoring and b) capacity effects which are enabled based on OTI.
Sub-Task 6.2.1 – OTI demonstrator 1 (Leader: AZD)
This activity includes development of OTI demonstrator TRL4.
Sub-Task 6.2.2 – OTI demonstrator 2 (Leader: INDRA)
This activity includes development of OTI demonstrator TRL4.
Sub-Task 6.2.3 – OTI demonstrator 3 (Leader: MERMEC)
This activity includes development of OTI demonstrator TRL4.
Sub-Task 6.2.4 – OTI demonstrator 4 (Leader: STS)
This activity includes development of OTI demonstrator TRL4.
This WP will provide when needed the required expertise to support WP2 in the execution of its task 2.4.

WP07 - On-Board Train Integrity: Demonstration, assessment and standardization proposal

Task 7.1 - WP Technical Coordination (Leader: STS)
This task includes general coordination activities.
Task 7.2 – Demonstration and Assessment (Leader: RAILENIUM; Participants: STS, ALS, AZD, BTSE, CEIT, DB, DLR, INDRA, MERMEC, NR, OBB , SNCF-R , SMO, SZ )
This task includes the following activities:
•    Contribute to the integration and demonstration activities of the OTI prototype for freight & low traffic lines scenarios, starting from the laboratory simulations and tests, to the final test trial in a real environment;
•    Contribute to the development of a demonstration unit suitable for both regional and freight lines; Carry out laboratory tests and pilot line tests on a regional line, using the defined test scenarios and test cases;
•    Perform the preliminary safety assessments of candidate new solution and review test scenarios, test cases and procedures defined in X2R2 WP4;
•    Ensure that OTI solutions comply with the requirements a validation environment will be defined and implemented in a suitable laboratory. The simulation-based ETCS/ERTMS laboratory RailSiTe® as well as the mobile validation environment RailDriVE® will be prepared accordingly to be ready to test OTI solutions. Processes and tools for generic validation and verification are to be set up. The rules for the assessment of the train integrity simulation prototype (on-board locator, based on GNSS and the wireless communication) will be proposed for standardisation;
•    Perform dependability study for the candidate solution, developing the safety integrity level (SIL) allocation methodology to the new train integrity solution on different rail segments, assessing (performance and security evaluation included) innovative wireless communication technologies for train integrity, integrating dependability and safety requirements (e.g. SIL 4 requirements) and contributing to the safety case for certification and authorization;
•    Develop a set of assessment criteria for the process and the product derived by performing an independent safety analysis of OTI demonstrators of sub-tasks 7.2.1, 7.2.2 and 7.2.3.
•    Conduct the safety assessment for certification and authorization activity using audit and review techniques

In order to accompany the development of the on-board train integrity solutions up to TRL7, an outlook on the technology migration of the OTI shall be taken into account. The conditions for the rollout of the new technology will be different for the different market segments. Special attention shall be drawn on the freight sector since these trains are composed individually. It must be ensured that track access is guaranteed when conventional train integrity technology (e.g. axle counters) from the infrastructure will be removed. Based on the technology specifications from the X2Rail-2 project, one or more representative scenarios will be defined, the conditions analysed and possible scenarios for the technology migration developed and described.
Sub-Task 7.2.1 – OTI demonstrator 1 (Leader: AZD)
This activity includes development of OTI demonstrator up to TRL6-7.
Sub-Task 7.2.2 – OTI demonstrator 2 (Leader: INDRA)
This activity includes development of OTI demonstrator up to TRL6-7.
Sub-Task 7.2.3 – OTI demonstrator 4 (Leader: STS)
This activity includes development of OTI demonstrator up to TRL6-7.
Task 7.3 – Standardization Proposal (Leader: STS; Participants: ALS, AZD, BTSE, CEIT, DB, INDRA, MERMEC, NR, RAILENIUM, SNCF, SMO)
This task includes the following activities:
•    Providing an analysis of the impacts on the signalling system, by defining a preliminary proposal for standardization in relation to OTI interfaces (e.g. in the context of CCS and rolling stock. Since today the train integrity functionality is performed by track side equipment influencing the interlocking, the new architecture, interfaces and processes have to be rearranged taking into account the new solution developed (on-board detection).
This WP will provide when needed the required expertise to support WP2 in the execution of its task 2.4.

TD 2.6 - Zero on-site testing

The development of a new laboratory test framework (TD 2.6) comprises simulation tools and testing procedures for carrying out open test architecture with clear operational rules and simple certification of test results. It aims to minimise on-site testing (with the objective of zero on-site testing) by performing full laboratory test processes, even when systems comprise subcomponents of different suppliers. The test framework will also allow remote connection of different components/subsystems located in various testing labs.

Implementation within IP2 projects


WP06 - Zero on-site Testing

The objective of this WP is to standardise the testing scope and procedures for signalling and telecom systems in order to improve quality and interoperability, reduce significantly on-site testing as well as the time to market.

The work package aims at:
  • Assessing today’s practice of field testing, including benchmarking with other industries;
  • Defining a common framework for the test process, which will guide the decision between on-site, and lab/simulation tests;
  • Defining a dedicated system test architecture for lab testing supporting Zero On-sight Testing;
  • Standardizing interfaces and test processes to ensure reproducibility;
  • Fostering interoperability of products based on commercial tests;
  • Foster common engineering, operational rules and concepts;
  • Create an international platform for knowledge exchange and harmonisation of specifications and processes in order to ensure efficiency.

WP1 - Project Coordination: management of the consortium and external coordination

The objective of this work package is to implement appropriate mechanisms to complete the project on-time with the required quality and making the best possible use of available resources.

WP2 - Test process framework: analyse current situation and taking into account user’s need elaborate a new test process framework including an optimisation of the testing protocols

To define a test process framework that will support the shift of testing from site to lab optimising the test case coverage model and exchange of information.

WP3 - Lab architecture: define architecture and new modules and interfaces

Definition of specific lab architecture, based on existing solutions at national level, in coordination with S2R JU member’s participating in S2R-CFM-IP2-01-2015 – Zero on site testing framework.
Implementation of the specific lab architecture defined within this WP.

WP4 - Demonstration: carry out a demonstration of the feasibility of the architecture and method for test cases proposed

The overall objective of WP4 are the following points:
  • to define a demonstration plan and a set of common test specifications
  • to carry out 3 basic demos
  • to collect and analyse test results
  • to draft a test report
  • to prove lab testing capabilities of the architecture and methods proposed in WP2

The core of the test developed in this work is ERTMS but, as stated in the Shift2Rail Master Plan, the IT virtualization platform developed here will be generic and open to support the architecture for test environment and communication (e.g. RBC-RBC, RBC-IXL, IXL-IXL, etc)

Together with its main target, the demonstrator will combine multiple benefits, in particular:
  • Check of the effectiveness of the architecture and related interfaces developed in WP3;
  • Check of the effectiveness of the remote testing approach and specifications to meet the actual expectations of the railway sector;
  • Verification of the repeatability of the results obtained in different independent laboratories;
  • Preliminary check of the compatibility of a Spanish ETCS BL2 On board unit in commercial operation in the Spanish
  • HS network with the trackside with ETCS BL2 installed in an Italian line.

WP5 - Assessment of the test framework and methodology proposed

The objective of this WP is to assess the test process framework and architecture proposed in WP2 and WP3 and the results achieved in the demonstration in order to use it in the CCS APIS process.

WP6 - Dissemination: disseminate the findings of the project through workshops, conferences or other dissemination means as well as coordinating with other S2R activities

Dissemination of the findings to achieve maximum awareness in the railway industry by means of this website, linked in, participate in conferences. Also a close coordination with S2R and a collaboration agreement with another project belonging to IP2: X2RAIL-1

WP05 - Zero On-Site Testing

Due to the complexity of signalling systems and the differences between sites, a large amount of tests must be carried out on-site. On-site tests take about 5 to 10 times the effort compared to similar tests done in the lab. Reduction of on-site tests for signalling and telecom systems is hence a reasonable approach to reducing testing costs. Today’s procedures of verification & validation testing differ all around Europe. Overcoming these differences by standardizing the procedures and test scopes will improve the interoperability and reduce the time to market.
The objectives of this work package are:
  • Integration of the new functionalities from X2Rail-1 and X2Rail-2, next generation of communication, ATO, moving block, satellite positioning, train integrity, Traffic Management Integration Layer, Smart Wayside Object Controller and cyber security, to complete the general test architecture.
  • Definition of a generic communication model between the different components of the test environment(s) defined in X2Rail-1.
  • Development and validation of standardized interfaces between the products from the test environments of different suppliers and operators and between the test environments and the subsystems under test.
  • Specification of simulators to support automated testing in the lab and to remove the current technical limitations identified in X2Rail-1 and therefore to move more tests from site to lab.
  • Develop and validate the test environment(s) and needed simulators.

WP1 - Project Management

The objectives of this WP are:
  • to ensure efficient coordination of the project together with the Technical Management Team;
  • to coordinate the technical work of the various WPs in order to keep the alignment with the overall objectives of the project;
  • to ensure efficient management of common consortium activities;
  • to ensure efficient overall administrative and financial management of the project;
  • to manage the internal and external communication, assessing and reporting on the progress made to EC and to partners;
  • to perform risk management, defining the risk mitigation strategies in order to achieve the complete project objectives in time;
  • to achieve a stringent collaboration with S2R-CFM-IP2-01-2018 call since beginning of the project to align objectives and maximise results.

WP2 - Railway Scenarios Requirements and Test Cases Definition

WP2 will define the requirements for railway regarding GNSS use, as well as the test cases for the performance evaluation. Global performances of the GNSS-based system are strictly related to railway scenarios that will determine required performances (e.g. MOPS) and are impacted by environmental factors (e.g., canyoning, multipath, interferences) affecting GNSS performances. Keeping in mind the ERTMS context of GATE4Rail (and the related S2R projects), which basically implies that GNSS is to be considered as a technological mean to implement virtual balises, the different market segments (main lines, regional urban/suburban and freight lines) will be addressed."

WP3 - Methodology Development of the GNSS Characterization in the Railway

The objective of WP3 is to define a comprehensive methodology and the associated tools able to characterise the GNSS performance into the railways application scenarios defined in WP2 in the framework of a VB detection in ETCS/ ERTMS context.
The developed methodology will allow to evaluate the effects of global and local GNSS faults on the properties of some Fail-Safe Train Positioning components (e.g. due to local effects as multipath, radio frequency interference, spoofing or global effects as satellite clock/ephemeris failure or multiple ones).
GNSS technologies are influenced by global as well as local hazards. By definition, global hazards will be shared by a large panel of users and are today well defined by global systems. Local hazards are caused by the infrastructure or vegetation around the track that creates blockages or multipath but also by interferers (intentional as well as nonintentional) that can degrade accuracy, availability and integrity of the GNSS solution.
Based on the state of the art, the methodology has to identify:
  • which effects of the railway environment have to be taken into account (local and global) and simulated in order to cover the main events that can occur during an operational scenario;
  • which parameters have to be tested to consider the effect of the receiver processing to deal with these effects;
  • which raw data will be used to process the PVT solution.
In addition to the methodology, the main tools and simulation blocks (as shown in the Virtualized Simulation and Verification Infrastructure architecture in Figure 1 12) required for implementing the virtualized test-bed required to support the characterization of GNSS in the railway will be defined.
Thus, the main goal of this WP will be to determine:
  • what are the main simulation blocks required for assessing the GNSS performance in the railway operational environment and then the end impact on virtual balise detection, considering the real train mission profiles.
  • the definition of the high level interfaces between the different blocks of the virtualized simulation and verification infrastructure, that will first simulate the GNSS behaviour in the rail scenarios of interest (selected in WP2) in nominal and fault conditions (considering the impact of the railway local environment on GNSS (signal blockage, multipath, foliage attenuation, EMI and intentional interferences (jamming, spoofing and meaconing (direct and network))) taking into account the main real operational ETCS phases (Start of Mission, Full Supervision and Staff Responsible), and then also its effect on PVT up to the VB detection.
This WP will be strictly related to WP4 (fully dedicated to design and test of the virtualized test-bed) and to WP5 (devoted to the development of the concept and methodology, together with the definition of the main tools, for automated update test environment) activities in order to realise a modular test-bed, reducing the need for re-assessments due to the upgrade so maintaining the simulation and testing environment in line with the latest evolutions such as: changing the hardware due to obsolescence or product enhancements; changing the software due to new functionality, upgrade of specifications.

WP4 - Geo-distributed Verification Infrastructure Set-up

The objectives of this WP are:
  • to identify the functional and operative requirements of the geographically distributed simulation and verification infrastructure, in terms of main blocks and interfaces among them, able to exploit the features of partners GNSS and ETCS/ERTMS laboratories;
  • to design, development and testing of the interfaces among the different the geo-distributed simulation and verification infrastructure connecting GNSS labs (GUIDE, M3SB, IFSTTAR and RDL) and ETCS/ERTMS ones (CEDEX). The design and development of the main modules of the GATE4Rail architecture will start from the tools already available in each GATE4Rail laboratory and taking into account the WP3 main outputs. The performance of the GATE4Rail virtualized simulation and verification infrastructure will be assessed considering the use cases and test cases defined in WP2.
This WP will be related to WP3 (where the main simulation GATE4Rail blocks together their respective tools, and the high level interfaces among these blocks will be defined), WP5 (devoted to the development of methodology, together with the definition of the main tools, for automated update test environment) activities and WP6 (fully devoted to development of methodology and tools, for integration, automated test repetition and evaluation). This WP shall rely on state on the state of the art of past and on-going projects, in which a virtualized simulation GNSS test-bed environment in the ERTMS context has been set for GNSS performance analysis (RHINOS), or a standard architecture for the lab testing has been defined in rail environment (including the interface specifications for connection between real equipment and lab tools and among different labs for remote testing together with ad hoc software tools for supporting automated lab testing (VITE)).
The activities of this WP will be carried out and strictly linked to X2Rail-2 WP3 and X2Rail-1 WP6.
At the end of WP, a final demo with the aim to test a real ERTMS equipment running over a specific line in Italy and in Spain will be performed to verify and assess the lab results. The GNSS will be simulated in nominal and fault conditions and the ERTMS OBU will be tested in a real operational mode.
This demo will show the functionalities and tools defined for automated update of test environment continuous integration, automated test repetition and evaluation defined in WP5 and WP6, respectively, taking into account the safety requirements from assessors as BVI

TD 2.7 - Formal methods and standardisation for smart signalling systems

The development of a set of standardised engineering and operational rules (TD 2.7) aims to contribute to the creation of an open standard interface (if supported by positive business cases) and a functional ETCS description model, all based on formal methods. It will ease verification and authorisation processes, eventually leading to improved interoperability, while reducing the need for extensive field tests in future.

Implementation within IP2 projects


WP4 - Formal Methods for the railway field

Identify the most suitable semi-formal and/or formal language and formal method to be applied in the railway field Despite the quite long story of successful application of formal methods in the railway domain, it cannot be yet said that a single mature technology has emerged; indeed, any proposed method or technique that goes under the umbrella of formal methods varies in its suitability and applicability to different stages of the signalling system development, and to different subdomains of railway signalling (interlocking, ATP, ATS, etc.).
This work package aims to identify, on the basis of an analysis of the state of the art, of the past experiences of the involved partners and of work done in previous projects as for example, MOD-CONTROL, EurailCheck, Cesar, Eurointerlocking, INESS, EULYNX, OpenETCS the candidate set of formal and semi-formal techniques that appear as the most adequate to be used in the different phases of the conception, design and development of a railway equipment in general, and of the class of signalling equipment that is the subject of this project in particular.

WP5 - Formal Methods and standardization for smart signalling systems

The Formal Methods designed in WP5 will have the main goal to propose suitable formal methods for requirement capture, design, verification and validation of railway signalling systems and applying for development of signalling systems with standardized interfaces and operational scenarios.

WP2 - Demonstrator Development for the use of Formal Methods in Railway Environment

The main objective of WP2 is to propose a demonstrator of state-of-the-art formal methods to evaluate the learning curve and to perform a cost/benefit analysis of the adoption of formal methods in the railway industry.

TD 2.8 - Virtually – Coupled Train Sets

Virtual Coupling (TD 2.8) aims to enable ‘virtually coupled trains’ to operate much closer to one another (within their absolute braking distance) and dynamically modify their own composition on the move (virtual coupling/uncoupling of train convoys), while ensuring at least the same level of safety as is currently provided.

Implementation within IP2 projects


WP06 - Virtually Coupled Trains - 1

This activity addresses the increment of network capacity, beyond the limitation of the current signalling approach for train and units separation. Increased capacity is today needed for many networks in Europe. Building new lines or adding tracks to existing lines is a slow and expensive process. Furthermore, decoupling, shunting and coupling is a key feature of the traditional railway system. Virtual Coupling can help to bolster the competitiveness of rail as regards flexible and timely operation on demand.

In this context, this Work package aims at defining the overall functional, performance and safety requirement of the VCTS, identifying the possible technological architecture of the solution as well as characterizing the functionality and its business case.

WP6 will target the overall functional requirements and safety analysis of the solution while WP7 will focus on the technological solution, and thus the associated business case

WP07 - Virtually Coupled Trains - 2

This activity addresses the increment of network capacity, beyond the limitation of the current signalling approach for train and units separation. Increased capacity is today needed for many networks in Europe. Building new lines or adding tracks to existing lines is a slow and expensive process. Furthermore, decoupling, shunting and coupling is a key feature of the traditional railway system. Virtual Coupling can help to bolster the competitiveness of rail as regards flexible and timely operation on demand.

In this context, this Work package aims at defining the overall functional, performance and safety requirement of the VCTS, identifying the possible technological architecture of the solution as well as characterizing the functionality and its business case.

WP6 will target the overall functional requirements and safety analysis of the solution while WP7 will focus on the technological solution, and thus the associated business case

WP3 - Communication Technology for Virtual Coupling

  • Identify appropriate Virtual Coupling technical communication solutions by reviewing previous studies and projects and analysing these against requirements for this work package.
  • Assess and identify proposals for Virtual Coupling technical communication solutions facilitating business analysis and exploitation road map.
  • Investigate the application, solutions and dynamics of automated car driving and evaluate the applicability to the railway field.

WP4 - Business Analysis of Virtual Coupling

  • Identify the potential markets and scenarios of the Virtual Coupling concept
  • Provide a cost-effectiveness analysis (CEA) for Virtual Coupling
  • Provide a roadmap and business Risk Analysis for the introduction of Virtual Coupling

TD 2.9 - Traffic management system

An optimised Traffic Management System (TD 2.9) aims to improve traffic management operations with automated processes for data integration and exchange with other rail business services. The backbone of the new architecture will be a scalable, interoperable and standardised communication structure applicable within an integrated rail services management system. These features will be combined with new business service applications (e.g. advanced driver advisory system, or intelligent, automated and flexible dispatching systems including conflict detection and resolution) to allow for predictive and dynamic traffic management in both regular and degraded situations. It will use and integrate real-time status and performance data from the network and from the train, using on-board train integrity solutions and network object control functions, supported by wireless network communication.

Implementation within IP2 projects


WP6 - Traffic Management evolution

The Traffic Management Evolution in WP6 is the first system design integrating all rail operation track-side based services. The heart of the entire system is the Integration layer linking the different Rail operation services amongst one another, with the infrastructure/vehicles and with external clients. Therefore the key interfaces will be standardized to secure compatibility and long-term applicability of all existing and new subsystems. The integration of legacy installations with different data structures will be covered. The Integration layer will provide a standardized scalable data-format to secure seamless and automated data exchange between the different clients to enable the integration of dynamically updated data from various services into a decision-making processes. This generic Trackside ICT is one of the key enabler to achieve the different targets of S2R such as capacity increase, cost reduction and increase of reliability of rail traffic operation.

The new Traffic Management will carry the development of a generic framework for applications allowing plug and play installation, a standardized multi-purpose workstation and advanced business logic applied for traffic regulation and operation covering the need for improving existing procedures and enabling the execution of new functionalities such as ATO and Moving Block developed under the S2R program to secure an increase of capacity and a reduction of cost.

WP08 - TMS services

The works carried out under this workstream are jointly undertaken from the involved partners.
Task 8.1 - Technical Coordination (Leader: DB, Participants: NR, TRV, SNCF-R, CAFS, INDRA, HC, SMO, STS)
Periodic meetings led by the WP Leader and the Task Leaders/partners to secure and monitor the progress of the activities. This task shall also align the different activities of the work package with other related work streams of S2R and coordinate interoperability of the different solutions developed.
Task 8.2 - Use cases for advanced TMS principles (Leader: NR, Participants: DB, TRV, SNCF-R, CAFS, INDRA, HC, TD, AZD)
Finalise the activities of task 6.4 (deliverable D6.3) of X2Rail-2 work package 6. The task will decide on a specific presentation format for the use cases building on from D6.3. This will include:
- Review and update of uses cases from D6.3
- Updated relevant use cases for degraded mode considerations
- Development of functional specification for TMS for the selected use cases, this will include considering any relevant lessons learnt from for example prototypes as they develop, other relevant tasks
Task 8.3 - Automated conflict handling solution (Leader: DB, Participants: NR, TRV, SNCF-R, CAF, INDRA, HC, SBB , RAILENIUM, TD, ALS, SMO, STS, AZD, SZ)
The conflict resolution solution shall be able to automatically calculate a re-plan after a complex disruption like the closure of a railway line in a dense network.
The solution shall be able to take multiple criteria into account
- Current positions of trains
- Re-routing options, incl. train characteristics
- Unit cycles or upcoming maintenance show-ups for units
- Crew cycles or passenger flows
The solution shall be able to provide several solutions with clear indicators (KPIs) attached to them and all information necessary to allow the operator to decide the most appropriate solution.
Task 8.4 - Large scale optimisation methods (Leader: DB, Participants: NR, TRV, SNCF-R, RAILENIUM, CAFS, INDRA, HC, ALS, STS, AZD)
The task shall identify most promising mathematical methods that will allow in future to use automation and optimisation on a much larger scale. The currently available methods for optimisation of train movements, especially for disruption management, have limits in the number of trains and complexity of the network and considered criteria (KPIs) they are able to take into consideration. This is to an extent that makes usage in large networks still impractical and impacts negatively network capacity and service quality, especially when trying to recover from serious disruptions.
This research task shall test and evaluate new approaches from Operations Research as well as Artificial Intelligence – or the combination of both – for their potential to scale up automation and optimisation of train movements for larger networks and more KPIs, e.g. for network capacity, service quality, cost and/or energy consumption.
The new approaches will aim to coordinate conflict resolution in different areas. They will be independent of the conflict resolution method used in each area, so to make possible to use different methods for areas with different characteristics.
Task 8.5 – Methods and measures for assessment of workload and situation awareness (Leader TRV, Participants: NR, DB, SNCF-R, CAFS, TD, AZD)
This task shall assess and validate the most promising methods and measures developed during X2R-2 for evaluating human performance on new TMS products and prototypes, as an integral part of system performance.
- Evaluate the methods for assessing workload and situation awareness in a simulated environment, using the different operation modes (from normal to emergency)
- Describe and develop a toolbox of methods for mapping and evaluating operator preconditions related with sub-optimal performance, for different stages of the product development process.
- If methods are effective, they could be used to support a proof of concept.
This WP will provide when needed the required expertise to support WP2 in the execution of its task 2.4.

WP09 - TMS Demonstrators TRL4

The works carried out under this workstream are based on the results from X2R2 WP6 project. Updates of specifications and the design of a new architecture are done jointly amongst the partners. The proposed non-collaborative demonstrators will be developed to reach TRL4. The design of the demonstrators are managed directly from the Partners. If required, Partners can agree for a joint or partially combined development of demonstrators.
Task 9.1 – Technical Coordination for the design of the demonstrators TRL4 (Leader: BTSE, Participants: STS, NR, SMO, TD, TRV, AZD, HC, DB, INDRA)
Periodic meetings led by the WP Leader and all partners of the work package will be held to secure and monitor the progress of the specification and development activities, the implementation strategy of the works performed under the OC S2R-OC-IP2-02-2019: “Support of the development of demonstrator platform for Traffic Management” and to align the cooperation with other S2R projects and Work Packages (e.g. ATO GOA3/4).
The work package leader will prepare all necessary reports, plans for the S2R IP2 coordinator and S2R JU and will attend TMT meetings of X2R4 to represent the work package.
Task 9.2 – Integration Layer and System Architecture (Leader: BTSE, Participants: STS, NR, SMO, TD, TRV, AZD, DB, HC, INDRA)
The development of the demonstrators related to the TMS workstream is based on specifications delivered from X2R2 project. The activities of this task represent the platform to flag required changes/amendments/enhancements of the SRS of the Integration Layer to the WP. The Partners involved in this activity monitor the change requests, specify necessary enhancements/amendments and deliver the changes to the Canonical Data Model (CDM) work package to be implemented in the design of the S2R CDM.
The works include further the specification/description of a comprehensive functional system architecture for TMS, Traffic and ATO Control. A close cooperation with the work packages specifying the generic ATO GOA3/4 and Moving Block/fixed virtual Block basic operational procedures will secure interoperability, standardization and flexibility of the architecture.
Task 9.3 - Development and Verification of demonstrators TRL4 (Leader BTSE; Participants: STS, NR, SMO, TD, TRV, AZD, HC, INDRA)
The objective of this task is to develop prototypes TRL4. Demonstrators are allocated to partners and shall follow the basic requirements defined in the deliverables of X2R4 WP6. Each demonstrator proposed will be designed and delivered by one partner.
Regular status updates demonstrating the progress of the design activities will be part of Task 1 of this work package.
All necessary activities related to the design of the prototypes shall follow the guidelines described in D6.4 of X2R2 WP6.
At the end of the design phase, the partners will provide reports for each demonstrator. These reports will be verified for completeness as required from the data management plan created in WP1 and will be consolidated into a summary report.
Sub-task - 9.3.1 Demonstrator TRL4 for Connected Driver Advisory System (Partner: STS)
The scope of work of this task is the development of a prototype that implements the computation of speed profile and driving modalities to feed a Connected Driver Advisory System (C-DAS); the development includes the definition of interfaces between the TMS and modules that provides the DAS functionalities. The work is based on the outcome of task 5.6.2 of .X2Rail-2 WP6.
Sub-task - 9.3.2 Demonstrator TRL4 for Conflict Prediction System (Partner: AZD)
This task focusses on the design of a prototype demonstrating complex Conflict Prediction System. The application will be realized by specifying and developing specific tools for handling regular and irregular traffic issues.
Sub-task - 9.3.3 Demonstrator TRL4 for Wayside ATO constituents (Partner: BTSE)
The demonstrator developed under this task addresses the design of constituents needed for ATO GOA2 operation based on data management based on the integration Layer. The works comprise the subsystems and Interfaces needed to read data from the Integration Layer to create a JP and SP, the business function to create these profiles in CDM and the necessary processes to make these messages available at the API linking the ATO -TS to the Integration Layer.
Sub-task - 9.3.4 Demonstrator TRL4 for Integration of field status information (Partner: HC)
This task aims at the development of a Demonstrator (TRL4) for modules for integrating field status information from trains, asset and train control into one single, consistent data source; train forecast calculation; possession management module for (re-)planning of maintenance activities and impacted trains; interfaces for data exchange with external resource management, train request and information services.
Sub-task - 9.3.5 Demonstrator TRL4 for TMS Business Applications (Partner: INDRA)
This task covers the provision of a TRL4 demonstrator based on TMS Business Applications focused on the mitigation of the impact that traffic disturbances and unexpected infrastructure restrictions generate into the traffic evolution. Under these circumstances, for instance, the evolution of the scheduled maintenance works on the facilities are considered, as well as additional required actions arisen during the traffic operation based on the modification of the scheduled trains behaviour.
The implemented prototypes will be based on the Proofs of Concept performed in the X2RAIL-2 and they will expose a modular architecture complying with the specified Integration Layer and its Application Programme Interface in a laboratory environment and using a common data model.
Sub-task - 9.3.6 Demonstrator TRL4 for Conflict Detection and Resolution (Partner: SMO)
This task addresses the specification and development of business service applications for the detection of future conflicts, the presentation of the results to the operator and conflict resolution measures and integration them into operator's workflow. The SW application modules will be hosted in an Application Framework.
Sub-task - 9.3.7 Demonstrator TRL4 for Application Modules (Partner: TD)
The works proposed for this task address the demonstration of use cases identified in Task 6.6 of X2R2 WP6. The prototypes describes the scenario for interaction between an Asset Management System (AMS) and TMS with the goal to perform TMS re-planning services based on early indication of an actual failure or a predicted failure of a railway asset, for example a set of points affecting the capacity of a station. As the proposals are assessed the Plans may be communicated with Rolling Stock and/or Crew systems to ensure they can be resourced. The prototype will include transfer of data between the Integration Layer and selected features of the Standard Operator Workstation (from X2RAIL2 D6.5) including third party application HMI integration and external interface to weather data.
This WP will provide when needed the required expertise to support WP2 in the execution of its task 2.4.

WP10 - TMS Demonstrators TRL6

The works carried out under this workstream shall boost the demonstrators started in WP9 from TRL 4 to reach TRL6 at the end the project.
Task 10.1 - Technical Coordination for the design of the demonstrators TRL6 (Leader: BTSE, Participants: STS, NR, SMO, TD, TRV, AZD, DB, HC, INDRA)
Periodic meetings led by the WP Leader and all partners of the work package will be held to secure and monitor the progress of the specification and development activities, the implementation strategy of the works performed under the OC S2R-OC-IP2-02-2019: “Support of the development of demonstrator platform for Traffic Management” and to align the cooperation with other S2R projects and Work Packages (e.g. ATO GOA3/4).
The work package leader will prepare all necessary reports, plans for the S2R IP2 coordinator and S2R JU and will attend TMT meetings of X2R4 to represent the work package.
Task 10.2 Development and Verification of demonstrators TRL6 (Leader BTSE; Participants: STS, NR, SMO, TD, TRV, AZD, HC, INDRA)
The objective of this task is to process the design of the prototypes TRL4 started in WP8 to TRL6 at the end of the project. Each demonstrator proposed will be designed and delivered by one partner.
Regular status updates demonstrating the progress of the design activities will be part of Task 1 of this work package.
All necessary activities related to the design of the prototypes shall follow the guidelines described in D6.4 of X2R2 WP6.
At the end of the design phase, the partners will provide reports for each demonstrator. These reports will be verified for completeness as required from the data management plan created in WP1 and will be consolidated into a summary report.
Sub-task Task - 10.2.1 Demonstrator TRL6 for Connected Driver Advisory System (Partner: STS)
The scope of work of this task is the development of a prototype that implements the computation of speed profile and driving modalities to feed a Connected Driver Advisory System (C-DAS); the development includes the definition of interfaces between the TMS and modules that provides the DAS functionalities. The work is based on the outcome of task 5.6.2 of .X2Rail-2 WP6.
Sub-task - 10.2.2 Demonstrator TRL6 for Conflict Prediction System (Partner: AZD)
This task focusses on the to design a prototype demonstrating complex Conflict Prediction System. The application will be realized by specifying and developing specific tools for handling regular and irregular traffic issues.
Sub-task - 10.2.3 Demonstrator TRL6 for Wayside ATO constituents (Partner:  BTSE)
The demonstrator developed under this task addresses the design of constituents needed for ATO GOA2 operation based on data management based on the integration Layer. The works comprise the subsystems and Interfaces needed to read data from the Integration Layer to create a JP and SP, the business function to create these profiles in CDM and the necessary processes to make these messages available at the API linking the ATO -TS to the Integration Layer.
Sub-task - 10.2.4 Demonstrator TRL6 for Integration of field status information (Partner: HC)
This task aims at the development of a Demonstrator  for modules for integrating field status information from trains, asset and train control into one single, consistent data source; train forecast calculation; possession management module for (re-)planning of maintenance activities and impacted trains; interfaces for data exchange with external resource management, train request and information services."
Sub-task - 10.2.5 Demonstrator TRL6 for TMS Business Applications (Partner: INDRA)
This task covers the provision of a demonstrator based on TMS Business Applications focused on the mitigation of the impact that traffic disturbances and unexpected infrastructure restrictions generate into the traffic evolution. Under these circumstances, for instance, the evolution of the scheduled maintenance works on the facilities are considered, as well as additional required actions arisen during the traffic operation based on the modification of the scheduled trains behaviour.
The implemented prototypes will be based on the Proofs of Concept performed in the X2RAIL-2 and they will expose a modular architecture complying with the specified Integration Layer and its Application Programme Interface in a laboratory environment and using a common data model.
Sub-task - 10.2.6 Demonstrator TRL6 for Conflict Detection and Resolution (Partner: SMO)
This task addresses the specification and development of business service applications for the detection of future conflicts, the presentation of the results to the operator and conflict resolution measures and integration them into operator's workflow. The SW application modules will be hosted in an Application Framework.
Sub-task - 10.2.7 Demonstrator TRL6 for Application Modules (Partner: Thales)
The task will continue the development of a number of the Thales prototypes developed in WP9 Task 9.3.7 to TRL6. This will include the deployment of environments for the Integration Layer, Core Operation Workstation and TMS and Asset Management applications. In particular the interaction between the TMS providing early indication of asset failure on the Integration Layer and selected features of the Standard Operator Workstation (from X2RAIL2 D6.5) including third party application HMI integration.
This WP will provide when needed the required expertise to support WP2 in the execution of its task 2.4.
Each partner developing a prototype in the frame of this WP10 will provide to WP13 a “confidential information free” presentation/technical description of its prototype to be used during X2Rail-4 final event.

WP2 - System Architectures, Technical Coherence and alignment with Shift2Rail

This WP is based on a proven project management and technical co-ordination methodology. 

WP3 - Delivery of Hardware and Software

WP5 - Integration of business clients/services

Work Package 5 addresses Open Call Work stream 3. The goal is the integration of the different business clients/services with the Integration Layer. This will be achieved by mapping function and data of specific formats to a CDM and all necessary administrative processes to manage the clients/services

WP6 - Conceptual Data Model and Database Configuration

The first objective of WP6 is to provide a usable and adaptable data management system for the TMS, in time for system tests and validation under WP7.

WP7 - Testing and validation of the system

Work Package 7 will develop and implement a test programme to validate the Communication Platform as a whole, i.e., integrated with traffic management system modules, external services and databases from the traffic management demonstrator platform

TD 2.10 - Smart radio-connected all-in-all wayside objects

Smart radio-connected all-in-all wayside objects (TD 2.10). This TD aims to develop autonomous, complete, intelligent, self-sufficient smart equipment (‘boxes’) able to connect not only with control centres (e.g. interlocking) or other wayside objects and communicating devices in the area (by radio or satellite), but also, for instance, with on-board units. Such intelligent objects — knowing and communicating their status conditions — would not only provide opportunities in terms of cost reduction and asset management improvement, but also set out new means of railway network information management and control.

Implementation within IP2 projects


WP07 - Smart Wayside Objects

The overall scope of this work package is to contribute to the development of an autonomous, intelligent, maintenance free smart equipment (“box”) able to connect with any signalling wayside object and communicating device in the area (by radio or satellite) in order to foster overall reduction both of installation and maintenance costs. The objective of this work package is to arrive at definitions and specification of practical demonstrations of prototypes. The WP’s detailed objectives are as follows:
  • Specifications for Smart wayside objects;
  • Develop concepts for locally derived power supply;
  • Develop concepts for the overall reduction of power consumptions and required cabling;
  • Specify data exchange with existing and/ or new control systems (Traffic Management System/Interlocking/On-board Unit)
  • Specification of maintenance data over high capacity communication links to allow better diagnosis and maintenance

WP2 - TECHNICAL COHERENCE

The main objectives of this WP, regarding the activities linked with the IP2 TD 2.5 and TD 2.10, are to:
  1. Coordinate the technological and scientific orientation of the project and effectively deal with all technical risks and issues as they arise;
  2. Liaise with the relevant activities within the S2R JU concerning IP2 TD2.5 and TD2.10;
  3. Define the overall Functional Requirements;
  4. Collect the System Requirements of the “On-board Train Integrity solution” and “Trackside Energy Harvesting device for Object Controllers”;
  5. Write the requirements coming from the Engineering Rules and Maintenance needed for the overall System

WP3 - Communication Solutions

The overall objectives of WP3 are to investigate and develop methods of checking the integrity of a train, and design, simulate and prototype wireless communication platforms for sending information on and off board the train. The specific objectives are to:
  • Investigate the state of the art of train integrity and develop new and improved methods;
  • Define a SIL4 capable, secure and versatile network infrastructure allowing the wireless communication of information along a train in motion/operation;
  • Define a reliable and secure network infrastructure tor track-site communication capable of being powered by energy harvesting;
  • Keep a strong link to the findings from WP4 (Energy Harvesting Solutions) during all activities to guarantee seamless operation of all systems without relying on grid power;
  • Incorporate methods for car identification during train reassembly;
  • Establish interfaces to existing on and off train systems to allow a seamless integration into existing infrastructure

WP4 - Energy Harvesting Solutions

The activities of this WP are are linked to IP2 TD 2.5 and TD 2.10, the main objectives of this WP are:
  1. Provide a survey and analysis of energy harvesting technologies available or in development that could be capable of a reliable energy supply to on-board and trackside train integrity and signalling systems. Each energy harvester technology must be analysed in the context of an appropriate energy storage and power management solution. Consideration must be given to the environment and mounting locations of each technology and the possibility of sufficient power to deliver additional functionality in addition to train integrity such as derailment detection, hazardous cargo monitoring and train consist information during train composition.
  2. Analyse and develop the proposed on-board energy harvester, power storage and management solutions (available or new technologies) for potential compatibility with OTI solutions under development, according to the output of WP2.
  3. Develop or adapt the on-board solution that best meets these requirements, and work with WP5 to validate the developed solution.
  4. From the output of WP6 (economic model) and WP2 (technical requirements) identify energy harvesting solutions (including power storage and management) that can deliver safe and reliable power for trackside signalling functions.
  5. Develop the selected solutions as prototypes, and working with WP5 (testing) continue to develop and prove the solution(s) to deliver a prototype system capable of supporting trackside signalling applications.

WP5 - Prototype Development, Validation and Testing of the Proposed Solutions

The core objective of this call is to deliver energy harvester and antenna technologies that can provide energy and efficient radio communication to support on-board information transfer (including On Train Integrity (OTI)) and energy for trackside signalling functions. The objective for this work package is to integrate the energy harvesting and communication technologies selected and developed in previous work packages into prototypes, and test those prototypes to demonstrate/validate the effectiveness of the proposed solutions.
The specific objectives of this WP are as follows:
  • Develop integrated prototypes and test installations to enable testing of energy harvesting and communication technologies for the OTI system, as well as trackside energy harvesting technologies.
  • Develop detailed test scenarios for testing both the on-train and trackside prototypes.
  • Perform tests in laboratories and/or controlled environment.
  • Perform tests under conditions relevant to real operational conditions.
  • Analyse the performance of the proposed solutions

WP6 - Economic Modeling

The overarching goal of WP6 is to investigate economic models for the energy harvesting systems meant to provide the suitable energy supply for trackside signalling equipment in order to minimize cables and trackside infrastructure. Making reference to the Call requirements, WP6 is situated in work stream 2 on trackside energy harvesting systems for object controller. Along these lines, WP6 intends to fulfil – in concert with WP4 – the objectives of the ETALON project by providing economic insights on the technological opportunities ushered-in by trackside energy harvesting. Resorting to an ample gamut of qualitative and quantitative techniques, WP6 intends to achieve the following objectives:
  • Set-up a framework to characterize the economics of trackside energy harvesting systems.
  • Analyse in realistic railway scenarios the economic feasibility of implementing trackside energy harvesting systems.

WP11 - Smart Wayside Object Controller. Demonstrators TRL 4

The goal is to take the activities started in X2Rail-1 WP7 project a stage further by developing demonstrators with TRL 4 to best support the concepts formulated during X2R-1.
Task 11.1 – Technical Coordination and System Integration (Leader: TD)
The leader will prepare reports, annual plans and call needs for the S2R IP2 coordinator and S2R JU and will attend IP2 SC meetings. Attendance to other Shift2Rail committees and dissemination events are expected too. The WP leader will also ensure technical coordination with other TDs in that IP or in others when relevant based on the dependency between TDs. And also, it is important to supervise the schedule of the demonstrations, in order to ensure the correct development and finalization of the demonstrators and manage the risks and mitigation actions. Overall project coordination will be supported by the task leaders.   
Task 11.2 – Definition of demonstrator specifications and test strategy (Leader: INDRA Participants: CAFS, SMO, BTSE, STS, AZD, TRV, TD, DB, RAILENIUM, MERMEC)
The objectives of that task are:
1. Definition of the specifications of System Requirements and System Architecture that will be covered in the demonstrators.
2. Definition of tests strategy and common principles to analyse test results to be applied for the demonstrators.
Task 11.3 – Development and Verification of selected demonstrators (Leader: SMO, Participants: CAFS, SMO, BTSE, STS, INDRA, AZD, TD, RAILENIUM)
The objectives of this task are to develop the laboratory functional models or prototypes following the specifications of System Requirements and System Architecture, to define and apply the tests to be done and to provide the laboratory test report:
1. Development of the prototypes following the specifications
2. Verification of the prototypes will take into account the environment for testing to reach a TRL 4.
As result of these tasks, every partner will provide the individual work with:
-    The description of the demonstrator
-    The results of the verification tests of the demonstrator
In this task the integration of the description and test results of the demonstrators generated as results of Sub-tasks 11.3.1 to 11.3.8 is completed.
Sub-task 11.3.1 – Development and Verification of WiLPOC (Wireless Low Power Object Controller) demonstrator (Partner: CAFS)
The development and verification of CAFS demonstrator will be performed in this sub-task.
The definition of the demonstrator is:
An autonomous object controller prototype to interface with ERTMS balises, signals and track circuits on areas far from stations. The object controller will be focused on Maintenance and Data Logging to allow a high availability of the system minimizing the onsite maintenance task. The object controller will also take into account minimizing the power consumption to allow a remote autonomous operation.. The autonomous power subsystem will be 100% renewable-based (solar+storage) and will be remotely monitorized to ensure its proper operation. The prototype will use secured IP based communications.
Sub-task 11.3.2 – Development and Verification of Track vacancy detection SWOC demonstrator (Partner: SMO)
The development and verification of SMO demonstrator will be performed in this sub-task.
The definition of the demonstrator is:
An object controller prototype, enabling track element management focused on Track Vacancy Detection (axle counters) with optional signal management and with safe and secured communication over wireless networks.
Specifically addressing:
-    The issues of scalability of the object controller networks
-    Communication between object controller and other systems using wireless technology
-    Reduction of power consumption and integration with a locally produced energy system.
Sub-task 11.3.3 – Development and Verification of Cable less Railway Embankment demonstrator (Partner: BTSE, TRV)
The development and verification of BTSE demonstrator will be performed in this sub-task.
The definition of the demonstrator is:
A basic meeting station consisting of two point-machines, an adjacent level crossing and necessary supporting field elements for train detection.
The prototype will contain features for easy installation, energy conservation, and predictive maintenance and for exchange of information with external systems.
Applicable standards and specifications from TD2.1 and TD 2.11 are planned to be integrated.
Based on the prototype, a model for the life cycle costs will be developed.
Sub-task 11.3.4 – Development and Verification of MuNeSS (Multiple Networks Scalable SWOC) demonstrator (Partner: STS)
The development and verification of STS demonstrator will be performed in this sub-task.
The definition of the demonstrator is:
A prototype of wayside object controller that will be able to communicate using the available heterogeneous wireless public networks (e.g. 2G/3G/4G, satellite, ..), instead of dedicated ones, in order to obtain target performances and to guarantee continuous connectivity, which will allow to improve service quality, offering advanced remote diagnostic and maintenance features of the smart object controller and controlled wayside object(s) with no impact on safe communications. SWOC demonstrator will be scalable and decentralized to permit minimization of required cabling.
Sub-task 11.3.5 – Development and Verification of SWOC network for managing WOs demonstrator (Partner: INDRA)
The development and verification of INDRA demonstrator will be performed in this task.
The definition of the demonstrator is:
Design and develop a SWOC for connecting a single-track element and the development of a Wireless Sensor Network for creating a network mesh (access nodes, transport nodes and gateways nodes). The integration of both developments will allow managing a single-track element from an IXL via wireless, through a closed network mesh that will facilitate the safe and secure communication as well as transparent routing for the IXL to the object to be controlled.
Sub-task 11.3.6 – Development and Verification of a LX Smart wayside objects demonstrator (Partner: AZD)
The development and verification of AZD demonstrator will be performed in this sub- task.
The definition of the demonstrator is:
The demonstrator will comprise a simple SWOC connected via radio connection to the IXL or, alternatively, to the level crossing (LX) controller. This SWOC will be able to control wayside objects commonly used at an LX – axle counter, gate signal, warning light, light signal or barrier drive. One or two wayside object types will be part of the demonstrator. It will be connected by a wireless link to the master IXL or LX controller and to a diagnostic and maintenance system. The power is provided either locally by an energy harvesting system or remotely over a cable.
Sub-task 11.3.7 – Development and Verification of WADILP (Wireless, Advanced Diagnosis, Intelligence distribution and Low Power consumption) SWOC for points machines demonstrator (Partner: TD)
The development and verification of TD demonstrator will be performed in this sub-task.
The definition of the demonstrator is:
A high efficient controlling of point machines as prototype with:
-    wireless communication for control entity connection
-    advanced diagnostic features of the smart object controller and the point machine;
-    specifically addressing the issue of optimized distribution of intelligence;
-    very low power consumption of the smart object controller (and requirements on the point machine) supplemented by autonomous power supply and storage
Sub-task 11.3.8 – Development and Verification of NEWNECTAR (New gEneration of adaptable Wireless sensor NEtwork for way side objeCTs in rAilway enviRonments) demonstrator (Partner: RAILENIUM)
The development and verification of RAILENIUM demonstrator will be performed in this sub-task.
The definition of the demonstrator is:
Development of a new generation of low-power and resource-constrained wireless sensor networks (WSN) for adaptive data collection and forwarding for railway environment. RAILENIUM will develop software define approaches. RAILENIUM will address the challenges both at physical layer and at higher layer. At Physical layer,  RAILENIUM will consider reconfigurability capabilities based on cognitive radio features such as spectrum detection and adaptable radio access technologies taking into account low energy consumption with algorithms implemented in Software Defined Radio (SDR) devices. The question of  antenna integration and solutions for energy harvesting will be also considered as well as radio propagation aspects for deployments. At higher level, RAILENIUM will consider Software Defined Networks (SDN) and Network Functions Visualization (NFV) techniques to demonstrate reconfigurability and adaptability when needed for example in case of flooding or other dangerous event in some part of the network.
Task 11.4 –Analysis and Evaluation of the demonstrators (Leader: SMO, Participants: CAFS, BTSE, STS, INDRA, AZD, TD, TRV, DB, RAILENIUM, MERMEC)
The analysis and evaluation of the demonstrator at TRL 4 phase will be used:
-    As an input for WP12 demonstrators
-    For updating of deliverables of X2Rail-1 project, if needed
-    As preliminary conclusions
This WP will provide when needed the required expertise to support WP2 in the execution of its task 2.4.

WP12 - Smart Wayside Object Controller. Demonstrators TRL 6

The goal is to take the technical demonstrators developed in WP11 a stage further in order to reach TRL 6.
Task 12.1 – Technical Coordination and System Integration (Leader: TD)
The leader will prepare reports, annual plans and call needs for the S2R IP2 coordinator and S2R JU and will attend IP2 SC meetings. Attendance to other Shift2Rail committees and dissemination events are expected too. The WP leader will also ensure technical coordination with other TDs in that IP or in others when relevant based on the dependency between TDs. And also, it is important to supervise the schedule of the prototypes, in order to ensure the correct development and finalization of the demonstrators and manage the risks and mitigation actions. Overall project coordination supported by the task leaders.   
Task 12.2 – Implementation and Validation of selected demonstrators (Leader: BTSE, Participants: CAFS, SMO, STS, INDRA, AZD, TD, RAILENIUM)
The objective of this task is the implementation, installation and validation of the prototypes in a representative environment.
Validation will be executed according to test and validation plans.
After implementation and installation of each demonstrator the expected results for each demonstration prototype will be:
-    First stage, the adaptation of validation plans and test description, including environment selection
-    Second stage, the preparation and the test execution.
At the end of this task it will be reached, in correspondence with the achievement of the following results:
-    Prototypes validation tests executed in operationally representative environment (simulation or field tests site) to reach a TRL 6.
-    Validation Test results
In this task the integration of the description and test results of the demonstrators generated as results of Sub-tasks 12.2.1 to 12.2.8 is completed.
Sub-task 12.2.1 – Implementation and Validation of WiLPOC (Wireless Low Power Object Controller) demonstrator (Partner: CAFS)
The implementation and validation of CAFS demonstrator will be performed in this sub-task.
The definition of the demonstrator is already included in Sub-Task 11.3.1.
Sub-task 12.2.2 – Implementation and Validation of Track vacancy detection SWOC demonstrator (Partner: SMO)
The implementation and validation of SMO demonstrator will be performed in this sub-task.
The definition of the demonstrator is already included in Sub-Task 11.3.2.
Sub-task 12.2.3 – Implementation and Validation of Cable less Railway Embankment demonstrator (Partner: BTSE, TRV)
The implementation and validation of BTSE demonstrator will be performed in this sub-task.
The definition of the demonstrator is already included in Sub-Task 11.3.3.
Sub-task 12.2.4 – Implementation and Validation of MuNeSS (Multiple Networks Scalable SWOC) demonstrator (Partner: STS)
The implementation and validation of STS demonstrator will be performed in this sub-task.
The definition of the demonstrator is already included in Sub-Task 11.3.4.
Sub-task 12.2.5 – Implementation and Validation of SWOC network for managing WOs demonstrator (Partner: INDRA)
The implementation and validation of INDRA demonstrator will be performed in this sub-task.
The definition of the demonstrator is already included in Sub-Task 11.3.5.
Sub-task 12.2.6 – Implementation and Validation of a LX Smart wayside objects demonstrator (Partner: AZD)
The implementation and validation of AZD demonstrator will be performed in this sub-task.
The definition of the demonstrator is already included in Sub-Task 11.3.6.
Sub-task 12.2.7 – Implementation and Validation of WADILP (Wireless, Advanced Diagnosis, Intelligence distribution and Low Power consumption) SWOC for points machines demonstrator (Partner: TD)
The implementation and validation of TD demonstrator will be performed in this sub-task.
The definition of the demonstrator is already included in Sub-Task 11.3.7.
Sub-task 12.2.8 – Implementation and Validation of NEWNECTAR (New gEneration of adaptable Wireless sensor NEtwork for way side objeCTs in rAilway enviRonments) demonstrator (Partner: RAILENIUM)
The implementation and validation of RAILENIUM demonstrator will be performed in this sub-task. The solutions designed and developed will be implemented. A demonstration in the field will be developed.  RAILENIUM will consider the possibility to implement in the Sense-City equipex in which flooding could be reproduced.
The definition of the demonstrator is already included in Sub-Task 11.3.8.
Task 12.3 – Analysis and Conclusion of demonstrators (Leader: BTSE, Participants: CAFS, SMO, STS, INDRA, AZD, TD, TRV, DB, RAILENIUM, MERMEC)
The analysis and evaluation of the demonstrator at TRL 6 phase will serve as an input for possible improvements on prototypes, specifications review and conclusions.
This WP will provide when needed the required expertise to support WP2 in the execution of its task 2.4.

TD 2.11 - Cyber Security

Cyber Security (TD 2.11) aims to achieve the optimal level of protection against any significant threat to the signalling and telecom systems in the most economical way (e.g. protection from cyber attacks and advanced persistent threats coming from outside).

Implementation within IP2 projects


WP08 - Cyber Security

The objectives of this work package are:
  • The definition of a cyber-security system, which consists in the specification of standardised interfaces, monitoring functions, protocol stacks and architectures for secure networks based, among other, on a security assessment of existing railway solutions and of railway networks. Efficiency and robustness of the standardised solution has to be demonstrated through a technical demonstrator. Security assessment, identification of the threat detection, prevention and response processes will be completed.
  • The definition of a security-by-design standard applicable to railways which consists in specifying protection profiles and cyber security standards applicable to railway application and in demonstrating their applicability in a technical demonstrator. The definition of protection profiles and the identification of the cyber-secure development process will be completed.

WP1 - PROJECT MANAGEMENT

Project management - It will carry out the necessary management activities aiming at an adequate coordination of the overall project work plan. This WP includes the Project management concerned with the administrative coordination of the work including costs, timing and completeness of the deliverables.

WP2 - OPERATIONAL CONTEXT AND SCENARIOS

Operational context and scenarios - It will provide a comprehensive analysis of the existing rail system and future requirements from a customer point of view who is asking for a door to door safe and secure transport. This work package will first identify the most critical components of the rail system and their interactions with the other transport modes. Then the existing means of protection will be described. Finally an operational transport scenario involving different types of environment will be proposed for further security assessment in WP3.

WP3 - SECURITY ASSESSMENT

Security assessment - This WP will define the security assessment methodology and will perform a risk assessment for specific railway services, safety and passenger-centric, in order to detect the most critical security zones, as well as the communication (also known as conduits) between them. The specific objectives of WP3 include:
  • Analysis and selection of the most suitable security assessment methodology for this kind of railway services.
  • Definition of the security zones and identification of vulnerabilities for the use cases proposed in WP2.
  • A risk analysis of the use cases covering the initial scenario and the final enhanced one with the improvements provided by other WPs in order to increase the security.

WP4 - THREAT ANALYSIS, ATTACK DETECTION AND EARLY WARNING

Threat analysis, attack detection and early warning - It will deliver a taxonomy of threats targeting rail management and control systems; provide threat classification, description and analysis. In a second step, a set of innovative techniques to detect attacks targeting rail management systems will be assessed, taking into account the potential combination of cyber and physical threats. Last but not least, a number of innovations supporting early warning, context-enriched alerting and collaborative incident management will be proposed.

WP5 - MITIGATION AND COUNTERMEASURES SPECIFICATION

Mitigation and countermeasures specification - It will provide the specifications for countermeasures, identify the different mitigation strategies and resilience mechanisms that allow the operation to continue with guaranteed quality levels, without having impact on operational safety. The mitigation strategies are aimed at proactively inhibiting attacks on the system by employing systematic protection techniques in advance. The countermeasures react to anomalies detected with respect to the normal operation of the system and proactively counteract identified attacks. The resilience mechanisms ensure the safe operation in the presence of attacks.

WP6 - PROTECTION PROFILES

Protection profiles - It will integrate the essential concepts considered in WPs 4 and 5 into profiles which capture the scenario and security requirements of WPs 2 and 3, respectively. The Protection Profiles Specification shall include: Security by Design; Specification of Protection profiles; Selection of Standard Framework; and Evaluation Assurance Level.

WP7 - DISSEMINATION AND OUTREACH

Dissemination and outreach - It aims to communicate and disseminate the result toward the public transport operators, manufacturers of public transport systems, security providers, scientific community and public bodies.

WP08 - Cybersecurity -1

The main objectives of this work package are:
  • To finalise the guidelines for “railway cybersecurity system” and “security-by-design”.
  • To apply the final release of the guidelines to signalling generic railway architecture.
  • To apply the railway cybersecurity system for risk assessment to other technical demonstrators of Shift2Rail, to railway future and resilient architecture; and to legacy system. Derive from these risk assessments a proposal for the component protection profiles.
  • To perform a detailed specification of the demonstrator

WP09 - Cybersecurity -2

This work package will focus on the implementation of a holistic cybersecurity verification approach by covering the following topics:

  • Verification along product and system security life-cycle (IEC 62443-2-1, 2-4, 4-1)
  • Verification along the supply-chain, across multiple security stakeholders (IEC 62443-2-x, 4-1)
  • Demonstrator 1: Verification of vertical security patch management process (IEC 62443-2-3)
  • Demonstrator 2: Verification of cybersecurity components for adaptable communications.
  • Challenges and recommendations for a holistic, multi stakeholder-based security verification approach

WP3 - Support to implementation of CSIRT to the railway sector

The main aim of WP3 is to deliver a pilot CSIRT model for Railway co-designed and owned by those stakeholders, along with a working pilot platform (Collaborative Environment) also co-designed with those stakeholders to ensure ownership and future uptake.