Home » railML newsgroups » railml.infrastructure » Infrastructure data for a train path finding tool - #2, microscopic view (How to represent data required by a train path finding tool in railmL2.4?)
Infrastructure data for a train path finding tool - #2, microscopic view [message #2508] Wed, 29 July 2020 14:08 Go to next message
Rüdiger Ebendt is currently offline  Rüdiger Ebendt
Messages: 4
Registered: July 2020
Junior Member
Hi everyone,

this is again from Ruediger Ebendt, staff at the Institute of Transportation Systems, German Aerospace Center (DLR). This post addresses the same use case as in my previous post (https://www.railml.org/forum/index.php?t=msg&goto=2507), but looking at a different level.

Some of the pieces of data we need to represent in railML2.4 (for the purpose of an import interface of a train path finding tool) belong to a microscopic view on the infrastructure (maybe, some of these even belong to interlocking instead of infrastructure). These pieces of data are (original German terms in square brackets):

- train control system (i.e. ETCS, LZB): begin, block sign, end, clearing point [Zugsicherungstechnik: Anfang, Blockkennzeichen, Ende, Zugschlussstelle]
- route (including an exact description of all negotiated route elements, exclusions and of the overlap) [Fahrstraße (inkl. einer exakten Beschreibung der befahrenen Fahrwegelemente, der Ausschlüsse und des Durchrutschwegs)]
- route clearing point [Fahrstraßenzugschlussstelle]
- overhead line section [Oberleitungsschaltgruppe]
- signal clearing point [Signalzugschlussstelle]
- operational procedures (e.g. direct traffic control (DTC)) [Betriebsverfahren, z.B. Zugleitbetrieb]

Thank you very much for your help!

Kind regards
Ruediger Ebendt

[Updated on: Wed, 29 July 2020 14:14]

Report message to a moderator

Re: Infrastructure data for a train path finding tool - #2, microscopic view [message #2511 is a reply to message #2508] Thu, 13 August 2020 12:02 Go to previous message
Dirk Bräuer is currently offline  Dirk Bräuer
Messages: 292
Registered: August 2008
Senior Member
Dear Rüdiger,

here are some remarks from our experience on your questions:

> - suitability of track for double-decker trains
> [Ertüchtigung für Doppelstockfahrzeuge]

This is not a general agreed property of infrastructure. If a certain track allows double-decker trains depends naturally on the loading gauge of the double-decker trains, which differ very much. Even in Germany, you have several different loading gauges of the double-decker carriages, not to write about North-American double-decker container freight cars...

This is a task of comparing loading gauges of tracks with loading gauges of vehicles. Both should be given in railML.

> - related to suitability of track: codes of
> combined-transport load units [KV-Profile]

Same as above: They are not general agreed, they break down to (more standardised) loading gauges.

> - train path pricing [Trassenpreis]

....depends on many properties of a certain train (date, time = timetable, mass, speed etc.) and therefore is no general infrastructure data.

> - loading limits [Grenzlasten]; dependent on length, per
> tractive unit, dependent on the type of railway coupling and
> direction, with or without banking

There are different loading limits for each combination of vehicles (engines and carriage types) and speeds, even head wind and rail condition, so to calculate them individually is a task for a reading software.

> - train category dependent line closures [zugartabhängige Sperrungen]

Line blockings are dealt with in railML (see for instance <states> of elements; I think more detailed at least from 3.x), but if they depend on train categories is not generally agreed (since there are no generally agreed train categories).

> - pre-signalling distance [Vorsignal-Abstand / Regel-Bremsweg der Strecke]

Is currently missing in railML. It is of course possible to calculate the certain pre-signalling distances but there is no general one of a line. This may be demand for a future extension of railML. The question is what the certain demand in the certain use case would be: What shall be calculated from the general pre-signalling distance of a line or what should it be used for?

- train control system (i.e. ETCS, LZB): begin, block sign,
end, clearing point [Zugsicherungstechnik: Anfang,
Blockkennzeichen, Ende, Zugschlussstelle]

The protection systems are included in railML (for 2.x see <trackElements>.<trainProtectionChanges>). Block posts should be given as <ocp>s via <crossSection>s. "Clearing points" (Zugschlussstellen) is special German terminology and not internationally agreed. Concerning the overlap (which may be internationally agreed), it would probably be a matter of <interlocking>.

- route (including an exact description of all negotiated
route elements, exclusions and of the overlap) [Fahrstraße
(inkl. einer exakten Beschreibung der befahrenen
Fahrwegelemente, der Ausschlüsse und des Durchrutschwegs)]

There was (as far as I know) no use-case so far to exchange interlocking routes. If, then it would be a matter rather of <interlocking> than of <infrastructure>. Please not that even in Germany not all interlocking technologies use "Fahrstraßen" and that from an international view, they would probably not be generally agreed. So the question would be: Are they general enough and what would be the certain demand in the certain use case?

- route clearing point [Fahrstraßenzugschlussstelle]
- signal clearing point [Signalzugschlussstelle]

Same as above: Is special German terminology, is rather a matter of <interlocking>, hardly international standard and what do they have to do with the use case of a train path finding tool?

- overhead line section [Oberleitungsschaltgruppe]

Do you really mean the Schaltgruppe? I think there would be no attempt to encode these so far.
In case you mean Ausschaltstellen, I could imagine that they are a matter for <infrastructure> and for certain use cases, since the train traction should be switched off when passing them. But even they are, afaIk, not included in railML.

- operational procedures (e.g. direct traffic control (DTC)) [Betriebsverfahren, z.B. Zugleitbetrieb]

There is an <trackElements>.<operationModeChange> in railML 2.x which goes into that direction. But since these "types" are highly national and hardly comparable, there is little demand on exchanging them. You would have to show what for they are necessary in your certain use case.

With best regards,
Dirk Bräuer.
Previous Topic: Infrastructure data for a train path finding tool
Next Topic: Visualization: Proposal to move to a separate subschema
Goto Forum:
  


Current Time: Fri Sep 25 12:57:15 CEST 2020