Wissensbasis

Grenzueberschreitendes DAS und das Interoperabilitaetsproblem

Ein Driver Advisory System ueber mehr als ein Land hinweg zu betreiben klingt nach einem Datenproblem. Meistens ist es das auch. Aber die eigentliche Schwierigkeit sind nicht die Formate. Es ist, dass jeder Infrastrukturmanager denselben Standard leicht anders interpretiert, und jede Abweichung kann die Qualitaet der Empfehlung still untergraben.

Veroeffentlicht: 7. Februar 2026

ThemenSFERAInteroperabilitaetGrenzueberschreitender VerkehrUIC 90940RailMLATOInfrastrukturmanager

Interoperability architecture

One server absorbs many IM differences

Each infrastructure manager implements SFERA slightly differently. The RU-TS handles those differences centrally so a data quirk discovered in live service gets fixed once, server-side, without pushing a new release to every train.

IM traffic servers

IM-TS DE

DB InfraGO

Sends: EBuLa + ZLR

IM-TS BE

Infrabel

Sends: JP + SP (v3), C-DAS-C

IM-TS NL

ProRail

Sends: JP + SP (v2), RelatedTrainInfo

RU Traffic Server

Normalise, aggregate, enrich, correct

Every IM connection is handled here. Per-IM quirks are resolved in one place so that issues found in live service are fixed once, server-side.

Driver trust

Fix in hours, not the months a train release or IM data fix takes.

Normalised

Onboard DAS

One device, every country

Same advisory logic regardless of how many IMs are involved.

Warum der grenzueberschreitende Verkehr waechst

  • Der EU Green Deal nimmt die Verkehrsemissionen direkt ins Visier. Kurzstreckenfluege unter rund 1 000 km sind die klarste Substitutionschance, und die Bahn ist auf vielen Korridoren der erwartete Ersatz.
  • Nachtzugverbindungen werden wieder ausgebaut. Die OEBB Nightjet ist heute der groesste Nachtzugbetreiber Europas und faehrt durch Oesterreich, Deutschland, Italien, die Niederlande, Belgien, die Schweiz und Frankreich. European Sleeper, ein neuerer privater Betreiber, hat Bruessel nach Prag gestartet und plant Amsterdam nach Barcelona.
  • Grenzueberschreitender Gueterverkehr hat schon immer die Zusammenarbeit mehrerer Infrastrukturmanager erfordert. Ein Containerzug von Rotterdam nach Mailand kann auf einer einzigen Fahrt vier oder fuenf Grenzen kreuzen. Das ist nicht neu, aber der Druck, solche Fahrten mit Advisory-Systemen zu optimieren, schon.
  • Automatic Train Operation ist auf EU-Ebene eine politische Prioritaet. Die Investition hinter ATO, ueber Programme wie ERAs System Pillar und SIP-CCS, beschleunigt das Oekosystem standardisierter Boden-zu-Onboard-Datenschnittstellen. SFERA profitiert direkt von dieser Dynamik.
  • Jede neue grenzueberschreitende Verbindung bedeutet, dass ein DAS-Anbieter gleichzeitig mit mehreren Infrastrukturmanagern sprechen muss, jeder mit eigenen Datensystemen und Betriebsregeln.

Der Schmerzpunkt: jeder IM ist anders

  • SFERA-Konformitaet bedeutet keine identischen Implementierungen. Jeder Infrastrukturmanager hat eigenes Daten-Timing, eigene Nachrichtenreihenfolgen, Feldinterpretationen, Sitzungsstartsequenzen und lokale Erweiterungen.
  • Ein SFERA-Handshake, der mit einem IM reibungslos laeuft, verhaelt sich beim naechsten nicht immer gleich. Feine Unterschiede darin, wann Daten ankommen, wie Segmentgrenzen referenziert werden oder wie Sitzungen nach einer Stoerung neu starten, koennen alle zu falscher Empfehlung im Fuehrerstand fuehren.
  • Wenn ein Fahrer eine Empfehlung sieht, die falsch, zu spaet oder fehlend ist, folgt er ihr nicht mehr. Vertrauen bricht schnell und baut sich langsam wieder auf. Ein wochenlang ungeloestes Datenproblem ist also keine technische Unannehmlichkeit. Es ist ein Scheitern der Einfuehrung.
  • Historisch haben DAS-Lieferanten das mit landes- oder IM-spezifischen Software-Builds geloest, die auf die Onboard-Geraete gespielt wurden. Der Zug selbst musste die Eigenheiten jedes IM kennen, dem er begegnen koennte.
  • Onboard-Software auf Zuegen zu aktualisieren geht nicht schnell. Ein Release-Zyklus erfordert eine Sicherheitspruefung, ein Rollout-Fenster und Abstimmung mit dem Betreiber. In der Praxis haben Korrekturen IM-spezifischer Datenprobleme auf diesem Weg Monate oder laenger gebraucht, um die Flotte zu erreichen.
  • Auch auf die Datenkorrektur durch den IM zu warten ist keine realistische Option. Infrastrukturmanager haben eigene Release-Zyklen, interne Prioritaeten und Governance-Prozesse. Eine Meldung eines DAS-Lieferanten fuehrt vielleicht erst nach Monaten zu einer Datenkorrektur, wenn ueberhaupt im Einfuehrungsfenster.

Die Standardlandschaft

  • SFERA (UIC 90940) ist der primaere Standard fuer den DAS-Datenaustausch zwischen Boden- und Onboard-Systemen. Er deckt Journey Profiles, Segment Profiles, Train Characteristics, C-DAS-Empfehlungsnachrichten und den Sitzungslebenszyklus ab. Er ist der reifste und am aktivsten eingesetzte Standard in diesem Bereich.
  • ATO-Spezifikationen (SUBSET-126 und das ETCS-ATO-Profil) definieren die Boden-zu-Onboard-Schnittstelle fuer automatisierten Zugbetrieb. SFERA baut ausdruecklich auf dieser Arbeit auf. Mit wachsender ATO-Investition wird das breitere Oekosystem standardisierter Schnittstellen staerker, und DAS profitiert von derselben Infrastruktur.
  • RailML ist eine XML-Schemafamilie fuer Fahrplan-, Infrastruktur- und Fahrzeugdaten. Es wird ueblicherweise fuer den Offline-Austausch von Planungsdaten genutzt und ist als Quellformat fuer DAS-Journey-Profile-Eingaben relevant, definiert aber kein Live-Austauschprotokoll.
  • TAF-TAP (Telematics Application for Freight and Passengers) ist ein EU-verbindlicher Rahmen fuer grenzueberschreitende Gueterwagenverfolgung und Fahrgastinformation. Es wirkt auf der kommerziellen Logistikebene, zeigt aber dieselbe Multi-IM-Koordinationsherausforderung wie DAS.
  • Die ERA Technical Specifications for Interoperability (TSIs) bilden den rechtlichen Rahmen fuer grenzueberschreitende Bahntechnik. DAS ist noch nicht TSI-reguliert, bewegt sich aber im selben politischen Umfeld, und die Richtung geht zu staerker standardisierten Schnittstellen.

Was SFERA tatsaechlich leistet und was nicht

  • SFERA definiert den Nachrichtenumschlag, nicht die Datenqualitaet. Es legt fest, wie alle ein Journey Profile formatieren, garantiert aber nicht, dass der IM ein gutes bereit hat, wenn der Zug es braucht.
  • Es definiert Sitzungsstart und -ende, schreibt aber nicht vor, was passiert, wenn das IM-System langsamer ist als erwartet oder eine Sitzung mitten in der Fahrt abbricht.
  • Es unterstuetzt sowohl C-DAS-C-Empfehlungsnachrichten (Konstantfahrt- und Coasting-Anweisungen vom Boden) als auch die Daten fuer die C-DAS-O-Onboard-Berechnung (Journey Profiles, Segment Profiles, Train Characteristics, damit der Zug seine eigene Empfehlung berechnen kann).
  • Was es nicht loest: Daten-Governance, lokale Feldinterpretationen, Timing der Datenverfuegbarkeit oder die nicht standardisierten Erweiterungen, die manche IM fuer ihre internen Systeme hinzufuegen. Genau dort findet die eigentliche Einfuehrungsarbeit statt.

Die Antwort des RU-TS

  • Der RU-TS (Railway Undertaking Traffic Server) ist die serverseitige Komponente, die zwischen allen Infrastrukturmanagern und dem Onboard-Geraet sitzt. Jede IM-Verbindung wird auf dieser zentralen Schicht gehandhabt, nicht am Zug.
  • Der RU-TS macht vier Dinge mit den empfangenen Daten: normalisieren, aggregieren, anreichern und korrigieren. Normalisierung bringt inkonsistente Feldformate in ein gemeinsames Modell. Aggregation kombiniert Daten aus mehreren Quellen, wenn eine allein unvollstaendig ist. Anreicherung ergaenzt Kontext, den der IM nicht direkt liefert. Korrektur behandelt bekannte Datenqualitaetsprobleme an der Quelle.
  • Wenn ein IM etwas aendert oder im Livebetrieb ein neuer Sonderfall auftaucht, kommt die Korrektur in den RU-TS. Das Onboard-Geraet erhaelt eine stabile, saubere Schnittstelle, unabhaengig davon, was sich stromaufwaerts geaendert hat.
  • Im Livebetrieb gefundene Datenprobleme koennen serverseitig innerhalb von Stunden korrigiert werden. Das ist die Zeitskala, die fuer das Fahrervertrauen zaehlt, nicht die Monate, die ein Zug-Release oder eine IM-Datenkorrektur braeuchten.
  • Probleme werden dennoch an den IM zurueckgemeldet. Der RU-TS ist kein Weg, Quellprobleme zu ignorieren. Aber der Fahrer muss nicht warten, bis ein IM-Governance-Prozess durchlaufen ist, um zuverlaessige Empfehlung zu bekommen.
  • Das ist der architektonische Grund, warum grenzueberschreitender Betrieb keine landesspezifischen Firmware-Varianten bedeuten muss. Die Komplexitaet bleibt dort, wo sie schnell beherrschbar ist, in der Cloud, nicht im Zug.

Woher Datenprobleme in der Praxis kommen

  • Spaete oder fehlende Journey-Profile-Daten: das IM-System ist zur Abfahrtszeit nicht bereit, und der Zug startet seine Fahrt ohne vollstaendiges Profil. Der RU-TS kann es halten oder aus benachbarten Daten rekonstruieren, um dem Fahrer etwas Brauchbares zu geben.
  • Inkonsistente Abdeckung der Segment Profiles: manche Abschnitte sind gut beschrieben, andere duenn. Anreicherung im RU-TS kann Luecken aus alternativen Quellen fuellen.
  • Luecken in der Feldinterpretation: Geschwindigkeitseinheiten, Referenzen auf Segmentgrenzen und Authority-Identifikatoren, die sich zwischen IM auch innerhalb derselben SFERA-Version unterscheiden. Normalisierung loest das, bevor es den Zug erreicht.
  • Sonderfaelle beim Sitzungsneustart: ein IM trennt mitten in der Fahrt und verbindet sich mit teilweisem oder inkonsistentem Zustand neu. Der RU-TS handhabt die Wiederverbindungslogik, ohne dass der Fahrer es bemerkt.
  • Multi-IM-Uebergabe: der Zug kreuzt eine Grenze und eine neue IM-Sitzung muss starten, waehrend die vorige noch auslaeuft. Der RU-TS verwaltet beide Sitzungen und haelt die Schnittstelle zum Onboard-Geraet durchgaengig stabil.
  • In jedem Fall wuerde ein klassischer Ansatz ein Firmware-Update oder eine IM-Datenkorrektur erfordern, beides in Monaten gemessen. Der RU-TS loest sie serverseitig, in Stunden gemessen.

Grenzen

  • Der RU-TS-Ansatz handhabt Integration und Datennormalisierung, braucht aber weiterhin, dass der IM brauchbare Daten liefert. Hat ein Infrastrukturmanager keine Echtzeit-Fahrtinformation verfuegbar, behebt keine Architektur das.
  • Grenzueberschreitender Betrieb erfordert zudem betriebliche Vereinbarungen zwischen Eisenbahnverkehrsunternehmen und Infrastrukturmanagern. Solche Vereinbarungen brauchen Zeit und sind kein technisches Problem.
  • Die Standards, SFERA, RailML und ATO-Spezifikationen, reifen, sind aber nicht ueberall gleich tief eingefuehrt. Echte Interoperabilitaet ist ein Spektrum, kein Haekchen.

Verwandte Artikel

UIC 90940 SFERABahn-Glossar zu DAS und SignaltechnikDatenquellen nach Land