Rundweg (Praxis)
Und hier nun die Richtung vom Zug an die Strecke, die meist nur in Level 2 relevant ist. Wenige Messages gehen aber auch in Level 1 an eine RIU.
Diese Message enthält vor allem das Packet 11 mit den Zugdaten.
Hiermit bittet ein Fahrzeug in Level 2 um die Erlaubnis, nach Shunting zu wechseln. Das RBC antwortet darauf mit M27/SH Refused oder M28/SH Accepted.
Hiermit bittet ein Fahrzeug in Level 2 um die Erlaubnis, nach Supervised Manoeuvre zu wechseln. Das RBC antwortet darauf mit M4/SM Authorisation oder M5/SM Refused.
Kurz bevor das Fahrzeug in die Bremskurve kommt, kann es vom RBC eine neue MA anfordern. Die Message hat aber auch in anderen Situationen ihre Berechtigung, z. B. wenn das Fahrzeug seine MA verworfen hat oder nach dem Aufrüsten.
Diese Message enthält vor allem das Packet P10 mit der Länge des Verbandes.
Eigentlich ist der Name dieser Message irreführend. Ein Position Report (Packet P0 oder P1) ist in fast allen Messages an die Strecke enthalten. Die M136 könnte man insofern eher als General Message bezeichnen.
Die positive Antwort des Fahrzeugs auf einen Request to Shorten MA: "Ja, ich kann vor dem neuen EOA halten und kürze meine MA darauf."
Die negative Antwort des Fahrzeugs auf einen Request to Shorten MA: "Nein, ich bin nicht sicher, dass ich vor dem neuen EOA halten kann und behalte meine alte MA."
Da dies von der Bremskurvenberechnung abhängig ist und diese eher konservativ ausgelegt ist, heißt das nicht, dass ein rechtzeitiges Bremsen generell unmöglich ist.
Diese Message ist die rein formelle Quittung auf eine vom RBC.
Da es zwei Arten von Nothalt gibt, hat diese Message auch drei oder vier Funktionen (Häh?)
Auf einen CES ist es die Antwort "Ich hatte die angegebene Position bereits passiert und ignoriere den Nothaltauftrag" bzw. "Ich war noch vor der angegebene Position, akzeptiere den Nothaltauftrag und kürze meine MA auf das neue EOA"
Ab Systemversion X=2 wird zudem noch unterschieden, ob der akzeptierte CES zu einer Verschiebung des EOA führte oder nicht.
Auf einen UES ist es einfach nur die funktionale Quittung.
Die Antwort des Fahrzeugs oder vielmehr des Triebfahrzeugführers auf den TAF Request "Vor mir ist bis zum Signal alles frei."
In Deutschland müsste sogar bis zum Haltfallabschnitt alles frei sein, was aber in den harmonisierten Regeln zum "Umgang mit einer Aufforderung zur Bestätigung einer freien Strecke" nicht berücksichtigt wird. Diese Funktion wird in Deutschland demzufolge auch nicht genutzt.
Hiermit beginnt das Fahrzeug den geordneten Abbau einer Kommunikationssitzung.
Die einzige Message, die wirklich nur an eine RIU geht. Das Verfahren ist anders als beim MA-Request: Für Infill gibt es nur eine Anforderung, die RIU schickt daraufhin zyklisch die Infill-MA.
Beim Aufbau der Session zwischen Fahrzeug und Strecke kann es vorkommen, dass das Fahrzeug keine ETCS-Version beherrscht, die zu der der Strecke kompatibel ist. (Die Strecke hat immer die Wahl der Version.) Das wird hiermit mitgeteilt. Diese Message ist eine der wenigen invarianten Messages, d. h. ihr Aufbau und Inhalt darf in keiner ETCS-Version geändert werden. Für das RBC gilt die Session damit als aufgebaut, sie muss gezielt abgebaut werden.
Witzig ist dabei, dass zu Baseline 3 der Name um das "supported" ergänzt wurde, aber Namen sind bekanntlich Schall und Rauch.
Das Fahrzeug sendet diese Message, wenn die Funkverbindung aufgebaut ist, das RBC meldet daraufhin seine Systemversion. Auch diese Message ist invariant.
Das Fahrzeug sendet diese Message, wenn es die Kommunikationssitzung als abgebaut betrachtet, das RBC schließt sich dann an. Auch diese Message ist invariant.
Der Sessionabbau bedingt nicht unbedingt ein End of Mission, zumal auch das RBC selbst ihn anstoßen kann.
Diese Message schickt das Fahrzeug beim Aufrüsten. Sie enthält neben dem Position Report (Packet P0 oder P1) auch dessen Status, d. h. ob die Position aus Sicht des Fahrzeugs glaubwürdig, unglaubwürdig oder unbekannt ist. Siehe dazu Message 40.
Eine Neuerung in Systemversion 2.0 und damit die einzige neue Message in Richtung Strecke ist die Bestätigung einer Textmeldung P73 oder P74. In Systemversion X=1 gibt es zwar die Möglichkeit, Textmeldungen vom Triebfahrzeugführer bestätigen zu lassen, jedoch nur fahrzeugintern.
Mit dieser Verbesserung kann das RBC nun direkt reagieren und beispielsweise eine MA nur verlängern, wenn eine Einschränkung empfangen wurde. Sowas wie "Du bekommst Fahrt, aber denk daran, dass Du in Wolfsburg halten musst."
Das Fahrzeug sendet diese Message, wenn es die Kommunikationssitzung als aufgebaut betrachtet, das RBC schließt sich dann an. Da die Systemversion zu diesem Zeitpunkt bereits ausgehandelt ist, ist diese Message nicht invariant.
Da das RBC für fast alle Funktionen die aktuelle Zugposition benötigt, ist dieses Packet oder das P1 in fast allen Messages in Richtung Strecke enthalten. Was ist drin:
Im Ansatz ist dieses Packet das gleiche wie P0. Es gibt jedoch zwei Balisen an, die aktuelle und die vorherige. Daraus kann die Strecke eine eindeutige Position ermitteln.
Die Angabe der Systemversionen, die das Fahrzeug beherrscht. Da das Packet erst ab Systemversion 2.1 definiert ist, gibt es folgende Kombinationsmöglichkeiten:
Mit diesem Packet kann einerseits festgestellt werden, ob die Übergabe in ein anderes RBC mit größerer Systemversion X (also von X=2 nach 3.0) möglich ist. Andererseits wird es auch benötigt, damit das RBC in SV X=2 die Anpassung für Fahrzeuge vornehmen kann, die nur ein kleineres Y beherrschen.
Die Angabe der Telefonnummern, unter denen das Fahrzeug erreichbar ist. Normalerweise sind es wohl zwei. Die Anzahl der Einträge ist aber formell nicht begrenzt, so dass theoretisch 32 Telefonnummern gemeldet werden können. In Systemversion 2.1 gibt es dieses Packet nicht mehr, da das RBC das Fahrzeug nicht anrufen kann. Allerdings muss ein RBC in SV 2.1 es dennoch von Fahrzeugen akzeptieren (Fahrzeug nach B3MR1).
Die Meldung eines vom Fahrzeug erkannten Fehlers an das RBC. Es gibt einen Satz von definierten Fehlergründen, die aber relativ pauschal sind. Es ist auch keinerlei Reaktion festgelegt.
Dieses Packet wurde ab Systemversion 2.0 aus P11 ausgelagert, da sich die Zugnummer durchaus öfter ändern kann als die restlichen Zugdaten.
Dieses Packet wird nur in Zusammenhang mit einer Balise mit P90 genutzt, um bei der Transition nach Level 2 eine MA zu erteilen.
Dieses Packet enthält die Länge des Fahrzeugverbands für Supervised Manoeuvre - nominal, minimal, maximal, nach vorn und hinten - oder keine sichere Länge.
Die "validierten", also vom Triebfahrzeugführer bestätigten Zugdaten. Mit einer Validierung im Sinne der Normen für sicherheitsrelevante Software im Eisenbahnwesen hat das allerdings nichts zu tun. Aber schauen wir mal auf einige der Inhalte:
Ähnlich wie P11 handelt es sich hier um Zugdaten, jedoch nicht vom Fahrzeugführer eingegeben, sondern Standardwerte. Es gibt keine Länge (dafür ist P10 da) und Liste der NID_NTC (in SM gibt es keine Leveltransitionen).
Das gleiche Packet gibt es auch in Gegenrichtung, der Aufbau ist allerdings etwas anders.
Diese Seite ist Teil eines Framesets © Sven Herzfeld Frameset laden
↑