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):

Seitdem sind zu Vollmitgliedern geworden:

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 {\em 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 {\em 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 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 ie 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 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.

Umgekehrt kann ein Fahrzeug nach Baseline 4 auf allen Strecken fahren, eines nach Baseline 3 auf allen 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:

Spezifikationsgruppe Baseline SRS Systemversion
1.0 1.1 2.0 2.1 2.2 2.3 3.0
# 1 B2 2.3.0d X CR - - - - -
# 2 B3MR1 3.4.0 X X X - - - -
# 3 B3R2 3.6.0 X X X X - - -
n/a B4R1 4.0.0 X X X X X X X

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,

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 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
Rundweg (Hardware)

Valid HTML 4.01 Transitional Diese Seite ist Teil eines Framesets © Sven Herzfeld Frameset laden