Home » railML newsgroups » railml.interlocking » Overlaps mith multiple release timers and release sections? (Question about how to handle an overlap with multiple timers and release sections in railML)
Overlaps mith multiple release timers and release sections? [message #3729] Mon, 29 September 2025 14:59 Go to next message
Jim Kjellberg is currently offline  Jim Kjellberg
Messages: 6
Registered: January 2025
Junior Member
Hello Interlocking forum.
I'm working on an exporter tool from Trafikverket internal Proprietary information system to railML-file with interlocking schema and I have ran into a problem that I don't really know how to solve nicely.

The problem is a struggle to represent all the data from our internal system in the railML format.
A route can consist of multiple tvd-sections and have different release conditions at the overlap dependning on the type of route (for example shunting route or normal route).

As an example:

A normal route has a release timer of 0s with condition "startTimerUponOccupation" on the last tvd-section.

A shunting route ending at the same overlap can have a timer of 90s "startTimerAfterVacating" on the second to last tvd-section and condition "startTimerUponOccupation" on the last tvd-section. (The data doesn't specify if it is AND or OR logic that is applied.)

I feel like I would need multiple <OverlapRelease>'s for one <Overlap> in order to put all of this information into the railML-file.

In version 3.2 a <Overlap> can have only one <OverlapRelease> with only one <releaseTriggerSection>, which makes it difficult to put in all information from the case mentioned above with a shunting route, because there are two of them.

Why there are two of them in my data I don't know or fully understand, since to my understanding you can't vacate the second to last one before occupying the last one, since the first axle of the train will occupy the last tvd-section before the last axle clears the second to last tvd-section.

Best Regards
Jim Kjellberg
Systems Developer
Trafikverket

Report message to a moderator

Re: Overlaps mith multiple release timers and release sections? [message #3780 is a reply to message #3729] Fri, 31 October 2025 16:09 Go to previous messageGo to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 107
Registered: March 2016
Senior Member
Dear Jim,

in railML you would need to define one overlap per release conditions. Multiple overlaps can be referred from a route exit.
If you have several release conditions for one overlap, you would need a criteria to decide which condition is currently valid.

Can you please provide an example where you have multiple release conditions for one overlap and how you decide on validity.

Best regards,
Joerg v. Lingen - Interlocking Coordinator

Report message to a moderator

Re: Overlaps mith multiple release timers and release sections? [message #3785 is a reply to message #3780] Fri, 07 November 2025 11:13 Go to previous message
Jim Kjellberg is currently offline  Jim Kjellberg
Messages: 6
Registered: January 2025
Junior Member
Hi Joerg.

I think there is a difference in how RailML models overlaps and how Trafikverkets legacy data system models them.
In our legacy system the Overlap is defined once as the physical area too keep clear with a reference to the signal that is the ending point of all routes leading to the overlap.

The signal has timer values listed for release/unlocking (not sure on the correct translation from swedish here) for the route exit depending on route type. For example a "normal" route can have a timer of 90 seconds and a shunting route 0.

The conditions for triggering this timer is stored in the route-object that has a collection of the insulated sections that makes up the route.

Some routes have multiple conditions listed for example the second to last section can have the condition "occupied to free"
and the last section can have the condition "free to occupied". Always 0 or 1 condition per insulated section in the route, but sometimes multiple sections in the same route can have conditions.

I dont know ff this is correct and I'm trying to get hold of a co-worker with more knowledge about our Interlocking data to verify if this is correct or not.

But this means that I should be able collect all the info from the routes, overlaps and signals in the legacy system and create the needed overlaps in the railML file and then refer to them from RouteExit.

So if the legacy system have for example 3 routes ending at the same signal the resulting railML routes should refer to the same RouteExit object, and the RouteExit has relations to all the relevant Overlaps?

Regards
Jim Kjellberg
Trafikverket

Report message to a moderator

Previous Topic: Correspondence IL:trackIL und IS:track
Next Topic: Elements of supervisory control system
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Mon Dec 15 15:11:37 CET 2025