meta: stdcm: things to do

[eckter]

This is a collection of tasks to do related to STDCM. If anyone wants to pick something to get started and learn how it works, feel free to convert an item to an issue and assign it to yourself, and ask me any question you may have.

It's a work in progress and gets edited quite often.

General

• [x] Migrate the whole module in kotlin
• [x] Use the kotlin infra
• [x] https://github.com/osrd-project/osrd/issues/4484
• [x] Let the user set the max running time
• [ ] Handle routing conflicts
  • For now only spacing conflicts are considered
  • Routing conflicts can be added somehow easily, but for now the performance cost would be too high, we're waiting for the optimizations
• [x] Update the website documentation to account for the conflict detection integration
• [ ] Let the user specify an arrival time rather than a departure time: to be refined
  • We can let the user enter a time window for the arrival time, and still look for the earliest time
• [ ] Handle trains that turn around in a station
  • This requires a lot of refactoring in all part of the project, but it needs to be done eventually
  • https://github.com/osrd-project/osrd-confidential/issues/604
  • https://github.com/osrd-project/osrd-confidential/issues/325

Stops

Note: most of them will require extra parameters for each stop. Ideally it would take some UX planning from the start, I don't think adding one field at a time would lead to a good result.

• [ ] A stop needs to be lengthened when we need to add delay after the stop. For now the stop duration is fixed.: https://github.com/osrd-project/osrd-confidential/issues/485
• [ ] We could set a time window any step, including first and last (eg. must arrive after 10:00 AM and leave before 12:00). This could replace the "arrival time" parameter and would be a nicer generalization, but the front-end / UX would be more complex.
• [ ] Add stops to be overtaken by other trains: https://github.com/osrd-project/osrd-confidential/issues/338

Bugs

See: https://github.com/orgs/osrd-project/projects/15/views/5. Anything that affects the envelopes, running time calculation, signaling or pathfinding will also affect STDCM requests. There are a few STDCM-specific bugs, but most are just running-time bugs that happen much more often in this context.

Removing the use of floats would significantly improve the reliability of the whole process.

Tests / stability

• [x] We need at least one test on an imported infra, including performance checks. Doesn't need to be part of the CI.
• [x] The fuzzer could be modified to have reproducible STDCM tests on reproducible schedules
• [x] We need to add some tests on a large imported infra, including some performance checks (reasonable timeout)
• [ ] We need an extensive validation of the results: it's mandatory before it's actually used by clients, but in the meanwhile it makes testing much easier (especially with fuzzer)
  • To be refined: we already run a fair amount of validation, but not enough to trust all results with no double-check

Performances

It's probably still too early for extensive optimizations, but it will be important later on.

• [x] Find a way to measure, monitor and benchmark execution time
• [x] Engineering allowances are extremely expensive: we could lower the accuracy, and/or use lazy evaluation
• [x] https://github.com/osrd-project/osrd/issues/6132
• [x] #6605
• [x] https://github.com/osrd-project/osrd/issues/6917

Possible refactoring

These suggestions aren't well refined, just things we could eventually look into

1. Split the generic Pathfinding.kt into two versions for stdcm / block pathfinding
   1. It would remove clutter to the main class and enable for more flexibility, including significant optimization paths
   2. It would also lead to code duplication and a need for more unit tests
   3. https://github.com/osrd-project/osrd/issues/6917
      1. This is necessary to handle engineering allowances in a reasonable time
      2. Depending on the approximations made here, the post-processing may fail, we may have to "blacklist" block openings and re-run a pathfinding

Eventual rewrite

The current implementation is just a proof of concept, we mostly check that our solutions actually work but it's not meant to last forever. The way it's written has blurry interfaces and flexible components that evolve over time to iterate quickly, but that kind of architecture can turn into a mess and isn't fit for a long-lasting solution. We tried to think about most future problems from the start, but we did have to re-think a few things along the way when adding new features. Some future features don't have a very precise plan.

We should keep this in mind, but even if I may have said otherwise in the last few days (IRL), I think it's too early to start working on this now. There are still some very complex features that are not implemented yet and we don't have clear plan for them. Implementing those will likely require a few changes, and we need to have a precise solution before starting the rewrite. The biggest one is the "lookahead problem" (explained here in French, not translated yet). We also need to find a good way to stop on secondary tracks to avoid conflicts.

Additionally, the rewrite would ideally be in rust. This requires migrating almost everything that's written in java/kt first.

[axrolld]

Isn't Use the kotlin infra done by now ?