On-Board FRMCS, TOBA und Anwendungsanbindung

Die gleiche Betriebsaufgabe hat zwei Enden

Im Fahrzeug bedient Lea ihre Sprachanwendung. In der Leitstelle verwendet Niko einen Arbeitsplatz für seine betrieblichen Gespräche. Beide Anwendungen brauchen Kommunikationsdienste; ihre Benutzeroberflächen und betrieblichen Aufgaben bleiben dennoch verschieden.

Die Telecom On-Board Architecture (TOBA) beschreibt die Kommunikationsarchitektur auf dem Fahrzeug. Sie ordnet Komponenten und Anschlüsse so, dass Anwendungen Kommunikationsleistungen nutzen können. TOBA bezeichnet weder die gesamte Leitstelle noch eine bestimmte einzelne Box.

OBAPP ist die Schnittstelle zwischen einer fahrzeugseitigen Anwendung und dem On-Board-FRMCS-System. Über sie werden die vorgesehenen Kommunikationsfunktionen angebunden. TSAPP ist die entsprechende Anwendungsschnittstelle auf der Streckenseite. Sie betrifft beispielsweise die Anbindung einer Leitstellenanwendung an das Trackside-FRMCS-System; sie ist kein zweiter fahrzeugseitiger Anschluss. [S10, S31]

Die fahrzeugseitigen funktionalen Anforderungen beschreibt UIC TOBA-7510, die TOBA-FRS. Sie legt fest, welche Fähigkeiten das On-Board-FRMCS-System bereitstellen soll. Dieser Kurs verwendet dafür Version 2.1.0 vom 25. April 2025. Die ERA-Liste für FRMCS B0 führt unter Index 099 dagegen Version 1.0.0; Lehrquelle und TSI-Referenzstand sind zu unterscheiden. Die Schnittstellendetails zu OBAPP und TSAPP stehen ergänzend in der FFFIS. [S39, S16, S10]

Wo sitzt der MCX-Client?

Aus 2.4 kennst du den MCX-Client als dienstseitigen Teilnehmer auf der Nutzerseite. Die Form Fit Functional Interface Specification (FFFIS) beschreibt die vorgesehenen Anwendungsschnittstellen. Sie legt unter anderem fest, wie Anwendungen angebunden werden und Kommunikationsfunktionen nutzen. Dazu gehören unterschiedliche Formen der MCX-Client-Einbindung.

Bei Tight Coupling ist der MCX-Client in die Anwendung eingebunden. Nach der lokalen Anbindung nutzt er die vorgesehenen Kommunikationsmöglichkeiten über OBAPP beziehungsweise TSAPP. Die Anwendung übernimmt damit mehr dienstbezogene Aufgaben.

Bei Loose Coupling nutzt die Anwendung eine angebotene Programmierschnittstelle, während das FRMCS-System die zugehörigen MCX-Client-Funktionen bereitstellt. Eine API ist eine festgelegte Schnittstelle, über die Software Funktionen anderer Software aufruft. Die Anwendung kann damit etwa eine Kommunikationssitzung anfordern, ohne selbst sämtliche MCX-Verfahren umzusetzen. [S10, Abschnitte 5.6–5.7]

Diese Unterscheidung sagt nicht, dass Tight immer schneller oder Loose immer austauschbar ist. Austauschbarkeit hängt von den konkret unterstützten Funktionen, Versionen, Fehlerreaktionen und Sicherheitsvorgaben ab.

Welche Anbindung gilt für unser Sprachbeispiel?

Das Voice Application Subsystem (VAS) bündelt die Funktionen der betrieblichen Sprachanwendung. Es verbindet die Bedienung mit den benötigten Sprachdiensten. Für das Fahrer-VAS schreibt die hier verwendete SRS 2.1.0 Tight Coupling über OBAPP vor. Die allgemein erklärte Loose-Coupling-Variante ist deshalb keine frei wählbare Alternative für dieses Sprachprofil. [S06, Abschnitt 24.2.3.3]

Beim Leitstellen-VAS hängt der Weg von der TSAPP-Unterstützung ab: Unterstützt es TSAPP, nutzt es TSAPP mit Tight Coupling. Andernfalls erfolgt die Anbindung über TSCTRL. Dieser eigene Bezugspunkt verbindet das Leitstellen-VAS mit den FRMCS-Kommunikationsdiensten. Ein Leitstellen-VAS verwendet TSAPP und TSCTRL nicht gleichzeitig. [S06, Abschnitte 6.4.1.3 und 24.3.3.2–24.3.3.4]

Für Niko wählen wir im Talbahn-Beispiel die TSAPP-Variante. Lea nutzt OBAPP, Niko TSAPP, jeweils mit Tight Coupling. Die folgende Grafik zeigt diese ausgewählte Sprachvariante und logische Grenzen. Ein Hersteller kann mehrere Funktionen auf gemeinsamer Hardware unterbringen; Schnittstellen und Verantwortlichkeiten bleiben trotzdem zu bestimmen.

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

Eine Schnittstelle braucht ein Verhalten

Nikos Anwendung fordert eine Verbindung zur Rolle «Lokführer Zug 1234» an. In diesem Testfall ist Lea dieser Rolle zugeordnet. Für ihre Anbindung muss die Talbahn mindestens wissen:

• welche Identität und Berechtigung die Anwendung verwendet;
• wie sie Erfolg, Ablehnung und Verbindungsverlust erkennt;
• welche Zustände nach Neustart oder Unterbrechung wiederhergestellt werden;
• wer Schnittstellenänderungen und Fehler auf jeder Seite verantwortet.

Ein erfolgreich übergebener Aufruf bedeutet noch nicht, dass Lea Sprache hört. Zwischen Aufruf und hörbarem Ergebnis liegen die Dienst- und Transportanteile aus 2.8.

Die On-Board-Spezifikation ist eine passende Quelle für die Fahrzeugarchitektur. Sie ersetzt keine allgemeine betriebliche Spezifikation der Leitstelle. Für die Fallakte werden deshalb Schnittstellenbeschreibung, betriebliche Leitstellenanforderung und Nachweis getrennt geführt.

Prüfe dein Verständnis

Ein Angebot nennt «TOBA mit OBAPP und TSAPP im Fahrzeug» und behauptet, Loose Coupling garantiere den Wechsel der Leitstellenanwendung ohne Nachtest. Korrigiere beide Aussagen. Welche Anbindung verwendet das hier betrachtete Fahrer-VAS?

Musterantwort

OBAPP gehört zur fahrzeugseitigen Anwendungsanbindung, TSAPP zur streckenseitigen. Beide sind keine zwei Anschlüsse derselben Fahrzeugarchitektur. Loose Coupling beschreibt die Einbindung über eine API und den Ort der MCX-Client-Funktionen. Für einen Anwendungswechsel müssen trotzdem Schnittstellenumfang, Versionen, Berechtigungen und Fehlerverhalten in der konkreten Kombination geprüft werden. Das Fahrer-VAS nutzt nach der betrachteten SRS 2.1.0 OBAPP mit Tight Coupling.

Das nimmst du mit

Eine klar benannte Schnittstelle trennt Zuständigkeiten; sie ersetzt keinen Funktionsnachweis.

Deine Talbahn-Fallakte

Trage OBAPP und TSAPP auf den richtigen Seiten deiner Systemkarte ein. Halte für die Fahrzeuganwendung fest, wo der MCX-Client sitzt und wer die Schnittstelle verantwortet. Kennzeichne die Sprachvariante mit Tight Coupling auf beiden Seiten und die Auswahl von TSAPP für Niko.