Trackside Gateway und streckenseitige Anbindung

Der Datenweg braucht eine streckenseitige Anbindung

Die Fahrzeuganwendung aus 2.9 hat einen Kommunikationspartner in der Infrastruktur. Dieser Partner soll keine Funkmodemfunktionen implementieren müssen. Das FRMCS Trackside Gateway stellt die streckenseitige Anwendungsanbindung bereit. TSAPP bezeichnet den dazugehörigen Anwendungsbezugspunkt. Das Gateway ist weder automatisch ein Dispatcher Terminal noch das Radio Block Centre einer ETCS-Anwendung. [S42, Abschnitte 4–6]

Wir betrachten zuerst eine lose gekoppelte Datenanwendung. Ihr fachlicher Prozess bleibt ausserhalb der Kommunikationsfunktion. Die Gateway-Seite übernimmt die zugehörigen MC-Service-Client-Verfahren und verbindet API-Zustände mit Dienstzuständen. Ein physischer Server kann mehrere solcher logischen Funktionen beherbergen; das ändert die Schnittstellenverantwortung nicht.

Registrierung, Profil und Sitzungszustand

Die streckenseitige Anwendung registriert sich an der Anbindung. Dabei entsteht ein Anwendungskontext: eine Zuordnung der registrierten Anwendung zu ihren Parametern und laufenden Vorgängen. Ein Railway Trackside Profile liefert die vorgesehenen Konfigurationsbezüge. Anwendungsregistrierung bedeutet nicht automatisch, dass die Dienstanmeldung bereits vollständig erfolgreich ist.

Bei einer ausgehenden Sitzung übergibt die Anwendung unter anderem die gewünschte Gegenstelle und Kommunikationskategorie. Das Gateway verwendet die passenden Zuordnungen für die MCData-Anforderung. Bei einer eingehenden Sitzung wird die lokale Gegenanwendung benachrichtigt. Sie kann den vorgesehenen Aufbau annehmen oder ablehnen. Die tatsächlichen Verfahren richten sich nach der gewählten Ausgabe und Kopplungsart. [S42, Abschnitte 6.2–6.3]

Grafik in voller Grösse öffnen (SVG, neuer Tab) G13

Steuerung und Datenweiterleitung gemeinsam prüfen

Im Datenfall muss die erfolgreiche Sitzung mit der richtigen lokalen Anwendungsadresse verbunden werden. Routing bestimmt den Weiterleitungsweg; NAT setzt die vorgesehenen Adressen um. Das Gateway darf deshalb nicht lediglich als «Kabelanschluss zur Leitstelle» gezeichnet werden. Es hält Zustände und Zuordnungen, die für den vollständigen Weg relevant sind.

Ein Beispiel: Die Talbahn startet die Gegenanwendung neu. Ein noch vorhandener alter Kontext kann nicht ungeprüft als neue Bereitschaft gelten. Die Anbindung muss die vorgesehenen Registrierungs-, Bereinigungs- und Benachrichtigungsverfahren durchlaufen. In der Fehleranalyse werden deshalb alter und neuer Kontext sowie laufende Sitzungen getrennt protokolliert.

Die Kopplungsvariante macht einen Unterschied

Bei Tight Coupling liegen MCX-Client-Funktionen in der Anwendung. Die Erklärung des lose gekoppelten Datenfalls darf nicht unverändert auf jede Sprachanwendung übertragen werden. Für das Fahrer- und Leitstellen-Sprachprofil folgt der Kurs den ausdrücklich benannten SRS-Regeln. Die nächste Lektion führt das Dispatcher-Beispiel weiter.

Prüfe dein Verständnis

Nach einem Neustart meldet die Anwendung «registriert», aber eine eingehende Datensitzung scheitert. Welche Grenzen untersuchst du vor einem Austausch des Funkmoduls?

Musterantwort

Ich prüfe Anwendungskontext und Profil, Dienstbereitschaft, Benachrichtigung und Annahme der eingehenden Sitzung sowie die Zuordnung zum lokalen Datenendpunkt. Registrierung an TSAPP ist nicht automatisch vollständige MCData-Bereitschaft. Erst Beobachtungen am Transport rechtfertigen eine Transporthypothese.

Das nimmst du mit

Das Trackside Gateway verbindet Anwendungsanbindung mit Kommunikationszuständen. Seine Aufgaben unterscheiden sich von Bedienarbeitsplatz, fachlicher Anwendung und GSM-R-Interworking.

Deine Talbahn-Fallakte

Zeichne für den lose gekoppelten Datenfall Anwendung, TSAPP, Gateway-Client-Funktionen und Dienstplattform. Markiere Steuerung und Daten getrennt.