functional requirements for an on board reference test ...€¦ · functional requirements for an...

© This document has been developed and released by UNISIG

SUBSET-094-0_v2.0.2

.

Functional Requirements for an on board Reference Test Facility /37

ERTMS/ETCS – Class 1

Functional Requirements for an on board

Reference Test Facility

REF : SUBSET-094-0

ISSUE : 2.0.2

DATE : 05/02/2009

Company Technical Approval Management approval

ALSTOM

ANSALDO SIGNAL

BOMBARDIER

INVENSYS RAIL

SIEMENS

THALES


SUBSET-094-0_v2.0.2

.


1. MODIFICATION HISTORY Issue Number

Date Section Number Modification / Description Author

0.0.1 13/01/2003

All First draft Raúl Martín,

Daniel Molina

0.0.2

15/02/2003

All Comments from the Madrid Meeting (08/02/2003) included

Raúl Martín,

Daniel Molina

0.0.3

05/03/2003

All Comments from the Braunsweig Meeting (21/02/2003) included

Raúl Martín,

Daniel Molina

0.0.4

09/04/2003

5.1.1.1.1

5.1.1.1.5

5.2.4.1.3

5.2.4.1.2

5.2.4.2.2

5.2.18

7.1.1.1.1

8.1.1.1.1

Comments from the Brussels Meeting (18/03/2003) and Paris Meeting (03/04/2003) included

Raúl Martín

1.0.0

14/04/2003

Change of the version number for delivery

Raúl Martín

1.0.1

05/10/2005

5.2.5.2

5.2.7.2

5.2.13.1

8

Comments from NoBos and update of Configuration Version.

Daniel Molina

1.0.2 5.1.1.1.5, 5.2.4.1.1,

5.2.4.1.2, 5.2.5.2.1, remove 10 and 11.2

Comments from the WG partners Daniel Molina

2.0.0

04-November-2004

Edition for delivery after acceptance of the UNISIG Test Specs WG members

Daniel Molina and Raúl Martín (CEDEX)

2.0.1

14-April-2008

4.1.1.1.2

5.2.10.1.3

5.2.10.1.4

5.2.10.1.5

5.2.13.1.6

Alignment to SRS 2.3.0 and some minor additions

Daniel Molina and Miguel Fernández (CEDEX)


SUBSET-094-0_v2.0.2

.


8.1.1.1.1

2.0.2 3.1.1.1.1

3.1.1.1.2

4.1.1.1.1

4.1.1.1.2

4.1.1.1.3

5.2.13.1.2

8.1.1.1.1

Editorial corrections. Update of the Configuration version and References table.

Oscar Rebollo


SUBSET-094-0_v2.0.2

.


2. TABLE OF CONTENTS 1.� MODIFICATION HISTORY................................................................................................................2�

2.� TABLE OF CONTENTS....................................................................................................................4�

3.� OBJECTIVES.................................................................................................................................5�

4.� INTRODUCTION .............................................................................................................................6�

5.� REFERENCE ON BOARD EQUIPMENT TEST ARCHITECTURE .............................................................7�

5.1� General Overview .............................................................................................................7�

5.2� Test Modules Definition.....................................................................................................9�

5.2.2� Scenario Generator (SG) ...........................................................................................9�

5.2.3� Scenario Controller (SC) ............................................................................................9�

5.2.4� TIU Simulator (TIUS) ...............................................................................................12�

5.2.5� TIU Adaptor .............................................................................................................13�

5.2.6� Speed Sensor Simulator (SSS)................................................................................14�

5.2.7� ODO Adaptor ...........................................................................................................16�

5.2.8� Train Motion Simulator (TMS) ..................................................................................18�

5.2.9� ETCS Level 1 Trackside simulator (L1TS) ...............................................................19�

5.2.10� ETCS Level 2 Trackside Simulator (L2TS)...............................................................21�

5.2.11� ETCS Level STM Trackside Simulator (LSTMTS)....................................................23�

5.2.12� Module Event Recorder (MER) ................................................................................24�

5.2.13� Euroradio Communication Simulator (ECS) .............................................................26�

5.2.14� JRU Downloading Evaluation Module (DEM) ...........................................................27�

5.2.15� Eurobalise and Euroloop Signal Generator (BSG & LSG)........................................27�

5.2.16� STM Coding and Communication (STMCC).............................................................28�

5.2.17� DMI Event Recorder (DER)......................................................................................29�

5.2.18� Driver or Emulator....................................................................................................29�

5.2.19� Trip Analysis & Validation (TAV) ..............................................................................29�

6.� STATE DIAGRAMS .......................................................................................................................31�

7.� SYSTEM INTEGRITY AND VALIDATION ...........................................................................................33�

8.� CONFIGURATION VERSION AND REFERENCES ..............................................................................34�

9.� ABBREVIATIONS .........................................................................................................................36�

10.� APPENDIX ............................................................................................................................37�

10.1� TTL Signals .................................................................................................................37�


SUBSET-094-0_v2.0.2

.


3. OBJECTIVES

3.1.1.1.1 This document defines the functional requirements for an ETCS reference test facility to perform test on the On board IC. The supplier of the test facility will use this document to prepare a detailed proposal for the implementation of the test facility

The Reference Test facility is required to provide a mean for Notified Bodies to assess the compliance of suppliers’ equipment with the specifications mandated in the Control Command and Signalling TSI. Currently the mandated specifications are tied to the ETCS Subset-026 version 2.3.0. Test specifications (Subset-076) are linked with the architecture defined in this paper, because they constitute the basic requirements to be tested on the on board equipement by using the architecture.


SUBSET-094-0_v2.0.2

.


4. INTRODUCTION

4.1.1.1.1 The test architecture to test the ERTMS/ETCS on board equipment is shown in this document. The architecture presented intends to be the “Reference Architecture”, called so because this Architecture allows to test the “On Board Equipment”, which has not only standard interfaces (FFFIS), but also other which, although they are national solutions (odometry and TIU), can be easily adapted. This architecture allows to run the test sequences (defined in Subset-076) proving compliance of the on board equipment with the requirements defined in the Subset-026 .

4.1.1.1.2 The mandatory components for the reference test architecture are related to levels 0, 1 and 2. The components related to Euroloop and STM have been defined although they are considered as optional interfaces for the ETCS On-board equipment. Finally, the test architecture should be reviewed in the future to cope with the Level 3 functionality.

4.1.1.1.3 Therefore, the on board equipment shall be provided by the supplier and must be properly interfaced with the architecture in order to be tested.


SUBSET-094-0_v2.0.2

.


5. REFERENCE ON BOARD EQUIPMENT TEST

ARCHITECTURE

5.1 General Overview

5.1.1.1.1 An overview of the ETCS On Board Class 1 test architecture is shown in the next figure:

ON BOARDINDUSTRIALEQUIPMENT

TIU

EURORADIOBTM

STM

JRU ODODMI

DRIVEROR

EMULATOR

LOOP

EURORADIO COM.SIMULATOR

RCS

FFFIS (wired)

ETCS L2 TRACKSIDESIMULATOR

L2TS

EUROLOOP SIGNALGENERATOR

LSG

FFFIS

ETCS LEVEL STMTRACKSIDE SIMULATOR

LSTMTS

STM CODING &COMMUNICATION

STMCC

FFFIS

FFFIS

DATA EXCHANGE

ETCS L1 TRACKSIDESIMULATOR

L1TS

EUROBALISE SIGNALGENERATOR

BSG

FFFIS

SCENARIOCONTROLLER

SC

MODULE EVENT RECORDERMER

SCENARIOGENERATOR

SG

JRU DOWNLOADEVALUATION MODULE

DEM

TRIP ANALYSIS &VALIDATION

TAV

DMI EVENTRECORDER

DER

SPEED SENSOR SIMULATOR

SSSSPEED

TIU Signals

TIUSIMULATOR

TIUS

ODOADAPTOR

TIUADAPTOR

TRAIN MOTIONSIMULATOR

TMS

Air gap is used

Equipment to be tested

Laboratory Modules

ADAPTOR FFFIS

ADAPTOR FFFIS

5.1.1.1.2 The boxes shown in the figure are “functional modules”. They can be implemented using one or several machines.

5.1.1.1.3 The set of modules in charge of performing the simulation are shown in the previous figure. The test to be performed is defined in the “Scenario Generator (SG)”. Once the test has been specified, it will produce information which will be needed by the other modules. The Scenario Controller (SC) distributes this information between the other modules and configures them before the simulation starts. This module also performs monitoring tasks during the simulation.


SUBSET-094-0_v2.0.2

.


5.1.1.1.4 The modules in charge of simulating the train dynamic are the “Speed Sensor Simulator” (SSS), the “TIU Simulator” (TIUS) and the “Train Motion Simulator” (TMS). This last module calculates the speed and acceleration of the train taking into account the interventions read from the TIU. These interventions are read by the TIUS, which also takes care of other TIU signals that have nothing to do with interventions. The “Speed Sensor Simulator” (SSS) calculates the travelled distance and gives this datum to the modules that need it, and also provides an odometry signal to the onboard equipment. Both the SSS and the TIUS are connected to the on board equipment through adaptors. This is necessary because interfaces are not defined at a FFFIS level. Therefore, an interface at such detail will be defined between the laboratory (TIU and SSS) and equipment, so that the company can build specific adaptors to turn the signals given by the laboratory into the ones that their specific implementation need. Therefore, these adaptors will be provided by the companies.

5.1.1.1.5 During the simulation, messages must be sent to the on board equipment to perform the test. The “Level 1 Trackside Simulator” (L1TS) sends eurobalise and euroloop messages through a reference loop (see Subset-085, Test Specification for Eurobalise FFFIS), according to the travelled distance. The “Level 2 Trackside Simulator” (L2TS) sends radio messages (also in fill) according to the travelled distance, time constraints and conditions about having received or sent other messages previously. The “Level STM Trackside Simulator” (LSTMTS) sends STM messages according to the same kind of conditions as the L2TS. Each one of these modules is connected to another, so the information produced by each one of them goes through another module before getting to the on board equipment. The L1TS is connected to the BSG and LSG which are the equipment in charge of producing the signals needed to interface with the on board equipment through the balise and loop interface using the FFFIS. The LSTMTS is connected to the “STM Coding and Communication” (STMCC) which will add all the layers needed to the messages and will send and receive them through a profibus connection. The L2TS is connected to the “Radio Communication Simulator” (RCS). This module codes and decodes the messages and is connected to the on board equipment using the interface this one has to link with the mobile equipment. This way, air gap is not needed for this complex interface and the simulation can take place using AT commands (as defined in A 11 T 6001 12).

5.1.1.1.6 The “Module Event Recorder” (MER) collects data from all the modules while the simulation takes place. Once the simulation has finished, the data stored in the on board equipment JRU is downloaded using the “Download Evaluation Module”. These sets of data and the specification of the test (what the on board equipment had to do) are used in the “Trip Analysis and Validation” (TAV) to analyse if the on board equipment has behaved according to the test or if it has not.

5.1.1.1.7 The Reference Architecture is based on a system in which radio messages are predefined. They are sent according to rules based on travelled distance and time, and


SUBSET-094-0_v2.0.2

.


they would be also conditional, so the delivery of some messages would depend on the previous arrival of others. These are the reasons:

• Certification Purposes: Using this architecture, all on board equipments are going to be tested with the same test specification defined by UNISIG.

• Using a real RBC, due to its dynamical behaviour, would be difficult to perform tests exactly in the same way and some specific test states cannot be created or reproduced.

• The detailed information about the modules described in this short overview can be found in the next sections.

5.2 Test Modules Definition

5.2.1.1.1 The Simulation is based on playing train trips described by scenarios, which are specified offline. The trip is translated into files, composed of train speed profile, track description, train data, messages for balises, STM and Radio, which are sent according to the travelled distance or time. These files will be used by different software and hardware modules to input information in the on board equipment. As the trainborne equipment has several interfaces, and it is a complex system, a central module will be used to set up, control and monitor the others. Therefore, there will be two phases in the simulation process. In the first one (configuration phase), this central software will configure and set up the others, and in the second phase the simulation and test will actually take place.

5.2.2 Scenario Generator (SG)

5.2.2.1 Functional Description

5.2.2.1.1 This is an offline module used to define test sequences. Once a test sequence is specified, it is transformed into several data files that will be used by the other modules when the simulation is being performed. These files are sent to the Scenario Controller via the communication link.

5.2.2.1.2 It will be possible to define the test manually or it will be able to read the “Test Sequences” format produced by the Test Sequences Working Group.

5.2.3 Scenario Controller (SC)


5.2.3.1.1 This module receives the files produced by the Scenario Generator. When a simulation is started, it sends the necessary data to configure the other modules, configures them, and starts the simulation. It also does a real time monitoring of the progress of the test on the screen. This module is as well responsible for other tasks:


SUBSET-094-0_v2.0.2

.


• Interaction with the operator

• Loading and synchronising an scenario/sequence

• Starting the simulation

• Real Time monitoring of the simulation and graphical representation of the speed profile

• Possibility to abort the simulation by the operator

• It will show when a message is sent to the on board equipment through the balise or radio interface

5.2.3.2 Communication with other modules

5.2.3.2.1 Communication with the Train Motion Simulator (TMS)

• Configuration Phase: The following information is sent to the TMS

o Train data

o Track description

o Predefined speed profile and some other general parameters

• Dynamic Phase: The Scenario Controller (SC) receives from the Train Motion Simulator (TMS)

o The train acceleration

o The train speed

o Failures occurring within the TMS

5.2.3.2.2 Communication with the Speed Sensor Simulator (SSS)

• Configuration Phase: information sent to the SSS

o Set of parameters to configure the speed data format.

• Dynamic Phase: the Scenario Controller receives from the SSS

o Travelled distance.

o Failures occurring within the SSS

5.2.3.2.3 Communication with the TIU Simulator (TIUS)

• Configuration Phase:

o A set of predefined TIU messages is sent to the TIUS

• Dynamic Phase:

o Failures occurring within the TIUS are reported to the SC

5.2.3.2.4 Communication with the Level 1 Trackside Simulator:

• Configuration Phase: The following information is sent to the L1TS


SUBSET-094-0_v2.0.2

.


o A table containing the locations at which a trigger must be transmitted to the Eurobalise Signal Generator when the beginning of a balise group is reached

o A table containing the telegrams to be transmitted

• Dynamic Phase:

o Level 1 Trackside Simulator informs SC when it sends a telegram or a trigger to the Eurobalise or Euroloop Signal Generator

o Failures occurring within the L1TS are sent to the SC



o A table containing the messages and location at which they have to be sent is given to the L2TS; it contains also optional conditions based on a time or distance window which inhibit/permit the transmission of a predefined message

• Dynamic Phase:

o Level 2 Trackside Simulator informs SC when it sends a message to the Euroradio Communication Simulator (RCS), or when it does not send one, due to a condition which was not fulfilled. The Level 2 Trackside Simulator informs SC when it receives a message

o Failures occurring within the L2TS

5.2.3.2.6 Communication with the Level STM Trackside Simulator (LSTMTS):

• Configuration Phase: Information sent to the LSTMTS

o Messages and release condition (message, location/time, optional condition within time or distance window).

• Dynamic Phase:

o Failure detected, if applicable, is sent to the Scenario Controller

5.2.3.2.7 Communication with the Module Event Recorder (MER):


o The Scenario Controller sends to the Module Event Recorder all the information it has used to configure the rest of the modules and the Module Event Recorder answers with an acknowledgment.

• Dynamic Phase:

o Failure detected, if applicable, is sent to the SC.

5.2.3.3 Performance and I/F requirements


SUBSET-094-0_v2.0.2

.


5.2.3.3.1 As this piece of software is in charge of controlling and monitoring the simulation, it must handle several communication links. Some of the information exchanged is to configure the rest of the modules (configuration phase), and the other information is for monitoring and reporting (dynamic phase). As the information exchanged is not time critical for the simulation, there are no special requirements about the performance for this communication.

5.2.4 TIU Simulator (TIUS)


5.2.4.1.1 The TIU Simulator will account for the communication with the industrial on board equipment through the TIU Adaptor. The TIU simulator shall implement all the TIU signals mentioned in the S.R.S.

5.2.4.1.2 This data flow will consist mainly of digital I/O signals like brakes commands, pantograph state, etc (use SUBSET-034 v200 TIU FIS when applicable). As the TIU interface is critical for the simulation, the interface with the lab will be capable of handling a real-time communication between the TIU Adaptor and the laboratory.

5.2.4.1.3 As each company has different TIUs (there is no FFFIS for this interface), it is necessary to adapt the signal going to and coming from this interface. The TIU simulator will provide a set of inputs/outputs to the TIU. The TIU Adaptor will turn these inputs into the adequate values and signals the TIU can handle. The signals provided by the TIU will be also transformed in a way that the TIU simulator can understand them. Therefore, there will be as many adaptors as TIUs.


5.2.4.2.1 Communication with the Scenario Controller (SC):


o Table of TIU actions to be issued at a predefined distance/time is sent to the TIUS

• Dynamic Phase:

o Failures occurring within the TIUS are transmitted to the SC

5.2.4.2.2 Communication with the Train Motion Simulator (TMS):

• Dynamic Phase: Information sent to the TMS

o Interventions: service and emergency brake command & traction cut off command

o Train Status: Pantograph up/down & main switch open close

5.2.4.2.3 Communication with the Speed Sensor Simulator:


SUBSET-094-0_v2.0.2

.


• Dynamic Phase:

o TIUS receives from SSS at least 10 times per second the distance travelled (or more if it is necessary for the accuracy of the test to be performed)

5.2.4.2.4 Communication with the TIU Adaptor:

• Dynamic Phase:

o The signals given by the train are read from the TIU Adaptor, and the signals given to the train are sent to the TIU Adaptor.


• Dynamic Phase: Information sent to the MER

o Cyclic information (braking orders, odometer parameters) is transmitted at a frequency which is a configuration parameter

o All non cyclic information passing through the TIUS are always recorded

o All information recorded is accompanied by the time and odometer stamp.


5.2.4.3.1 As the TIU information is critical for the simulation, it must be handled in real time (the implementation must ensure that these signals are immediately taken into account). This information is also needed by other modules, as the Train Motion Simulator. As the train dynamic is part of the simulation core, this channel must be also real time, as well as the communication with the Speed Sensor Simulator (SSS).

5.2.5 TIU Adaptor


5.2.5.1.1 This module offers a translation from the input/outputs between the company specific Train Interface Unit (TIU) and the laboratory (TIU Simulator). This adaptor will be provided by the company which wishes to perform tests in the facility.

5.2.5.2 Interface between the TIU Simulator and the TIU Adaptor

5.2.5.2.1 This interface shall be able to handle all the TIU signals used in all the Test Sequences of Subset-076-6-3. e.g.: sleeping, isolation, service brake, emergency brake, main switch, traction cut-off, direction controller, cab status, pantograph, air tightness, passenger emergency brake inhibition, regenerative, eddy current and magnetic shoe brakes inhibition, switch-off balise transmission and STM activation. If the TIU adaptor does not provide all the TIU signals used in the Test Sequences, the scope of the certification will be limited by these unavailable signals.


SUBSET-094-0_v2.0.2

.


5.2.5.2.2 Digital input/output boards will be used. This way, signals will be introduced and taken from the TIU through an interface quick enough to meet the performance requirements. The levels of the signals will be TTL. Subset-034 TIU FIS may be used for reference, when applicable.

5.2.6 Speed Sensor Simulator (SSS)


5.2.6.1.1 The Speed Sensor Simulator receives the train speed from other module (the Train Motion Simulator) through a real time channel. Then it provides an output signal, which is connected to the ODO Adaptor. This way, the EVC believes the train is moving. This signal is also transmitted to the Level 1 Trackside Simulator, so that it can determine the position reached.

5.2.6.1.2 The companies use different odometry sensors in their equipments, so the odometry adaptor is needed to turn the signal given by the simulator into the different solution each enterprise uses.


5.2.6.2.1 Communication with Scenario Controller (SC):

• Configuration phase: Information sent to the SSS

o The frequency at which the speed is read, the recording frequency, and the value of the distance increment.

• Dynamic phase:

o The distance travelled by the train is transmitted from SSS to SC.

o A failure detected by SSS will be transmitted to SC.

5.2.6.2.2 Communication with Train Motion Simulator (TMS):

• Dynamic phase:

o The train speed generated by TMS is read at least 10 times per second (or more if it is necessary for the accuracy of the test to be performed) by the SSS.

o The travelled distance is given to the TMS at least 10 times per second (or more if it is necessary for the accuracy of the test to be performed).

5.2.6.2.3 Communication with the TIU Simulator (TIUS):

• Dynamic phase:

o The TIU Simulator receives the travelled distance from the SSS at least 10 times per second (or more if it is necessary for the accuracy of the test to be performed).


SUBSET-094-0_v2.0.2

.


5.2.6.2.4 Communication with Level STM Trackside Simulator (LSTMTS):

• Dynamic phase:

o The travelled distance is sent to the LSTMTS at least 10 times per second (or more if it is necessary for the accuracy of the test to be performed)

5.2.6.2.5 Communication with the Level 1 Trackside Simulator (L1TS):

• Dynamic Phase:

o The travelled distance and speed are sent to the L1TS. The travelled distance is needed to issue the triggers to the BSG. The rate at which this datum must be sent to the L1TS from the SSS will depend on the precision needed and the speed at which the simulation is run. If the train is moving at v m/s, and the exchange rate is t, the precision is x=v/t (for v= 10 m/s and t=10, the precision would be 1 meter). Therefore, this exchange rate must be calculated to have the right performance to run the simulation depending on the speed of the train and the precision needed.

5.2.6.2.6 Communication with Level 2 Trackside Simulator (L2TS):

• Dynamic phase:

o The travelled distance is sent to the L2TS at least 20 times per second (or more if it is necessary for the accuracy of the test to be performed although this could be enough, as radio messages are not exactly tied to a position as balise messages are).

5.2.6.2.7 Communication with the ODO Adaptor:

• Dynamic Phase:

o The train speed is sent to the ODO Adaptor

5.2.6.2.8 Communication with Module Event Recorder (MER):

• Dynamic Phase:

o Time elapsed since beginning of trip (time stamp)

o Distance travelled by the train (odometer stamp)


5.2.6.3.1 The communication channels used to receive the speed (SSS � TMS) and to give the travelled distance (SSS�Other modules) must be quick enough to fulfil the performance requirements.


SUBSET-094-0_v2.0.2

.


5.2.7 ODO Adaptor


5.2.7.1.1 The adaptor will turn the generic output provided by the SSS into an odometry signal understandable by the specific on board equipment sensors. This adaptor will be provided by the company which wishes to perform tests in the facility.

5.2.7.2 Interface between the laboratory and the ODO Adaptor

5.2.7.2.1 This interface is critical for the simulation, and therefore, the speed data must be given in a way which ensures the minimum possible delay and an easy adaptation by means of the adaptor. The best way to do this is using an odometer like signal. Giving the signal like this, the companies that use a standard odometer sensor only need to do a hardware adaptation. In those cases, where the EVC’s odometry system is too complex to get all the needed information from this square waveform signal, the SSS can also supply a serial connection (RS-232) including timestamp, speed and acceleration.

5.2.7.2.2 An odometer sends a square signal which determines the traveled distance. Each period of this signal represents two distance increments. Dividing this distance by the elapsed time, the real speed of the train can be obtained.

5.2.7.2.3 We can use two ways for giving the distance and direction information. We need at least a first signal giving the travelled distance information and another signal giving the direction information. This second signal could be a digital signal (0 forward and 1 backward) or the same incremental signal as the first one but with a difference of phase of plus or minus 90 degrees.

5.2.7.2.4 The Speed Sensor Simulator will calculate the frequency which corresponds to the speed issued from the Train Motion Simulator calculation using the formula:

ISpeed

Frequency2= , where I is the increment of distance;

5.2.7.2.5 The I parameter will be configurable to some extend. If a too high or a too low value is chosen, the frequency could result in a strange value to be produced by the hardware. The highest value of the frequency of the square signal will be 10 KHz. If the train is moving at 500 Km/h (v=138.9 m/s, worst case scenario), the diameter of the wheel is 1 m (D=1m), and the wheel has 20 teeth (k=20), the frequency needed would be:

HzDvk

f 884·· ==

π


SUBSET-094-0_v2.0.2

.


5.2.7.2.6 Although 1 KHz would be enough for a typical case, having a maximum value of 10 KHz ensures that strange combinations of diameter of the wheel and number of teeth will be able to be reproduced in the test facility.

5.2.7.2.7 With this value, for example, if the train is running at 100 m/s (360 Km/h) the increment would be:

cmHz

smfv

I 210000

/100·22 === , which is accurate enough.

5.2.7.2.8 The way in which the direction is given will also be configurable. There are two possibilities:

5.2.7.2.8.1 Digital output signal (TTL level):

o 0: forward

o 1: backward

5.2.7.2.8.2 Same incremental signal as the first one but with a difference of phase:

o + 90º: forward

o – 90º: backward

5.2.7.2.9 The physical configuration of the serial channel is 38400 bits/sec, eight bits of data, no parity and one stop bit. The following message is sent every 100 milliseconds.

5.2.7.2.10 The SSS provides a DB-9 male connector, with the following pin assignment. The mandatory signals are just RD, TD and GND.


SUBSET-094-0_v2.0.2

.


5.2.7.2.11 The use of the square waveform signal and/or the serial link is not mandatory, being possible to agree another solution between the laboratory and the industrial EVC supplier. The new solution shall not imply a loss of performance in comparison to the proposed solutions in this document.

5.2.8 Train Motion Simulator (TMS)


5.2.8.1.1 The train motion simulator goes through a cyclic sequence, calculating train speed and acceleration in real time, according to the parameters that were provided by the scenario controller and according to the interventions received from the TIU.

5.2.8.1.2 The model of the train used by this module must be accurate enough to ensure that the speed will be calculated with an error less than 1 km/h.

5.2.8.1.3 The module will take into account different interventions:

• Service Brake

• Emergency Brake

• Traction Cut off

• Direction Controller

• Pantograph up/down;

• Main switch open/closed.

5.2.8.1.4 When such a change is detected the train follows the relevant order:

• Pantograph is raised: the train follows the predefined speed profile and gives traction when and where required;

• Pantograph is lowered: the train cuts the traction off and continues to run in coasting mode;

• Main switch is closed: the train follows the predefined speed profile and gives traction when and where required;

• Main switch is opened: the train cuts the traction off and continues to run in coasting mode.

• This module sends the current speed to the Speed Sensor Simulator, and receives the distance travelled from it (managed in real time). It also sends the current speed and acceleration to the scenario controller.



• Configuration Phase: Information sent by the SC


SUBSET-094-0_v2.0.2

.


o Track description, from which the electrical profile and gradient information is extracted;

o Train description, including a predefined speed profile;

o Other parameters such us driver reaction time, frequency of speed calculation, etc.

• Dynamic Phase: Information sent to the SC

o Train speed

o Failure detection, if applicable

5.2.8.2.2 Communication with the Speed Sensor Simulator (SSS):

• Dynamic Phase:

o The SSS receives from the TMS the current speed (at least ten times per second)

o The SSS sends the travelled distance to the TMS (at least ten times per second)

5.2.8.2.3 Communication with the TIU Simulator (TIUS):

• Dynamic Phase:

o The TMS receives from the TIUS as often as possible:

� Emergency and service brake interventions

� Train Status: Traction cut off, pantograph up/down, main switch open/closed

5.2.8.2.4 Communication with the Module Event Recorder:

• Dynamic Phase:

o Train speed, time stamp and odometer stamp are sent to the MER


5.2.8.3.1 As explained before, the communication with the TIUS and the SSS will be done in real time (for the interfaces which require this, not for the tasks of monitoring and configuration).

5.2.9 ETCS Level 1 Trackside simulator (L1TS)


5.2.9.1.1 During the Configuration phase, the ETCS Level1 Trackside Simulator receives different information: a table of load and trigger distances. It must also receive the balise telegrams. These telegrams can be encoded before the simulation starts and would be sent to the L1TS during the configuration phase or they can be coded during the dynamic phase (this is a detail opened for implementation). These data will be


SUBSET-094-0_v2.0.2

.


used to feed the Eurobalise Signal Generator in real time (the distance at which the messages are sent is critical and the delays must be minimum). This way, the L1TS knows when to load data into the generator, and according to the travelled distance received from SSS, triggers the Generator, to send its output to the reference loop.

5.2.9.1.2 The dynamic phase consists of an endless loop that reads continuously the train location from the Speed Sensor Simulator in order to detect the moment at which a trigger has to be issued.

5.2.9.1.3 As this laboratory will be used to perform functional tests, it is not necessary to simulate the air gap with a perfect accuracy. It is enough to deliver the messages using the air gap, simulating the train speed in a simple way. “When the trains approaches the balise”, the signal generators will make the electromagnetic field grow, following a slope, until it reaches the maximum value. After that, it will decrease to become zero. So the exact waveform won’t be simulated, but the speed of the train will be taken into account by this simple procedure. Both the slope and the interval of time in which the message is sent will be correlated to the speed.

5.2.9.1.4 So we will only use the air gap to introduce messages in a standardised way (FFFIS), but not to perform tests about the interface. These tests are out of the scope of this laboratory and will be performed in the “Eurobalise Laboratory”.



• Configuration Phase: The L1TS receives

o The distances at which the balise messages will be sent

o The content of the balise messages

o Any other information that might be necessary to use the EuroBalise Signal Generator (BSG)

• Dynamic Phase:

o Detection of failure, if applicable, is sent to the SC

o Reports on telegram sending for display purposes


• Dynamic Phase:

o The train location and speed or the odometry signal to know when to issue the triggers. The rate at which the travelled distance must be sent to the L1TS from the SSS will depend on the precision needed and the speed at which the simulation is run. If the train is moving at v m/s, and the exchange rate is t, the precision is x=v/t (for v= 10 m/s and t=10, the precision would be 1 meter). Therefore, this exchange rate must be calculated to have the right performance to run the simulation depending on the speed of the train and the precision needed.


SUBSET-094-0_v2.0.2

.


5.2.9.2.3 Communication with the Eurobalise Signal Generator (BSG):

• Dynamic Phase:

o The EuroBalise Signal Generator (BSG) is handled in the proper way to send the messages to the train antenna at the right location. This way depends on the equipment chosen to generate the signals.


• Dynamic Phase: Information sent to the MER

o The train location is sent to the MER when L1TS generates a trigger


5.2.9.3.1 The communication with the SSS (to get the travelled distance) and with the equipment in charge of generating the waveforms must be real-time.

5.2.10 ETCS Level 2 Trackside Simulator (L2TS)


5.2.10.1.1 During configuration phase, The ETCS Level 2 Trackside Simulator (L2TS) receives:

• Table of predefined radio messages;

• For each message, optional condition including:

o Type of condition (time or distance);

o Window beginning (time or distance);

o Window end (time or distance);

o Identity of expected radio message within time/distance window.

5.2.10.1.2 The L2TS will be able to receive the predefined radio messages specifying which RBC is sending the corresponding message.

5.2.10.1.3 The issue of a telegram can be conditional, as it is seen in the information it receives during the configuration phase. The L2TS shall manage the expected release condition properly.

5.2.10.1.4 It will also set up one link per GSRM modem with the Euroradio Communication Simulator, to prepare it for the dynamic phase.


SUBSET-094-0_v2.0.2

.


5.2.10.1.5 The L2TS is also in charge of simulating the radio in-fill, if this option is implemented by the architecture (as it was explained in the introduction, this is not a mandatory option).

5.2.10.1.6 The travelled distance is received from the Speed Sensor Simulator (SSS). Radio messages are not so tied to a position as balise ones. Therefore, the rate at which the travelled distance is sent to the L2TS doesn’t need to be very high (20 times per second should be enough), although it must be ensured that this datum is sent continuously to the L2TS without delays. When the correct moment/distance is reached, the radio telegram is transmitted.


5.2.10.2.1 Communication with the Scenario Controller:

• Configuration Phase: Information sent to the L2TS


• Dynamic Phase:

o Failure detected, if applicable, is sent to the SC

o Messages sent or received report for display purposes


• Dynamic Phase:

o The L2TS receives through a real-time channel the travelled distance at least 20 times per second


• Dynamic Phase:

o Content of the received/transmitted message and time stamp is sent to the MER

5.2.10.2.4 Communication with the Euroradio Communication Simulator:

• Dynamic Phase:

o The messages must be sent and received to and from the Euroradio Communication Simulator through a quick enough channel to ensure the proper functionality of these two modules.



SUBSET-094-0_v2.0.2

.


5.2.10.3.1 The only requirements in this section are the handling of the communication. They must be quick enough with Euroradio Communication Simulator and the Speed Sensor Simulator to guarantee the performance needed for the simulation.

5.2.11 ETCS Level STM Trackside Simulator (LSTMTS)


5.2.11.1.1 This module plays a similar role to ETCS Level 1 and 2 Trackside Simulator, but for STM level (see STM FFFIS subset-035). This module will be generic and will follow the STM Specification. During the configuration phase, it receives a set of messages from the Scenario Controller that will be sent to the on board equipment, to simulate an STM (this messages will be sent through the STM Coding and Communication Module which will be in charge of coding the messages and handling the communication with the on board equipment). It also receives information about when sending the messages (time or distance).

5.2.11.1.2 During the dynamic phase (the simulation), it reads the travelled distance from SSS, to know when it must send the messages. The rate at which this data is sent depends on the STM simulated. If the national system is based on balises the performance would have to be similar to the one which L1TS has. The same analysis based on speed and on accuracy is valid for this module.

5.2.11.1.3 The delivery can be conditional, being necessary that some conditions are fulfilled to send the messages (for example, receiving a certain telegram from the on board equipment).



• Configuration Phase: Information sent to the LSTMTS


• Dynamic Phase:



• Dynamic Phase:

o The LSTMTS receives through a real-time channel the travelled distance

5.2.11.2.3 Communication with the Module Event Recorder:

• Dynamic Phase:


SUBSET-094-0_v2.0.2

.


o Content of the received/transmitted message and time stamp are sent to the MER

5.2.11.2.4 Communication with the STM Coding & Communication:

• Dynamic Phase:

o The messages must be sent and received to and from the STMCC through a quick enough channel to ensure a real-time performance.


5.2.11.3.1 The only requirements in this section are the handling of the communication. They must be quick enough to assure the performance with STM Coding & Communication and the Speed Sensor Simulator.

5.2.12 Module Event Recorder (MER)


5.2.12.1.1 Its purpose is to record useful information from the others tools. The recorded information, together with the data downloaded from JRU, allows an off-line evaluation of a test sequence, which will be done by the “Trip Analysis and Validation”.

5.2.12.1.2 MER is connected to the tools that appear in the laboratory schematic through the communication link.

5.2.12.1.3 A scheme of the data flow with the MER is shown in the next figure:


SUBSET-094-0_v2.0.2

.


MER(Module Event Recorder)

Speed SensorSimulator

Train Motion Simulator

ScenarioController

Time StampDistance Traveled

Time StampSpeed

Configuration Information

Acknowledgement

ETCS Level 1Trackside SimulatorTime Stamp

Location where triggered

ETCS Level 2Trackside Simulator

Time/Odo StampContent of received/transmitted messages

STM Messages Generator

Time stampContent of received/transmitted messages


5.2.12.2.1 All information goes from the Module to the Module Event Recorder (MER), except if a failure is detected in the Module Event Recorder. In this case, a report will be sent to the Scenario Controller.



o All configuration files

• Dynamic Phase:



• Dynamic Phase:

o Travelled Distance with the time stamp

5.2.12.2.4 Communication with the Train Motion Simulator:

• Dynamic Phase:

o Train speed with the time stamp


SUBSET-094-0_v2.0.2

.


5.2.12.2.5 Communication with the Level 1 Trackside Simulator

• Dynamic Phase:

o Location where a balise message is triggered and time stamp


• Dynamic Phase:

o Content of the received/sent message with the time stamp

5.2.13 Euroradio Communication Simulator (ECS)


5.2.13.1.1 This module plays the role of the “ME” boarded equipment (GSM-R mobile equipment). In a first step, it informs the ETCS on board equipment about the GSM-R network state and manages the call to the RBC. This stage is called “command state” and is regulated by document “Radio Transmission FFFIS for Euroradio”. In the “command state”, the ECS has to answer correctly the AT commands sent by the ETCS on board equipment and manage the control signals at physical level.

5.2.13.1.2 Once the connection is established, the situation moves to the “online data state”. At this moment, the ECS must deal with the safety and lower communication layers described in Subset-037 “EuroRadio FIS”. Specially for the safety layer, it is necessary to agree a common KMAC (cryptographic key) between the laboratory and the EVC industrial supplier. This KMAC shall be used afterwards to build the corresponding Ks (Session Key) that is used in the ERTMS messages encryption.

5.2.13.1.3 During the “online data state”, the ECS has to decrypt the messages received from the EVC and send them to the L2TS. By the other side, when the ECS receives a message from the L2TS, it has to encrypt it and deliver it again to the EVC, respecting all the Euroradio protocols. The ECS has also to deal with the procedures of the lower communication layers defined in Subset-037 and referenced documentation.

5.2.13.1.4 This simulator must be complete enough, and must have all the functionality required to test all requirements specified in SRS (and therefore, in the Test Sequences).

5.2.13.1.5 The physical connection between the ECS and the EVC shall follow the recommendation V.28/RS-232 included in “Radio Transmission FFFIS for Euroradio”, section 4.2.3. In case the RTM output follows the other recommendation (V.11/RS-422), the company shall provide an adequate RS422-RS232 converter.

5.2.13.1.6 This simulator must ensure that two different radio sessions can be handled simultaneously, in case the EVC is equipped with two different modems.


SUBSET-094-0_v2.0.2

.




• Dynamic Phase:

o The messages must be sent and received to and from the L2TS through a quick enough channel to ensure a real-time performance.


5.2.13.3.1 It communicates with the ETCS Level 2 Trackside Simulator via a quick enough channel.

5.2.14 JRU Downloading Evaluation Module (DEM)


5.2.14.1.1 This module is an off-line module that will be very useful to verify the FFFIS JRU protocol and to check the behaviour of the on board equipment.

5.2.14.1.2 Once the test trip has finished, this module is connected to the JRU of the ETCS/ERTMS On Board equipment and the data recorded is downloaded with this module according to the FFFIS JRU protocol.

5.2.14.1.3 The data downloaded from the JRU will also be used (together with data extracted from the other modules) to check if a test sequence has been correct, and the on board equipment has behaved according to the SRS and the Test Specification.

5.2.14.1.4 The JRU Downloading Evaluation module includes the “Juridical Recorder Download Tool” (Subset-027).


5.2.14.2.1 The interface with the ETCS/ERTMS on board is defined in the JRU Downloading Tool FFFIS (a serial link RS232 compatible with 3-wire interface (full duplex) and the speed is 19200 BPS).

5.2.15 Eurobalise and Euroloop Signal Generator (BSG & LSG)


5.2.15.1.1 This module consists on the different equipments that generate the balise and euroloop telegrams. This hardware is managed by the ETCS Level 1 Trackside Simulator. The train speed will be taken into account when producing the telegrams (both the duration of the message and how the electromagnetic field increases and decreases will be correlated to the speed).


SUBSET-094-0_v2.0.2

.


5.2.15.1.2 To produce the balise messages, a signal generator and perhaps an amplifier would be necessary. Concerning Euroloop Reference Signal Generator, we believe that this architecture based on a similar wave generator and amplifier is quite general to allow the reproduction of real Euroloop Messages.



• Dynamic Phase:

o The messages must be sent from the L1TS to the BSG or LSG through a quick enough channel to ensure a real-time performance.

5.2.15.2.2 Communication with the ERTMS/ETCS on board equipment:

• Dynamic Phase:

o The messages are sent through the airgap to the antenna of the train according to the subset 036 (Eurobalise FFFIS) and 085 (Test Specification for Eurobalise FFFIS). It is possible to use a standard reference loop or a reduced one.


5.2.15.3.1 The hardware proposed consists on an Arbitrary Waveform Generator to generate the modulated message, and an amplifier to set the signal power. The messages will be modulated according to the Eurobalise specification (subset-036 and subset-085), taking into account the current speed in the simulation.

5.2.16 STM Coding and Communication (STMCC)


5.2.16.1.1 This module receives the messages from ETCS Level STM Trackside Simulator, and send them to the profibus where the STMs are connected to the on board equipment (it can also receive messages through the profibus, and send them to the ETCS Level STM Trackside Simulator) (see STM FFFIS subset-035). This module will be generic and will follow the STM Specification. This software is necessary because the messages must go through safety security layers, before being sent using the profibus (see subset-056 Safe Time Layer STM FFFIS, subset -057 Safe Link Layer STM FFFIS and subset -058 Application Layer STM FFFIS).


5.2.16.2.1 Communication with the Level STM Trackside Simulator:


SUBSET-094-0_v2.0.2

.


• Dynamic Phase:

o The messages must be sent and received to and from the LSTMTS through a quick enough channel to fulfil the performance requirements for the simulation.


5.2.16.3.1 This module could run in a computer which would need a communication link to get data from the ETCS Level STM Trackside Simulator, and a profibus board to communicate with the on board equipment profibus.

5.2.17 DMI Event Recorder (DER)

5.2.17.1 Functional description

5.2.17.1.1 The DMI Event Recorder shall record at least all the input/output DMI events defined in the Test Specification (subset-076).


5.2.17.2.1 The DMI Event Recorder shall not disturb the ETCS on board equipment including the DMI itself.

5.2.17.2.2 The DMI Event Recorder could be synchronised with the other modules for time stamping.

5.2.18 Driver or Emulator


5.2.18.1.1 This module will be a human operator or a device in charge of performing the driver actions (replacing the human operator).

5.2.18.1.2 This device shall be out of the ETCS on board equipment.

5.2.19 Trip Analysis & Validation (TAV)


5.2.19.1.1 This is an off line procedure used to check the results of a test sequence using as an input the information that MER and DMI Event Recorder have acquired during the simulation and the files downloaded from the JRU. This procedure will give a result saying if the trip has been correct or not. It will also provide useful information to analyse the trip.


SUBSET-094-0_v2.0.2

.



SUBSET-094-0_v2.0.2

.


6. STATE DIAGRAMS

6.1.1.1.1 In the next diagram, a summary containing the interchange of messages during the configuration phase is shown:

ScenarioController

SpeedSensor

Simulator

TIUSimulator

TrainMotion

Simulator

Level 1TracksideSimulator


Train Data

Track Description

Speed Profile and other parameters

Conf output signal

TIU Messages & conf to send them

Parameters to configure com link

Distances to send the triggers

Parameters to configure com link

Messages + Constraints

Level STMTracksideSimulator

STM Messages

Release Condition

6.1.1.1.2 In the next figure, a similar diagram is shown, but this one contains the schema for the dynamic phase:


SUBSET-094-0_v2.0.2

.


ScenarioController

SpeedSensor

Simulator TIUSimulator

TrainMotion

Simulator



Train accelaration & speed

Failues within TMSTravelled Distance

If a failure is detected

When it send triggers

to the BSG and LSG

When it sends or receives messages

When it doesn’t send a message due

to a constraint not fulfilled

Travelled Distance

Train Speed

Travelled Distance

Train Speed

Travelled Distance

Interventions

Failure Detected

Interventions Info

Level STMTracksideSimulator

When it sends or receives messages

When it doesn’t send a message due

to a constraint not fulfilled

Travelled Distance


SUBSET-094-0_v2.0.2

.


7. SYSTEM INTEGRITY AND VALIDATION

7.1.1.1.1 The implementations of a test facility will be used to test an ETCS on board equipment which shall be SIL 4, although it can include components with a lower SIL.

7.1.1.1.1.1 Note: The recommendations of Cenelec 50126, 50128 and 50129 for V&V activities, regarding quality of software, competence of staff and the independence of the staff from the ETCS design process should be complied with.

7.1.1.1.2 An implementation of a test facility shall demonstrate how it is intended to meet the integrity requirements. It is the responsibility of the Test facility to demonstrate how the system is going to be designed and maintained to ensure its suitability to test SIL4 equipment. The test facilities shall be developed according to SIL 0 quality standards.

7.1.1.1.3 An implementation of a test facility shall prove the compliance with the SRS.

7.1.1.1.3.1 Note: If the evidence of integrity and SRS compliance is not created, it would be unlikely that the Notified Bodies would rely on the test facility for conformity assessments.

7.1.1.1.4 An implementation of a test facility shall have its own procedures to calibrate the test facility before and after the testing of a supplier equipment.


SUBSET-094-0_v2.0.2

.


8. CONFIGURATION VERSION AND REFERENCES

8.1.1.1.1 As the ETCS specification is can evolve in time, it is necessary to define versions of the architecture. Each of these versions will be compliant with different versions of the set of documents related to the architecture: The System Requirement Specification (SRS) which is indeed the tested object; and set of documents which are references for this architecture and must be taken into account (specification of interfaces and of subsystems). These versions are showed in the next chart:

Architecture Version Document Version

SUBSET-026

System Requirement Specification 2.3.0

SUBSET-108

Interoperability-related consolidation on TSI annex A documents

1.2.0

SUBSET-027

JRU Downloading Tool FFFIS 2.2.9

SUBSET-034

TIU FIS 2.0.0

SUBSET-035

STM FFFIS 2.1.1

SUBSET-036

Eurobalise FFFIS 2.4.1

SUBSET-037

EuroRadio FIS 2.3.0

SUBSET-044

FFFIS for Euroloop sub-system 2.2.0

A11 T6001

(MORANE) Radio transmission FFFIS for EuroRadio

12

2.0.2

SUBSET-056

Safe Time Layer STM FFFIS 2.2.0


SUBSET-094-0_v2.0.2

.


SUBSET-057

Safe Link Layer STM FFFIS 2.2.0

SUBSET-058

Application Layer STM FFFIS 2.1.1

SUBSET-085

Test Specification for Eurobalise FFIS 2.2.2


SUBSET-094-0_v2.0.2

.


9. ABBREVIATIONS

• AT: Attention: this two-character abbreviation is always used to start a command line to be sent from TE (terminal equipment) to TA (terminal adaptor)

• BSG: EuroBalise Signal Generator

• BTM: Balise Transmission Module

• DER: DMI Event Recorder

• DEM: Download Evaluation Module

• DMI: Driver Machine Interface

• ETCS: European Train Control System

• ERTMS: European Rail Traffic Management System

• EVC: European Vital Computer

• FFFIS: Form Fit Functional Interface Specification

• FIS: Functional Interface Specification

• ISDN: Integrated Services Digital Network

• JRU: Juridical Recorder Unit

• LSG: EuroLoop Signal Generator

• LSTMTS: ETCS Level STM Trackside Simulator

• L1TS: ETCS Level 1 Trackside Simulator

• L2TS: ETCS Level 2 Trackside Simulator

• ODO: Odometry

• RBC: Radio Block Center

• RCS: EuroRadio Communication Simulator

• SC: Scenario Controller

• SG: Scenario Generator

• SSS: Speed Sensor Simulator

• STM: Specific Transmission Module

• STMCC: STM Coding & Communication

• TAV: Trip Analysis & Validation

• MER: Module Event Recorder

• TIU: Train Interface Unit

• TIUS: Train Interface Unit Simulator

• TMS: Train Motion Simulator

• TTL: Transistor-Transistor Logic


SUBSET-094-0_v2.0.2

.


10. APPENDIX

10.1 TTL Signals

These are the values for 0 and 1 of the TTL family:

• 0: From 0.0 to 0.8 V

• 1: From 2.0 to 5.0 V

functional requirements for an on board reference test ...€¦ · functional requirements for an...

Documents