The IEC Train Communication Network

Der IEC Zugbus WTB (Wire Train Bus)

Der IEC Zugbus standardisiert die Vernetzung von Fahrzeugen, die auf offener Strecke oder in Bahnhöfen an- oder abgekoppelt werden. Der Zugbus stammt ursprünglich aus der Deutschen Vornorm DIN V 43322. Die IEC hat diese Lösung erweitert, unter Mithilfe der Technologie, die Italien für ihren Schnellzug CD450 entwickelt hatten. Der Name WTB (Wire Train Bus) deutet darauf hin, dass in der Anfangsphase neben dem drahtgebundenen Zugbus (Wire) auch einen optischen Zugbus (Fibre) erwägt wurde, welcher nicht weiter verfolgt wurde.

Der Zugbus überträgt zeitkritische Daten, wie z.B. Steuerbefehle aus dem Führerstand, Mehrfachtraktion, Türschliessung, und Neigeinformation bei Neigezügen.

Die Geschwindigkeit von1Mbit/s ist relativ hoch, unter Berücksichtigung, dass der Zugbus über 860 m parallel zu einer Hochspannungsleitung mit starken Störungen verläuft. Dazu kommt eine schlechte Kabelqualität. Der Bus verläuft über bis zu 31 Stecker, die oxydiert sein können, und die der Zugbus vor dem Betrieb mit Frittierpulsen reinigt. Eine durchgehende Busverbindung ohne Wiederholer war nötig, um Leitungswagen ohne Knoten einzugliedern, und um den Betrieb zu sichern, wenn Fahrzeugbatterien ausfallen .

Der Zugbus wurde ursprünglich für die sogenannten 12-Draht UIC-Leitungen entwickelt, die heute die Lautsprechersignale übertragen, wie dies heute noch die SNCF tut [1]. Um 1 Mbit/s zu erreichen, führte die UIC einen neuen Kabeltyp mit 18 Leitungen ein. Die Verbindung zwischen Fahrzeugen erfolgt über den automatischen Koppler oder von Hand mit den heute verwendeten Peitschen. Der WTB wird immer redundant geführt, ein Kabel verläuft auf jeder Seite eines Fahrzeuges, wie Figur 3 zeigt.

Figur 3 – Auslegung des WTBs

Das besondere am IEC Zugbus ist die Zugtaufe, seine einzigartige Fähigkeit, die Fahrzeuge bei der Kupplung oder Trennung zu erkennen und der Reihe nach zu nummerieren.

Es gibt normalerweise einen Knoten pro Fahrzeug, aber es können auch mehrere oder keine sein. Der WTB nummeriert also in erster Linie nicht die Fahrzeuge, sondern die Knoten, wie Figur 4 zeigt:

Figur 4 - Ergebnis der Zugtaufe

Nach einer Zugtaufe (die weniger als 1 s für 22 Fahrzeuge dauert), wird einer der Knoten als Busmaster erkoren. Busmaster kann jeder Knoten werden, aber die Anwendung kann auch einen bestimmten Knoten als Busmaster erzwingen. Nach der Zugtaufe steuert der Master den Verkehr und teilt allen Knoten mit:

- ihre Adresse, Orientierung (links/rechts) und Position in Bezug auf den Master;

- die Anzahl und Position aller anderen Knoten;

- den Typ(z.B. Lokomotive, Speisewagen,...) der Knoten;

- die dynamischen Eigenschaften (z.B. Anwesenheit des Lokführers).

Zum Zweck der Zugtaufe besitzt jeder WTB Knoten zwei Datenkanäle, wie Figur 5 zeigt. Einer davon dient dem normalen Datenverkehr. Der andere ist nur auf den Knoten am Ende des Zuges aktiv. Diese suchen nach weiteren Knoten und veranlassen bei Erkennung (oder Verlust) eines anderen Knoten eine Zugtaufe.

Figur 5 – Knoten des WTBs

Die Zugtaufe ist komplex, weil sie eine grosse Anzahl von Sonderfällen behandeln muss, z.B. Verlust der Datenkommunikation, Verlust der Redundanz, Schlafzustand bei Entladung der Batterie und Wiedereingliederung nach einem Ausfall. Um eine schnelle Neukonfiguration beim Verlust des Masters zu erreichen, übernimmt der nächste Knoten beim ausgefallenen Master die Buskontrolle.

Nach der Zugtaufe, die den Datenverkehr sicherstellt, tauschen die Knoten weitere Informationen über ihre Fahrzeuge aus, die noch vom Lokführer bestätigt werden müssen (aber zum Echtzeitbetrieb nicht notwendig sind). Dazu hat die UIC das Merkblatt UIC 556 verfasst, welcher die Bedeutung der ausgetauschten Daten über den WTB definiert.

Der MVB Fahrzeugbus

Der MVB baut auf den Erfahrungen der Schweizerischen Lokomotiven 460 seit 1990 auf. Der MVB arbeitet bei 1,5 Mbit/s über drei definierte Medien:

• Aderpaar mit RS-485 für kurze Distanzen, innerhalb eines Schrankes oder benachbarten Geräten;

• Verdrilltes Aderpaar mit Trafokopplung für mittlere Distanzen, z.B. innerhalb eines Fahrzeugverbundes;

• Optische Faser für kritische EMV-Umgebung, hohe Verfügbarkeit und längere Distanzen (bis zu 2000 m).

Alle Medien können über Wiederholer verbunden werden, wie Figur 6 zeigt.

Figur 6 - MVB Auslegung in einer Lokomotive

Der MVB bietet eine sehr hohe Integrität gegen Datenfälschung. Dank seiner Manchesterkodierung und Checksummen erreicht er Klasse FT2 nach IEC 61870-5, mit HD=8 auf optischen Fasern.

Der MVB wird grundsätzlich redundant ausgelegt. Ein Gerät sendet auf beiden Kanälen und empfängt die Daten über einen Kanal, wobei er den anderen überwacht. Jedes Gerät wählt seinen Empfangskanal selbst, der Master sammelt die Störungsmeldungen, um übergreifende Fehler festzustellen.

Der MVB wird durch einen Master gesteuert. Aus Verfügbarkeitsgründen können mehrere Stationen als Busverwalter konfiguriert werden. Auf jedem Gerät wickelt ein eigener Kontroller den Busverkehr ab, ohne Eingreifen des Applikationsprozessors. Damit lassen sich auch einfache Ein-/Ausgabegeräte ohne Prozessor bauen.

Unterschiedliche Busse, gemeinsame Protokolle

Aufgrund ihrer Einsatzgebieten unterscheiden sich die physikalische und die Verbindungsschicht von WTB und MVB. Die darüber liegenden Protokolle sind jedoch gemeinsam.

Zug- und Fahrzeugbus transportieren zwei Arten von Daten:

1) Prozessvariablen sind kurze Daten (16 bis 256 Bits), die den Zustand des Zuges widerspiegeln, z.B. Geschwindigkeit oder Fahrbefehle. UIC verlangt, dass innerhalb eines Fahrzeuges alle zeitkritischen Variablen (unter allen Bedingungen) in weniger als 16 ms von Applikation zu Applikation wandern. Innerhalb eines Zuges (vom Fahrzeugbus zum Zugbus und wieder zu einem Fahrzeugbus) sind 100 ms zulässig. Um diese Zeiten unter allen Bedingungen einhalten zu können, werden die Prozessvariablen zyklisch übertragen.

2) Meldungen tragen längere Informationen, z.B. für Diagnose oder Netzverwaltung. Die Meldungsgrösse variiert zwischen wenigen Bytes bis zu Megabytes. Von den Meldungen wird zwar eine kurze Übertragungszeit erwartet, aber es darf auch mal länger werden. Darum werden Meldungen bedarfsorientiert (sporadisch) übertragen, ohne Garantie für die Zustellzeit, aber mit Empfangsquittung.

Periodische und sporadische Mediumzuteilung

Periodische und sporadische Daten werden in den Geräten separat behandelt, sie teilen sich abwechslungsweise den Bus, wie Figur 7 zeigt:

Figur 7 - Periodische und sporadische Datenübertragung

Der Busmaster unterteilt die Buszeit in Basisperioden. Eine Basisperiode dauert 1 ms auf dem MVB und 25 ms auf dem WTB. Die periodische Phase belegt einen Anteil jeder Basisperioden, welcher von Periode zu Periode variieren kann, aber 2/3 der Perioden nicht überschreitet. Während der periodischen Phase fragt der Busmaster die einzelnen Variablen nach einer vordefinierten Reihenfolge. Jede Variable hat eine vordefinierte individuelle Periode, die von 1 ms bis zu 1024 ms einstellbar ist.

Zwischen zwei periodischen Phasen findet die sporadische Phase statt. In dieser Zeit fragt der Master nach Geräten, die sporadische Daten zu übertragen haben. Falls kein Gerät antwortet, bleibt die sporadische Phase unbenutzt. Falls genau ein Gerät antwortet, leitet der Master die Ereignisdaten an den oder die Empfänger weiter. Falls mehrere Geräte gleichzeitig antworten, legt der Master durch Arbitration die Reihenfolge fest. Die Zeit, während der ein Gerät auf die Beantwortung seiner Abfrage wartet, kann mehrere Basisperioden in Anspruch nehmen, obwohl die Arbitration fair ist, weil die Anzahl beteiligter Geräte nicht vorausgesagt werden kann.

Quellenadressierte Prozessdatenübertragung

Prozessdaten werden grundsätzlich an alle Geräte im Bus gesendet. Der Master sendet zunächst ein Telegramm mit der Adresse der Prozessdaten. Jedes Gerät schaut nach, ob es an diese abonniert ist oder nicht. Das Quellgerät, welche diese Daten produziert, sendet darauf den Wert der Daten an alle Geräte. Diejenigen Geräte die abonniert sind, behalten die Daten. Jedes Gerät führt dazu eine Tabelle seiner abonnierten Daten. Diese Übertragungsart wird als quellenadressierte Rundverteilung bekannt. Sie wird von zeitkritischen Bussen wie WorldFIP oder Fieldbus Foundation (IEC 61158) verwendet. Die Prozessdaten sind somit unabhängig von den Geräten. Figur 8 verdeutlicht den Ablauf.

Figur 8 - Quellenadressierte Verteilung

Der Buskontroller wickelt diesen Verkehr selbständig ab und legt die Prozessdaten in einer kleinen Datenbank ab, dem Verkehrsspeicher. Der Verkehrsspeicher ist die Schnittstelle zwischen Bus und Anwendung, er entkoppelt Busverkehr und Applikationsverkehr. Eine Applikation liest aus dem Verkehrsspeicher zu einem beliebigen Zeitpunkt wie aus einem globalen Speicher. Der Verkehrsspeicher sichert die Datenkonsistenz, auch wenn mehrere Applikationen auf dem gleichem Gerät den Verkehrsspeicher lesen.

Aus Effizienz werden mehrere Prozessvariablen in einem Prozessdatentelegramm verpackt. Auf dem MVB kann jedes Gerät bis zu 4096 Prozessdaten abonnieren. Auf dem WTB kann ein Knoten nur ein Prozessdatum von jedem anderen Knoten empfangen, dafür enthalten die Telegramme bis zu 1024 Variable. Die Applikationen können auf einzelnen Variablen oder auf Gruppen von Variablen in einer Operation zugreifen.

Applikationen arbeiten meist zyklisch, ihre Zyklen sind untereinander und vom Buszyklus unabhängig, obwohl sie mit dem Busverkehr synchronisiert werden können, wie Figur 9 zeigt:

Figur 9 – Rundverteilung von Prozessvariablen und Verkehrsspeicher

Der Applikationsprozessor braucht also nur zum Zweck der Synchronisierung, z.B. am Anfang einer Basisperiode unterbrochen zu werden. Damit ist eine deterministische Datenübertragung garantiert von Applikation zu Applikation durch die periodische Natur aller beteiligten Prozesse.

Da Prozessdaten mit ihrer individuellen Periode wiederholt werden, braucht es keine zusätzlichen Protokolle, um verlorene Daten (zum Beispiel bei Übertragungsfehler) zu wiederholen. Auch braucht es keine Flusskontrolle, da die neuen Daten stets die vorherigen überschreiben. Um gegen Dauerausfälle gewappnet zu sein, wird jedes Prozessdatum mit einem Zähler versehen, der anzeigt, wie lange die Daten schon im Verkehrsspeicher seit der letzen Auffrischung durch den Bus oder die Applikation weilen. Die Anwendung liest die Daten regelmässig aus dem Verkehrsspeicher, und kann diese verwerfen wenn der Zähler einen zu hohen Wert anzeigt. Überdies kann jede Variable durch eine Checkvariable gesichert werden, die vom Hersteller gesetzt wird. Bei sicherheitsgerichteter Übertragung kommt eine globale Sicherung hinzu.

Prozessvariablen werden von Fahrzeug zu Fahrzeug versendet. Zu diesem Zweck führen die Knoten Kopiertabellen, welche die Variablen von Verkehrsspeicher zu Verkehrsspeicher entpacken und wieder verpacken. Auch hier ist Determinismus garantiert: alle Variablen werde von Applikation zu Applikation innerhalb einer festen Zeit übertragen, wie Figur 10 veranschaulicht. Eine Synchronisierung über Busse ist meist nicht nötig, die Applikationen müssen ohnehin einzelne Datenausfälle tolerieren.

Figur 10 - Vernetzung von Prozessvariablen

Das Sicherheitskonzept

Im Rahmen des ETCS-Projektes (European Train Control System) zur Vereinheitlichung der Europäischen Eisenbahnsignalisierung wurde das Eurocab-Sicherheitskonzept entwickelt [5]. Bei diesem Konzept werden weder Bus noch Geräten vertraut, denn obwohl Fehler auf dem Bus unwahrscheinlicher sind als Gerätefehler, ist ihre Wahrscheinlichkeit doch hoch. Die Daten werden grundsätzlich redundant aus zwei verschiedenen Geräten verschickt, unter Ausnützung der Annahme, dass bei einer seriellen Übertragung der gleiche (mehrfach)-Fehler nicht genau gleich bei aufeinanderkommenden Telegrammen eintritt (Figur 11). Überdies werden die Daten mit einem Zeitstempel und einer Quellenautentifizierung versehen, welche Teile der Checksumme (implizite Information) sind und von verschiedener Software (A/B) ausgewertet werden. Auf weiteren Optimierungen (z.B. Übertragung der Daten durch ein Gerät und der Checksumme durch das andere Gerät) wurde verzichtet, um die Implementierung einfach zu halten. Der Busverkehr wird dadurch nicht verdoppelt, denn es gibt nur wenige sicherheitskritischen Variablen und Geräte.

Figur 11 – Eurocab Integritätskonzept auf dem Fahrzeugbus

Das Verfügbarkeitskonzept

Die erhöhte Sicherheit wird mit Hardware-Redundanz erkauft. Dadurch sinkt die Verfügbarkeit des Leitsystems und damit des Zuges. Aus diesem Grund wird die Verdoppelung der Geräten auch zur Erhöhung der Verfügbarkeit herangezogen.

Alle Kommunikationskomponenten (Busleitungen, Busverwalter) sind grundsätzlich doppelt ausgelegt - einfache Strecken werden aber dort verwendet, wo dies unkritisch ist. Zu jedem kritischem Gerät gehört ein Ersatzgerät, welches bei Ausbleiben des Lebenszähler des kritischen Gerätes seine Funktion übernimmt. Gleichzeitig liefert das Ersatzgerät die redundanten Daten zur Gewährung der Sicherheit. Fällt ein Gerät aus, so hängt die Sicherheit des Zuges nur noch am Ersatzgerät. Je nach Anwendung darf dann bis zum nächsten Bahnhof oder bis zum Nachtdepot gefahren werden. Die Rundverteilung quellenadressierten Daten erlaubt eine elegante Umschiffung des Quittungsproblemes und eine geringe Busbelastung. Die Umschaltung des Busmasters erfolgt in wenigen Millisekunden,diejenige des Ersatzgerätes erfordet einige 100 ms. Dies bleibt unterhalb der Spanne, bei welcher eine Notbremsung eingeleitet würde.

Figur 12 – Eurocab Integritäts- und Verfügbarkeitskonzept

Meldungsaustausch

Anwendungen tauschen Meldungen über das TCN aus, wobei die Ansprechpartner auf verschiedenen Fahrzeugen, auf dem gleichem Fahrzeug oder auf dem gleichem Prozessorresidieren können, wie Figur 13 zeigt.

Figur 13 - Kommunizierende Prozesse

Die Anwendungen verfügen über zwei Kommunikationsdienste:

1.Unicast: Eine Kommunikation besteht aus einer Anfrage- und aus einer Antwortmeldung (Remote Procedure Call, Client-Server Prinzip). Das Transportprotokoll sorgt für Segmentierung, Fehlerkorrektur und Flusskontrolle von Applikation zu Applikation.Über dieses Protokoll wird praktisch der gesamte bedarfsorientierte Verkehr abgewickelt.

2.Multicast: Eine Nachricht wird an mehrere Funktionen, die eine Gruppe bilden, verschickt. Das Transportprotokoll bietet eine begrenzte Fehlerkorrektur und Flusskontrolle, es wird erwartet, dass Anwendungen unkritisch sind oder eine übergeordnete Quittung verschicken. Diese Übertragungsart wurde für das Passagierinformationssystem entwickelt.

Das Sessionsprotokoll sorgt für die Paarung von Anfrage und Antwort. Es baut eine Verbindung bei der Anfrage auf und löst sie nach Empfang der Antwort. Dadurch kann eine grosse Zahl Applikationen miteinander verkehren bei schonender Belegung der Betriebsmittel. Dies ist hilfreich bei Geräten, die sehr oft als Server dienen, wie Diagnoserechner oder Bedienungstafel.

Die Netzwerkschicht überträgt die einzelnen Pakete auf Grund ihrer Ursprung- und Ende Netzwerkadresse. Da die innere Struktur eines Wagens von aussen unbekannt ist, und von Hersteller zu Hersteller variieren kann, werden keine physikalischen Adressen verwendet, sondern logische Funktionsbezeichner, z.B. 36 für die Türsteuerung.

Die Zugbusknoten führen zu einem Funktionsverzeichnis und einem Stationsverzeichnis, die angeben, welche Funktionen auf ihrem Fahrzeug existieren und welche Station sie ausführt. Dabei kann eine Station mehrere Funktionen ausführen, oder eine Funktion kann von mehreren Stationen ausgeführt werden, wobei der Zugbusknoten selbst Funktionen ausführen kann, wie Figur 14 andeutet.

Figur 14 - Logische Applikationsfunktionen und Stationen in einem Fahrzeug

Das gleiche Prinzip wird auch innerhalb eines Fahrzeuges verwendet: Funktionen verkehren mit anderen Funktionen, die Geräte führen alle ein Funktionsverzeichnis mit allen unterstützen Funktionen.

Netzverwaltung

Die Netzverwaltung dient der Konfiguration, der Inbetriebnahme und dem Unterhalt des TCNs.Eine Station (z.B. ein PC) dient als Netzverwalter, welcher auf die Geräte zugreifen kann, sei es auf dem gleichen oder in anderen Fahrzeugen. (Figur 15).

Figur 15 - Manager und Agenten

Das Gegenstück zum Manager ist der Agent, welcher in jeder Station eine Fernbedienung erlaubt. Durch Ausrufe an den Agent kann der Manager Variable lesen, Programme herunterladen, die Uhr setzen oder Applikationen starten oder stoppen. Das TCN Netzwerkmanagementbietet also die gleichen Funktionen wie MMS (ISO 9506), jedoch mit einer Kodierung, welche auf die kurzen Pakete und einfachen Prozessoren ausgelegt wurde.

Test auf dem ERRI-Zug

Obwohl Zug- und Fahrzeugbus aus bekannten Entwicklungen der Eisenbahnindustrie stammen, haben die Verbesserungswünsche der Anwender zahlreiche Neuerungen gebracht, so dass eine Validierung des Konzeptes nötig wurde.

Die UIC finanzierte von Mai 1994 bis September 1995 einen Volltest im Labor in Erlangen und auf einem laufenden Zug. Eine Komposition aus Wagen von DB, FS, NS und SBB mit Geräten verschiedener Hersteller: Adtranz, Siemens, Firema, Holec verkehrte täglich zwischen Amsterdam (Holland) und Interlaken (Schweiz), wobei unterwegs die Komposition an jeder Grenze wechselte.

Die Erfahrung aus diesem nicht einfachen Versuch führte zu mehreren Verbesserungen des Standards. Insbesondere wurde die Notwendigkeit eines umfangreichen Tests jedes Fahrzeugs erkannt, welcher nicht nur das Zugnetz betrifft, sondern auch die elektrische Ausrüstung (z.B. Batterieerdung) umfasst.

Das ROSIN-Projekt

Die Europäische Union unterstützte die Anwendungen des TCN im Projekt ROSIN des V Telematik-Programmes, welches drei Jahre dauerte. Es wurden verschiedene Profile für Passagierzüge, Frachtzüge, S-Bahnen, usw... definiert.

Das Arbeitspaket 4 definierte die Daten für den Unterhalt der Fahrzeuge. Gemeinsame Protokolle genügen zur Interoperabilität von Applikationen nicht, man braucht noch eine Vereinbarung über die Bedeutung der ausgetauschten Daten.

Es wurde Rücksicht darauf genommen, dass die Erneuerungsrate bei Rollmaterial klein ist, und dass Fahrzeuge nachgerüstet werden. Darum war eine Standardisierung der ausgetauschten Daten nicht sinnvoll, weil existierende Ausrüstungen integriert werden müssen. Hingegen wurden die Methoden ihrer Beschreibung genau definiert und fand Eingang im IEC-Standard. Die ROSIN-Notation lehnt sich an die ASN.1 Notation, und legt Datenformate auf dem Bit genau fest. Damit konnten auch Datensätze spezifiziert werden, die von existierenden Geräten und von Fremdgeräten kommen.

Aussichten

Heute sind weltweit über tausend Schienenfahrzeuge mit TCN ausgerüstet, praktisch alle neuen Aufträge werden mit TCN abgewickelt. Dies heisst nicht, dass es an Bord keine andere Busse gibt, innerhalb einer Untereinheit ist keine Standardisierung zwingend. Hingegen wird erwartet, dass alle Daten, die zwischen Ausrüstungen ausgetauscht werden, über TCN gehen.

Die Standardisierung der Gerätedaten und der Erfahrungsaustausch innerhalb der Eisenbahnwelt gehen weiter. Die Entscheidung von 1990, nicht auf einen internationalen Feldbus zu warten, war richtig. Obwohl heute Feldbusse mit ähnlichen Eigenschaften wie TCN erhältlich sind, würden heutige kommerzielle Komponenten nur einen Bruchteil der Aufgaben lösen. Die Anpassung handelsüblicher Komponenten an die Eisenbahnbedingungen (Temperaturbereich, Rüttelfestigkeit, EMV) hätten eine Divergenz unausweichlich gemacht. Für Konfigurationswerkzeuge, die auf die Bedürfnisse der Projektierung von Schienenfahrzeugen zugeschnitten sind, wurde wesentlich mehr ausgegeben als für die Kommunikationskomponenten selbst.

REFERENZEN

1.J.C. Boutonnet & Michel Chateaureynaud "Multiplexing und Fernsteuerung von Lokomotiven bei der SNCF", ETR 38(1989), Heft 5, Mai, pp 265-269.

2.UIC B 108.3, "Informationsübertragung im Zug", Merkblatt 556, 12. Ausgabe, 1999.

3.International Electrotechnical Committee, IEC 61375 "Train Communication Network", Geneva, 1999.

4.Wilfred Marsden et al., "Design of a high-performance field bus for a distributed control system,” IPEC 90, Tokyo. 1990.

5.Peter Etter et al, "Use of standardized Integrated Communication Systems on Vehicles and Trains," IPEC 93, Tokyo, 1993.

6.Eschermann, B et al. "Fail-safe on-board data bus for automatic train protection", Railtech 1994, Birmingham

7.Kirrmann, H et al, “The IEC Train Communication Network,”16th Conference on Transportation Systems, KoREMA, Split/Ancona, November 1996.

Autoren

Hubert Kirrmann, ABB Corporate ResearchCH 5405 Baden, Switzerland

Telefon: +41 56 486 8071 email: hubert.kirrmann@ch.abb.com

Ulrich Claessen

Adtranz

DaimlerChrysler Rail Systems, email: ulrich.claessen@adtranz.ch

Notwendigkeit der Normierung

Architekturvarianten