5 A Virtual Laboratory as an Assessment Tool for Wireless Technologies in Railway Systems – Networking Simulation for Intelligent Transportation Systems

5
A Virtual Laboratory as an Assessment Tool for Wireless Technologies in Railway Systems

The European Rail Traffic Management System (ERTMS) is now an international reference standard for railway signaling. Its deployment in Europe will be long and expensive; thus, the industry needs faster rollout and a reduction in cost in order to obtain the certification and authorization to put equipment into service. Most of the proposed lab-testing tools for ERTMS evaluation have focused mainly on its functional subsystem, the European Train Control System (ETCS). The related test scenarios and simulators have been developed while assuming an ideal telecommunication subsystem. On the contrary, wireless technologies suitable for supporting communications in railway systems have been evaluated only on the basis of the key performance indicators expected for ERTMS signaling applications. Most of the evaluations in the literature have considered only the performance evaluation of the wireless technology itself, using a network simulator, and without taking into account effective train traffic scenarios and the related ETCS feedback. This chapter presents a virtual laboratory based on co-simulation and relying on two existing tools: an ERTMS simulator implementing the functional subsystem (ETCS) and an OPNET simulator that allows us to model the whole telecommunication subsystem, namely the GSM-R (Global System for Mobile Communications – Railways). First, the virtual laboratory architecture and the assumptions on which it has been built are presented. Then, this chapter describes how offline and live co-simulation between the aforementioned simulators can be performed. Thus, the impairments of any prospective wireless technology can be taken into account during the simulation-based evaluation of ERTMS traffic scenarios before costly real-world testings. Finally, the virtual laboratory serves as a case study in the analysis of the co-simulation approach, particularly when the simulators are not of the same type. Prospective work targeting an evolution from co-simulation to multi-modeling, in order to directly connect the models and avoid the problems related to heterogeneity of simulators, concludes the chapter.

5.1. Introduction

The International Union of Railway (UIC) introduced the European Rail Traffic Management System (ERTMS – visit www.ertms.net) in order to harmonize the different train control systems in use in Europe. Following the goal of opening the market of customers and goods transportation inside the European Union (UE), this harmonization also needed to be accompanied by an optimized utilization of the tracks through dynamic train control. In order to achieve this objective, the ERTMS needed both safer train driving supervision processes and a continuous train-to-track/track-to-train communication system able to operate at high-speed levels. These two functions are mainly ensured by the two major components of the ERTMS: (1) the telecommunication subsystem, GSM-R (Global System for Mobile Communication – Railway), which ensures wireless communications between the train and the control location and (2) the functional subsystem identified as the European Train Control System (ETCS), which ensures control of the train and its signaling with the control location via the GSM-R infrastructure [RUE 08].

As a set of control–command processes, the ETCS applications are prone to evaluation approaches that only need to prove their correctness, such as formal methods. The Union Industry of Signaling (UNISIG), the consortium in charge of the development of ERTMS/ETCS technical specifications, has produced the subset 026 [UNI 10] that fixes the compliancy requirements for any test bed dedicated to ERTMS evaluation. Some ERTMS simulators are presented in [MER 07], and the one used in this work is compliant with the subset 026. However, although the functional behavior of the components communicating through the GSM-R infrastructure, such as the Radio Block Center (RBC), is modeled in these simulators, the underlying telecommunication technology itself is not modeled. As a result, GSM-R communications are supposed to be ideal and their related failures due to the impairments of wireless communications, to mention a few, cannot be taken into account during the evaluations performed with these simulators.

On the contrary, it should be noted that GSM was almost the most widely deployed wireless mobile technology in Europe when the telecommunication subsystem for the ERTMS needed to be specified. Thus, the main question was not “which mobile technology for the ERTMS?”, but almost “can GSM do the job?”. It took several years of real-world testing to demonstrate that the GSM-R satisfies the Quality-of-Service (QoS) requirements imposed by ERTMS/ETCS applications at the telecommunication subsystem interface. Nowadays, GSM is a declining technology, and several technologies widely deployed over the world could be potential solutions to replace it in the ERTMS. Moreover, nowadays nobody can imagine performing several years of real-world testing for each one of these prospective solutions. In this context, the use of virtual laboratory could evaluate them by simulation and determine how they meet the QoS requirements of current ERTMS/ETCS applications and which new value services they could introduce while maintaining or even improving safety and security.

The literature contains some attempts at modeling ERTMS/ETCS applications directly inside network simulators such as OPNET in order to include the model of the telecommunication subsystem technology during the evaluations [RUE 08, LOP 14]. However, these evaluations are very limited because of the difficulty of modeling every ETCS application while also including all the ERTMS components and all the factors that may affect an ERTMS traffic scenario. For these reasons, this work proposes a co-simulation approach, where an ERTMS simulator can be connected to a network simulator that models the telecommunication subsystem. In this way, the resulting virtual laboratory can rely on an ERTMS evaluation tool compliant with the subset 026, while taking into account realistic behavior of the telecommunication subsystem.

The presentation of this chapter is organized as follows. Section 5.2 presents the main features of both the functional and the telecommunication subsystems of the ERTMS and some work related to their evaluation by simulation. The co-simulation approach developed in this work, the resulting virtual laboratory architecture and implementation are presented in section 5.3. A case study of an ERTMS scenario evaluated using this virtual laboratory is presented in section 5.4, completed by a discussion on the advantages and drawbacks of the co-simulation approach itself. This chapter is concluded in section 5.5, where prospective works are also announced.

5.2. ERTMS subsystems and related test beds

The different components of an ERTMS deployment are described in [MID 08], the main two being the functional subsystem and the telecommunication subsystem.

5.2.1. The functional subsystem of the ERTMS

This first component is the European Train Control System (ETCS), which is dedicated to train signaling and control. It is designed in order to fulfill the following three main objectives [LEV 08]:

  • – Improved safety by train driving supervision: during its movement, the train receives information about running limitations (speed, distance, etc.) in the form of a Movement Authority (MA) that defines a place on the track (End of Authority – EO As A), which it must not pass. On the basis of both the track and train data, the on board equipment calculates a set of braking curves for train movement supervision;
  • – Higher performance by increasing speed and capacity: provided the movement information directly through displays, the driver can drive safely following the speed information directly through displays, the driver can drive safely following the speed
  • – Interoperability: in contrast to trackside signaling systems based on colors depending on national rules, ETCS is an appropriate train control system for lines belonging to different railway administrations.

Figure 5.1. ETCS operational levels (image from [LEV 08])

To achieve these goals progressively on the different railroads, ETCS specifications define different ETCS implementation levels for lines in relation with trackside equipment (Figure 5.1). In ETCS level 2, a train equipped with ETCS operates on a line controlled by a Radio Block Center (RBC) and is equipped with Eurobalises and GSM-R. The train is permanently connected to the RBC using GSM-R infrastructure. In this way, the control center can update the information about train movements in real time and supervise them more dynamically. Current ERTMS deployments involving GSM-R concern this ETCS level.

Several research works targeting ETCS level 3 are still in progress, especially concerning the use of a satellite-based localization system in railway transport [BEU 12]. Thus, all references to ETCS in this chapter implicitly concern level 2.

Figure 5.2. ERTMS simulator architecture (image from ERSA France)

The ETCS applications play a key role in the safety and efficient supervision of railway traffic. For this reason, their conception and evolution follow a stringent validation process. In such a process, test beds are particularly useful in order to perform fast and low-cost preliminary evaluations. Almost all existing ERTMS simulators are designed in order to only evaluate the functional behavior of the system. It is possible to verify, in normal functioning conditions, if a control–command procedure makes the train behave as expected in the specifications. The proposed ERTMS simulators are validated on the basis of the fact that they allow all the tests required in the subset 026 to be performed [UNI 10]. The ERTMS simulator used in this work has been implemented following the subset 026 specifications, and the resulting simulation platform is compliant to the requirements for ERTMS test beds. It consists of three main components and several additional offline tools for scenario design and analysis distributed over computers connected through a wired network. The platform architecture is described in Figure 5.2, where:

  • – a train driving simulator equipped with a Driver Machine Interface (DMI) compliant to CENELEC specifications is attached to the first component. A human operator can virtually drive the train on a single ERTMS track. The data of the scenario are stored for post-simulation analysis;
  • – the second component is a three-dimensional environment available on a single track. When used with the first component, it reproduces a virtual realistic environment for the driver, who can also rely on the visual signals included in the scenario;
  • – the third component consists of several modules: a route manager, an interlocking management system, including up to two RBCs, up to 11 trains moving simultaneously, and also the driving simulator. This component is both the control center of the railway traffic and the trains’ manager in manual or automatic mode. When used with the other components, it allows the human operator on the driving simulator to interact with traffic, including several other simulated trains.

Although such ERTMS simulators usually include a GSM-R interface, the functioning of the telecommunication subsystem is idealized. Therefore, it is not possible to evaluate the values of telecommunication-related metrics such as end-to-end delay, loss rate, network load, throughput and retransmission count per message. Moreover, the impact of a dysfunction in the telecommunication subsystem on the behavior of the whole system cannot be simulated with these tools.

5.2.2. The telecommunication subsystem of the ERTMS

The telecommunication subsystem is actually the second major component of the ERTMS. The main part of the ERTMS level 2 is currently implemented using the GSM-R (Figure 5.3). This technology is based on the classical GSM architecture, but it uses specific frequency bands dedicated to railway communications. In France, frequency bands from 876 to 880 MHz are used for uplink transmission (Mobile Station – MS – to Base Transceiver Station – BTS), and those from 921 to 925 MHz are used for downlink transmission (BTS to MS). There are 20 channels of 200 kHz each uplink and the same amount for downlink to allocate to the different BTSs, which are placed every 3–4 km along the railway in order to ensure high redundancy and to support high speeds up to 500 km/h.

Figure 5.3. GSM-R infrastructure with redund ant BTS (image from Siemens)

The telecommunication subsystem plays a key role in the ERTMS as it ensures communications between the control center and the train for the traffic related to both the signaling and the applications. For these reasons, stringent requirements have been specified for the telecommunication technologies candidate that could be adopted in ERTMS. GSM technology met these QoS requirements, and the tests carried out by the European Railway Agency (ERA) confirmed its accuracy as a telecommunication technology for the ERTMS. GSM technology also has two other major advantages as a solution for interconnecting railway networks of the different European countries:

  • – GSM was widely deployed by mobile telephony operators in Europe, and for this reason, both the equipment and maintenane costs were relatively lower than those of other technologies;
  • – in addition to ETCS signaling, GSM was used by almost all European railroad operators for their professional mobile communications. In this way, the same technology served to interconnect both the ERTMS infrastructures and the operators’ professional networks of the different countries.

Since the adoption of GSM-R, many developments have occurred in transportation. Indeed, the development of Intelligent Transport Systems (ITS) has brought new applications for the safety and monitoring of transport systems and also new services for customers and user-friendly applications. Evolution of railway transportation systems in order to provide some of these new services will be mandatory for its competitiveness; however, it will a also imply new QoS constraints and consequently increase the traffic supported by the communication network. In this context, the GSM-R may still not be the appropriate technology [SON 12]. Several researchers proposed investigating other telecommunication technologies for the ERTMS, such as GPRS [RUE 08], WIMAX [AGU 07] and, recently, LTE [SNI 14]. Analytical and simulation-based evaluations on these telecommunication technologies are proposed in the literature regarding various telecommunication-specific metrics.

The authors of the aforementioned work used the Riverbed OPNET modeler, which is one of the most popular simulators for the evaluation of network technologies. However, their experiments concerned only the behavior of the telecommunication subsystem and were disconnected from the functional part of the ERTMS. The ETCS applications evaluated are modeled approximately in terms of the messages that they generate during the simulation scenarios; however, the behavior of the functional component of ERTMS is not actually modeled in these scenarios. Consequently, it is possible to evaluate the value of the telecommunication-specific metrics for some particular messages exchanged during the scenario, whereas it is not possible to actually observe the behavior of ETCS applications in a specific ERTMS scenario when a dysfunction occurs in the simulation of telecommunication technology.

These observations emphasize the need for an evaluation tool for the ERTMS in which both the functional and telecommunication subsystems can be simulated and in which the impact of the behavior of one component on the functioning of the other component can be studied accurately. It is the purpose of the work presented in this chapter, where OPNET is also used as a telecommunication simulator.

5.3. A virtual laboratory based on co-simulation for ERTMS evaluation

This section presents the co-simulation approach developed in the ANR Project VEGAS (Virtual lab based on co-simulation to include impairments of wireless tElecommunication such as GSM-R in the evAluation of ERTMS components) that supported this work and the resulting virtual laboratory software tool.

5.3.1. Why a co-simulation approach?

As mentioned in section 5.2, current ERTMS simulators are mostly designed to evaluate the functional behavior of the system, and they have been validated for this purpose. However, they do not actually implement the telecommunication subsystem and do not allow for evaluation of either the behavior of the entire system regarding telecommunication metrics or the scenarios where dysfunctions occur in the telecommunication subsystem. Integrating a model of the telecommunication subsystem inside the current ERTMS simulators would require a complete development, from scratch, of all the components of the GSM-R architecture and from the physical to the network and transport layers. Moreover, it would be necessary to develop the models for all other prospective telecommunication technologies and maintain the evolution of the related protocols and equipment in the designed models. Such work would be equivalent to that of designing a complete network simulator from scratch, and it should be avoided as efficient and validated tools, such as OPNET, already propose powerful features for advanced simulation of network and telecommunication technologies.

We also noted that the functional subsystem of ERMTS is made of various ETCS applications. Implementing all the features of these applications in a network simulator would result in an inefficient modeling of the complete ERTMS functional subsystem again, as it is already done in current validated ERTMS simulators. Moreover, keeping this validation for the resulting platform would not be straightforward.

To avoid such complicated and unpredictable work, we propose a new approach based on co-simulation that will connect an ERTMS simulator with a simulator especially designed for network and telecommunication technologies, namely the OPNET simulator, in order to design a simulation tool dedicated to the joint evaluation of the functional and telecommunication components of ERTMS.

5.3.2. Which data and processes must be modeled in each simulator?

In any ERTMS level 2 scenario, each train moves on a specific track as described in Figure 5.1. On its movement through GSM-R, the train sends various information to the control center via the RBC and receives specific instructions (MA) in the same way. Therefore, under the assumption that all the communications occurring in the scenario between the train and the RBC meet the requirements imposed by ERTMS at the GSM-R interface, the behavior of the functional subsystem can be accurately evaluated using the ERTMS simulator.

Following the same reasoning, let us consider a scenario simulated on the ERTMS simulator, where the movement (successive positions, instant velocities and accelerations, etc.) of the train over a certain time as well as all the sequence of the messages exchanged in that time with the RBC during this movement are completely stored. Under the assumption that we are able to precisely reproduce the same movement in OPNET and the same sequence of messages following the same chronology, it is possible to precisely obtain the value of the end-to-end delay for each message exchanged. Other telecommunication-related metrics can be studied in the same way.

Figure 5.4. Co-simulation architecture and concepts. For a color version of this figure, see www.iste.co.uk/hilt/transportation.zip

Following these ideas, the co-simulation platform architecture can be described as in Figure 5.4(a). The functional subsystem is simulated using the ERTMS simulator, and the telecommunication subsystem is simulated using OPNET. The key elements that synchronize both simulators are the movement of the train and the messages exchanged with the control center during this movement.

Therefore, the same ERTMS scenario can be partially modeled inside the different simulators in order to evaluate the related components. To ensure the coherency of each one of the partial scenarios modeled inside each simulator with the ERTMS scenario, the following concepts are introduced [SON 12]:

  • – The Track: this concept represents the physical and static elements that materialize the railroad, the network infrastructure, the localization and signaling systems component;
  • – The Trajectory: this refers to the movement of one train during a specific scenario. In this way, the movement of any train during an ERTMS scenario can be reproduced faithfully inside any of the simulators;
  • – The Transmissions: these refer to the set of messages exchanged between each train and the control center during a scenario, ordered by the date of emission;
  • – The Metrics: these refer to the indicators that are evaluated during a scenario. In an ERTMS functional simulator, we can mainly evaluate the conformity of the train behavior with the ERTMS safety specifications. In a telecommunication simulator, we can evaluate metrics such as end-to-end delays, loss rate and handover duration.

When generating the partial view of an ERTMS scenario for a specific simulator, a specific view must be generated for each one of these four concepts (Figure 5.4(b)). The related view to generate would contain more or less details, according to the component evaluated by one specific simulator and the related metrics considered.

5.3.3. Overall architecture of the ERTMS–OPNET virtual laboratory

The virtual laboratory is realized through a software infrastructure that connects the ERTMS simulator and OPNET. It is composed of the following three major components (Figure 5.5):

  • – The ERTMS co-simulation interface: this proposes a set of remote procedures that can be invoked in order to obtain either trajectory information about the trains or the messages emitted by both the trains and the RBCs involved in a scenario. These interfaces are proposed as CORBA interfaces: the RMCPlugin (over the Route MaP Controller) for trajectory information and the RNSPlugin (over the Radio Network Simulator) for the messages;
  • – The ESYS interface: each node model in OPNET (train or RBC) contains an ESYS process, which exposes an interface able to exchange data with an external program. In this way, each train model in OPNET can be notified of any change in the position of the corresponding train in the ERTMS simulator so that it can update itself. Also, any message sent by a train or RBC in the ERTMS simulator is written at the interface of the corresponding train or RBC model in OPNET so that this latter performs the emission of the message in the OPNET as well;
  • – The co-simulation manager: it is composed of two independent components that share some data, namely the movement manager and the message manager. The first connects to the RMCPlugin and obtains information about the scenario, the track, the trains and the RBCs. Periodically, it requests current train position in the ERTMS simulator to the RMCPlugin and sets them on the ESYS interface of the corresponding train in OPNET. Also, the message manager is notified by the RNSPlugin of each emitted message in the ERTMS simulator so that it can notify the OPNET model of the corresponding emitter through its ESYS interface. When a node model in OPNET receives an ETCS message, it sends feedback to the message manager through a callback function registered on its ESYS interface so that the latter can notify the RNSPlugin.

Figure 5.5 ERTMS–OPNET virtual laboratory architecture

5.3.4. Synchronization modes

In order to perform a co-simulation, both the ERTMS simulator and OPNET can be connected live for an online simulation or offline by replaying a scenario previously run in one simulator in the other.

Online simulation presents the advantage of running both functional and telecommunication subsystems simultaneously, thus allowing a more realistic evaluation of the entire ERTMS scenario. In this mode, the model of the telecommunication subsystem implemented in OPNET interacts with the Radio Network Simulator and the Route Map Conntroller of the ERTMS simulator (Figure 5.5). The trajectory information of the train is transmitted live to OPNET so that the train follows the same movement in both simulators. The messages generated, for example, by a train in the ERTMS simulator go without delay through the OPNET train model, where they are sent to the OPNET RBC model through the GSM-R infrastructure modeled in OPNET under realistic conditions of mobility, propagation and network transmissions. They are then routed without delay from the OPNET RBC model to the RBC simulator in the ERTMS simulator for functional processing. The complete process followed by one message and the related response during co-simulation are illustrated in Figure 5.6.

Figure 5.6. Process of a message and its related response during online co-simulation

For any scenario run with the ERTMS simulator, the information about the track, trajectory, transmissions and metrics is backed up as chronologic events by the simulation manager. In this way, it is possible to check that the scenario is valid from a functional viewpoint. This scenario is then replayed offline in OPNET in order to evaluate the behavior of the telecommunication subsystem under realistic functional constraints. Typically, there is no difference between online and offline simulation at the OPNET interface. As a result, it is also possible to use real-world traces of the trains running on ERTMS level 2 lines in order to build offline co-simulation scenarios, provided that these traces are formatted like the data backed up by the co-simulation manager during online co-simulation [SON 13].

5.3.5. Virtual laboratory implementations in the ERTMS simulator

The implementation of the virtual laboratory in the ERTMS simulator is achieved through two interfaces: the RMCPlugin and the RNSPlugin.

The RMCPlugin implements remote procedures that allow any client to post updated information periodically or on-demand (Figure 5.7) on the movement of the trains in a scenario. The movement manager module of the co-simulation manager registers to the RMCPlugin server, and it sets the periodicity for receiving push messages about train position updates.

Figure 5.7. Movement information provided by the RMCPlugin of ERTMS simulator

The RNSPlugin implements remote procedures that allow any client to register in order to receive a copy of any message emitted by a train or RBC in the ERTMS simulator. It is also able to receive a notification from the message manager of the co-simulation manager about the acceptance or the rejection of a message after its transmision has been simulated with OPNET. The functioning of the RNSPlugin server operating at the ERTMS co-simulation interface is summarized in the chart presented in Figure 5.8

Figure 5.8. Functioning of the RNSPlugin server at ERT MS co-simulation interface

5.3.6. Virtual laboratory implementations in OPNET

In a classical GSM infrastructure, many components are involved in order to ensure efficient management of the network and provide the best services to the subscribers. However, a GSM-R infrastructure is dedicated only to ERTMS subscribers. However, a GSM-R infrastructure is dedicated only to ERTMS operations, and in this project, the focus is on the wireless impairments. As a result, the core network from the Base Transceiver Stations (BTSs) can be simplified as all the compnents are connected through a wired infrastructure.

Figure 5.9 . GSM-R infra structure in O PNET for co-simulation

The GSM-R infrastructure modeled in the virtual laboratory includes the following components (Figure 5.9):

  • – the mobile nodes that model the trains;
  • – the Base Transceiver Stations that are placed along the railroad in order to provide wireless coverage to the trains running on ERTMS level 2 lines. Following GSM-R deployments, they are placed every 4 or 7 km depending on the railroad configuration;
  • – the Radio Block Centers that represent the control locations.

The train model is derived from an advanced wireless node model in OPNET. As a result, it contains all the components, making a refined modeling of all the protocols from the application to the physical layer possible. The train model in OPNET does not generate traffic directly. The messages are produced by ETCS applications in the ERTMS simulator, and the packets are routed to OPNET via the ESYS interface by the co-simulation manager. This implies the following:

  • – the ETCS applications do not need to be modeled in OPNET. Only the message that they generate in the train’s on-board equipment is routed through OPNET in order to simulate the related packets through the wireless interface to the core network. The main advantage is that of preventing the very long development of only approximated models of the actual ETCS application with relatively poor gain in terms of ERTMS analysis. Another advantage is that any new ETCS application introduced in the ERTMS simulator will be able to be simulated immediately through this co-simulation architectuure without any change to the train model;
  • – the messages coming from the ERTMS simulator include connection requests and releses. Furthermore, they are already managed by the EURORADIO layer modeled in the ERTMS simulator. As a result, there is no need to model this layer in OPNET. The ETCS messages are already encrypted, and any request related to a OPNET. The ETCS messages are already encrypted, and any request related to a message not routed by OPNET due to wireless impairment will not have any effect. As a result, the connetion or disconnection or data transmission processes and their implications are still managed by the ETCS application implemented in the ERTMS simulator, and only the consequences due to a wireless impairment are actually managed in OPNET.

Figure 5.10. Train model and its ESYS interfaces (cosim_intf) in OPNET. For a color version of this figure, see www.iste.co.uk/hilt/transportation.zip

The BTS model is derived from the OPNET native model of a bridge node with two intefaces: a TDMA interface and an Ethernet interface. The TDMA interface manages wireless communications with the trains evolving in the location covered by the BTS, and the Ethernet interface connects each BTS to a central switch at the control location. In the global architecture, the group of BTS that depends on the same RBC is connected to the switch connected with this RBC.

The model of the RBC is almost the same as that of the train, except that there is no TDMA interface but an Ethernet interface instead. It can be noted that the same ESYS model is used for both the train and the RBC, following the generic approach developed in the VEGAS project.

5.3.7. Virtual laboratory implementations in the co-simulation manager

The co-simulation manager main window presents the main information about the scenario and the track as well as the state of its different components (Figure 5.11), namely:

  • – Train Manager: its state (running, stopped or not working) and position update periodicity;
  • – Message Manager: its state and the simulation time in ERTMS simulator;
  • – OPNET interface: its state and the current simulation time in OPNET.

Figure 5.11. Co-simulation manager main window

During co-simulation, it is possible to monitor the train positions through the Visualize menu. Also, through another submenu of the Visualize menu, it is possible to monitor the messages sent or received by the different trains and RBC (Figure 5.12).

Figure 5.12. Message view in visualize menu of the co-simulation manager

5.4. Effective use of the ERTMS–OPNET virtual laboratory

5.4.1. A co-simulation scenario with the ERTMS–OPNET virtual laboratory

This section presents the co-simulation process applied to a scenario and the related main steps. While simulation is running, both the OPNET interface in the co-simulation manager and the OPNET simulator print debug traces in a terminal or a file. These traces include the following:

  • – OPNET model of the network scenario invoked in the co-simulation (Figure 5.13);
  • – ESA initializations, including the ESYS interfaces of predefined trains and RBC (Figure 5.13);
  • – indexes of the available interfaces for assignment to ERTMS simulator trains and RBCs; in this way, it is possible to perform the assignments automatically (Figure 5.13);
  • – the time in each simulator and the difference of time between them; in this way, it is always possible to know if the co-simulation can continue online or if it should go offline when synchronization conditions cannot be met anymore (Figure 5.13);
  • – co-simulation events: for example, when the OPNET interface receives train information from the co-simulation manager for Train with ETCSID 1 (Figure 5.14);
  • – interfaces assignment: for example, Train 1 is associated with ESYS interface 0 (Figure 5.14);
  • – OPNET traces always start with this label, for example, when nodes are initialized (Figure 5.14);
  • – replacement of default positions of nodes in OPNET by their initial positions in ERTMS simulator when trajectory information is received, and association between ETCSID of the train or RBC and their MAC address in OPNET (Figure 5.15);
  • – update of train position in OPNET upon receipt of new positions of the corresponding train in the ERTMS simulator through trajectory data (Figure 5.16). It can be noted that when no message is exchanged, the time difference between the simulators can be higher without causing synchronization problems (e.g. up to 0.5 s in Figure 5.16);
  • – message transmission: for example, Figure 5.17 shows that the message of ID 1 sent by Train with ETCSID 1, which is associated with Mobile_1_1 in OPNET, is sent to its current controller (Controller_1). The latter then sends it to the switch node_0, which transmits it to RBC1;
  • – when the message reaches the destination in OPNET (namely RBC1), RBC1 updates routing table information and sends a notification to the co-simulation manager to indicate whether or not the messsage should be routed in ERTMS simulator (Figure 5.18);
  • – some metrics values are available immediately during co-simulation (Figure 5.19); however, the detailed telecommunication metrics, such as end-to-end delays, loss rates, throughput, network load and others, are available, as for the classical OPNET scenarios in the OPNET graphical user interface, at the end of the co-simulation.

Figure 5.13. OPNET initialization traces

Figure 5.14 Interfaces assignment

Figure 5.15. Train information and initial positions setting

Figure 5.16. Position updates

Figure 5.17. Message transfer from ERTMS simulator to OPNET for telecommunication transmission simulation

Figure 5.18. Message whose transmission was simulated by OPNET receives an acceptance notification for routing in ERTMS simulator

Figure 5.19. Metrics are updated along with message updates for each node

5.4.2. Efficiency of the co-simulation approach in the evaluation of railway systems

The co-simulation approach developed in the VEGAS project and presented in this chapter achieves its main goal by introducing an accurate simulation of the telecommunication subsystem in the loop of any evaluation of the ETCS applications using an ERTMS simulator. Moreover, by concentrating all the co-applications using an ERTMS simulator. Moreover, by concentrating all the model in OPNET, the co-simulation approach developed in this work can be quickly adapted in order to evaluate any other wireless technology than the GSM-R without any change in its other components (the ERTMS simulator interface and the co-simulation manager). For example, the co-simulation ESYS process can simply be added to LTE mobile equipment to obtain a train model equipped with LTE technology instead of GSM-R. The only other node that would need to be upgraded in the overall LTE infrastructure would be the one playing the role of the RBC.

Figure 5.20 Getting LTE (Long-Term Evolution) node models ready for co-simulation. For a color version of this figure, see www.iste.co.uk/hilt/transportation.zip

Thus, the main advantages of the co-simulation approach developed in this work regarding railway systems evaluation, especially the ERTMS l level 2, are:

  • – the possibility of reusing existing railway system simulators. The railway domain is subject to many rules and constraints of different types, and it involves very complicated processes that make any software development dedicated to its evaluation or exploitation a big challenge. In this context, reusing the software tools that have been already developed, tested and eventually certified is always a gain. The co-simulation approach presented in this work uses an existing professional ERTMS simulator without introducing any modification in its core functioning, by increasing its ability to interact with external tools;
  • – the possibility of using an improved network simulator in order to efficiently model the current telecommunication subsystem of the ERTMS and other prospective technologies that could be used in the future. As explained earlier, any operation involving the GSM-R is sent to OPNET by the co-simulation manager, which also takes into account the environment of the tracks, the network infrastructure and the movement of the trains in order to perform an accurate simulation of that operation. In this way, the feedback sent to the ERTMS simulator reflects the impact of the wireless communication in the context of the simulated ERTMS scenario. Moreover, the GSM-R infrastructure can be easily replaced by any other technology, where evaluation is needed on the same scenario, notably when evaluating potential prospective technologies such as LTE;
  • – the possibility of using real-world traces of the train on ERTMS level 2 lines in order to build accurate evaluation scenarios for studying the telecommunication subsystem behavior. The co-simulation manager is able to reproduce any set of chronologic events containing the movement and message information concerning an ERTMS scenario at the OPNET interface, and it operates a co-simulation without feedback to the ERTMS simulator. In this way, real-world traces of trains on ERTMS level 2 lines, such as those presented in [SON 13], can be used in offline co-simulation in order to study the behavior of the telecommunication subsystem.

However, the co-simulation approach may present some drawbacks in the development of accurate evaluation tools for railway systems, such as:

  • – the weak interaction possibilities due to custom simulation tools. Most of the simulation tools for railway systems are developed in the context of industrial projects that are submitted to various constraints that make them very specific. As a result, they may present some particularities such as: they are able to simulate only some modules and not the complete system; they cannot interact with other tools; they are under industrial protection and cannot be shared; and they are not event-based and cannot support pause/replay mechanisms. For example, the ERTMS simulator used in this work is not event-based, does not support pause/replay mechanisms and could not receive any feedback from external tools. It took 3 years of development to increase its ability to share some scenario data and to receive message acceptance or rejection data. However, it still does not support pause/replay and cannot operate in a tier-controlled event-based loop. As a result, an online co-simulation always depends on the ERTMS simulator scenario and can be used to evaluate the impact of this scenario on the telecommunication subsystem modeled in OPNET. The inverse situation is not possible, except through feedback on message acceptance or rejection;
  • – the impossibility of guaranteeing the convergence of a complete simulation scenario in online co-simulation mode. Indeed, the ERTMS simulator starts and runs without pausing until the end of the scenario. As a result, the co-simulation manager and OPNET need to operate very fast in order to send feedback before the message becomes obsolete or the default policy fixed in the configuration be applied. The sole solution to this problem is to monitor the time in both simulators and check regularly if the gap is still acceptable regarding the scenario. Once this condition is no longer satisfied, the co-simulation manager sets the default policy of the message to “accept all”, stops the feedbacks to ERTMS simulator and starts an offline co-simulation with OPNET based on the events coming from the ERTMS simulator that it will continue to back up anyhow. This time synchronization problem could be avoided if the ERTMS simulator was event-based as well.

This latter observation suggests that it could be more efficient to couple in virtual laboratory, such as the one built in VEGAS project, not the simulators, but actually the models of the different components of a railway system. Indeed, multi-modeling is a well-known approach for modeling and analysis of complex systems such as railways. Moreover, many tools based on DEVS (Discrete Event System Specification) formalism [ZEI 00] have been developed in order to couple discrete and continuous models in the same virtual laboratory and generate custom simulators reproducing the entire system. The Virtual Laboratory Environment (VLE) [QUE 09], OPNET modeler and VSimRTI, to mention few, are all based on DEVS. In order to evolve from co-simulation to multi-modeling in building evaluation tools for railway systems, at least the following two major opposite facts need to be considered:

  • – before any custom simulation tool is designed for a component of a railway system, a model is realized first. This implies that the models of the components of railway systems are at least as available as the related simulators. Thus, building virtual laboratories on the basis of multi-modeling should be possible every time co-simulation is possible, with the advantage of avoiding the synchronization problems introduced by co-simulation;
  • – however, although some simulators can be made available as binary or emulated inside material devices in order to limit reverse engineering attempts, the models are more prone to intellectual property violation. In the railway domain, where these questions including confidentiality are central, it is obvious that the availability of the models that could contribute to a virtual laboratory based on multi-modeling is not guaranteed. As a result, it should be considered that developing and proposing appropriate solutions that could guarantee coupling of the models in a secure environment that preserves confidentiality and prevents intellectual property violations will be a key point in the development of future evaluation tools for the components of railway systems. Moreover, it will improve the collaboration between concurrent groups that may operate together in the design and implementation of the infrastructures for future railway systems.

5.5. Conclusion

This chapter presented a co-simulation approach developed in order to improve the joint evaluation of both the functional and telecommunication subsystems of the ERTMS by taking into account the impact of their respective behavior on each other. This approach relies on a co-simulation manager, which collects simulation data about the tracks and the movement of the trains from an ERTMS simulator implementing the functional subsystem of the ERTMS and uses them in order to simulate the transmission of the messages in OPNET. In this way, the resulting virtual laboratory has improved the evaluation of the GSM-R, and possibly other wireless technologies, by introducing realistic scenarios of the functioning of the railway system in its simulation in OPNET. Furthermore, it has improved the ERTMS simulators by introducing more realistic behavior of the telecommunication subsystem through feedback sent for any message by the co-simulation manager after it has simulated the transmission of the message through OPNET.

Despite these contributions that improve these evaluation tools, the co-simulation approach may lead to some problems, the two main ones being the limitation of interaction possibilities with custom simulators not designed for the ERTMS simulator and the impossibility of guaranteeing a co-simulation convergence due to time synchronization problems between a non-event-based simulator and event-based simulators, such as OPNET.

Prospective works are in progress to evolve from co-simulation to multi-modeling by directly coupling the models of the components instead of the resulting related simulators in order to avoid the synchronization problems. However, this approach induces new challenges concerning confidentiality which is crucial in the railway domain.

5.6. Bibliography

[AGU 07] AGUADO M., ONANDI O., JACOB E. et al., Wimax Role on CBTC Systems, ASME/IEEE JRCICE 2007, Pueblo, 2007.

[BEU 12] BEUGIN J., MARAIS J., “Simulation-based evaluation of dependability and safety properties of satellite technologies for railway localization”, Transportation Research Part C: Emerging Technologies, vol. 22, pp. 42–57, 2012.

[LEV 08] LEVÊQUE O., DE CICCO P., ETCS Implementation Handbook, Infrastructure Department, UIC, 2008.

[LOP 14] LOPEZ I., AGUADO M., JACOB E., “End-to-end multipath technology: enhancing availability and reliability in next-generation packet-switched train signaling systems”, IEEE Vehicular Technology Magazine, vol. 9, no. 1, pp. 28–35, 2014.

[MER 07] MERA J.M., GOMEZ-REY I., CAMPOS A., “ERTMS/ETCS test simulation bench”, Urban Transport XIII Urban Transport and the Environment in the 21st Century, UK, 2007.

[MID 08] MIDYA S., THOTTAPPILLIL R., “An overview of electromagnetic compatibility challenges in European Rail Traffic Management System”, Transportation Research Part C: Emerging Technologies, vol. 16, no. 5, pp. 515–534, 2008.

[QUE 09] QUESNEL G., DUBOZ R., RAMAT E., “The virtual laboratory environment – an operational framework for multi-modelling, simulation and analysis of complex systems”, Simulation Modelling Practice and Theory, vol. 17, pp. 641–653, April 2009.

[RUE 08] RUESCHE S.F., STEUER J., JOBMANN K., “The European switch – a packet-switched approach to a train control system”, IEEE Vehicular Technology Magazine, vol. 3, no. 3, pp. 37–46, September 2008.

[SNI 14] SNIADY A., SOLER J., “LTE for railways: impact on performance of ETCS railway signaling”, IEEE Vehicular Technology Magazine, vol. 9, no. 2, pp. 69–77, 2014.

[SON 12] SONDI P., KASSAB M., BERBINEAU M. et al., “Toward a common platform for simulation-based evaluation of both functional and telecommunication subsystems of the ERTMS”, American Society of Mechanical Engineers Joint Roll Conference, Philadelphia, pp. 351–359, 2012.

[SON 13] SONDI P., BERBINEAU M., KASSAB M. et al., “Generating test scenarios based on real-world traces for ERTMS telecommunication subsystem evaluation”, International Workshop on Communication Technologies for Vehicles, Springer-Verlag, pp. 223–231, 2013.

[UNI 10] UNISIG, System Requirements Specification, ERTMS Specifications, Subset 026 v2.3.0, ERTMS, 2010.

[ZEI 00] ZEIGLER B.P., KIM D., PRAEHOFER H., Theory of Modeling and Simulation: Integrating Discrete Event and Continuous Complex Dynamic Systems, Academic Press, 2000.

Chapter written by Patrick SONDI, Eric RAMAT and Marion BERBINEAU.