|
|
| 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   |
christian.rahmig
Messages: 474
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:06My 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 |
Thomas Nygreen
Messages: 78
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 |
Thomas Nygreen
Messages: 78
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
|
|
|
|
Members
Search
Help
Login
Home
