Dev:Train Coupling And Sharing

From railML 2 Wiki
Revision as of 14:40, 17 October 2012 by RailML Superseded Users (talk | contribs) (verschob „TT:trainCouplingAndSharing“ nach „TT:Train Coupling And Sharing“: Better naming according to typical wiki conventions)
Jump to navigation Jump to search

Train coupling and sharing / Kuppeln und Trennen von Zugteilen

To couple train parts (trains) and share them at another station is a typical phenomenon in timetable calculation for multiple reasons. The principle of "Train coupling & sharing" requires the same operating days of two trains.
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 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. So I will give a view examples only:

  • Due to reasons of infrastructure fee and organisation, you’ll find many cases of train coupling and sharing especially in the today’s German regional traffic.
  • Not only in Germany, also for instance in the UK’s regional traffic we have the trains from Glasgow to Mallaig and Oban running joined to a station called A’ Chrìon Làraich… And you’ll also find it in Wales but the village names there are even more complicated.
  • The same principle applies to the so-called “Kurswagen” or through-coaches so typical of former times. Who knows Agatha Cristie’s Murder on the Orient Express? The murder took place in the Calais Coach, and next to that was the Athens Coach which joined the train running from Stamboul to Paris in Belgrade.
  • 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 even find it in countries which are not famous for railway passenger traffic (or, which are even famous for having no railway passenger traffic worth mentioning): 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 version 2.0 of RailML is to satisfy the many requirements of every-day railway operation such as ‘strengthen’ of trains for raised capacity, direct through-coaches, and even train coupling and sharing. This shall be done 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 “Bradshaw’s” 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 my 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 (PDF).

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 operational 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 [1] (PDF, 269 kByte, German only - English to be done).

More, graphic examples

Examples with graphical explanation are in a separate file:
RailML-Beispiel Zugteile, 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.
Weitere Erläuterungen und Beispiele können unter diesem externen Link nachgeschlagen werden.