Home » railML newsgroups » railml.infrastructure » railML 2.3 infrastructure extension proposal switch / crossing (railML 2.3 infrastructure extension proposal switch / crossing)
railML 2.3 infrastructure extension proposal switch / crossing [message #1459] Tue, 20 December 2016 18:31 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 19
Registered: March 2016
Junior Member
Dear railML infrastructure forum,
This posting contains the discussion to an extension towards the
switch &crossing
We need to define which controller controls a switch or crossing, and how.
The elements <crossing> and <switch> are extended with the new attribute @NO:levelOfControll with the preset values: "controlled","supervised" or "unsupervised"
The elements <crossing> and <switch> are extended with the new attributes @controllerRef and @NO:typicalThrowTime [datatype: time in seconds]
The last attribute is needed as we need to define the average time a switch uses from the command is given in the interlocking to turn the switch and its points are indicated locked in the interlocking in the new position.
Re: railML 2.3 infrastructure extension proposal switch / crossing [message #1471 is a reply to message #1459] Mon, 02 January 2017 17:30 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 37
Registered: January 2016
Member
Dear Torben,

Am 20.12.2016 um 18:31 schrieb Torben Brand:
> [...]
> switch &crossing
> We need to define which controller controls a switch or
> crossing, and how. The elements <crossing> and <switch> are extended
> with the
> new attribute @NO:levelOfControll with the preset values:
> "controlled","supervised" or "unsupervised"

This attribute is misleading as in the end all switches and crossings
are somehow controlled (even if it is manually controlled). Can you
please clarify this requirement by providing some more information about
the use case behind?

> The elements <crossing> and <switch> are extended with the
> new attributes @controllerRef and @NO:typicalThrowTime
> [datatype: time in seconds]

These two suggested parameters make sense to me. In fact, all
infrastructure elements that can be incorporated in an interlocking
controlling, may have a reference to a controller. Alternatively (from
an interlocking point of view), the controller/interlocking shall
reference all the infrastructure elements that it controls. We should
decide for one direction of referencing, but not implement both.

> The last attribute is needed as we need to define the
> average time a switch uses from the command is given in the
> interlocking to turn the switch and its points are indicated
> locked in the interlocking in the new position.

Understood. However, instead of a "typical" throw time, which may vary a
lot, I prefer defining a "minimumThrowTime" and/or a "maximumThrowTime".

Best regards
Christian

--
Christian Rahmig - Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Phone Coordinator: +49 173 2714509; railML.org: +49 351 47582911
Altplauen 19h; 01187 Dresden; Germany www.railml.org
Re: railML 2.3 infrastructure extension proposal switch / crossing [message #1513 is a reply to message #1471] Fri, 24 February 2017 15:57 Go to previous message
Torben Brand is currently offline  Torben Brand
Messages: 19
Registered: March 2016
Junior Member
Chrtistian Rahmig wrote:
This attribute [@NO:levelOfControll] is misleading as in the end all switches and crossings
are somehow controlled (even if it is manually controlled). Can you
please clarify this requirement by providing some more information about
the use case behind?


My answer:
True, all switches must be controlled. So the use of the word "control" and "controlled" are misleading. I will use other terms here. What I mean is that we need to define if the switch position is indicated remotely. This usually in the interlocking, but it could also be in simpler none interlocking devices like a switch tableau. Further we need to know if the switch is operated at the switch or remotely. Remotely from a central operator, usually by a dispatcher through the interlocking, but also simpler by a local central operator/ shunting personnel through a switch tableau. The combination of the two states form three possible combinations:
- indicated in interlocking/tableau and remote operated (by same)
- indicated in interlocking but operated at the switch
- not indicated in interlocking and operated at the switch.
The fourth combination, remote operated but not indicated is not logical.
Alternatively, we could just make it clean and use:
<switch/crossing>@NO:positionRemoteIndicated value:bolean(yes/no)
<switch/crossing>@NO:positionRemoteOperated value:bolean(yes/no)

In fact, all
infrastructure elements that can be incorporated in an interlocking
controlling, may have a reference to a controller. Alternatively (from
an interlocking point of view), the controller/interlocking shall
reference all the infrastructure elements that it controls. We should
decide for one direction of referencing, but not implement both.


Agreed. The usual workflow in Norway is: is the switch controlled and how. Not: Which switches does this controller operate? Furthermore, the controllerRef is already implemented in railML 2.3 on the switch. So we recommend this direction.


However, instead of a "typical" throw time, which may vary a
lot, I prefer defining a "minimumThrowTime" and/or a "maximumThrowTime".
Your suggested attributes @minimumThrowTime" and @maximumThrowTime are needed in the interlocking use case and will be modelled in the interlocking schema.


For the capacity use case we need the average throw time. Thus my suggestion for element name was "averageThrowTime". But the interlocking coordinator preferred "typicalThrowTime". Obedient as I am, I bow to the coordinators... ;-) But this maybe indicates that the suggested name is misleading.

Bob writes: "attribute typicalThrowTime for movable elements is now defined: «typical throw time is the average time it takes between the moment the IL receives the call and the element reaches the new position. Point throwing adds a delay to route setting that is of great interest to the use case simulation. For this purpose, we add an attribute typicalThrowTime that allows capacity planners to estimate the influence of slow throwing points on train traffic. Note that this excludes OCS processing time and communication between OCS and IL."

Previous Topic: railml 2.3 Export only updated data from a data source
Next Topic: railML 2.3 infrastructure extension proposal tunnel resistance factor
Goto Forum:
  


Current Time: Wed Mar 29 11:15:20 CEST 2017