Home » railML newsgroups » railml.common » A train with ETCS?
Re: A train with ETCS? [message #1116 is a reply to message #1115] Wed, 10 October 2012 13:12 Go to previous message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Hi Dirk and others interested,

Dirk Bräuer <dirkbraeuer(at)irfpde> writes:

> for the usage of RailML in Austria in conjunction with the opening of
> ETCS on Westbahn line at the end of this year, we need to describe
> whether a train operates with ETCS or not.
>
> Therefore, it is necessary to use the element
> <train>.<trainPartSequence>.<equipmentUsage> with its attribute
> type'.

There are two positions in the railML-Timetable-Tree for this kind of
information, both of which result in the same railML types:

timetable/trains/train/trainPartSequence/equipmentUsage
timetable/trainParts/trainPart/formationTT/equipmentUsage

> The better solution would be to have a unification of
> - rail:etcs,
> - rail:nationalSystem,
> - rail:equipmentUsage.

+1

> All three lead to the same: A train protection system
> (Zugbeeinflussungsanlage). The 'nationalSystem' element is very good
> (with a very bad name - from my opinion) but why is 'etcs' outside
> nationalSystem'?

It was introduced in the spirit of the ETCS ideology as train equipment
system. From the ETCS point of view there are for purpose different
levels (and not intended different SRS Versions) and historically other
national (train protection) systems it has to interact with. The
"national systems" are encapsulated in STMs (Specific Transmission
Modules).

That's the reason why railML defines ETCS (levels, SRS versions)
separated from "traditional" train protection systems as
"nationalSystems".

> And the same type should be used
> - for vehicles,
> - at a train,
> - at a track,

+1

> all three in sequences:
> A vehicle can support non, one or more trainProtectionSystems,

Already implemented.

> a track can support some trainProtectionSystems.

Partly implemented with "trainProtectionChange", in a non-harmonized
way across the sub-schemas. See also [1], influences [2]

We will fix this issue with the next major release.

> Normally, a train would operate with none or
> one trainProtectionSystem only in one section, but there may also be
> two trainProtectionSystem with different tasks - one for securing the
> maximum speed, and another for securing the main signals. For
> instance, in Germany INDUSI and ZUB262 operate simultaneously in
> trains with tilting technology.

train/trainPartSequence/equipmentUsage offers the possibility to define
multiple "equipment"s. I mean that there is no need to define the
securing policy for each system, it would be enough to enable ETCS at
this place. Both above mentioned German systems are already kept by the
enumeration list in the attribute "type".

We could add an "etcs" element with its attributes "aETCS" (from
Rollingstock), but then there is no information about an STM, the ETCS
could interact with. Otherwise the STMs would be defined as a "national
system" like already done with the "type" attribute. I'm not sure, if
all aspects are covered by this solution, I try to figure it out.

....
<equipmentUsage>
<equipment type="Indusi60" uses="true"/>
<equipment type="ZUB262" uses="true"/>
<equipment uses="true">
<etcs level0="true" level1="true"/>
</equipment>
</equipmentUsage>
....

> Would be nice if we could get
> - a short solution with RailML 2.2
> - a good solution with RailML 3.0…
> ;-)

+1

How about the above approach?

Kind regards...
Susanne

[1] https://trac.assembla.com/railML/ticket/80
[2] https://trac.assembla.com/railML/ticket/23

Crosspost & Followup-To: railML.timetable

--
Susanne Wunsch
Schema Coordinator: railML.common
 
Read Message
Read Message
Previous Topic: Problems with automatic library generation
Next Topic: Concerns about RailML interoperability
Goto Forum:
  


Current Time: Tue Apr 30 20:28:35 CEST 2024