Okay, that's fine.
Hello, welcome to my presentation.
My name is Paula Fonda.
I'm from the Technical University of Orange Lake in Germany.
I'm currently my colleague, Basti.
He's got the flu.
I work through his life as well.
The topic that we want to present you today is an open source workflow for
Huawei analysis.
We want to do that by connecting the open source Huawei designer
and the simulator of Urban Mobility.
So this has two open source tools, which we think are really cool.
In research, it's really helpful to work with open source.
Because you can just deep dive into the software
you know exactly what's happening and that's pretty good.
It's also more reproducible.
And well for research, it's also helpful if it's not so expensive.
First of all, let me introduce you to the workflow of Huawei analysis.
So first of all, we have to build an infrastructure.
So there's some kind of infrastructure design.
There will be some switches, some sightings, there will be some signals.
And of course, this will depend on the kind of the policy that we have,
the kind of demand and the operational mode that we want to drive in.
And then on the other side, we have the rolling stock.
So these are our vehicles and they come with certain driving dynamics.
And then if we put the vehicles on the tracks, we can estimate the driving time
and we have the demand. So we know how often we want to have this train driving on that tracks.
And from that, we can create a schedule.
So there will be a departure time and we will can also do a capacity analysis.
So we know how many trains we can follow each other so that there will be a service.
Well, all of this is basically static analysis.
We can do this in theory.
But then, well, if we go to practice, we all know how that goes.
I think either of us has had delays when we are riding a train.
And to kind of take some of the bottlenecks upfront, we can do a microscopic operational simulation.
And then we can add disturbances to our scenario.
And from that, we get operational results.
We can see how resilient our system is and how resilient our schedule is.
Well, it would be really cool if we would have this workflow in open source.
And there's already been some work done by the SNTF with the open source Huawei designer.
And there's a lot of these functions that can be done in the open source Huawei designer.
But we are missing the other the right side of this workflow.
And we thought about gapping this with the sumo the simulator of open mobility.
So what we want to do is kind of combine these two tools for our analysis.
Well, just a really short example on the open source Huawei designer.
I know there has been talks about the open source Huawei designer here and there will be more.
So I would keep this very short here.
We have an example here from his student work.
So he put a bunch of passenger trains.
And then he tried to fit flight planes on this.
And he did this with 160 kilometers an hour for the flight trains.
And then he was able to fit only one or two per hour.
But then he added some sightings.
And he said, well, let's maybe do that differently.
Maybe let's go with 160 kilometers an hour.
And let's just let him drive a little faster.
Well, and then we can build this in serious.
So he was actually able to fit five trains per hour.
Just looking at the capacity analysis and do a time schedule.
Looking at the time schedule constraints.
But then the question is how does this look and practice.
And what if we added disturbance to the system.
And this is what we want to look at in sumo.
So we checked out what sumo could do.
Because simulation is a valuable mess up.
So we can kind of wherever you understand the operational behavior.
We can see the impact of disturbances.
And also we kind of can make changes in a virtual environment.
Have like a virtual playground, a virtual test of our resilience.
To see if we want to do something and play around.
Because we researchers then we can test this in a virtual environment.
And not have this in a real network.
Well, there is software for that.
There's like open track, there's well, there's looks.
There are commercial tools that are perfectly made for this.
So they come with very specific railway modeling capabilities.
And you can use these tools tools to do this task.
But they're licensed.
So you have to pay for that.
And you don't really know what exactly is happening down in the software.
And how things are modeled exactly.
So we want to use sumo instead.
Sumo was developed as a German aerospace center.
And it's covered under the eclipse foundation.
And what it's also.
So that's what we all really like about it.
It's an agent based microscopic simulator.
So basically any vehicle that's moving in the simulation.
You can access all the information and all the paths.
And you can get all that data.
Originally it's been designed for road vehicles.
So it's coming from the car domain.
And it's been used for traffic forecasting,
VTV communication, things like that.
But the good thing about is that because it's from the road domain,
they're used to working with very high amounts of vehicles.
So it's very powerful simulator.
And sumo has added the feature of intermodality.
So it's not only cars anymore.
But we can do a well ways.
We can do trumps and subways.
We can also do bicycles and pedestrians.
So there's a lot of possibilities to simulate the transportation.
So we've been checking out sumo.
And the case study.
And to see how we can we represent, for example, a light real system in sumo.
And for that, I took the corridor A in front of us.
This car is lines U1, U2, U3 and U8.
With the upper part, this is all about surface, the blue part.
And the red part is in the tunnel.
And then in the south trains we were.
And then they go back up to the north.
And I'm ordered two different scenarios here.
So the first one was the conventional scenarios.
Twins are driving in a pig's block system.
And they have a non automated reversal.
And then I tried a different scenario.
It was a new system called communication based train control.
And these trains go with moving block.
And they do an automated driverless reversal.
And I used sumo to see how these different techniques would turn out.
And then I added, of course, delay because that's when it gets interesting.
And well, first of all, about the worst thing.
What we do in the schedule planning, this is just driving from A to B.
And we now, how the passengers take that train.
But then also, of course, we have to do the worst thing.
We have to see how do the vehicles we've heard.
And which driver is on which train in the end.
So making the reverse was always part of the planning as well.
And this is the reverse thing, not in front of a soup on hoof.
As we can see, two different paths.
How the train may reverse there.
And then there's two different kinds to do that.
So that would be the non automated reversal.
Well, the driver actually drives into the reverse thing area.
Get out of the vehicle, walk to the other side, get back in,
and then drive out again.
The automated driverless reversal, the driver actually gets out at the last station.
The train does everything by itself, and the driverless manner.
And then the driver just gets back on when the train returns to the station.
I did a little video of the sumo simulation to give you an idea how that looks like.
So the trains just arrive, they return, and then they go back to the noise.
Well, then I added delay to that system.
In this case, 300 seconds. So that's five minutes.
And then I checked out how the conventional system would do.
And how the CDC system would do if we added delay.
So they were driving the same schedule.
This is the actual schedule that's been driven there.
I got it by a GTFS.
And then I checked out how they could cope with the CDLA.
And we can see that the CDC system can recover from the delay much faster.
It's due to the movie vlog, but also due to the reversal.
We can see the delay is dropping faster.
Then I also looked at how much the delayed vehicle affects the consecutive vehicles.
This is subsequent vehicles that follow behind it.
So this is a 600 seconds delay, a 10 minute delay.
And this is the average delay across all stations.
And we can see this is the first one, the vehicle that has the delay.
And then while the U-1-3, this is the first vehicle which is not affected by the delay anymore.
And again, we have the two different systems that I'm comparing.
And I can see that in the conventional scenario, my delay is much higher for the consecutive vehicles than with the CBTC system.
So we can see also there's an improvement by this new technique.
And this is something that I can model in sumo and that I can get the results from.
And the schedule has been the same for both.
It's just the operational mode has been different.
Yeah, this is also a video of sumo.
This is Frankfurt City.
So I have the Hop-Bacher and the Constable-Bacher.
Anybody has been Frankfurt.
And then there's this great train here.
And it's actually broken down.
So this has just stopped operation.
And we can see a jamming here behind it.
Of course, the vehicles are bunching.
They can't go anywhere else.
There's no sighting.
And then at some point, this luckily, this vehicle continues its journey.
And we can see how the other vehicles then pick up it again.
And how they try to re-establish the schedule.
And then what we want to do is, well, we look at the initial vehicle delay.
But we can also investigate the second day of the delay.
And well, how could things be different if we added a sighting?
Or if we had a different schedule.
So we can check out different possibilities.
And how that influences my dynamic behavior.
So we think sumo is a really cool tool.
We can do some stuff with that.
So we did a little deep dive into what sumo, how sumo works.
So sumo implements a node edges model in XML.
So if edges files have node files,
or I can also combine it to dot net files.
And if I have a track section, that is a bidirectional edge in sumo.
They have a geometry, and they also have a speed limit.
They can also do arc radius via geometry points,
but it's kind of implicit.
Now I have switches.
Well, they basically nodes with several attached edges.
I do have stations, and they can model a dweltime.
Then I have signals.
They are just basically nodes of type will.
So it's attached to the node, not to the edge.
But they are only main signals.
They are no distance signals.
So this is something that is, if I want to compare to a legacy scenario,
this is a bit difficult.
So basically the trains behave as if they had in cap signalization.
I mean for the fast 20, mostly do,
but if I want to do like a commuter train,
they don't have that yet.
And then we have a vacancy detection,
which is also kind of implicit.
Sumo knows the exact position of the train,
and it's freeing the occupancy of the tracks based on that knowledge.
Well, there are some railway specifics, which I'm missing.
So if we want to use this for a railway analysis,
that's the question, how can we improve that?
How can we add this?
And then also if we wanted to use it together with the open source,
where we design a, there's also the question,
how can we map this to the open source,
where we design a to that railway JSON format?
Also about the results analysis in the commercial tools,
but if we're showing you earlier, where this looks,
they have very ready statistics that we turn in the end of the simulation.
There are certain performance metrics that are well established in the railway domain.
So if the railway engineers look at these tooling say,
and now exactly what they get out of that software.
For example, there's like train graphs,
there's speed resistance,
there's always an analysis of the capacity of the headway.
So these are metrics that the railway engineers will look at.
And then we use sumo, we don't have that, at least,
we don't have it out of the box.
So the war data is all available.
We have a lot of XML output from sumo,
and also I have a precise control on any vehicle,
and there's an API, which I can hook myself to,
and then I can get any elements paths, any elements characteristics.
So basically what we need to do is,
what I did for my results earlier that I've shown you,
I did this with Python scripting.
So the information there, it's just not nice and ready.
So you kind of need some programming skills to get this information out of it.
And well, yeah, programming skills, I must have, I'm not a programmer,
I'm from the railway domain,
and so also this is something that's toppling,
and so it would be good to provide some metrics
also for the railway engineers,
which are not that good at programming like me.
So in the end, this is the workflow that we are imagining of.
This is how we would like to use the open source of railway designer
and sumo together.
So we would start our designing infrastructure in the open source of railway designer.
We would add it to infrastructure, we would draft the timetable,
and then we would export this and use it in sumo.
In sumo, we would do the microscopic simulation,
we would test the dynamic behavior, we would look at the bottlenecks,
and then of course there needs to be some kind of results analysis.
So we will look at the delays, we will look at the capacity conflicts,
and how resilient our system is.
And in the end, we want to do then we work in the open source railway designer,
so maybe it would be helpful to add a siding,
or to maybe make some modifications at the timetable.
The left side, I think, is already pretty established,
these tools are available,
but on the right side, the data transformation from the open source
railway designer to sumo,
and also the results analysis, there are still some gaps,
there's anybody who wants to contribute to that, we're happy,
that we work on this to get this connection,
that we can use the both tools and combination,
and close the gap to close this workflow,
and then it's iterative manner.
This is our context, a few, free to reach out,
we'll be happy to get in touch with you,
and have further discussions.
Thank you.
Any questions?
Yes?
You gave an example of changing the operational mode in the performance.
We have one on the transport system.
Yeah.
How you implemented any of these in a practical real transport system?
Well, actually, thank for studying that at the moment,
so they still use the fixed block and the manual reversal,
and we have to talk in 2030,
because then they plan to be done,
and then we can actually compare these,
but I don't have the results of that yet, but.
Yes?
Yes.
You mentioned,
you mentioned the occupied parts of the track,
and you also use this software to,
with my regards, improve the hardware a lot,
so that, for example, adding one or two switches,
you can double the volume of trains on a specific part of track,
or you can come to your waiting time,
and complete normal timing and get a lot.
Well, basically, you can change the infrastructure,
and one two different scenarios, and see how they compare.
You can do that.
Yes?
Yes.
It will, however.
I would really love to do that.
Unfortunately, I'm missing the data to do that.
But what we're actually doing is,
we are comparing it to the commercial software,
because at the other level of engineers,
I actually have some work on going
that's comparing it to the commercial software.
I hope they have done some validation as well,
but it will be really cool to do that.
So I listened to the talks earlier about the delays,
and how to gather the delays,
and I will try to maybe catch an event and compare that to my zoom-o results.
Yes?
That will be cool to do.
Yes?
Okay, last questions?
Yes?
You know, so, by now, the zoom is responsible for
stimulating or the trains behave, like,
of the x-a-way, this area, and the tap.
Yes?
And what's important to zoom-o xi to are the next
young actual operation of all that stuff?
Well, I know that, the cow world, they do
microscopic simulation of the vehicle,
and then they give out the acceleration,
and they can hook it a sumo.
So it has an external appie, it's called Tracy,
and with that, you can have interaction
and like a co-singulation.
Thank you.