Home » railML newsgroups » railml.interlocking » Re: railML 2.3 infrastructure extension proposal operational properties of an OCP
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1468] Mon, 02 January 2017 17:29
christian.rahmig is currently offline  christian.rahmig
Messages: 37
Registered: January 2016
Member
Dear Torben,

Am 20.12.2016 um 18:27 schrieb Torben Brand:
> [...]
> propOperational
> In Norway trains are by default only allowed to enter a
> station one by one, due to safety reasons. If a station is
> equipped/designed with simultaneous entry features
> (NO:samtidig innkjør) trains may enter simultaneously. This
> is necessary to know for the capacity planner, timetable
> planner and train driver. The element <propOperational> is extended
> with the new
> attribute @NO:samtidigInnkjør [datatype: enumeration]. The
> attribute has 4 Norwegian preset values and the values
> "partial" and "none". The precise values of the value
> "partial" needs to be defined in another system/model.

The reasons for having the attribute seem clear to me. Can you tell us
what are the four Norwegian preset values for this parameter? Further,
instead of "partial", which is rather unspecific, I would prefer having
more concise values instead. Are there any other railways that make use
of such an attribute? If yes, I have no objections against creating a
Trac ticket and implementing this attribute with the next release.

> The attribute @operationalType is extended with the value
> "siding". In Norway a "siding" is an additional track on the
> path (section of line between stations). It is not a station
> according to Norwegian definition as it does not have a
> main-home signal. Thus the path on the siding needs to be
> blocked during the operation of entering and leaving the
> siding. PS. There is a trackType under track with value
> "sidingTrack" This is described in the Wiki as: "This is a
> siding"

Yes, railML already allows to specify a track as being a siding track by
setting <track type="sidingTrack">. However, what is missing is an
operational representation of the siding as you request it. Therefore,
your suggestion to add the enumeration value "siding" for the attribute
@operationalType seems to be valid. Is there anybody among the railML
community who needs to model sidings outside of stations, too?

> The attribute @operationalType is extended with the value
> "halt". In Norway we need to separate between a halt within
> a station and outside the station (on the path). I suggest
> to use the existing operationalType "stopingPoint" with
> halts within the station (As this correlates with the
> Norwegian name "stoppested"="stoppingplace"). And the new
> operationalType "halt" for halts on the path.

An operation control point <ocp> is located on a track indirectly via
the <crossSection> element. The track itself can be classified as a
station track or a main route track via its attribute @type. Thus, it is
possible to distinguish between an OCP within a station and an OCP
outside the station (de: "freie Strecke"). Consequently, it is not
absolutely necessary to introduce a new enumeration value "halt" for
<ocp><propOperational>@operationalType. Your example may look like this:

<track id="tr01" type="stationTrack">
<trackTopology>
<crossSections>
<crossSection id="cs01" pos="123.4" ocpRef="op01">
</crossSection>
</crossSections>
</trackTopology>
</track>
....
<ocp id="op01">
<propOperational operationalType="stoppingPoint">
</propOperational>
</ocp>

However, the solution is complex and it requires <track> elements in
order to locate the OCP via their <crossSection> elements. Your proposed
attribute adaptation would work also without tracks and it would assign
the feature directly to the OCP. Therefore, I am open for more opinions
on this issue to find a practical solution.

> It needs to be defined if a station is remote controlled (by
> CTC). Thus we have added the new bolean attribute
> @NO:remoteControlled. Later extensions could define which
> remote controller (CTC) is controlling the interlocking
> controller.

Accepted. Instead of a boolean attribute, it might be useful to define
an enumeration attribute in order to specify the type of controlling. On
the other side, the detailed definition of station control should be
done in the <controller> element and therefore your suggested solution
with the boolean attribute seems to fit well.

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
Previous Topic: Re: railML 2.3 infrastructure extension proposal - controller
Goto Forum:
  


Current Time: Thu Mar 23 23:11:30 CET 2017