An Experimental Analysis of Hierarchical Rail Traffic and Train Control in a Stochastic Environment

College of Transportation Engineering, Tongji University, Shanghai, China Key Laboratory of Road and Traffic Engineering of the Ministry of Education, Tongji University, Shanghai, China Shanghai Key Laboratory of Rail Infrastructure Durability and System Safety, Tongji University, Shanghai, China IVT-Institute for Transport Planning and Systems, ETH Zurich, Zurich, Switzerland Swiss Federal Railways, Bern, Switzerland IDP-Institute for Data Analysis and Process Design, ZHAW, Zurich, Switzerland


Introduction
In railway systems, intelligent rescheduling (Traffic Management System, TMS) and autonomous driving (Automated Train Operation, ATO) are not a novelty. e automation module partially or entirely takes over the tasks of dispatchers and drivers. With the support of TMS and ATO, trains have no conflicts with other trains and run with their optimal speed profiles, therefore optimizing the utilization of railway capacity and overall system efficiency.
ose benefits, however, have been found so far only on metro systems: many driverless metro systems are now operating around the world. e current challenge is to apply automated systems to operations on conventional (mainline) railways. In mainline railways, the state-of-the-art execution of both traffic control and train control happens manually. Only very few automated processes are implemented to guarantee a safe train operation. One such example is the Automatic Train Protection (ATP) supporting the train's overspeed protection and keeping a safe headway between trains. However, the increasing need for sustainable transportation of people and goods has led to a growing density of traffic on a limited railway network. Extending the network with new railway lines is rarely an option, as such projects require huge investments and long-term planning. erefore, the capacity of the existing network needs to be increased while simultaneously keeping the energy consumption low. is can be realized by further automating processes. e TMS is often proposed to help/replace dispatchers. TMS automatically monitors the real-time traffic state and in case of delays/conflicts computes an updated schedule that minimizes delays by changing train speeds, times, routes, and orders [1]. e TMS makes decisions at the traffic level, while the ATO takes actions at the train level, which is responsible for executing the production plan, and makes real-time driving decisions [2]. e ATO system has been typically defined as hierarchically below the TMS [3][4][5]. is hierarchical connection of TMS and ATO has been proposed for a while and the advantages are promising. However, few have investigated the interaction with the real field [6], like (i) stochastic external disturbances to real train operations (e.g., unforeseen dwell and/or running times extensions), (ii) missing or erroneous information about current traffic state and train parameters, etc. e main open question for both researchers and practitioners is whether automatic rescheduling and train operation tools can concretely reach the improvements found in theory, when instead they are actually interfaced with uncertainty. erefore, this paper is to set up a hierarchical connection between TMS and ATO for mainline railways and thus to evaluate the performances of such a system in stochastic environment in terms of punctuality, energy efficiency, and conflict-resolving with simulation methods.
In general, railway traffic is based on a timetable, defining the exact arrival and departure times for each train at each station. Meanwhile, railway traffic is subject to many different kinds of perturbations propagating quickly through the system. erefore, real-time dispatching is needed to restore the original timetable and resolve conflicts. A conflict in that sense occurs, when two or more trains require the same piece of infrastructure at the same time. Nowadays, most of the railway traffic control is done by human dispatchers, which base their decisions on training and experience, lacking intelligent decision support. Nevertheless, the research on the topic of automated railway traffic control by the TMS is extensive. An overview can be found in [7,8].
e basic principle is to either re-route, re-time, and reorder trains, or cancel services to restore the original timetable while fulfilling certain other objectives, such as the reduction of the total delay or the reduction of the consecutive delay. ere exists a variety of approaches on how to solve this problem, differing in the following considerations: (i) Consideration of future changes: static TMS gets information on the traffic state at one point in time and computes the control measures and implements them, assuming perfect knowledge of future traffic states. Dynamic TMS on the other hand takes uncertainty into account and after a certain rescheduling interval, the control measures are computed again with updated traffic state information [6]. (ii) Level of detail: macroscopic rescheduling approaches consider stations only while microscopic rescheduling approaches consider each block section and signal [9][10][11]. (iii) Dimension of disturbance: small disturbances only request small rearrangements in the timetable, while big disturbances might require the cancellation and/ or replacement of certain trains [12,13]. us, the rescheduling processes regarding big disturbances might also take into account the rearrangement of crews and rolling stock. (iv) Solving algorithm: different solving approaches have been adopted for solving the rescheduling problem, such as the alternative graph approach, mixed-integer linear program (MILP), etc. An overview can be found in [7,8].
Despite the variety of rescheduling approaches and TMS types, many TMSs do not consider detailed train dynamics (e.g., train mass, train failure, different driving strategies, etc.). is could lead to a side effect that the real-time TMS traffic plan cannot be executed well by drivers/ATO systems. Nevertheless, being able to follow TMS timetables is essential to make automatic railway traffic control practicable [4,14,15]. In fact, TMS has so far been mainly a scientific topic and there are very few practical applications; showing applicability in real life conditions is very important.
ATO is the automatic real-time control of a train's acceleration, braking, cruising, and coasting commands according to the actual traffic plan [16]. e technology has emerged over the last few years with the development of control and computer technologies and is considered to be a very promising approach in order to improve energy efficiency and network capacity compared to the manual train control by a train driver [2,17]. e latter is based on training and experience rather than exact computation, which is why it is difficult to guarantee the optimal operation, for example, in terms of energy efficiency, punctuality, and stopping accuracy.
Many metro lines are operating ATOs (e.g., Paris Metro, London Underground, Beijing Subway, and Lausanne metro). Metro railways depend strongly on an efficient operation to get the maximum capacity out of their rail network. As they have a relatively simple timetable design, homogeneous trains, and few uncertainties due to weather conditions, they are predestined for the ATO system. On the other hand, mainline railways have a much more complex timetable [18], different train types, dependent connections, and uncertainty due to weather conditions. erefore, developing an ATO system for mainline railways is much more complex. Nevertheless, some mainline railways are equipped with driver advisory systems (DASs), which support drivers with additional advice on optimal speeds, control regimes [19,20]. ere exist practical DAS examples, such as the AF (Automatic Function) in the Lötschberg Base Tunnel in Switzerland [21], the GreenSpeed applied in Denmark [22], and the Computer-Aided Train Operation (CATO) applied in Sweden [23]. e research on integrated traffic and train control becomes more and more popular only in recent years. One research stream of integrated traffic and train control is to simultaneously solve the rescheduling problem and the train trajectory optimization problem [24,25]. A TMS has a clear overview of the entire traffic state and possible conflicts. erefore, the TMS can not only re-route, re-time, and re-order trains, but also compute and transmit optimal speed trajectories directly to involved trains. Such a framework spares the train from braking or stopping at signals due to an unexpected, rescheduled timetable and it can therefore prevent both time and energy loss. In [9,10], such a model is proposed, where the dispatching and train trajectory computation are not done sequentially, but rather both tasks are part of the entire problem-solving. Another research stream is to specify proper system frameworks for integrated management of traffic and train operation. In other words, TMS and ATO are still independent tools. Research has been focused on optimizing the communication and interaction between the two systems and investigating efficient ways of distributing intelligence (functions) among the two systems. e European project ONTIME has developed a framework to set up standards for the inter-operable cross-border automatic real-time management [14,15]. e ATO system has been typically defined as hierarchically below TMS [3,4,19]. With such a hierarchical framework, the TMS takes charge of conflict detection and computes conflict resolutions, while the ATO undertakes executing traffic plans. However, there is always a gap between optimized results and actual situations. e first reason is due to unexpected disruptions, such as unpredictable dwell times, inappropriate driver behaviors (in case of using DASs), communication delays, and so on. e second reason, however, results from deviations between train dynamics estimation/prediction in TMS and in the real situation. e train dynamics estimation/prediction in TMS not only relies upon the real-time information about traffic state, but also needs the real-time information about train parameters (driving strategies, train weight, train failures, etc.), as those factors lead to different train performances. If TMS has no access to real-time train parameters, these train dynamics estimation/prediction in TMS cannot represent the real case. Consequently, the differences bring inaccuracies and difficulties for ATOs/drivers to follow real-time traffic plan accurately. Only recently, [5] elaborated a more holistic theoretical framework, which uses bidirectional communication between traffic management and train automation. By doing so, the TMS knows if its traffic plan has been fulfilled and it can improve its calculation according to the real-time feedback from train automation. However, the bidirectional communication between traffic management and train automation has not been examined with detailed experiments yet.
According to the background information and literature review given above, this paper focuses on specifying a control framework for an integrated management of traffic and train operation on mainline railways and sets up a simulation environment to evaluate the integrated traffic and train control in stochastic and dynamic conditions. Compared to the other large study of interaction between traffic control and simulation, like the proof-of-concept presented in [15], the present paper uses a microsimulator tool like OpenTrack, which has been validated and used in many real life projects and is a de facto standard and connects not only TMS and simulation, but also ATO for energy efficient and smooth train control, with simulation.
Moreover, the stochastic aspects included in comparable studies in the state of the art are not going beyond a simple Monte Carlo scenario of delayed traffic, while we introduce randomness/incomplete knowledge also in train parameters, and information availability. Finally, we evaluate a range of KPIs, instead of pure delays.
is paper interfaces a rescheduling tool [26,27] and an ATO tool [28] with the realistic traffic simulation environment OpenTrack [29]. ree different traffic scenarios are designed, including an on-time scenario, a delay scenario, and a train failure scenario. e investigation has been performed by referring to the three different traffic scenarios within a typical Monte Carlo scheme. e proposed methodology has been applied to a real case-study in the Netherlands: the railway corridor between Utrecht and Den Bosch. Results show that, in case of on-time operations, the implementation of ATO systems is beneficial for maintaining timetables and saving energy costs. Moreover, in case of delay disruptions, the TMS rescheduling has its full effect only if trains are able to follow TMS rescheduled timetables, while the energy-saving by using ATO can be only achieved with conflict-free schedules. A bidirectional communication between ATO and TMS is beneficial for conflict-resolving and energy-saving. e rest is organized as follows. Materials and Methods presents the integrated TMS and ATO control and simulation framework. Results and Discussion presents the case study in the Dutch railway corridor Utrecht-Den Bosch, and the evaluation we perform. e last section concludes the paper and discusses the future research directions.

Materials and Methods
In this section, a simulation framework for integrated traffic (TMS) and train control (ATO) is presented. is involves the choice of the control scheme, the simulation platform, the rescheduling method, the speed profile optimization method, and the ATO driving command generation method. Figure 1 presents a cascade control loop framework for integrated rail traffic management and train control, which is extended from the basic control framework proposed by ON-TIME project [14]. e framework consists of four basic control loops. e first loop is the TMS control loop, which is responsible for traffic state monitoring, conflict detection, and resolution. In other words, TMS computes and translates the real-time traffic plan to each train based on information from different sensors. e real-time traffic plan, here indicated as the rescheduled timetable, defines conflict-free train paths, with detailed route setting, for each train and updated arrival, departure, and passing-through times, which typically minimize delays. In the second loop (ATO/DAS control loop I), a speed profile and the associated time-distance path are computed based on outputs from the first loop. e speed profile is derivable and fulfills a set of constraints and objectives, such as minimal energy consumption, punctuality, or riding comfort. e third control loop, ATO/DAS control loop II, is used for generating driving advice/commands to train drivers, or to directly control train movement to follow the optimal trajectory, or get back to the trajectory in case of deviations. en the final automatic train protection (ATP) control loop supervises independently that any safety restrictions are respected by the advice implementation.

Control Framework.
Overall, TMS is in charge of the traffic level and produces the conflict-free real-time traffic, while the ATO is in charge of optimizing train speed profiles (trajectory computation) to match the time constraints set by TMS decisions. It has to be mentioned that a TMS nowadays predominantly has to deal with non-continuous train detection, depending on certain fix-installed infrastructure elements (e.g., axle counters) (without the red dashed line in Figure 1). In other words, the TMS only knows one train's position after the train passes an axle counter. We assume that instead trains can report some status description to a control center. is requires sensor and onboard processing capabilities, which can be integrated into a supervisory control for movement, and onboard monitoring systems (e.g., for power equipment) and communication channel to a trackside control center. Concerning this latter, on top of the existing communication channels now dedicated to movement supervision (in legacy and ETCS systems) we can assume more pervasive communication capabilities, allowing the TMS to be quasi-continuously connected to every train's ATP/ATO (see, for instance, the project 5GRail: 5G for future railway mobile communication system [30]).
We therefore assume possible to enhance the future train states' predictions, conflict detection, and resolution functions with more information on current trains' performances and conditions. In addition, the ATO nowadays receives only train speed and position reports. By those channels, the information reported on train position and speed can be enriched with other information, from onboard monitoring systems, such as acceleration and deceleration, failures (e.g., doors not opening), train integrity, automatic passenger counters, remaining useful life of critical components, etc., as well as from train dynamics (estimated or calibrated train acceleration and deceleration capabilities, train weight, train failures, etc.). All this information is assumed available to the ATO, to improve control accuracy.

Simulation Framework.
We construct a simulation platform to analyze the potential benefits and limitations of the integrated traffic and train control framework presented in Figure 1. e simulation framework implemented in this work is shown in Figure 2. It consists of four modules: TMS, trajectory generation, ATO command generation, and OpenTrack simulation platform. e data exchanged is detailed as follows, as described in both upper part and lower part of the figure. Infrastructure pertains length, topology, routes, switches, gradients, radii, etc. Vehicle pertains rolling stock characteristics such as maximum speed, acceleration, braking, etc. e planned timetable and the rescheduled timetable specify the operation of trains as a sequence of time and space points. A train failure can be represented by updated values for maximum speed, acceleration, and braking possibilities for the affected vehicle. e dwell time represents the time spent at a planned stop; the entrance delay represents the variation with regards to the planned departure times at any planned stop. In the paper, we also investigate different scenarios in which some information on delays and failure is not available, to provide benchmark cases. e speed profile lookup table (LUT) reports the expected consequences from a series of actions (accelerating, braking), for any considered position and speed. ATO Commands are the specific decision on changing/maintaining the speed of a train at a specific moment and space. e most relevant input and outputs of the four modules are summarized in Table 1, divided into offline inputs (data which does not change, and is available on beforehand), online input (data which is available only at a specific moment), derived inputs (computed by another module in our proposed framework), and outputs (data made available to other modules, or implemented as control actions). We also mention when the data exchange takes place. e TMS rescheduling function is built based on the work done in [26,27]. We here recall briefly the main characteristics of the models in the following sections, while for formal definitions and detailed examples we refer to [26,27]. e TMS is responsible for the rescheduling of the original timetable according to entrance delays, train failures, etc. e output of TMS is a rescheduled timetable. In case trains are controlled by ATOs, the rescheduled time-  module. Otherwise, the rescheduled timetable is transmitted to the disposition system in OpenTrack before the runthrough. On the other hand, it is assumed that the train operation can be controlled by the ATO or the OpenTrack internal speed controller. e ATO system consists of two parts, which, respectively, correspond to ATO control loops I and II in Figures 1 and 2. e first part is an offline trajectory generation module which calculates several speed profile lookup tables with respect to the given rolling stock (different train parameters) and infrastructure. e second part is an ATO command generation module, which decides on optimal driving commands with regard to the real-time train location, speed, speed profile lookup tables, and rescheduled timetable.
e ATO trajectory generation function and driving command generation function are built on the basis of [31]. More detailed descriptions regarding speed profile lookup table and ATO command generation algorithm are introduced in Sections 2.5 and 2.6. e real-time simulation interconnects two elements: the microscopic simulation tool OpenTrack [29] simulating the train movements and railway system and the ATO command generation algorithm deciding on optimal actions for every train at different locations. At regular time intervals, updated traffic information is gathered from OpenTrack and transferred to the ATO command generation tools to compute optimal driving commands, based on all available information. A basic introduction to OpenTrack is included in Section 2.3.

Simulation of Railway Traffic with OpenTack.
e railway system is represented by the microscopic simulation tool OpenTrack [29]. OpenTrack contains detailed information about the infrastructure (signals, stations, radii, gradients, and speed limits), the rolling stock (length, mass, maximum traction power, maximum traction force, deceleration, and resistance parameters) as well as timetable entries (departure, arrival, and dwell times). As output, OpenTrack generates several data files for evaluation, such as speed, acceleration, or energy consumption per time or distance. e simulation of train movement is a time-driven model, meaning that the simulation is realized by integrating Newton's motion equations for each time step in order to get the train's position and speed. e trains must, however, also respect signals indicating whether the according block   OpenTrack provides a "train performance" parameter to simulate different human driver behaviors. e train performance parameter is the scaling value for acceleration and maximum speed (initial state 100%). By default, OpenTrack simulates the train movement at maximal available acceleration, speed, and deceleration, respecting the infrastructure speed limits and signals. is results in a minimum travel time, provided that the train performance is set to 100%. OpenTrack suggests imitating human driver behavior by reducing the performance of the train; i.e., OpenTrack allows users to define their own piece-wise linear distribution functions for travel time performance of punctual (on time) and delayed individual trains. is allows OpenTrack to provide a more realistic distribution of travel times.
Besides, OpenTrack allows the connection to other programs via a programming interface (API: application programming interface) so that they can send standardized commands to OpenTrack and receive defined status messages from OpenTrack [32]. In our proposed simulation framework, OpenTrack is connected to the TMS module and the ATO command generation module ( Figure 2). On the one hand, TMS rescheduled timetables can be directly handed over from the TMS to OpenTrack, so that the dispatching in OpenTrack is handled according to TMS timetables accordingly. On the other hand, OpenTrack receives driving commands from the ATO driving command generation function and sends train position reports to corresponding ATOs.
It is also possible to implement delays or other perturbations in OpenTrack. To simulate train movement in a stochastic environment, the simulation takes into account random entrance delays and random dwell times. e entrance delays are assumed to be known by the scheduler (TMS) and the simulator (OpenTrack), while the random dwell times are known by the simulator, but not to the scheduler. e scheduler uses predefined dwell times for rescheduling.

TMS Rescheduling Algorithm.
e TMS algorithm used in this paper is based on the work presented in [26,27]. Its task is to reschedule the original timetable in order to resolve conflicts and to reduce delays, which have been caused by various perturbations. As a standard assumption, the algorithm is assumed to have perfect future knowledge of all entrance (initial) delays arising during the considered time horizon [7]. e TMS maintains an estimated internal evolution of the network, therefore, by which there is no dynamic detection of the traffic state at any point in time during the run-through (train failure information is assumed to be available when relevant). In addition to the entrance delays and train dynamics, further inputs to the TMS include the infrastructure information (position of signals and stations), traffic characteristics (origin, destination, route, minimum travel time, etc.), and original timetable, to compute minimal travel times. e TMS algorithm formulates the rescheduling process as a mixed-integer linear programming (MILP) model, based on the time-continuous formulation method. e model optimizes train orders and arrival and departure times at passing stations based on the current delay and traffic situation, minimizing the sum, over all trains, of the absolute delay times (both late arrivals and early arrivals) at all visited stations, subject to a number of constraints for ensuring the operational and safety requirements. e key constraints include the following: (1) transition constraint to force the spatial and temporal transition of each train as it moves on the rail network; (2) train travel/dwell time constraint to ensure the required minimum travel/dwell time; (3) safety headway constraint to define the safety time interval between trains; and (4) capacity constraint to guarantee that any pair of trains using the same infrastructure (track/block) are conflict-free. For the sake of space, we do not present here the detailed formulations of the TMS algorithm; interested readers may refer to the MILP model presented in [27] for those details. Note that the TMS algorithm can be solved by a standard MILP solver, e.g., CPLEX or Gurobi.
In the TMS algorithm, we consider microscopic infrastructure details (i.e., block sections), and we allow only one train to occupy a block section at any given time. us, the output of our TMS algorithm is a microscopic schedule, i.e., arrival and departure times for each block section, with a guarantee of the solution feasibility at the microscopic level. It is worth noting that OpenTrack timetable entries are only possible for stations (not, e.g., signals) and entries at stations are only respected by trains stopping at that respective station. erefore, we neglect the microscopic details of the generated TMS timetable and extract only the macroscopic schedule (i.e., the train arrival and departure times at stations), used as the OpenTrack timetable entries.

ATO Trajectory Generation.
e ATO trajectory generation function and driving command generation function are built on the basis of [31]. Within the ATO trajectory generation module, the train operation control problem is formulated as a Markov decision process (MDP) and solved using an offline approximate dynamic programming (ADP) method to learn the energy and time costs over iterations.
Specifically, the train driving process is formulated as an MDP by dividing the train journey into small pieces with a set of discrete locations (which correspond to the control points); see Figure 3. e discretized location is represented with the symbol d in the following description. At every discretized location d, a set of potential train speeds (S d ) are defined.
ose speeds have to be non-negative and are bounded from above by the speed limit. In addition, at every speed point S d , a set of potential driving commands are defined.
e driving command at S d is represented by x d (S d ), while the set of potential driving commands is represented by e driving command set is defined by following two heuristic rules: (i) the driving command is among the four optimal regimes for energy-efficient driving: maximum traction (MT), speed holding (SH), coasting (CO), and maximum braking (MB) [33][34][35]; (ii) the driving command respects the maximum accelerating/braking rate restrictions for passengers' riding comfort [36]; and (iii) performing the decision MT from the departure station, MB to stop at the arrival station, and MT, SH, CO, or MB in the middle of the journey but avoiding decisions that would violate the speed limits or result in unnecessary stops and low travel speeds.
For every combination of discretized location d, speed S d , and driving command x d (S d ), an ADP-based method [31] is used to learn the following two values: e learned results are stored in a so-called lookup table, as the example presented in Table 2, which is then adopted by the ATO command generator for online decision-making, as described in the next section.

ATO Command Generation.
e ATO command generation module receives the up-to-date train position and speed report from OpenTrack in a regular time interval. As soon as the train reaches any predefined discretized location, the ATO needs to come up with a driving command and sends it to OpenTrack for the control of train movement. e driving command is determined according to the off-line learning results (lookup table, Section 2.3) as well as a decision-making function in (1). Assume a train is reaching a discretized location d and heads towards a timetable target point, z. Its speed is closest to the speed point S d , then the optimal driving command at stage d is selected with the following function: where X d (S d ) refers to the selected driving command at location d. t d (S d , x d ) and T z d+1 (S d+1 ) are the learning results obtained from the offline ADP-based algorithm proposed in [31].
is equal to the overall estimated running time from d to z. T z d (S d ) is the scheduled remaining time from state S d to z. e difference between the two items refers to the ability of the train following its timetable by using energy-efficient driving commands. In case that the overall estimated arrival time is later than the scheduled time, X d (S d ) often goes for a fast driving in order to reduce delays. Otherwise, X d (S d ) goes for a cruising or a coasting, in order to arrive on time and saving energy. Function (1) ensures the selected driving command prioritizes on-time arrival over energy reduction. In addition, the ATO command generation module works online but is extremely fast as it has to take a single control decision mostly based on precomputed information.

Test Case.
e corridor between Utrecht and Den Bosch ('s-Hertogenbosch) from the Dutch Railways has been used. e corridor is about 48 km long and has nine stations. e infrastructure characteristics consist of an accurate description of all track sections, points, speed signs, gradients, and signals over the entire track layout from Utrecht until Hertogenbosch. Details can be found in [28]. e infrastructure is equipped with the fixed-block signalling system NS'54 and the automatic train protection system ATB.
e corridor is simulated in one direction only (Ut-Ht); however this does not affect the results as the other direction operates on different tracks. Two train types are operated on this corridor: intercity trains (IC) and sprinters (SP). e characteristics (train mass, rotating mass factor, train length, maximum traction force and power, maximum braking rate, and train resistance curves) of the sprinter and intercity can be found in [28]. Each hour, three IC services drive directly from Utrecht to 's-Hertogenbosch without any intermediate stop. Moreover, two SP services stop at each station, one terminates in Geldermalsen, the other in 's-Hertogenbosch. For the simulation a time horizon of two hours was considered with a half-hourly clocked timetable, resulting in 20 trains departing from Utrecht (12 ICs, 8 SPs).

Simulated Human Driver Behaviors.
As we mentioned in Section, OpenTrack provides a "train performance" parameter to simulate different human driver behaviors (different levels of acceleration, deceleration, and cruising speeds). In this work, the train performances are random parameters and set based on the following rules: for trains operating punctually: 20% of trains operate with performance values between 90% and 92%; 60% of trains operate with performance values between 92% and 94%; and 20% of   [6,37]). e scale, shape, and shift parameters of these distributions are, respectively, equal to 394 s, 2.27 s, and 315 s for ICs and 235 s, 3 s, and 186 s for SPs.

Simulated Train Failure.
To study how failures affect the train operations, the study simulates a train failure that a local train, SP6927, lost half of its engine. Such a train failure affects several following train operations and causes secondary delays.

Scenarios.
e experiment aims to examine the performances of the integrated TMS and ATO under both punctual and delayed circumstances. In addition, it also aims to evaluate the impacts of full/partial knowledge of real-time train parameters. ree sets of scenarios are built to achieve our targets; see Table 3.
Scenario I: the first scenario set simulates the train operation under punctual circumstances. No TMS rescheduling function is needed. e traffic is controlled by OpenTrack internal FCFS (first come first serve) dispatching rule. Scenario I includes two cases: Scenario I(a), as a benchmark, assumes all trains are controlled by human drivers (OpenTrack simulated human behavior). Scenario I(b), instead, assumes all trains are operated with ATOs.
Scenario II: the second scenario set simulates the traffic in case of delay disruptions by assuming simulated trains get random entrance delays at their initial stations. Scenario II includes four cases: in Scenario II(a), trains are controlled by human drivers and the train dispatching follows the original timetable and the FCFS dispatching rule. Scenarios II(b) and II (c) have only ATOs or TMS into use. Scenario II(d) assumes both TMS and ATOs come into use. Scenario III: the third scenario set is to examine the impact of full/partial knowledge of real-time train parameters. is scenario set considers a real-time train failure of SP6927, which might be known or not known by TMS and ATOs. Both entrance delays and the train failure are considered in Scenario III. Scenario III(a), as a benchmark scenario, assumes all trains are not equipped with ATOs and there is no TMS rescheduled timetable. Scenarios III(b)-III(d) assume all trains are operated with ATOs and follow the TMS rescheduled timetables. e differences between the three scenarios include the following: in Scenarios III(b) and III (c), only ATOs or the TMS are/is aware of the train failure. In Scenario III(d), both TMS and ATOs have knowledge of the train failure. In Scenarios III(b) and III(d), it is assumed that new lookup-tables were computed offline considering different types of train failures. ose lookup tables can be used accordingly in real time for the train speed control.

Monte Carlo Simulation Settings. For every scenario, the analysis is performed over 20 different cases in a typical
Monte Carlo setup. Each case is generated by randomly sampling entrance delays (Scenarios II-III) and disturbances to dwell times at stations (Scenarios I-III). e Monte Carlo simulation is performed on the basis of the framework presented in Figure 2. 3.1.7. Metrics. Paper [38] provides a comprehensive review on different metrics for the evaluation of rail service. is paper selects the following metrics from [38] to evaluate the simulation results, respectively, from punctuality, energysaving, and conflict-resolving perspectives: (i) Average delay is the average of the total arrival delay (i.e., max actual arrival time− {  e first three metrics indicate the deviation in time and space between the planned and simulated train paths, which are closely related to the capability of the control framework to keep acceptable levels of traffic performance when stochastic disturbances affect operations. e fourth metric is closely related to operational costs. e last two metrics give a measure of how vulnerable the traffic is in terms of unexpected yellow and red signals (the planned timetable has no yellow or red signal).

Scenario I: Undelayed Traffic.
e metric values of the scenario are reported in Figure 4. ose variations are reported in average; note that variation might occur, due to the different delay samples, and within each delay sample, due to the heterogeneity of traffic (which we analyze in detail in Figure 5).
Concerning punctuality, both Scenarios I(a) and I(b) contain some delays. ose delays are caused by the random dwell time settings we used: in order to simulate the uncertain passenger boarding/alighting time, the simulation assumes random dwell times. erefore, the simulated dwell times might be longer than the scheduled dwell times in some cases, causing affected trains depart/arrive late at following stations. e average early and late arrival times by using ATOs are much less than the cases with simulated human drivers. Besides, the values of punctuality indicators, P1min and P3min, of Scenario I(b) are higher than Scenario I(a). We can conclude that the ATO algorithm performs better in maintaining the given timetable in case of no entrance delay. e early arrivals in Scenario I(a) have two reasons. First, the original timetable includes some time supplements to be robust against small disturbances. Second, the OpenTrack speed controller does not make full use of those time supplements and this leads to early arrivals.
Concerning energy, the total energy consumption of all trains is reported in Figure 4. Scenario I(b) saves around 487 kWh (11.1%) energy costs, in 2 hours. e energy-saving can be explained as the ATO makes better use of time supplements (less early arrivals) and adopts energy-efficient driving commands (coasting, low-speed holding). Scenario I(a) uses reduced train performance parameters (90%-96%) to simulate human behaviors; i.e., trains are driven with reduced speeds and traction power, instead of moving at their maximum power and speed. erefore, this is a relatively fair simulation of human drivers, and thus we can conclude that implementation of ATO has an essential effect on reducing energy consumption in case of no big disruptions.
Concerning conflict-resolving, red signals are not observed in both Scenarios I(a) and I(b), as Scenario I simulates no-delay circumstances. But, around 10 yellow signals on average are observed in both scenarios. ose yellow signals are caused by two reasons: first, some trains get late departures due to unexpected long dwell times. Late departures make the actual train paths differ from their scheduled paths and cause small headways and yellow signals. Second, some SPs are overtaken by ICs at station Gdm, and the headways between ICs and SPs are quite small around Gdm, therefore, causing yellow signals.
We further consider the heterogeneity of traffic and analyze in Figure 5 the probability distribution of variations in energy (left) and delay (right), split by the two train categories. Positive values along the x-axis identify better performance of Scenario I(b) compared to Scenario I(a): reduced delays, or reduced energy consumption. e energy variation is typically slightly positive; in other terms Scenario Journal of Advanced Transportation 9 I(b) reduces energy compared to Scenario I(a), for IC trains. For the SP trains, a bimodal case arises, with some trains which have 25% less energy, and some which have 10% more energy. e delay variation is always positive; in other terms, Scenario I(b) never increases delay compared to Scenario I(a), with a large peak at 0. e delay variation for the IC trains is larger, spreading all the way to more than a minute. For SP trains, it is more concentrated into a range of about 10-30 seconds. e diversity in outcomes between IC and SP shows that heterogeneous traffic is affected differently from TMS-ATO, already when limited random factors are considered.

Scenario II: Delayed Traffic.
e metric values of the scenario are reported in Figure 6. ose variations are reported in average; note that variation might occur, due to the different delay samples, and within each delay sample, due to the heterogeneity of traffic (which we analyze in detail in Figure 7).
Concerning punctuality, Scenario II simulates the traffic under delay circumstances in four cases: in Scenario II(a), trains are controlled by human drivers and the train dispatching follows the original timetable and the FCFS dispatching rule. Scenarios II(b) and II(c) have only ATOs or TMS into use. Scenario II(d) assumes both TMS and ATOs are put into use. In Scenario II(b), although the average delay is lower than the benchmark scenario, the overall punctuality, especially P3min, is not improved. is can be explained by the fact that Scenario II(b) does not have the TMS rescheduling function, so that ATOs can only follow a non-optimal timetable. Scenario II(c) simulates the cases equipped with only the TMS. Its P1min, P3min, and average delay are even worse than Scenario II(a). is indicates that the TMS rescheduled timetable might not be able to achieve its delay reduction function if the rescheduled timetable is not well executed by drivers. Compared to Scenario II(c), the punctuality is much improved in Scenario II(d), which replaces human drivers with ATOs. In other terms, the ATO algorithm is better at following TMS rescheduled timetables than the simulated human drivers.
Concerning energy, the energy consumption in Scenario II is higher than the one in Scenario I. Scenario II simulates all trains operated under delay circumstances. e ATO driving command generation function prioritizes delayed trains in catching up timetables instead of energy-saving operation (see Section 2.5).
e OpenTrack simulated drivers move delayed trains with performance values between 98% and 100%, which basically means to run with nearly maximum power and speed. erefore, the energy consumption in Scenario II is higher than Scenario I. Meanwhile, by comparing Scenarios II(b)-II(d) to II(a), we see that the energy costs are reduced by using TMS or/and ATOs. It is observed that, with only TMS or ATOs (Scenarios II(b)-II(c)), the energy costs are reduced by 0.86%-2.29%. With both TMS and ATOs (Scenario II(d)), the energy costs decrease by as much as 8%. It indicates ATOs' ability in energy-saving can be better achieved only with conflict-free schedules from TMS. In addition, the energy reduction in Scenarios II(b)-II(d) can be explained for two reasons: first, the average early arrivals in Scenarios II(b)-II(d) are less than that in Scenario II(a), so that punctual trains in Scenarios II(b)-II(d) make better use of running time supplements and therefore require less energy consumption than in Scenario II(a). Second, the number of conflicts (red signals) in Scenarios II(b) and II(d) is lower than in Scenario II(a). As the conflicts may lead to energyconsuming braking and re-accelerating processes, fewer red signals basically means less energy wastes due to the braking and reaccelerating processes.
Concerning conflict-resolving, Scenario II leads to more red and yellow signals than Scenario I, because Scenario I simulates traffic without delay impacts whereas Scenario II simulates traffic with entrance delays. Delayed trains deviate from their conflict-free scheduled time and space paths, thus resulting in more conflicts. By comparing Scenarios II(b)-II(d) to the benchmark Scenario II(a), it is seen that the number of yellow signals is not much reduced by using ATOs or/and TMS, and the number of red signals can be only significantly reduced with the combination of TMS and ATOs. e results reveal that the TMS rescheduling has its full effect in improving punctuality and conflict-resolving only if the TMS rescheduled timetable is well executed.
We further consider the heterogeneity of traffic. Figure 7 analyzes the probability distribution of variations in energy (left) and delay (right), split by the two train categories; and comparing Scenarios II(b), II(c) and II(d) against Scenario II(a), respectively in the rows. Positive values identify better performance compared to Scenario II(a): reduced delays, or reduced energy consumption. Scenario II(b) shows a certain amount of variation between the different trains, when compared to Scenario II(a), with the IC trains achieving a general 10% reduction in energy. Instead, the SP trains have a larger variation, linked to a small (around 10%) increase in energy. ere are individual trains which have a large increase in energy, up to 50%. In any case, the two train classes have distinct behavior: IC are generally saving energy, while SP do not. Scenario II(c) has a very sharp distribution of variation (with the value at 0 out of vertical scale); i.e., energy is pretty much the same as in Scenario II(a). Scenario II(d) shows a rather homogeneous picture with both train classes having a similar variation, covering the range ±25%. is is possibly due to the intermediate stops which regularize the delays. Scenario II(c) shows again a very sharp distribution (with the value at 0 out of vertical scale); i.e., TMS alone is able to identify which few specific trains need to be controlled, to result in less delays. Again, IC have a slightly larger spread; some SP have a negative variation of delay (i.e., an increase), following the order optimized by TMS. Scenario II(d) shows a sharper peak for SP trains, while IC trains suffer more variation of delay. For all scenarios, the average delay variation is not very large, and only for the scenarios using TMS this increases. Overall, the two train categories result in different characteristics, when exposed to the four scenarios, with a larger spreading of effect compared to the benchmark II(a), especially when ATO is used.

Scenario III: Disrupted Traffic.
Scenario III is designed to examine the impact of full/partial knowledge of the train failure by TMS/ATOs. e metric values of the scenario are reported in Figure 8.
Concerning Punctuality, Scenarios III(b)-III(d) lead to similar delays and punctuality: the average delays are around 50 s (32%) less than Scenario III(a), and the P1min and P3min are, respectively, improved by 25% and 18%. Such an improvement can be explained for two reasons: First, the ATO function prioritizes following rescheduled timetables. Second, the TMS changes train orders (rerouting is not considered in our case study) thus avoids delay propagation. e knowledge of train failure by TMS/ATOs seems not to affect punctuality much. In other words, in the case of the tested train failure, equipping with TMS/ATOs is beneficial for the improvement of punctuality, no matter if the train failure is known by TMS/ATOs or not.
Concerning energy, Scenario III(d) consumes 11.97% and 9.85% less energy than Scenarios III(b) and III(c), respectively; and 7.60% more energy than Scenario III(a). In Scenarios III(b)-III(c), the train failure is known by only TMS or ATOs. erefore, TMS produces nonoptimal timetables, or ATOs come up with improper driving commands, which may cause conflicts (red and yellow signals, most numerous for those two scenarios) and frequent braking-acceleration behaviors. Such frequent braking-acceleration behaviors lead to high energy costs in Scenarios III(b)-III(c). In Scenario III(d), on the contrary, both TMS and ATOs are aware of the train failure. Hence, the TMS rescheduling function and ATO driving command generation function have taken into account the train failure.
is contributes to a reduction of conflicts (red signals) as well as a reduction of energy consumption. Scenario III(d) consumes 7.60% more energy than Scenario III(a). e additional energy costs come from the concurrent effect of a few factors. In Scenario III(a), TMS is not considered; therefore the traffic runs in such a way that multiple trains are hindered by the broken train and cannot drive as fast as they are supposed to do. is is an effect reducing energy for Scenario III(a). Scenario III(d) has all trains controlled by ATOs. ATOs prescribe delayed trains to run as fast as possible. Instead, in Scenario III(a) the assumed reduced performance value (modeling a human driver) is fixed to a maximum of 98%; thus trains will go at a lower maximum speed, reducing energy. Finally, the traffic control in Scenario III(a) does not take into account traffic properties and results in trains running too close, seeing repetitively yellow signal and experience multiple acceleration and braking processes to keep up with the speed of the preceding (broken, or delayed) trains.
is can be evaluated by the number of yellow and red signals in Scenario III(d), which is the lowest, about half compared to Scenario III(a).
is is an effect increasing energy consumption for Scenario III(a). e final balance of those three effects is what empirically evaluated.

Journal of Advanced Transportation 13
Concerning conflict-resolving, the number of yellow and red signals in Scenario III(d) is the lowest, about half compared to Scenario III(a).
at indicates the full knowledge of the train failure by TMS/ATOs is beneficial for conflict-resolving.
We again quantitatively study the heterogeneity of traffic, this time by analyzing the performance of trains happening to run before the broken train, and those afterwards, also identifying the single contribution of the broken train itself. We report the results in Figure 9, with stacked bars identifying energy, average delays, and yellow and red signals (respectively, top and bottom row). In those cases, we do not separate into train categories IC/SP, as the data samples might be too small. We specifically focus on the 14 Journal of Advanced Transportation variation before/after the disruption (respectively, top/bottom of the stacked bar), which shows the capabilities to limit propagation of non-performance in the network. Concerning energy, Scenario III(a) achieves the lowest values, and for all trains (before, and after): this is a systematic condition due to the default train dynamic in OpenTrack.
e variations in the other scenarios pertain only traffic after the disruption. Scenario III(b) results in the largest energy for the trains running after the disruption, due to multiple downstream speed adjustments (TMS aims to reduce delays, at the cost of low fluidity of traffic, being unaware of the disruption).
We study average delays, reporting in Figure 9 the average per each category, in order to compare the categories, which have different amounts of trains. In all cases, the broken train has the largest average delay, as it runs at    reduced performance. In Scenario III(a), the traffic before and after the broken train faces a larger average delay, compared to Scenarios III(b), III(c), and III(d). In those latter cases, the traffic is reorganized by means of TMS or ATO actions, which results in increasing the average delay of the broken train, but achieving better performance for the rest of the traffic. In Scenario III(b), the delays are the lowest, but the traffic fluidity is low: the trains after (i.e., those subject to rescheduling) face many yellow and red signals, as they follow each other very closely. In other terms, a bad model of traffic characteristics used in TMS results in the ATO reactively (and not proactively) managing the speed changes. Scenario III(d) results in the smallest amount of yellow and red signals shown, mostly due to much better management of trains after the broken train, limiting propagation of non-performance. Scenarios III(b) and III(c) are relatively similar with most differences in the trains following the broken train. Scenario III(b) gives fewer red signals to the broken train, compared to Scenario III(c) at the cost of having more red signals for the downstream traffic. In other terms, some actions computed happen to be myopic with regard to their consequences. Finally, we select a case respectively from Scenarios III(a) and III(d) for a further illustrative analysis as below. e two example cases have same entrance delays, dwell times, and train failure. eir time-distance paths are presented in Figures 10 and 11. e metric values of the two cases are shown in Table 4. Overall, the example case of Scenario III(d) has fewer delays, higher punctuality, more energy costs and fewer conflicts than Scenario III(a). is finding is the same as the results presented in Figure 8.
Again, the average energy cost of Scenario III(d) is a bit higher (4.5%) than Scenario III(a), and this further differs if we look into individual trains. Take the intercity, IC827, in Figures 10 and 11 for instance. We also draw the speed profiles of IC827 of the two scenarios in Figure 12. In Scenario III(a), IC827 is directly hindered by the broken train SP6727 and meets many yellow signals in the section between Htnc and Gdm. e speed profile shows indeed no less than 12 braking-acceleration actions. In Scenario III(d), instead, the TMS rescheduled timetable suggests IC827 to run slow, with a long coasting between Ut and Cl, and ultimately arriving at Gdm at the same time as in Scenario III(a). Deciding to perform such a long coasting is beneficial for conflict-resolving as well as for energy-saving and requires the cooperation between ATOs (to actually implement the coasting) and TMS (to know how long the coasting should be). Failure to include those both aspects explains why Scenario III(d) consumes much less energy costs than Scenarios III(b) and III(c).

Conclusions
is paper investigates the benefits and limitations of an integrated framework of connecting TMS and ATO in terms of punctuality, energy efficiency, and conflict-resolving with simulation methods. e simulation is built by interfacing a rescheduling tool [26,27] and an ATO tool [28] with the realistic traffic simulation environment OpenTrack [29], and applying the proposed methodology to a real case-study in the Netherlands: the railway corridor between Utrecht and Den Bosch. e main findings are summarized below: (i) In Scenario I, we see that the energy costs are reduced by around 11.1% and the punctuality (P1min) is improved by 12.36% by using ATOs. It reveals that, in case of no entrance delays, the implementation of ATO systems is beneficial for  maintaining timetables and saving energy costs. e effects of ATO/TMS to the traffic are different, depending on the train type; in other terms, heterogeneity of traffic adds complexity to the evaluation and setup of the systems.
(ii) Scenario II simulates the traffic under delay circumstances. e results show that the energy reduction by equipping both TMS and ATOs (8%) is more obvious than by equipping only the TMS or ATOs (0.86%-2.29%). In other words, the energysaving by using ATOs can be better achieved with conflict-free schedules. On the other hand, from the punctuality and conflict-resolving point of view, the punctuality at 1 min level and 3 min level of Scenario II(d) is, respectively, improved by 8.77% and 2.20%. e red signals of Scenario II(d) are reduced by 57.89%. In other words, by equipping both TMS and ATOs, the punctuality is much improved with less early arrivals and less delays. On the contrary, in case that only TMS or ATOs are equipped (Scenarios II(b)-II(c)), either the punctuality is not improved, or the conflict-resolving is not improved. We can conclude that the TMS rescheduling has its full effect in improving punctuality and conflictresolving only if trains are able to follow TMS rescheduled timetables.
(iii) Scenario III examines the impact of full/partial knowledge of the train failure by TMS/ATOs. In the case of our tested train failure (half engine loss of one single train), equipping with TMS/ATOs is beneficial for the improvement of punctuality (the average delay is reduced by 32%), no matter if the train failure is known by TMS/ATOs or not. But the knowledge of train failure by TMS/ATOs is beneficial for conflict-resolving and energy-saving. e benefit is more obvious if both TMS and ATOs have knowledge of train failure. Compared to the scenarios in which only TMS or ATOs know the train failure, the energy cost is reduced by around 9.85%-11.97% and the number of red signals is reduced by 68.25%-81.82% in the scenario that both TMS and ATOs have knowledge of train failure. However, different train dynamics and failures (mass, or failure, or driving strategies, etc.) may have different impacts on the performance of the integrated TMS/ ATO framework. erefore, it is also an interesting topic to explore the impacts of different knowledge of train dynamics in the future.
In addition, the results also prove the usefulness of the proposed simulation methodology to analyze the benefits and limitations of the integrated traffic and train control in a stochastic and dynamic environment. e simulations and evaluations done in this work can be further developed and improved in several aspects. To start with, the simulation framework can be extended to study other failures that affect the train operations; the simulation framework can be extended with the implementation of an online multiple open-loop or a closed-loop TMS, sending updated rescheduled timetables based on the current traffic state. Further, the speed optimization function could be moved to a central unit, so that multiple trains' speed profiles are optimized together, which is expected to reduce the amount of yellow and red signals. Both TMS and ATO could be extended to include also other performance indicators, such as passenger travel time, or riding comfort. e more precise estimation of impact on traffic flow from the interaction between ATO and TMS could support other design choices, like infrastructure (block layout), or timetable (buffer time) [39]. Finally, this simulation approach proved how the microscopic timetable has benefits in solving local conflicts and reducing delays. is assumes though that some processes and barriers in real life can be overcome, which include availability of offline and real time data, with a good microscopic quality for timetable and actual operations, availability of train dynamic parameters, specific reaction time and delay of the ATO system, and description of the specific rules used by the signalling system. Moreover, it assumes a fast-enough loop to disseminate information between the involved users.

Data Availability
e data used to support the findings of this study are included within the article.

Conflicts of Interest
e authors declare that there are no conflicts of interest regarding the publication of this paper.