Home » railML newsgroups » railML.infrastructure » Missing attributes and maybe elements in railML3.2 for RTCI-a
Missing attributes and maybe elements in railML3.2 for RTCI-a [message #3133] Thu, 21 September 2023 21:27 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 169
Registered: March 2016
Senior Member
The mapping in post "Requirements for RTCI-a (Infrastructure) UC"
https://www.railml.org/forum/index.php?t=msg&th=922& start=0&
has revealed that all items are present in railML2.5 (and in railML2.4nor) and most items are present in railmL3.2. But some are missing and some might be missing.

These are in prioritised order:
- Tunnel resistance
- Electrification change (macroscopic)
- Train protection system change (macroscopic)
- Operational rules

The items are introduced bellow. If there are development ideas for railmL3.3 I suggest to make a separate post.

Tunnel (resistance)
Uses <overCrossing> but is missing resistance factor attribute.
in railML2.5 used: tunnel@resistanceFactorPassenger and @resistanceFactorFreight (https://wiki2.railml.org/wiki/IS:tunnel)
Suggest to add as new attribute in railML3.3.

Electrification change
Purpose is macroscopic system change e.g. none vs overhead. See example in Network statement:
https://networkstatement.banenor.no/doku.php?id=vedlegg:elek trifiserte_linjer
Can we use <electrificationSection>? We only need @contactLineType="none" or "overhead" on a macro level. But is correct use of <electrificationSection>? It seems to be of more microscopic use. Or can you mix macro and micro <electrificationSection>s?
In railML2.5 used: electrificationChange@type
https://wiki2.railml.org/wiki/IS:electrificationChange

Train protection system change
Purpose is macroscopic system change e.g. none vs ETCS. See example in Network statement:
https://networkstatement.banenor.no/doku.php?id=vedlegg:syst em_for_automatisk_hastighetsovervaking
Can we use <trainProtectionElement>? Only need @trainProtectionSystem. Is it correct to use <trainProtectionElement> for change on macroscopic level?
In railML2.5 used: trainProtectionChange@trainProtectionSystem with values from TrainProtectionSystems.xml/trainProtectionSystemsAtTrack.
https://wiki2.railml.org/wiki/IS:trainProtectionChange

Operational rules
This element seems to be missing in railML3.
In railML2.5 used : <operatingRules> under <infrastructure>.
https://wiki2.railml.org/wiki/IS:operatingRule
Was decided to be under <common> in railML3? But is not implemented.

Report message to a moderator

Re: Missing attributes and maybe elements in railML3.2 for RTCI-a [message #3145 is a reply to message #3133] Wed, 18 October 2023 17:33 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear Torben,

thank you very much for your specific proposals on extending railML 3 data model w.r.t. RTCI use case requirements. Let me comment on them one by one:

(1) tunnel resistance
Adding the attributes @resistanceFactorPassenger and @resistanceFactorFreight to element <overCrossing> seems to be a straightforward adaptation of railML 3 data model [1]. However, it is only half of the solution railML 2.5 provides, where a tunnel resistance can also be calculated from wall material and tunnel cross-section. So, dear community, are you fine with just the tunnel resistance factors, or do you need wall material and tunnel cross-section, too?

(2) Electrification change
Electrification related parameters can be linked with the railway network (topology) by <electrificationSection> elements and their <*Location> child elements. For microscopic modelling, you would most likely use <linearLocation>, but it is also possible to aggregate a bigger number of netElements with an <areaLocation> and thus define a certain electrification setting in a rather "macroscopic style". It is also possible to use <networkLocation> to link the electrification section with a complete network (level). So, you are very flexible here.

(3) Train protection system change
The concept for train protection system changes is similar to the electrification change issue in (2). Maybe, the term "trainProtectionSection" would be better than "trainProtectionElement" if we want to describe a certain train protection system setting in a rather macroscopic style. So, dear community, what do you think: do we need an <trainProtectionSection> in addition to a <trainProtectionElement> or shall we rename <trainProtectionElement> into <trainProtectionSection> or shall we leave everything as it is?

(4) Operational rules
This element is not part of railML 3.2 data model as it was not required by the use cases that have been implemented so far. So, if RTCI needs operational rules, we are free to extend the model with the most appropriate solution. Is there anyone from the community, who needs operational rules as well, and if so, for which use case?

Thank you very much and best regards
Christian

[1] https://www.railml.org/forum/index.php?t=msg&th=486& goto=1460&#msg_1460

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: Missing attributes and maybe elements in railML3.2 for RTCI-a [message #3172 is a reply to message #3145] Thu, 07 December 2023 13:02 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 79
Registered: March 2008
Member
christian.rahmig wrote on Wed, 18 October 2023 17:33

(3) Train protection system change
The concept for train protection system changes is similar to the electrification change issue in (2). Maybe, the term "trainProtectionSection" would be better than "trainProtectionElement" if we want to describe a certain train protection system setting in a rather macroscopic style. So, dear community, what do you think: do we need an <trainProtectionSection> in addition to a <trainProtectionElement> or shall we rename <trainProtectionElement> into <trainProtectionSection> or shall we leave everything as it is?
To add some context for the community, railML 2 has both trainProtectionElement (for individual magnets etc.) and trainProtectionChange (for points where something about the system changes). These elements are syntactically quite similar, the main difference being that trainProtectionChange has an attribute to specify if the monitoring is intermittent, continuous or none at all. That same attribute is also present in the railML 3 element trainProtectionElement, so syntactically it has the capabilities of both the two elements from railML 2.

If we decide to use the same element for both purposes, I think we need a name that does not contain either Element or Section, as they both indicate a specific usage.

Best regards,
Thomas

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: Missing attributes and maybe elements in railML3.2 for RTCI-a [message #3180 is a reply to message #3172] Thu, 04 January 2024 13:41 Go to previous messageGo to next message
Morten Torstensen is currently offline  Morten Torstensen
Messages: 1
Registered: October 2023
Location: Oslo, Norway
Junior Member
We in Bane NOR need Operational rule references in order to do runtime calculations, because some rules affect the max allowed speed of trains in some cases. We should look into exactly how it should be modeled.



Morten Torstensen
Bane NOR - Norwegian Infrastructure Manager
Digital Information Model for railway infrastructure
Ontology, modeling, mapping

Report message to a moderator

Re: Missing attributes and maybe elements in railML3.2 for RTCI-a [message #3276 is a reply to message #3145] Mon, 12 August 2024 13:50 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear all,

following my forum posting from October there has not been any further feedback or feature request. Therefore, I suggest the following solution for railML 3.3 implementation of element <overCrossing>:

* add attribute @resistanceFactorPassenger to describe the tunnel resistance factor valid for passenger trains running through this tunnel
* add attribute @resistanceFactorFreight to describe the tunnel resistance factor valid for freight trains running through this tunnel.

The proposed solution is documented in the Git issue https://development.railml.org/railml/version3/-/issues/563


christian.rahmig wrote on Wed, 18 October 2023 17:33
...
(1) tunnel resistance
Adding the attributes @resistanceFactorPassenger and @resistanceFactorFreight to element <overCrossing> seems to be a straightforward adaptation of railML 3 data model [1]. However, it is only half of the solution railML 2.5 provides, where a tunnel resistance can also be calculated from wall material and tunnel cross-section. So, dear community, are you fine with just the tunnel resistance factors, or do you need wall material and tunnel cross-section, too?
Best regards

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Re: [railML3] tunnel resistance [message #3323 is a reply to message #3276] Mon, 16 September 2024 11:15 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 474
Registered: January 2016
Senior Member
Dear all,

in the last SCTP developer group meeting on September 13, 2024, an alternative solution for tunnel resistance has been discussed. In particular, the proposal looks like this:

* add optional child element <tunnelResistance> in functional infrastructure element <overCrossing>
* in <tunnelResistance> add optional attribute @crossSection (Tunnelröhren-Querschnitt in qm) and extendable optional enumeration attribute @wallConstructionType (Tunnelwand-Material: rock, quarrystone, brick, concrete, other)
* in <tunnelResistance> add optional repeatable child element <resistanceFactor> with mandatory attribute @value (in kg/m) and mandatory enumeration attribute @type (enumeration: passenger, freight, mixed, other)

Is there any objection or feedback for this solution?

Thank you very much and best regards
Christian


christian.rahmig wrote on Mon, 12 August 2024 13:50
Dear all,

following my forum posting from October there has not been any further feedback or feature request. Therefore, I suggest the following solution for railML 3.3 implementation of element <overCrossing>:

* add attribute @resistanceFactorPassenger to describe the tunnel resistance factor valid for passenger trains running through this tunnel
* add attribute @resistanceFactorFreight to describe the tunnel resistance factor valid for freight trains running through this tunnel.

The proposed solution is documented in the Git issue https://development.railml.org/railml/version3/-/issues/563

Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Previous Topic: [railML3] Regular and a track of the opposite direction
Next Topic: [railML3] Tunnel infrastructure
Goto Forum:
  

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

Current Time: Thu Dec 05 14:58:45 CET 2024