ETCS: Einleitung ↓

Was ist ETCS? ↓

In vielen Fällen ist von ERTMS/ETCS die Rede. Das European Rail Traffic Management System umfasst auch noch die Mobilfunkstandards GSM-R und zukünftig FRMCS, die für die Zugbeeinflussung allerdings nur Transportmedia sind. Hinzu kommt mit Baseline 4 auch Automatic Train Operation (ATO). Ich werde mich im Folgenden auf ETCS beschränken.

Wie der Name schon andeutet, handelt es sich bei ETCS um eine europäische Zugsicherung oder korrekt übersetzt Zugbeeinflussung. Mit Europa ist dabei nicht der (gar nicht existierende) Kontinent Europa gemeint, sondern die Europäische Union. ERTMS/ETCS wurde erfunden, um den (EU-) europäischen Bahnverkehr zu harmonisieren. Deshalb nennen sich die entsprechenden Regeln auch Technical Specification for Interoperability, kurz TSI. Das Wort Interoperabilität ist gewissermaßen der Kernbegriff von ETCS.

Es gibt verschiedene TSI für den Bahnverkehr, die sich beispielsweise mit Güterwagen, Energieversorgung oder Lärmschutz befassen. Für uns sind die technischen Spezifikationen für die Interoperabilität (TSI) der Teilsysteme "Zugsteuerung, Zugsicherung und Signalgebung" (ZZS) relevant. Eigentlich ist mit "Zugsicherung" nur der Anteil der "Zugbeeinflussung" gemeint, obwohl die Begriffe in der Praxis durchaus gemischt werden (die SBB haben ihre Begrifflichkeit nach Jahren angepasst und sprechen inzwischen auch von "Zugbeeinflussung"). Auf Englisch heißt die TSI "control-command and signalling", kurz CCS.

Genau genommen handelte es sich bis September 2023 um die

VERORDNUNG (EU) 2016/919 DER KOMMISSION
vom 27. Mai 2016
über die technische Spezifikation für die Interoperabilität der Teilsysteme "Zugsteuerung,
Zugsicherung und Signalgebung" des Eisenbahnsystems in der Europäischen Union

Und weil es so viel Spaß macht, die letzte Änderung:

DURCHFÜÜHRUNGSVERORDNUNG (EU) 2019/776 DER KOMMISSION
vom 16. Mai 2019
zur Änderung der Verordnungen (EU) Nr. 321/2013, (EU) Nr. 1299/2014, (EU) Nr. 1301/2014,
(EU) Nr. 1302/2014, (EU) Nr. 1303/2014 und (EU) 2016/919 der Kommission sowie des
Durchführungsbeschlusses 2011/665/EU der Kommission im Hinblick auf die Angleichung an die
Richtlinie (EU) 2016/797 des Europäischen Parlaments und des Rates und Umsetzung der in dem
Delegierten Beschluss (EU) 2017/1474 der Kommission festgelegten spezifischen Ziele

Am 8. September 2023 wurde die neue TSI ZZS zusammen mit verschiedenen anderen TSI verabschiedet (die anderen diesmal eigenständig). Diese TSI ZZS enthält einige wesentliche Änderungen, was den Einsatz von ETCS angeht. Seit 28.09.2023 ist somit die folgende Vorschrift maßgeblich:

DURCHFÜÜHRUNGSVERORDNUNG (EU) 2023/1695 DER KOMMISSION
vom 10. August 2023
über die technische Spezifikation für die Interoperabilität der Teilsysteme „Zugsteuerung, Zugsicherung und Signalgebung“ des Eisenbahnsystems in der Europäischen Union und zur Aufhebung der Verordnung (EU) 2016/919

Die Ausrüstung von Strecken mit ETCS wird damit durch EU-Recht gefordert. Hingegen wurde die funktionale Spezifikation von der Union Industry of Signalling, kurz UNISIG, entwickelt, einer Arbeitsgemeinschaft folgender Bahntechnikunternehmen (zumindest im Stand der letzten Spezifikationen der Baseline 3):

• Alstom S. A., früher GEC Alsthom; Frankreich
• Ansaldo STS SpA, zur Finmeccanica-Gruppe; Italien; inzwischen von Hitachi übernommen
• Bombardier Inc., früher DaimlerChrysler Rail Systems, Adtranz, AEG; Kanada (Vorgängerunternehmen weitgehend deutsch); inzwischen von Alstom übernommen
• Invensys plc, früher Westinghouse Rail Systems Ltd; Großbritannien, wurde zwischenzeitlich von Siemens übernommen
• Siemens (aktuell Siemens Mobility GmbH); Deutschland
• Thales S. A., früher Alcatel, GEC, Standard Elektrik Lorenz AG (SEL); Frankreich (Lorenz war deutsch); inzwischen aus dem Konzern ausgegliedert und Übernahme durch Hitachi geplant

• AŽD Praha, Tschechische Republik
• CAF, Spanien

ECM S.p.A., Italien, und MERMEC STE, Italien, sind assoziierte Mitglieder.

Wichtig ist zunächst die Feststellung, was ETCS nicht ist: Ein Zugbeeinflussungssystem, das mit PZB 90 oder LZB vergleichbar ist. Oder mit ASFA, ATB, TPWS, TVM, ZUB 121 oder was auch immer.

???

Aber genau dass es sich um eine Zugbeeinflussung handelt sagt doch der Name, oder etwa nicht?

Im Prinzip ja. Das Problem ist allerdings, dass eine Zugbeeinflussung naturgemäß an der Betriebsordnung einer Bahnverwaltung hängt. Und diese europaweit zu harmonisieren ist nicht einfach, da sich die Sicherungstechnik im Bahnwesen – vereinfacht gesagt – landesspezifisch von Unfall zu Unfall entwickelt hat und auch die Philosophien traditionell bis zur Inkompatibilität unterschiedlich sind. Damit kommen wir auch schon zur ersten und wichtigsten Feststellung:

ETCS definiert die Luftschnittstelle zur Zugbeeinflussung zwischen Strecke und Fahrzeug.

Es gibt also einen definierten Satz von Nachrichten, die die Strecke an das Fahrzeug schicken kann. Unter Umständen kann auch das Fahrzeug etwas an die Strecke schicken. Zu diesen Nachrichten gehören einige Regeln, wann sie genutzt werden dürfen und wie sie zu interpretieren sind. Ein mit ETCS ausgestattetes Fahrzeug hat dabei relativ wenige Freiheiten für eigene Entscheidungen (abgesehen von denen des Triebfahrzeugführers), die Strecke hingegen recht viele. Das ist auch logisch, denn die Strecke unterliegt den nationalen Regeln, das Fahrzeug soll hingegen auf allen Strecken fahren können.

Ich gebe aber zu, dass diese Definition nur meine eigene ist und ihre Fehler hat. Auch die PZB 90 wird beispielsweise in Österreich anders genutzt als in Deutschland, wäre also keine Zugbeeinflussung. Dennoch ist die Bandbreite bei ETCS größer, nicht zuletzt auch weil ETCS wesentlich mehr Möglichkeiten bietet.

Das erklärt auch, warum die Funktion der Streckenausrüstung von ETCS nicht einheitlich definiert ist, sondern ähnlich wie ein Stellwerk für jedes Land angepasst werden muss.

Tatsächlich ist natürlich nicht nur die Luftschnittstelle definiert, sondern auch einiges an Drumherum.

Baselines, Systemversionen und Spezifikationsgruppen ↑↓

Die Geschichte der Baselines und Spezifikationsgruppen

Im Laufe der Entwicklung gab es verschiedene Gruppen von Spezifikationen für ETCS, die praktisch inkompatibel zueinander waren. Das war anfangs nur ein kleines Problem, da sich lediglich einige Strecken in Testbetrieb befanden. Es gab also nur wenige Fahrzeuge, die bei einem Upgrade der Strecke zu aktualisieren waren.

Die ersten praktisch nutzbaren Spezifikationen nannten sich Baseline 2. Im Laufe der Zeit gab es mehrere von ihnen, vor allem die ursprüngliche mit der SRS 2.0.0, jene mit der SRS 2.2.2 (2006 rechtskräftig) und schließlich die 2.3.0, die ab 2012 mit einem Satz von ergänzenden Change Requests aus dem SUBSET-108 jahrelang der offizielle (in der jeweils gültigen TSI ZZS genannte) Stand war. Dieser Stand ist allgemein als SRS 2.3.0d (d wie debugged}, also fehlerkorrigiert) bekannt.

Aufgrund neuer Funktionen wurde die Baseline 3 entwickelt. Zusammen mit der SRS 2.3.0d wurde die SRS 3.2.0 als Grundlage für Ausschreibungen eingeführt, die im November 2012 in der Version 3.3.0 ebenfalls offiziell wurde. Baseline 2 blieb jedoch parallel dazu gültig, so dass so zwei Spezifikationsgruppen entstanden, die wahlweise angewendet werden konnten.

Anfang 2015 wurde die Baseline 3 auf einen neuen Stand gebracht, der u. a. die SRS 3.4.0 enthielt.

2016 wurde ein neuer Stand der Baseline 3 eingeführt. Diesmal blieb die vorherige Version mit SRS 3.4.0 jedoch gültig, so dass es drei Spezifikationsgruppen gab: # 1 mit ETCS Baseline 2 (SRS 2.3.0d), # 2 mit ETCS Baseline 3 Maintenance Release 1 (SRS 3.4.0) und ETCS Baseline 3 Release 2 (SRS 3.6.0). Aus diesen drei Spezifikationsgruppen konnte gewählt werden, wenn es um Fahrzeug- oder Streckenausrüstung ging. Die Anwendung von Baseline 2 für neue Fahrzeugeinrichtungen wurde später jedoch verboten.

Interessant - und problematisch - war diese Dreigleisigkeit insofern, als dass neuere Baselines naturgemäß auch die Fehler der älteren korrigieren (dass sie auch neue einführen, ist ein anderes Thema). Insbesondere die Baseline 2 ist an vielen Stellen lückenhaft. Trotz angedachter funktionaler Kompatibilität konnte es also zu unterschiedlichem Verhalten kommen.

Die neue TSI kennt keine unterschiedlichen Spezifikationsgruppen mehr. Dies bedeutet, dass alle ETCS-Komponenten zukünftig auf den gleichen Anforderungen aufsetzen müssen, also auf Baseline 4 Release 1 (mit SRS 4.0.0)..

Systemversionen ↑↓

Um die Interoperabilität nun nicht wieder zu zerstören, hat man darauf geachtet, dass ein Baseline-3-Fahrzeug auch auf sogenannten Baseline-2-Strecken fahren kann. Es ist also nicht erforderlich, wie manchmal behauptet, dass es Fahrzeuggeräte geben muss, die sowohl Baseline 3 als auch Baseline 2 können.

Da die Nachrichten zwischen Fahrzeug und Strecke aber teilweise inkompatibel geändert wurden, muss die Strecke dem Fahrzeug zunächst mitteilen, welche "Sprache" sie spricht. Das geht mit einem Trick: Neben den Baselines wurden ab Baseline 3 Systemversionen definiert, die von der Strecke vorgegeben werden. Jede Systemversion referenziert im Ergebnis auf eine "Sprachversion" (für die es keinen Namen gibt), allerdings kann eine Sprachversion theoretisch auch für mehrere Systemversionen gelten. Schließlich gibt es zwischen den verschiedenen Baselines auch kleinere Abweichungen der "Sprache" der verschiedenen Systemversionen. Hierbei handelt es sich meist darum, dass bestimmte Werte einer Variablen in einer höheren Baseline nicht mehr genutzt werden dürfen.

Systemversionen werden als X.Y bezeichnet. Alle Versionen mit gleicher erster Nummer sind per Definition untereinander kompatibel. So werden 1.0 und 1.1 auch als X=1 bezeichnet, 2.0, 2.1, 2.2 und 2.3 als X=2.

Technisch gesehen ist es so, dass das RBC die Systemversion für die Kommunikation mit dem Fahrzeug vorgibt, das Fahrzeug nutzt allerdings nur die X-Version direkt und wendet die höchste für dieses X unterstützte Version Y dazu. Verlangt das RBC beispielsweise 2.0, so können unterschiedliche Fahrzeuge 2.0, 2.1, 2.2 oder 2.3 anwenden.

• Systemversion 1.0 entspricht dabei weitgehend der Baseline 2 (zwischen Strecke und Fahrzeug, die RBC-RBC-Schnittstelle ist inkompatibel), es dürfen allerdings bestimmte Werte einiger Parameter nicht genutzt werden. Auf Strecken, die mit Systemversion 1.0 ausgerüstet sind, können Fahrzeuge nach Baseline 2 also uneingeschränkt fahren.
  Nein, das stimmt nicht ganz, ein RBC Baseline 3 Systemversion 1.0 darf zwar nur Nachrichten senden, die ein aktuelles Baseline-2-Fahrzeug versteht, in einigen Fällen aber in Situationen, in denen ein Baseline-2-Fahrzeug sie nicht versteht.
• Systemversion 1.1 ergänzt einige Nachrichten, die von Baseline-3-Fahrzeugen verstanden werden (u. a. die Parameter für die Bremskurven), aber aus den alten Nachrichten nicht umgerechnet werden können. Ein Fahrzeug nach Baseline 2 kennt diese Nachrichten nicht und ignoriert sie (ab SRS 2.3.0d verpflichtend), kann also auch hier uneingeschränkt fahren. Es gibt zudem Fahrzeuge, die keine Baseline 3 beherrschen, aber die Bremskurvenparameter verstehen (das ist beispiesweise auf VDE 8 eine Netzzugangsvoraussetzung).
• Systemversion 2.0 entspricht schließlich der vollständigen Nutzung des in Baseline 3 definierten Formats. Auf einer solchen Strecke können nur Fahrzeuge fahren, die mit Baseline 3 oder höher ausgerüstet sind. Systemversion 2.0 wurde mit Baseline 3 eingeführt (in der damaligen SRS 3.3.0).
• Systemversion 2.1 entspricht weitgehend der 2.0, unterstützt aber paketorientierte Datenübertragung (GPRS). Allerdings bezogen sich zuletzt alle Spezifikationsgruppen der aktualisierten TSI 2016/919 auf die GSM-R-Baseline 1, die GPRS enthält. Systemversion 2.1 wurde mit Baseline 3 Release 2 (SRS 3.6.0) eingeführt.
• Systemversion 2.2 bietet zusätzliche Funktionen für Automatisches Fahren, also ATO (Automatic Train Operation), im Automatisierungsgrad (GoA) 2. Der Fahrzeugführer muss hierbei das Abfahrkommando geben. Ein vollautomatischer Betrieb ist noch nicht vorgesehen. Systemversion 2.2 wurde mit Baseline 4 Release 1 (SRS 4.0.0) eingeführt.
• Systemversion 2.3 enthält Anpassungen für das Future Railway Mobile Communication System (FRMCS), das GSM-R ablösen wird. Sie erlaubt zudem Rangieren ohne Funkabbau und ohne Eingabe von Zugdaten, was vor allem in Kombination mit der Digitalen Automatischen Kupplung sinnvoll ist. Diese Punkte waren bislang wesentliche Kritikpunkte, da nach dem Rangieren praktisch ein Neustart des Fahrzeugs erforderlich war. Hierzu müssen die Fahrzeuge aber diese Systemversion unterstützen. Systemversion 2.3 wurde mit Baseline 4 Release 1 (SRS 4.0.0) eingeführt.
• Systemversion 3.0 hat gegenüber der 2.3 nur einige Detailverbesserungen. Da viele ETCS-Strecken in Europa noch auf Systemversion X=1 beruhen und Systemversion 3.0 nur mit Baseline-4-Fahrzeugen möglich ist, wird eine Einführung vermutlich noch länger auf sich warten lassen (Sonderanwendungen als Inselbetrieb wären möglich). Systemversion 3.0 wurde mit Baseline 4 Release 1 (SRS 4.0.0) eingeführt.

Entsprechend kann ein Fahrzeug nach Baseline 4 auf allen Strecken fahren (siehe aber weiter unten), eines nach Baseline 3 auf allen im Oktober 2023 vorhandenen Strecken, wobei es auf Strecken mit Systemversion 1.0 und je nach Nutzung der optionalen Nachrichten auch mit Systemversion 1.1 insofern Einschränkungen geben kann, als dass einige Informationen nicht umgerechnet werden können und dem Fahrzeug fehlen. (B2-Fahrzeuge haben diese natürlich auch nicht.)

Es ergibt sich folgendes Bild für die in der alten TSI definierten Spezifikationsgruppen und die neue TSI, was die Systemversionen betrifft. Die Tabelle ist zu lesen als

Ein Fahrzeug der angegebenen Spezifikationsgruppe bzw. Baseline beherrscht jede der angegebenen Systemversionen.

Ein RBC der angegebenen Spezifikationsgruppe bzw. Baseline kann eine beliebige der angegebenen Systemversionen nutzen. (Im laufenden Betrieb ändert sich diese nicht.)

CR = Wenn Change Request 595 und die zugehörigen CR umgesetzt sind, sind wesentliche Teile verfügbar. jedoch nicht die volle Funktionalität.

Nach der alten TSI konnte ein RBC also nach B3MR1 entworfen sein und somit die SRS 3.4.0 anwenden, aber trotzdem die Systemversion 1.0 unterstützen, also auch für Baseline-2-Fahrzeuge geeignet sein. Das gilt beispielsweise auch für die RBC der VDE 8, die nach Spezifikationsgruppe # 2 (also mit SRS 3.4.0) entwickelt und zugelassen wurden, aber in Systemversion 1.1 betrieben werden.
Aber: Nach der alten TSI konnte ein RBC ebenso nach B3R2 entworfen sein und somit die SRS 3.6.0 anwenden, trotzdem jedoch die Systemversion 1.0 unterstützen. Und: Es konnte aber auch nach B2 entworfen sein (SRS 2.3.0d).
Alle drei Systeme würden sehr ähnlich mit dem gleichen Fahrzeug kommunizieren - womöglich mit kleinen Unterschieden im Verhalten, aber zueinander kompatibel.

Die neue TSI beseitigt diese Mehrdeutigkeit. Konkret ist es nur noch möglich, RBC und Fahrzeuge nach Baseline 4 zuzulassen. In diesem Rahmen wird eine der sieben Systemversionen gewählt. Aus RBC-Sicht ist dies im Prinzip bereits bekannt, da die Systemversion frei aus den Systemversionen der jeweiligen Baseline/SRS-Version gewählt werden konnte. Zudem ist der Funktionsumfang eines RBC vom Anwender (Land bzw. Betreiber) definiert.

Aber auch mit der Systemversion ist die Strecke oder das Fahrzeug zwar hinsichtlich der Kompatibilität eindeutig definiert, alle technischen Rahmenbedingungen sind jedoch noch nicht geklärt. Der Grund hierfür ist, dass die anzuwendenden Normen in der TSI ZZS spezifiziert sind. Die Konformitätsbewertung der Bennannten Stellen (Notified Bodies, kurz NoBo) verweist somit auf die TSI und die Spezifikationsgruppe.

Recht unglücklich ist, dass sich von SRS 1.2.0 bis 2.3.0d alle Systemversionen als 1.0 bezeichnen. Fahrzeuge vor 2.3.0d sind aber nicht uneingeschränkt kompatibel zu einer aktuellen Strecke mit Systemversion 1.0 und in der Regel überhaupt nicht mit 1.1. In der Schweiz verkehren noch Fahrzeuge nach SRS 2.2.2+, was einige Einschränkungen im Funktionsumfang bedeutet.

Besonderheiten der neuen Baseline 4 Release 1 ↑↓

Aber was ist mit den Fahrzeugen, müssen diese nun plötzlich alle sieben Systemversionen unterstützen?
Nein!
Für Fahrzeuge definiert Baseline 4 mehrere Rahmen (Envelopes), die angewendet werden können. So muss ein Fahrzeug nach Baseline 4 zwar die Systemversionen 1.0, 1.1, 2.0 und 2.1 unterstützen, aber es gibt die Optionen,

• keine weitere Systemversion oder
• zusätzlich die Systemversion 2.2 oder
• zusätzlich die Systemversionen 2.2, 2.3 und 3.0.

zu realisieren. Damit ergibt sich mindestens die gleiche Kompatibilität wie mit der früheren Spezifikationsgruppe # 3. Der wesentliche Unterschied zu dieser ist, dass Baseline 4 Fehler korrigiert. Wenn nach der alten TSI eine "alte" Spezifikationsgruppe genutzt wurde, wurden die in den neuen Baselines implementierten Fehlerkorrekturen nicht automatisch angewendet. Die neue TSI setzt nun alle neuen Systeme verpflichtend auf den gleichen Stand - theoretisch. Es gibt Übergangsregelungen, auf die ich nicht näher eingehen möchte.

Die Systemversionen 2.2 und 2.3 unterscheiden sich in der ETCS-Sprache von der 2.0 und 2.1. In ganz kleinem Rahmen gab es dies auch in B3R2 zwischen 2.0 und 2.1, jetzt sind die Unterschiede aber größer. Faktisch sind die Sprachen der Systemversionen X=2 inkompatibel.
Um dieses Problem zu beheben, muss das RBC wissen, welche Systemversionen das Fahrzeug unterstützt. Dank Packet 2/Onboard supported system versions ist dies der Fall, wenn das Fahrzeug mindestens die Systemversion 2.1 beherrscht. So kann das RBC beispielsweise in Systemversion 2.2 arbeiten, muss dann aber zur Kommunikation mit einem Fahrzeug, das nur die 2.1 kennt, einige Packets anpassen.

Rundweg (Hardware)

Diese Seite ist Teil eines Framesets © Sven Herzfeld Frameset laden  ↑