Home » railML newsgroups » railML.infrastructure » trainProtection and equipmentUsage
trainProtection and equipmentUsage [message #281] Thu, 15 March 2012 13:22 Go to next message
Andreas Tanner is currently offline  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 Go to previous messageGo to next message
Christian Rahmig is currently offline  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 Go to previous messageGo to next message
Christian Rahmig is currently offline  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 Go to previous messageGo to next message
Susanne Wunsch railML is currently offline  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 Go to previous messageGo to next message
Christian Rahmig is currently offline  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
Re: trainProtectionElement, ETCS and balises [message #480 is a reply to message #473] Mon, 03 December 2012 09:57 Go to previous messageGo to next message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 311
Registered: August 2008
Senior Member
> 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...

+1

> Maybe we should rename it "tNationalSystemsTypeForVehicle"?

+1

> The second list "tNationalSystemsTypeOnRail" might be shorter because of
> discarding values such as 'IndusiXY' and summarizing them to 'PZB'.

+1 but please name it "tNationalSystemsTypeAtTrack" or "...Lineside" (the
first might be regarded exactly but the second one is usual in UK).

> "tNationalSystemsTypeOnRail" might be shorter because of discarding
> values such as 'IndusiXY' and summarizing them to 'PZB'.

For the sake of completeness: You leave the knowledge which
tNationalSystemsTypeAtTrack works with which tNationalSystemsTypeOnRail up
to the programmes. From my side, this is ok so far. For completeness, we
could include into to <interlocking> scheme or possibly in a separate
scheme the linkage and function of the train protection systems.

Best regards,
Dirk.
Re: trainProtectionElement, ETCS and balises [message #1879 is a reply to message #480] Sat, 14 July 2018 17:28 Go to previous messageGo to next message
Torben Brand is currently offline  Torben Brand
Messages: 156
Registered: March 2016
Senior Member
trainProtectionChange@nor:type

There is currently no attribute "type" under trainProtectionChange. There is clearly a need as the dormant development page for train protection systems value list shows ( https://wiki.railml.org/index.php?title=Dev:TrainProtectionS ystems).
I strongly disagree to use code. As this is used for national internal systems and for our national UID's. Thus we will add a Norwegian extension with the optional attribute @type with string values.

The same value list is used by trainProtectionElement@trainProtectionSystem. We will not use <trainProtectionElement> in Norway as the physical train protection elements are all part of the balises used in ATC or ERTMS. They are already mapped under <balises>. But as we need to map the transition between the different systems at concrete borders we use <trainProtectionChange> to map those borders.

We will use the values: "none","norD-ATC", "norF-ATC", "ETCS-L2"

I suggest to add this attribute to railML2.4 also. Alternative as an enumeration value from the value list in Dev:TrainProtectionSystems. We ask the infrastructure coordinator to add the value "none" and our national values into the list.
Adding of trainProtectionSystems for IS:trainProtectionChange and IS:trainProtection [message #1910 is a reply to message #281] Fri, 17 August 2018 09:42 Go to previous messageGo to next message
Tobias Bregulla is currently offline  Tobias Bregulla
Messages: 20
Registered: June 2017
Junior Member
Dear all!

Am 15.03.2012 um 13:22 schrieb Andreas Tanner:
> 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.

Even if this post is rather old, I want support the proposal of IVU and
the timetable group also from Infrastructure side for railML 2.4.

So the predefined list from
https://wiki.railml.org/index.php?title=Dev:TrainProtectionS ystems shall
be usable also from

1) IS:trainProtectionChange
- (general elements)
- medium
- monitoring
N trainProtectionSystems
see https://wiki.railml.org/index.php?title=IS:trainProtectionCh ange

2) IS:trainProtection in IS:infraAttributes
- (general elements)
- medium
- monitoring
N trainProtectionSystems
see https://wiki.railml.org/index.php?title=IS:trainProtection

As there is only a linking needed and no additional development seems to
be needed I would be happy if this could be done on short notice to be
useable in railML 2 projects too.

A complete remodelling (e.g. definition of "medium" and "monitoring" in
the TrainProtectionSystems.xml) shall be done with railML 3.

Best regards,

Tobias Bregulla and the whole Bahnkonzept team
Re: Adding of trainProtectionSystems for IS:trainProtectionChange and IS:trainProtection [message #2188 is a reply to message #1910] Fri, 03 May 2019 13:29 Go to previous message
christian.rahmig is currently offline  christian.rahmig
Messages: 436
Registered: January 2016
Senior Member
Dear all,

Am 17.08.2018 um 09:42 schrieb Tobias Bregulla:
> [...]
>
> 1) IS:trainProtectionChange
>   - (general elements)
>   - medium
>   - monitoring
>   N trainProtectionSystems
> see https://wiki.railml.org/index.php?title=IS:trainProtectionCh ange
>
> 2) IS:trainProtection in IS:infraAttributes
>   - (general elements)
>   - medium
>   - monitoring
>   N trainProtectionSystems
> see https://wiki.railml.org/index.php?title=IS:trainProtection

I created a Trac ticket [1] for this issue.
Any comments are highly appreciated...

[1] https://trac.railml.org/ticket/356

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
Previous Topic: railML2: trackRef@sequence
Next Topic: [railML3] Mapping of tvdSection in infrastructure?
Goto Forum:
  


Current Time: Thu Mar 28 13:13:12 CET 2024