Moderator: OpenTTD Developers
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.
- attachment #3
- img3.png (100.93 KiB) Viewed 15314 times
- attachment #2
- img2.png (20.03 KiB) Viewed 15311 times
- attachment #1
- img1.png (32.2 KiB) Viewed 15315 times
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.
- attachment #6
- img6.png (20.45 KiB) Viewed 15281 times
- attachment #5
- img5.png (79.69 KiB) Viewed 15306 times
- attachment #4
- (131.11 KiB) Downloaded 286 times
In this post are attachments #7 to #9.
- attachment #8
- (140.37 KiB) Downloaded 264 times
- attachment #7
- img7.png (25.73 KiB) Viewed 15273 times
- attachment #9
- (102.58 KiB) Downloaded 243 times
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.Tekky wrote:This track layout works, in principal. However, there is the danger of a lockup, using the current miniIN PBS implementation:
[image: see attachment #4]
Other than that, you seem to have thought this through properly, which is, unfortunately, rather unusual. Good work.
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.
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?)
- possible problem.png (8.48 KiB) Viewed 15013 times
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.
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.
- attachment #13
- (121.44 KiB) Downloaded 384 times
- attachment #12
- (119.34 KiB) Downloaded 359 times
- attachment #11
- (119.46 KiB) Downloaded 417 times
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".
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.
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.Pookey wrote: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?
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.
- bi-directional station layout
- station.png (43.98 KiB) Viewed 13777 times
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.Citizen Erased wrote:Single Line Working is also useful if one of the two tracks requires emergency closing due to obstruction, defect or buckling.
http://www.railfaneurope.net/pix/gb/die ... 1jun02.jpg
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...
The DJP line in North Wales has a similar problem (Spot the problem with the Sea Wall in the Attached Photo)richk67 wrote:Its quite spectacular to watch the waves crash in, and 50ft spray scatter its way over the tracks.
- DJP 89m50c Up-DOT.jpg
- (298.6 KiB) Downloaded 385 times
Single Line Working is simulated very nicely in TTD by trains braking downCitizen Erased wrote:Actually most of the reason in Network Rail Western Route is upgraded to Bi-Directional Signalling is to enable Single Line Working
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).
Users browsing this forum: No registered users and 1 guest