TTOBench—an Open-Source Library for Train Trajectory Optimization

Abstract

Over the past few years, the field of train trajectory optimization has been enriched with numerous publications proposing novel solution algorithms, solving known practical problems or applying existing methods to academic and industrial applications. However, the data that were used in the numerical experiments - especially those related to the railway infrastructure - are rarely public, making the comparison of different algorithms or the reproduction of any results difficult if not impossible. In this work, we try to bridge this gap by introducing a library of track data with slope and speed limit information as a first step towards an open-source benchmark suite for train trajectory optimization. The collected items were either publicly available in some form or acquired by the digitalization of published figures. We encourage authors in the field to contribute to this library for the common benefit of the community.

1 Introduction

Train trajectory optimization (TTO), often referred to as energy-efficient train control (EETC) or minium-time train control (MTTC) depending on the objective function of the underlying optimization problem, has been an active topic in the field of transportation research due to its potential to improve driver advisory systems and automatic train operation algorithms. For a recent, comprehensive review the reader is referred to [1]. From early on, numerical methods based on Pontryagin’s maximum principle were used to solve the train control problem, translating the calculation of the optimal trajectories into the computation of switching points between optimal driving regimes [2, 3]. One disadvantage of such methods is that small variations in the problem formulation require expert knowledge to update the solution algorithm, justifying the numerous publications on the topic. Moreover, the set of optimal driving regimes is based on the assumption that the efficiency of the propulsion system is constant. Modelling the nonlinear nature of the power losses gives rise to additional driving regimes (e.g., limited acceleration) and the developed algorithms are no longer applicable [4, 5]. On the contrary, solution methods based on the principle of dynamic programming can elegantly treat such nonlinear models [4, 6]. They are well suited for TTO because the typical problem size (number of states and controls) is small enough to avoid the so-called curse of dimensionality that such methods suffer from. Dynamic programming methods require a computationally intensive initialization step, where the state feedback law is calculated for all points on the discretized state space. It is important to note that updates on problem parameters that would require a new initialization may severely affect the applicability of the algorithm. Recently, direct optimal control methods, which transform the train control problem into a nonlinear programming problem (NLP), also attracted the attention of researchers in the field due to the flexibility they allow in the problem formulation and the availability of reliable NLP solvers. Algorithms based on a special variant of direct transcription methods - the pseudospectral method - were proposed in [7,8,9], while the authors in [10] discretize the optimal control problem using direct multiple shooting.

With so many different methods and software implementations, a convenient framework to compare the performance of different approaches under the same conditions becomes scientifically and practically relevant. In the context of TTO, same conditions imply common track data, train specifications and timetable-related constraints. As the most relevant train and problem data can be typically summarized in a short table, the focus of this paper is on a library of track data, which are are either too lengthy to be part of a scientific publication or kept confidential by the railway companies. The library is hosted on GitHub and contributions that follow the indicated guidelines are always welcome [11]. Finally, we note that the recently published library EETTlib [12], which contains a series of benchmark problems for energy efficient train timetabling, is based on fixed power profiles of trains on track segments and does not provide any information on track characteristics such as gradients and speed limits.

The structure of the paper is as follows: Sect. 2 introduces the TTO problem in continuous space. Section 3 explains the current content and structure of the benchmark library. Section 4 compares three TTO algorithms in terms of energy efficiency on the tracks of the database. Finally, Sect. 5 discusses possible extensions of the library and concludes the paper.

2 Train Trajectory Optimization

Although the track database can be of use in several domains of railway research (e.g., in train simulation software), its creation was motivated by the need for common benchmark examples in the field of TTO. In this section we briefly go through one of the many possible problem formulations with a focus on the parameters that are related to the infrastructure.

Two important classifications of problem formulations arise with the choice of the objective function and the independent variable: time versus energy optimization and time versus space discretization. For the sake of clarity, we will briefly present the train control problem in continuous space. Let us choose as differential states of the train dynamics the elapsed time t in $\textrm{s}$ and the square of the velocity $b:= v^2$ in $\mathrm {m^2/s^2}$. As control input we define the specific electrical force $f^{\text {el}}$, where positive values denote traction and negative values regenerative braking. The term specific is used throughout this section to express the division of the corresponding variable by the total mass of the train $m\rho$, with m the train mass in $\textrm{kg}$ and $\rho$ the dimensionless rotating mass factor. This implies that $f^{\text {el}}$ is expressed in $\mathrm {m/s^2}$ or equivalently $\mathrm {N/kg}$. The other two forces acting on the train are the specific line resistance force $f^{\text {lr}}$, comprising the sum of forces due track slope and curvature, and the specific rolling resistance force $f^{\text {rr}}$, which is typically expressed as a second degree polynomial of the train speed. Since forces due to curvature are almost always ignored in the literature and there is hardly any data available, they are currently not considered in the benchmark library. Positive values of the line resistance imply uphill track sections and negative values downhill track sections. The rolling resistance force is always positive.

Based on these definitions, the acceleration of the train in $\mathrm {m/s}$ is given by Newton’s second law of motion: $a(s):= f^{\text {el}}(s) - f^{\text {rr}}\left( v(s)\right) - f^{\text {lr}}(s),$ and the TTO problem in continuous space can be formulated as follows:

$$\begin{aligned} \underset{t(\cdot ), b(\cdot ), f^{\text {el}}(\cdot )}{\text {minimize}} \;&u \int _{S}^{0} f^{\text {el}}(s) + \frac{p^{\text {loss}}(s)}{v(s)}\text {d}s + (1-u)t(S) \end{aligned}$$

(1a)

$$\begin{aligned} \text {subject to} \;&b^{\prime }(s) = 2\,a(s), \qquad \qquad s \in [0, S], \end{aligned}$$

(1b)

$$\begin{aligned}&t^{\prime }(s) = \frac{1}{\sqrt{b(s)}} \qquad \qquad s \in [0, S], \end{aligned}$$

(1c)

$$\begin{aligned}&\underline{b}(s) \le b(s) \le \bar{b}(s), \qquad \qquad s \in [0, S], \end{aligned}$$

(1d)

$$\begin{aligned}&\underline{f}^{\text {el}} \le f^{\text {el}}(s) \le \bar{f}^{\text {el}}, \qquad \qquad s \in [0, S), \end{aligned}$$

(1e)

$$\begin{aligned}&\underline{p} \le {f}^{\text {el}}(s)\sqrt{b(s)} \le \bar{p}, \qquad \qquad s \in [0, S), \end{aligned}$$

(1f)

with S the length of the track in $\textrm{m}$. Equation (1a) describes the objective to be minimized, with $p^{\textrm{loss}}$ the specific power losses in the traction chain and u a binary variable that is equal to 1 for EETC and 0 for MTTC. Equations (1b) and (1c) enforce the train dynamics, Equation (1d) ensures that the speed limits are respected and Equations (1e) and (1f) summarize the physical constraints of the propulsion system with respect to specific electrical force and power.

The track-related information embedded in Equation (1a) consists of: the track length S, the values of the specific line resistance $f^{\text {lr}}$ and the speed limits $\bar{v}(s):= \sqrt{\left. \bar{b}(s) \right. }$ along the track. With $\theta (s)$ denoting the angle of the track in $\textrm{rad}$, the commonly used track gradient $\textrm{g}(s)$ in ‰ is defined as $\textrm{g}(s):= 10^3\tan (\theta (s))$ and the value of the specific line resistance is given by:

$$\begin{aligned} f^{\text {lr}}(s) = \frac{g}{\rho }\frac{\textrm{g}(s)}{10^3}, \end{aligned}$$

(2)

with g the gravitational acceleration in $\mathrm {m/s^2}$. Equation (2) assumes that for small slopes it holds $\tan (\theta (s)) \approx \sin (\theta (s))$ and (as already mentioned) neglects forces due to curvature. Typically, track data consist of track sections with piece-wise constant gradient, similarly to speed limit values.

Remark 1

Most TTO algorithms assume a point mass model of the train. To avoid speed limit violations, the length of the vehicle should be used in a pre-processing step to transform the speed limits over the track accordingly. Similarly, the track gradients should be adjusted based on the mass distribution of the train [3].

3 Open-source Benchmark Library

In this section, we explain in detail how each track in TTOBench is defined, how the database was created and how it is structured.

3.1 Track Description

Every track in the library is currently defined by a JSON file with the following fields: metadata, altitude, stops, speed limits and gradients. Future extensions of the benchmark library may include further properties, such as curvature information, track gauge or tunnel resistance, which are for the moment not considered due to lack of public data.

• metadata: a dictionary of key-value pairs with general information on the file content. Required fields for a valid track file are id and library version. The id is a unique identifier that should contain only letters, numbers and underscores. If applicable, the first part of the id followed by an underscore shall indicate the country of origin via the ISO Country Code. Otherwise, the prefix 00 shall be used. The library version is necessary for compatibility purposes, in case there are changes in the library format. The optional fields at the time of writing are: description (information about the track in plain text), created by (author of the file) and license (to indicate the terms of use in case the file is distributed outside the library).

• altitude: altitude at beginning of track. This field is optional and may be used in combination with the gradients to plot the altitude profile of the complete track.

• stops: a list of positions on track where stops are located. The first element of the list must be equal to 0 and the remaining positions should follow a strictly increasing order. The last element of the list indicates the length of the track S. Optimized trajectories may be derived from any departure to any destination point in the list.

• speed limits: a list of pairs - position, speed limit - indicating the beginnings of track sections and their respective velocity restrictions. The positions must be strictly increasing and every speed limit should be different than its predecessor (otherwise there would be no need to add this pair in the list). The position of the first pair should be 0 and the position of the last pair cannot exceed the length of the track.

• gradients: a list of pairs - position, gradient - indicating the beginnings of track sections and their respective (approximately constant) slope. The positions must be strictly increasing and every gradient should be different than its predecessor. Positive and negative gradient values indicate uphill and downhill sections respectively. The position of the first pair should be 0 and the position of the last pair cannot exceed the length of the track. The field can be omitted for level tracks.

To improve the readability and ease the interpretation of the track files, every field (except for the metadata) contains all the information about the units. Currently, the positions are expressed in $\textrm{m}$, the speed limits in $\mathrm {km/h}$ and the gradients in ‰. Note that the positions of speed limits and gradients will in general not coincide and a preprocessing step to derive track sections with constant properties is necessary in the context of trajectory optimization. This representation, however, makes a clear distinction between points with a speed limit change and points with a slope change and simplifies the interpretation of the track properties. The details of the JSON files are summarized in Table 1 and a simple example of a JSON file is provided in Appendix. The use of $\mathrm {km/h}$ over the SI unit of $\mathrm {m/s}$ is adopted to ensure that the speed limits can be represented by integer values.

Table 1 Properties of tracks in the database (library version 1.1)

To fully define the track properties of a specific numerical simulation, some additional parameters may need to be specified. We propose to use a configuration file (also in JSON format) defining upon loading of a track the following fields:

• id: the ID of the track to be used in the simulation.

• from: index of departure station. 0 if not specified.

• to: index of destination station. Last stop if not specified.

3.2 Data Sources

Every track in the benchmark library comes from a scientific publication. We distinguish between the following cases among which the data has become available:

• P for public: track information is already publicly available in digital form. Only re-formatting to JSON was necessary.

• D for described: the scientific publication contains enough information to accurately reconstruct the track.

• I for illustrated: the track is reconstructed only approximately, by digitalizing the figure of a publication with an online tool (WebPlotDigitalizer [13]).

An example of the digitalization process is shown in Fig. 1.

Fig. 1

On the top: original plot from [14] being processed with WebPlotDigitizer. On the bottom: approximate benchmark example imported to database

3.3 Content and Structure

The benchmark instances that were collected from the recent literature in TTO are listed in Table 2, together with some of their key properties. TTOBench, which is freely available on GitHub [11], includes both simple benchmark examples as well as real-world track data and it consists of the following files:

• JSON files with track data.

• README files with instructions and references.

• Python files with auxiliary functions (e.g., checking the validity of a track).

• License file (BSD2, which is one of the most permissive licenses).

Table 2 Collected benchmark examples in alphabetical order (library version 1.1)

An interface to import track data to (or export data from) Python has been added to our recently published code in [24], such that the provided optimization framework can be used in combination with TTOBench. We encourage authors in the field to contribute to the benchmark library in form of pull requests to the GitHub repository. The contributions could for example consist of: new tracks, improvement of digitalized tracks or extension of the list of references.

4 Numerical Simulations

To demonstrate a typical use case of the benchmark library, we compare the performance of three TTO algorithms in terms of energy consumption on every track of the database. The optimization is performed on the complete length of the track, neglecting intermediate stops. The train specifications, adapted from [15], are summarized on Table 3. The constant efficiency factor $\eta = 0.7$ implies that the function of specific power losses in Eq. (1a) is defined as:

$$p^{\textrm{loss}}(s) = \left\{ \begin{array}{ll} \frac{1-\eta }{\eta } f^{\text{el}}(s)v(s),{} & {} \text{if}\;\; f^{\text{el}}(s) \ge 0, \\ \eta f^{\text{el}}(s)v(s),{} & {} \text{otherwise}. \end{array} \right.$$

(3)

Table 3 Train specifications NS Intercity VIRM-6 [15]

4.1 Trajectory Calculation

The optimal control problems are discretized with direct multiple shooting and solved with an interior point method [10, 24]. Three problem formulations are considered:

• MTTC: minimum-time train control problem, i.e., train must arrive as fast as possible. The optimal trajectories contain only maximum acceleration, cruising and maximum braking. Yields the highest possible energy consumption. The maximum travel time of the other two methods is equal to the travel time of MTTC plus an additional $15\%$ time reserve.

• RMS: reduced maximum speed. With this heuristic method, the maximum allowed speed of the train is iteratively reduced until the MTTC trajectory reaches the maximum allowed travel time (with a tolerance of $0.5\,\textrm{s}$). The optimal control regimes are again maximum acceleration, cruising and maximum braking.

• EETC: energy-efficient train control problem, i.e., train must arrive using the least possible energy. Under the assumption of constant efficiency, the optimal trajectories consist of maximum acceleration, cruising, coasting and maximum braking, arriving at the destination as late as possible.

4.2 Benchmark Results

The optimal speed profiles and respective electrical force at the wheel are shown in Figs. 2, 3, and 4, while the results are summarized on Table 4.

Fig. 2

Time-optimal (red), reduced-maximum-speed (blue) and energy-optimal (green) trajectories on benchmark problems with varying speed limits (purple) on level track

Fig. 3

Time-optimal (red), reduced-maximum-speed (blue) and energy-optimal (green) trajectories on benchmark problems with varying gradients (gray) and constant speed limit

Fig. 4

Time-optimal (red), reduced-maximum-speed (blue) and energy-optimal (green) trajectories on benchmark problems with varying speed limits (purple) and gradients (altitude profile in gray)

Table 4 Travel time and energy consumption of intercity train on different tracks

Figure 2 contains trajectories on level track with varying speed limits. The RMS algorithm reduces the total energy consumption by $26\%$ on average with respect to the worst-case scenario (MTTC), while the EETC trajectories bring an additional $5\%$ improvement.

Figure 3 depicts the trajectories on the tracks with constant speed limit and varying gradients. Here, the situation is fairly similar: the RMS algorithm reduces the energy consumption by $21\%$ on average and the EETC algorithm by another $5\%$.

Based on the simple benchmark examples of Figs. 2 and 3, one could draw the conclusion that the additional benefit of EETC with respect to the RMS method is rather limited. However, the results change significantly once realistic tracks with varying speed limits and gradients are considered. According to Table 4, the RMS trajectories in Fig. 4 reduce the total energy consumption by $23\%$, yet the EETC algorithm brings an additional improvement of $28\%$.

5 Conclusion

This paper presents an effort to improve the data availability in the field of TTO, since we believe that repeatability of the results of publications in the field is an essential step for the derivation of better algorithms and software.

As a first step towards a comprehensive benchmark library, we provide a database of track infrastructure data including gradients and speed limits. We envision that the content of TTOBench will grow further than that, steered by the interest and participation of the community. In the list below, we summarize the content of the library at the time of writing, a tentative collection of future features and what is currently considered out of scope:

• Current status: version 1.1 of TTOBench provides a detailed description of track-related information in JSON. 15 tracks have been collected from the literature and brought into this format to enable easier benchmarking of different TTO algorithms.

• Future extensions: the structure of the JSON files has been carefully designed to allow for straightforward extensions in the near future. Trains shall be also described by means of comprehensive JSON files, a library of trains used in scientific papers or published by train manufacturers shall be collected and the track description shall be populated with more fields (e.g., curvature and tunnel information). Finally, other relevant information, such as timetable and weather data, shall be additionally described in JSON to complete the definition of elements that may play a role in TTO.

• Out of scope: although we recognize the relevance of interconnections between tracks and interlocking information in the field of TTO, we consider these categories to be out of the current scope of the library.

Appendix. JSON File Example

An example of a JSON file describing a 10-$\textrm{km}$-long track with one speed limit change and one gradient change is shown in Listing 1. The speed limit is decreased from $140~\mathrm {km/h}$ to $100~\mathrm {km/h}$ in the middle of the track and a positive (i.e., uphill) slope of $10\permille$ starts $2~\textrm{km}$ before the end of the track.

Listing 1

JSON file example of a simple track