TOWARD A COMMON PLATFORM FOR SIMULATION-BASED EVALUATION OF BOTH FUNCTIONAL AND TELECOMMUNICATION SUB-SYSTEMS OF THE ERTMS

Transcription

1 Proceedings of the 2012 Joint Rail Conference JRC2012 April 17-19, 2012, Philadelphia, Pennsylvania, USA JRC TOWARD A COMMON PLATFORM FOR SIMULATION-BASED EVALUATION OF BOTH FUNCTIONAL AND TELECOMMUNICATION SUB-SYSTEMS OF THE ERTMS Patrick Sondi Univ Lille Nord de France, F-59000, Lille IFSTTAR, LEOST, F Villeneuve d Ascq, FRANCE Mohamed Kassab Univ Lille Nord de France, F-59000, Lille IFSTTAR, LEOST, F Villeneuve d Ascq, FRANCE Marina Aguado University of the Basque Country (UPV/EHU) Bilbao, Spain Etienne Lemaire Univ Lille Nord de France, F-59000, Lille IFSTTAR, ESTAS, F Villeneuve d Ascq, FRANCE Marion Berbineau Univ Lille Nord de France, F-59000, Lille IFSTTAR, LEOST, F Villeneuve d Ascq, FRANCE ABSTRACT The deployment of the European Rail Traffic Management System (ERTMS) in Europe will be mandatory on the major corridors, but this process will be long and expensive. Industry needs faster roll-out and a reduction in cost in order to obtain the certification and authorization to put equipment into service. New lab-testing tools for European Train Control System (ETCS) validation based on automatic testing could accelerate the process. In this work, we propose a co-simulation platform relaying on two existing tools: the ERTMS simulator that implements only the functional sub-system (ETCS) of ERTMS; and the OPNET simulator that allows modeling the whole telecommunication subsystem (GSM-R) from the Physical layer to higher layers, including the Euroradio interface. We describe a co-simulation protocol that determines how the results obtained from each simulator are reused as input in the other in order to take into account the impact of the functioning of one subsystem on the other. In this way, the problems related to radio propagation impairments, network load and electromagnetic interferences can be taken into account in ERTMS evaluation. Furthermore, some actors of the railway industry think about moving towards emerging technologies like LTE (4G Long Term Evolution). This platform will also allow evaluation of prospective technologies in the framework of ERTMS scenarios before costly real-world implementation. INTRODUCTION In order to harmonize the different train control systems in use in Europe and optimize the utilization of tracks by dynamic train control, the International Union of Railway (UIC) introduced the European Rail Traffic Management System (ERTMS). It relies on two major components: the telecommunication subsystem GSM-R (Global System for Mobile Communication - Railway), which ensures wireless communications between the train and the control location; and the functional sub-system 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 [1]. The deployment of ERTMS will be mandatory on the major corridors in case of new installation or an upgrade of the train control and radio communication systems. However, this process will be long and expensive. Meanwhile, both subsystems may be subject to evolutions and the impact of these evolutions must be evaluated prior to their implementation. Thus, there is a need for faster roll-out and reduction in cost for the certification and authorization necessary to put equipment into service. The solution to accelerate the process clearly relies on making use of lab-testing in connection with the validation and evolutions of the European Train Control System (ETCS). The development of tools and methodologies for lab testing with automatic interpretation of test results, automatic data input and automatic running of test sequences should be a priority. An existing ERTMS simulator allows us to perform various tests based on specific scenarios which may include a human operator driving the train in a 3D virtual environment. All major ETCS functionalities have been implemented in this simulator but, in its current version, no impairments on the Air gap can be taken into account for the evaluation. The key idea of our methodology consists in the development of a co- 1 Copyright 2012 by ASME

2 simulation approach based on two existing tools: the aforementioned ERTMS simulator and the OPNET simulator. This latter will allow us to model, with a discrete events technique, the whole telecommunication subsystem, from the Physical layer to the application one, including the Euroradio interface. With such an approach, it will be possible to take into account in ERTMS evaluation all the problems related to radio propagation impairments, network load, electromagnetic interferences and attacks. Furthermore, some actors of the railway transport industry already think about moving towards new emerging wireless technologies such as LTE (4G Long Term Evolution). This platform will allow us to evaluate prospective telecommunication technologies in the framework of ERTMS scenarios before costly implementation. This paper presents a co-simulation protocol that specifies how the results obtained from each simulator are reused as input in the other in order to take into account the impact of the functioning of one subsystem on the other. A complete cosimulation process is described as a set of simulation sessions that exchange data following the proposed protocol. As a proof of concept, we show as preliminary results how a co-simulation Scenario can be implemented in both the current ERTMS simulator and OPNET, including a GSM-R model. and 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 realtime and supervise them more dynamically. Therefore, Eurobalises mainly servers as a reference location. However, the train detection and train integrity supervision are still performed by trackside equipment. ETCS level 3: this level is similar to the previous one, except that the train location and the train integrity supervision are performed by the train, and no longer by trackside equipment. Eurobalises only serve as a reference location. In the future, such information could be obtained from systems such as Galileo. TECHNICAL OVERVIEW The first component of the ERTMS is the European Train Control System (ETCS) dedicated to train signaling and control. It is designed in order to fulfill three objectives [2]: Improved safety by train driving supervision: based on both the track and train data, the onboard equipment calculates a set of braking curves for train movement supervision. In case of dysfunction detection, ETCS prompts the driver to stop the train. Higher performance by increasing speed and capacity: the driver operates safely following the speed limitation without having to look at trackside signals. Dynamic train control allows increasing the utilization of tracks, thus improving capacity. Interoperability: contrary to trackside signaling systems based on colors depending on national rules, ETCS is the appropriate train control system for the lines belonging to different railway administrations. In each country, the coherency between ETCS behavior and local regulations is set in ETCS configuration. ETCS specifications define different ETCS implementation levels for lines in relation to ETCS trackside equipment: ETCS level 1: train equipped with ETCS operating on a line equipped with Eurobalises, and optionally Euroloop or Radio in-fill to exchange messages between the train and the trackside. The train obtains its position and movement data set from the balises and it calculates the braking curves for its movement. ETCS level 2: train equipped with ETCS operating on a line is controlled by a Radio Block Center (RBC) Figure 1 ERTMS operational levels [2] ETCS applications play a key-role in safety and efficient supervision of railway traffic. For this reason, their conception and evolution must follow a stringent validation process as in the case of critical applications. In such process, testbeds are particularly useful in order to perform fast and low-cost preliminary evaluations. Some ERTMS simulators are described in [3], [4] and [5], to mention a few. The ERTMS simulator used in this work [6] has been implemented following the subset 026 specifications [7], and the resulting simulation platform is compliant to SRS 2.3.0d requirements for ERTMS testbeds. 2 Copyright 2012 by ASME

3 However, these platforms are designed in order to evaluate the functional component of ERTMS. Though a GSM-R interface is present, its functioning is ideal and not actually modeled. Thus, the impact of its behavior on the whole system in the case of network dysfunction cannot be evaluated accurately. The second component of the ERTMS is the telecommunication subsystem. Its main part which is specific to ERTMS is the GSM-R. 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 MHz to 880 MHz are used for uplink transmission (Mobile Station MS to Base Transceiver Station BTS) and those from 921 MHz to 925 MHz for downlink transmission (BTS to MS). There are 20 channels of 200 KHz each uplink and the same amount downlink to allocate to the different BTS which are placed every 3 to 4 kilometers along the railway in order to ensure high redundancy and to support high speeds up to 500 km/h. If we analyze the reasons that led to the choice of GSM-R, we can notice that: GSM key performance indicators met the QoS requirements of all ETCS applications and the tests carried out by the European Railway Agency (ERA) confirmed its accuracy [3]. Since that time, many evolutions have occurred in transportation. Indeed, the development Intelligent Transport Systems (ITS) have brought new applications for safety and monitoring of transport systems, and also new services for customers and user-friendly applications. Evolution of railway transport in order to provide some of these new services will be mandatory for its competitiveness, but will also imply new QoS constraints and increase the traffic that should be supported by the communication network. In this context, the GSM-R may still not be the appropriate technology. Anticipating on this situation, several researchers have proposed to move toward more recent technologies, such as GPRS [1], WIMAX [8] or, recently, LTE [9]. GSM technology was widely deployed by mobile telephony operators in Europe. For this reason, both equipment and maintenance costs were relatively lower in comparison with other technologies. In addition to ETCS signaling, GSM-R is also used by almost all European railroad operators for their professional mobile communications. Using GSM-R simplifies the intercommunication of railway networks of the different European countries. However, mobile telephony operators in Europe have moved to 3G technologies and they are even planning to evolve towards 4G technologies such as LTE. Moreover, the end of maintenance on GSM equipment has been announced for 2015 [10]. This situation will oblige railroad operators to resort to specialized services for manufacturing and maintaining GSM equipment in order to keep GSM-R operational. Consequently, GSM-R may still not be the least expensive technology for ERTMS wireless communications in a few years. Even if we consider that, for the very essential ETCS applications, GSM-R provides sufficient network capabilities, we have to keep in mind that in ETCS level 3 deployments the wireless communication system will play a vital role. Indeed, the information necessary to determine train location and train integrity will be computed onboard and will have to be transmitted to the control center via the wireless communication infrastructure. For this reason, it is essential to evaluate the current solution, namely the GSM-R, and the other prospective solutions in the framework of ETCS applications, particularly when impairments occur in the functioning of the telecommunication subsystem. To do so, a tool that could allow us to model the network architecture from the physical layer to higher ones, and to evaluate it by simulation, will be very useful. In the work mentioned previously [1][8][9], the authors used the OPNET [11] simulator in order to model and evaluate their proposals. These evaluations concerned only the behavior of the telecommunication subsystem and are disconnected from the functional part of ERTMS. The ETCS applications evaluated are modeled approximately in terms of the messages they generate during the simulation scenarios. However, the behavior of the functional part of ERTMS is not modeled. In this context, it is not possible to realize simulation scenarios that will allow us to evaluate the behavior of ETCS when impairments occur in the telecommunication subsystem. There are three possibilities for realizing an exhaustive simulation platform that could allow us to take into account both functional and telecommunication subsystem behaviors: By implementing the whole telecommunication subsystem in the ERTMS simulation platform. This will require long development tasks and validation processes such as those related to the implementation of a complete network simulator from scratch; By implementing the whole functional subsystem of ERTMS in OPNET. This will also require long development and validation processes. In addition, the compliancy of the resulting platform with SRS 2.3.0d requirements will have to be demonstrated; By combining the ERTMS simulator for the functional subsystem and OPNET simulator for the telecommunication subsystem. This approach allows us to keep an ERTMS simulation platform compliant with SRS 2.3.0d while taking benefits from a powerful tool like OPNET for modeling the telecommunication subsystem. The major work will consist in specifying how both simulators are synchronized in order to evaluate the same scenario while taking into account the influence of the functioning of each subsystem on the other, and on the performance of the whole system. The third approach has been adopted in this work. For a best understanding of the presented proposals, a brief description of the existing ERTMS platform is necessary. 3 Copyright 2012 by ASME

4 THE ERTMS SIMULATION PLATFORM The ERTMS simulation platform consists of three main components and offline tools for scenario design and analysis. Figure 2 ERTMS simulator architecture Figure 3 The Track Editor Figure 4 Configuring the delays of the messages They are distributed on computers connected through a network. Figure 1 describes the platform architecture 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 track according to a specific ERTMS deployment. Related data are stored for post-simulation analysis. The second component is a 3-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 occurring in the scenario. The third component consists of several modules: a route manager, an interlocking management system, up to two RBCs, up to eleven trains moving simultaneously, including 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 train driving simulator to evolve in traffic including several other trains. The simulation parameters are configured by means of two main tools, namely: The Track editor: allows us to manage all static data of tracks (Fig. 3). It is possible to configure: - Track topology: buffer stop, track segment, switches, crossings, level crossings, track circuits; - Track profiles: electrical, gradient, speed, radio hole, reduced adhesion, non-stopping area; - special areas and infrastructures: RBC control area, RBC to RBC handover, ETCS level transition order, shunting area, bridges, tunnels, stations; - Signals, Boards, ETCS Eurobalises, etc. The Scenario editor for fixing various parameters: - Common tasks: choice of train(s), train configuration, Eurocab or 3D starting conditions; - Traffic scenario tasks: traffic generated according to the data defined in the Track editor, creating one timetable for each train (route setting, arrival time), blocks allocated by Movement Authority, Euroradio key manager (with RBC test bench); - Opsimu scenario tasks: Opsimu scenario is performed on a single line. The parameters are configured manually and one by one (signals, switches, Eurobalises and all messages). For example, for each message, it is possible to set manually the RBC reply delay (see Fig. 4). In the ERTMS simulator only global communication parameters can be set, as illustrated in figure 4. The fact that each message must be configured manually makes the configuration work very hard when frequent periodic messages or several trains are involved. In addition, the fact that all the layers of the telecommunication subsystem are not modeled, the impairments that could occur on the Air gap and modify the delays or some other metrics cannot be taken into account. As mentioned previously, the ERTMS simulator has been designed mainly in order to evaluate the functional subsystem. Modeling the telecommunication subsystem in the same environment will require a complete development from zero of all the components implied, from the physical to the network layer. Moreover, it will be necessary to develop the models for all 4 Copyright 2012 by ASME

5 prospective telecommunication technologies and maintain their evolutions. In order to avoid such a task, we propose a new approach combining the ERTMS simulator with a simulator especially designed for network and telecommunication systems, namely the OPNET simulator. THE CO-SIMULATION PLATFORM ARCHITECTURE Figure 5 The concept of co-simulation for the ERTMS ERTMS simulator View OPNET View Track Trajectory Transmissions OPNET View Metrics ERTMS simulator View Figure 6 The concept of Scenario and its components Figure 7 Modeling the Trajectory in OPNET The first step consists in defining which components of the ERTMS must be modeled in each simulator. As described in figure 5, an ERTMS simulation session can be regarded: either as a simulation of the functional subsystem based on a set of assumptions on the functioning of the telecommunication subsystem; or as a simulation of the telecommunication subsystem where the inputs are based on assumptions on the functioning of the functional subsystem. In order to characterize the components that change in each part of the co-simulation, it is necessary to define a concept that can be used as an invariant in both simulators. The concept of Scenario is proposed as a set of four components: the Track, the Trajectory, the Transmissions and the Metrics. Each of these components refers to an abstract concept that includes all the information on the related objects in the system (Fig. 6). A different view of each component is implemented in both the ERTMS simulator and OPNET. Each view contains only the information that is necessary for performing the simulation on the corresponding simulator. In addition, each view can be refined in one simulator independently from the other, if needed, in order to perform more accurate simulations. The different components can be implemented as follows: 1. The Track: includes all data related to a track. In the ERTMS simulator, it refers to the parameters configured through the Track Editor. Each Track is described once and can be reused in several scenarios. The OPNET simulator provides an API (Application Programming Interface), graphical tools and real world maps, including roads and railways (Fig. 7). The other objects of the Track can be added as node models (Eurobalises, Signals, etc), and custom data structures can be defined in order to support additional attributes. 2. The Trajectory: is defined for each train in a specific Scenario and for a specific ordered set of Tracks. It includes the departure, arrival and pausing times, and the speed on each segment or on any special area or infrastructure. In the ERTMS simulator, the Trajectory is obtained by combining some information obtained through the Track Editor with some others defined through the Scenario Editor. OPNET allows custom trajectories including specific endpoints with geographic or relative location, speed over each segment, and pausing time on specific points (Fig. 7). 3. The Transmissions: this component includes all the packets generated during the communications between the train and the RBC. In the ERTMS simulator it is implemented through the messages defined through the Scenario editor. In OPNET, it includes the control messages related to the telecommunication technology and the messages exchanged by the ETCS applications. OPNET allows defining custom applications and custom messages. 4. The Metrics: include all the metrics and the key performance indicators taken into account during a simulation scenario. In the ERTMS simulator, they are mainly related to the behavior of the system according to ETCS specifications (for example the delay between a request of a RBC and the response of the train). In OPNET they are mostly related to the performance of 5 Copyright 2012 by ASME

6 the telecommunication technology. They can be chosen among built-in statistics provided by OPNET or defined as custom statistics in the code source of the related models (for example the end-to-end delay). Defined this way, the Scenario becomes the key element for synchronizing both ERTMS and OPNET simulators. The abstract concept of Scenario and its abstract components can be modeled using a high-level modeling language such as UML (Unified Modeling Language). Therefore, it is easy to generate the different views for both simulators from these models. Since OPNET provides an API that allows us to implement all the views by programming, specific code generation procedures can be written in order to generate the views automatically for OPNET. In the ERTMS simulator there is still a need to implement such procedures since all the parameters are to be defined via the editors, at this time. THE CO-SIMULATION PROTOCOL OVERVIEW Thanks to the scenario concept, the simulation performed using each view of the same scenario in the related simulator can be seen as the simulation of one subsystem of the ERTMS according to that scenario. Therefore, the results obtained from both ERTMS and OPNET simulators using the related views of the same scenario can be considered as the result of a cosimulation of the whole system for that scenario. However, we still need to define how the synchronization is actually realized, how a co-simulation session can be run and how the results obtained can be validated. To that end, we introduce a cosimulation protocol which can be summarized as follows: 1. Elaborate a Scenario: at this step, the Track is chosen, a Trajectory is defined, the ETCS applications involved which will determine the Transmissions are defined and finally, what is to be evaluated is fixed in the Metrics component. 2. Generate the view for the ERTMS simulator: using the Track and the Scenario Editors, all the parameters necessary for evaluating the system according to the defined Scenario in the ERTMS simulator are set. 3. In the Metrics component, fix the values related to the telecommunication subsystem to those actually expected for the scenario: by default, the values required by the ETCS specifications can be used. But the operator can choose to work with different values according to the objectives of the evaluations. 4. Run the simulation using the ERTMS simulator: this first run refers to what is done using the ERTMS simulator independently from the co-simulation process. We denote it as Sim_ERTMS_Run1. 5. Generate the view for the OPNET simulator based on the original Scenario: this view is directly derived from the original Scenario without taking into account anything in the results of the simulation in step Update the values related to the Trajectory, Transmissions and Metrics components with those obtained in the results of Sim_ERTMS_Run1: the telecommunication subsystem transmits the messages generated by the ETCS applications between the train and the Control Center. Thus, during the simulation the Trajectory adopted will be the one followed by the train in the ERTMS simulator. For example, we may need to change the location of some endpoints of the original scenario to the values observed in the results of the ERTMS simulation. The Transmissions view includes the packets generated by ETCS applications and the control packets generated by the telecommunication subsystem. The Metrics view includes the metrics related to the ETCS applications and to the telecommunication technology itself. 7. Run the simulation using the OPNET simulator: this simulation denoted as Sim_OPNET_Run1 will allow us to observe the actual behavior of the telecommunication subsystem in the context of the Track, the Trajectory and the Transmissions fixed in the Scenario and preliminarily studied with the ERTMS simulator. The actual behavior of this subsystem may lead to a change in the Metrics component and modify some relations between the events generated by ETCS applications (for example, some of the messages exchanged may be received earlier, later or never on the Trajectory, thus leading to changes in the behavior of the functional subsystem). 8. Update the Trajectory, the Transmissions and the Metrics components of Sim_ERTMS_Run1 with those obtained in the results of Sim_OPNET_Run1. 9. Run the simulation using the ERTMS simulator: this simulation is denoted as Sim_ERTMS_Run Validate the results: in order to validate the results of a co-simulation using ERTMS and OPNET simulators, we introduce the concept of Set of Events. When a train is moving on a Track, the successive functional responses of ETCS applications (MAs, Stop orders, etc) on the Trajectory of the studied Scenario can be regarded as an Ordered Set of Events. Two Ordered Sets of Events are equivalent for a specific Scenario when they lead, from a functional point of view, to the same behavior of the system. Each simulation run on the ERTMS simulator leads to a specific Ordered Set of Events. Therefore, the results of the co-simulation process are validated if the Ordered Sets of Events attached respectively to Sim_ERTMS_Run1 and Sim_ERTMS_Run2 are equivalent. The process can be repeated by going back to step 6 using the results obtained at step 9 until a valid co-simulation is obtained. The ERTMS simulator has a time granularity of 1 second. Thus, when two successive simulations obtain the same sequence of delays without being equivalent, the co-simulation process stops on a fail. This guarantees that there is a stop condition anyway. The results obtained respectively in each simulator allow a deep study of the related ERTMS subsystem. 6 Copyright 2012 by ASME

7 The results of the co-simulation ensure that the study of the functional subsystem using the ERTMS simulator has been performed with a realistic telecommunication subsystem. EXAMPLE: ANALYZING THE IMPACT OF THE DELAY Let us consider a Scenario elaborated in order to study the impact of different delays observed during the movement of a train on a specific Track. As described in figure 8, when the train sends a request to the RBC, the telecommunication subsystem, namely the GSM-R, delivers the message with a certain delay D T->RBC. The Trackside ETCS applications process the message with a certain delay D P. The response of the RBC is delivered to the train by GSM-R with a certain delay D RBC->T. Figure 8 The different delays observed for one message In the ERTMS simulator, the total delay D = D T->RBC +D p + D RBC->T can be set arbitrary as a parameter (see Fig. 4) in Sim_ERTMS_Run1. Let us consider the chosen value as D ERTMS1. During the co-simulation process, we can introduce a mechanism in the ERTMS simulator that allows us to obtain precisely the value of the processing delay D p. This value is used as an input in Sim_OPNET_Run1, and OPNET will allow us to obtain precisely the values of D T->RBC and D RBC->T. Let us denote by D ERTMS2 = D T->RBC +D p +D RBC->T the sum of these precise values. We use it as an input in Sim_ERTMS_Run2. We can now compare the functional responses obtained in Sim_ERTMS_Run1 and Sim_ERTMS_Run2. If the train receives the same response to its request (for example: Stop or pass at the next interlocking ), Sim_ERTMS_Run1 and Sim_ERTMS_Run2 are equivalent since their ordered sets of events are equal. As a result, the co-simulation is valid. In some conditions, it may be useful to introduce additional conditions. For example, it may be stated that the co-simulation is valid if Sim_ERTMS_Run1 and Sim_ERTMS_Run2 are equivalent, and that the condition D ERTMS2 -D ERTMS1 <ε is fulfilled (where ε is co-simulation parameter that represents the maximum acceptable difference on the delays). If the co-simulation fulfills these conditions, we obtain a valid co-simulation that provides in the Metrics component a value for the delay D ERTMS2 which is based on a realistic functioning of both the functional and the telecommunication subsystems, instead of the arbitrary value D ERTMS1. The example presented in this section illustrates a cosimulation based on a Scenario that represents normal conditions. However, it is also possible to introduce a disconnection after the train has transmitted, for example, and obtain a Scenario where the response of the RBC arrives much later than the initial value D ERTMS1. This way, the impact of a dysfunction in the telecommunication subsystem on the functional response delay can be also studied by co-simulation. When a Scenario is based on real-world traces, they can be used in order to validate the results obtained by each simulator. PRELIMINARY RESULTS This paper presents a work in progress. The co-simulation platform is currently being realized by several teams working in collaboration. The first step consists in validating separately each one of the two simulators in its ability to model and evaluate accurately the related ERTMS component. To that end, we chose to work with real-world traces of a train movement on an ERTMS level 2 track. The departure of the train and a part of its movement, about 30 minutes later, are described in figure 10. The traces provide the position and the speed of the train. For each message exchanged between the train and the RBC, they give the source of the message, the duration of its transmission, its content and the time at which it is transmitted. These traces allow building a very realistic scenario. Following the co-simulation approach, this Scenario serves to implement the different views for both ERTMS and OPNET simulators. Time ms KP Speed Source of data RBC M# ETCS Message Bytes ETCS Application Message HEX data (Eur 16:24: TRAIN Initiation of a communication 18 9B FF0B64D231636C2F session 16:24: RBC 1 32 Configuration Determination C FFFFFE43FC135765D1C936 16:24: TRAIN Session established 21 9F A C F260FAC 16:24: ,6 10 TRAIN Validated Train Data C000028AC E43521A200A450 16:24: RBC 1 8 Acknowledgement of Train Data AFFFFFFE F A 16:24: TRAIN Acknowledgement A AC025134A61 16:24: RBC 1 24 General Message FFFFFFFFA238A4B0B :24: TRAIN Acknowledgement A C03AAF5AF2 16:24: RBC 1 24 General Message FFFFFFFF90E0B76ED48C7A0 16:24: TRAIN Acknowledgement C08A8AC849 16:25: RBC 1 24 General Message EFFFFFFFFFF603213BBF9D130 16:25: TRAIN Acknowledgement EFC0422B24F1 16:25: RBC 1 24 General Message FFFFFFFF69982EE F 16:25: TRAIN Acknowledgement F C0A0B584EF 16:25: RBC 1 24 General Message DDFFFFFFFF6A289F86C9B6AB 16:25: TRAIN Acknowledgement F DDC0C52A :25: ,9 10 TRAIN Position Report A E43521A1001F50 16:57: ,3 120 TRAIN Position Report C586C E435202E069E00 16:57: RBC 2 3 Movement Authority C5876D480B81E016101FF80BC99 16:57: TRAIN Acknowledgement C59F C B 16:57: ,6 120 TRAIN Position Report C5A E435202E07EB00 16:57: ,6 120 TRAIN Position Report C5A E435202E07EB00 16:57: ,0 120 TRAIN Position Report C E435202E0D :57: ,0 120 TRAIN Position Report C603C E435202E0D :57: RBC 1 24 General Message C603ED480B85501C4D :57: TRAIN Acknowledgement C C603C08962F1AF 16:57: TRAIN Termination of a communication session 18 9C028000C C4DE88E2A :57: RBC 1 39 ACK of termination of a communication C61CCD480B9F6004C8C1068CA9B Figure 9 Real-world traces of a train movement The Track and the Trajectory views derived from this Scenario for ERTMS simulator have been implemented easily. The Transmissions view has been modeled, but still presents some difficulties. Indeed, the time granularity of 1 second in the ERTMS simulator cannot allow retrieving exactly the same values for the delay in the Metrics component view than in the Traces, where they are given in milliseconds. One solution consists in taking several successive messages of the same type in the traces which total time is about an integer multiple of 1 second, and modeling them as a single message block. But this is possible only if the successive messages have the same source, that they are sent to the same destination, and that no message from this destination is received meanwhile. 7 Copyright 2012 by ASME

8 For example, the message of type Position Report sent at 16:57:45 during 176 ms by the train to RBC2 can be aggregated with the one of the same type sent by the same train to the same RBC2 at 16:57:48 during 801 ms (Fig. 9) in order to obtain a single RBC2 answering delay (Fig. 4) of 977 ms (about 1 s) since no message from RBC2 has been received meanwhile. Doing so is not possible all the time, but over the entire Scenario, it will allow us to reduce the gaps and to improve the delay analysis. This feature and others are still being addressed in order to perform an accurate evaluation of this Scenario using the ERTMS simulator and to validate the results. The views for OPNET related to the Scenario derived from the realworld traces are generated as follows: The Track and the Trajectory views are modeled in a single OPNET trajectory object. Indeed, we do not need to model physically the balises or the other components of the track; we only need to know where they are located. Thus, on the trajectory object we can define a specific endpoint at every location associated with a track component in the real-world traces. As described in figure 10, the location and the corresponding time in the OPNET Trajectory view are exactly the same as in the real-world traces. In OPNET, it is possible to obtain a high precision of similarity between the Transmissions and Trajectory views (fig. 10), and the real-world traces. Indeed, in the Trajectory view, we can provide a start time, a starting position and a speed such that at each time given in the real-world traces, the train will be exactly at the related location. Moreover, we can schedule a transmission at exactly the same time than in the realword traces with a precision of up to ten milliseconds. The Metrics view keeps the values of the delay metric. accurate studies, we need a realistic model of the GSM which will be customized in order to meet GSM-R specifications. Several GPRS models have been proposed for the OPNET simulator. The authors of [1] present a detailed description of all of them and propose some improvements in order to obtain a GPRS-R model. However, as stated by the authors themselves, this model does not implement the physical layer. The MAC/RLC and the Air interface modules are missing, thus impeding the analysis of important metrics like the Bit Error Rate (BER). Moreover, this model does not implement the GSM signaling messages that are mandatory in the GSM-R model that we are targeting. We also found a GSM model for OPNET available in the contributed models [11]. The model, originally designed in order to study the GSM technology from the point of view of signaling, implements almost all the features including signaling messages, measures procedures, different handover procedures, user actions, SIM operations, interconnection with other networks and all the components of a GSM network (MS, BTS, BSC, MSC, SS7, GMSC, HLR, PSTN). However, the model misses some important features: The MAC/RLC module and the TDMA frames are missing. Only dedicated channels can be used. The transmission of Voice and Data are not modeled. We have started to improve this model in order to complete all the features of the GSM. The transmission of new packets has been implemented, thus allowing us to simulate the transmission of voice only in a circuit-switched mode. We study a scenario that implies a single mobile station representing the train (ms_1 in fig. 11) which sends data to the MSC (msc1 which represents the RBC) during its ten minutes movement. Figure 10 The Trajectory view for Transmissions Once all the views are defined, we obtain a model of the Scenario ready for simulation in OPNET. We need a model of the telecommunication subsystem, namely a model of GSM-R in this case. The OPNET Modeler provides a model for the UMTS, WIMAX and LTE technologies, but not for the GSM. The behavior of this later can be studied by using the TDMA (Time Division Multiple Access) model provided in OPNET. However, such a study will allow us to analyze only the transmissions, but not the signaling or the other mechanisms implied among the different layers. In order to perform more Figure 11 The GSM model in OPNET Figure 12 End-to-end delay for voice transmission 8 Copyright 2012 by ASME

9 Using a full-rate GSM voice codec, the train sends 260 bits in each 20 ms block of speech. We observe (Fig. 12) an end-toend delay of 22 ms which is less than 35 ms required for voice transmission in railway environment. This allows us to validate the data transmission that we have implemented in this model. We are currently improving this model in order to obtain a realistic GSM-R deployment and perform accurate evaluations in the framework of the co-simulation process. It is therefore already possible to replace the GSM-R infrastructure by the model of any of the other prospective telecommunication technologies and perform simulation using the views generated for the Scenario. Such evaluations have been carried out notably in [8], but the main advantage of the approach presented in this paper is that it will be possible to connect it with a corresponding evaluation of the functional subsystem. CONCLUSION AND FUTURE WORK This paper has presented a new approach to simulationbased evaluation of railway transport management systems, particularly the ERTMS. Most of the existing testbeds focus mainly on the functional subsystem and idealize the functioning of the telecommunication. Most of the simulation-based evaluation carried on the telecommunication subsystem simplify the functional subsystem and reduce it to a sequence of message exchanges. We proposed to connect these separate evaluations by the mean of a co-simulation implying both the ERTMS simulator for the functional subsystem and OPNET for the telecommunication subsystem. Using the scenario as the keyconcept on which the co-simulation is based, we showed how different views of the same scenario can be generated for each simulator. A co-simulation protocol also described how the results obtained from both simulators can be combined in order to obtain a valid co-simulation. Since this paper presents a work in progress, we have to finalize the implementation of a GSM-R model in OPNET in order to validate a complete co-simulation process on a realistic scenario. In our future research lines, we are targeting the implementation of a virtual testbed in OPNET based on real-world data (on tracks, traffic and transmissions) that will allow us to evaluate the GSM-R and the other prospective telecommunication technologies in the framework of ERTMS scenario. We will also study the changes that are necessary to adapt the ETCS applications and the Euroradio layer to a full-ip telecommunication technology such as LTE. NOMENCLATURE ERTMS European Rail Traffic Management System ETCS European Train Control System OPNET Optimum Network Performance GSM-R Global System for Mobile Communications- Railway UIC International Union of Railway MA Movement Authority EOA End Of Authority RBC Radio Block Center MS Mobile Station BTS Base Transceiver Station ERA European Railway Agency ITS Intelligent Transport Systems GPRS General Packet Radio Service WIMAX Worldwide Interoperability for Microwave Access DMI Driver Machine Interface CENELEC European Committee for Electrotechnical Standardization RBC Radio Block Center UML Unified Modeling Language MAC/RLC Medium Access Control/Radio Link Control UMTS Universal Mobile Telecommunication System TDMA Time Division Multiple Access BER Bit Error Rate BSC Base Station Controller MSC Mobile Switching Center SS7 Signaling System 7 GMSC Gateway Mobile Switching Center HLR Home Location Register PSTN Public Switched Telephone Network ACKNOWLEDGMENTS The present research work is supported by: the CISIT, the FEDER, the Region Nord Pas de Calais. The authors gratefully acknowledge the support of these Institutions. REFERENCES [1] Ruesche, S. F., Steuer, J. and Jobmann, K., 2008, Increase of Efficiency in Wireless Train Control Systems (ETCS level 2) by the Use of Actual Packet-Oriented Transmission Concepts, IEEE/ASME JRC2008, Delaware, USA (2008) [2] Levêque, O. and De Cicco, P., 2008, ETCS Implementation Handbook, Infrastructure Department, UIC (2008) [3] [4] Müller, H. K., 2003, ERTMS: on track for success, UIC ERTMS Conference 2003, Leipzig (2003) [5] Mera, J. M., Gomez-Rey, I. and Campos, A., 2007, ERTMS/ETCS test simulation bench, Urban Transport and the Environment in the 21 st Century, XIII, UK. [6] [7] UNISIG SUBSET-026, 2010, System Requirement Specification, ERTMS, European Railway Agency (2010) [8] Aguado, M., Onandi, O., Jacob, E., Pinedo, C., Saiz, P. and Higuero, M., 2007, Wimax Role on CBTC Systems, ASME/IEEE JRCICE2007, Pueblo, Colorado, USA (2007) [9] Aguado, M., Liedo Samper, I., Berbineau, M. and Jacob, E., 2011, 4G Communication Technologies for Train to Ground Communication Services: LTE versus WIMAX, a simulation study, 9 th World Congress on Railway Research, Lille (2011) [10] [11] 9 Copyright 2012 by ASME