openrailassociation / osrd Goto Github PK

It wasn't automatically checked for a while, so style errors have accumulated. Especially in the test files.

Create an endpoint to check if an infrastructure is valid:

We could check the following things:

• The infrastructure is consistent (no references to objects that doesn't exists)
• No cyclic dependency between the signals
• The warning signals are spaced far enough apart to allow the train to slow down in extreme cases.

Currently, the path a train follows does not take in account stops, nor signaling system changes
the path of a train on the track section graph is implicit : it's guided by the routes it takes

Add primitives to simplify railscript

• Add signal list for routes.
  • Add it to the infra.
  • Add it in railjson.
  • Parse it from railml.
• Add Optional type
• Add reserved_route(Signal) -> Optional<Route> primitive
• Add next_signal(Signal, Route) -> Optional<Signal> primitive

Example of matched Optional:

match Some("test") {
    Some(signal): AspectSet { GREEN },
    None: AspectSet { RED }
}

match reserved_route(current_signal) {
    Some(route): AspectSet {
        match next_signal(current_signal) {
            Some(signal): AspectSet {
                GREEN,
                YELLOW if signal_has_aspect(signal, RED)
            },
            None: AspectSet { YELLOW }
        }
    },
    None: AspectSet { RED }
}

For example, releaseGroups in Route should probably be a set. This makes the code more readable.

Currently, to start a simulation, OSRD needs:

• an infrastructure file
• a rolling stock file per train type
• a schedule

It'd be quite a bit fancier to be able to start a simulation from a single API call, once the infrastructure is loaded. We could put the rolling stocks and schedule in the same JSON parameter file, as neither really need to be persistent in the backend (both are pretty small)

Currently, it uses the same base code as the track section graph, where neighbors are stored on each ends of edges. this is pretty wrong : the pathfinding algorithm does extra work for nothing

If a field is missing, has the wrong name, or an object is generally not properly formed, we end up with an obscure NullPointerException or similar. It would be better to have a clear error, something like "missing field foo in object bar".

https://github.com/DGEXSolutions/osrd-core/blob/dev/src/main/java/fr/sncf/osrd/infra_state/RouteState.java#L131-L141

This was a workaround not to make trains appear on non-reserved routes, but it can cause bugs when a train is created after t=0 as we also force switch positions with no delay.

• Make an explicit list of the inputs required to make the position of the train evolve
• Move the simulation loop in a separate class
• Try to make an alternate simulator which uses an approximate analytical method (it can be done easily by ignoring slope)
• Design an interface which would work for simulating extra parameters, like train battery charge
• Make a remote control API, which would enable manual control of trains using a video game UI

This work touches two major components:

• the integrator
• the driver decision making process

The tiny simulation example renegates 60 changes, which sounds like a bit much. It can be optimized:

• route and tvd section state changes account for most of the noise. Consider bundling changes together.

• Add slope in railjson
• Add circular curve into TrainPhysicsIntegrator.make
• Inject slope in TrackSection.slope
• Parse slope from railml
• Parse slope from rsl

 "track_sections": [
  {
    "id": "my_track_section",
    "slope": [
        {
          "begin": 0,
          "end": 1000,
          "gradient": 10
        }
     ],
     "curve": [
        {
          "begin": 0,
          "end": 1000,
          "radius": 10
        }
     ]
  }
]

This is needed to find the starting point / end point when finding paths

RailML3 isn't yet good enough for simulation

https://wiki3.railml.org/wiki/IL:hasAspect
https://wiki3.railml.org/wiki/IL:signalIL/3.2

compute the margin on distance only on the phase range

This interface should be easily exportable over the network, so that other programs can be used to control trains

cause by candidatePaths.add(pathsToGoal.get(pathsToGoal.size() - 1)); when pathsToGoal is empty

We need to rework the phases as it has become an accumulation of too many things.

• Separate train path
  • Create another class containing the whole path
  • Move all relevant methods from SignalNavigatePhase
• Separate margin limits
  • Add a parameter for margin begin and end positions relative to the full train path
• Move SpeedInstruction instance to TrainSchedule
• Create an alternative for stops
  • Create a list of stops
  • Add configs to the schedule
  • Replace the EndOfPhase event
• Improve Phase interface for an easier integration of mobile block
  • Create new evolveUntilTimeOrPosition function in TrainState

https://github.com/DGEXSolutions/osrd-core/blob/add-phase-tests/src/test/java/fr/sncf/osrd/train/PasesTest.java#L42-L79

https://github.com/DGEXSolutions/osrd-core/blob/add-phase-tests/src/test/java/fr/sncf/osrd/train/PasesTest.java#L81-L102

It seems that trains don't "see" signals in another phase until they enter in that phase.

RJSRoute has an attribute transitType that must be filled in when parsing RailML.

https://github.com/DGEXSolutions/osrd-core/blob/0d32eb63a9168778ab31e69120076d889463f43f/src/main/java/fr/sncf/osrd/railml/RMLRoute.java#L60-L62

In the current implementation, the end of phase is detected with an interaction on the path. But if we reach a stop slightly earlier, it's not reached and the event doesn't happen. We need to improve this behavior.

nor a default exists

https://developers.google.com/blockly

This happens when integrating the phases system with front-end (@flomonster middle-end branch)

There is also a problem with a route being reserved and occupied at the same time on the same infra.

The end user selects a starting point, an end point, and expects a path to be found.
This can be done ahead of time in the route graph.

inputs:

• some infrastructure
• a start and end operational point

output:

• a route path from the infrastructure

Another endpoint will be needed to get the track section a route goes through.

Change pathfinding/routes endpoint response with the following format:

{
  "path": [
    {
    "route": "route_id_1",
    "track_sections": [{"track_section": "track_id_1", "begin": 30, "end": 45}]
    },
    {
    "route": "route_id_2",
    "track_sections": [{"track_section": "track_id_2", "begin": 30, "end": 45}]
    }
  ],
  "operational_points": [
    {
      "op": "my_operational_point_1",
      "position": {"track_section": "track_1", "offset": 50}
    }
  ]
}

Trains should activate routes as they go

Portions of track are exclusively allocated to the train :

• routes
• ERTMS MA

These must be stored for sending to the frontend

Implement the rsl to railJSON parser to support this format.

Directional train detectors must be handled :

• Parse from RailML
• Modify WaypointGraph construction (It might become a directional graph...)

https://github.com/DGEXSolutions/osrd-core/blob/0d32eb63a9168778ab31e69120076d889463f43f/src/main/java/fr/sncf/osrd/railml/RMLTrainDetectionElement.java#L31-L33

https://medium.com/@dbottillo/how-to-write-a-custom-rule-in-lint-d2395d88c8c2

Some of the simulation APIs can easily be misused. This could be proactively prevented by writing proper checks ahead of time:

• changes should be published once applied
• timeline events can only be created, identified using nextEventId and inserted on the timeline using scheduleEvent in a class which implements Change
• the constructor of TimelineEvent subclasses must be private, as these should be created in a change (which can have access to the private constructor)

When a switch moves, routes are kept in a requested but not yet locked state
TODO:

• add the position_change_delay field to RailJSON
• add the REQUESTED RouteStatus, which applies while the switches are moving
• add a MOVING member to the SwitchState enum
• create a new event corresponding to the successful position change of a switch
• when the event completes, tell the route so it can lock itself if all switches are ready (doing nothing otherwise)

This may only require a double-check, but the entry signal seems to be wrong in some cases.

We don't handle the case of two signals on both directions linked to the same detector.

This was only identified on @kengreville branch switch-post, but it may also happen on dev.

Sometimes train subscriptions to signals last for too long or not long enough. The reasons have not been clearly identified yet.

We need to generate new data, as we can't publish the one we're currently using for licensing reasons

At a given simulation step, we consider the speed limit at the current position to compute the speed at the next step. This shifts the speeds by speed * dt.

Fixing this breaks a lot of tests, so we need to reconsider precisely the wanted behavior whenever we compute speeds per position and rework the tests accordingly.

This is what I've understood of the issue #39 after discussing with everyone involved, as well as a suggested implementation. Please correct me if I'm wrong somewhere.

The main changes will affect speed controllers. This is the tool we use to pre-compute and describe train speeds at every point, for now it only defines the max speed.

We would need to add a similar tool to describe the desired speed on top of the max speed, with a way to tell the train when it is running late. This desired speed would come from an abstract interface, configured in simulation.json. The mareco implementation would follow this interface, and the default behavior would be to follow the max speed.

To do this, we would also need to rework the TrainPhysicsIntegrator. We need it to be able to simulate a train speed from start to finish easily and with as little inputs as possible, excluding any interaction. We may also need more complex operations such as backward steps, which would also let us improve max speed estimations.

In some cases two signals (in opposite direction) can be linked to the same detector.
To handle this case multiple things must be done in the RailJSONParser.

• Adapt the detectorIdToSignalMap to handle the signal direction (make the key a pair <ID, Direction>).
  https://github.com/DGEXSolutions/osrd-core/blob/04e0d30bdac6a73747ed14c44a25ddf6f9712f2c/src/main/java/fr/sncf/osrd/railjson/parser/RailJSONParser.java#L177-L178
• If a signal has already been added to the map then a parse error must be raised.
• Adapt the uses of detectorIdToSignalMap
  https://github.com/DGEXSolutions/osrd-core/blob/04e0d30bdac6a73747ed14c44a25ddf6f9712f2c/src/main/java/fr/sncf/osrd/railjson/parser/RailJSONParser.java#L248

Route:

    {
      "id": "rt.C1-S7",
      "entry_point": "buffer_stop_b",
      "switches_position": {
        "il.switch_foo": "RIGHT"
      },
      "release_groups": [
        [
          "tvd.track"
        ],
        [
          "tvd.switch_foo"
        ]
      ]
    }

Signal:

{
  "expr": {
    "type": "call",
    "function": "warn_signal",
    "arguments": [
      {
        "type": "signal",
        "signal": "il.sig.C6"
      }
    ]
  },
  "id": "il.sig.W4",
  "applicable_direction": "REVERSE",
  "position": 1025,
  "sight_distance": 400,
  "linked_detector": "tde.foo_a-switch_foo"
}

Railjson:

• Suppress waypoints field
• Add entry_point. Takes a waypoint.
• Add field linked_detector for signal. This field is optional.

Core:

• RouteGraph.makeRoute() must retrieve TVDSectionPath from entryPoint and tvdSections.
• If entry_point is a detector then we must have at least one signal linked to it.

RailML:

• Adapt railml parser.