| train protection systems [message #1240] |
Wed, 07 January 2015 08:45  |
Joerg von Lingen
Messages: 148
Registered: May 2011
|
Senior Member |
|
|
Hi all,
w.r.t. the harmonisation of and semantic rules for the train protection systems
I found one rule which cannot be formally proofed:
The values of "trainProtectionMedium" and "trainProtectionMonitoring" shall be
consistent with "type" in <nationalSystem>.
As this seems to be a fixed 1:1 relation I would propose to extend the
accompanied file TrainProtectionSystems.xml by this information to allow a
formal check.
--
Best regards,
Joerg v. Lingen
Rollingstock Coordinator
|
|
|
|
| Re: train protection systems [message #1244 is a reply to message #1240] |
Mon, 09 February 2015 10:24  |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Dear Joerg,
dear everyone,
Am 07.01.2015 um 08:45 schrieb Joerg von Lingen:
> Hi all,
>
> w.r.t. the harmonisation of and semantic rules for the train protection systems
> I found one rule which cannot be formally proofed:
> The values of "trainProtectionMedium" and "trainProtectionMonitoring" shall be
> consistent with "type" in <nationalSystem>.
>
> As this seems to be a fixed 1:1 relation I would propose to extend the
> accompanied file TrainProtectionSystems.xml by this information to allow a
> formal check.
that's indeed a good idea. If I understood you correctly, you propose to
extend the current structure in TrainProtectionSystems.xml to something
like this:
<trainProtectionSystems ...>
<trainProtectionSystemsAtTrack>
<name />
<validFor />
<medium />
<monitoring />
</trainProtectionSystemsAtTrack>
<trainProtectionSystemsOnVehicle>
<!-- [...] -->
</trainProtectionSystemsOnVehicle>
</trainProtectionSystems>
<medium> defines the physical medium of the train protection system and
shall provide a value of the current enumeration tTrainProtectionMedium
(cable, inductive, radio, mechanical, optical...).
<monitoring> defines the coverage of a train protection system and
refers to the values of the enumeration tTrainProtectionMonitoring
(intermittent, continuous).
Any comments on this proposal are very welcome...
Best regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
| Re: train protection systems [message #1248 is a reply to message #1244] |
Fri, 08 May 2015 19:22 |
Dirk Bräuer
Messages: 311
Registered: August 2008
|
Senior Member |
|
|
Dear Joerg and Christian,
I can possibly help to clarify this matter a little bit. Probably these
"medium" and "monitoring" go back to the very roots of railML when we
(at Fraunhofer Dresden / TU Dresden then) filled the first structures
with all we knew - with or without practical background...
If so, and if there was no usage of these values in the years since
then, we possibly can omit at least the "monitoring". It is very
theoretical and has never had a real background. It is only that we did
teach the students things about Zugbeeinflussungsanlagen from a German
point of view like
PZB = punktförmig; induktiv, mechanisch, optisch...
LZB = linienförmig, Kabel oder Schiene...
ATP = punktförmig, magnetisch
Krokodil...
We should avoid the "monitoring" = [intermittent, continuous] since
Zugbeeinflussungsanlagen like ZUB (HF-Technik, Induktionsschleifen) and
ETCS (radio) are hybrids, they are a kind of semi-continuous. I think
nobody here (in railML) needs this rather academic information.
We can possibly also discard the "medium" if we have a certain attribute
for type/model/series such as "PZB80". "I60", "LZB90", "LZB500",
"ZUB121" a. s. o. If so, everybody can deduce the "medium" from the
type. Also, some types (as ZUB121) can have several mediums (HF-Balisen
and Induktionsschleifen).
Best regards,
Dirk.
|
|
|
|
Members
Search
Help
Login
Home
