Echtzeit-Flottenmanagement im ÖPNV bedeutet, jederzeit zu wissen, wo jeder Bus ist, welche Fahrt er fährt und wie weit er vom Fahrplan abweicht, und auf dieser Grundlage zu handeln. Bei einem Busunternehmen übernimmt das ein RBL (rechnergestütztes Betriebsleitsystem, international ITCS), das fünf Bereiche abdeckt: Fahrzeugortung, Fahrplantreue, Leitstelle und Disposition, Fahrgastinformation sowie Betriebsdaten.
Der Unterschied ist wichtig: Ein Lieferdienst verfolgt Transporter, Kraftstoff und Fahrverhalten, ein Verkehrsunternehmen dagegen muss Fahrten gegen einen veröffentlichten Fahrplan verfolgen, Takte regelmäßig halten, Fahrgäste informieren und dem Aufgabenträger die erbrachten Fahrten melden. Dieser Leitfaden zeigt, was ein RBL leistet, welche Daten und Standards es erzeugt, was die EU inzwischen verlangt und wie man ein System auswählt.
Was ist Echtzeit-Flottenmanagement im ÖPNV?
Im ÖPNV ist die Steuerungseinheit nicht das Fahrzeug allein, sondern das Fahrzeug auf einer geplanten Fahrt. Ein Bus, der mit laufendem Motor im Betriebshof steht, ist ein Telematik-Ereignis. Derselbe Bus, der um 07:42 Uhr mit drei Minuten Verspätung an der ersten Haltestelle der Linie 12 abfährt, ist ein betriebliches Ereignis, das Fahrgäste, Anschlüsse und den Vertrag mit dem Aufgabenträger betrifft.
Ein RBL verknüpft drei Informationsebenen:
- Der Plan: der Fahrplan (meist eine GTFS- oder NeTEx-Datei), die Umlauf- und Dienstpläne, die Haltestellen und Linienverläufe.
- Die Realität: GPS-Positionen, Türereignisse, die Fahrt, auf der der Fahrer angemeldet ist, die tatsächlichen Zeiten an jeder Haltestelle.
- Die Reaktion: was die Leitstelle tut, wenn die Realität vom Plan abweicht, und was den Fahrgästen mitgeteilt wird.
Allgemeine Telematik oder RBL?
Allgemeine Flottentelematik auf Basis von Telematikboxen im Fahrzeug ist auf Fahrzeuge und Fahrer ausgerichtet: Ortung, Motordiagnose, Kraftstoffverbrauch, Fahrverhalten, Wartung und Sicherheit. Diese Funktionen sind für jede Flotte nützlich, auch für Busse.
Ein RBL geht vom Fahrplan aus. Seine Kernobjekte sind Linien, Fahrten, Haltestellen und Dienste. Der folgende Vergleich betrifft den Schwerpunkt, nicht die Qualität: Viele Verkehrsunternehmen nutzen beide Werkzeugtypen parallel.
| Kriterium | Allgemeine Flottentelematik | RBL |
|---|---|---|
| Bezugsobjekt | Fahrzeug, Fahrer, Anlage | Geplante Fahrt, Linie, Haltestelle |
| Kernfrage | Wo ist das Fahrzeug, wie wird es gefahren? | Ist die Fahrt pünktlich, und was sehen die Fahrgäste? |
| Fahrplandaten | Nicht zentral | GTFS- oder NeTEx-Fahrplan importiert und abgeglichen |
| Hauptergebnisse | Kraftstoff, Diagnose, Fahrerbewertung, Geofences | Pünktlichkeit, erbrachte Fahrten, Kilometer, GTFS-RT- und SIRI-Feeds |
| Nutzer | Fuhrpark- und Werkstattleitung | Disponenten, Fahrer, Planer, Aufgabenträger, Fahrgäste |
Wenn Ihr Hauptproblem Kraftstoff oder Wartung ist, liefert Telematik die Antwort. Wenn es um Betriebsqualität und Fahrgastinformation geht, brauchen Sie ein RBL.
Kernfunktionen: Was leistet ein RBL jede Minute?
Fahrzeugortung und Fahrtzuordnung
Die GPS-Ortung ist der einfache Teil. Der schwierige Teil ist die Fahrtzuordnung: zu wissen, welche geplante Fahrt ein Fahrzeug gerade fährt. Sie kann aus der Anmeldung des Fahrers auf einem Dienst stammen, aus der automatischen Erkennung entlang des Linienverlaufs oder aus beidem. Ohne zuverlässige Fahrtzuordnung ist jede nachgelagerte Kennzahl (Pünktlichkeit, Prognosen, erbrachte Fahrten) falsch.
Fahrplan- und Takttreue
Sobald die Fahrt bekannt ist, vergleicht das System an jeder Haltestelle Ist- und Sollzeiten. Zwei Logiken bestehen nebeneinander:
- Fahrplantreue auf Linien mit geringerer Frequenz, auf denen Fahrgäste nach Fahrplan fahren. Die Kennzahl ist die Verfrühung oder Verspätung gegenüber der veröffentlichten Zeit.
- Takttreue auf hochfrequenten Linien, auf denen Fahrgäste einfach zur Haltestelle kommen. Die Kennzahl ist die Regelmäßigkeit der Abstände zwischen den Bussen, denn Pulkbildung schadet mehr als eine gleichmäßige Verspätung.
Ein gutes RBL lässt das Verkehrsunternehmen die Logik je Linie und Zeitfenster wählen.
Werkzeuge für die Leitstelle
Echtzeit ist nur wertvoll, wenn jemand darauf reagieren kann. Die üblichen Eingriffe der Betriebslenkung sind:
- Halten eines Busses an einem Zeitpunkt, um einen Takt wiederherzustellen oder einen Anschluss zu sichern.
- Umleitungen bei gesperrten Straßen, mit Übermittlung der Abweichung an die Fahrer und an die Fahrgastinformation.
- Ersatz und Ausfälle, wenn ein Fahrzeug liegen bleibt oder ein Fahrer fehlt: Die Fahrt wird entweder neu zugewiesen oder in den Daten als ausgefallen markiert.
- Fahrerkommunikation, vordefiniert oder als Freitext, in beide Richtungen, damit die Leitstelle nicht allein auf Sprechfunk angewiesen ist.
Jeder Eingriff sollte protokolliert werden, denn diese Protokolle erklären die Differenz zwischen geplanter und erbrachter Leistung, wenn der Aufgabenträger danach fragt.
Fahrgastinformation: GTFS-RT, SIRI, Anzeigen und Apps
Fahrgäste beurteilen ein Netz nach der Genauigkeit der Wartezeiten, nicht nach der GPS-Präzision. Das RBL erzeugt Prognosen und Störungsmeldungen und verteilt sie über mehrere Kanäle.
Standards: GTFS-RT und SIRI
- GTFS-RT (GTFS Realtime) ist das Format, das Reiseplaner wie Google Maps, Moovit oder Citymapper verarbeiten. Es umfasst drei Feed-Typen: Fahrtaktualisierungen (prognostizierte Zeiten, Ausfälle), Fahrzeugpositionen und Störungsmeldungen.
- SIRI (Service Interface for Real Time Information) ist der europäische CEN-Standard für den Echtzeitaustausch zwischen Systemen, der von Aufgabenträgern und nationalen Zugangspunkten breit genutzt wird.
Der Export beider Formate ist in Europa inzwischen eine Grundanforderung. In Frankreich listet der nationale Zugangspunkt transport.data.gouv.fr 221 GTFS-RT-Datensätze und 43 SIRI-Datensätze (Statistikseite, abgerufen im Oktober 2026). Von den GTFS-RT-Datensätzen liefern 200 Fahrtaktualisierungen, 146 Fahrzeugpositionen und 78 Störungsmeldungen, was zeigt, dass Prognosezeiten verbreiteter sind als Störungsmeldungen.
Anzeigen und Apps
Dieselben Daten speisen Haltestellenanzeiger, Bildschirme und Ansagen im Fahrzeug, die eigene App und Website des Netzes sowie Apps von Drittanbietern. Die Regel lautet: eine einzige Datenquelle. Wenn Haltestellenanzeiger und App sich widersprechen, verlieren Fahrgäste das Vertrauen in beide. Wie die Fahrgastinformation aus einer Quelle aufgebaut ist, zeigt Pysae Passenger.
Daten und Kennzahlen: Was sollte gemessen werden?
Echtzeit-Flottenmanagement erzeugt auch eine historische Aufzeichnung, oft das wertvollste Ergebnis für die Unternehmensführung und das Vertragsreporting. Die zentralen Kennzahlen:
| Kennzahl | Was sie misst | Häufiger Fehler |
|---|---|---|
| Pünktlichkeit | Anteil der Abfahrten innerhalb eines Toleranzfensters (zum Beispiel 1 Minute zu früh bis 5 Minuten zu spät) | Toleranz im Vertrag nicht definiert oder nur an der Endhaltestelle gemessen |
| Taktregelmäßigkeit | Schwankung der Abstände auf dichten Linien | Über den Tag gemittelt, wodurch die Pulkbildung in der Spitze verborgen bleibt |
| Erbrachte Fahrten | Geplante gegenüber gefahrenen Fahrten, mit Ursache für jede Abweichung | Teilfahrten als vollständig gezählt |
| Nutzkilometer | Im Fahrgastbetrieb gefahrene Strecke je Linie und Fahrzeug | Vermischung von Leerfahrten und Nutzkilometern |
| Fahrzeiten | Tatsächliche Fahrzeit je Abschnitt und Zeitfenster | Nicht in die Fahrplanüberarbeitung zurückgeführt |
Fahrzeiten je Abschnitt und Zeitfenster sind das Rohmaterial für jede Neugestaltung des Fahrplans, ob durch Planer oder mit KI-Werkzeugen: Kein Modell kann besser planen als die Ist-Daten, die es erhält. Warum das so ist, erklärt unser Beitrag zur KI-gestützten Busnetzplanung; wie diese Daten in die Netzplanung einfließen, zeigt Pysae Network.
Bordhardware: dedizierte Geräte oder Smartphones und Tablets?
Das Bordgerät ist oft der größte Kostenblock und der langsamste Teil einer RBL-Einführung. Es gibt zwei Hauptansätze.
Dedizierte Bordrechner werden im Fahrzeug verbaut und mit dem Fahrzeugnetz, Türsensoren, Vertrieb, Fahrgastzählsystemen und Anzeigen verbunden. Sie eignen sich für große Stadtflotten mit vielen integrierten Teilsystemen. Der Einbau erfordert Standzeiten und Facharbeit.
Smartphones und Tablets in einer Halterung führen eine Fahrer-App aus, die Anmeldung, Fahrtzuordnung, Kommunikation und Navigation übernimmt. Die Einführung geht schnell, die Hardware ist handelsüblich ersetzbar, und dasselbe Gerät kann im Schülerverkehr, im Regional- und im Stadtverkehr eingesetzt werden. Grenzen zeigen sich, wenn viele Bordsysteme miteinander verkabelt werden müssen.
ITxPT ist die Referenz für den integrierten Ansatz. Der gemeinnützige Verband veröffentlicht technische Spezifikationen für eine offene, interoperable IT-Architektur an Bord und vergibt ein Label, das bestätigt, dass Geräte oder Software diesen Spezifikationen entsprechen. Wer in einer Ausschreibung ITxPT-Konformität verlangt, schützt sich vor der Bindung an einen einzigen Hardwareanbieter.
Viele Netze kombinieren beide Ansätze, sofern alle Fahrzeuge in dasselbe RBL und dasselbe Datenmodell melden.
EU-Datenpflichten: Was verlangt die Delegierte Verordnung 2024/490?
Die Delegierte Verordnung (EU) 2024/490 der Kommission hat den MMTIS-Rahmen (multimodale Reiseinformationsdienste, ursprünglich Verordnung 2017/1926) überarbeitet. Sie ist am 4. März 2024 in Kraft getreten und legt Termine fest, bis zu denen Daten über den nationalen Zugangspunkt jedes Mitgliedstaats bereitgestellt werden müssen.
Für dynamische Daten zum Linienverkehr nennt der Text Störungen (Sperrungen, Umleitungen und, wenn möglich, deren Ursache) sowie den Echtzeitstatus, etwa prognostizierte Abfahrts- und Ankunftszeiten, Verspätungen und Ausfälle. Die Fristen:
| Daten | TEN-V-Gesamtnetz | Übrige Teile des Unionsnetzes |
|---|---|---|
| Dynamische Daten, Servicestufe 1 (Punkt 2.1: Störungen, Echtzeitstatus) | 1. Dezember 2025 | 1. Dezember 2028 |
| Dynamische Daten, Servicestufe 2 (Punkt 2.2) | 1. Dezember 2026 | 1. Dezember 2028 |
| Historische und beobachtete Daten (Punkt 1.4, einschließlich Verspätungen und Ausfällen) | 1. Dezember 2025, gesamtes Netz | 1. Dezember 2025, gesamtes Netz |
Auslastungsdaten (Punkt 2.3) sind optional und liegen im Ermessen jedes Mitgliedstaats.
Die praktische Folge: Bis zum 1. Dezember 2028 muss ein lokales Busnetz außerhalb des TEN-V-Gesamtnetzes Echtzeitprognosen, Verspätungen, Ausfälle und Störungen in einem Standardformat veröffentlichen können. Verspätungen und Ausfälle als beobachtete Daten sind bereits überall fällig. Für viele kleine und mittlere Netze werden Echtzeitdaten damit erstmals zur Pflicht statt zum Fahrgastservice. Derselbe Druck trifft auch die Netze in Osteuropa, deren Flotten mit EU-Mitteln erneuert werden.
Wie funktioniert es in der Praxis? Beispiele aus Westeuropa
- Deutschland: DELFI e.V., Connect-Fahrplanauskunft und Google haben im März 2026 einen Partnervertrag über deutschlandweite Nahverkehrs-Echtzeitdaten (DELFI-Realtime) geschlossen. Google Maps erhält damit einen zentralen, gebündelten Zugang zu qualitätsgesicherten Echtzeitinformationen, statt die Daten bei jedem Anbieter einzeln zu beziehen (GoogleWatchBlog, 31.03.2026).
- Spanien: Die EMT Madrid übermittelt Busstandorte und prognostizierte Ankunftszeiten für alle ihre Linien per GTFS-RT an Google Maps (eSmartCity, März 2025). Auf nationaler Ebene umfasste der spanische Zugangspunkt (nap.transportes.gob.es) im Dezember 2025 116 Datensätze, damals nur statisches GTFS; dynamische Daten werden ergänzt, um die EU-Verordnung zu erfüllen (datos.gob.es).
- Portugal: Carris Metropolitana, die Busmarke der TML für den Großraum Lissabon mit 18 Gemeinden, hat im Januar 2024 Echtzeit-Abfahrtszeiten für mehr als 1.700 Busse und rund 12.000 Haltestellen in Google Maps gebracht, in einem offenen öffentlichen Format, das auch Moovit und Citymapper nutzen (Pressemitteilung der TML).
- Frankreich: Der nationale Zugangspunkt bündelt GTFS-RT- und SIRI-Feeds von Netzen jeder Größe, mit 221 gelisteten GTFS-RT-Datensätzen.
- Belgien: De Lijn veröffentlicht auf transportdata.be einen minütlich aktualisierten GTFS-Realtime-Feed für Bus und Straßenbahn mit prognostizierten Zeiten, Fahrzeugdetails und Störungen sowie veröffentlichten Nutzungsgrenzen für die API.
- Niederlande: Echtzeit-Fahrzeugdaten der Verkehrsunternehmen werden über die nationalen NDOV-Zugangspunkte gebündelt und an Reiseplaner weitergegeben, ein Modell, das lange vor den EU-Fristen entstanden ist.
Wie wählt man ein System für Echtzeit-Flottenmanagement aus?
Nutzen Sie diese Kriterien statt Funktionslisten (den übergeordneten Ansatz beschreibt unser Leitfaden So wählen Sie das richtige RBL für Ihr Busunternehmen, die Funktionen im Detail unsere RBL-Checkliste 2026):
- Qualität der Fahrtzuordnung. Fragen Sie nach dem Anteil korrekt zugeordneter Fahrten in einem realen Netz und danach, wie nicht zugeordnete Fahrten behandelt werden.
- Standardexporte. GTFS-RT (Fahrtaktualisierungen, Fahrzeugpositionen, Meldungen) und SIRI, ohne kostenpflichtige Zusatzmodule je Feed, sowie GTFS- oder NeTEx-Import.
- Arbeitsabläufe der Leitstelle. Halten, Umleitungen, Ersatz und Ausfälle sollten wenige Klicks erfordern und automatisch in die Fahrgastinformation einfließen.
- Hardware-Flexibilität. Läuft das System auf dedizierten Geräten, auf Smartphones und Tablets oder auf beidem? Wird ITxPT unterstützt, wo Sie Integration brauchen?
- Datenhoheit und Datenzugang. API-Zugang zu Roh- und Historiendaten, mit Exporten in offenen Formaten.
- Passendes Reporting. Pünktlichkeitstoleranz, erbrachte Fahrten und Kilometer so berechnet, wie Ihr Vertrag sie definiert.
- Bereitstellungsmodell und Zeitrahmen. Cloud-SaaS oder lokale Installation, Anzahl der Wochen bis zum Livebetrieb und wer die Server betreibt.
- Transparente Preisgestaltung. Verstehen Sie, was die Kosten treibt: Fahrzeuge, Module, Hardware, Integration.
Pysae ist ein Beispiel für den Cloud-Ansatz: ein SaaS-RBL, Mobile-first entwickelt, das auf Smartphones und Tablets läuft und offene GTFS- und GTFS-RT-Exporte bietet (siehe Pysae Operations). Unabhängig vom Anbieter gilt: Führen Sie einen Pilotbetrieb auf ein oder zwei Linien durch, vergleichen Sie die Ist-Daten des RBL mit Ihren eigenen Aufzeichnungen und skalieren Sie erst dann.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einem RBL und Flottentelematik?
Flottentelematik verfolgt Fahrzeuge und Fahrer (Ortung, Kraftstoff, Diagnose, Fahrstil). Ein RBL verfolgt geplante Fahrten: Es ordnet jedes Fahrzeug seiner Fahrt zu, misst die Pünktlichkeit, unterstützt die Leitstelle und speist die Fahrgastinformation.
Brauchen kleine Busnetze nach EU-Recht Echtzeitdaten?
Ja, mit der Zeit. Nach der Delegierten Verordnung (EU) 2024/490 müssen dynamische Daten wie Verspätungen, Ausfälle und Störungen bis zum 1. Dezember 2028 für das gesamte Verkehrsnetz der Union über nationale Zugangspunkte verfügbar sein, im TEN-V-Gesamtnetz schon früher.
Können Smartphones Bordrechner für ein RBL ersetzen?
Für Ortung, Fahrtzuordnung, Fahrerkommunikation und Fahrgastinformation ja, und viele Netze nutzen sie bereits. Dedizierte Geräte bleiben sinnvoll, wenn der Bus Vertrieb, Zählsysteme, Anzeigen und Fahrzeugdaten in einem Bordnetz integrieren muss, idealerweise nach ITxPT-Spezifikationen.
Welche Echtzeitformate sollte ein Busunternehmen veröffentlichen?
GTFS-RT für Reiseplaner (Fahrtaktualisierungen, Fahrzeugpositionen, Störungsmeldungen) und SIRI für den Austausch mit Aufgabenträgern und nationalen Zugangspunkten. Wer beide veröffentlicht, deckt die meisten europäischen Anforderungen ab.
Quellen: Delegierte Verordnung (EU) 2024/490 der Kommission, EUR-Lex; transportdata.be, Informationen für Datenanbieter und GTFS-Realtime-Datensatz von De Lijn; transport.data.gouv.fr, Statistikseite (Oktober 2026); datos.gob.es, Podcast zu offenen Verkehrsdaten (11.12.2025); Transportes Metropolitanos de Lisboa, Pressemitteilung „Tempo real da Carris Metropolitana já chegou ao Google Maps“ (Januar 2024); eSmartCity, „La ubicación en tiempo real de los autobuses de EMT Madrid se puede consultar en Google Maps“ (20.03.2025); GoogleWatchBlog, „Google Maps: Zuverlässige ÖPNV-Echtzeitdaten für ganz Deutschland, neue DELFI-Kooperation läuft an“ (31.03.2026); ITxPT, itxpt.org; GOVI / NDOV-Zugangspunkt, govi.nu.