Conflict detection

[eckter]

Conflicts happen when trains are scheduled too close to each other and one train needs to slow down because of an other.

The way we originally intended to detect this is by using signal updates sent from the core, the ones displayed in the space time graphic. A conflict happens when the same signal has overlapping constraints from different trains. The reason for this choice is to rely on completely generic signalization modules.

There are two problems with this approach:

1. In some edge cases, there can be conflicts caused by signals that are never actually seen, outside of the train path
2. The core only reports signal aspect updates, nothing is reported when we add a constraint on a red aspect. This can cause undetected conflicts in parallel paths

There is no easy solution. One possible method to solve this is to stop doing standalone simulation and run simulations with every train on the same infra. But we still need the trains to ignore each other and possibly overlap, which may not be possible in this setting.

A temporary fix to both problems could be to only detect and report conflicts on the projected path, but this isn't good enough long-term.

[eckter]

The following case can't be done with just signal changes from standalone simulation:

        ->
--------C1-----+-------------S1------>
                \
        ->       \
--------C3--------+----------S3------>

A train going trough the bottom track should block the top track as they share a section. But since C1 is red by default and remain red, no update is reported.

[eckter]

In this (far-fetched) setup, if we ignore the problem with unreported aspects mentioned above, a false positive would be detected:

    ->
----C1--------------------------------------->
        \        \        \        \
         \        \        \        \
         C2       C3       C4        C5
           \        \        \        \
----------------C7-------C8-------C9-------C10---------------------->
                ->       ->       ->       ->

Two trains could follow each other on the bottom track with a normal BAL3 cascade of aspects and no conflicts, but they would both make C1 display a warning at the same time, causing a "conflict"

[eckter]

A solution could be to wait for the new simulation model, and handle routing and spacing separately.

The problem with signals that are not updated comes from signals that are red by default. But this is caused by controlled routes. If we "force" all routes to be open in standalone simulations, we wouldn't have this problem. We would then handle route conflicts separately