Home » railML newsgroups » railml.infrastructure » railML 2.3 infrastructure extension proposal operational properties of an OCP (railML 2.3 infrastructure extension proposal operational properties of an OCP)
railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1457] Tue, 20 December 2016 18:27 Go to next message
Torben Brand is currently offline  Torben Brand
Messages: 27
Registered: March 2016
Junior Member
Dear railML infrastructure forum,
This posting contains the discussion to an extension towards the
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 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"
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.
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.
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1466 is a reply to message #1457] Mon, 02 January 2017 17:29 Go to previous messageGo to next message
christian.rahmig is currently offline  christian.rahmig
Messages: 46
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
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1510 is a reply to message #1466] Fri, 24 February 2017 15:33 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 27
Registered: March 2016
Junior Member
Christian Rahmig wrote:
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.


My reply:
The four Norwegian generic values for simultaneous entry are: Standard, alternative 1, alternative 2 and alternative 3. For more information, see: https://trv.jbv.no/wiki/Signal/Prosjektering/Forriglingsutru stning#Samtidige_togbevegelser
The Norwegian line description book (DE:"Streckenbuch") lists the four alternatives, but also stations with "partial" functionality. This means that some routes have simultaneous entry functionality and others do not on the same OCP. This is an indicator to get more information from other sources. One future source could be the upcoming interlocking schema. An alternative would be to have a sub-element that refers to the specific routes that have simultaneous entry. This would require routes to be described in railML. Therefore, I suggest to leave it at "partial".

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.


As I read the documentation a <track>@type"mainTrack" is valid for both the path and the stations.
To be able to seperate between a main track in a station and on the path, we need to add a new value "mainStationTrack"? But this would remove the possibility for long tracks through stations. See railML wiki: mainTrack=DE:"durchgehendes Hauptgleis" and stationTrack=DE:"Bahnhofsgleis (Hauptgleis im Bahnhof) and compare to Fiedler „Bahnwesen" 5.Auflage page 311-312.
However, this is not relevant if I understand the documentation to be that there is only one main track, independent from path or station.

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.

I agree the solution is complex.
It would be easier, as you suggest, to create a new enumeration value to distinguish between a stopping point within a station (todays value "stoppingPoint") and on the path (new value "NO:halt", like I suggest.
Also alternatively, you could use value "stoppingPoint" for both and use the suggested line section extension to determine if a ocp (or any other object) is within a station or on the path. But this would again be somewhat complex and require the use of an optional new extended element. For macroscopic purposes I suggest the approach with the new enumeration "halt".
Re: railML 2.3 infrastructure extension proposal operational properties of an OCP [message #1583 is a reply to message #1466] Thu, 18 May 2017 17:51 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 213
Registered: August 2008
Senior Member
Dear Christian and Torben,

>> 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?

Yes, of course. In Germany (and other countries), we have the same type
of sidings. In Germany they are called Anschlussstelle und
Ausweichanschlussstelle depending on interlocking and operational rules.
It is an <ocp> but not a station. In both cases, the line track has to
be blocked between the adjacent stations during the operation of
entering and leaving the siding.

Currently we model such an <ocp> as follows:

<ocp id=...>
<propOperational orderChangeable='false'
ensuresTrainSequence='false' />
<propService goodsLoading='true'/>
<propEquipment>
<summary hasHomeSignals='false' hasStarterSignals='false'/>
</propEquipment>

We do not model the siding itself since there can be no train operation
at it (just shunting). The train begins and ends at the main track at
the <ocp>.

The intention of "sidingTrack" is to model any non-main track,
independently whether in stations or line-side. "Non-main track" means
tracks with no train operation, just shunting.

I think it's not necessary to explicitly distinguish between a siding of
a station or a line-side siding. Torben has already suggested to create
a possibility to assign track elements to <ocp>s. This implements the
solution to distinguish the two kinds of sidings.

Best regards,
Dirk.
New reflected thoughts towards infrastructure extension proposal operational properties of an OCP [message #1625 is a reply to message #1457] Fri, 14 July 2017 09:46 Go to previous message
Torben Brand is currently offline  Torben Brand
Messages: 27
Registered: March 2016
Junior Member
Some ocps have areas (usually stations) as others are point based (usually stopping point). But it is up to the user to define this. They can do this through referencing tracks under the existing sub element <ocp/propEquipment/trackRef>.

See aIso discussion under "line section": An alternative to lineSection type "openSection" (NO:"linjen",DE:"freihe Strecke" railML wiki "open track", term to be fixed), could be to add a new <propOperationa @operationalType="openSection". I do not recomended this, as the open section is not an ocp and ocps can overlap the open section. Thus a solution in lineSection is recomended. What do you think?

In Norway we also have ocp's on main signals in large stations that have alternative entry routes from the same neighbour ocp into the station. This is a sort of mesoscopic modelling where there is missing a microscopic route allocation defining the path into the station. Thus I suggest to add an new value for ocp @operationalType:"other:mainSignal"

I also like to suggest to add a macroscopic attribute to all ocp's a @timingPoint [absPos mileage].
Today the timing point can only be defined in an ocp microscopically on the track level as a <crossSection> which have to be defined per track. For macroscopic models the new approach would be simpler. Also historically an ocp (in Norway) has an absPos mileage timing point, where the local dispatcher used to sit. Today's remote controlled stations have no longer local dispatchers, but retain the same timing point for timetable purposes. But also additional timing points have been allocated to TVD's, for automatic time registration purposes. If we have the @timingPoint we could allocate the ocp general TT mileage there. This is used in timetabling and is deemed sufficient there. But for the use case simulation we would like to use the timing points of the TVD's. We could then use todays <crossSections> to define the automatic timing points. An alternative is to use both <crosssection>@type:"station" for the macroscopic timing point and <crosssection>@type:"autoblock" for the microscopic automatic time registration point (but I am uncertain if this is the correct use of the value "autoblock"). But this solution would lose the macroscopic advantage.
Ps. Could anyone describe the values "autoblock" and "block" @type <crossSection>? I could not find anything either in wiki, forum nor schema.

We in Norway still think it's important to have a seperate operationalType for "siding". Mapping the ocp like Dirk describes with describing the ocp's caracteristics in 6 lines with the attributes describing it in propOperational, propEquipment and propService seems less efficient as to define one unique term. We suggest to differentiate between "Anschlusstelle" and "Ausweichanschlusstelle" through use of @ensuresTrainSequence. We define all passing times for "sidings" ocp's in the TT in Norway today. So it would be usefull to differentiate them as <propOperational @operationalType="siding" in the TT as well.

I propose to retract my suggestion for a new <propOperational>@operationalType:"halt". The purpose of this was to model stopping points within stations. I think that this can be sufficient modelled through using the existing @operationalType:"stoppingPoint" in combination with a set value for <ocp>@ocpParentRef. This will indicate that the stopping point is part of another ocp presumably a station and thus in Norway a "stoppested" (stopping point within a station).
Previous Topic: railML 2.3 infrastructure extension proposal line sections
Goto Forum:
  


Current Time: Thu Jul 27 14:32:12 CEST 2017