bi-directional double track with new PBS system

[Tekky]

NOTE: I have created a new wiki article under http://wiki.openttd.com/index.php/Realistic_PBS since this forum thread has gotten quite messy. Therefore, I suggest you read this wiki article for understanding my proposal instead of the forum, because the wiki article is a lot easier to read. But please post all responses to my proposal in this forum thread and not under wiki, unless your response is related to development details.

In Germany, most newly built double-track is bi-directional and also old double track is now being upgraded to become bi-directional. Bi-directional double track has the major advantage of allowing one train to overtake another train, as long as no train is coming the opposite way. This is how bi-directional double track looks like in reality:

[image: see attachment #1]

However, for my proposal, only the realistic placement of signals is of interest, not the placement of realistic switches. Therefore, I will simplify the above layout to this:

[image: see attachment #2]

This realistic signal placement will currently not work in OpenTTD, for these 3 reasons:

1. OpenTTD consideres track with single signals as one-way track.

2. The above signals are all pre-signals. OpenTTD also requires the placement of corresponding exit-signals, which do not exist in reality.

3. OpenTTD by default doesn't allow more than one train to be in an intersection area at a time. This means a train would be obstructed by traffic coming the other way, even if their paths do not cross.

The closest solution available in OpenTTD to these 3 problems would be the following track layout, which uses path based signalling (PBS signals), which is available in the miniIN version of OpenTTD:

[image: see attachment #3]

This track layout works, in principal. However, there is the danger of a deadlock, using the current miniIN PBS implementation:

[image: see attachment #4; NOTE: Due to a limitation in the forum software, this attachment #4 appears after attachment #6]

This deadlock occurs if two trains try to enter the same block from two sides, at the same time. This problem could be fixed in the current miniIN PBS implementation by making a train also reserve the block behind the intersection, so that two trains won't attempt to enter the same block from two sides. However, this solution would not prevent the following deadlock from occuring:

[image: see attachment #5]

In order for OpenTTD to implement bi-directional double track without the danger of a deadlock, I propose the following semi-realistic track layout, which would require a new PBS system in OpenTTD:

[image: see attachment #6]

Assuming right-hand traffic (like in Germany), trains should normally use the right track and only use the left track when the right track is being blocked by another train travelling in the same direction. Since many OpenTTD players also create rail networks with left-hand traffic, I will from now on use the terms "normal track" and "opposite track" instead of "right track" and "left track", respectively.

In the above picture, I have set the signals so that trains will always encounter normal signals when travelling on the normal track and orange signals when travelling on the opposite track. These different signal types tell the pathfinder which side of the track to use, if possible. This can be accomplished by adding an additional "weight" for orange signals to the pathfinder.

Of course, the above track layout would only work if OpenTTD were reprogrammed to not consider track with single signals as one-way track. This can be changed easily. Also, all of my signals in the above picture are pre-signals. OpenTTD (more specifically, the PBS-system) would have to be modified to act as if implicit exit-signals were behind the switches. It is important not to have real signals which can show red/green as exit signals, because trains should not be allowed to wait in front of exit signals, since they would be blocking the intersection. Instead, they should reserve the route up to the next non-exit-signal.

As a rule of thumb, trains should try to wait in front of signals on the normal track (=normal signals). As long as there are only trains waiting on the normal track, there is no danger of a deadlock. Trains should only be allowed to wait in front of signals on the opposite track (=orange signals) if they can be absolutely sure to soon be able to swap back to the normal track. Otherwise, there is a danger of a deadlock:

[image: see attachment #7]

This picture may not look like a deadlock, but if there is a full station immediately to the left, then the waiting train on the opposite track will have caused a deadlock:

[image: see attachment #8]

In order to prevent such deadlocks, trains should only be allowed to wait in front of signals on the opposite track (=orange signals) if they can be absolutely sure to be able to swap back to the normal track without a deadlock occuring beforehand. Therefore, a train whose pathfinder decides to wait in front of an orange signal will have to have reserved a route to the next normal signal. This reservation of the path to the next normal signal, however, does not mean the path to the next normal signal must be completely free. Such a requirement would make all orange signals redundant, since they would always show green and never red. Instead, it is enough to reserve a route to the next normal signal that is safe from a deadlock (a "weak reservation"), such as in the following picture:

[image: see attachment #9]

In the above picture, it was safe for train 1 to use the opposite track, because it can be sure to soon be able to swap to the blue signal next to train 2. Train 1 can be sure of this because train 2 is already moving and has already reserved a route past the signal.

Conclusion: It is always safe for a train to wait in front of a signal on the normal track (=normal signal). It is also always safe for a train to use the opposite track, as long as it has a "weak" reservation of a path to a normal signal. A "weak" reservation of a path means the path is guaranteed to soon be cleared. This is the case, for example, if all trains currently blocking the path have an exclusive ("strong") reservation of a path leading to a point outside the area of the weak reservation and no furhter trains are allowed into the area of the "weak" reservation.

This system could also be used to allow bi-directional triple track, where the outer two tracks are one-way and the middle track is bi-directional, or even make all 3 tracks bi-directional.

For all of this to work, the following modifications would have to be made to OpenTTD:

First, OpenTTD should not automatically consider track with single signals as one-way track. It must be permitted to put single signals also on bi-directional track. One-way track must be marked in a different way.

Furthermore, all signals in OpenTTD are to be PBS signals. With a proper PBS implementation, exit-signals can be considered implicit after every switch, making them obsolete. They don't exist in reality, either, because in reality, signals are only placed in places where trains are supposed to wait. Using this system, a "ro-ro" station would look like this:

[image: see attachment #10]

Please note that you now only need one pre-signal for the station, all the exit-signals of that pre-signal before each platform are now implicit, as they are in reality (although in reality most stations are bi-directional). You only need additional signals for the trains leaving the station.

Also, all signals should show red by default, as in reality. Only after a train reserves a route through a signal, should a signal show green (until the train passes by). This is also how modern signals behave in reality.

A train's pathfinder should always reserve a route to the next signal. This reservation must be "strong", i.e. the path to the next signal must be completely clear. In the case of the next signal being an orange signal instead of a normal signal, the train must also make a "weak" reservation from the orange signal to the next normal signal, in order to not risk getting stuck in front of an orange signal (which could cause a deadlock). If these path reservations are not possible or conflict with another train with a higher priority, the train does not proceed and waits in front of its current signal (which shows red). The basics of such a system have already been implemented with the current miniIN PBS sytem, although this current system only supports strong reservations and not weak ones and also does not support train priorities.

As long as normal signals are only placed in safe waiting locations for trains and all unsafe waiting locations are marked with orange signals, there should be no danger of a deadlock.

I am fully aware of the fact that it would be a lot of work to implement such a new PBS system into OpenTTD. However, I think this system would be very flexible and much better than the current OpenTTD signalling system, which is very limited.

I am considering to attempt to try to implement this system myself into OpenTTD, but before I make any such attempt, I'd appreciate any feedback you have on this topic.

[Tekky]

Due to the forum's limit of 3 attachments per post, I must post 4 times for my 10 attachments.

In this post are attachments #4 to #6.

Please note that attachment #4 appears after #5 and #6. The forum automatically displays images over 100KB after smaller images, therefore I cannot change the order.

[Tekky]

Due to the forum's limit of 3 attachments per post, I must post 4 times for my 10 attachments.

In this post are attachments #7 to #9.

[Tekky]

Due to the forum's limit of 3 attachments per post, I must post 4 times for my 10 attachments.

In this post is attachment #10.

[DaleStan]

This track layout works, in principal. However, there is the danger of a lockup, using the current miniIN PBS implementation:

[image: see attachment #4]

Neither Patch's nor Open's PBS implementation fixes that. YAPF may fix that, or may be able to fix that with the proposed guaranteed-green system, but that is (AFAICT) currently vapourware. I'm not sure whose is "running" that project, but you might want to consider looking at it and seeing if it does something useful.


Other than that, you seem to have thought this through properly, which is, unfortunately, rather unusual. Good work.

[Tekky]

Thanks for your reply!

Yes, I am aware that all current PBS implementations are rather unreliable. However, with my post, I mainly wanted to discuss design issues, not implementation issues yet. These is no point in implementing something if its design is not good

Well, maybe you are right. I have thought a lot about this new PBS system in the last few days and maybe it is time for me to try to implement it. However, before I make such an attempt, I would like to hear what other people think about my design proposal. For example, someone might find a serious flaw in my design proposal that I had overlooked.

[imaginner]

Tekky, your description is both detailed and well thought-out!
But, AFAIK, that is what PBS were invented for (am I wrong?)
So that's not a new idea

[DaleStan]

No, this is not within the purview of PBS to fix.

After some thought, I've come up with a couple possible problems. In all cases, stretch the attached image so that there's enough space for a full train between all signals. All trains are traveling at the same speed.

1) Given the below, will the rear, opposite-tracked trains' weak reservations prevent the further forward, regular-tracked trains from crossing the first junction until after the rear train?

2) At what point do the various reservations start interfering, forcing the opposite-tracked trains back onto the regular track? (IOW: Are you sure you aren't just shuffling the problem one junction further back?)

[Tekky]

@imaginner:

All current signalling models, including PBS in miniIN, only support pieces of bi-directional single track, not double track. This is what I want to change.

I have explained why bi-directional double track is not supported by the current PBS implementation in my first post, in the section which refers to attachment #5.

@DaleStan:

Yes, that is a very good question. I have illustrated which track is reserved by which train in attachment #11. In this picture, the red path is the "strong" reservation and the yellow path is the "weak" reservation.

In this picture, the simplest solution to the problem is that the train on the opposite track shifts ist weak reservation to the next junction, as soon as the pathfinder detects a path conflict, so that both trains can continue unhindered by the other train, as shown in attachment #12.

This would of course only work if there is no traffic coming the other way. If it is not possible to reserve the path to next junction due to traffic coming the other way, then there are two possible solutions:

1. The path reservations in attachment #11 are left unchanged. This means that the train on the opposite track switches back to the normal track and the train already on the normal track must stop.

2. The path reservations are changed to that displayed in attachment #13. In this case, the train on the opposite track stops and waits for the train on the normal track to clear the area of the weak reservation. The train on the normal track must make a strong reservation out of the area of the other train's weak reservation(i.e. to the next signal), otherwise it would risk deadlocking the other train, thus violating the other train's weak reservation.

In your example, the second solution would be more desirable, since the train on the normal track is already further ahead than the train on the opposite track.

Whenever there is a path conflict, OpenTTD should determine which solution is best, depending on how much time every train would lose and possibly also taking train priority into account. In order to detect path conflicts in time to take all of these considerations into account, it may be necessary that also trains on the normal track have some kind of additional "lookahead", possibly in the form of a weak reservation.

[SM9T8]

Nice Ideas, actually I was only thinking today how useful bi-directional double tack would be.

[doghousedean]

I dont see its advantages, Whats wrong with omni-directional double-track. you dont get that problem. I suppose you cant overtake but you could put passing places in with route markers or way points.

Maybe i just dont get it fully

[Tekky]

I assume with "omni-directional double-track" you mean that both tracks have one-way traffic in different directions.

In reality, the main point of bi-directional double track is that a fast train can overtake a slower train. However, in OpenTTD, with breakdowns set to normal, the main advantage would be that broken down trains can be overtaken, so that a broken down train would not block any traffic. This would not be possible with your proposed "passing places" unless the break down happens fully inside your "passing place".

[doghousedean]

Oh i see, I get the point now.

Im just getting into the advanced track building and it seems some people must work in the rail industries or have a lot of time on there hands.

[Tekky]

I don't work in the rail industry, but I've spent many hours driving through Germany in a very realistic train simulator, which simulates how train signals work in reality. This train simulator inspired my ideas to provide OpenTTD with more realistic signalling and bi-directional double track.

In case you are interested, a demo version of this train simulator is available from http://www.zusi.de/. To get the English version of the page, you must click on the British flag.

[Tekky]

Note: The following quote originates from thread http://www.tt-forums.net/viewtopic.php?t=24304. I will answer this question here because the question concerns bi-directional stations with my proposed new PBS system.

I have a question. You have a large flaw if a train reaches the pre-signal and all platforms are occupied. What is it supposed to do then?

I have attached a screenshot of how a bi-directional station layout would look like with my realistic PBS system. This signal layout is exactly how it would look like in reality, only the layout of the switches would be a bit different in reality. Since you are from Australia, I have designed the layout in such a way that it assumes left-hand traffic. My previous examples assume right-hand traffic.

Please note that the single signals are not one-way signals. With my realistic PBS system, it is only meaningful to place signals in front of places where trains are supposed to wait. Therefore, the placement of double signals is never meaningful, since two trains are never supposed to wait on both sides of the same signal (this would cause a deadlock). For this reason, you will also never see such double signals in reality.

Please also note that I don't use pre-signals, since this is not necessary with my PBS system, because signals only turn green when the train found a route to the next safe waiting location (i.e. next signal or station). Therefore, one could say that PBS signals are not necessary in my realistic PBS system, because all PBS signals are also pre-signals.

In the attached screenshot, there are two trains waiting to enter the station, on the "entry track" of both sides of the station. As can be seen, both sides of the station have their "exit track" free. So the trains currently inside the station will have no problem leaving the station, because they can leave either direction. Of course, the difficulty settings of OpenTTD would have to be set so that train reversal is also possible at stations and not only at end of track, for this layout to work.

As soon as one of the trains leaves the station, one of the two waiting trains will be able to reserve a route into the free station platform and take this reserved route. The other waiting train will continue waiting until it is also able to reserve a route to a free station platform.

[kaan]

The more I think about it the more I like this

[Citizen Erased]

Actually most of the reason in Network Rail Western Route is upgraded to Bi-Directional Signalling is to enable Single Line Working with the aim of minimising disruption from minor engineering works where only one of two lines is being affected/utilised by the works, of course in some areas like the MLN1 approach section from Portobello Jn into London Paddington it is also to do with Load Balancing and priorities on the signalling set dependant on traffic.

Single Line Working is also useful if one of the two tracks requires emergency closing due to obstruction, defect or buckling.

[richk67]

Single Line Working is also useful if one of the two tracks requires emergency closing due to obstruction, defect or buckling.

The South West mainline has always had single line working at Dawlish for when an easterly storm causes too much spray & waves over the normal down line. Its quite spectacular to watch the waves crash in, and 50ft spray scatter its way over the tracks.
http://news.bbc.co.uk/1/hi/england/4494068.stm
http://www.railfaneurope.net/pix/gb/die ... 1jun02.jpg
http://cjm.fotopic.net/p8689298.html
http://cjm.fotopic.net/p31673393.html <- This one shows the wave action!
http://cjm.fotopic.net/p34301907.html <- Finally... Ive found a pic showing the waves, and wrong way working...

[Citizen Erased]

Its quite spectacular to watch the waves crash in, and 50ft spray scatter its way over the tracks.

The DJP line in North Wales has a similar problem (Spot the problem with the Sea Wall in the Attached Photo)

[Tekky]

Actually most of the reason in Network Rail Western Route is upgraded to Bi-Directional Signalling is to enable Single Line Working

Single Line Working is simulated very nicely in TTD by trains braking down

In TTD, the effect of a train braking down is exactly the same as Single Line Working becoming necessary. In both cases, one track is completely blocked for a period of time. This blocked track problem can be best solved by having bi-directional double track. This applies both to TTD and reality. But unfortunately, TTD doesn't support bi-directional double track (yet).