[railML 3.1] level crossing parameters [message #1714] |
Thu, 08 March 2018 17:20 |
christian.rahmig
Messages: 463 Registered: January 2016
|
Senior Member |
|
|
Dear all,
I would like to ask for your feedback on the following level crossing
parameters proposed for railML 3.1 implementation:
@protectionType
.... describes the technical protection of the level crossing
(doubleHalfBarrier, fullBarrier, halfBarrier, lights, none)
@activation
.... describes how the level crossing is being activated (automatic (by
train), local (by staff), remote (by staff))
@obstacleDetection [bool]
.... states whether the level crossing is equipped with technical system
for object detection (radar, camera)
@opensOnDemand [bool]
.... states whether the level crossing is by default closed for road
transport and the barriers are opened only on demand
Any comments on this implementation proposal are highly appreciated.
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
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|
Re: [railML 3.1] level crossing parameters [message #1729 is a reply to message #1714] |
Mon, 19 March 2018 09:51 |
Tobias Bregulla
Messages: 20 Registered: June 2017
|
Junior Member |
|
|
Dear Christian, dear railML community,
Some thoughts from the point of view of video-based infrastructure data
measurement on level crossings. First of all: Our modelling concepts are
far from being comprehensive and sufficient for an expert in the field
of level crossings and mainly reflect the situation in Germany and Austria.
We would therefore be very pleased to receive information from other
countries and to have a specialist discussion.
Please note the suggestions and questions under your individual points:
Am 08.03.2018 um 17:20 schrieb Christian Rahmig:> @protectionType
> ... describes the technical protection of the level crossing
> (doubleHalfBarrier, fullBarrier, halfBarrier, lights, none)
* singleFullBarrier [de: Vollschranke; DB Netz: LzV or mVS]
* doubleHalfBarrier [de: doppelte Halbschranke; DB Netz: LzHH]
* singleHalfBarrier [de: einfache Halbschranke]
* lightsOnly [de: Lichtzeichen; Lz]
* noBarrier (Saltire/Crossbuck only) [de: nichttechnisch
gesichert/ntg, nur Andreaskreuz]
* none (rarely, only in industrial plants or locomotive workshops)
[de: ohne Andreaskreuz (selten, nur in Industriegebieten oder Bahnwerken)]
Question 1: However, a distinction between level crossings “With
barriers AND lights [de-DB Netz: LzV = Lichtzeichen+Vollschranke]” and
“With barriers but WITHOUT lights [de-DB Netz: mVS = mechanische
Vollschranke]” does not seem possible; perhaps a different detailing
would be more useful?
Question 2: What about "gates" as level crossing protection? Such gates
(which sometimes blocking the railways tracks too, when not used) are
common in Scotland and Ireland IMHO (see
https://www.youtube.com/watch?v=Xh8Xl6t7Oqg for an example). Shall they
included into the barriers in the Middle Europeas sense or should a
distinction be modelled?
> @activation
> ... describes how the level crossing is being activated (automatic (by
> train), local (by staff), remote (by staff))
* infrastructureRoute (IM will care for closing, but level crossing
will activated by setting the train route under normal conditions) [de:
Hp-abhängig]
* infrastructureManual (IM will care for closing, by station master or
signal box/CTC operator or level-crossing attendant)
* trainAutomatic (RU will 'care' for closing [de: zugbediente
Einschaltung Fü/Lo]
* none (default value for @protectionType:nonTechnicallySecured and
@protectionType:none; rarely for the others, when level crossing is
available but closed forever)
> @obstacleDetection [bool]
> ... states whether the level crossing is equipped with technical system
> for object detection (radar, camera)
This causes the question of a missing (optional) attribute, therefore I
suggest to avoid such a optional boolean value.
In addition, a distinction should be made or a clear description given
between monitoring the functionality of the level crossing and
obstacle-free detection of the intersection area.
> @opensOnDemand [bool]
> ... states whether the level crossing is by default closed for road
> transport and the barriers are opened only on demand
This causes the question of a missing (optional) attribute too. For us
the use case of this attribute is not very clear in the railML 3 domain.
Best regards,
Tobias Bregulla and the whole Bahnkonzept team
|
|
|
Re: [railML3] level crossing parameters [message #2399 is a reply to message #1729] |
Mon, 16 March 2020 11:54 |
christian.rahmig
Messages: 463 Registered: January 2016
|
Senior Member |
|
|
Dear all,
the railML 3 model use case working group "ETCS Track Net" discussed requirements for modelling level crossings considering their specific use case. In the consequence, the following model adaptations are being suggested (cp. [1]):
(1) Extend <levelCrossingIS>
- @etcsID to put the ETCS variable value NID_TSR or NID_LX
- @disctanceToStop to put the distance in meters between the stopping point in front of the level crossing to the level crossing itself
- @linkedSpeedSection to reference the <speedSection> that defines the speed for passing the level crossing when being in unprotected mode.
(2) Adapt <levelCrossingIL>
- @unprotectedSpeed is marked deprecated (replaced by <levelCrossingIS>@linkedSpeedSection)
I would like to collect the feedback from the railML community beyond the ETCS working group and ask if there are any objections from other perspectives. As usual, any comments are highly appreciated...
[1] https://trac.railml.org/ticket/377
Thank you very much and best regards
Christian
Christian Rahmig – Infrastructure scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org
|
|
|