Forum - RDF feed
https://www.railml.org/forum/index.php
Re: [railML3]: signal lamps
https://www.railml.org/forum/index.php?t=rview&goto=3216&th=786#msg_3216
Approach of [1] was enhanced in the presentation from 44-th railML conference [2] from November 2024. There is now a ticket / issue in the GitLab [3] based on [2]. Please let us know if it does not meet your expectations.
Sincerely,]]>Larissa Zhuchyi2024-03-22T12:14:58-00:00Re: New area types for railML 3.3
https://www.railml.org/forum/index.php?t=rview&goto=3210&th=940#msg_3210
This sounds very good. Adding keyLockInState and levelCrossingInState makes sense based on the refrenced forum post from Heidrun.
On the topic of referring to a trigger detector for CESA, I think it depends on what railML want to include in the standard. As I mentioned, the detector in this case would typically be a bit outside of the railway system itself, such as a fire alarm. Since that configuration is possible in our signalling system, directly effecting the state of an Emergency Stopping Area I think it also makes sense to add the possibility to model it in railML. However, are the current definitions in IL:detectorInState sufficient to do so? How would a fire alarm (or a similar detector) fit into that definition?
Best regards,
Terje Nordal]]>Terje Nordal2024-03-13T12:38:40-00:00Re: Release triggers for routes in railML 3.2
https://www.railml.org/forum/index.php?t=rview&goto=3209&th=936#msg_3209
The suggested addition of a route release trigger for <routeExit> seems to fit our use case very well. Thank you for the feedback.
Best regards,
Terje]]>Terje Nordal2024-03-13T12:05:19-00:00Re: Release triggers for routes in railML 3.2
https://www.railml.org/forum/index.php?t=rview&goto=3206&th=936#msg_3206
from Thales' perspective, for the TMS Norway project, for some routes we also need the route release trigger information as a reference to an element (either a track or a point).
That's why we would like to support the proposal from Terje.
Best regards,
Heidrun]]>heidrun.jost@thalesgroup.2024-03-12T15:05:11-00:00Reuse IL:SignalBox for Object controllers
https://www.railml.org/forum/index.php?t=rview&goto=3203&th=941#msg_3203
I work for Finnish ETCS-project, and we are planning to use railML for out engineering data needs.
Due to us moving to EULYNX based architecture, we need a model to group IL::elements to elements controlled by single or multielement controllers.
Has anybody used railML for this (with an agreed solution with signalling supplier) , and could share their solution?
Logically one could use IL:signalbox to represent object controller (in addition to CBI):
2) Set IL:controlledBy to IL:Signalbox to point to actual centralised CBI.
3) Add needed RASTA-ids, IPs of object controller as schema enhancements to IL:signalbox.
Best Regards, Ari
]]>Ari Tilli2024-03-08T10:17:34-00:00Re: [railml3] Signal types and functions
https://www.railml.org/forum/index.php?t=rview&goto=3200&th=649#msg_3200
the differentiation of values for <signalIS>@type and for <signalIL>@signalFunction are still not clear to everyone.
<signalIS>@type shall define the basic types of signals like main, distant and shunting signal. This basic classification might be enough for some user. If more details are needed than <signalIL>@signalFunction is to be used in addition covering the interlocking related functions of the signal.
In case of type="main" the possible functions can be https://wiki3.railml.org/wiki/IL:signalIL:
- block
- entry
- exit
- group
- intermediate
- intermediateStop
- junction
- trackEnd (with v3.3)
The values 'blockInterface' and 'lineInterface' are like a main signal but a supporting virtual construction used to transfer information over the border between two interlockings or between station and open line. As they are virtual and for interlocking use only they will never appear as signalIS.
The types 'shunting' and 'distant' are related to similar functions, i.e. type="shunting" + function="shunting" or type="distant" + function="distant".
--
Best regards,
Joerg v. Lingen - Interlocking Coordinator]]>Jörg von Lingen2024-03-05T05:25:59-00:00Re: [railml3] Signal types and functions
https://www.railml.org/forum/index.php?t=rview&goto=3199&th=649#msg_3199
signal/marker board placed at a buffer stop. Thus we shall add "trackEnd" for
such function. The proposed "end" might be ambiguous.
Best regards,
Joerg v. Lingen - Interlocking Coordinator
On 28.02.2024 11:56, Torben Brand wrote:
> Jernbanedirektoratet and Bane NOR need a definition.
>
> Which is the correct enumeration value to use in
> signalIL@function for an "end" markerboard (ETCS) or "end of
> route board" (conventional optical system)? This is always a
> (marker)board that is placed at a buffer stop. See example in the advanced
> example:
> https://railoscope.com/tickets/Fyh1WAZliOQbgVmY?modelId=64d2 293fb1421a4b8096c580&selectId=123-4
>
> Or should a new "other:end" value be introduced?
> ]]>Jörg von Lingen2024-03-03T07:42:37-00:00Re: [railml3] Signal types and functions
https://www.railml.org/forum/index.php?t=rview&goto=3198&th=649#msg_3198
Which is the correct enumeration value to use in signalIL@function for an "end" markerboard (ETCS) or "end of route board" (conventional optical system)? This is always a (marker)board that is placed at a buffer stop.
See example in the advanced example: https://railoscope.com/tickets/Fyh1WAZliOQbgVmY?modelId=64d2 293fb1421a4b8096c580&selectId=123-4
Or should a new "other:end" value be introduced?
]]>Torben Brand2024-02-28T10:56:38-00:00Re: Release triggers for routes in railML 3.2
https://www.railml.org/forum/index.php?t=rview&goto=3197&th=936#msg_3197
thanks for your the description of your rules and background. Let me add
the following:
1) Objects in a train route and its flank protection are
released when related TVP section is passed by the entire
train.
That's the assumed standard behaviour why it does not need extra
definition. Refer https://wiki3.railml.org/wiki/IL:routeReleaseGroupRear.
<routeReleaseGroupRear> is forseen the cases where elements are released
from route as a group by extra command.
2) final route release by train
If route release shall be independent of any associated overlap a route
release trigger can be added to the <routeExit> referring to the trigger
position with mode information (occupation, dispatcher, trainStandstill).
--
Dr.-Ing. Jörg von Lingen - Interlocking scheme coordinator]]>Jörg von Lingen2024-02-27T04:30:12-00:00Re: New area types for railML 3.3
https://www.railml.org/forum/index.php?t=rview&goto=3196&th=940#msg_3196
I have made a draft of the proposed areas in the model derived from RestrictedArea.
<xs:complexType name="DangerArea">
<xs:complexContent>
<xs:extension base="rail3:RestrictedArea">
<xs:sequence>
<xs:element name="detectorInState" type="rail3:DetectorInState"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="signalWithAspect" type="rail3:SignalWithAspect"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>