Home » railML newsgroups » railml.interlocking » Route conditions
Route conditions [message #2213] Fri, 05 July 2019 10:32 Go to next message
Jörg von Lingen is currently offline  Jörg von Lingen
Messages: 86
Registered: March 2016
Member
Dear all,

in the railML2.4nor the characteristics of a route are extended by the attribute
@conditional with possible values "manned"/"unmanned" with respect to the
related OCP.

In case to include this in railML3.x I would suggest the following attribute values:

- manual = route is set only manually by operator, equals "manned"

- automaticRouteSetting = route is set only automatically by interlocking if
triggered, equals "unmanned"

- automaticTrainRouting = route is set only automatically by a train management
system (TMS)

Do we need also combinations of these values? Are there any other suggestions?


--
Best regards,
Joerg v. Lingen - Interlocking Coordinator
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
Previous Topic: Defining the limits of RestrictedArea
Next Topic: Station indicator
Goto Forum:
  


Current Time: Fri Mar 29 01:38:54 CET 2024