Anwenden · 2.22
Abschlussfall: drei Kommunikationswege
Zeit: etwa 7–10 Minuten einschliesslich Aufgabe; Schätzung
Leitfrage: Kannst du drei Kommunikationswege samt Fehlerfällen erklären?
Lernziel: Du erklärst drei vollständige Kommunikationswege samt Fehlerzuordnung.
Voraussetzungen: Die vorausgehenden Lektionen bis 2.21; insbesondere die dort erklärte Fallakte.
Drei Wege, ein gemeinsames Verständnis
Die Talbahn bereitet einen Integrationsversuch vor. Lea fährt FRMCS-Zug 1234; Niko arbeitet am Dispatcher Terminal. Für den gemischten Sprachfall fährt Amir ausdrücklich GSM-R-Zug 5678. Das separate FRMCS-Testgerät aus dem MCPTT-Lehrablauf ist in diesem Versuch nicht Amirs Fahrzeugausrüstung. Eine Diagnoseanwendung überträgt zusätzlich Fahrzeugdaten. Alle Angaben beschreiben einen fiktiven Lehrfall.
Die Aufgabe verbindet die zuvor erklärten Funktionen. Für jeden Weg werden Ausgangspunkt, Gegenstelle, Anwendungsanbindung, Dienst, Transport und Erfolgskriterium benötigt. Eine Architekturzeichnung allein reicht nicht: Du ergänzt, wie die Kommunikation vorbereitet, aufgebaut, benutzt und beendet wird.
Dein Auftrag
Erstelle drei kommentierte Wege: einen FRMCS-Sprachruf zwischen Lea und Niko, einen Datenfall zwischen Fahrzeug- und Streckenanwendung sowie einen gemischten Ruf mit Amir über die IWF. Kennzeichne bei jedem Steuerung und Nutzdaten. Beschreibe anschliessend einen Fehler: Dienstautorisierung fehlt, Gegenanwendung lehnt ab oder IWF fällt aus. Weise die Fehler jeweils dem passenden Weg zu.
Musterlösung
Beim Sprachruf sind Netz- und Dienstzugang vorbereitet. Die gewählte Sprachanwendung nutzt ihre MCPTT-Client-Funktionen. SIP-basierte Steuerung unterstützt den Aufbau; dienstspezifische Funktionen bestimmen Teilnahme und Sprechrecht. Medien müssen bis zur richtigen Audioausgabe gelangen. Fehlende Dienstautorisierung wird nicht durch einen erfolgreichen Funkzugang behoben.
Beim Datenfall nutzen wir die lose gekoppelte H2H-Variante. Die Fahrzeuganwendung fordert ihre Sitzung an. MCData und die streckenseitige Anbindung verbinden die vorgesehenen Partner. Lehnt die Gegenanwendung ab, ist dies ein anderer Befund als Paketverlust nach erfolgreichem Aufbau. Die Anwendungsgrenze, das Gateway und der Dienst erhalten getrennte Beobachtungen.
Beim gemischten Ruf wird die IWF nur für ihren nachgewiesenen Funktionsumfang eingeplant. Identitäten, Rufverhalten, Sprechsteuerung, Medien und Priorität benötigen eine passende Abbildung. Ein IWF-Ausfall kann den systemübergreifenden Weg unterbrechen, obwohl FRMCS-interne Kommunikation weiter funktioniert. Ein Ersatzverfahren wird nur dann genannt, wenn Ausrüstung, Berechtigung und freigegebener Ablauf bestehen.
Für keinen Weg genügt das Etikett «FRMCS vorhanden». Die Talbahn benötigt die Kombination aus Anwendungsprofil, Implementierung und beobachtbarem Ergebnis. [S07; S09; S11; S42]
Selbstbewertung
Bewerte sechs Kriterien mit jeweils 0 Punkten für fehlend/falsch, 1 für teilweise und 2 für nachvollziehbar: richtige Partner; Anwendungsanbindung; Dienstzustände; Trennung Steuerung/Nutzdaten; Fehlerzuordnung; passender Nachweis. Maximal sind 12 Punkte möglich. Für den Übergang zu Stufe 3 sind mindestens 10 Punkte sinnvoll. Unabhängig davon müssen Dienst und Transport getrennt bleiben und die IWF darf nicht als universeller Funktionskonverter dargestellt werden.
Das nimmst du mit
Du kannst nun eine Kommunikation durch die Architektur verfolgen und Beobachtungen den richtigen Funktionen zuordnen. Stufe 3 verwendet dieses Verständnis für Projektentscheidungen.
Deine Talbahn-Fallakte
Bewahre die drei Wege als Referenz auf. Ergänze offene technische Fragen ausdrücklich; ersetze sie nicht durch angenommene Produkteigenschaften.
Quellen
S07 · ETSI TS 103 764: FRMCS System Architecture
ETSI TS 103 764: FRMCS System Architecture
Version: 1.1.1, Januar 2026 · Geprüft: 2026-10-11
Bezug: Architekturabschnitte: FRMCS-Systemgrenze, Service und Transport, nutzende Anwendungen.
Geltungsgrenze: Grafiken im Lehrgang sind eigene Vereinfachungen, keine normativen Referenzbilder.
Verwendet in: 1.3, 1.5, 1.8, 1.9, 1.10, 2.1, 2.22
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
S11 · ETSI TS 103 792: FRMCS/GSM-R Interworking
ETSI TS 103 792: FRMCS/GSM-R Interworking
Version: 1.1.1, Januar 2026 · Geprüft: 2026-10-11
Bezug: Interworking-Architektur und definierte Funktionsvermittlung.
Geltungsgrenze: Unterstützung pro Funktion und Kombination nachweisen; keine universelle ETCS-Übersetzung.
Verwendet in: 1.10, 2.7, 2.20, 2.22
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.
Ende dieser StufeStufenübersichtWeiter mit Stufe 3: Gestalten →