FFFIS for the critical interfaces in the distributed lab ...

Project funded by the S2R JU

S2R-OC-IP2-02-2015 – IT virtualisation of testing environment

Grant Agreement: 730815 - VITE

VITE: Virtualisation of the Test Environment

FFFIS for the critical interfaces in the distributed lab architecture for remote

testing

Issue 1.0 Date 29/12/2017

Number of pages 33 Classification PU

Document Reference

Project Work package Partner Nature Number

VITE WP3 CEDEX Deliverable 3.4

Partner reference (optional)

Responsible Name/Company Signature Date

Author CEDEX / MULTITEL / RFI / RINA 27/12/2017

WP Leader D Molina / CEDEX 29/12/2017

Project coordinator B Sierra / INECO 29/12/2017

S2RJU Project Officer Lea PATIES

Ref. Ares(2019)1048364 - 20/02/2019

FFFIS for the critical interfaces in the distributed lab

architecture for remote testing

Ref: VITE-WP3-CED-DEL-3.4-v0.2

Issue: 1.0 Date:

29/12/2017

Class: PU / 33

VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815

DOCUMENT CHANGE LOG

Issue Date Affected Sections Comments

0.1 16/12/2016 All Schematic draft to start working in the different sections

0.2 29/12/2017 All First draft including contributions from every partner.

1.0 29/12/2017 All Quality review for delivery




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


TABLE OF CONTENTS

1 INTRODUCTION ....................................................................................................... 5

1.1 Purpose ...................................................................................................................... 5

1.2 Intended audience / Classification ............................................................................... 5

1.3 Associated documentation .......................................................................................... 5

1.4 Abbreviations and Acronyms ...................................................................................... 6

2 CURRENT EXPERIENCES FOR REMOTE TESTING .............................................. 8

2.1 Introduction ................................................................................................................. 8

2.2 Background ................................................................................................................. 8

2.2.1 CEDEX ................................................................................................................ 8

2.2.2 RFI and MULTITEL ............................................................................................ 11

2.3 Summary .................................................................................................................. 15

2.3.1 Strong points...................................................................................................... 15

2.3.2 Weak points. ...................................................................................................... 15

2.3.3 Conclusions. ...................................................................................................... 16

3 DETAILED ANALYSIS OF SUBSET-111-2 ............................................................. 17

3.1 Introduction ............................................................................................................... 17

3.1.1 TEST CONTROL ............................................................................................... 17

3.1.2 LOGGING .......................................................................................................... 17

3.1.3 STIMULUS ........................................................................................................ 17

3.2 Background ............................................................................................................... 18

3.2.1 TEST CONTROL ............................................................................................... 18

3.2.2 LOGGING .......................................................................................................... 19

3.2.3 STIMULUS ........................................................................................................ 19

3.3 Summary .................................................................................................................. 24

4 DETAILED ANALYSIS OF SUBSET-111-3 ............................................................. 25

4.1 Introduction ............................................................................................................... 25

4.2 Background ............................................................................................................... 25

4.3 Summary .................................................................................................................. 25

5 ANALYSIS OF THE RBS IMPLEMENTATION BASED ON THE EXPERIENCE ..... 26

5.1 Introduction ............................................................................................................... 26

5.2 Background ............................................................................................................... 27

5.3 Summary .................................................................................................................. 27




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


6 ANALYSIS OF THE TRANSFER PROTOCOL STACK (XML-RPC) BASED ON THE EXPERIENCE ........................................................................................................................... 28

6.1 Introduction ............................................................................................................... 28

6.2 Summary .................................................................................................................. 28

6.2.1 Strong points...................................................................................................... 28

6.2.2 Weak points: ...................................................................................................... 28

7 STAGE 2 TEST ARCHITECTURE: ADAPTED IMPLEMENTATION OF SUBSET-111-2 FOR REMOTE TESTING .......................................................................................................... 29

7.1 Introduction ............................................................................................................... 29

7.2 List of messages ....................................................................................................... 29

7.3 Summary .................................................................................................................. 31

8 STAGE 3 TEST ARCHITECTURE: VITE PROPOSAL FOR SUBSET-111-2 AND SUBSET-111-3 ......................................................................................................................... 32

9 CONCLUSIONS ...................................................................................................... 33

LIST OF TABLES

Table 1 CEDEX Test Architecture Links description. ...................................................................... 9

Table 2. Stage 2 selected messages. ........................................................................................... 31

Table 3 Stage 2 undefined messages. ......................................................................................... 31

LIST OF FIGURES

Figure 1. CEDEX Test architecture

Figure 2 Flow diagram for test action: Set/revoke route

Figure 3 Flow diagram for test action: train moves

Figure 2. CEDEX Test architecture for remote testing

Figure 3. RFI logic structure of the test environment

Figure 4 . RFI Remote/Distributed Laboratory architecture

Figure 5. RBS Unit Overview




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


1 INTRODUCTION

1.1 Purpose

The purpose of this deliverable is to describe in detail the critical interfaces to enable remote testing in distributed architectures. The document dedicates most of the content to the analysis of the IOP specification. This analysis is performed considering the previous experiences of test laboratories. The main shortcomings are identified and solutions are proposed to solve them.

Due to the VITE project constraints, and following the strategy described in Deliverable 3.2 Test Architecture, this document will also present two solutions. The first, and more conservative one, is intended to be used in the VITE Test Campaign. This is the so-called Stage 2 solution. The second one, more ambitious and complete, is called Stage 3 Test Architecture. This last definition will only be presented at theoretical level. Its verification is out of the scope of the present project.

1.2 Intended audience / Classification

This document is public.

1.3 Associated documentation

1. Railway line capacity consumption of different railway signalling systems under scheduled and disturbed conditions. Goverde R.M.P., Francesco Corman F., D'Ariano A. 3, August de 2013, Journal of Rail Transport Planning & Management, Vol. 3, págs. 78-94. ISSN 2210-9076, http://dx.doi.org/10.1016/j.jrtpm.2013.12.001.

2. COMMISSION REGULATION (EU) 2016/919 of 27 May 2016 on the technical specification for interoperability relating to the ‘control-command and signalling’ subsystems of the rail system in the European Union.

3. Formalizing a subset of ERTMS/ETCS specifications for verification purposes. M., Ghazel. 42, s.l. : Elsevier, 2014, Transportation Research Part C: emerging technologies, págs. 60-75.

4. Datenmodellanalyse zum Austausch von Projektierungsdaten für Stellwerkssysteme in INESS (Analysis of data models for the exchange of project data for interlocking systems in INESS). Linder C., Grimm M. 104, 2012, Signal und Draht, págs. 9-16.

5. Efficient formalization of railway interlocking data in RailML. Bosschaart M., Quaglietta E., Janssen B., Goverde R.M.P. 49, s.l. : Elsevier, 2015, Information Systems, págs. 126-141.

6. Towards a Universal Topology Model for Railways and Data Exchange Format for Infrastructure. Paris : s.n., 2015. 4th UIC RailTopoModel and railML Conference.

7. www.railml.org. [En línea]

8. UIC. RailTopoModel - Railway infrastructure topological model. 18/04/2016. UIC International Railway Standard. IRS 30100.

9. Capacity for Rail. Data Notation and Modelling. 10/03/2016. Collaborative project SCP3-GA-2013-60560 Increased Capacity 4 Rail networks through enhanced infrastructure and optimised operations FP7-SST-2013-RTD-1.

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

11. http://www.sefev.eu/SEFEV_files/SEFEV_Leaflet.pdf. [En línea]

12. ECC Report 96 - Compatibility between UMTS 900/1800 and systems operating in adjacent bands. March 2007.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


13. ECC Report 146 - Compatibility between gsm mcbts and other services (trr, rsbn/prmg, hc-sdma, gsm-r, dme, mids, dect) operating in the 900 and 1800 mhz frequency bands. June 2010.

14. Compatibility between LTE and WiMAX operating within the bands 880/915 MHz / 925-960 MHz and 1710-1785 MHz / 1805-1880 MHz (900/1800 MHz bands) and systems operating in adjacent bands. 12 November 2010. CEPT Report 41 - Report from CEPT to the European Commission in response to Task 2 of the Mandate to CEPT on the 900/1800 MHz bands.

15. ECC Report 162 - Practical mechanism to improve the compatibility between gsm-r and public mobile networks and guidance on practical coordination. May 2011.

16. ECC Report 229 - Guidance for improving coexistance between GSM-R and MFCN in the 900 MHz band. May 2015.

17. UIC O-8736 rev. 2.0 - Assesment report on GSM-R current and future radio environment. July 2014.

18. QoS on GSM-R networks for ETCS Level 2 operation. Markus Myslivec, Christian Sagmeister. 9, 2013, Signal und Draht.

19. VITE Consortium. VITE-WP3-CED-DEL-3.1-v1.0-Lab architecture State of the art analysis. 2017.

20. UNISIG. Interoperability Test Environment Definition (FFFIS for TCL-OBU Adaptor). 2016. UNISIG Subset-111-2 version 3.6.0.

21. —. Interoperability Test Environment Definition (FFFIS for TCL-RBC Adaptor). 2016. UNISIG-SUBSET-111-3 Version 3.6.0.

22. —. Interoperability Test Environment Definition (General). 2016. UNISIG SUBSET-111-1 versión 3.6.0.

23. —. UNISIG Basics for Interoperability Test Scenario Specifications. 2016. UNISIG Subset-112 version 3.6.0.

24. —. UNISIG Interoperability Test - Guidelines. 2016. UNISIG Subset-110 version 3.6.0.

1.4 Abbreviations and Acronyms

CA Consortium Agreement

CORBA Common Object Request Broker Architecture

DLR Deutsches Zentrum für Luft- und Raumfahrt

EC European Commission

ERTMS European Rail Traffic Management System

ETCS European Train Control System

GA Grant Agreement

GUI Graphical User Interface

HTTP HyperText Transfer Protocol

IOP InterOPerability subsets

IXL Electronic InterlLocking

OBU On Board Unit




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


PC Project Coordinator

RBC Radio Block Centre

RPC Remote procedure call

S2RJU Shift2Rail Joint Undertaking

SS SubSet

TCL Test Control and Logging

TCP/IP Transfer Control Protocol/Internet Protocol

VITE Virtualisation of the Test Environment

VPN Virtual private Network

WP Work Package

WPL Work Package Leader

XML eXtensible Markup Language

XML-RPC Remote procedure call based on XML format




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


2 CURRENT EXPERIENCES FOR REMOTE TESTING

2.1 Introduction

In this section, the VITE partners with ETCS laboratories shall describe their experience with remote tests. This description shall include the test architecture employed for remote testing, the nature of the tests undergone and some conclusions.

2.2 Background

2.2.1 CEDEX

2.2.1.1 Test Campaign Description

In 2014-2015, the CEDEX laboratory in Madrid performed a test campaign with the RailSite laboratory of DLR, in Braunschweig. The trackside equipment was placed at CEDEX and the ETCS on-board unit at DLR.

The trackside equipment was supplied by Invensys and was configured with the data from one section of the Spanish High-Speed Line Madrid-Albacete-Valencia. The ETCS on-board equipment was supplied by Siemens. Both systems were ERTMS Baseline 2 products.

The Test Campaign consisted on several operational scenarios from the Spanish Integration Test Protocol. The test execution was completely driven from CEDEX side with some support from DLR to prepare their test environment and solve the unexpected incidences.

This Test Campaign was done in the frame of project TEN-T 2011-EU-60013-S Facilitating and speeding up ERTMS deployment.

Figure 6. CEDEX Test architecture




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


2.2.1.2 Basic test architecture

The test campaign was possible since, at that time, CEDEX and DLR shared the same core of software for the simulators composing the test architecture.

In Figure 1. CEDEX Test architecture , the CEDEX test architecture is displayed. As can be easily observed, this test architecture resembles the IOP architecture (1) and, therefore, the VITE architecture. The structure in three main blocks is preserved. The trackside part is coloured in red. The onboard part is coloured in light blue. In the middle of the diagram, in colour dark blue, two simulators are placed. These modules, acting as coordinators between the trackside and the onboard part, are the Track Simulation tool and the GSM-R Network Simulation tool.

In this test architecture, the test driving actions are decentralized, so the train driver actions must be done directly on the ETCS DMI or through a robot controlled by the DriverSim GUI. The driver actions on the train must be done directly on the TrainSim GUI. By the other side, the train dispatcher functions are managed directly on the IXL GUI and the RBC GUI. These actions are performed manually in test execution time. The automatic actions are related to the coordination of both test benches (trackside and onboard) and are numbered in Figure 1. CEDEX Test architecture . The description of such a links is included in Table 1

The basic behaviour of this test architecture is described in the flow diagrams shown in Figure 2 and Figure 3. In these diagrams, the two basic actions for driving a test are explained:

Trackside main action: Set/revoke a route

Train main action: moving through the track.

Link

ID From To Comment Delivery

1

Track

Simulation

Trackside

Simulation

List of ETCS telegrams with relative distance

from the test start location. These telegrams

are selected according to the signalling state

and the path fixed for the train movement.

Cyclically

Track

Simulation

Train

Simulation

Track description affecting the simulation of

the train movement (gradients, powerless

section, etc) with relative distance from the

test start location. The track description only

includes information relative to the specific

path fixed for the train movement.

Cyclically

Train

Simulation

Track

Simulation

Relative position of the train from the test start

location. Cyclically

2

Track

Simulation

IXL

Simulation

Signal, switches and track occupation devices

status.

At start up and upon

change.

IXL

Simulation

Track

Simulation Signal and switches commands. Upon change.

3 RBC OBU Euroradio exchange (including euroradio

protocols plus ETCS radio messages) Upon change

Table 1 CEDEX Test Architecture Links description.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


Figure 3 Flow diagram for test action: train moves

Figure 2 Flow diagram for test action: Set/revoke route




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


After these explanations, it is clear the key coordination role performed by the Track Simulation Tool to synchronize the Trackside and the Onboard parts and translate automatically the train movement over a network to one dimensional information and vice versa.

2.2.1.3 Remote test architecture

Once the basic test architecture of Figure 1. CEDEX Test architecture is understood, in this section it will be explained how the remote tests can be done. In the first term, it is important to emphasize that every data exchange within the links described in Table 1, are done over network connections (more specifically, CORBA messages over TCP-IP). By the other side, as the automation level is reduced, most of the control actions driving the test must be done manually in the different GUI’s of the modules in the test architecture.

The network connection between Madrid and Braunschweig was done through a VPN. The GUIs exportation to Madrid were performed using standard methods of Linux-like systems. Although, as already mentioned before, the test automation level was reduced, the use of such a configuration allowed to control completely the test execution from Madrid.

2.2.2 RFI and MULTITEL

2.2.2.1 Test Campaign Description

Remote testing for ERTMS/ETCS system was arranged by RFI, locating and connecting two different test laboratories in two different geographical areas.

One lab was located in Rome (Italy), hosting wayside systems; the other was located in Mons (Belgium), hosting train system.

The framework used to interface the systems under test was the IOP, as defined in the subset 110, 111 and 112.

Figure 7. CEDEX Test architecture for remote testing




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


RFI defined a set of activities in order to verify the usability of the IOP; it was used version 1.0.0 of the specifications. This means that required functionalities were a subset of those reported by the last version (3.6.0).

An IOP test environment was set up in Portonaccio laboratories (Rome, Italy) where functional tests involving RBC (track side ERTMS system) and Train On Board SubSystem (On board ERTMS system) were performed. The primary objective was to verify if the IOP specification suited the needs to perform functional system tests, and if the IOP proposed architecture suited the yet present proprietary test and simulation environments. In particular, the activities tended to demonstrate that ERTMS systems still worked properly under IOP control. Both systems were ERTMS Baseline 2 products.

RBC and related adaptor were provided by Ansaldo STS

Simulation environment and TCL were provided by Ansaldo STS.

On Board system was provided by Mermec.

OBU adaptor and VPN was provided by Multitel.

In this environment the OBU adaptor was physically placed in a remote lab in Mons (Belgium) and connected to the lab in Rome through the Internet using a VPN.

The OBU adaptor was also connected to the RBC adaptor using a RBS connection, bypassing the ERTMS communication layer on GSM-R.

Tests were lead from the TCL in Portonaccio Lab. Actions on the On Board system were performed by personnel located in Mons laboratory.

2.2.2.2 Test Architecture Description

The testing laboratory is intended to perform functional tests to verify the interoperability of ERTMS systems developed by different providers.

RFI developed such kind of laboratory for this purpose: testing the integration of the ERTMS wayside system provided by ASTS (RBC) and the ERTMS on-board system provided by Mermec (OBU).

RFI also used that experience to identify the following general requirements:

Each ERTMS system must be interfaced with a specific and proprietary simulation environment that must simulate and provide all required inputs to the system, for both hardware and software interfaces.

The ERTMS system under test must be the real system to install on the field. Other system not under test can be real or simulated

ERTMS systems must interface according to the European standard described in the subsets SS110, SS111 and SS112 (IOP, which defines a standard mechanism, a protocol and functionalities to support for integration test execution).

The test environment must be not intrusive respect the test execution. This means that the test environment shall not alter the behaviour and the result of the system under test.

Tests shall be executed both manually and automatically, using scripts in a centralized test orchestrator / manager.

The laboratory architecture has the main objective to be not intrusive, according to the requirements above, and allow the verification and validation of the ERTMS system interaction, in order to ensure their capability to work together well. For this reason, the set of tests to perform must be the most complete set of functional tests required and provided for the certification process of the ERTMS system.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


This means that the set of test shall cover all functionalities of the ERTMS systems under tests, foreseen for the specific railways line in which the test session is performed.

Communication between the adaptors and the Test Orchestrator/Manager shall be the network, and communication shall be performed using a standard protocol as defined by SS111.

Interfacing between an adaptor and its related system shall be proprietary, as it strictly depends on the capability of the system under test to accept inputs and provide outputs.

The particular implementation of the logic structure shown in Figure 5. RFI logic structure of the test environment is displayed in Figure 6 . RFI Remote/Distributed Laboratory architectur. It can be described as follows:

A TCL workstation: to manage and execute tests.

-A real OBU o interfaced to the simulation environment through an Adaptor (OBU Adaptor) o connected to a dedicated simulator in order to acquire physical input signals

A real RBC o interfaced to the simulation environment through dedicated simulation modules

(RBC Adaptor)

A real IXL connected to the simulation environment via network

An RBS module to simulate the GSM-R connection between the on-board system and the RBC via network

A simulation environment to reproduce train movement on the line

All resources were connected to the network in order to allow data exchange and to be interfaced with the simulation environment.

In order to have a distributed test environment (and lab) the various elements were located in different geographical areas, Rome and Mons, connected via Internet.

Figure 8. RFI logic structure of the test environment




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


Resources in Rome:

VPN Managers: Dedicated hardware and software modules, capable to connect the machines of different local networks, by creating a VPN through an Internet connection. Each network uses a VPN adaptor (as gateway/router), which establishes a connection to other(s) VPN adaptor(s) through Internet. In the used configuration one adaptor was located in Rome (Italy) and another in Mons (Belgium)

TCL: Central workstation to orchestrate and record the test execution. It provided the interface to control the OBU from remote.

Line Simulator: set of processes realizing the simulation environment. It replicates the train movement on the line and generates all required information to inform the wayside systems (RBC and IXL) about the current line status (e.g. track circuit occupation, switch orientation, etc…) and send to the train all information from the track (e.g. balises).

RBC Adaptor: A set of software modules used to interface the wayside systems (RBC and IXL) to the simulation environment. It realized the data exchange between the RBC and the other systems.

RBC system: The real ERTMS/ETCS wayside equipment to be tested.

IXL system: The real Signalling wayside system required by RBC to acquire information about the status of the line.

Control Workstation (TCL)

VPN Manager

INTERNET

RBC IXL

Line simulator

OBU Adaptor

OBU System

VPN Manager

Scheme of Distributed Laboratory for ERTMS/ETCS Systems Tests

Physical itnerfaces

RBC Adaptor

RBSmodule

Figure 9 . RFI Remote/Distributed Laboratory architecture




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


Resources in Mons:

VPN Managers: Corresponding module of the one located in Rome, used to realize the VPN, connecting the two different local networks.

RBS module: Can be considered part of the RBC Adaptor. It allowed to simulate the GSM-R channel establishing the connection between the OBU and the RBC via Ethernet.

OBU adaptor: A set of software/hardware modules used to interface the train system to the simulation environment and to generate physical input signal for the OBU in order to simulate train hardware equipment.

OBU system: The real ERTMS/ETCS train equipment to be tested.

Euroradio connection between the On Board system and the RBC was realized via RBS. OBU and RBC adaptors exchanged information via network using a proprietary protocol defined by Ansaldo STS based on TCP/IP. This allowed to bypass the GSM-R connection.

2.3 Summary

Both architectures show that remote testing is possible, although a major effort to automate and become independent from the equipment’s suppliers must be done. In the following sections, the strongest and weakest points from both approaches are summarized.

2.3.1 Strong points.

2.3.1.1 CEDEX

Complete test control from the trackside part, without any support in the on-board side for testing.

Complete independence from the industrial suppliers, by means of local “standard” interfaces.

2.3.1.2 RFI & MULTITEL

The effort for the providers was restricted to the realization of an adaptor or the TCL as a part of their existing test simulation environments.

The system decoupling and the capability to orchestrate the test from a central interface (offered by TCL application) allowed to perform tests between systems located in different geographical areas, without the need of collecting all the ERTMS systems in the same place.

Using a common standard protocol to interface the adaptors with the TCL allows to focus the attention on the functional layer of the development as HTTP and XML

2.3.2 Weak points.

2.3.2.1 CEDEX

Strong dependence from the simulation tools provider.

Proprietary interface for remote testing.

2.3.2.2 RFI & MULTITEL

As the RBS is not standardized by the IOP specification it was required to develop a dedicated and specific communication task to simulate the Euroradio connection. Anyway this protocol is proprietary and cannot be reused by the OBU adaptors providers with other track-side system providers.

As providers do not need to be in the same place, sometimes the distance could introduce some delays in sharing information and finding solution in case of problems or bugs.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


2.3.3 Conclusions.

The current experiences indicate clearly the steps to follow in VITE project:

Improve Subset-111-2 to ease the remote communication between laboratories and TCL.

Improve TCL and Subset-111-3 definition to isolate it from the trackside test environment.

Define interfaces to the industrial equipment in order to become independent from industrial providers.

Improve RBS definition to become independent from industrial providers.

Maintain the current test scope: functional tests to verify the interoperability of ERTMS systems developed by different providers.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


3 DETAILED ANALYSIS OF SUBSET-111-2

3.1 Introduction

The Subset-111-2 corresponds to the OBU Adaptor within the main IOP architecture. Today, laboratories are in condition to achieve FULL tests according to SUBSET-094 and to automate almost all interactions related to the driver, the train simulation, the ETCS unit and its surrounding interfaces.

By experience, it was shown that a series of integration tests were necessary before starting IOP testing. It consisted in the establishment of a VPN network between different sites and in the confirmation of the interface communication protocol as described in the SUBSET-111-2. Some of the messages were not necessarily used during the test phase as the target was to show a proof of concept.

Several actions needed to be performed manually. However, today, it would be possible to automate all interactions as described in the subset and related to the driver interactions.

Subset-111-2 can be divided into three different major categories:

TEST CONTROL

LOGGING

STIMULUS

In the following sections, some additional clarifications are provided.

3.1.1 TEST CONTROL

The test control part corresponds to the preparation of the simulation and the control of the Device Under Test (the DUT) from the adaptor itself. In other words, we can think about firstly start the test, and then to power up the equipment as if a real driver would start his journey. Then this real driver could stop his mission and power off the system.

This category can also be divided in:

CONFIG

INIT

OBU

INFORMATION

3.1.2 LOGGING

The logging part is necessary for the TCL to have information and to analyse the data coming from the TCL OBU adaptor. It consists not only in downloading JRU but also in downloading the ADAPTOR logs for further analysis.


LOGGING

JRU-LOGGING

3.1.3 STIMULUS

Most of the stimulus are covered by the SS094 architecture. An analysis was achieved in order to start a comparison between IOP and SS094. The most critical points were shown in the conclusions of this analysis. We believe that it is important to take this analysis into consideration at this stage of the VITE project.


BALISE




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


EUROLOOP

RADIO

TIU

DMI

MOVEMENT

NTC

TDA

3.2 Background

Most of the messages represented by the IOP v3.6.0 covers all the needed information related to the OBU management. The following list emphasize the critical information that was identified and answer item by item based on experiments and issues encountered so far with IOP testing principles.

3.2.1 TEST CONTROL

3.2.1.1 CONFIG.requestData

This message is not critical. The aim of sending the TCL configuration information is to help OBU Adaptor having more accurate information regarding the simulation. In our experience, the OBU adaptor can evaluate the trackside information in order to anticipate any change of information such as gradients for example. The timestamps are used to ensure that all information exchanged at the level of the OBU adaptor will have enough traceability in order to validate the global scope of the test scenario.

3.2.1.2 CONFIG.data

This message is not critical. Same as CONFIG.RequestData but changing the OBU Adaptor by the TCL.

3.2.1.3 INIT.activate

This interaction is critical. Our experience showed that it is required to have some exchange of time information in order to ensure a correct synchronicity between both sites. At start-up of a test scenario, ones can think that it is necessary to put in place the test and to ensure that the device under test will be powered on whenever necessary. At this stage, whenever there was any delay between one message and the other, the TCL shall always ensure that a "switch off" is sent when the test scenario finishes.

3.2.1.4 INIT.status

This interaction is critical. Same as INIT.activate.

3.2.1.5 OBU.setSystemFailure

Not critical. Not necessary for the VITE Test Campaign. No attribute is included in Table 4.6, although a boolean attribute could be used, as in some other examples within the Subset.

3.2.1.6 OBU.setColdMovement

Not critical. Not necessary for the VITE Test Campaign. In the Attribute Comment, it could be added that zero value means no cold movement at all.

3.2.1.7 OBU.reset

Not Critical. Not necessary for the VITE test Campaign. The reset option looks quite limited since it is not possible to specify proper starting conditions, but the unknown or the previously stored one.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


3.2.1.8 OBU.activate

Critical.

3.2.1.9 OBU.status

Critical.

3.2.1.10 INFORMATION.error

Critical.

3.2.2 LOGGING

3.2.2.1 LOGGING.activate

Not Critical. Logging should be mandatory. The log of the Adaptor were used to clarify what type of information was exchanged during the test.

3.2.2.2 LOGGING.request

Not Critical. Same as LOGGING.activate

3.2.2.3 LOGGING.result

Not Critical. Same as LOGGING.activate

3.2.2.4 JRU-LOGGING.request

Critical.

3.2.2.5 JRU-LOGGING.result

Critical. An attribute describing the version of Subset-027, in case "translation" is false, could be very helpful. During the TCL CONFIG messages, version of different devices are exchanged.

3.2.3 STIMULUS

3.2.3.1 MOVEMENT.setTarget

Critical. See Summary section.

3.2.3.2 MOVEMENT.setAdaptorBehaviour

Critical.

3.2.3.3 MOVEMENT.setGradientProfile

Critical. The two arrays should have the same length: first gradient (g(0)) is valid from 0 m to first entrance point (ep(0)), g(1) from ep(0) to ep(1) which could be a large number to identify infinity.

3.2.3.4 BALISE.insertBalise

Critical. The attribute distanceToEntrancePoint indicates the distance from the scenario start location. Each BALISE.insertBalise message corresponds to one Balise (the attributes are not arrays) so when new Balises enter in the preview window a new message is transmitted by the TCL with the new Balise. The Subset-111-2 gives more details on how the windowing information is used.

3.2.3.5 BALISE.removeBalise

Critical. The behaviour of this message assumes the TCL knows perfectly the position of the train. In case a route is cancelled, all balises already inserted should be removed.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


3.2.3.6 BALISE.activeAntenna

Not Critical. The usage of this information in the TCL is not clear at all. This information can be retrieved by other means out of the testing time.

3.2.3.7 EUROLOOP.insertLoop

Not critical. The problems are exactly the same as the BALISE ones, but due to the almost negligible use of the EUROLOOP, the implementation of this message is not that critical.

3.2.3.8 EUROLOOP.removeLoop

Not critical. The problems are exactly the same as the BALISE ones, but due to the almost negligible use of the EUROLOOP, the implementation of this message is not that critical.

3.2.3.9 NTC.insertTrackData

Not critical. It requires an OBU Test Bench fitted to provide NTC data, what it is not obvious.

3.2.3.10 NTC.removeTrackData

Not critical. It requires an OBU Test Bench fitted to provide NTC data, what it is not obvious.

3.2.3.11 TIU.sleeping

Critical.

3.2.3.12 TIU.passiveShunting

Not critical. BL3 Functionality.

3.2.3.13 TIU.nonLeading

Not critical. BL3 functionality.

3.2.3.14 TIU.isolation

Critical.

3.2.3.15 TIU.setSpeedValue

Not critical. BL3 MR2 functionality.

3.2.3.16 TIU.brakeStatus

Not critical. We understand this message as the way the OBU adaptor can report the OBU actions on the brakes system. This message is therefore intended to inform the TCL about these OBU commands. No action is expected from the TCL.

3.2.3.17 TIU.brakeActivation

We do not understand the aim of this message. The brakes system simulation is done in the OBU Adaptor, as clearly stated in SS-111-1-req.7.9.2.5.1. The brakes system configuration is delivered using the next message and the reaction to OBU commands is fixed in message MOVEMENT.SetAdaptorBehaviour.

3.2.3.18 TIU.brakeConfiguration

Critical. We understand this message as the way to configure the OBU adaptor brake system. We think the Expected behaviour is wrong, since this information is not directly translated to the OBU TIU, but managed internally by the OBU adaptor.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


3.2.3.19 TIU.brakePressure

We do not understand the aim of this message. The brakes system simulation is done in the OBU Adaptor, as clearly stated in SS-111-1-req.7.9.2.5.1. The brake pressure calculation is therefore done in the OBU Adaptor.

3.2.3.20 TIU.trainIntegrity

Not critical. BL3 functionality.

3.2.3.21 TIU.selectCab

Critical

3.2.3.22 TIU.selectDrivingDirection

Critical.

3.2.3.23 TIU.signalStatus

Critical. We understand this message as the way the OBU adaptor can report the OBU actions on the train system. This message is therefore intended to inform the TCL about these OBU commands. No action is expected from the TCL.

3.2.3.24 TIU.coldMovementStatus

Not critical. We do not understand the aim of this message. With message OBU.setColdMovement it is possible to activate this functionality from the TCL and this is far enough.

3.2.3.25 TDA.data

Not critical. Definition from SS-094 could be taken.

3.2.3.26 TIU.getTrainDataEntryType

Not critical.

3.2.3.27 TIU.replyTrainDataEntryType

Not critical.

3.2.3.28 DMI.getSystemVersion

Not Critical. DMI action on the settings Window to check the system version

3.2.3.29 DMI.replySystemVersion

Not Critical. DMI action on the settings Window to check the system version.

3.2.3.30 DMI.getLanguage

Not Critical. DMI action on the settings Window to check the language.

3.2.3.31 DMI.replyLanguage


3.2.3.32 DMI.setLanguage


3.2.3.33 DMI.getLevel

Not Critical. The question is not the current level but the available levels on the ETCS OBU. The information retrieved in this way can be used afterwards in message DMI.LevelRequest. This information is not exclusive from the DMI. There could be another sources.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


3.2.3.34 DMI.replyLevel

Not Critical. The question is not the current level but the available levels on the ETCS OBU. The information retrieved in this way can be used afterwards in message DMI.LevelRequest. This information is not exclusive from the DMI. There could be another sources.

3.2.3.35 DMI.getTrainType

Not Critical. Only to be used when the train data type is fixed. This information is not exclusive from the DMI. There could be another sources.

3.2.3.36 DMI.replyTrainType

Not Critical. Only to be used when the train data type is fixed. This information is not exclusive from the DMI. There could be another sources.

3.2.3.37 DMI.getTrainCategory

Not Critical. Only to be used when the train data type is flexible. This information is not exclusive from the DMI. There could be another sources. This is not the only information to be managed when train data type is flexible.

3.2.3.38 DMI.replyTrainCategory

Not Critical. Only to be used when the train data type is flexible. This information is not exclusive from the DMI. There could be another sources. This is not the only information to be managed when train data type is flexible.

3.2.3.39 DMI.getRadioNetworkId

Not critical. The information retrieved in this way can be used afterwards in message DMI.LevelRequest. This information is not exclusive from the DMI. There could be another sources.

3.2.3.40 DMI.replyRadioNetworkId

Not critical. The information retrieved in this way can be used afterwards in message DMI.LevelRequest. This information is not exclusive from the DMI. There could be another sources.

3.2.3.41 DMI.getVBC

Not critical. Used to manage the Virtual Balise Cover Functionality. However, this information is not available in DMI. The OBU Adaptor must know somehow the list of virtual balise covered stored on-board.

3.2.3.42 DMI.replyVBC

Not critical. Used to manage the Virtual Balise Cover Functionality. However, this information is not available in DMI. The OBU Adaptor must know somehow the list of virtual balise covered stored on-board.

3.2.3.43 DMI.setVBC

Not critical. Used to manage the Virtual Balise Cover Functionality. This action is available in the DMI, in the window "Settings"

3.2.3.44 DMI.removeVBC

Not critical. Used to manage the Virtual Balise Cover Functionality. This action is available in the DMI, in the window "Settings"




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


3.2.3.45 DMI.setPeriodicity

Critical. The message is delivered as explained in Annex B1.2.3 of SS-111-2.

3.2.3.46 DMI.status1

Critical. DMI.Status1 and DMI.Status2 mix information that might be or might be not available in the DMI. For instance, the cab activation and the distancetoEntrancePoint are not displayed at all on the DMI. The permittedSpeed, distanceToTarget, geoPos and tunnelPos are only displayed in certain conditions. The only information that is permanently displayed is the DisplayedSpeed, but only when the cab is active. In SL this is not the case. Besides, we do not understand why the tunnelPos is included and not the other DMI track conditions as neutral areas, special brakes inhibition, etc.

3.2.3.47 DMI.status2

Critical. In this message, the attributes are more related to DMI available information than in the previous case (DMI.status1). However, it should be evaluated if the content is complete or not.

3.2.3.48 DMI.rbcConnectionStatus

Critical. Attributes are clear.

3.2.3.49 DMI.messageIndication

Critical. Attributes are clear.

3.2.3.50 OBU.trackConditionIndication

Critical. This message must be used independently on the information displayed to the driver, since not all the track conditions request an indication to the driver. However, as already indicated in message DMI.status1, the track conditions actually shown on the DMI are not completely reflected in DMI.Messages.

3.2.3.51 DMI.setDriverIdStart

Critical. This message usage is described in 4.3.11.1 and Annex B1.2.4. The messages to retrieve information (Levels, Network IDs, Train Categories, Train Types, NTCs) are supposed to be sent AFTER delivering this message. In my opinion this is not the right sequence. First of all, before starting the Data Entry on the DMI, the needed information is retrieved. Once all the information is available in the TCL, the Start of Mission can be launched properly, starting with the Driver ID entry/validation.

3.2.3.52 DMI.setDriverIdReady

Not Critical. Due to messages sequence proposed in Annex B1.2.4, this message is necessary to indicate to the OBU adaptor that the SoM procedure is reengaged. In our opinion, modifying this order, this message wouldn't be necessary.

3.2.3.53 DMI.setTrainRunningNumber

Critical. This message is intended for the Train Running Number Entry/Validation. Its use is decribed in Annex B1.2.4.

3.2.3.54 DMI.beginStartOfMission

Not Critical. Due to messages sequence proposed in Annex B1.2.4, this message is necessary to indicate to the OBU adaptor that the SoM procedure is reengaged. In our opinion, modifying this order, this message wouldn't be necessary. It is also redundant to DMI.SetDriverIDReady. It could be useful in case the data entry in the SoM is managed automatically by the OBU Adaptor. If the SoM is going to be completely controlled by the TCL, then it does not make sense.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


3.2.3.55 DMI.levelRequest

Critical. This message is intended for the Level and RBC Data Entry/Validation. Its use is described in Annex B1.2.4.

3.2.3.56 DMI.setFixedTrainData

Critical. This message is intended for the Train Type Selection/Validation. Its use is described in Annex B1.2.4.

3.2.3.57 DMI.setFlexibleTrainData

Critical. This message is intended for the Train Data Entry/Selection/Validation. Its use is described in Annex B1.2.4. The list of parameters is complete according to the SRS 3.4.0.

3.2.3.58 DMI.setAdhesion

Critical. This message is intended for the Adhesion Modification. Its use is described in 4.3.12.4.

3.2.3.59 DMI.setSRdata

Critical. This message is intended for the SR parameters modification. Its use is described in 4.3.12.4.

3.2.3.60 DMI.driverDecisionRequest

Critical. The list of values should be carefully crosschecked against the possible events on DMI. It seems this message is only valid for situations where the ETCS OBU request an action from the driver. Situations when the system offers several possibilities to the driver, must be handled in a different way, probably using message DMI.driverInput.

3.2.3.61 DMI.driverInput

Critical. The list of values should be carefully crosschecked against the possible inputs on DMI.

3.2.3.62 RADIO.data

Not critical. In principle, this message is not to be used with real RBCs.

3.3 Summary

The list of messages covers basically all needed interactions related to the OBU management, although some mismatches have been detected, mainly in the DMI messages. To a lesser extent, TIU messages are also affected.

There is also a general lack of definition on the functions distribution between the TCL and the OBU Adaptor. This fact is particularly clear on the train simulation function, which affects both systems, since the core simulation is done in the OBU Adaptor side, but the train management bust be controlled by the TCL. The mechanisms proposed in the IOP specifications could be improved considering other approaches (i.e. from Subset-094).




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


4 DETAILED ANALYSIS OF SUBSET-111-3

4.1 Introduction

Under Construction

4.2 Background

Under Construction

4.3 Summary

Under Construction




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


5 ANALYSIS OF THE RBS IMPLEMENTATION BASED ON THE EXPERIENCE

5.1 Introduction

According to the IOP standard, the train-track euroradio communication can be directly routed through a module called RBS.

This module enables the direct communication between subsystems and, hence, avoids overloading the communication through the TCL. Moreover, it is intended to bypass the real physical media used by the system (GSM-R airgap and fixed network), in order to simplify the test environment.

Its essential functions, as specified in (1), are:

Establishment and closing-down connections

Monitor the message transfer

Another optional functions are related to the possibility to interrupt the connection establishment for a certain time and the possibility to introduce time delays in the point-to-point communications.

These optional functions could be managed directly or through the TCL.

Figure 10. RBS Unit Overview




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


5.2 Background

The solutions adopted to perform the previous test campaigns both in CEDEX and RFI with MULTITEL were simplified in the following terms:

In CEDEX case, as only one on-board unit and only one RBC were involved, the connection-disconnection procedure was automatic: that is, no checking of the correctness of telephone number was done. Every time the on-board unit requested to contact the RBC, the connection request was accepted and redirected directly to the RBC. The data exchange was tunnelled through the VPN connection and redirected to the RBC through the standard ISDN PRI connection and to the OBU through the IGSM interface described in the MORANE specifications.

For RFI & MULTITEL, the solution adopted was the proprietary one from the RBC provider. The RBC presented a way to accept connections via Ethernet. MULTITEL OBU adaptor implemented the protocol on this interface.

5.3 Summary

The above experiences show several limitations, all of them due to the limited definition of RBS in the IOP documentation. Therefore, the steps to follow in VITE project should be:

Improve RBS definition and architecture, including the interfaces to the Adaptors and to the TCL for the correct management of the radio link during the tests.

Define the interfaces to the industrial equipment in order to become independent from industrial providers.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


6 ANALYSIS OF THE TRANSFER PROTOCOL STACK (XML-RPC) BASED ON THE EXPERIENCE

6.1 Introduction

Only RFI and MULTITEL have used this application protocol in the past. This protocol defines a “remote procedure call” using the HTTP protocol (based on TCP/IP protocol) as the transport and XML format for data encoding.

So a message is described by an “XML document” which nodes are filled and structured according to XML-RPC standard definitions. HTTP calls are used to send a message to the target system (adaptors or TCL).

6.2 Summary

The strongest and weakest points detected by RFI and MULTITEL are summarized below.

6.2.1 Strong points.

Using the HTTP protocol allows the communication and interaction among very different systems developed on heterogeneous platforms

The XML format allows to exchange structured data easy to access.

Using standard such as HTTP and XML allow to (re)use standard and predefined library to perform the communication and data manipulation. This improves the integration process speeding up the adaptor development and testing (as provided framework or library do not need to be tested.)

6.2.2 Weak points:

The XML format introduces a certain overhead in data sending and a computational load in the data managing. Anyway, according to the modern infrastructures and hardware, this impact can be considered negligible.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


7 STAGE 2 TEST ARCHITECTURE: ADAPTED IMPLEMENTATION OF SUBSET-111-2 FOR REMOTE TESTING

7.1 Introduction

For the Stage 2 Test Architecture, the main focus will be placed exclusively on Subset-111-2, which is the interface between the TCL and the OBU Adaptor. The difference with previous experiences consists on the upgrade to version 3.6.0 and the introduction of CEDEX as a laboratory compatible with IOP specifications.

7.2 List of messages

Only the messages catalogued as critical in section 3 will be included here. They are summarized below

Message Name From Level

CONFIG.requestData TCL mandatory

CONFIG.data OBU Adaptor mandatory

INIT.activate TCL mandatory

INIT.status OBU Adaptor mandatory

OBU.activate TCL mandatory

OBU.status OBU Adaptor mandatory

LOGGING.activate TCL mandatory

LOGGING.request TCL mandatory

LOGGING.result OBU Adaptor mandatory

JRU-LOGGING.request TCL mandatory

JRU-LOGGING.result OBU Adaptor mandatory

INFORMATION.error OBU Adaptor mandatory

MOVEMENT.setTarget TCL mandatory

MOVEMENT.setAdaptorBehaviour TCL mandatory

MOVEMENT.setGradientProfile TCL optional

BALISE.insertBalise TCL mandatory

BALISE.removeBalise TCL mandatory

TIU.sleeping TCL mandatory

TIU.passiveShunting TCL mandatory

TIU.nonLeading TCL mandatory

TIU.isolation TCL mandatory

TIU.brakeStatus OBU Adaptor mandatory

TIU.brakeActivation TCL mandatory

TIU.brakeConfiguration TCL mandatory




Issue: 1.0 Date:

29/12/2017

Class: PU / 33



TIU.brakePressure TCL mandatory

TIU.trainIntegrity TCL mandatory

TIU.selectCab TCL mandatory

TIU.selectDrivingDirection TCL mandatory

TIU.signalStatus OBU Adaptor mandatory

TIU.coldMovementStatus OBU Adaptor mandatory

TIU.getTrainDataEntryType TCL mandatory

TIU.replyTrainDataEntryType OBU Adaptor mandatory

DMI.getSystemVersion TCL mandatory

DMI.replySystemVersion OBU Adaptor mandatory

DMI.getLanguage TCL mandatory

DMI.replyLanguage OBU Adaptor mandatory

DMI.setLanguage TCL mandatory

DMI.getLevel TCL mandatory

DMI.replyLevel OBU Adaptor mandatory

DMI.getTrainType TCL mandatory

DMI.replyTrainType OBU Adaptor mandatory

DMI.getTrainCategory TCL mandatory

DMI.replyTrainCategory OBU Adaptor mandatory

DMI.getRadioNetworkId TCL mandatory

DMI.replyRadioNetworkId OBU Adaptor mandatory

DMI.getVBC TCL mandatory

DMI.replyVBC OBU Adaptor mandatory

DMI.setVBC TCL mandatory

DMI.removeVBC TCL mandatory

DMI.setPeriodicity TCL mandatory

DMI.status1 OBU Adaptor mandatory


DMI.rbcConnectionStatus OBU Adaptor mandatory

DMI.messageIndication OBU Adaptor mandatory

DMI.getNTCData TCL optional

DMI.replyNTCData OBU Adaptor optional

DMI.setDriverIdStart TCL mandatory




Issue: 1.0 Date:

29/12/2017

Class: PU / 33



DMI.setDriverIdReady TCL mandatory

DMI.setTrainRunningNumber TCL mandatory

DMI.beginStartOfMission TCL mandatory

DMI.levelRequest TCL mandatory

DMI.setFixedTrainData TCL mandatory

DMI.setFlexibleTrainData TCL mandatory

DMI.setAdhesion TCL mandatory

DMI.setSRdata TCL mandatory

DMI.selectNTC TCL optional

DMI.setNTCData TCL optional

DMI.driverDecisionRequest OBU Adaptor mandatory

DMI.driverInput TCL mandatory

RADIO.data Both mandatory

Table 2. Stage 2 selected messages.

7.3 Summary

The list of messages defined in the previous section is not the only prerequisite for the VITE Test Campaign, although the most important one. There is still some pending work to refine the attributes of the following messages, mentioned in Table 2.


CONFIG.requestData TCL mandatory

CONFIG.data OBU Adaptor mandatory

LOGGING.activate TCL mandatory

LOGGING.request TCL mandatory

LOGGING.result OBU Adaptor mandatory

JRU-LOGGING.request TCL mandatory

JRU-LOGGING.result OBU Adaptor mandatory

MOVEMENT.setTarget TCL mandatory

MOVEMENT.setAdaptorBehaviour TCL mandatory



Table 3 Stage 2 undefined messages.

It is also important to clarify the implementation of the RBS interface, since the current approaches from the different laboratories are incompatible nowadays.




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


8 STAGE 3 TEST ARCHITECTURE: VITE PROPOSAL FOR SUBSET-111-2 AND SUBSET-111-3

Under Construction




Issue: 1.0 Date:

29/12/2017

Class: PU / 33


9 CONCLUSIONS

At the present time the document is not yet complete. Additional effort must be done in the following subjects:

Harmonization of the content of messages mentioned in Table 3, for the Stage 2 test Architecture.

RBS definition improvement. The current approaches from laboratories to deal with the euroradio exchange are different and, moreover, include a different degree of dependence with respect to the trackside providers. The level of detail of the IOP specification is not helping, neither. This issue must be solved for the VITE test Campaign.

Analysis of Subset-111-3. This analysis is complicated because of the lack of experience in its use. It can only be analysed considering the laboratories experience working with proprietary interfaces from the trackside providers, what it is not obvious. This analysis must be undergone in the following months.

Introduce a complete proposal for the Stage 3 Test Architecture, taking advantage of the work done for Stage 2 and the analysis of Subset-111-3.

END OF DOCUMENT

FFFIS for the critical interfaces in the distributed lab ...

Documents

Transcript of FFFIS for the critical interfaces in the distributed lab ...