# Introduction
Dynamic Interlocking (DI) is where
trains use moving block signalling
instead of regular static block
signalling.
This was inspired by the DLR, which
does not use static signalling
anymore.
Each section is marked by a TCB of a
colour which differs from the existing
TCBs (I propose blue).
# Implementation 1
The amount of blocks is determined by a
factor (default 1.5) of the amount of
trains on each section. Each section
has its own pig-signals and pig-TCBs,
which are like regular TCBs and Signals
except they do not physically exist on
the map, only as arbituary points.
Trains still follow instructions from
these.
# Implementation 2
Inside a DI section, trains have an LZB
set to 10- the Manhattan distance of
the next train on the track. This is
helpful as trains never crash. Despite
the Manhattan distance being a poor
approximation in the case of curves,
this is still helpful as it just makes
trains even further away from each
other, which should be seen as a "net
safety positive".
# Implementation 3
Each piece of track is checked if there
is a train on it. These are "Danger
tracks". Based on the speed of the
train, tracks at different distances
from the Danger Tracks are set to
"Buffer" "Warning I", "Warning II" and
"Warning III" (In decreasing order of
importance), impossng different speed
restrictions on trains on those tracks,
with buffer being "STOP NOW".
Here are suggested warning-speed
pairs:
* Danger - 0
* Buffer - 0
* Warning
** I - 5
** II - 10
** III - 15
And these are the suggested factors to
multiply by the speed of the train to
find the length of each zone:
* Danger - Length of train
* Buffer - 3
* Warning I - 5
* Warning II - 7
* Warning III - 8
Lengths overlap:
w
w
w
bw
bw
x
x
x
bw
bw
w
w
w
# Junctions
So far, these implementations only work
for 1in1out track and won't work where
there are points or crossings.
I propose that a TCB is places at the
entrances and exists of junctions,
making what i call a "junction
section".
From the TCB, you can press a button
which allows routes to be automatically
generated across the entire junction.
and ARS rules can be placed on these.
The TCB can be set to only one train on
the entire junction or allowing
multiple heading different routes
across unoccupied tracks.
# Conclusion
This has several advantages:
* Trains are not stuck waiting at
signals on unnecessarily long sections
* Builders are not forced to spend
hours of effort on the interlocking of
rail lines
* Safer then hand-building interlocking
as human error is not a factor
* Being slightly unrealistic, opens the
playing field for other slightly
unrealistic ideas, like a programming
interface which lies on the tracks and
runs on Lua.
I am pushing my ideas forward here to
see if they meet feasibility
requirements.
Also, each implementation might as well
get its own TCB flavour, giving
builders max choice.
56independent <56independent@protonmail.com> writes:
> # Introduction> Dynamic Interlocking (DI) is where> trains use moving block signalling> instead of regular static block> signalling.>> This was inspired by the DLR, which> does not use static signalling> anymore.>> Each section is marked by a TCB of a> colour which differs from the existing> TCBs (I propose blue).
And I propose writing about this on the wiki instead of the mailing list.
> # Implementation 1> The amount of blocks is determined by a> factor (default 1.5) of the amount of> trains on each section. Each section> has its own pig-signals and pig-TCBs,> which are like regular TCBs and Signals> except they do not physically exist on> the map, only as arbituary points.> Trains still follow instructions from> these.
So basically, instead of actually placing the signal, you specify where
signals are supposed to be.
> # Implementation 2> Inside a DI section, trains have an LZB> set to 10- the Manhattan distance of> the next train on the track. This is> helpful as trains never crash. Despite> the Manhattan distance being a poor> approximation in the case of curves,> this is still helpful as it just makes> trains even further away from each> other, which should be seen as a "net> safety positive".
Or better: take the position of the next train, convert it to the path
index of the current train and place/move a LZB point there. The
occupation system seems to provide features relevant to this.
> # Implementation 3> Each piece of track is checked if there> is a train on it. These are "Danger> tracks". Based on the speed of the> train, tracks at different distances> from the Danger Tracks are set to> "Buffer" "Warning I", "Warning II" and> "Warning III" (In decreasing order of> importance), impossng different speed> restrictions on trains on those tracks,> with buffer being "STOP NOW".
Then the warnings differ depending on the speed of the other train. This
may also duplicate the occupation system to an extent.
> # Junctions> So far, these implementations only work> for 1in1out track and won't work where> there are points or crossings.>> I propose that a TCB is places at the> entrances and exists of junctions,> making what i call a "junction> section".>> From the TCB, you can press a button> which allows routes to be automatically> generated across the entire junction.> and ARS rules can be placed on these.
What about complicated junctions where you have to go through multiple
TCBs?
> The TCB can be set to only one train on> the entire junction or allowing> multiple heading different routes> across unoccupied tracks.
And how do you check whether the paths of two trains do not overlap?
> # Conclusion> This has several advantages:>> * Trains are not stuck waiting at> signals on unnecessarily long sections
If certain sections are _unnecessarily_ long, these need to be
shortened. I have also rarely seen cases where this is actually a problem.
> * Builders are not forced to spend> hours of effort on the interlocking of> rail lines> * Safer then hand-building interlocking> as human error is not a factor
There is already some work on simplifying the process of route
programming, as discussed in the second conference.[1]
In any case, patches are welcome.
[1] https://advtrains.de/wiki/doku.php?id=events:conf:2022-04-02
> And I propose writing about this on
the wiki instead of the mailing list.
I am here to discuss the proposal
before putting a draft on the wiki.
> So basically, instead of actually
placing the signal, you specify where
> signals are supposed to be.
The computer does that for you based on
an equation.
But it seems a good idea to make signal
placeholders, which are places signals
are a good idea.
> Or better: take the position of the
next train, convert it to the path
> index of the current train and
place/move a LZB point there. The
> occupation system seems to provide
features relevant to this.
Good idea.
> Then the warnings differ depending on
the speed of the other train. This
> may also duplicate the occupation
system to an extent.
The warning types and speeds do not
change. Only the amount of track each
warning occupies. If a train is going
faster, it makes sense to give it more
space.
> What about complicated junctions
where you have to go through multiple
> TCBs?
As far as I know, you can split a
junction into multiple subjunctions.
Can you give an example of a junction
which //needs// multiple TCBs?
> And how do you check whether the
paths of two trains do not overlap?
I don't understand how paths work. I
think that you could just check each
track to see if a potential conflict is
possible.
> If certain sections are unnecessarily
long, these need to be
> shortened. I have also rarely seen
cases where this is actually a
problem.
Sometimes shortening is impossible.
Whilst a DI section is very long, it is
split into maany sections.
> There is already some work on
simplifying the process of route
> programming, as discussed in the
second conference.[1]
>> In any case, patches are welcome.
Thank god. I have plans for automating
the entirety of interlocking using
helpful buttons and assumptions (track
closest to TCB will be what it is
assigned to). But that is far on the
horizon.
> [1]https://advtrains.de/wiki/doku.php?id=events:conf:2022-04-02
Hi all,
Thanks for the proposal 56independent, and your good reasoning and
mathematics
ywang. This is the sort of thing I've though about for a while but not
gotten
down to describing or proposing properly.
First: 56independent: consider setting your email client to wrap text
lines at
78 or so columns instead of the minuscule 40 or so that you seem to have it
at. It's pretty standard to have that width and it's clearly creating
issues
when you are quoting Y. Wang where it's breaking the quotes up over
different
lines, which displays incorrectly in at least Thunderbird. 80 columns is a
convention for text terminals' max columns and 78 is a little bit under to
allow for > characters that introduce quotes to be added.
I think it would be prudent to study the real world for a bit to inform
how this kind of system should work. Also in order to give it a name that
matches the real world closer than inventing a new term. In the real world,
this 'dynamic block' type of system is called Communications-Based Train
Control (CBTC). CBTC is not mutually exclusive from other systems, so it
would
sit alongside TSS interlocking and LZB safety systems. Also CBTC's main
application is in densely packed urban areas and mass transit systems, where
reducing headways and increasing trains per hour are major goals, and fixed
block signalling is insufficient. Introducing dynamic blocks is a major
saver
of time and resources compared to installing a huge number of signals and
track circuits, which we all know is really tedious in Advtrains.
CBTC is made of three main components: track equipment, train equipment and
central control. Track equipment and train equipment communicate between
each
other to detect the train's position and for the train to send
information from
its onboard computer. In the real world, these need to communicate in
complicated ways that we can mostly ignore in Advtrains. There is no
need for
track equipment as we always know a train's exact position, speed and path.
Train equipment to obey CBTC I envision as a kind of flag just like we
have an
ARS flag, and central control would live inside Advtrains rather than
physical
nodes in the Minetest world.
As ywang mentioned, you can use a formula with two trains' velocities to
calculate a safe following distance. We have the advantage that we have
perfect
speed measurements and instant communication between trains, tracks etc.
This
will allow central control (Advtrains) to easily calculate speed limits and
apply them to the trains; it could apply them the same way that passing
a fixed
speed limit sign does. It could also make trains brake if necessary, but I'm
thinking an LZB checkpoint would be best rather than direct ATC commands,
though the LZB checkpoint would have to be cleared.
Now as I said I envision that trains will have a flag to enable CBTC
operation
mode. I also think that it will be necessary to mark positions where CBTC
operation begins and ends, just like we have start/end of interlocking
points.
Probably a CBTC Start/End Track node will achieve this.
This is how a train will enter a CBTC zone:
When a train has CBTC mode enabled and passes a CBTC Start track, it will be
looking ahead for more than the usual LZB checkpoints of TSS signals
(dynamic
signals, signs or special tracks like station/stop, LuaATC), but will
mark the
rear of trains in front of it. After the CBTC Start Track should be
placed a TCB
that marks the end of the route that leads into the CBTC area. Now
operating in
what is usually an unsafe way according to the rules of interlocking,
the CBTC
train will continue looking ahead for the rear of trains, which it had
already
started as soon as it passed the CBTC start point. However, it was safe for
this train to enter the CBTC zone as the rear of the train in front had
passed
beyond that 'route ending TCB' before this train was allowed to enter.
The train
can then proceed through the CBTC area with safety provided by looking ahead
and placing LZB checkpoints, rather than with fixed signals.
This is how a train will exit a CBTC zone back to a TSS fixed block zone or
uninterlocked zone:
The train will go over a CBTC end track. It will meet a
normal fixed signal that will stop it from hitting the train in front.
It will
be prepared to stop at this signal because it never stopped obeying normal
signals via LZB while in CBTC mode.
This is how a train will navigate areas with junctions while in CBTC mode:
Junctions will still need TCBs to subdivide them into safe small sections.
Some proposals are floating around for making it easier to interlock these
areas, but these can develop independently of the CBTC module. The
CBC-enabled
train will use ordinary ARS to set the route and will use ordinary LZB to
continue obeying this type of signal at the same time as checking CBTC. The
'route ending TCB' approach mentioned for how a train enters a CBTC zone
will
be used, so that there is only a small section under absolute block control.
Delays from scenarios where trains are very closely following and hit a red
absolute signal should be rare.
If this makes at least some sense then reply and I will post it onto the
wiki
as a proposal rather than continuing an already-length email thread.
Diagrams
will greatly help, which I will surely put on the wiki, but I hope you can
understand at least enough for an initial thumbs up..
Regards,
Blockhead
> Hi all,>> Thanks for the proposal 56independent, and your good reasoning and> mathematics> ywang. This is the sort of thing I've though about for a while but not> gotten> down to describing or proposing properly.>> First: 56independent: consider setting your email client to wrap text> lines at> 78 or so columns instead of the minuscule 40 or so that you seem to have it> at. It's pretty standard to have that width and it's clearly creating> issues> when you are quoting Y. Wang where it's breaking the quotes up over> different> lines, which displays incorrectly in at least Thunderbird. 80 columns is a> convention for text terminals' max columns and 78 is a little bit under to> allow for > characters that introduce quotes to be added.
Makes a lot of sense. I had set it to 40 because i wanted to be well within standard and avoid critiscism for making my lines too long
> I think it would be prudent to study the real world for a bit to inform> how this kind of system should work.
Makes sense. I just skimmed one wikipedia article so i could spin my own
cloth from this knowledge.
> Also in order to give it a name that> matches the real world closer than inventing a new term. In the real world,> this 'dynamic block' type of system is called Communications-Based Train> Control (CBTC). CBTC is not mutually exclusive from other systems, so it> would> sit alongside TSS interlocking and LZB safety systems.
The first version of DI (CBTC) will focus mainly on 1in1out tracks. This
makes standard interlocking required at junctions, which make a minority of
track-km.
> Also CBTC's main> application is in densely packed urban areas and mass transit systems,
where
> reducing headways and increasing trains per hour are major goals, and fixed> block signalling is insufficient. Introducing dynamic blocks is a major> saver> of time and resources compared to installing a huge number of signals and> track circuits, which we all know is really tedious in Advtrains.
Exactly. Since servers are limited to 60 km^2, smaller then most metro areas,
it makes sense that we replicate such dense networks in their signalling, not
the big international railways.
> CBTC is made of three main components: track equipment, train equipment and> central control. In the real world, these need to communicate in> complicated ways that we can mostly ignore in Advtrains. There is no> need for> track equipment as we always know a train's exact position, speed and path.> Train equipment to obey CBTC I envision as a kind of flag just like we> have an> ARS flag, and central control would live inside Advtrains rather than> physical> nodes in the Minetest world.
Makes sense.
> Now as I said I envision that trains will have a flag to enable CBTC> operation> mode. I also think that it will be necessary to mark positions where CBTC> operation begins and ends, just like we have start/end of interlocking> points.> Probably a CBTC Start/End Track node will achieve this.
As i said, i will makr the boundaries with a blue TCB. This TCB is where CBTC
takes over. No train-specific flag. Just different interlocking system.
> If this makes at least some sense then reply and I will post it onto the> wiki> as a proposal rather than continuing an already-length email thread.> Diagrams> will greatly help, which I will surely put on the wiki, but I hope you can> understand at least enough for an initial thumbs up..
Please make a list of rules regarding this.
I think there should be two competing technologies. This goes back to the
railways (France was making the tracks and trains higher speed and the UK
just made the trains higher speed, with tilting trains). You can have green
TCBs :p.
> Regards,> Blockhead
> This is the sort of thing I've though about for a while but not gotten> down to describing or proposing properly.
I can recall a few times where this feature was discussed on LinuxForks.
> As ywang mentioned, you can use a formula with two trains' velocities to> calculate a safe following distance. We have the advantage that we> have perfect> speed measurements and instant communication between trains, tracks> etc. This> will allow central control (Advtrains) to easily calculate speed limits and> apply them to the trains; it could apply them the same way that> passing a fixed> speed limit sign does. It could also make trains brake if necessary, but I'm> thinking an LZB checkpoint would be best rather than direct ATC commands,> though the LZB checkpoint would have to be cleared.
As a minor detail, it _might_ be sensible to (at the same time)
implement identifiers for LZB entries so that you can easily move them.
> Now as I said I envision that trains will have a flag to enable CBTC> operation> mode. I also think that it will be necessary to mark positions where CBTC> operation begins and ends, just like we have start/end of interlocking> points.> Probably a CBTC Start/End Track node will achieve this.
What if a train without the CBTC flag enters a CBTC section?
> This is how a train will enter a CBTC zone:> When a train has CBTC mode enabled and passes a CBTC Start track, it will be> looking ahead for more than the usual LZB checkpoints of TSS signals> (dynamic> signals, signs or special tracks like station/stop, LuaATC), but will> mark the> rear of trains in front of it. After the CBTC Start Track should be> placed a TCB> that marks the end of the route that leads into the CBTC area. Now> operating in> what is usually an unsafe way according to the rules of interlocking,> the CBTC> train will continue looking ahead for the rear of trains, which it had> already> started as soon as it passed the CBTC start point. However, it was safe for> this train to enter the CBTC zone as the rear of the train in front> had passed> beyond that 'route ending TCB' before this train was allowed to> enter. The train> can then proceed through the CBTC area with safety provided by looking ahead> and placing LZB checkpoints, rather than with fixed signals.
I think this was one of the implementations that 56independent suggested
(and IMO the most sensible one).
> This is how a train will exit a CBTC zone back to a TSS fixed block zone or> uninterlocked zone:> The train will go over a CBTC end track. It will meet a> normal fixed signal that will stop it from hitting the train in> front. It will> be prepared to stop at this signal because it never stopped obeying normal> signals via LZB while in CBTC mode.
It is appreciated that this is pointed out. I did not think about this
when looking through the previous proposal.
One thing that probably needs to be discussed is how this should
interact with the current signaling mechanism, especially now that I am
working on a route signaling system (along with distant signaling).
> This is how a train will navigate areas with junctions while in CBTC mode:> Junctions will still need TCBs to subdivide them into safe small sections.> Some proposals are floating around for making it easier to interlock these> areas, but these can develop independently of the CBTC module. The> CBC-enabled> train will use ordinary ARS to set the route and will use ordinary LZB to> continue obeying this type of signal at the same time as checking CBTC. The> 'route ending TCB' approach mentioned for how a train enters a CBTC> zone will> be used, so that there is only a small section under absolute block control.> Delays from scenarios where trains are very closely following and hit a red> absolute signal should be rare.
Then CBTC only handles a single track without junctions, right? This
seems like an interesting compromise between capacity and complexity.
> If this makes at least some sense then reply and I will post it onto> the wiki> as a proposal rather than continuing an already-length email> thread. Diagrams> will greatly help, which I will surely put on the wiki, but I hope you can> understand at least enough for an initial thumbs up..
Your proposal looks good so far, and some (mostly minor) issues can be
addressed after the proposal is put onto the wiki. I will add comments
if there is something else I notice that possibly needs to be addressed.
>> Also CBTC's main>> application is in densely packed urban areas and mass transit systems,>> where>> reducing headways and increasing trains per hour are major goals, and fixed>> block signalling is insufficient. Introducing dynamic blocks is a major>> saver>> of time and resources compared to installing a huge number of signals and>> track circuits, which we all know is really tedious in Advtrains.>> Exactly. Since servers are limited to 60 km^2, smaller then most metro areas,> it makes sense that we replicate such dense networks in their signalling, not> the big international railways.
I am quite sure some maths went _seriously_ wrong there.
> I think there should be two competing technologies. This goes back to the> railways (France was making the tracks and trains higher speed and the UK> just made the trains higher speed, with tilting trains). You can have green> TCBs :p.
Please consider the sanity of other people (in particular, of those who
work on things related to the feature). Most people working on advtrains
only have a limited amount of time they can spend working on the mod,
and having to support multiple implementations is not something that
people prefer spending time on, especially considering that the time
spent on supporting different implementations is essentially wasted
because there is likely only one implementation that will end up landing
in the master branch, and that one is _the_ one to provide support for.
> > Exactly. Since servers are limited to 60 km^2, smaller then most metro
areas,
> > it makes sense that we replicate such dense networks in their signalling,
not
> > the big international railways.> I am quite sure some maths went seriously wrong there.
Let's try again... So we have radius 30,000 m. For the diameter of the world,
it is 60,000. If we convert 60,000 to 60 km, and then asume Minetest is a
square, minetest is 60 km^2. Explain the error. London is 1000 km^2, and
Manchester is also.
> > I think there should be two competing technologies. This goes back to the> > railways (France was making the tracks and trains higher speed and the UK> > just made the trains higher speed, with tilting trains). You can have
green
> > TCBs :p.>> Please consider the sanity of other people (in particular, of those who> work on things related to the feature). Most people working on advtrains> only have a limited amount of time they can spend working on the mod,> and having to support multiple implementations is not something that> people prefer spending time on, especially considering that the time> spent on supporting different implementations is essentially wasted> because there is likely only one implementation that will end up landing> in the master branch, and that one is the one to provide support for.
Please note the `:p`, which is a face with a tounge out, meaning that the
entire pragraph was written as a joke. I understand humor as a thing that
Germans often struggle with :p.
But seriously, the technologies can compete for a place in active
development, as opposing proposals.
>> > Exactly. Since servers are limited to 60 km^2, smaller then most metro> areas,>> > it makes sense that we replicate such dense networks in their signalling,> not>> > the big international railways.>> I am quite sure some maths went seriously wrong there.>> Let's try again... So we have radius 30,000 m. For the diameter of the world,> it is 60,000. If we convert 60,000 to 60 km, and then asume Minetest is a> square, minetest is 60 km^2. Explain the error. London is 1000 km^2, and> Manchester is also.
It's (60km)^2 = 3600 km^2, not 60km^2 (the two are different because the
first one applies the square to the number _and_ the unit while the
latter one does not).[1][2]
The size of cities can also vary based on how the city limit is defined.[3]
The other thing to consider is the size of cities in Minetest compared
to those in real life. You could try to copy the subway network of
Tokyo[4] to a server, but the sensibility of doing so (in particular,
that of actually being useful as a trainsit system) is likely
questionable on most servers.
> But seriously, the technologies can compete for a place in active> development, as opposing proposals.
And the paragraph I wrote essentially questions the sensibility of such
competition in an environment like the development of advtrains,
especially for people who work on related features. I do not welcome
such competition as it potentially wastes _my_ time if I want to support
both implementations in the things I work on, and I have enough things
to spend time more on.
[1] https://en.wikipedia.org/wiki/Square#Perimeter_and_area
[2] https://en.wikipedia.org/wiki/Exponentiation#Identities_and_properties
[3] https://en.wikipedia.org/wiki/List_of_largest_cities
[4] https://www.tokyometro.jp/en/subwaymap/index.html
Hi 56independent, hi everyone,
I've read through the discussion, and in my opinion there are two central ideas here that we want to work on:
## 1. Moving-block signalling
That is, trains follow each other in a safe distance, without relying on signals.
This feature correlates with the "drive on sight" feature. I put some ideas for this in http://bugs.linux-forks.de/advtrains/184.html
Essentially, this would be an extension to LZB for what can be described as "moving LZB checkpoints" - the rear end of each train (+ some safety margin) would be considered an LZB stop/speed restriction point for trains that follow. I am not sure whether this should really be squeezed into the LZB code or handled somewhere else... that would be up to the person implementing it.
Activation of this mode would be through a special signal, something like "Moving block signalling from this point on". The next main signal or a special "moving block signalling off" signal would disable it again.
Important: Junctions can not use MBS (for reasons already discussed), so I would prefer that junctions still use "conventional" interlocking. This will also prevent trains stopping on the junction itself.
If someone wants to bring up a solid proposal for this kind of moving-block/drive on sight, please go ahead and write it on a wiki page.
## 2. Automatic programming of routes in a junction
This is about bringing more intuitivity to the route setup stuff. As I explained in the last meeting, this is what I am working on on the route_prog_rework branch (or at least I am planning to).
----
Please let us split this discussion into two threads. "Dynamic Interlocking" is also a very vague term which doesn't really describe what we want to do.
Regards,
orwell
Am 03.04.22 um 00:46 schrieb 56independent:
> # Introduction> Dynamic Interlocking (DI) is where> trains use moving block signalling> instead of regular static block> signalling.> > This was inspired by the DLR, which> does not use static signalling> anymore.> > Each section is marked by a TCB of a> colour which differs from the existing> TCBs (I propose blue).> > # Implementation 1> The amount of blocks is determined by a> factor (default 1.5) of the amount of> trains on each section. Each section> has its own pig-signals and pig-TCBs,> which are like regular TCBs and Signals> except they do not physically exist on> the map, only as arbituary points.> Trains still follow instructions from> these.> > # Implementation 2> Inside a DI section, trains have an LZB> set to 10- the Manhattan distance of> the next train on the track. This is> helpful as trains never crash. Despite> the Manhattan distance being a poor> approximation in the case of curves,> this is still helpful as it just makes> trains even further away from each> other, which should be seen as a "net> safety positive".> > # Implementation 3> Each piece of track is checked if there> is a train on it. These are "Danger> tracks". Based on the speed of the> train, tracks at different distances> from the Danger Tracks are set to> "Buffer" "Warning I", "Warning II" and> "Warning III" (In decreasing order of> importance), impossng different speed> restrictions on trains on those tracks,> with buffer being "STOP NOW".> > Here are suggested warning-speed> pairs:> > * Danger - 0> * Buffer - 0> * Warning> ** I - 5> ** II - 10> ** III - 15> > And these are the suggested factors to> multiply by the speed of the train to> find the length of each zone:> > * Danger - Length of train> * Buffer - 3> * Warning I - 5> * Warning II - 7> * Warning III - 8> > Lengths overlap:> > w> w> w> bw> bw> x> x> x> bw> bw> w> w> w> > # Junctions> So far, these implementations only work> for 1in1out track and won't work where> there are points or crossings.> > I propose that a TCB is places at the> entrances and exists of junctions,> making what i call a "junction> section".> >>From the TCB, you can press a button> which allows routes to be automatically> generated across the entire junction.> and ARS rules can be placed on these.> > The TCB can be set to only one train on> the entire junction or allowing> multiple heading different routes> across unoccupied tracks.> > # Conclusion> This has several advantages:> > * Trains are not stuck waiting at> signals on unnecessarily long sections> * Builders are not forced to spend> hours of effort on the interlocking of> rail lines> * Safer then hand-building interlocking> as human error is not a factor> * Being slightly unrealistic, opens the> playing field for other slightly> unrealistic ideas, like a programming> interface which lies on the tracks and> runs on Lua.> > I am pushing my ideas forward here to> see if they meet feasibility> requirements.> > Also, each implementation might as well> get its own TCB flavour, giving> builders max choice.>