Echtzeitdaten gelten im ÖPNV als Standard – in der Praxis erleben Fahrgäste jedoch öfters das Gegenteil. Tobias Schulz-Hess, Senior IT Cloud Architekt bei PROTOS, zeigt in seinem Beitrag aus Projektsicht, wo und warum Echtzeitinformationen entlang der Systemkette verloren gehen – und wie sich diese strukturellen Schwächen durch eine ereignisgetriebene Cloud-&-Edge-Architektur nachhaltig beheben lassen.
Im Fokus stehen dabei keine theoretischen Zielbilder, sondern ein pragmatischer Integrationsansatz, der bestehende Systeme einbindet und schrittweise weiterentwickelt.
Wenn „Echtzeit“ nicht beim Fahrgast ankommt
Wenn man mit IT-Verantwortlichen von Verkehrsunternehmen über Echtzeit spricht, fällt mir immer wieder derselbe Satz auf: ‚‚Fahrgäste beschweren sich öfters über die App. Anzeige und Betrieb passen nicht immer zusammen.‘‘
Unsere Erfahrung: Die Ursache liegt fast nie in der App – sondern in dem, was dahinter passiert: eine Kette aus ITCS, Bordrechnern, Datendrehscheiben und Schnittstellen, die im Alltag selten wirklich als durchgängiges System funktioniert.
Wir sehen in Projekten immer wieder die gleichen Symptome: Geisterbusse, verzögerte Prognosen, widersprüchliche Informationen. Nicht, weil die Daten fehlen – sondern weil sie auf dem Weg durch die Systeme, Schnittstellen und Übergaben verloren gehen.
Echtzeit aus Fahrgastsicht vs. Realität im System
Für den Fahrgast ist das Thema denkbar einfach: ‚‚Ich will wissen, wann mein Bus wirklich kommt.‘‘
Genau an dieser Stelle entsteht jedoch die größte Diskrepanz, die wir in Projekten sehen.
Denn technisch betrachtet ist diese scheinbar einfache Frage das Ergebnis einer langen Kette aus technischen und organisatorischen Übergaben:
Im Fahrzeug werden Positionsdaten erfasst. Der Bordrechner kombiniert diese mit Türsignalen, Fahrplandaten und weiteren Sensordaten. Im ITCS entstehen daraus Prognosen und Abweichungen. Diese Informationen werden über Datendrehscheiben, Verbünde und Landesplattformen verteilt.
Und erst am Ende dieser Kette stehen die Systeme, die der Fahrgast überhaupt sieht – Apps, Anzeigen oder Displays.
In der Praxis bedeutet das: Jeder einzelne Übergang in dieser Kette ist ein potenzieller Bruchpunkt.
Und genau dort entstehen die Inkonsistenzen, die später als „App-Problem“ wahrgenommen werden.
Wo Echtzeitdaten tatsächlich verloren gehen
Wenn man sich diese Kette in der Praxis anschaut, wird schnell klar:
Die Probleme entstehen nicht an einer Stelle – sondern an vielen kleinen Übergängen.
Genau diese Bruchstellen sehen wir in Projekten immer wieder – und sie folgen erstaunlich oft demselben Muster:
Im Fahrzeug beginnt es bereits bei der Datenerfassung.
Bordrechner arbeiten nicht durchgängig mit stabilen Mobilfunkverbindungen – insbesondere außerhalb urbaner Räume. Daten werden gepuffert, verzögert übertragen oder gehen im Roaming verloren. Gleichzeitig erschweren proprietäre Protokolle die saubere Integration in nachgelagerte Systeme.
Im ITCS setzen sich diese Probleme fort.
Viele Systeme sind historisch für den lokalen Betrieb entstanden – nicht für eine kontinuierliche Verarbeitung von Millionen externer Echtzeitabfragen. Prognosen entstehen häufig in festen Zyklen oder nach manueller Freigabe, statt ereignisgetrieben zu reagieren. Gerade in Störungssituationen führt das zu Verzögerungen, die sich durch die gesamte Kette ziehen.
In Datendrehscheiben und Verbundsystemen entstehen zusätzliche Inkonsistenzen.
Unterschiedliche Datenformate, parallele Verteilwege und batchbasierte Synchronisation sorgen dafür, dass identische Informationen an verschiedenen Stellen unterschiedlich aktuell sind. Die Information ist vorhanden – aber nicht konsistent.
Und auf der letzten Meile zum Fahrgast wird das Problem sichtbar.
APIs sind oft generisch statt nutzungsorientiert aufgebaut, Caching ist rein technisch gedacht, und ein durchgängiges Monitoring über alle Systeme hinweg fehlt. Fehler werden dadurch nicht früh erkannt, sondern erst dann, wenn der Fahrgast sie bereits erlebt.
Das Ergebnis sehen wir immer wieder:
Kein einzelner Fehler – sondern eine Kette aus kleinen Unschärfen, die sich kumulieren.
Und genau daraus entstehen die „Geisterbusse“, die am Ende als App-Problem wahrgenommen werden.
Genau diese Kette machen wir in Projekten sichtbar – und stabilisieren sie gezielt von innen heraus.
Wie eine durchgängige Echtzeitarchitektur entsteht
Die zentrale Frage, die wir in Projekten stellen: Wie bekommt man aus dieser fragmentierten Kette ein System, das wirklich in Echtzeit funktioniert?
Unsere Antwort darauf ist kein Tool – sondern ein Architekturprinzip:
Echtzeit muss durchgängig gedacht werden – vom Fahrzeug bis zur API.
Genau daraus ergibt sich der Ansatz, den wir bei PROTOS verfolgen: eine Kombination aus Edge-Intelligenz und einer konsequent ereignisgetriebenen Cloud-Architektur.
Im Fahrzeug beginnt die Stabilisierung bereits vor der Übertragung.
Daten werden nicht einfach weitergereicht, sondern vorverarbeitet: GPS-, Tür- und Fahrplandaten werden plausibilisiert, normalisiert und – wenn nötig – zwischengespeichert. Gerade bei instabilen Verbindungen ist das entscheidend, um Datenverluste zu vermeiden.
In der Cloud wird aus einem Datenstrom ein Ereignisstrom.
Statt periodischer Verarbeitung werden eingehende Informationen kontinuierlich über Streaming-Plattformen wie Kafka oder MQTT verarbeitet. Entscheidend ist dabei die Entkopplung: Produzenten und Konsumenten kennen sich nicht mehr direkt – das System wird dadurch robuster und skalierbarer.
Prognosen entstehen dort, wo sie hingehören: in eigenständigen Services.
Verspätungen, Umläufe oder Anschlusssituationen werden nicht mehr in monolithischen ITCS-Systemen berechnet, sondern in spezialisierten, ereignisgetriebenen Microservices. Auch manuelle Eingriffe – etwa Fahrtausfälle oder Dispositionsentscheidungen – werden als Events behandelt und nicht als nachgelagerte Korrektur.
Nach außen bleibt die Komplexität beherrschbar.
Über Adapter werden die Daten in bestehende Formate wie VDV oder GTFS-RT überführt. Für Apps, Anzeigen und Dritte stehen klar definierte APIs zur Verfügung, die auf unterschiedliche Nutzungsszenarien optimiert sind.
Und entscheidend: Die gesamte Kette wird sichtbar.
Durchgängiges Monitoring und gezieltes Alerting sorgen dafür, dass Probleme nicht erst beim Fahrgast auffallen, sondern bereits innerhalb der Architektur erkannt werden.
Der Unterschied zu klassischen Ansätzen ist dabei grundlegend:
Echtzeit entsteht nicht mehr durch das Weiterreichen von Daten –
sondern durch das gezielte Verarbeiten von Ereignissen entlang einer durchgängigen Architektur.
Wie der Weg dorthin in der Praxis aussieht
Die Frage, die wir fast immer gestellt bekommen, ist: Muss man dafür alles neu bauen?
Die kurze Antwort: Nein.
In der Praxis funktioniert dieser Wandel nur, wenn er schrittweise erfolgt – ohne den laufenden Betrieb zu gefährden. Genau deshalb setzen wir bei PROTOS auf einen pragmatischen Integrationsansatz, der bestehende Systeme einbindet, statt sie sofort zu ersetzen.
Der erste Schritt ist Transparenz.
Bestehende Fahrzeugflotten und ITCS-Systeme werden an eine zentrale Streaming-Infrastruktur angebunden – zunächst ohne in die bestehenden Prozesse einzugreifen. Die Daten werden gespiegelt und unter realen Bedingungen sichtbar gemacht.
Darauf aufbauend entsteht ein kontrollierter Parallelbetrieb.
Bestehende Systeme bleiben führend, während neue Datenflüsse, Prognosen und Architekturen im sogenannten „Shadow Mode“ validiert werden. So lassen sich Schwachstellen identifizieren, ohne Risiko für den operativen Betrieb.
Im nächsten Schritt wird der Fokus verschoben – von Analyse zu aktiver Nutzung.
Streaming-Daten werden nicht mehr nur beobachtet, sondern gezielt für Prognosen, Monitoring und Steuerung eingesetzt. Engpässe – sowohl technisch als auch organisatorisch – werden dadurch sichtbar und bewertbar.
Erst dann erfolgt die schrittweise Verlagerung von Logik in die Cloud.
Prognose- und Entscheidungslogik wird aus monolithischen ITCS-Systemen herausgelöst und in skalierbare Services überführt. Bestehende Plattformen und Verbundsysteme bleiben dabei integriert und werden über Adapter angebunden.
Langfristig entsteht so kein Bruch – sondern eine kontrollierte Transformation.
Einzelne Komponenten werden ersetzt, ohne das Gesamtsystem zu destabilisieren.
Genau das ist in unseren Projekten der entscheidende Unterschied:
Nicht der große Architekturentwurf entscheidet über den Erfolg –
sondern die Fähigkeit, bestehende Systeme kontrolliert in eine neue Realität zu überführen.
Genau an diesen Übergängen begleiten wir unsere Kunden – von der ersten Transparenz bis zur stabilen Zielarchitektur.
