Decentralised multi-agent coordination for real-time railway traffic management

TL;DR

The paper reframes real-time railway traffic management as a Distributed Constraint Optimisation Problem (DCOP) with trains as agents and path choices as variables, formalised by $\langle A, V, \mathfrak{D}, \mathcal{U}, \eta\rangle$ and utilities $u_r$ and $u_c$. It introduces a decentralised coordination algorithm extending the classical DSA, operating asynchronously with adaptive neighbourhood size to promote convergence and scalability. Through synthetic benchmarks, the approach yields high-quality solutions, rapid convergence, and robustness across varying network sizes and solution counts, outperforming classical DSA in many settings. The work highlights the potential of DCOP-based decentralised coordination for real-time rail networks and other autonomous systems requiring conflict-aware, distributed decision-making, while outlining directions for deadlock analysis and parameter learning.

Abstract

The real-time Railway Traffic Management Problem (rtRTMP) is a challenging optimisation problem in railway transportation. It involves the efficient management of train movements while minimising delay propagation caused by unforeseen perturbations due to, e.g, temporary speed limitations or signal failures. This paper re-frames the rtRTMP as a multi-agent coordination problem and formalises it as a Distributed Constraint Optimisation Problem (DCOP) to explore its potential for decentralised solutions. We propose a novel coordination algorithm that extends the widely known Distributed Stochastic Algorithm (DSA), allowing trains to self-organise and resolve scheduling conflicts. The performance of our algorithm is compared to a classical DSA through extensive simulations on a synthetic dataset reproducing diverse problem configurations. Results show that our approach achieves significant improvements in solution quality and convergence speed, demonstrating its effectiveness and scalability in managing large-scale railway networks. Beyond the railway domain, this framework can have broader applicability in autonomous systems, such as self-driving vehicles or inter-satellite coordination.

Figures (8)

• Figure 1: Distribution of the number of solutions per problem instance. Problem instances are grouped by the number of agents $n$ and by minimum number of solutions $n_{sol}$ we require the problem instance to have. For each combination of $n$ and $n_{sol}$, there are $100$ problem instances in our dataset. As evident from panels in the bottom left of the figure, when we add solutions to a graph $\mathcal{G}_C$ with few nodes, there is a high probability that the links of two solutions can be combined to form new solutions that we have not been explicitly inserted in the graph. This happens less frequently as the number of nodes in $\mathcal{G}_C$ increases.
• Figure 2: Ranking of the solutions given by our algorithm. Data are grouped by the type of agent, by number of agents $n$ and by minimum number of solutions $n_{sol}$ we require the problem instance to have. Bars with label "$1$" represent the fraction of executions that converged to an optimal solution. Bars with label "$\geq 10$" represent the fraction of executions that converged to a solution in position greater than 10 in the ranking. Bars with label "Fail" represent the fraction of executions that exceeded the upper bound of $10^5$ iterations.
• Figure 3: Top: Regret (percentage loss from the optimal solution value) of the solutions given by our algorithm in position 2 or 3 of the ranking. Data are grouped by type of agent, by number of agents $n$ and by minimum number of solutions $n_{sol}$ we require the problem instance to have. Bottom: Average convergence rate to a top-3 solution.
• Figure 4: Distribution of convergence times (in terms of number of iterations) per type of agent on problem instances grouped by number of agents $n$ and by minimum number of solutions $n_{sol}$ we require the problem instance to have. For each of the 100 problem instances characterised by $n$ and $n_{sol}$, we performed $100$ executions of our algorithm for each agent type. Each execution has an upper bound of $10^5$ iterations, beyond which it fails.
• Figure S1: An example of problem instance in our DCOP-based formulation of the dec-rtRTMP. (A) Interaction graph $\mathcal{G}_I$. (B) Constraint graph $\mathcal{G}_C$. (C) Two possible solutions of the problem instance.