fffis for the critical interfaces in the distributed lab
TRANSCRIPT
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 Page 2 / 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
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 Page 3 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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
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 Page 4 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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
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 Page 5 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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.
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 Page 6 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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
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 Page 7 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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
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 Page 8 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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
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 Page 9 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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.
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 Page 10 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
Figure 3 Flow diagram for test action: train moves
Figure 2 Flow diagram for test action: Set/revoke route
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 Page 11 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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
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 Page 12 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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.
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 Page 13 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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
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 Page 14 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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
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 Page 15 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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.
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 Page 16 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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.
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 Page 17 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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.
This category can also be divided in:
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.
This category can also be divided in:
BALISE
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 Page 18 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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.
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 Page 19 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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.
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 Page 20 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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.
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 Page 21 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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
Not Critical. DMI action on the settings Window to check the language.
3.2.3.32 DMI.setLanguage
Not Critical. DMI action on the settings Window to check the language.
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.
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 Page 22 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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"
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 Page 23 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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.
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 Page 24 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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).
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 Page 25 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
4 DETAILED ANALYSIS OF SUBSET-111-3
4.1 Introduction
Under Construction
4.2 Background
Under Construction
4.3 Summary
Under Construction
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 Page 26 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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
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 Page 27 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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.
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 Page 28 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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.
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 Page 29 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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
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 Page 30 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
Message Name From Level
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.status2 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
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 Page 31 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
Message Name From Level
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.
Message Name From Level
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
DMI.status1 OBU Adaptor mandatory
DMI.status2 OBU Adaptor 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.
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 Page 32 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
8 STAGE 3 TEST ARCHITECTURE: VITE PROPOSAL FOR SUBSET-111-2 AND SUBSET-111-3
Under Construction
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 Page 33 / 33
VITE: Virtualisation of the Test Enviornment Grant Agreement No: 730815
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