Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03109.jsonl.gz/3050

TCN,
der IEC 61375 Standard für die zeit- und sicherheitskritische
Datenübertragung in Schienenfahrzeugen
Prinzipien und Verwendung
Dadurch wird die weltweite Interoperabilität der Schienenfahrzeuge und die Austauschbarkeit ihrer Ausrüstung möglich.
Das Zugnetz TCN (Train Communication Network) besteht aus einem Zugbus, welcher die Fahrzeuge eines Zuges verbindet, und einem Fahrzeugbus, welcher die Ausrüstung an Bord der einzelnen Fahrzeuge verbindet (Figur 1).
Der Zugbus (WTB) verbindet bis zu 32 Fahrzeuge durch ein verdrilltes Aderpaar und arbeitet mit 1,0 Mbit/s über 860m. Seine Eigenart ist die Fähigkeit, sich bei jeder Änderung der Zugkomposition neu zu konfigurieren und die Position und die Eigenschaften der Fahrzeuge automatisch zu erkennen. Dazu war eine strenge Normierung des Datenaustausches nötig, welche die UIC 5R Gruppe vorgenommen hat.
Der Fahrzeugbus (MVB)arbeitet mit 1,5 Mbit/s über optische Faser oder verdrillte Aderpaare. Er kann bis zu 4096 intelligente Steuerungen und einfache E/A Geräte verbinden.
Beide Busse arbeiten mit den gleichen Protokollen auf dem Prinzip der synchronen, zyklischen Datenübertragung von quelladressierten Nachrichten. Dadurch wird ein deterministisches Verhalten garantiert, welches einerseits die Echtzeitkriterien erfüllt und andererseits die Fehlertoleranz erhöht.
Neben der zyklischen Übertragung unterstützt TCN den Austausch von bedarfsorientierten, nicht zeitkritischen Meldungen, z.B. für Netzverwaltung.Diese können dank einem 7-Schichten Stack zwischen zwei beliebigen Applikationen an Bord des Zuges ausgetauscht werden.
Der Standardisierung voraus kam eine mehrjährige Testphase, bei welcher die ERRI (Europäisches Eisenbahnforschungsinstitut, Utrecht) und die Hersteller das Konzept auf laufenden Zügen testeten.
Richtlinien erlauben den Herstellern, die Konformität ihrer Geräte zu prüfen, bevor sie installiert sind.
Heute steuert TCN in über 1000 Fahrzeugen (Passagierzüge, S-Bahnen und U-Bahnen) die Fahrt.
TCN
wurde 1999 zum IEC Internationalen Standard 61375. Auch in der USA verbreitet
sich TCN. Die IEEE Arbeitsgruppe Rail Transit Vehicle Interface Standards
Committee hat IEC 61375 als Grundlage für die IEEE 1473 Norm adoptiert,
welche jetzt verabschiedet ist.
Die Standardisierung umfasste sowohl die Verbindung zwischen Fahrzeugen wie die Verbindung der Ausrüstung an Bord von Fahrzeugen.
·Zugbus: Der Zugbus erlaubt den Datenaustausch zwischen Wagen. Bei Zügen, deren Komposition häufig wechselt, wie internationale Züge, trägt jedes Fahrzeug ein Segment des Busses. Bei An- oder Abkopplung erweitert oder verkürzt sich der Bus. Der Datenaustausch muss auf Anhieb funktionieren, auch bei Fahrzeugen unterschiedlicher Herkunft und Bahngesellschaft. Zu diesem Zweck wurde derWTB (Wire Train Bus) standardisiert.
·Fahrzeugbus: innerhalb eines Fahrzeuges werden Ausrüstungen mit Hilfe des Fahrzeugbusses vernetzt. Die Standardisierung ist nur nötig, wenn Ausrüstungen von mehreren Herstellern verwendet werden. Dies ist aber häufig der Fall:
1.Fahrzeughersteller setzen vermehrt ihre Fahrzeuge aus vorfabrizierten Einheiten zusammen (z.B. Türen, Lüftung) mit eigener Steuerung. Eine genormte Schnittstelle vereinfacht Montage und Test.
2.Unterlieferanten schätzen es, wenn Ihre Produkte nur mit einem Bussystem zu versehen sind.
3.Eisenbahngesellschaften könnenWartung und Lagerhaltung vereinfachen, wenn alle Ausrüstungen an der gleichen Datenschnittstelle hängen.
Zu diesem Zweck hat die Arbeitsgruppe 22 den MVB (Multi-function Vehicle Bus) als Fahrzeugbus spezifiziert.
Figur 2 - Einsatzvarianten des TCNs
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;
- 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.
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.
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.
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.
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

Figur 12 Eurocab Integritäts- und Verfügbarkeitskonzept
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.
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.
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.
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.
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.
Telefon: +41 56 486 8071 email: <email-pii>
Ulrich Claessen
Adtranz
DaimlerChrysler Rail Systems, email: <email-pii>