Home » railML newsgroups » railml.common » Use railML to model parts of a large network
Use railML to model parts of a large network [message #3050] Wed, 08 February 2023 10:54 Go to next message
Thomas Langkamm is currently offline  Thomas Langkamm
Messages: 25
Registered: April 2019
Junior Member
Dear all, I wanted to discuss something that came up in the IS group but also applies to interlocking and visualization (and possibly to other schemes). The question is, how do we model part of a network? Unfortunately "just stick to the elements that you want to model" is not the correct answer. Right now we use a somewhat proprietary solution to this problem, but were wondering if this is something that railML in general should support.

Let me describe the use case first. We import a railML network as basis for our train control system, and I know two real-life situations where we need a part of a network.

(1) We're modelling importing a large network (say 50+ stations), but due to the size of the project we're doing this in stages, splitting a network in several parts. (One part could be the area controlled by one interlocking, for example, or perhaps one line.)

(2) There is construction work with new objects (tracks, switches, signals) and we model the part of the network that has changed.

In both cases we have the issue that we need to link up the newly imported file to the remaining parts in the network that we already have in our database. But we also need objects that span parts of the network like track routes, which may be only partially contained in the file. (Let's use track routes as benchmark for the rest of this post, but we could also talk about regions, lines, operational points and more.)

Consider the following track plan:


Assume that the red markers show the boundary of the area, and we're currently importing the part to the left. (The part to the right would be contained in a different track plan, and let's say we have already imported that one.) So left = track plan A (new), right = track plan B (old). We need to define the track routes starting at S01 and the ones ending in S04, all of which cross the border. Which means our "partial track plan" can't end at the red markers but must contain some extra elements, at the very least the part of the network containing the tracks to S05 and S07 (plus possible tracks required to define overlaps, flank conditions and flank overlaps).

Now we basically have two choices.
(a) Have overlapping track plans and full redundancy. That is, the part I showed here would be contained in both track plans A and B, including the definition of the track routes. Both track plans contain all objects and the full details of all objects in the affected area. (Meaning all the objects including the ones not displayed on the track plan like balises, axle counters, markerboards and whatnot.) There is no separation in "this part is defined in this track plan" and "this part should be defined somewhere else".

(b) Have overlapping track plans, but mark some objects as "border" objects and do not use all details. For example, track plan A would have netElements for the displayed tracks, but would only contain the signals and tvdSections required to define the track routes. (For example, the platforms would be omitted as they are not relevant.) For the border objects, only very few properties would be set. For example, the signals would have an ID and a linear position, but none of the other 2 dozen attributes. And there is a clear definition which objects are border objects, and conversely we know which objects are defined in this plan. Which allows us to separate the network into disjoint sections, while maintaining only a minimum of "border" objects that are redundant.

Now, plan (a) would already be supported by railML. But there is two very important arguments against it, and the first one is this: Redundancies are bad. We all know that if we keep the same data in two or more places, there is always a risk that we update only one plan and have diverging plans. From a software standpoint, it would be undefined what happens if we have conflicting data because the same area is contained in two plans, but modelled differently. Now it is fairly clear that these border elements should be in an area as simple as possible. (So we'd never cut track plans in a station with 4 tracks, 10 parking tracks and 20 switches. Let's try to find an area with 1 or 2 tracks and no switches to make the cut.) But still, some of our track routes may be long and therefore the redundant part, modelled in both track plans, might be long. (Happens a lot in areas where we have two tracks, one for each direction, but some track routes going against the normal direction.) Which gives a lot of opportunities to make errors.

The second issue with the redundancy approach is: How would you detect if objects were deleted? Say some object O is in plan B and not plan A, and we're importing plan A. Was O removed (say a signal that got dismantled), or is it simply an object that is part of B and not modelled in A? (This sounds obvious if you see the track plan visually with a "left = A, right = B" marker. But it's not obvious at all for an algorithm that tries to decide which objects need to be deleted.

Therefore we currently use plan (b). Which is, unfortunately, not supported by railML. But it's fairly straightforward. All we need is to tag some objects as "border", and our import knows that these border object either exist in our database (in which case we can create the track routes) or they don't (in which case we'll throw a warning that we can't create the track routes because objects are missing). Our import also ignores everything but the ID from border objects, so there is no need to enter a gazillion properties. (We'll still try to make our cuts in "simple" areas where we have a minimum of tracks, track routes, switches and so on.)

What do you think? Would it make sense to include such concepts in railML, to better support the splitting of track plans?
  • Attachment: borders.pdf
    (Size: 12.63KB, Downloaded 198 times)
Re: Use railML to model parts of a large network [message #3064 is a reply to message #3050] Tue, 28 March 2023 11:35 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 68
Registered: March 2008
Dear Thomas,

My apologies for the somewhat delayed response!

Given that you mention netElements, I assume that you are using railML 3.

Your question is a timeless one, and it has been discussed in the community longer than I have been a part of it. In addition to the challenges you mention, I'd like to add that you also need a strategy to stop domino effects that could lead to the whole network being included. It is not possible to find a point where you do not have any references from the inside to the outside. So you either need to include the referenced elements outside your selected area, or you need a strategy for references to elements not contained in the exported file. This is one of the reasons for supporting UUIDs in railML 3.

Using UUIDs means that you can apply choice (a) with no or minimal overlap. Actually, having a sharp cut as your description of choice (a) seems to imply, does not work without some mechanism to reference outside elements. Without it, you would need a "tail" of referenced elements, which would need to have fewer details so that they in turn do not reference even more elements, leading you towards choice (b).

If you do use choice (b), there is a <project> element, with a <projectArea>, particularly suited to situation (2). This lets you define the affected area by referencing a <genericArea>, which in turn references your border elements (either actual <border type="area"> elements or other infrastructure elements).

Best regards,

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Use railML to model parts of a large network [message #3136 is a reply to message #3064] Fri, 29 September 2023 14:49 Go to previous messageGo to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 38
Registered: November 2022
Dear all

railML.org and its partners actively developed approaches to split and connect the railway network this year. The intermediate result is two approaches: placeholder and connector published in a paper at the conference [1].

railML.org partners (Siemens, Thales, PSI Transcom GmbH) have also proposed their own approaches: intrinsic coordinate, splitting of functional infrastructure elements, etc.

Currently, the connector approach of [1] is being implemented and somehow worked to split and connect railway lines for routes that combine them. However, during the meeting of the NEST working group, it happened that there is a reverse task to split the railway network into lines.

The planned result of the development process is a set of guidelines published at wiki unifying splitting and connecting infrastructure.

Thus, please provide some example data and use cases for splitting (input, desired output, e.g. we have a network in one file but want to have a single line per file) to generalise the developed tool (future guidelines).

This request is related to both railML2 and railML3 users as a tool is closely related to the railML ontology development process [2] i.e. allows for splitting railML2 files after their transformation to railML3.

[1] https://www.dlr.de/fs/Portaldata/16/Resources/dokumente/beri chtsreihe/Volume_40_5th_SmartRaCon_Scientific_Seminar_2023.p df#page=176

[2] https://www.railml.org/en/public-relations/news/reader/railm l-ontology-subgroup-started.html

Summarising all the above there is an ongoing development of guidelines to split and connect infrastructure and railML.org kindly asks you to provide your use cases.


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Use railML to model parts of a large network [message #3244 is a reply to message #3136] Mon, 13 May 2024 16:21 Go to previous messageGo to next message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 38
Registered: November 2022
Dear all

The current intermediate result after half a year of the work on the "splitting" topic is a document describing all the requirements gathered from the infrastructure and interlocking working groups [1]. railML.org still follows the connector approach at the topology level [2, Figure 2 on page 6].

Please reply whether these meet your expectations so far and keep in mind that they are currently rather rough as are in the draft stage! The use case template is used not officially, only in illustrative purpose.

The document [1] consists of many pages therefore please see a short summary below.

NEST working group requested splitting network into railway lines.
ETCS working group requested splitting lines into line sections and stations.
SCTP working group requested splitting everywhere, but this is currently interpreted as splitting tracks into parts.

For all of these requests valid railML files (input -> split -> merged) are produced.

railML.org plans the further work as follows (phases may overlap):
- the review by users;
- producing description of best practices in wiki;
- elaboration of interlocking part e.g. handling routes.

See also related forum posts on restricting linearPositioningSystem [3] and aggregation principles [4] inspired by this "splitting" initiative! Hopefully this will give more context to them.

[1] https://cloud.railml.org/s/GddqjsSYoacY5ee
[2] https://cloud.railml.org/s/wFeHeFAgPEbwaRA
[3] https://www.railml.org/forum/index.php?t=msg&th=946& start=0&
[4] https://www.railml.org/forum/index.php?t=msg&th=948& start=0&


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: Use railML to model parts of a large network [message #3262 is a reply to message #3244] Sat, 22 June 2024 07:32 Go to previous message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 89
Registered: March 2016
Dear all,

for splitting of infrastructure you have to consider the perspectives in order to get consistent and complete data for routes and each and everything. Splitting at arbitrary positions will mostly not work.

ETCS perspective
The splitting shall be done at RBC borders. The RBC does know (control) any infrastrture only until the border balise. Thus it authorises MA only until its border (handing over RBC). Any information beyond this border will be provided by the accepting RBC. This will allow MA across the border.
The relation from RBC to interlockings (SignalBox) is always 1:n. Thus one signalbox communicates only with one RBC.

Interlocking perspective
From history a relay interlocking did cover at least one station. Thus the station routes did end at the station border. This is achieved with the construct of virtual signal "Line Interface" which is located at the position of the home signal. Thus any exit route (operational from exit signal to first block signal) is for the interlocking from exit signal to line interface as first part and from line interface to first block signal as second part. Thus there can be an easy split at station border. In case of internal interface (station and open line controlled by same signalbox) the transfer of permissions at line interface is handled internally without additional configuration data. In case of station and open line controlled by different signalboxes the line interface is replaced by virtual signal "Block Interface". The exchange of information between the two systems is defined in IL-element <interface>. Such block interface is often located at one station border. But it can be also at any detection element on the open line. Than again each system knows (Controls) only the route part until the border. Every information needed from beyond the border is to be transmitted via the interface. Due to the features of open line there is no need to consider special data for overlaps or flank protection. The open line has neither of them.
Subsequently the splitting shall be done at signalbox borders.

In case the signalbox border is located within a station (station block) the information of overlap and flank protection has to be transferred via signal "blockInterface" as defined in <interface>.

Dr.-Ing. Jörg von Lingen - Interlocking scheme coordinator
Previous Topic: [railML3] Overview of how to deal with schema changes
Goto Forum:

Current Time: Sat Jul 20 08:57:33 CEST 2024