Suggested extension for operating rules [message #2283] |
Wed, 04 December 2019 16:13 ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Torben Brand
Messages: 162 Registered: March 2016
|
Senior Member |
|
|
Many objects mapped by railML2.4 have special operating rules. The norwegian sector suggests a new trunk element <operatingRules> which will group and map those special rules. Only special rules that differ from the generic rule book and apply for specific physical objects are mapped. The generic rule book shall not be mapped here!
As the same rule can apply for multiple objects, we form a list of rules that can be referred to from individual elements (objects).
The usage of the <operatingRules> element is optional.
For UC example see current rule book exemption for Hamar station in Norway:
https://orv.banenor.no/sjn/doku.php?id=saerbestemmelser_omra der:trafikk_ost:ost:3.6_dovrebanen_eidsvoll_-_dombas#hamar_s tasjon
We will implement the element as an <nor:> extension in railML2.4, but will deprecate its use if implemented in railML2.5/3.X
Attributes of the element
The sub element <nor:operatingRule> to the container element <nor:operatingRules> contains the standard common attributes without position (@id,@code, @name, @description)
All elements can use the extended optional attribute @ruleRef, with reference to the rule that applies for it.
Code example
<nor:operatingRules>
<nor:operatingRule id="id62" code="HMR1" name="old signal bulb" description="Signal shows orange instead of white aspect"/>
</nor:operatingRules>
...
<signal id="si52" ruleRef="id62"/>
Question: Reference to only one rule enough? Work-around to bunde multiple rules in one rule. Or do we need to make a sub element (if possible on all elements?)
What does the community think?
|
|
|
Re: Suggested extension for operating rules [message #2288 is a reply to message #2283] |
Fri, 06 December 2019 20:54 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
christian.rahmig
Messages: 465 Registered: January 2016
|
Senior Member |
|
|
Dear Torben,
thank you for your detailed proposal on introducing "operating rules" in the railML standard. Like you, I am very interested in opinions from the community...
As infrastructure coordinator I have to add the following (central) question:
Are operating rules correctly located within the infrastructure scheme? Or do they belong to an own (not yet existing) scheme?
To answer this question, we should look at the references to existing elements and schemes: Your example shows that operating rules are referenced by infrastructure elements, where they apply. How about references from timetable and interlocking? If such references exist, operating rules should be placed in the common part of the schema.
Best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
Re: Suggested extension for operating rules [message #2352 is a reply to message #2288] |
Wed, 26 February 2020 17:11 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Thomas Nygreen
Messages: 75 Registered: March 2008
|
Member |
|
|
Dear Torben,
Dear Christian,
The rules that Torben link to concern how the infrastructure can be used. As such, they may belong with interlocking (in 3.x)?
Unlike the rules in the link, the example that Torben provides above, is to me not a rule, but a comment or information about a property of the infrastructure. It is maybe best handled as some kind of annotation on the signal element.
Another example, which is more like a rule is the following extract from the page Torben linked to:
Shunting signal R11
The driver of a vehicle shall always report to the local dispatcher. Train radio shall be used for the communication. If the way is free then permission will be given by shunting signal R11 using aspect 44 "Cautious shunting allowed" or aspect 45 "Shunting allowed".
I think this could be solved in the way Torben proposes, or very similarly by referencing the rule from a route element (in 3.x), where it would be a kind of verbal constraint on the route.
Best,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
Re: [railML3] Suggested extension for operating rules [message #2392 is a reply to message #2352] |
Wed, 11 March 2020 06:34 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) ![Go to next message Go to next message](/forum/theme/default/images/down.png) |
Jörg von Lingen
Messages: 91 Registered: March 2016
|
Member |
|
|
Hi,
the currently discussed operating rules are not a direct characteristic of the infrastructure. They seem to be related
more to the interlocking functions. However, we shall investigate how operators typically collect such rules. Are they
aggregated by station, signal box or other criteria. This would give the hint where to place them.
In the give example of "Hamar stasjon" I would collect them per signal box. Thus making a child list of <signalBox> for
these operational rules.
Regards,
Jörg von Lingen - Interlocking Coordinator
Thomas Nygreen wrote on 26.02.2020 17:11:
> Dear Torben,
> Dear Christian,
>
> The rules that Torben link to concern how the infrastructure
> can be used. As such, they may belong with interlocking (in
> 3.x)?
>
> Unlike the rules in the link, the example that Torben
> provides above, is to me not a rule, but a comment or
> information about a property of the infrastructure. It is
> maybe best handled as some kind of annotation on the signal
> element.
>
> Another example, which is more like a rule is the following
> extract from the page Torben linked to:
>
> Shunting signal R11
>
> The driver of a vehicle shall always report to the local
> dispatcher. Train radio shall be used for the communication.
> If the way is free then permission will be given by shunting
> signal R11 using aspect 44 "Cautious shunting allowed" or
> aspect 45 "Shunting allowed".
>
> I think this could be solved in the way Torben proposes, or
> very similarly by referencing the rule from a route element
> (in 3.x), where it would be a kind of verbal constraint on
> the route.
>
> Best,
> Thomas
>
|
|
|
|
Re: [railML3] Suggested extension for operating rules [message #2686 is a reply to message #2453] |
Thu, 25 March 2021 12:47 ![Go to previous message Go to previous message](/forum/theme/default/images/up.png) |
Thomas Nygreen
Messages: 75 Registered: March 2008
|
Member |
|
|
Dear Morten,
Can you please describe a use case or some examples of operating rules that you and your colleagues need? Specifically, do you really have operating rules on timetable objects?
Best regards,
Thomas
Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|