Applying Collaborative Co-Simulation to Railway Traction Energy Consumption

Abstract

Simulation is a vital tool for understanding rail traction energy consumption. Simulating such energy consumption requires an understanding of the interactions between timetable, infrastructure, and driver behavior to be encapsulated within a multi-train system model. This is critical to simulating systemic interactions that affect energy consumption on a rail network. However, building and executing such a system simulation is challenging because of diverse models, stakeholders, and knowledge, as well as a lack of tools to support flexible and scalable simulation. This paper presents a demonstration of co-simulation—an approach originating in the automotive industry and now being used in other sectors—that enables a system model to be assessed for different configurations of timetable, rolling stock, infrastructure, and driver behavior. This paper describes the co-simulation approach before outlining the development process that allowed three research institutes, each with diverse models, to collaborate and deliver an integrated, holistic modeling approach. The results of this work are presented and discussed, both in terms of the quantified outputs and findings for energy consumption, and the lessons learned through collaborative co-simulation. Future avenues to build on this work are identified.

1. Introduction

Rail simulation is a common approach to understanding rail performance. It plays an important role in the design of hardware (rolling stock and infrastructure), as well as for operational planning and optimization, such as timetabling and train pathing. Simulation is also integral to efficient energy consumption, be that through the design of new components for energy-efficient rolling stock (for example, regenerative braking systems [1]), the design of power supply to the rail network [2], or optimal design of discontinuous electrification [3,4].

While adaptation of individual components or subsystems can deliver decarbonization benefits, these benefits can be amplified when coupled at a system level to maximize energy efficiency [5]. Conversely, benefits can be negated through unanticipated system interactions. For example, while it may be possible to recharge batteries during turnarounds in duty cycles, this needs sufficient time in the timetable to allow the transfer of sufficient charge, which may vary because of seasonal factors such as weather or use of a Heating, Ventilation and Air Conditioning (HVAC) subsystem [6]. Therefore, the challenge is to predict system interactions to support informed decision-making for design and operations.

The kind of systems modeling required to assess these interactions is often impeded by a number of factors. Different models may have incompatible interfaces; models may be built in different formats or using different modeling tools [7]. Different disciplines (e.g., electrical engineering, mechanical engineering, and operations management) have different knowledge, terminology, and expectations. The complex and legacy nature of the rail sector can be particularly challenging for new entrants [8].

Multi-modeling offers a solution to address this simulation challenge. Multi-modeling is the application of two complimentary technologies—Functional Mock-up Interface (FMI) and co-simulation. FMI is an open standard format, widely adopted in sectors such as automotive and aerospace, which enables the packaging of simulation models in the form of Functional Mock-up Units (FMUs). Multiple FMUs can be run together in parallel through a co-simulation toolchain. The toolchain supports the interfacing and synchronized execution of qualitatively different model types, including both discrete event and continuous time, to generate and visualize complex simulation results. Together, FMI and co-simulation have the potential to deliver complex system simulation in a more flexible manner than is currently possible through traditional rail simulation methods.

While previous low Technology Readiness Level (TRL) work has demonstrated the potential for multi-modeling to support rail power modeling [9], the work was on a simple metro model and had not been tested with an interdisciplinary group, including expertise in power modeling and timetabling. However, the potential benefit of the FMU approach is that it can be used to wrap and export high-fidelity modeling from other providers with specialist expertise and within the system model [10].

This paper presents a demonstration of the collaborative co-simulation approach applied to a railway decarbonization problem. Crucially, multiple specialists and institutions were involved, each providing a different model to the overall system model. The models came in diverse formats and were orchestrated through the INTO-CPS co-simulation platform [11], an approach to allow reuseable and flexible dynamic simulation that is common in other sectors, e.g., [12,13]. These models were then used to demonstrate successfully the integration of timetable, power draw calculations, and driver behavior, as well as how systems effects emerge in terms of energy consumption when the models are combined and varied in a single co-simulation.

The fundamental research aim was to attempt to integrate multiple models from diverse institutions to create an effective system simulation for rail energy modeling using the FMI/co-simulation paradigm. In achieving this aim, the contributions of this paper are: (1) a description of the demonstration simulation, (2) a description of the process required to deliver a flexible co-simulation, and (3) lessons learned from the process.

The paper is structured as follows—Section 2 presents the background on relevant aspects of modeling and the co-simulation approach. Section 3 presents the methodology used in the paper. Section 4 presents the source base models used for the co-simulation prior to their integration. Section 5 presents results in terms of both the final co-simulation model and the final modeling outputs. Section 6 discusses the learnings through the process, limitations, and areas for future research, with conclusions in Section 7.

2. Background

2.1. Energy Modeling

2.1.1. Traction Network Modeling

In the context of railway efficiency and sustainability, traction network modeling serves as an indispensable research tool. This technique focuses on the electrical infrastructure required to power trains, as well as the distribution and regulation of electrical energy from substations to the trains traveling through the rail network [14]. The core of traction network modeling lies in its ability to simulate and optimize the interaction between the rolling stock and the power supply. This includes assessing the voltage stability, impedance, and power loss across various components of the traction system, such as overhead lines or third rails [15]. It also entails analyzing how different train operations impact the power load and the subsequent need to balance the power supply.

The primary outputs of traction network modeling, including detailed assessments of the current capacity of the electrical network, identification of critical points where power may fall short during peak times [16], and projections for future expansion needs [17], are crucial for maintaining an efficient and reliable power supply as rail networks grow and demand increases for more frequent and faster services.

2.1.2. Train Power Modeling

Power modeling is a fundamental aspect of railway systems analysis, as it provides insights into energy consumption, operational efficiency, and the environmental impact of train operations [18]. By simulating the power demand during a train’s journey, engineers can design systems that are both energy-efficient and aligned with operational constraints. Power modeling is crucial for evaluating the performance of different rolling stock configurations, optimizing energy usage, and ensuring the sustainability of rail transport [17]. In addition, the power model is able to evaluate the performance of the train under different conditions, including different slopes, loads, and speeds. This helps to design trains that can meet service requirements while minimizing energy consumption. Train power modeling can also provide information for infrastructure planning by determining the power requirements of the electrical system, evaluating the technical and operational feasibility of dynamic or static charging solutions for battery electric multiple unit trains, balancing power distribution between hybrid train energy supply systems, and evaluating the interaction between trains and the power grid [19]. Train power modeling mainly includes vehicle characteristic parameter simulation, traction energy demand calculation, regenerative braking energy recovery, route topology, and operation scenarios.

Simulation tools such as Vision OSLO are used to facilitate train power modeling. Vision OSLO enables detailed analysis of power consumption under various operational conditions, offering insights into the most energy-efficient practices [9]. Another pivotal tool, RailSys, is employed for comprehensive operational planning. RailSys integrates timetable and power modeling to assess the operational impacts of various scheduling scenarios, helping to optimize both the efficiency of train operations and the energy utilization across the rail network [20]. In this study, the train power simulation was constructed using MATLAB Simulink version R2024a Update 3.

2.2. Timetable Modeling

Timetable modeling is a critical element in managing the efficiency and reliability of railway operations. This process involves careful coordination of train schedules to ensure optimal service provision while adhering to operational constraints. In addition to the physical and power demand aspects of train operation, the formulation of an appropriate timetable is critical for maximizing operational efficiency and safety. A well-structured timetable aids in avoiding conflicts between trains, ensuring there are adequate buffers and thus reducing the need for abrupt stops or rapid accelerations, which are significant contributors to high energy consumption and increased maintenance needs. By aligning the timetable with dynamic conditions and operational constraints, railways can achieve a more sustainable and safe transport system. Incorporating these considerations into power simulation modeling can thus provide more comprehensive insights into the overall performance of railway operations, including scenarios that test the robustness of timetables under varying conditions.

The essential output of timetable modeling includes the arrival and departure times of each train at each station, expressed in terms of links, where a link is a section of track that forms a path between two consecutive stations. Figure 1 illustrates two trains, $i$ and $j$, running on a railway line with $\left|L\right|+1$ stations and $\left|L\right|$ links, where L is the set of links. The preceding train is $i,$ and the following train is $j$. The times at which trains $i$ and $j$ leave link l (and thereby arrive at station l) are denoted by ${out}_{il}$ and ${out}_{jl}$, respectively. The times when $i$ and $j$ enter link l (and thereby depart from station l − 1) are denoted by ${in}_{il}$ and ${in}_{jl}$. Thus, these link timing variables collectively represent the arrival and departure times of all trains at each station and thereby form the timetable for the entire railway system.

The Train Timetabling Problem (TTP) is a complex optimization problem that has garnered significant attention from researchers over the past few decades. Two primary modeling approaches have been employed: continuous models, where train arrival and departure times are treated as continuous variables, and space-time (discretized) models, which discretize these times based on a space-time network.

2.2.1. Continuous Models

Continuous models aim to determine optimal train schedules by treating time variables as continuous, allowing for precise adjustments to minimize conflicts and maximize efficiency. Szpigel [21] introduced one of the earliest mathematical formulations for train scheduling, focusing on minimizing total travel time. Subsequent studies, such as those by [22,23], developed linear programming models to optimize train movements on single-track railways, emphasizing the reduction in delays, operating costs, and improvement in punctuality. The survey by [24] gives a comprehensive review of early works using continuous models. Kr0on and Peters [25] extends the periodic event scheduling problem (PESP) model for cyclic railway timetabling by incorporating variable trip times, enabling greater flexibility and feasibility in scenarios where fixed trip times are impractical while retaining compatibility with existing solution methods. Kroon et al. [26] proposes a stochastic optimization model to minimize train delays by reallocating running time supplements, demonstrating that small timetable adjustments can significantly reduce average delays for both individual trains and cyclic timetables on shared railway infrastructure. Meng and Zhou [27] presents a stochastic programming framework with recourse to optimize train schedules over a rolling horizon, addressing input data uncertainty and leveraging a multi-layer branching solution to generate robust meet-pass plans under varying probabilistic scenarios.

2.2.2. Space-Time (Discretized) Models

Space-time models discretize the railway network into time-space units, facilitating the application of combinatorial optimization techniques. Caprara et al. [28] first developed an integer programming approach based on a time-expanded graph, effectively handling large-scale instances of the train timetabling problem. This method soon became the dominant approach, given its effectiveness in representing the essential elements and constraints in TTP. See the surveyed papers in [29,30] for details.

2.3. Human Performance Modeling

In practice, human performance characteristics are known to show variability that influences overall rail system performance, including power consumption [31]. For the driver, performance variability may be due to driver strategy (for example, training in defensive driving) [32]; route knowledge of ideal acceleration and coasting points [33]; anticipation of signal states, particularly after incidents [34]; concerns around traction and adhesion issues because of weather or location. In addition to this rational adaptation of behavior, operational roles are also prone to more general limitations on human performance. For the driver, this is often an issue of fatigue and decrements in vigilance [35]. However, increased automation leads to greater periods of monitoring for the signaler versus greater responsibilities for the driver at stations (driver-only operation) or dealing with driving in congested conditions means low workload can also be a factor [36].

Such behaviors and performance-shaping factors can be modeled for simulation. AlMekhlafi et al. [37] demonstrated the effect of work factors and fatigue on driver performance, while [38] developed a driver model using cognitive theory to predict performance time under different conditions. This was subsequently implemented as a computational model. Nneji et al. [39] uses a discrete-event model to predict human operator workload at different traffic levels.

However, the preceding simulation work is standalone and lacks the flexibility for integration into wider, flexible system modeling. Golightly et al. [40] demonstrated the potential for non-rail human performance modeling in FMU and co-simulation. Subsequently, Golightly et al. [9] demonstrated the influence of driver behaviors in a simple metro co-simulation. Pierce et al. [41] demonstrated the impact of different driver models in a three-train mainline model, but this used a simple rolling stock model, and the sequencing of trains was only described as a set headway (e.g., 2 min headway between trains) rather than a full timetable. Therefore, there is an opportunity to demonstrate the role of human performance modeling in more complex, multi-stakeholder co-simulations with accurate train and timetable models.

2.4. Multi-Modeling for Systems

Multi-modeling refers to a set of processes to combine and analyze groups of heterogeneous models representing different parts of a system. A common method of analysis is co-simulation, where two or more simulations are executed simultaneously under the control of a master simulation algorithm that shares data between them. In this way, individual simulations influence each other. Multi-modeling differs from a tool pipeline, where the output from one analysis forms the input to another in a chain, as data in a co-simulation is shared at runtime. Multi-modeling allows for the creation of holistic, system-level models where each part of the system can be modeled in a different paradigm by different teams from different domains and potentially using different formalisms. This, in turn, enables collaborative modeling, as multidisciplinary teams can model together while using familiar tools and techniques, which in turn enables communication—any issue found in integrating multi-models will necessarily lead to discussions and mutual understanding.

Cyber-physical systems (CPSs) that combine hardware, software, and human elements are a key area in which multi-modeling is beneficial. This is because computing and other logical processes are often represented using discrete-event modeling paradigms—where the focus is on the key events that represent the state of the system and when it changes, whereas physical systems (such as rolling stock and power simulations) use continuous-time modeling—where differential equations are used to represent physical phenomena and numerical methods are used to perform high-fidelity simulations. Within this work, our discrete-event formalism is VDM-RT, a real-time dialect of the well-established Vienna Development Method (VDM) formalism, supported by VDMJ (VDMJ tool site [42]) and the Overture Tool suite (Overture tool website [43]). The continuous-time tool used is 20-sim [44], an accessible yet powerful modeling and simulation tool supporting the modeling of physical phenomena with equations, block diagrams, and an extensive library.

The multi-modeling and co-simulation approach that enabled our collaboration is based on the FMI open standard [45]. This standard was developed for the co-simulation of automobile component models but has been more widely adopted in several industries. The FMI standard defines a way to package models as FMUs. An FMU should contain all binaries and data required for the model inside to run, as well as a model description (an XML file) that defines the interface—inputs, outputs, and parameters—that the model provides. There is a core set of functions in FMI that each FMU must implement to initialize, receive inputs, perform a simulation step, and provide outputs. The FMI standard website lists over 100 tools that can export FMUs, and there are several open libraries to help users create their own. Both 20-sim and the Overture tool suite can export FMUs.

A master algorithm is required to run a co-simulation. The algorithm is responsible for loading and running the FMUs and passing data between them, as well as the synchronization of (simulation) time between the FMUs. This project uses the Maestro co-simulation engine [11], an open-source tool managed by the INTO-CPS Association (INTO-CPS Association [46]), which provides two standard master algorithms. A basic, fixed-time step master algorithm initializes the required FMU instances, then requests each in turn to take a fixed time step (e.g., one second) and synchronizes the inputs and outputs after all the FMUs have completed this step. This is simple to implement but inflexible because the time step may not coincide with an event (instant in time) in one or more of the FMUs. A more complex variable-time step master algorithm will additionally ask each FMU what time step size it would prefer and will select the minimum; in this way, allowing for more flexibility, but at the cost of compatibility (many FMUs do not implement this optional feature). Maestro also allows for the definition of custom master algorithms using a domain-specific language called MABL, which is useful for specific co-simulations where, for example, the FMUs must be advanced in a particular order due to dependencies between them.

Successful applications of INTO-CPS include [47], which uses multi-modeling in the development and optimization of a steering system for a driverless industrial-size lawnmower. Initial models of the kinematics, dynamics, and steering control system are co-simulated to investigate the performance of the controller in a virtual setting. Ref. [48] demonstrates the use of multi-modeling for the design and validation of a robotic assembly line combining models including the robot arm, warehousing, part tracking, production, and order-scheduling human–machine interface. Ref. [49] gives a manufacturing example of the collaborative benefits of using FMI and INTO-CPS. Ref. [12] applied the FMI co-simulation paradigm to support hybrid fire testing and demonstrated results experimentally. As noted above, FMU and co-simulation have been applied to a number of rail applications, including power modeling and driver behavior, as well as software in the loop testing of networked rail systems [50] and digital twins of railway infrastructure [51].

3. Methodology

The above background highlights both the gaps and opportunities for rail co-simulation that draws on the relevant expertise of multiple institutions. While low-TRL demonstrators of rail co-simulation existed [9,41], these did not involve external models by other providers. Including these models, particularly sophisticated timetable and power models would demonstrate the technical and collaborative feasibility of rail co-simulation for power. In this particular case, the institutions involved had knowledge of:

• Rolling stock and traction power supply—Universities of Birmingham and Liverpool—Authors Z.T., X. Lyu, K.J., X. Liu
• Timetabling—Institute of Transport Studies, Leeds University—Authors Z.L., R.L.
• Rail human performance; rail signaling control—Future Mobility Group, Newcastle University—Author D.G.
• FMU integration and co-simulation—School of Computing, Newcastle University—Authors A.B., K.P.

Collaborative integration of each other’s modeling would support mutual knowledge development but come with challenges of establishing common ground and goals. Furthermore, the project was envisaged to be pragmatic, targeted, and achievable in a relatively short duration (up to 6 months). Therefore, the methodology needed to accommodate both consensus building and the technical work required to deliver useful outputs. The methodology was envisaged as the following linear process (see Figure 2):

• Setting aims—The overall aim of the project is established and shared between the project partners. Confirming our relevant areas of expertise and modeling background. Agreeing to model a linear section of track, based on the Merseyrail network with the aim of integrating:

  a.

  Timetable

  b.

  Rolling stock and power modeling

  c.

  Infrastructure models and driver models

  d.

  Integration and co-simulation

  Specifically, the area of the Merseyrail network being covered was from Hamilton Square to West Kirby. This is approximately 14 km with 11 stations, including starting and terminating stations (see Figure 3).

2.

Agreeing approach—In order to scope the work, a Minimum Viable Product (MVP) [52] approach was taken. This would initially involve one train running to one timetable for the specified area of infrastructure. This MVP model would then support elaboration in terms of:

a.

multiple timetables

b.

multiple trains (having more than one train running on the network at the same time and thus exploring train interactions)

c.

different driver profiles

3.

Setting model framework—An initial architecture of models based on prior co-simulation work [9].

4.

Develop timetable—A timetable needed to be generated for the Merseyrail network from Leeds University. A number of variants of the timetable were then generated with different headways.

5.

Tuning the baseline—Integrating the Merseyrail infrastructure (signaling, track distance, speed limits, stations) information and the Leeds-generated timetable into the pre-existing co-simulation from [41].

6.

FMU of rolling stock and power model—Replacing the pre-existing rolling stock and power models from ANNSIM with the more accurate combined rolling stock and power model from Birmingham University.

7.

Running co-simulations—Taking adapted models and running them to generate power outputs. Running co-simulation in different scenarios (timetable variants, multiple trains, and driver variants).

8.

Display outputs—using co-simulation outputs to calculate energy consumption for different simulation scenarios.

4. Base Models

4.1. Initial Rail Infrastructure and Driver Models

The initial architecture of the Newcastle model consisted of four components: a rail infrastructure model (implemented using a single FMU) termed the ‘movement authority model’ as it also embodied a dynamic signaling system that would permit trains to proceed; a driver model (implemented using three FMUs, one for each train); a train model (three FMUs), and a power draw model (a single FMU) recreating the overall draw on the power network. The relationship between these models is shown in Figure 4, and further details are provided in [41].

The source Movement Authority FMU modeled linear track and the four-aspect signaling management system. The Movement Authority inputs the train positions and lengths from the three Train FMUs and outputs the signal aspects, line speeds, and stopping stations of the trains (up to the maximum look ahead distance of the rail network, 3000 m) to their respective Driver FMUs. The area covered by the source model originally used four-aspect signaling. This was captured by the Movement Authority FMU as follows: after a train entered a berth, the signal guarding entry to the berth was changed from a proceed aspect to red. After the train cleared the berth, the aspects of the signals guarding the berths behind the train were changed as follows: red → yellow, yellow → double yellow, and double yellow → green, unless an aspect had been updated by a following train. In this way, it is possible to see effects such as reactionary delay, whereby one train is impeded by a slower-running train ahead [53].

The source driver model was based on [39,54] and driver policy (e.g., what speed to run at when under a double or single yellow aspect). A Driver FMU inputs sequences of signal aspects, line speeds, and stopping stations ahead of the train from the Movement Authority and input the train’s speed and position from the Train FMU. Discrete throttle and brake values, corresponding to a finite number of notch settings, were output to the train to control the train speed and the position at which the train stopped for a red aspect or a stopping station. The braking value required to stop the train was calculated using Newton’s equation of motion (see Equation (1)) and a brake value ↔ deceleration map.

$$\mathit{deceleration}={\displaystyle \frac{{speed}^2}{2\times dist\_to\_stop}}$$

(1)

The driver model was implemented as a finite state machine (see Figure 5) characterized by driving style. That is, parameterized by proportions of maximum braking force and maximum motive force, used respectively for braking and accelerating by a Driver. Thus, at one extreme, a baseline driver brakes hard and accelerates quickly. On the other extreme, a defensive driver brakes gently and accelerates slowly. This kind of difference in driving style is found empirically in the operation of the rail network [32], and defensive driving is often the product of training strategies [33] or driver support programs [19]. The braking parameter was used to calculate the maximum stopping distance of the Driver traveling at the maximum line speed of the network (35 m per second), which was used as the Driver’s look-ahead distance for signals, line speeds, and stopping stations.

The original train model included mass, length, maximum braking force, maximum tractive effort, and friction with the rails. The power draw of the train was output to the Power FMU, which summed the values to calculate the total energy consumption of the three Trains. The original Power FMU was an infrastructure-based model based on a 1.5 kV DC [9].

Both the Movement Authority and the Driver FMUs were discrete-time models implemented in VDM-RT. In contrast, the Train and Power FMUs were continuous-time models implemented in 20-sim. We believe that train movement and power draw are better described by differential equations rather than by discrete mathematics, which requires continuous time and can be emulated by 20-sim.

4.2. Traction Power Model

Train power simulation is physically modeled based on vehicle characteristics and route data, and the model is used to evaluate the dynamic performance of the train under different conditions. The vehicle characteristics include vehicle mass, tractive effort parameters, and Davis constants. These route data include gradient, speed limits, and station positions along the route. Figure 6 describes the structure of the power simulator. The driving strategies are treated as dynamic inputs to the train power simulator. The train power requirement and traction energy consumption can be computed for further studies.

The train movement can be determined by standard Newtonian equations of motion. In the longitudinal direction, the motion of the vehicle is governed by the tractive effort, the gradient, and the vehicle resistance, known as Lomonossoff’s equation [55] (Equation (2)).

$$M_e{\displaystyle \frac{{\mathrm{d}}^{2}s}{\mathrm{d}{t}^2}}=F-Mg\mathrm{s}\mathrm{i}\mathrm{n}\left(\alpha \right)-R$$

(2)

where $M_e$ is the effective mass of the train, $s$ is the displacement of the train along the track, $F$ is the traction force provided by the train’s propulsion system, $M$ is the train’s mass, $g$ is the gravitational acceleration, $\alpha$ is the slope angle of the track, and $R$ is the total resistance, including air resistance, rolling resistance, and other resistive forces.

The power draw of the train is calculated according to Equation (3), and the energy consumed is calculated using Equation (4).

$$P_D=F\times speed$$

(3)

$$E_{total}={\sum }_{t=1}^n\int P_{D}dt/\eta$$

(4)

where $P_D$ is the train’s power draw, $speed$ is the train’s current speed, $E_{total}$ is the total energy consumed by the train during its journey, and $\eta$ is the energy conversion efficiency of the pantograph.

4.3. Timetable Model

We use a continuous TTP model following the work in [22] because of its straightforwardness in representing the essential entities of the problem. The optimization model to minimize the operation time is developed in this research. In this model, in addition to the arrival and departure times of each train at each station, as introduced in Section 2, the immediate precedence of train $i$ to train $j$ on link $l$ is defined by the decision variable $x_{ijl}$.

$$x_{ijl}=\left\{\begin{array}{c}1 if train i immediately precedes train j on link l\hfill \\ 0 otherwise\end{array}\right.$$

(5)

This model incorporates several operational constraints that are defined as follows.

Travel time on links: let $H_{jl}^t$ denote the minimum time needed by train $j$ to travel across link $l$, and let $I_l$ be the set of all trains that pass through link $l$. This constraint can be expressed as follows:

$${in}_{jl}+H_{jl}^t \le {out}_{jl}, \forall j\in I_l \forall l\in L$$

(6)

Waiting time at stations: let $H_{jl}^w$ denote the minimum waiting time required for train $j$ at station $l$.

$${out}_{jl}+H_{jl}^w \le {in}_{jl+1}, \forall j\in I_l\cap I_{l+1} \forall l\in L$$

(7)

Departure-departure headways: let $H_{ijl}^{dd}$ be the minimum departure-departure headway between trains $i$ and $j$ at station $l$ − 1, and let $N$ be a sufficiently large number.

$${in}_{il}+H_{ijl}^{dd} \le {in}_{jl}+\left(1-x_{ijl}\right)N, \forall ⟨i,j⟩\in I_l \forall l\in L$$

(8)

Arrival-arrival headways: let $H_{ijl}^{aa}$ be the minimum arrival-arrival headway between trains $i$ and $j$ at station $l$, and let $N$ be a sufficiently large number.

$${out}_{il}+H_{ijl}^{aa} \le {out}_{jl}+\left(1-x_{ijl}\right)N, \forall ⟨i,j⟩\in I_l \forall l\in L$$

(9)

Unique predecessor: let ${\underset{\_}{i}}_l$ and ${\overline{i}}_l$ be the artificially introduced first and last dummy trains, respectively, on link $l$.

$$\sum _{i:i\ne {\overline{i}}_l}{x}_{ijl}=1,\forall j\in I_l\backslash \left\{{\underset{\_}{i}}_l\right\} \forall l\in L$$

(10)

Unique successor:

$$\sum _{j:j\ne {\underset{\_}{i}}_l}{x}_{ijl}=1,\forall i\in I_l\backslash \left\{{\overline{i}}_l\right\} \forall l\in L$$

(11)

Forbidden overtaking: assume overtaking on a link is now allowed.

$$x_{ijl}=x_{ijl+1},\forall ⟨i,j⟩\in I_l \forall l\in L$$

(12)

In the current stage of this project, the objective function is to minimize the operation time.

$$\mathit{min} {\sum }_{j=1}^I({out}_{j\left|L\right|}-{in}_{j1})$$

(13)

This objective function can be modified to incorporate energy consumption if needed, allowing for an optimized solution that considers both operational time and energy efficiency.

Generating the Timetable for the Use Case Context

The primary objective of our TTP is to minimize the total travel time of trains, aiming to operate them as quickly as possible within the given constraints. However, it is a common phenomenon in train energy efficiency studies that lower operating speeds often result in greater energy efficiency. This creates a fundamental trade-off: an optimized timetable that minimizes travel time does not necessarily align with an energy-efficient operation. Addressing this inconsistency between travel time optimization and energy efficiency is a critical aspect of this work. Specifically, we seek to explore methods and strategies that balance these competing objectives, ensuring that timetable decisions account for both operational efficiency and energy saving.

In this study, multiple timetables with varying travel times and disruption scenarios are designed to evaluate the performance and robustness of the simulation platform. This iterative approach ensures a comprehensive analysis of the platform’s ability to adapt to diverse operational conditions. The process begins with the creation of a basic timetable derived from actual operational data provided by Merseyrail. This baseline serves as a reference point for subsequent modifications and analyses.

To explore the extremes of train performance, the shortest running time for each train between stations is determined by simulating operations at maximum allowable speeds. The resulting timetable, referred to as the “fastest timetable”, represents an idealized scenario with minimal delays and no time supplements. While this timetable minimizes travel times, it is often impractical for real-world operations, as it leaves little room for delays or disruptions.

Building on the fastest timetable, a series of modified timetables are constructed to account for practical constraints and operational flexibility. One such modification includes the addition of a 25% time supplement to the fastest timetable, effectively creating a buffer that accommodates potential delays/disruptions while maintaining overall efficiency. Furthermore, timetables with varying headway intervals—ranging from 3, 5, 10, to 15 min—are generated to examine the impact of train spacing on system performance. These intervals are chosen to reflect a wide spectrum of scheduling scenarios, from tightly packed high-frequency operations to more relaxed, lower-frequency schedules.

Each of these timetables is then applied to the simulation platform under both normal and disrupted conditions to test its capabilities. This involves evaluating how well the platform handles variations in travel times, adapts to delays, and maintains operational stability across different scenarios. By systematically analyzing the performance of the platform with these diverse timetables, this study aims to identify strengths and limitations in the system and inform improvements for real-world railway operations, especially when different timetables are linked with subsequent simulation experiments considering energy saving and other factors that cannot be directly reflected at the TTP modeling stage.

5. Results

5.1. Timetable Outputs

This section presents operational data from Merseyrail, which forms the basis of our timetable simulations.

Table 1. Real operational data of Merseyrail.

Station	Location (km)	Dwelling Time (s)	Running Time (s)	Link Index
Hamilton Square	0	-	-	-
Conway Park	0.72	30	90	1
Birkenhead Park	1.95	30	120	2
Birkenhead North	3.36	120	120	3
Biston	4.96	30	120	4
Leasowe	6.37	30	120	5
Moreton	7.26	30	90	6
Meols	10.11	30	155	7
Manor Road	11.32	30	120	8
Hoylake	12.04	30	90	9
West Kirby	14.06	-	300	10

details the key parameters, including station locations, dwelling times, and running times, essential for building accurate and realistic models.

Based on route and rolling stock data, we derived the Fastest Timetable shown in Figure 7, which optimizes travel times between stations under ideal conditions. To assess the robustness of our timetables against disruptions, we introduced a hypothetical disturbance on link 5. This disturbance requires a minimum running time of 200 s on link 5. We evaluated timetables with time margins of 25%, 50%, and 75%, demonstrating their ability to accommodate unexpected delays without significant rescheduling, as illustrated in Figure 8. Our findings indicate that timetables with larger time margins are more robust, allowing the system to manage disruptions effectively. These results are critical for further research that seeks to balance operational efficiency, timetable stability, and energy consumption within railway networks.

5.2. Integrated System Model

The final architecture of the integrated system model consists of four components: a timetable (implemented using a CSV data file), a rail infrastructure model (implemented using CSV data files and a modified Movement Authority FMU), a driver model (implemented using three modified Driver FMUs), and a combined train and power draw model (implemented using three PhysicsModelV2 FMUs), as shown in Figure 9. The interactions between the FMUs are implemented using their interactions with the Maestro version 1.0.10 co-simulation engine, as shown in Figure 10, which shows the dynamic view. The boxes in Figure 10 are instances of FMUs. Thus, there are three instances of the PhysicsModelV2 FMU and three instances of the Driver FMU, which are paired. There is a single instance of the Movement Authority. While FMUs logically pass data between each other, the Co-Simulation Orchestration Engine (Maestro) manages the exchanges.

The software was run on a SAMSUNG NP700Z5C-S03UK Series 7 Chronos Notebook with an Intel(R) Core(TM) i7-3635QM CPU at 2.40 GHz, and 4 cores, 12 GB RAM, 1 TB SSD (made in China), running a 64-bit Windows 10 Pro operating system.

The timetable is a non-null valued CSV file that defines the arrival and dwell times of three consecutive trains at eleven stations between Hamilton Square and West Kirby (inclusive) on the Merseyrail network in the UK. Different timetables define different constant headways between consecutive trains (e.g., 3, 5, and 10 min), as described in Section 4.3.

The existing Movement Authority FMU was modified to a three-aspect signaling management system, with aspects red, yellow, and green representing the signaling system of Merseyrail. Hence, signal aspect update after a train clears a berth is red → yellow and yellow → green, unless an aspect has been updated by the following train. While exact signal locations were not available, 21 signals were distributed evenly across the modeled area. The Movement Authority passes signals, speed limits, and stations to the driver model, as well as a timetable, from non-null valued CSV files, thereby increasing the flexibility of the FMU in modeling rail infrastructure.

The driver model was extended significantly: (i) to drive the train/power model so that the input timetable is satisfied, and (ii) to handle non-linear driving characteristics of the new train/power model (e.g., non-linear speed/time curve for a given brake value). To satisfy the timetable, a train must stop at each station at the specified time. This requires the train to be traveling at a particular speed at the start of braking, which is a real root of the following cubic polynomial (see Equation (14)). The braking begins when the distance to the stopping point is the maximum stopping distance of the driver.

$${reqd\_speed}^3-6Kgear\times duration\_to\_stop\times reqd\_speed+6Kgear\times dist\_to\_stop$$

(14)

where

$$K={\displaystyle \frac{max\_power\_draw\_of\_train }{mass\_of\_train}}$$

(15)

and gear ∊ [−1, 1] is the brake value determined by the driving style of the driver.

To stop the train at a station according to the timetable, the brake value gear used is:

$$\mathit{gear}={\displaystyle \frac{{speed}^3}{3K(dist\_to\_stop+duration\_to\_stop)}}$$

(16)

To stop the train at a signal at aspect red, the above equation simplifies to:

$$\mathit{gear}={\displaystyle \frac{{speed}^3}{3K\times dist\_to\_stop}}$$

(17)

The continuous gear values are discretized to correspond to the finite number of notch settings that control throttling and braking on trains. The allowance for friction in the driver was removed, as the train/power model does not model friction.

A PhysicsModelV2 FMU implements the train/power (draw) model. The dynamics of a train is modeled by the following non-linear equation.

$$A={\displaystyle \frac{K\times gear}{speed}}$$

(18)

The power model of PhysicsModelV2 is local to the train and is defined by Equation (19). The power draw is integrated over time to calculate the energy consumption of the train. The PhysicsModelV2 does not model friction or gradient (flat terrain).

power_draw_of_train = max_power_draw_of_train × gear

(19)

The complexity of the integrated system model can be understood in terms of the computational complexities of its components: the timetabling algorithm, the Movement Authority, Driver, and PhysicsModelV2 FMUs, and the Maestro version 1.0.10 co-simulation engine.

The Train Timetabling Problem, also referred to as the train scheduling problem, is a well-known NP-hard combinatorial optimization problem. Hence, solving TTP is computationally challenging, especially for large railway networks. The goal is to determine feasible arrival and departure times for trains while satisfying infrastructure constraints (e.g., track capacities and signal blocks) and operational requirements (e.g., train running times and connections). Numerous studies have explored the complexity of TTP, highlighting that even simplified versions—such as single-track scheduling or periodic timetables—remain computationally intractable [29,56]. The combinatorial nature of the problem creates an exponential number of feasible timetables when considering interactions between trains, limited resources (tracks and stations), and safety requirements such as headway times [28]. Consequently, exact methods often struggle to solve real-world instances within a reasonable time, leading to increased interest in heuristic, metaheuristic, and hybrid approaches.

In contrast to TTP, the computational complexity of the co-simulation is P. The Movement Authority execution is O(m²), where m is the maximum number of signals, speed limits, and stations, because of the use of the quicksort algorithm on the sequences of these quantities sorted by their positions. At each co-simulation step, the complexity is O(m₁ × m₂), where m₁ is the number of trains and m₂ is the number of signals, because of checking which signal (if any) has been crossed by a train. At each co-simulation step, the complexity of Driver execution is O(n₁ + n₂ + n₃), where n₁ is the number of signals, n₂ is the number of speed limits, and n₃ is the number of stations, because of checking and extraction from the single event queue associated with these quantities. The complexity of PhysicsModelV2 is O(1). At each fixed time step co-simulation synchronized by Maestro, the complexity of the synchronization is O(p), where p is the total number of input ports of the FMUs.

The co-simulation latency is the fixed time step, which was set at 1 s. Latency within the system model is represented by delays in signaling: (i) the delay between a train entering a berth and the signal guarding entry to the berth changing to red, and (ii) the delay between the train clearing the berth and the guarding signal changing from red to a proceed aspect.

5.3. Co-Simulation Outputs

When running a co-simulation, the INTO-CPS Application generates live graphs showing the changing values of one or more variables in the co-simulation. A screenshot is shown in Figure 11 for the first 300 simulated seconds. The graphs are:

• Graph 1: Position—Here, we see a train moving from 0 m (at rest) to ≈2000 m. The train stops at two stations along the way.
• Graph 2: Next Signal—This shows the signal the driver sees, in this case, a value of 5 that indicates a green aspect.
• Graph 3: Speed—This is the speed of the train (m/s). The train comes up to speed and slows to a stop for each station. Notice the line speed restriction in the first few seconds of the co-simulation.
• Graph 4: Throttle/Brake Set Points—This shows the notched throttle and brake outputs between 0 and 1. Notice there is some oscillation as the algorithm of the driver is discrete-event and acts similarly to a PWM signal to ensure the train stops at the right point and time.
• Graph 5: Energy/Power Draw—This shows the cumulative energy used by the train during the run.
• Graph 6: Move State/Driving State—This is an indication of which mode the driver is in, as seen in Figure 5 (STOPPED, BRAKING, DRIVING).

We then run the co-simulation for longer, with three trains and a marginal headway of five minutes. Critically, we had a realistic functioning signaling system, which did not exist in either the Liverpool model or the Birmingham model, nor had the impact of signal interference been previously factored into the Leeds timetable. We can see that trains experience reactionary delays because of a slower train in front.

This can be seen in Figure 12, which shows annotated plots for position, signal, and speed in the three-train scenario. Here, we observe the second and third trains set off at 300 s and 600 s, respectively. The signal and speed plots show interference between the trains. Specifically, the second and third trains catch up to the first train, meaning that they see a yellow aspect (which has a value of 2 in the signal plot). The speed plot clearly shows that the second train must slow down (at t = 500 s) because of this.

We then ran the three-train co-simulation four times, with combinations of two different driver styles (baseline and defensive) and two different headways (600 s and 300 s). We recorded the power consumption of each train and computed the total energy consumption. The results are shown in

Table 2. Energy consumption of three trains between Hamilton Square and Leasowe with different headways and driving styles.

Energy Consumption (Kilo Watt Hours)	25% Time Margin
	Headway 600 s (10 min)	Headway 300 s (5 min)
Baseline 1	66.2809	66.2809
Baseline 2	66.2808	66.9367
Baseline 3	66.2808	68.6789
Defensive 1	66.2880	66.2880
Defensive 2	66.2741	68.0183
Defensive 3	66.2741	68.0183
Baseline Total	198.84	201.90
Defensive Total	198.84	202.32

. Here, we see that for a 600 s headway (10 min), the trains consume essentially the same amount of energy for a given driving style, and the difference in energy consumption between driving styles is negligible. In this case, there is no interference. The headway is large enough that track sections behind each train are fully cleared before the following train enters, and therefore, each train always sees a green signal.

6. Discussion

6.1. Discussion of Outputs

The aim of the work was to prove that multiple institutions with specialist expertise but using different modeling formats could work together using co-simulation to deliver a working simulation that could generate energy calculations. These calculations reflect different systemic factors, such as different timetabling headways and different driving styles, and thus demonstrate potential systemic interactions. More broadly, it demonstrates the potential of collaborative co-simulation to extend existing simulation work [9,41].

In this regard, the project was successful, with the outputs demonstrated above. This study has developed a physics-based simulation framework to advance train power simulation and energy consumption analysis, which integrates vehicle characteristics, route data, and dynamic driving strategies to enable a more detailed and flexible evaluation of traction energy consumption. By incorporating Newtonian motion equations and Lomonossoff’s equation [55], the model provides a more accurate representation of train dynamics and resistance forces, improving power demand and efficiency predictions. Unlike traditional static models, this approach incorporates real-time driving strategies, allowing for the evaluation of adaptive power control and energy efficiency measures. Additionally, a co-simulation methodology, adapted from the automotive sector, enables multi-institutional collaboration, integrating diverse models into a holistic railway power optimization framework. Designed for scalability, the proposed model can be applied across various railway infrastructures and operational configurations, providing practical insights into power optimization and energy management strategies for real-world rail networks.

The results indicate the power of co-simulation to generate systems results. For example, when the timetable reduces headway to 300 s, we observe interference, as seen above in Figure 12. The result is that the first train consumes the same energy as the previous scenarios, but the second and third trains show higher energy consumption. With the baseline driving style, which accelerates and brakes harder, there is a notable increase in energy consumption of the third train. Here, the train repeatedly catches up to the second train, which slows behind the first train and has to brake. With the defensive driving style in the smaller headway scenario, we observe that both following trains consume the same amount of energy, which sits between the two baseline values. While this makes overall consumption of the defensive drivers greater in this scenario, this may well not play out over a longer stretch of track with more stations.

Notice that it is not our claim that the values of power consumption presented here are realistic or validated. We simply aim to demonstrate that the multi-modeling methodology can be used to combine several heterogeneous models and explore system-level characteristics that cannot be achieved by the models separately.

As important as the technical outputs of the work was the knowledge exchange that resulted from the process of simulation and the subsequent enhancement to each other’s modeling capabilities, as follows.

Timetabling—the inclusion of timetabling expertise enhanced other partners’ understanding of the generation of timetables and the typical constraints that apply. Furthermore, the base simulation of [9] was enhanced so that the driver model had a cognizance of arrival, dwell, and departure times. Conversely, the timetable team gained knowledge of the detailed workings of the signaling system, which could trigger reactionary delays [53], particularly under short headways.

Power modeling—the inclusion of a more accurate train and power model enhanced the fidelity of the overall simulation. Furthermore, the prior work of Birmingham with the Merseyrail system attained accurate knowledge of local infrastructure, stations, line speeds, and (for a future project) gradients. In return, the original rolling stock physical model (Figure 6) used only a simple parameter to reflect driver strategy. As an outcome of this work, the implementation of the strategy was now a dynamic behavioral characteristic moderated by the current status of the train in terms of signal state and line speed.

Driver behavior—as mentioned above, the inclusion of the driver model enhanced the realism of other aspects of the simulation. In return, human modeling was developed to accommodate variable line speeds, react to a timetable, and exhibit realistic behaviors on approach to a station.

6.2. Model Development and Integration

In terms of learning, the integration of the three sets of models—timetable, infrastructure, and driver models, as well as the combined train and power draw model—was unexpectedly complex. This was due to (i) controlling three dependent variables (train speed, position, and arrival time at that position) using a single independent variable (driver throttle/brake value). (ii) The architecture of the train/power draw model was unsuitable for co-simulation. In a co-simulation, the FMUs must interact and are required to conform to the FMI (e.g., they must have a state). In contrast, the train/power draw FMU (PhysicsModelV2) was a standalone function (with no state).

The complexity of the model integration necessitated the incremental development of the FMUs. Hence, the modeling process became non-linear with multiple development/test iterations in comparison to the original plan, as follows: driving to schedule (activity 5) followed by running simulations (activity 7) was performed iteratively to develop the Driver FMU. After that, developing the train/power draw FMU, then driving to schedule, then running simulations (activities 6, 5, and 7, respectively) was iterated to develop the PhysicsModelV2 FMU, which necessitated redevelopment of the Driver FMU. Running simulations tested the FMUs developed by the other two activities.

In terms of increments for model integration, initially, the Merseyrail station data was ‘hard-coded’ in the Movement Authority FMU for simplicity. Signal locations were unknown and were estimated from berth lengths used in [9]. Initially, Merseyrail line speeds were also unknown and were set to 35 m/s. The Movement Authority was modified to use three-aspect signaling. The original Driver, Train, and Power FMUs (described in Section 4.1) were used. The three simulated trains stopped correctly at the modeled Merseyrail stations using Equation (1) in Driver.

In the second increment, a timetable was ‘hard-coded’ into the Movement Authority and passed to a modified Driver FMU. All attempts to introduce timing information into a braking formula (e.g., Equation (1)) in the driver to stop a train at a station at its timetabled arrival time failed to stop the train at the station, as it was traveling too quickly. We hypothesized that since trains can stop at stations without timing information, and the speed/time curve is linear for any given brake value (for the original Train FMU), then if a train’s speed is suitable at the braking point, it should be possible to stop a train at a station at the timetabled arrival time by braking using Equation (1). Thus, the problem of stopping a train at the correct time and the correct place is partitioned into the task of driving the train to arrive at the braking point at the correct speed and then braking normally (without using time information) to arrive at the correct place. This hypothesis turned out to be correct, and the required speed for the original train model is given by Equation (20).

$$reqd\_speed=\left\{\begin{array}{c}deceleration\times duration\_to\_stop-\sqrt{discriminant} if discriminant>0\hfill \\ deceleration\times duration\_to\_stop otherwise\end{array}\right.$$

(20)

where

$$discriminant={deceleration}^2\times {duration\_to\_stop}^2-2\times deceleration\times dist\_to\_stop$$

The third increment involved replacing the ‘hard-coded’ data in the Movement Authority with data in CSV files, including line speed data that had become available by this time. Thus, this data could be passed to the Movement Authority in a pipeline, and no interaction was required. Hence, infrastructure and timetable data generation was not implemented as an FMU.

In subsequent increments, the separate train and power draw models used earlier were replaced by a single combined train/power draw model that was originally implemented in MATLAB. In summary, our attempt to implement FMU export methods for the MATLAB model failed. Next, the model was re-implemented in Simulink, which has an FMU export facility. However, the Simulink FMU export failed to interact with the other FMUs exported from 20-sim, even after the state had been introduced into the model. Therefore, the modified train/power draw model was re-implemented in 20-sim, and the 20-sim FMU export facility was used to generate the PhysicsModelV2 FMU, which interacted successfully with the Driver and Movement Authority FMUs. The speed/time curve for a given throttle/brake value is non-linear in the modified train/power draw model (see Equation (18)). Hence, the driver had to be re-implemented using a new set of driving and braking equations (see Equations (14)–(18)) to achieve semantic integration between the Driver and PhysicsModelV2 FMUs.

6.3. Collaboration

As well as the technical learnings above, it was clear from the execution of the project that much of the management of the project and collaboration with multiple partners with different skillsets and perspectives requires close attention to how people and resources are coordinated. For successful, multi-stakeholder FMU, scheduling is important. This includes extensive time at the beginning of the project for all stakeholders to understand their various expertise, conceptual frameworks, and discrepancies in viewpoints so that there is a mutual understanding of the semantic integration of the models. Furthermore, as described above, scheduling needs to reflect an iterative process of model integration, with cycles of model development and testing as inconsistencies are surfaced and resolved.

To manage the remote collaboration between several teams, it is important to have a designated integrator. This is a single designated person (or small sub-team), ideally with experience in the tools, who is responsible for receiving updated models from collaborators, testing via co-simulation, and giving feedback. This was also found beneficial in previous collaborations. For example, in the iPP4CPPS (integrated Product-Production co-simulation for Cyber–Physical Production System) project [49], several teams worked on models of part of a production line, gradually replacing simple, abstract models with higher-fidelity versions. Having a designated person to perform testing allowed teams to work on different timescales and receive rapid feedback as models evolved. Our experience has confirmed this need for rapid, collaborative iterations in order to manage both technical [7] and conceptual integration.

Another key recommendation is to keep tools up to date. We experienced several problems that were discovered to be due to tool versions being old and not including updates. For example, Java updates yearly and has made several changes to launching native code (required for FMUs) that break backward compatibility. Similarly, the Maestro co-simulation has gone through several major updates that caused our multi-model not to work. Within the multi-modeling setting, there are evolutionary development issues—in the Systems of Systems (SoS) sense—because there are simply more tools that may update on their own timescales and without regard for the multi-modeling community. Therefore, regularly updating tools for all models and the co-simulation engine and performing regular integration testing will minimize the effect that version drift and a sudden breaking of compatibility will cause.

6.4. Limitations

One limitation of the work is that we did not validate the power results of the simulation against any empirical data on energy usage. Our primary aim was to deliver the integrated simulation environment and to understand the path to collaboration and a fully functioning simulation model. The energy outputs presented in Table 2 demonstrate reasonable face validity, but this is only a first step. Future work should ensure these outputs are accurate by comparing the model with rolling stock power outputs or the potentially on-train data recorder logs of control actions to assess the accuracy of the human performance model.

While the modeling is, as we understand, the most sophisticated FMI-based rail model to date, there are also several limitations. The model does not yet have a model of friction, which would be particularly valuable for modeling different rail adhesion conditions. It does not have a gradient model, which would influence power demand when climbing gradients and opportunities to coast when going down a gradient. We modeled three trains, but more trains and a larger infrastructure model may generate more complex performance interactions and reactionary delays.

Finally, our model is deterministic, and it would be useful to integrate a more stochastic element into the model, for example, to recreate minor variations and perform sensitivity analysis. Variations could come from technical variables such as rolling stock performance, boarding time by passengers at stations, fault modeling, or the monitoring of fluctuations in the power supply to the rolling stock.

7. Conclusions

Power draw/energy consumption is a system-level property caused by the activities of system components and their interactions. Modeling and analyzing such properties is the problem domain of multi-modeling and co-simulation. In this paper, we have described and demonstrated the application of collaborative co-simulation, integrating multiple models and different expertise, to generate systems-level outputs. Future work will address the limitations outlined in the discussion section. Going beyond that, producing FMUs for co-simulation is non-trivial but worthwhile. Also, different FMUs can be tightly coupled. Hence, it may be beneficial to design FMUs into layers or sub-components to manage their inter-dependencies. A case in point is the driver model. Separating out

• a control element (how the driver inputs control actions to the train model), and
• a behavioral element (how the driver processes and reacts to information from the infrastructure; the policy for implementing control actions such as driving under yellow aspects or managing station arrival times)

would allow easier and more modular integration with other elements. For example, a future version of the simulation may use another type of rolling stock with a different control architecture. Therefore, the element module could be updated in the driver model without impacting the behavioral element. Extending this principle to other elements of the simulation (e.g., the infrastructure model, the train model) would allow a flexible, extendable approach to tackle a range of power problems in the future. Most critically, we would seek to overlay a realistic traction supply network, including overhead lines and substations, to fully model the effect of multiple trains driving with different styles and strategies, following a variety of timetables.