Home » railML newsgroups » railML.infrastructure » How to Indicate a working process when doing a signal redesign.
How to Indicate a working process when doing a signal redesign. [message #2546] Fri, 09 October 2020 13:06 Go to next message
Georg Boasson is currently offline  Georg Boasson
Messages: 18
Registered: October 2020
Junior Member
My name is Georg Boasson and I am working at Bane NOR in Norway with implementing the ETCS signal system.

Bane NOR need to indicate the working process when doing a redesign of our signal systems. This is very valuable information in the migration phase, especially when replacing conventional signals with ETCS signals. So far, we have used an attribute in the Norwegian extension of railML2.4 to indicate "new", "removed" and "modified" elements.

My suggestion for implementation of this feature in railML3.1 will be to use the element <infrastructureState> with the sub-element <elementState> and the attributes @refersToElement and @value.

The elementState@refersToElement attribute will be used to reference any element in the infrastructure model (ex: <SignalIS@id>).

The elementState@value attribute will be used to indicate the state of the referenced element:

Removed @value="disabled" or "closed"
New --> @value="operational"
Modified --> @value="conceptual"
Unchanged --> no @value defined

Is this an acceptable way of implementation? Or anybody have other suggestions?

  • Attachment: example.xml
    (Size: 0.60KB, Downloaded 309 times)
Re: [railML3] How to Indicate a working process when doing a signal redesign. [message #2566 is a reply to message #2546] Fri, 30 October 2020 16:29 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 447
Registered: January 2016
Senior Member
Dear Georg,

welcome to the railML forum and thank you for your message!


Georg Boasson wrote on Fri, 09 October 2020 13:06
My name is Georg Boasson and I am working at Bane NOR in Norway with implementing the ETCS signal system.

Bane NOR need to indicate the working process when doing a redesign of our signal systems. This is very valuable information in the migration phase, especially when replacing conventional signals with ETCS signals. So far, we have used an attribute in the Norwegian extension of railML2.4 to indicate "new", "removed" and "modified" elements.

My suggestion for implementation of this feature in railML3.1 will be to use the element <infrastructureState> with the sub-element <elementState> and the attributes @refersToElement and @value.

The elementState@refersToElement attribute will be used to reference any element in the infrastructure model (ex: <SignalIS@id>).

The elementState@value attribute will be used to indicate the state of the referenced element:

Removed @value="disabled" or "closed"
New --> @value="operational"
Modified --> @value="conceptual"
Unchanged --> no @value defined

Is this an acceptable way of implementation? Or anybody have other suggestions?

This looks already quite good. Just few remarks:
* If the signal is (physically) removed, please use @value="closed". If it is only temporarily not operational resp. in usage, then @value="disabled" shall be used.
* A new signal, which is used in operation shall use @value="operational". If the new signal is already placed, but not yet in usage, @value="disabled" shall be used.
* The state @value="conceptual" is defined as "The construction or commissioning of the element is planned for the medium or long term. However, there are still no concrete (planning) activities for the construction of the element beyond the preliminary planning and cost estimation." So, please use it only for signals that are not yet prepared for installation. How about using @value="planned" instead?


Dear community, how do you model your signal (or other elements) in different states? Any feedback from a user perspective is very much appreciated considering the objective to improve the state model in railML 3.x.

Thank you very much and best regards
Christian



Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] How to Indicate a working process when doing a signal redesign. [message #2567 is a reply to message #2566] Fri, 30 October 2020 23:21 Go to previous messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 68
Registered: March 2008
Member
Dear Christian,

I think what Georg is after is not about describing the current state of the objects, but distinguishing new (operational) objects and modified (operational) objects from unchanged (operational) objects. This is common in planning processes, to track the changes from existing (or previously approved) infrastructure or between phases in construction projects.

Best regards,
Thomas


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Re: [railML3] How to Indicate a working process when doing a signal redesign. [message #2607 is a reply to message #2567] Fri, 04 December 2020 15:56 Go to previous message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 68
Registered: March 2008
Member
Dear all,

To recap a little: This issue was already raised by Torben three years ago. Christian created a trac ticket for it and suggested an implementation as an element rather than an attribute (in a railML 2 context). The equivalent in railML 3 would probably be an implementation similar to <elementStates>, e.g. called <elementsChanged>, where elements can be referenced and given a change type.

I have talked with Georg, who started this thread, and this feature is important in the exchange between (internal or external) signal engineers when planning a new signalling system to replace and existing one, or when planning modifications to the existing signalling system. Any comments regarding implementing this in railML 3 are most welcome!

Best regards,
Thomas


Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
Previous Topic: [railML3] Left and right track of a two-track line
Next Topic: railML 2.3 infrastructure extension proposal - "change"
Goto Forum:
  


Current Time: Thu Jul 25 20:40:21 CEST 2024