Dev:Train Coupling And Sharing

From railML 2 Wiki
Jump to navigation Jump to search

Train coupling and sharing / Kuppeln und Trennen von Zugteilen

This article explains basic concepts of coupling and sharing trains within the timetable subschema. To couple train parts (trains) and share them at another station is a typical phenomenon in timetable calculations for multiple reasons. The principle of "Train coupling & sharing" requires the same operating days of two trains.
Dieser Artikel erklärt Grundlagen des Kuppelns und Trennens im Timetable-Subschema. Das Kuppeln und Trennen von Zugteilen (Zügen) ist aus unterschiedlichen Gründen ein typisches Phänomen in Fahrplankonstruktionen. Es wird auch "Flügelzugbetrieb" bzw. "Flügeln von Zügen" genannt.

With the term train coupling and sharing we describe the situation where two or more parts of a train (nowadays mostly multiple units) run joined at one section and separated at another section of line.

This principle is not a special case of modern time but well-known throughout the world of railways for a long time. Here are some examples:

  • Due to reasons of infrastructure fee and organisation, you’ll find many cases of train coupling and sharing especially in the today’s European regional traffic.
  • Not only in Continental Europe, also for instance in the UK’s regional traffic there are trains from Glasgow to Mallaig and Oban running joined to a station called A’ Chrìon Làraich.
  • The same principle applies to the so-called “Kurswagen” or through-coaches so typical of former times.
  • In former times of steam traction in Britain there were slip coaches - a special type of direct coach to serve places where the main train was not scheduled to stop.
  • Nowadays, we still have through-coaches for instance in the overnight trains from Prague and Berlin to Zürich or from Warsaw to Paris and Copenhagen.
  • We also find it in the rail passenger traffic of other countries, such as the USA: The ‘Sunset Limited’ New Orleans - Los Angeles (train #1) is joined in San Antonio with ‘Texas Eagle’ Chicago - Los Angeles (train #21) and vice versa.

On trains and train parts in general

One of the base philosophies of railML® is to satisfy the requirements of every-day railway operation such as doubling of trains for raised capacity demands, direct through-coaches, and even train coupling and sharing. This shall be done since railML® 2.0 by “deconstructing” of trains in smallest, atomic fragments. These atomic fragments of trains are called train parts.

The actual train information as times, vehicles a. s. o. are properties of the train parts. A <train> structure of railML® only joins train parts to trains (“reconstructs” in the sense of the above named “deconstructing”) but, besides this, normally holds no additional information.

While e. g. operating days or no. of vehicles may change during a train’s run, all such properties of a <trainPart> stay constant.

The railML® element <train> can describe either an operational or a commercial train. This is defined by the attribute type which either is operational or commercial.

The characteristic attribute of operational trains is that at one moment there is only one train allowed at a section of line track. This train has clearly to be defined by one “primary key” (called ‘head code’ or ‘train number’). These aspects partly come from reasons of security (as for instance communication between signal boxes).

On the contrary, commercial trains are seen from the customers view. They refer to trains as published in public schedules like the historic Bradshaw’s https://en.wikipedia.org/wiki/Bradshaw's_Guide Bradshaw’s (external link)' or modern electronic medias. There may be apparently more than one train simultaneous in one direction of one track of a line. In a timetable two coupled trains are shown in two separate columns with the same times. In a departure poster there may be two entries with the same departure time and track but bound for different directions (both trains splitting at an intermediate station). Concerning this view, the term “train” is used in a wider sense. So, such a commercial train does not even need to have an engine (e. g. a slip coach).

Each train part normally is used by exactly one operational and one commercial train.

Each train names all its train parts in its element <trainPartRef> with the attributes ref and position. A train may consist of more than one train part either in one section or in subsequent sections of its route. There may be several elements <trainPartRef> with the same position if the corresponding train parts apply in different sections.

Please note that the value of <trainPartRef>.position does not necessarily give the actual position in the train. There may be some train parts “missing” due to different operating days.

More than one train part in one section applies for instance with train coupling and sharing.
More than one train part in subsequent sections applies for instance if the operating days change at an intermediate station.

How to define it with railML®?

Example 1

For the sake of readers of UK as well as of the rest of the world (for which A’ Chrìon Làraich probably means nothing - as Bischofswerda of German examples) let’s assume the following example:
A train leaves London St Pancras bound for Paris and Bruxelles.
It is split in Lille (capital of French Flanders).

The following railML® extract describes the one operational train which starts in London with two train parts, drops off the rear part in Lille and continues its journey with one part only: 

<train id='tro_9014' type='operational' trainNumber='9014'>
  <trainPartSequence sequence='1'>
    <trainPartRef ref='tp_9014_London-Lille' position='1'/>
    <trainPartRef ref='tp_9114_London-Lille' position='2'/>
  </trainPartSequence>
  <trainPartSequence sequence='2'>
    <trainPartRef ref='tp_9014_Lille-Paris' position='1'/>
  </trainPartSequence>
</train>

The following railML® extract describes the other operational train which starts in Lille and runs to Bruxelles: 

<train id='tro_9114' type='operational' trainNumber='9114'>
  <trainPartSequence sequence='1'>
    <trainPartRef ref='tp_9114_Lille-Bruxelles' position='1'/>
  </trainPartSequence>
</train>

So far, we cannot see that the train part which is dropped off the first train in Lille is the same train part which forms the second train. In other words, seeing the operational view only, a traveller would not know whether he has to change in Lille en route from London to Bruxelles. Therefore, here come the commercial trains.

The following railML® extract describes the through commercial train from London to Bruxelles: 

<train id='trc_9114' name='9114' type='commercial'>
  <trainPartSequence sequence='1'>
    <trainPartRef ref='tp_9114_London-Lille' position='2'/>
  </trainPartSequence>
  <trainPartSequence sequence='2'>
    <trainPartRef ref='tp_9114_Lille-Bruxelles' position='1'/>
  </trainPartSequence>
</train>

The following railML® extract describes the through commercial train from London to Paris: 

<train id='trc_9014' name='9014' type='commercial'>
  <trainPartSequence sequence='1'>
    <trainPartRef ref='tp_9014_London-Lille' position='1'/>
  </trainPartSequence>
  <trainPartSequence sequence='2'>
    <trainPartRef ref='tp_9014_Lille-Paris' position='1'/>
  </trainPartSequence>
</train>

You may think that trc_9014 is unnecessary since it holds no new information compared with tro_9014. But there should be poetic justice so if the travellers to Bruxelles get their own commercial train… However, please consider that some programmes reading railML® files only look for the commercial trains and do not ‘see’ any operational train. It also may be a little bit complicated to separate the operational trains which are superset by commercial trains from that which are not. So, that’s why there is the rule that each train part normally has to be used by exactly one operational and one commercial train.

In general, if we have the situation of train coupling and sharing, there is

  • one ‘long’ operational train running at the section where both parts are coupled, and normally, also at one of both ‘branches’,
  • one ‘short’ operational train running at the other ‘branch’, so starting or ending at the intermediate station where both train are split or joined,
  • two commercial trains (equal before the law), one for each ‘branch’ but both running through the shared section.

In the example above,

  • the ‘long’ operational train is tro_9014,
  • the ‘short’ operational train is tro_9114,
  • the two pari passu commercial trains are trc_9014 and trc_9114.

(Please note that there is no meaning in the id’s. They are just used that way for easier understanding.)

Additionally, you have to have at least four train parts for this example (tp_9014_London-Lille, tp_9114_London-Lille, tp_9014_Lille-Paris, tp_9114_Lille-Bruxelles) which are not shown here for shortness. You’ll find extracts from the train parts as well in the external example files.

As mentioned above, there is a difference from the operational and from the commercial point of view. There is only one operational train at the “shared section“ (here: London - Lille) but two commercial trains. The train number often given at the column’s header of time tables is not identical to the operational train number (or h’code) of a train. This inconsistent usage of the term “train number” is often the reason for misunderstandings: Does the train between London and Lille has the number 9014 or 9114?

Example 2

To seek the US-American example again: They use three operational trains for the same situation which makes it even more equal before the law: 

<train id='tro_1' type='operational' trainNumber='1'>
  <trainPartSequence sequence='1'>
    <trainPartRef ref='tp_01_NewOrleans-SanAntonio' position='1'/>
  </trainPartSequence>
</train>

<train id='tro_421' type='operational' trainNumber='421'>
  <trainPartSequence sequence='1'>
    <trainPartRef ref='tp_21_SanAntonio-LosAngeles' position='1'/>
    <trainPartRef ref='tp_01_SanAntonio-LosAngeles' position='2'/>
  </trainPartSequence>
</train>

<train id='tro_21' type='operational' trainNumber='21'>
  <trainPartSequence sequence='1'>
    <trainPartRef ref='tp_21_Chicago-SanAntonio' position='1'/>
  </trainPartSequence>
</train>

Then, we have again the two commercial trains. This time I assigned them the name rather than a number since the train number is more typical for the operational view: 

<train id='trc_SL' name='SUNSET LIMITED' type='commercial'>
  <trainPartSequence sequence='1'>
    <trainPartRef ref='tp_01_NewOrleans-SanAntonio' position='1'/>
  </trainPartSequence>
  <trainPartSequence sequence='2'>
    <trainPartRef ref='tp_01_SanAntonio-LosAngeles' position='2'/>
  </trainPartSequence>
</train>

<train id='trc_TE' name='TEXAS EAGLE' type='commercial'>
  <trainPartSequence sequence='1'>
    <trainPartRef ref='tp_21_Chicago-SanAntonio' position='1'/>
  </trainPartSequence>
  <trainPartSequence sequence='2'>
    <trainPartRef ref='tp_21_SanAntonio-LosAngeles' position='1'/>
  </trainPartSequence>
</train>

Well, now imagine: The Sunset Limited takes about 15 hours from New Orleans to San Antonio, leaving New Orleans about noon on Mondays, Wednesdays, and Fridays. The Texas Eagle takes about 30 hours from Chicago to San Antonio, leaving Chicago in the afternoon of Wednesdays and Saturdays. At which position of train #421 is train part #tp_01 from San Antonio to Los Angeles on Thursdays? Do they meet in San Antonio at all?

This shows how difficult real-world examples with train parts may become in conjunction with operating days and midnight-overrun and leads us to the next topic: Midnight-overrun. So far, it is described in https://www.irfp.de/download/railml_beispiel_mueg.pdf (external link, PDF, 🇩🇪; 269 kByte).

Example 3: Usage of trainNumber, code and name

It is, up to now, not clearly defined how to use the attributes trainNumber, code and name of <trainPart> and <train>. The following "rules" give an indication and a recommendation which applies at least for the examples here:

  • <train> with type='commercial':
    • trainNumber shall contain the (published) train number of the commercial train. This is typically what the passenger sees e. g. at the head of a Customer's Timtable (de: Kursbuch) column. If there is no published train number (but a published name as in the above example) the attribute name may be used instead and train number of commercial trains is committed.
    • code may contain a unique identifier for the commercial train which - in contrary to id, may have a meaning even outside the railML® file.
    • name shall be used for a published name ("branding") of a commercial train (e. g. "Sunset limited" or "Phoenix"). But please be aware that this name would apply to all <trainPart>s of the operational train. If the name is only valid for some <trainPart>s (name changes during the train's route or train parts with different names are coupled), use the attribute name of the element <trainPart>.
  • <train> with type='operational':
    • trainNumber shall contain the operational train number. For uniqueness, the attributes additionalTrainNumber and scope may be used here, and the rule for the uniqueness of these three attributes applies here as written at <train>.
    • code may contain a unique identifier for the operational train which - in contrary to id, may have a meaning even outside the railML® file.
    • name is typically not used for operational trains.
  • <trainPart>
    • trainNumber may redundantly contain the number of the train (in simple cases) or may contain the number of the train part. This is not necessarily the same as the train number of the corresponding train. Please be aware that one train part may be referred by two trains: one commercial and one operational. Therefore, more than one train number can apply to the same train part depending from the point of view.
    • code shall be used to identify the same train part. In this contents, for a through connection (connection without transfer for passengers), all elements <trainPart> which define a through connection shall have the same code.
    • name shall be used for a published name ("branding") of a train part / through connection (e. g. "Sunset limited" or "Phoenix").

The following “trains” may be assumed to be published:

  • 456 Praha – Amsterdam (branded “Phoenix”)
  • 458 Praha – Zürich (branded “Canopus”)
  • 60456 Praha – Berlin
  • 61458 Praha – Erfurt

All four “trains” run coupled between Praha and Dresden. In railML®, they are entitled as commercial trains. (Actually, there are more trains involved in reality. This has been simplified a little bit for the purposes of this example.)

From the operational point of view, there are the following operational trains:

  • 456 Praha – Amsterdam
  • 458 Dresden – Zürich

Please note that the numbers of the operational are identical with some numbers of commercial trains. But, this does by far not mean that these trains are identical! It is only that different objects have the same numbers (one could say: by coincidence).

<trainParts> in railML®: 

<trainPart id='tp_1.1' name=’Phoenix’ code='456' trainNumber='456' … />
<trainPart id='tp_1.2' name=’Phoenix’ code='456' trainNumber='456' … />
<trainPart id='tp_2.1' name=’Canopus’ code='458' trainNumber='458' … />
<trainPart id='tp_2.2' name=’Canopus’ code='458' trainNumber='458' … />
<trainPart id='tp_3.1' code='60456' trainNumber='60456' … />
<trainPart id='tp_3.2' code='60456' trainNumber='60456' … />
<trainPart id='tp_4.1' code='61458' trainNumber='61458' … />
<trainPart id='tp_4.2' code='61458' trainNumber='61458' … />

commercial trains: 

<train id='trc_1' trainNumber='456' name=’Phoenix’ type='commercial'>
  <trainPartSequence sequence='1'>	//section Praha - Dresden
    <trainPartRef ref='tp_1.1' position='1'/>
  </trainPartSequence>
  <trainPartSequence sequence='2'>	//section Dresden - Amsterdam
    <trainPartRef ref='tp_1.2' position='1'/>
  </trainPartSequence>
</train>

<train id='trc_2' trainNumber='458' name=’Canopus’ type='commercial'>
  <trainPartSequence sequence='1'>	//section Praha - Dresden
    <trainPartRef ref='tp_2.1' position='3’/>
  </trainPartSequence>
  <trainPartSequence sequence='2'>	//section Dresden - Zürich
    <trainPartRef ref='tp_2.2' position='1'/>
  </trainPartSequence>
</train>

<train id='trc_3' trainNumber='60456' type='commercial'>
  <trainPartSequence sequence='1'>	//section Praha - Dresden
    <trainPartRef ref='tp_3.1' position='2'/>
  </trainPartSequence>
  <trainPartSequence sequence='2'>	//section Dresden - Amsterdam
    <trainPartRef ref='tp_3.2' position='2'/>
  </trainPartSequence>
</train>

<train id='trc_4' trainNumber='61458' type='commercial'>
  <trainPartSequence sequence='1'>	//section Praha - Dresden
    <trainPartRef ref='tp_4.1' position='4'/>
  </trainPartSequence>			//section Dresden - Zürich
  <trainPartSequence sequence='2'>
    <trainPartRef ref='tp_4.2' position='2'/>
  </trainPartSequence>
</train>

operational trains: 

<train id='tro_1' type='operational' trainNumber='456'>
  <trainPartSequence sequence='1'>	//section Praha - Dresden
    <trainPartRef ref='tp_1.1' position='1'/>
    <trainPartRef ref='tp_3.1' position='2'/>
    <trainPartRef ref='tp_2.1' position='3'/>
    <trainPartRef ref='tp_4.1' position='4'/>
  </trainPartSequence>
  <trainPartSequence sequence='2'>	//section Dresden - Amsterdam
    <trainPartRef ref='tp_1.2' position='1'/>
    <trainPartRef ref='tp_3.2' position='2'/>
  </trainPartSequence>
</train>

<train id='tro_2' type='operational' trainNumber='458'>
  <trainPartSequence sequence='1'>	//section Dresden - Zürich
    <trainPartRef ref='tp_2.2' position='1'/>
    <trainPartRef ref='tp_4.2' position='2'/>
  </trainPartSequence>
</train>

More, graphic examples

Examples with graphical explanation are in a separate file:
railML®-Beispiel Zugteile (external link, PDF; 314 kByte)

Why not to use the 'scope' attribute?

Some misunderstandings are caused by a mixture of terms in German: 'Train coupling & sharing' translates to 'Flügeln von Zügen, Flügelzugbetrieb' and the enumeration values secondaryStart and secondaryEnd of the scope attribute in the <train> element are translated to 'Startflügel' and 'Zielflügel' at Deutsche Bahn. These terms are used for historical reasons from the context of freight traffic only.
Einige Missverständnisse bezüglich dieser Thematik rühren daher, dass die Begrifflichkeiten hier leider nicht sauber getrennt sind. Die Deutsche Bahn spricht bei ihren Ergänzungsfahrplänen von 'Startflügel' (secondaryStart) und 'Zielflügel' (secondaryEnd). Diese haben aber überhaupt nichts mit dem gemeinhin als 'Flügeln' oder 'Flügelzugbetrieb' bezeichneten Phänomen zu tun.

The intention of the scope attribute in the <train> element is only to allow that one train (to be exactly: one train number) may have different routes or slots at different operating days. In contrast, 'Coupling & Sharing' is only possible at same operating days. That is an important difference. This attribute should not be misused for the phenomenon of 'train coupling and sharing'.
Der Sinn des Attributs scope im Element <train> ist einzig und allein zu erlauben, dass ein Zug (genauer: eine Zugnummer) an unterschiedlichen Verkehrstagen unterschiedliche Trassen (Zeiten oder Laufwege) belegen darf - was bei der Deutschen Bahn als "Ergänzungsfahrplan" bezeichnet wird. Demgegenüber erfordert das 'Kuppeln und Trennen von Zügen' die gleichen Verkehrstage an der Stelle der Flügelung bzw. Vereinigung. Das ist ein wichtiger Unterschied. Das Attribut scope darf nicht für das Phänomen des 'Kuppelns und Trennens von Zugteilen' missbraucht werden.

See examples following the external link (external link, pdf).
Weitere Erläuterungen und Beispiele können hier (externer Link, pdf) nachgeschlagen werden.

Different aspects on commercial trains

According to the statements above, a commercial train is a train seen from a view of a passenger: Any vehicle a passenger can enter at one station and leave at another station without changing. Still, one commercial train can consist of several vehicles or even several train parts.

However, in special circumstances some railML®-users see a lack of strength in the structure of railML® 2.x schemes: If a train consists of several train parts over several route sections (in railML®: <trainPartSequence>s), how to find out which train part of one section becomes which train part of the next section?

  • One could think that naturally the first train part of the first section becomes the first of the next section and so on. But this is not sure - trains may reverse at intermediate stations.
  • Even if one would consider the attributes orientationReversed and trainReverse, the problem may not necessarily be solved by the order of the train parts: The number of train parts in a commercial train can change. If the train arrives with three parts and departs with two parts, is it the first two or the last two?
  • For many (probably most) use cases the problem is not relevant and therefore not solved at all: A commercial train is a group of vehicles and possibly train parts a traveller can use without changing, that’s all. It doesn’t matter of how many vehicles it consists and which one is the first and last. This applies to most cases of passenger information, as for instance schedules / Kursbuch, platform panels and departure posters.

However, at least to exactly restore original data, the problem has to be solved anyway. There are currently two solutions for that:

  • <trainPart>s of several <trainPartSequence>s are linked by one of their attributes. This may be the attribute trainNumber and/or code: Two <trainPart>s of neighbouring <trainPartSequence>s with the same trainNumber belong together, they are the same formation.
  • Commercial trains have exactly one <trainPart> per <trainPartSequence> but not more than one. This solves the problem in an elegant way using railML® structures only. But it also means to define more commercial trains than necessary and usual, especially for passenger information systems. The number of commercial trains in such a railML® file may not be the same as the number of commercial trains seen ‘from outside’, from a passenger’s view, from a public timetable view.

However, there are the two modes of usage

  1. “Normal” commercial trains, for passenger information / from passenger view: A commercial train can have more than one train part per route section.
  2. Commercial trains “for exact data transfer”: A commercial train has exactly one train part per route section but not more.

Which mode is or shall be used is not further defined by railML® so far; it is a question of use case. You simple should be aware both possibilities.

Please note, that the rule “Each train part normally is used by exactly one operational and one commercial train“ is fulfilled with both modes.

Retrieved from "https://wiki2.railml.org/index.php?title=Dev:Train_Coupling_And_Sharing&oldid=15258"