Hi, I'm Eunice and I work for SNCF Rizzo and the OSRD project.
So standard disclaimer, the opinion in this presentation I'm maum and not those of the
OSRD project SNCF Rizzo or the Open Relay Association.
So what's OSRD?
It's a railway design toolbox built around microscopic simulation.
So it allows to perform operational studies and also to find last minute pass through
the infrastructure without creating any new conflicts.
It's a licensed under our GPL V3 and funded by SNCF Rizzo, the European Union and the
French state.
So a short signaling primer.
The main goal is that trains do not crash into each other or derail.
The problem is trains are very hard to stop.
They take a very long time to slow down and they need to know that they should slow down
very much in advance.
To do that we use signals and in order to actually use the signals we need to know where
the trains are.
So for that we use track circuits and the axle contours.
But basically we divide the infrastructure into zones and in each zone we can know if
a train is there or isn't there.
We call the space between signal blocks and the block detection zones.
Another thing is that train must not go over a switch that isn't set for them.
So for that they need to have actually an itinerary through the infrastructure.
We call that a route.
And the route need to be established which means that the switches must be locked in place
before a train can pass the signal at the start of the route.
So for example this is using your ball signalings which is the French main signal system.
So here we have a train and behind it this route is set so you have one red light, one
yellow light that signals that this is a red light and then it's okay it's a green light.
But up above the route isn't set this switch is dangerous so there is not only one red
light there is two red lights.
This means that under no circumstance a train must pass the signal.
Here a train can pass it but very slowly.
So we have a number of challenges.
Every European country has its own signalling system and actually multiple.
And there is standardization which is called ERTMS which is actually three levels of signalling
system and even more complicated than that but it's not widely deployed yet and it probably
never will be because nobody is going to upgrade an online for no reason.
But we need to cover every single one of those cases so far as it's just another standard.
We also need to not simulate the infrastructure every time we make a small change in a train
for example departure time or in a forest EDCM for example it use an ASTAR through the graph
of time, space and speed in order to find the pass that doesn't conflict with another
train and every iteration of that ASTAR we cannot simulate the whole infrastructure it
would just one scale.
So we need to be able to model the capacity needs of a train while only simulating it.
And also most of the application should not have 15 implementation of everything because
of 50 signalling system it should be very much abstracted.
So our approach is that signalling system have a very restricted view of the infrastructure
the only thing that only see in front of it and it see linear pass until the next signal.
So they see the state of the zones they protect and they also see the state of the next signals.
We give them other metadata such as the speed of the approaching train or the kind of train
this is useful in some special case.
And we also separate the concept of signalling system such as BAL or RTMS and signalling the
rival which is the actual code that implement the behavior of a signal.
For example, yeah, so they depend on the output and input signalling system.
So for example, here we have the BAL signal that followed either by a T-VM signal or by
a BAL signal also.
And we have two drivers, so two modules that under every BAL to BAL signals and every BAL
to T-VM signals.
And we inject BAL parameters because this is actually a BAL signal since the actual lights
are using the BAL signalling system.
So from that we can actually feed along the path of the train the state of the preceding
signal here, get a state and feed it forward and we have signalling.
But there is a number of problems with this.
It's very cool but as you can see the actual signal reacts after the passage of the train
which is quite normal because that's how it is in the real world.
Our problem is actually trains need to see green before them.
Their actual needs are before them and not after them.
They don't really care.
And we linearize the path but what is the path of the train that follow our train?
We don't know because as we said earlier we are simulating each train alone.
So we need to model the capacity requirement of a train but only knowing that this train
pass.
So why do train conflict?
Either they are following too close to each other in which case they need the zone in front
of them to be free or they have incompatible routes which means that they need the zone
before them to have some specific switch configuration in order to proceed.
There are other reasons why train conflicts such as power delivery needs and many other
reasons but we don't handle those and they have nothing to do with signalling.
So what's the spacing requirements?
We have a zone, a begin time and end time.
It's quite simple.
For a route we have a set deadline which is the begin time.
We have the actual switch configuration.
So in order to set a route you need to know in which direction you are going to traverse
the zone and what is the switch configuration you traverse it.
So how do we get this?
Every time a train encounters a signal we start by assuming the zone in front of the
signal is occupied and we probe the infrastructure linearly until that signal becomes green again.
And then we know that all the zones where the signal wasn't green basically are part
of that signal requirement and we can adjust the begin time of the zone to match the time
at which the train saw the signal.
And every time a train leaves the zone it doesn't require it anymore.
In terms of routing requirements most of the parameters only depend on the path of the
train.
So if we go earlier the route, the traverse zone, the detectors which basically indicate
the direction in the zone and the switch configuration only depend on the path of the train.
We know that.
We are simulating the train.
But in order to find the setting deadline which means we need to know which signal protects
the entry of the route.
And not only that signal but the signal before it because as we saw trains can see a signal
being packed by signal before the actual protecting signal.
So basically we probe in the other way so we set all the zones in the route as incompatible
which means that the route isn't set and then we iterate through the signals until we find
a signal that's green.
Good so now for a train we have its conflict and spacing requirements and the good thing
with those is they are indexable by zone so we can simulate every train once and then
keep a database of each requirement and we simply need to check for every zone if all
the requirements match.
So the spacing requirements are never compatible if they overlap and the routing requirements
are compatible if they go in the same direction and have the same switch configuration.
And if we had a new train we only need to check its requirement and same thing in the
ASTAR of STDCM if we had a train we only need to check that the new zones that are
traversed by ZC ASTAR iteration are actually conflicted.
So in the future we want to implement TVM support.
We are actually in the process of doing that and it should be done by the end of the month.
We want to implement support for overlaps.
The main problem is friends doesn't use overlaps which basically are zones that must be free
after the rest of the signal in case a train doesn't stop there.
Friends doesn't use that but for example Germany do and we do not have any German on the team.
And same thing for other countries signaling systems we want to implement those and the
contribution are very welcome.
There are also moving block support with basically the ERTMSV3 and in order to implement those
we probably need another model specifically for moving block systems.
Thank you for listening.
Do you have any question?
Five minutes question.
Here.
Thanks.
Another one?
You mentioned the different signaling systems and the different operational rules.
Can you move this quite flexibly or as you said the implementation of TVM as a manual
coding?
Manual coding of the signaling system on the driver.
The signaling system is quite simple.
It's not actually a JSON file but it could be.
So it's just declaring what properties the signal may have and there is actually code
to check when we actually construct the blocks that they are correct.
So basically sanitization of user input and in order to make the driver you just decide
what are the possible transitions for your system and you implement those it's basically
one function class.
So it's actual code but it's quite simple.
So when you do the root planning you know of course what rules you train such as post-created
times but I can imagine that the train will occupy is on for a short time and the other
will have to wait a little bit for that to become available.
So there is an optimization problem there like what do we do?
So this is a system how does it tie in with the actual timetable planning?
So the timetable planning in operational studies are done manually.
So because the people doing operational studies actually do this manually or want to do this manually
for now and in the case of SCD-CM we cannot change the path of any train because they are already sold.
So we cannot make a new train but it must not interact with any other train.
So essentially this gives you a yes or no?
Yeah it gives you a yes it's possible and this is the fastest path.
Again for now.
For now yeah.
What's the difficulty?
Was it a challenge for TVN's?
Because there is this big limit on blocks with the speeds before?
Well it's yeah but this was a challenge to integrate in the design.
But for now it's not a challenge it's just a developer bandwidth.
Does the conductor of the train see some kind of nice map that they can see how fast they can still be going?
Or do they just see the green light red light, orange light, double red light and they just kind of react to these very basic signals?
So on BAL signalling they only see the green light, white light, etc.
On TVM it's actually a cab signalling system.
So the driver sees in the train what speed he should go.
But yeah on BAL I don't think.
There is no connection so the driver just look outside the window and see what he has to do.
What challenges do you have now?
Or how does this simulation help in case of delays and dynamically reallocating paths or timetables where the delays are in a cabin at a scale?
So we do not currently support any dynamic simulation but we plan to.
We hope so.
And well in order for dynamic simulation you pretty much have the same constraint and simulating.
You need to actually simulate what state it's in at any point but you also need to know the.
The resource needs in front of a train.
So the situations are for now resolved manually like from the control center?
Oh yeah OSRD actually is not used in real operations in real time for them.
So I think at SNSF most of it is done by experience of the regulator.
This one last question maybe short.
Yes please.
What is the safety requirement of the company?
No.
Thanks.
No no no.
That's it.
Thank you.