Migrating away from speed controllers

[multun]

This discussion is meant to explain how speed controllers work, and why we want to use speed envelopes instead.

Here is how things currently work:

• when a train plans a move, it calls duplicates its current state and calls TrainState.simulatePhase
• TrainState.simulatePhase calls trainSchedule.trainDecisionMaker.simulatePhase(train, sim)
• TrainDecisionMaker.simulatePhase calls trainState.currentPhaseState.simulate(train, trainState)
• SignalNavigatePhase.simulate:
  • finds the next interaction point
  • simulates until there with trainState.evolveStateUntilPosition(sim, nextInteraction.position)
    • while the goal isn't reached, position changes generated by TrainState.step(locationChange, timeStep, distanceStep) are appended to a location change
    • TrainState.step calls TrainPhysicsIntegrator.nextStep
    • TrainPhysicsIntegrator.nextStep calls iterateFindNextAction via a callback given from TrainState.step
    • iterateFindNextAction calls findActionToReachTargetSpeedAtPosition
    • findActionToReachTargetSpeedAtPosition calls trainSchedule.trainDecisionMaker.getActiveSpeedControllers(isLate)
    • getActiveSpeedControllers uses trainState.trainSchedule.speedInstructions and gets speedInstructions.maxSpeedControllers or speedInstructions.targetSpeedControllers depending on isLate, and then adds dynamic speed controllers, which depend on the phase
  • creates an event which applies the move then it occurs

[multun]

Here's how I'd like things to work.

First, some changes:

• no more speed controllers, only envelopes
• no more phases

The process for standalone train simulation goes as follows:

• find static constraints, such as track or train limits, to produce the most restricted speed profile
• add braking curves to the mix to produce the max speed envelope
• integrate train movement equations along this envelope to produce the max effort envelope
• add margins to the mix, and compute the economic envelope from the max effort envelope
• return both the economic envelope and max effort envelope

The process for many train simulations would go as follows:

• each train starts by running a standalone train simulation, and gets the economic and max effort envelopes
• When a train plans a move, it duplicates its state, finds the next action point (stop, signal sight, detector, ...) and simulates until it is reached
• The dynamic max effort envelopes and dynamic economic envelopes are generated until the position of the action point
• Train movement integration is performed over these curves just like with standalone train simulation, except that the train can switch between the max effort and economic curves given a lateness criteria
• An event which applies the move is created

[axrolld]

So if I get it right there will be an Enveloppe object, and 4 different object will extend this Enveloppe as follows :

• MostRestrictedEnveloppe
• MaxSpeedEnveloppe
• MaxEffortEnveloppe
• EconomicEnveloppe

And when running many train simulations, isn't the dynamic envelope supposed to be the same as the standalone one as long as nothing particular happens, to avoid re-computing the curves ?

[bgiuliana]

I don't know if we could say that the four kinds of enveloppe are extentions ? could we?
I think that there is only one class Enveloppe that could be of different EnveloppeType and so we will create 4 objebts of the class Enveloppe with different EnveloppeTypes. Isnt'it?

Of course, when we run many trains simulations we can use as base the same enveloppe of the standalone case and we will add to this the dynamic EnveloppeParts related to the siganlisation. In this way, we create a dynamic Enveloppe.

[eckter]

The way allowances currently works is this:

• When we load a train schedule, we create a SpeedInstructions instance that contains information about each allowance. These are stored as a list of set of SpeedControllerGenerator.
• A SpeedControllerGenerator has a simple interface: a beginning, an end, and a generate method. generate takes max speeds and returns new max speeds, represented as a Set<SpeedController>.
• We initialize everything when a train is created, this is all managed in SpeedInstructions:
  • We have the Set<SpeedController> that represents max speed
  • We iterate over the SpeedControllerGenerators and generate new max speeds given the previous max speeds.
    • If a set contains several generators, they all take the same max speeds from the previous step
    • The result is a combination of all resulting sets, which results in the most restrictive envelope
    • This is done that way to handle both transitions between independent allowances in different intervals, and allowances "on top" of each other, but it should be changed
  • Once we have generated everything, we have a Set<SpeedController> that represents the speed limits we follow if we are not late. We also keep the one with max speed limits
  • We then create a map of expected (position, time) to know if we are late. This is also done in SpeedInstructions
    • We can also give this as an input, and we need to figure out if we really need this "default" behavior
  • The SpeedInstruction instance is kept in TrainSchedule. It provides both sets of SpeedController and a method to know if we are late

[flomonster]

This is legacy