Moving Block + UTO: Rail signals enforce fixed block on bidirectional sections despite --railsignal-moving-block

[MHorsthemke]

Context

Basis_Scenario_U4_running.zip

This issue is related to #16855 (railway switches and moving block behavior).

I am building a simulation of a highly automated subway line with UTO (Unattended Train Operation) in a CBTC environment, where Moving Block is the primary safety system.

Problem

When using --railsignal-moving-block, safety function a) (block section guarding for distance keeping) is correctly disabled, as described in the documentation. However, safety function c) — guarding bidirectional sections against head-on collisions — remains active and is still enforced by rail signals.

In my simulation, this causes rail signals to turn red at reversing sections in order to protect the bidirectional used track. This leads to train queues and congestion when the simulation is run at scale (e.g., headway factor 100), because trains are held at the signal even though Moving Block should be handling all spacing and safety functions.

Additionally, it seems that rail signals are required for the simulation to run at all — removing them causes the simulation to fail or produce incorrect behavior. This creates a dependency on fixed-block infrastructure that contradicts the intent of Moving Block operation.

Expected Behavior (Real World)

In a real CBTC / UTO environment:

• Moving Block handles all safety-relevant spacing and collision avoidance — including on bidirectional sections.
• In full UTO operation, wayside signals are operationally irrelevant and would not impose any movement authorities on a regular basis.

Current Behavior in SUMO

• --railsignal-moving-block disables function a) as documented.
• Function c) still causes signals to turn red on bidirectional sections, blocking trains even in Moving Block mode.
• The simulation appears to require rail signals to function correctly, making it impossible to model a purely Moving Block / CBTC system without fixed-block side effects.

Question / Feature Request

Is there a way to:

1. Fully disable rail signal enforcement (including function c) on specific sections or globally, to simulate a pure CBTC Moving Block environment?
2. Additionaly: configure signals so that in Moving Block mode, bidirectional section protection is handled by the Rail carFollowModel rather than by signal states? Alternatively would it be nice, if there is an option for MovingBlock mode, to disable safety functions manualy. So that users can decide if safety function an and c should be disabled.

I will attach my scenario as a ZIP file for reference.

Thank you!

[MHorsthemke]

Here a test for understanding the Moving Block issue. It is also attached in a zip:

Scenario:

• Two tracks with a shared single-track section in the middle
• Different train speeds
• No rail signals are used (simulation equal to UTO)
• Rail signal moving block is set in sumocfg
• Schematic representation of the track used: Edges contain an explicit distance,
  which differs from the displayed geometry
• Two routes are used
• Two trains with different departure times are defined for each route
• Only one train is used on each track in the simulation

Problems:

• Trains collide. It seems, that safety function c) guarding bidirectional sections against head-on collisions is not properly working in scenarios without railsignals (same could be for saftyfunktion b) and d), but that was not testet)

sumo_rail_04_20260227.zip

• In the simulation GUI, trains are not displayed scaled according to the track (visually too large); "Scale length with geometry" does not work (problems sees close to rail carriages are still scaled when disabling 'scale length with geometry' #11576)

I will attach my scenario as a ZIP file for reference.

Thank you!

[namdre]

I think there is a misunderstanding about UTO-modeling in SUMO and I'll try to clarify.

Any kind of safety system must prevent simultaneous entry onto the same track from different sides (for vehicles that intend to traverse the full length of the track). Operationally, this will result in vehicles occasionally stopping and waiting before entering a conflict section. in SUMO, there is only a single system that achieves this behavior and it is implemented with rail signals.

There exist other safety systems that do not require rail signals and exhibit the same behavior.
The design goal of SUMO is to be able to replicate the vehicle behavior of these systems.
The following things are potential design goals of SUMO

• replicating the visual appearance of systems without rail signals (this could be accomplished by optionally hiding some or all rail signals with some additional configuration features, yet to be implemented)
• replicating the convenience of achieving the safety aspects of such as system without the need to manually place rail signals at both sides of a bidirectional section. This is mostly achievable with a pre-processing tool: https://sumo.dlr.de/docs/Tools/Railways.html#patchrailconflictspy

In the following I'll address specific points you raised:

Additionally, it seems that rail signals are required for the simulation to run at all — removing them causes the simulation to fail or produce incorrect behavior. This creates a dependency on fixed-block infrastructure that contradicts the intent of Moving Block operation.

Yes. Rail signals are required for safety functions at bidirectional tracks (flanking conflicts can also be handled with zipper junctions).
This requires far fewer rail signals than regular train operations and only serves the purpose of declaring conflict points for the internal conflict resolution logic (which would exist in any safety system even if you don't see signals). The behavioral goal of achieving short headways in train following, which is a key concern of moving block operations, is fully achievable.

In my simulation, this causes rail signals to turn red at reversing sections in order to protect the bidirectional used track. This leads to train queues and congestion when the simulation is run at scale (e.g., headway factor 100), because trains are held at the signal even though Moving Block should be handling all spacing and safety functions.

To me this is the key concern: Your observation potentially reveals a bug or limitation in the current rail signal implementation. In moving block mode, signals should only restrict train movement if this is necessary to avoid a collision. Please provide a minimal example scenario and a detailed description (vehicle id and time stamp) of train movements that are expected and safe but prevented by a rail signal.

In the simulation GUI, trains are not displayed scaled according to the track (visually too large)

The scaling issue in the linked ticket only concerns issues with abstract networks and length-geometry-mismatch. In your networks the lengths match the edge geometries and the trains are simply as long as their vType defines it. Please describe in more detail how the current visualization differs from your expectation.

Only one train is used on each track in the simulation

In the scenario you provided in sumo_rail_04_20260227.zip, your input defines 2 trains per route for a total of 4 trains. What is the expected behavior for the pair of trains that share the same route? Since the network does not provide a way for them to pass each other, they cannot run at the same time.

[MHorsthemke]

Thank you for the detailed clarification — this is very helpful.

Regarding the signal-based approach:

Thank you for confirming that rail signals are currently the only mechanism in SUMO for resolving bidirectional track conflicts (safety function c). I assume this architectural decision will remain in place going forward — is that correct? From a conceptual standpoint, route-based conflict resolution via Moving Block would be a valid approach in real-world CBTC systems. However, I understand that SUMO implements this through auxiliary signals, and that the resulting vehicle behavior should be functionally equivalent. I just wanted to confirm my understanding.

Correction — scale factor, not headway factor:

I need to correct a mistake in my original post: I was referring to the scale factor (vehicle count multiplier), not the headway factor. Apologies for the confusion.

Regarding the congestion issue (Basis_Scenario_U4_running.zip):

Basis_Scenario_U4_running.zip

I have simplified the scenario to better demonstrate the problem: the scale factor (for vehicles) is set to 100. The congestion occurs specifically at the reversing tracks. The scenario serves as a line capacity test, designed to reveal exactly these kinds of bottlenecks. Rather than isolating a single vehicle ID and timestamp, the purpose is to demonstrate the systemic issue: in Moving Block mode, safety function c) is not handled natively, which means that without manually placed auxiliary signals, congestion builds up at bidirectional sections. This is the core problem I wanted to illustrate — the "incomplete" Moving Block behavior in SUMO.

As you explained, the current solution would be to place auxiliary signals at the appropriate positions to ensure safety function c) is enforced up to the switches at the reversing tracks. I understand that this is not something SUMO aims to handle automatically via Moving Block — is that correct?

That said, I would like to express this as a feature wish: in a digital twin development context, manually placing auxiliary signals at all bidirectional conflict points is an intensive process. It would be very helpful if Moving Block mode could optionally handle safety function c) natively, without requiring manual signal placement. (Same for safety function b and d.)

Regarding patchrailconflicts.py:

Thank you for pointing out this tool — I will evaluate whether it can address the signal placement needs in my scenario.

Regarding Scenario 4:

In the previously posted sumo_rail_04, I defined 2 trains per route (4 total), but only one per route actually runs since the track is never free for the second. I have since removed the second vehicle per route to provide a truly minimal example:

sumo_rail_04_02_20260227.zip

In this minimal scenario, trains on different routes collide at timestep 642, which demonstrates that safety function c) is not provided by Moving Block in the absence of rail signals. This is the issue I wanted to highlight.

I was also able to resolve some issues myself: in sumo_rail_04, I incorrectly used the distance attribute to define edge length. The corrected version (sumo_rail_04_2) uses length instead, which is the parameter actually used by the simulation.

[namdre]

Thank you for confirming that rail signals are currently the only mechanism in SUMO for resolving bidirectional track conflicts (safety function c). I assume this architectural decision will remain in place going forward — is that correct? From a conceptual standpoint, route-based conflict resolution via Moving Block would be a valid approach in real-world CBTC systems. However, I understand that SUMO implements this through auxiliary signals, and that the resulting vehicle behavior should be functionally equivalent. I just wanted to confirm my understanding.

Yes. This architectural decision is likely to remain functional going forward. Support for the use case of simulating railway systems without signals, is likely to come in the shape mentioned above: improving automated signal placement and optionally hiding them from view.
In a sense, the current implementation of conflict resolution is closer to a "route-based conflict resolution via Moving Block" then to a traditional block based system insofar that each rail signal will switch to green as soon as the routes are not in conflict anymore. This would correspond to a very tight placement of block-free-detection infrastructure (i.e. axle counters) which certainly is not available everywhere. Manually overriding the placement of this detection infrastructure is planned for the future.

Thank you for pointing out this tool — I will evaluate whether it can address the signal placement needs in my scenario.

I advise to update to the latest development version to profit from recent fixes to the tool (https://sumo.dlr.de/docs/ChangeLog.html#bugfixes) Please let me know if the tool does not solve the targeted problem.

In this minimal scenario, trains on different routes collide at timestep 642, which demonstrates that safety function c) is not provided by Moving Block in the absence of rail signals. This is the issue I wanted to highlight.

I confirm that this is working as designed.

Correction — scale factor, not headway factor: I need to correct a mistake in my original post: I was referring to the scale factor (vehicle count multiplier), not the headway factor. Apologies for the confusion.

The linked ticket #11576 refers to a third meaning of "scale": visual scaling. If there are any remaining issues with either meaning of scale, please clarify the misbehavior.