Anwenden · 2.9
MCData: eine Datensitzung vollständig verfolgen
Zeit: etwa 8–11 Minuten einschliesslich Aufgabe; Schätzung
Leitfrage: Wie wird aus einer Anwendungsanforderung eine nutzbare Datensitzung?
Lernziel: Du verfolgst eine MCData-IPCon-Sitzung vom Anwendungswunsch bis zur Beendigung.
Voraussetzungen: Die vorausgehenden Lektionen bis 2.8; insbesondere die dort erklärte Fallakte.
Vom Anwendungswunsch zur Datensitzung
Eine Fahrzeuganwendung der Talbahn soll Daten an eine streckenseitige Gegenanwendung übertragen. Wir betrachten eine lose gekoppelte Verbindung: Die Anwendung nutzt die FRMCS-Programmierschnittstelle, während die FRMCS-Ausrüstung MCData-Client-Verfahren ausführt. Eine Programmierschnittstelle, kurz API, ermöglicht solche Softwareaufrufe mit festgelegten Parametern und Rückmeldungen.
MCData IP Connectivity, kurz IPCon, stellt im betrachteten Profil eine dienstgesteuerte IP-Kommunikation bereit. Sie ist mehr als ein erreichbarer Netzanschluss: Endpunkte, Berechtigungen und Sitzung müssen zusammenpassen. Eine Sitzung bezeichnet hier den verwalteten Kommunikationszusammenhang zwischen den vorgesehenen Partnern. [S09, Abschnitt 6.2.2]
Ein vollständiger Lehrablauf
Die Anwendung meldet sich zunächst an ihrer lokalen FRMCS-Anbindung an. Diese ordnet die Anwendung einer freigegebenen Konfiguration und Dienstidentität zu. Netz- und Dienstbereitschaft sind Voraussetzungen, nicht das Ergebnis der ersten gesendeten Nutzdaten.
Anschliessend fordert die Anwendung eine Sitzung zu einer benannten Gegenstelle mit einer Kommunikationskategorie an. Diese Kategorie ordnet den Austausch einer vorgesehenen Behandlung zu. Die Client- und Serverfunktionen bearbeiten den Aufbau. Auf der Gegenseite muss die richtige Anwendung angebunden und zur Annahme bereit sein. Die Gateway-Lektion erklärt diese Seite genauer.
Nach erfolgreichem Aufbau liefert die Anbindung die vorgesehenen Sitzungs- und Adressinformationen. Die Anwendung sendet nun IP-Pakete. Der Dienst verwendet den dafür eingerichteten Datenweg; die SIP-Signalisierung transportiert nicht den gesamten Anwendungsdatenstrom. Bei Beendigung werden Sitzung und zugehörige Zuordnungen bereinigt. Bei einem Fehler benötigt die Anwendung eine passende Rückmeldung statt einer dauerhaft irreführenden Anzeige «verbunden». [S09; S42]
Zwei Adressierungsmodelle
Host-to-Host (H2H) verbindet zwei Endsysteme. Host-to-Network (H2N) verbindet ein Endsystem mit einem Datennetz. Die Wahl beschreibt die benötigte Kommunikationsbeziehung; sie ist nicht einfach ein anderes Wort für Funkzugang. Im H2H-Lehrfall muss klar sein, welches Fahrzeug mit welcher streckenseitigen Instanz kommuniziert. [S06, Abschnitt 6.5.2]
Adressabbildungen können lokale Anwendungsadressen und die im Kommunikationsweg verwendeten Adressen unterscheiden. Network Address Translation (NAT) bezeichnet die entsprechende Umsetzung von Adressinformationen. Ein Tunnel kapselt Pakete für einen definierten Übertragungsabschnitt. Dadurch kann ein Paketmitschnitt ausserhalb des Tunnels andere Adressen zeigen als ein Mitschnitt direkt an der Anwendung. Die Fallakte hält beide Sichtweisen fest, ohne konkrete Adresswerte zu erfinden.
Eine erfolgreiche Sitzung ist noch kein fachliches Ergebnis
Die Gegenanwendung kann Daten empfangen und trotzdem ablehnen, etwa weil die Nachricht zur falschen fachlichen Sitzung gehört. Deshalb prüft die Talbahn nacheinander Aufbau, Datenfluss und Anwendungsverarbeitung. In der ETCS-Lektion wird daraus die wichtige Trennung zwischen Kommunikationsbereitschaft und gültiger Zugbeeinflussungsinformation.
Prüfe dein Verständnis
Die Sitzungsanforderung wird angenommen, am Gateway sind Pakete sichtbar, die Gegenanwendung verarbeitet sie aber nicht. Welche drei Zuordnungen kontrollierst du?
Musterantwort
Ich kontrolliere die Zuordnung zur richtigen Gegenanwendung, die Sitzungs- und Adressabbildung sowie die fachliche Zuordnung innerhalb der Anwendung. Gateway-Pakete allein beweisen weder korrekte Weiterleitung zum richtigen Prozess noch eine gültige Anwendungsnachricht.
Das nimmst du mit
Eine MCData-Datensitzung verbindet Dienstzustände mit einem Datenweg. Anwendungsbereitschaft, Dienstbereitschaft und fachlicher Erfolg bleiben unterscheidbar.
Deine Talbahn-Fallakte
Dokumentiere die Schritte Anmeldung, Aufbau, Übertragung und Beendigung. Ergänze je eine Beobachtung auf Anwendungs- und Dienstseite.
Quellen
S06 · UIC FRMCS SRS AT-7800
Version: 2.1.0, 30.04.2025 · Geprüft: 2026-10-11
Bezug: Systemanforderungen, Architektur, Dienst-/Transportzusammenspiel und Mobilität. Functional Alias: 11.6/21.3; Sprachprofile: 24.2.3.3 und 24.3.3.2–4; TSCTRL: 6.4.1.3.
Geltungsgrenze: Projektbaseline muss konkrete anwendbare Teile festlegen.
Verwendet in: 1.3, 2.4, 2.7, 2.9, 2.11, 2.13, 2.15, 2.16, 2.17, 2.18, 2.19, 3.2, 3.3, 3.16
S09 · ETSI TS 103 765-2: FRMCS Service Stratum
ETSI TS 103 765-2: FRMCS Service Stratum
Version: 1.1.1, Januar 2026 · Geprüft: 2026-10-11
Bezug: Dienstarchitektur; Begriffsdefinition SIP Core; Registrierung und MC-Dienste.
Geltungsgrenze: IMS und SIP nicht gleichsetzen; Architektur erlaubt die spezifizierten SIP-Core-Alternativen.
Verwendet in: 1.9, 2.1, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 2.10, 2.14, 2.19, 2.22, 3.5, 3.16
S42 · ETSI TS 103 765-4: Trackside functions and interfaces
ETSI TS 103 765-4: Trackside functions and interfaces
Version: 1.1.1 (2026-01) · Geprüft: 2026-10-11
Bezug: Abschnitte 4–6: Trackside Gateway, Kontext und Verfahren.
Geltungsgrenze: Benannte Lehrausgabe; keine pauschale Produkt- oder Projektfreigabe.
Verwendet in: 2.1, 2.9, 2.12, 2.22, 3.3, 3.5
Dein Fortschritt wird in diesem Browser auf diesem Gerät gespeichert.