Home » railML newsgroups » railML.infrastructure » trainProtection and equipmentUsage
| trainProtection and equipmentUsage [message #281] |
Thu, 15 March 2012 13:22  |
Andreas Tanner
Messages: 52
Registered: March 2012
|
Member |
|
|
Hello friends of RailML,
the trainProtection element offers a somewhat rough classification of
train protection equipment for tracks. On the other hand, in the
timetabling scheme we have the <equipmentUsage> of a trainPart where a
predefined list is offered. I think this should be harmonized.
Best regards
Andreas Tanner.
|
|
|
|
| Re: trainProtection and equipmentUsage [message #282 is a reply to message #281] |
Sun, 18 March 2012 17:17  |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Hello Andreas,
> the trainProtection element offers a somewhat rough classification of
> train protection equipment for tracks. On the other hand, in the
> timetabling scheme we have the <equipmentUsage> of a trainPart where a
> predefined list is offered. I think this should be harmonized.
You are right, the trainProtection element within the infrastructure
scheme is still quite abstract and needs revision. Your idea is to add
the enumeration attribute
tNationalSystemsType
(ALSEN, ALSN, ASFA, ATB, ATBEG, ATBEN, ATC, ATSP, ATSS, AWS, BACC,
CIR-ELKE, CIR-ELKE2, Crocodile, CSS, DATC, EBICAB, EVM120, EVM160,
Fahrsp, GWATP, Indusi54, Indusi60, Indusi60R, Integra-Signum, KHP,
KLUBU, KVB, LS, LS90, LZB, Memor, Memor2, Mirel, PZ80, PZB90, RS4c,
SAUTC, SAUTCM, SAUTU, SCMT, SELCAB, SHP, SSC, TBL, TPWS, TVM300, TVM430,
ZSI127, ZSI90, ZSL90, ZST90, ZUB121, ZUB122, ZUB123, ZUB262)
that is being used within the timetable schema in the
trainProtectionElement object? Thus, the string attributes "system" and
"model" may become redundant. What do other users of the
trainProtectionElement think about this idea? Would you like to see the
strings substituted by the enumeration list?
Another idea of how to bring more structure inside the train detection
and protection topic was proposed in a ticket by Susanne [1]. Maybe it's
possible to combine these two ideas.
[1] http://trac.assembla.com/railML/ticket/23
---
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
| Re: trainProtection and equipmentUsage [message #412 is a reply to message #282] |
Sat, 27 October 2012 19:12 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Dear Andreas and other railML users,
>> the trainProtection element offers a somewhat rough classification of
>> train protection equipment for tracks. On the other hand, in the
>> timetabling scheme we have the <equipmentUsage> of a trainPart where a
>> predefined list is offered. I think this should be harmonized.
>
> You are right, the trainProtection element within the infrastructure
> scheme is still quite abstract and needs revision. Your idea is to add
> the enumeration attribute
>
> tNationalSystemsType
> (ALSEN, ALSN, ASFA, ATB, ATBEG, ATBEN, ATC, ATSP, ATSS, AWS, BACC,
> CIR-ELKE, CIR-ELKE2, Crocodile, CSS, DATC, EBICAB, EVM120, EVM160,
> Fahrsp, GWATP, Indusi54, Indusi60, Indusi60R, Integra-Signum, KHP,
> KLUBU, KVB, LS, LS90, LZB, Memor, Memor2, Mirel, PZ80, PZB90, RS4c,
> SAUTC, SAUTCM, SAUTU, SCMT, SELCAB, SHP, SSC, TBL, TPWS, TVM300, TVM430,
> ZSI127, ZSI90, ZSL90, ZST90, ZUB121, ZUB122, ZUB123, ZUB262)
>
> that is being used within the timetable schema in the
> trainProtectionElement object? Thus, the string attributes "system" and
> "model" may become redundant.
for the implementation of this open task I created a new trac ticket
with the following content [1]:
For railML 2.2 the infrastructure element trainProtectionElement should
be enhanced with a new parameter "trainProtectionSystem" with the values
of type tNationalSystemsType. The string parameter "system" is then no
longer needed and should be marked as DEPRECATED.
[1] https://trac.assembla.com/railML/ticket/175
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
| trainProtectionElement, ETCS and balises (was: trainProtection and equipmentUsage) [message #472 is a reply to message #412] |
Tue, 27 November 2012 14:44 |
Susanne Wunsch railML
Messages: 0
Registered: January 2020
|
|
|
|
Dear Christian, Andreas and others,
Christian Rahmig <coord(at)infrastructurerailmlorg> writes:
> For railML 2.2 the infrastructure element trainProtectionElement
> should be enhanced with a new parameter "trainProtectionSystem" with
> the values of type tNationalSystemsType. The string parameter "system"
> is then no longer needed and should be marked as DEPRECATED.
In the meantime the type 'tNationalSystemsType' was enhanced by the
value 'ETCS'. As stated by Thomas Kauer at the railML-conference in
Zurich the element 'trainProtectionElement' should be somehow harmonized
with respect to ETCS.
That may be a goal for the next major release (3.0), but nevertheless we
should clarify the current semantics.
<trainProtectionElement id="tp1" pos="10.0" trainProtectionSystem="PZB90" model="500Hz"/>
<trainProtectionElement id="tp2" pos="460.0" trainProtectionSystem="PZ80" model="2000Hz"/>
<trainProtectionElement id="tp3" post="455.0" trainProtectionSystem="ETCS"/>
* PZB90, PZ80 and INDUSI60 are different hardware/software releases at
the vehicle providing different functionality. The magnets next to the
rail are the same. de:[1]
Another type for the infrastructure view at the train protection
elements is needed.
* What to do, if the value 'ETCS' is used? What does it mean?
If it's a balise, the appropriate element 'balise' or 'baliseGroup'
should be used.
If it's a GSM-R zone, the new element 'trainRadio' should be used
(attention: currently not implemented).
If it's a border of an ETCS-equipped zone the 'trainProtectionChange'
element should be used.
What else?
Any comments appreciated.
Kind regards...
Susanne
[1] http://de.wikipedia.org/wiki/Punktf%C3%B6rmige_Zugbeeinfluss ung
--
Susanne Wunsch
Schema Coordinator: railML.common
|
|
|
|
| Re: trainProtectionElement, ETCS and balises [message #473 is a reply to message #472] |
Sun, 02 December 2012 10:22 |
Christian Rahmig
Messages: 151
Registered: January 2011
|
Senior Member |
|
|
Dear Susanne and other railML users,
> <trainProtectionElement id="tp1" pos="10.0" trainProtectionSystem="PZB90" model="500Hz"/>
> <trainProtectionElement id="tp2" pos="460.0" trainProtectionSystem="PZ80" model="2000Hz"/>
> <trainProtectionElement id="tp3" post="455.0" trainProtectionSystem="ETCS"/>
>
> * PZB90, PZ80 and INDUSI60 are different hardware/software releases at
> the vehicle providing different functionality. The magnets next to the
> rail are the same. de:[1]
>
> Another type for the infrastructure view at the train protection
> elements is needed.
I agree with you and consequently we should throw out all enumaration
values that further define the train protection system. Alternatively, I
suggest to define two separate lists for listing train protection
systems. The first one focuses on the train protection system device
installed to the train and contains the enumeration values as currently
available in "tNationalSystemsType". Maybe we should rename it
"tNationalSystemsTypeForVehicle"? The second list
"tNationalSystemsTypeOnRail" might be shorter because of discarding
values such as 'IndusiXY' and summarizing them to 'PZB'.
> * What to do, if the value 'ETCS' is used? What does it mean?
>
> If it's a balise, the appropriate element 'balise' or 'baliseGroup'
> should be used.
>
> If it's a GSM-R zone, the new element 'trainRadio' should be used
> (attention: currently not implemented).
>
> If it's a border of an ETCS-equipped zone the 'trainProtectionChange'
> element should be used.
In my opinion, the value 'ETCS' should only be used in case I need to
define the position of an ETCS train protection element without knowing
the certain train protection element type (balise, loop, ...).
> [1] http://de.wikipedia.org/wiki/Punktf%C3%B6rmige_Zugbeeinfluss ung
Regards
--
Christian Rahmig
railML.infrastructure coordinator
|
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Wed Sep 18 10:02:03 CEST 2024
|
Members
Search
Help
Login
Home
