Home » railML newsgroups » railml.infrastructure » Suggested extension for operating rules (<nor:operatingRules>)
Suggested extension for operating rules [message #2283] Wed, 04 December 2019 16:13 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 89
Registered: March 2016
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 messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 260
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 messageGo to next message
Thomas Nygreen is currently offline  Thomas Nygreen
Messages: 22
Registered: March 2008
Junior 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 - Coordinator Across Schemes
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
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 27
Registered: March 2016
Junior 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
>
Previous Topic: [railML3] transfer times for connections
Next Topic: [railML 3.1] level crossing parameters
Goto Forum:
  


Current Time: Mon Mar 30 11:35:29 CEST 2020