~gpcf/advtrains-discuss

2 2

Re: [Proposal] Dynamic Interlocking

Details
Message ID
<G6W3pfbezP8cJFjUMdosWMhZoON4S_Eot7fUhFI4eeY1q6n0PS_Ssc_URiM4VRMkxcZqDhCSr8gct2iCuaLNTDxYROWHQRJdCibmMlhSaqI=@protonmail.com>
DKIM signature
missing
Download raw message
> > I am here to discuss the proposal
> > before putting a draft on the wiki.
>
>
> The wiki is also a place to discuss
such topics. In particular, it can,
> in some cases, provide a better
overview than a discussion thread via
> email.

Noted.

>
> I should also piont out that, again,
you did not CC your previous email
> to the mailing list.

https://imgur.com/a/zQXME6d

Just a gentle reminder to ensure you
don't make the same mistakes as me.


> > 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.
>
>
> A specification on how this is
calculated is appreciated.

Already done:

> The amount of blocks is determined by
a factor (default 1.5) of the amount of
trains on each section

The amount of signals are <amount of
trains>*1.5.

Placement is evenly-done across the
rail (using signals with no physical
appearence, instead directly on the
rail, like an influence point).

> What I meant is that the warning may
differ for a train depending on its
> speed. You can, for example, have a
train B behind a train A. Then, for
> a relevant time period (e.g. before
reaching a junction where two trains
> go in different directions), you can
give B different warnings based on
> its speed relevant to A:
>
> - If B is proven to be slower than A
(e.g. due to the difference in the
> maximum speed) or move in the
opposite direction (i.e. away from A)
> for the relevant time period, a
warning is likely not needed as it
> can be proven that B can never reach
A in the relevant period of time.

Makes sense. Noted for next draft.

> - If B is proven to move at the same
speed as A or faster than A but is
> proven to not be able to catch up to
A in the relevant period of time
> (e.g. because the trains are very far
away from each other), then a
> warning is, like in the above case,
likely not needed.

It depends. The point of warnings is to
prevent trains reaching each other. At
high speeds, warnings may cover many
blocks.

They belong to the train which is being
warned about, with a train checking
before and after itself for trains, and
querying their warnings.

> In addition, there are many other
factors to consider here, such as
> acceleration, speed restrictions at
different sections, and LuaATC, the
> last one of which can make a warning
system unnecessarily conservative
> to the point that it may not bring
much difference compared to the
> current interlocking system.

Difference in terms of what? Effort
setting up? DI is designed for
mainlines, not railyad operations. A
Wye will likely be fine, but anything
more then a Wilsden Junction should be
made with standard interlocking.
(Automation works for 90% of the work,
leaving 10% to humans)


> I can not give an example of one
where multiple subjunctions are
> necessary. However, splitting a
junction into smaller parts is often a
> good idea to allow higher capacity,
e.g. for multiple trains that can be
> in a junction at the same time if it
can be proven that the paths of the
> trains do not overlap.

DI makes splitting easier. Routes are
automatically made between places, but
multiple  can be set at the same time,
making the system potentially higher
capacity.

Take rail line x (which only goes one
direction, from a manufacturing plant
to a scrapyard).

_> To destination 1
/
>---<
\_> To destination 2

Train service A goes to destination 1,
B to destination 2

If we had a timetable of ABABABAB, then
with standard interlocking, trains
would have to wait until the junction
is free before moving. With DI, they
just have to wait until their path does
not collide with another train and its
path.


> I am not sure how shortening an
extremely long section (in the
magnitude
> of 500 or more nodes) is not possible
unless in certain edge cases
> that are likely caused by suboptimal
track placement.

Shortening may be impossible due to
logistical limitations of extremey long
lines (WB N to WB S, anyone?). In DI,
the admin can just remove all entries
for the long line and worldedit them
away. Then they can just put in DI TCBs.

Re: [Proposal] Dynamic Interlocking

Details
Message ID
<871qyciqid.fsf@forksworld.de>
In-Reply-To
<G6W3pfbezP8cJFjUMdosWMhZoON4S_Eot7fUhFI4eeY1q6n0PS_Ssc_URiM4VRMkxcZqDhCSr8gct2iCuaLNTDxYROWHQRJdCibmMlhSaqI=@protonmail.com> (view parent)
DKIM signature
missing
Download raw message
> The amount of blocks is determined by
> a factor (default 1.5) of the amount of
> trains on each section
>
> The amount of signals are <amount of
> trains>*1.5.
>
> Placement is evenly-done across the
> rail (using signals with no physical
> appearence, instead directly on the
> rail, like an influence point).

Then you have the potential problem that trains may be put into the same
imaginary section when their boundaries change because of the change in
the number of trains in the DI section (e.g. when a train enters or
leaves it).

>> - If B is proven to move at the same
> speed as A or faster than A but is
>> proven to not be able to catch up to
> A in the relevant period of time
>> (e.g. because the trains are very far
> away from each other), then a
>> warning is, like in the above case,
> likely not needed.
>
> It depends. The point of warnings is to
> prevent trains reaching each other. At
> high speeds, warnings may cover many
> blocks.

What actually matters is the difference in the speed of the two trains,
which is the _actual_ reason I discuss the different cases.

If you have a train moving at the speed of v0 and a train second train
moving at the speed of v1 behind the first train with the distance of
Ds, then, to catch up, you solve the equation

v0*t+Ds = v1*t

(i.e. there is a time t after the starting time where the second train
moves as far as the initial distance between the two trains plus the
amount the first train moves)

Then you get

t = Ds/(v1-v0)

Then you need to check whether the first train moves far enough this
becomes irrelevant, such as (as in the example I mentioned before) when
the both trains go in two different directions at a junction and a
hypothetical collision point goes beyond the particular junction.

In fact, if the difference between the speed of the two trains is the
same but the trains are faster, then Ds can be smaller as the trains are
otherwise more likely to collide outside the section, which, in the
example I mentioned earlier, becomes irrelevant.

> They belong to the train which is being
> warned about, with a train checking
> before and after itself for trains, and
> querying their warnings.

IMO this is closer to implementation detail than mathematical
considerations that I tried to show above. What I tried to point out is
that, with your proposal, warnings may be given out to slow down trains
when these are not necessary.

>> In addition, there are many other
> factors to consider here, such as
>> acceleration, speed restrictions at
> different sections, and LuaATC, the
>> last one of which can make a warning
> system unnecessarily conservative
>> to the point that it may not bring
> much difference compared to the
>> current interlocking system.
>
> Difference in terms of what? Effort
> setting up? DI is designed for
> mainlines, not railyad operations. A
> Wye will likely be fine, but anything
> more then a Wilsden Junction should be
> made with standard interlocking.
> (Automation works for 90% of the work,
> leaving 10% to humans)

I think I did not write it clearly, but I meant speed restrictions as in
ones set by (for example) signal signs.

>> I can not give an example of one
> where multiple subjunctions are
>> necessary. However, splitting a
> junction into smaller parts is often a
>> good idea to allow higher capacity,
> e.g. for multiple trains that can be
>> in a junction at the same time if it
> can be proven that the paths of the
>> trains do not overlap.
>
> DI makes splitting easier. Routes are
> automatically made between places, but
> multiple  can be set at the same time,
> making the system potentially higher
> capacity.
>
> Take rail line x (which only goes one
> direction, from a manufacturing plant
> to a scrapyard).
>
> _> To destination 1
> /
>>---<
> \_> To destination 2
>
> Train service A goes to destination 1,
> B to destination 2
>
> If we had a timetable of ABABABAB, then
> with standard interlocking, trains
> would have to wait until the junction
> is free before moving. With DI, they
> just have to wait until their path does
> not collide with another train and its
> path.

I fail to see how DI speeds things up in this case besides the distance
of the train (instead of the occupation of track sections) being used as
a reference for setting speed restrictions, which is the potential
advantage of DI in general and not specific to junctions.

With the current mechanism for interlocking, you can also split
junctions into smaller parts to allow multiple routes through the
junction to be set at the same time, provided that the paths (which, in
this case, involve track sections) are not shared across the routes
(note that the term "path" here is used rather loosely - I mean path in
terms of the track sections used by the routes here, not the path system
itself).

From what I understand about your proposal, the main difference is that,
instead of manually setting up routes, the list of potential routes is
automatically created for (sub)junctions, which can potentially make
interlocking easier. However, there are also other attempts with the
same goal that does not involve implementing DI.

Re: [Proposal] Dynamic Interlocking

Details
Message ID
<zVZQ0hSmBNNa2a1ACkGdQxyPZsPJ73BatbFg9Vmw4Mr4cQYilx0igOWfTg0MO5lS7epi_1narN2s6glq67exMlyyHeScsfKcvve31cpD-Vc=@protonmail.com>
In-Reply-To
<871qyciqid.fsf@forksworld.de> (view parent)
DKIM signature
missing
Download raw message
> Then you have the potential problem that trains may be put into the same
> imaginary section when their boundaries change because of the change in
> the number of trains in the DI section (e.g. when a train enters or
> leaves it).

I will need to consider solutions to this. Maybe we run a check before
merging sections, or keep a set amount per hour to make it easier to run.

> What actually matters is the difference in the speed of the two trains,
> which is the actual reason I discuss the different cases.
>
> If you have a train moving at the speed of v0 and a train second train
> moving at the speed of v1 behind the first train with the distance of
> Ds, then, to catch up, you solve the equation
>
> v0t+Ds = v1t
>
> (i.e. there is a time t after the starting time where the second train
> moves as far as the initial distance between the two trains plus the
> amount the first train moves)
>
> Then you get
>
> t = Ds/(v1-v0)
>
> Then you need to check whether the first train moves far enough this
> becomes irrelevant, such as (as in the example I mentioned before) when
> the both trains go in two different directions at a junction and a
> hypothetical collision point goes beyond the particular junction.
>
> In fact, if the difference between the speed of the two trains is the
> same but the trains are faster, then Ds can be smaller as the trains are
> otherwise more likely to collide outside the section, which, in the
> example I mentioned earlier, becomes irrelevant.

I am sorry i was unclear. The warning co-ordinate ranges are a property of
the train which is being warned about. Trains near that train request the
warning co-ordinates and then act upon them. The choice of requesting will
follow the logic mentioned above, in your text.

> I fail to see how DI speeds things up in this case besides the distance
> of the train (instead of the occupation of track sections) being used as
> a reference for setting speed restrictions, which is the potential
> advantage of DI in general and not specific to junctions.
>
> With the current mechanism for interlocking, you can also split
> junctions into smaller parts to allow multiple routes through the
> junction to be set at the same time, provided that the paths (which, in
> this case, involve track sections) are not shared across the routes
> (note that the term "path" here is used rather loosely - I mean path in
> terms of the track sections used by the routes here, not the path system
> itself).

Makes sense. CBTC (the new term) simplifies this, making it less effort to
create.

>
> From what I understand about your proposal, the main difference is that,
> instead of manually setting up routes, the list of potential routes is
> automatically created for (sub)junctions, which can potentially make
> interlocking easier. However, there are also other attempts with the
> same goal that does not involve implementing DI.

Makes sense. This just my take at it. I am currently training my sister to do
interlocking for the new raillines on the server, and it's been a very hard
process. To place two TCBs on each end of track massively simplifies things.
Reply to thread Export thread (mbox)