Home » railML newsgroups » railml.interlocking » Route conditions
Re: Route conditions [message #2229 is a reply to message #2213] Tue, 20 August 2019 14:35 Go to previous message
Thomas Nygreen JBD is currently offline  Thomas Nygreen JBD
Messages: 68
Registered: February 2017
Member
Dear Jörg,

First a minor correction: the values in railML2.4nor are "ocpManned" and "ocpUnmanned".

In railML2.4nor this attribute was introduced to put a condition on a given route, that it can only be set when the OCP is manned, or only when it is unmanned. I like your approach of instead describing how or by whom the route is set. And if it must be set locally, then naturally the OCP must be manned. The "ocpUnmanned" case corresponds to the route being just an extension of the previous one (as the entry signal is disabled) or set by Centralised Traffic Control (CTC). These cases may be included in your "automaticRouteSetting" and "automaticTrainRouting" cases, although CTC still involves an operator. Therefore, I am not sure that "manual" and "automatic" are the best choices of words, as the degree of automation vary both locally and in CTC systems.

An alternative approach would be to only reference the controller(s) that can set the route. Currently, the relations between controllers and routes are given through signalBoxes, implying that any controller of a signalBox can set all routes referenced by the signalBox. Maybe the existing relations are actually sufficient for the Norwegian cases by creating separate signalBoxes for the virtual/CTC routes.

--
Best regards,
Thomas Nygreen - Common Coordinator
 
Read Message
Read Message
Previous Topic: Defining the limits of RestrictedArea
Next Topic: Station indicator
Goto Forum:
  


Current Time: Thu May 09 01:15:44 CEST 2024