Gestalten · 3.16
Abschlussfall: begründete Entscheidungsvorlage
Zeit: etwa 11–14 Minuten einschliesslich Aufgabe; Schätzung
Leitfrage: Welchen konkreten nächsten Schritt kannst du mit deiner Evidenz begründen?
Lernziel: Du erstellst eine konsistente Entscheidungsvorlage mit begrenztem Freigabeumfang.
Voraussetzungen: Die vorausgehenden Lektionen bis 3.15; insbesondere die dort erklärte Fallakte.
Eine Entscheidung für einen begrenzten nächsten Schritt
Du bereitest die Freigabe eines Talbahn-Piloten vor. Lea nutzt FRMCS-Zug 1234, Niko den festgelegten Dispatcher-Arbeitsplatz. Amir fährt im gemischten Versuch GSM-R-Zug 5678. Der Pilot umfasst betriebliche Sprache und eine Diagnoseanwendung. ETCS und ATO werden als gesonderte Integrationspakete bewertet; ihre Betriebsfreigabe wird nicht aus diesem Piloten abgeleitet.
Eine Entscheidungsvorlage macht deutlich, was entschieden werden kann, was noch offen ist und welche Bedingungen gelten. Du verwendest die Architektur- und Nachweisarbeit aus allen drei Stufen. Die Aufgabe verlangt keine erfundenen Herstellerfähigkeiten oder pauschalen V3-Zusagen.
Dein Auftrag: acht verbundene Bausteine
Beschreibe den Bedarf und die beteiligten Rollen; die Sprach- und Datenarchitektur; die Anwendungsschnittstellen; Spezifikationsstand und Anwendbarkeit; Migration und IWF; Test- und Abnahmekriterien; Betrieb und Schutz; Kosten und Entscheidung. Jeder Baustein muss zu den anderen passen. Wenn beispielsweise ein öffentlicher Zugang vorgesehen ist, erscheinen seine Berechtigung, Leistung, Ausfallprüfung und Kosten auch in den übrigen Teilen.
Durchgearbeitete Musterlösung
Bedarf: Niko soll die vorgesehenen Fahrer erreichen. Die Diagnoseanwendung soll vereinbarte Fahrzeugdaten liefern. Erfolg wird an nutzbarer Sprache beziehungsweise verarbeiteten Daten gemessen.
Architektur: Der Sprachfall nutzt das gewählte VAS-Profil mit den zugehörigen MCPTT-Client-Funktionen. Der Datenfall nutzt die lose gekoppelte Anbindung und MCData IPCon. Die Architektur trennt Steuerung, Medien beziehungsweise Daten und Verwaltungsabhängigkeiten. [S06; S09; S10]
Schnittstellen: OBAPP und TSAPP werden den richtigen Seiten zugeordnet. Das Dispatcher-VAS verwendet die im Kurs ausgewählte TSAPP-Variante; der Trackside Gateway wird für den Datenfall mit seinem Anwendungskontext betrachtet. Offene RAS-Funktionen bleiben konkrete Lieferantenfragen.
Baseline: Die Vorlage nennt die verwendeten Dokumentversionen und unterscheidet Lehrausgaben, rechtlich referenzierte Baseline und Produktstand. Ein erwarteter V3-Termin ist kein Produktnachweis. Stand & Zeitachse
Migration: Für Amir wird nur der nachgewiesene IWF-Umfang freigegeben. Die IWF-Funktionsmatrix umfasst Identitäten, Rufverhalten, Medien, Priorität und Fehlerfälle. Die Rückkehr in den vorherigen freigegebenen Zustand wird vorbereitet.
Tests: Sprache wird unter definierter Last und mit Sprechwechseln geprüft. Für Daten werden Annahme, Ablehnung, Neustart und Wiederherstellung geprüft. Ein öffentlicher Zugang erhält einen eigenen Last- und Ausfallversuch. ETCS-/ATO-Freigaben bleiben ausserhalb dieser Entscheidung.
Betrieb und Schutz: Zuständigkeiten für Identitäten, Konfiguration, Schlüssel, Dienstüberwachung und Störungsführung sind benannt. Gemeinsame Ausfallursachen werden trotz mehrerer Transportwege untersucht.
Kosten und Entscheidung: Der Kostenvergleich verwendet denselben Zeitraum und Funktionsumfang. Aus 3.15 werden auch Integrations- und Betriebskosten übernommen. Freigegeben wird nur der nachgewiesene Pilotumfang; offene Bedingungen erhalten Verantwortliche, Prüfpunkte und ein eindeutiges Abschlusskriterium.
Selbstbewertung
Vergib je Baustein 0 Punkte für fehlend/falsch, 1 für plausibel mit Lücken und 2 für konsistent mit benanntem Nachweis. Maximal sind 16 Punkte möglich. Ab 13 Punkten ist die Vorlage für eine fachliche Diskussion gut vorbereitet. Unabhängig von der Summe verhindern falsche Rollen, unzulässige Konformitätsbehauptungen oder ungeprüfte Sicherheitsfreigaben eine positive Bewertung. Dies ist eine Selbstbewertung, kein Zertifikat und keine reale Projektabnahme.
Das nimmst du mit
Eine gute Entscheidung verbindet den tatsächlichen Bedarf mit Architektur, Anforderungen, Evidenz und Betrieb. Offene Punkte werden entscheidbar gemacht, nicht sprachlich versteckt.
Deine Talbahn-Fallakte
Schliesse mit «Freigabeumfang», «Bedingungen», «Nicht entschiedener Umfang» und «Nächster Nachweis». Damit ist die Fallakte eine zusammenhängende Entscheidungsvorlage.
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
S10 · UIC FRMCS FFFIS FFFIS-7950
Version: 2.1.0 · Geprüft: 2026-10-11
Bezug: 5.1/5.2 OBAPP, 5.3/5.4 TSAPP, 5.6 Tight Coupling, 5.7 Loose Coupling; 6.3/6.6/6.7 Sicherheitsbezüge.
Geltungsgrenze: Anwendungsschnittstellen; keine allgemeine Betriebsordnung für Leitstellen.
Verwendet in: 2.1, 2.6, 2.11, 3.2, 3.3, 3.16
Dein Fortschritt wird in diesem Browser auf diesem Gerät gespeichert.
Ende dieser StufeStufenübersicht