Ja, ein RBL (rechnergestütztes Betriebsleitsystem, international ITCS) lässt sich mit nahezu jeder Bordhardware verbinden, aber nur, wenn die Ausschreibung das ausdrücklich verlangt. In der Praxis bedeutet „hardwareunabhängig" eine Software, die auf Standardgeräten läuft und über offene, dokumentierte Schnittstellen mit der vorhandenen Bordtechnik kommuniziert, statt im Paket mit der proprietären Box eines einzigen Herstellers zu kommen. Fünf Klauseln in den Vergabeunterlagen leisten den Großteil der Arbeit: Ergebnisse spezifizieren, offene Schnittstellen verlangen, Hardware entkoppeln, Dateneigentum und Ausstieg sichern und die Versprechen vor der Vergabe testen.
Der Grund dafür ist struktureller Natur. Im Fachmagazin Mass Transit argumentierte Gabriel Lopez-Bernal im Februar 2026, dass viele Softwareanbieter im öffentlichen Verkehr Software nicht allein verkaufen können und Hardware mitliefern müssen, um die benötigten Daten zu erfassen, weil der Branche offene, standardisierte Hardwareplattformen fehlen. Der Autor vertritt einen Anbieter von Konnektivitätslösungen, der Beitrag ist also als Branchenmeinung zu lesen. Der beschriebene Mechanismus ist jedoch jedem Käufer vertraut, der schon einmal versucht hat, ein Pilotprojekt zu skalieren.
Warum enden RBL-Ausschreibungen bei der Hardware eines einzigen Herstellers?
Herstellerbindung entsteht selten durch eine einzige schlechte Klausel. Sie wächst aus mehreren Gewohnheiten.
- Produktgeförmte Leistungsbeschreibungen. Die Ausschreibung beschreibt exakt das Gerät des bisherigen Anbieters, fügt „oder gleichwertig" hinzu und geht davon aus, dass der Wettbewerb damit gewahrt ist. Das EU-Vergaberecht legt die Latte höher: Nach Artikel 42 Absatz 4 der Richtlinie 2014/24/EU (und Artikel 60 Absatz 4 der Sektorenrichtlinie 2014/25/EU, unter die viele Verkehrsunternehmen fallen) dürfen technische Spezifikationen nicht auf eine bestimmte Marke, Herkunft, ein Patent oder einen Typ verweisen, es sei denn, dies ist durch den Auftragsgegenstand gerechtfertigt, und nur ausnahmsweise, wenn keine hinreichend genaue Beschreibung möglich ist, mit dem Zusatz „oder gleichwertig". In der Praxis richtet ein Markenname mit „oder gleichwertig" die Angebote trotzdem auf ein Produkt aus.
- Gekoppelte Lieferung. Die Software wird nur zusammen mit Routern, Bordrechnern oder anderen Geräten angeboten. Wer die Software wechseln will, muss die Hardware wechseln.
- Pilotprojekte ohne Ende. Die Erprobung eines marktreifen Produkts ist eine Bewertung, keine Innovation, und Verkehrsunternehmen mit langen Pilotphasen schaffen die Skalierung oft nicht.
- Geschlossene Daten. Die an Bord erfassten Daten sind nur über die Werkzeuge des Herstellers zugänglich.
Welche 5 Klauseln gehören in eine hardwareunabhängige RBL-Ausschreibung?
1. Ergebnisse und Daten spezifizieren, nicht Produkte
Beschreiben Sie, was das System messen muss und in welcher Qualität, statt vorzugeben, welches Gerät messen soll. Zum Beispiel: Intervall der Positionsmeldung, Anteil der korrekt einem Fahrzeug zugeordneten Fahrten, Genauigkeit der Erkennung von Ankunft und Abfahrt an Haltestellen, Verfügbarkeit des Dienstes. Es sind dieselben Qualitätsfaktoren, die darüber entscheiden, ob man Planungswerkzeugen trauen kann: Lange Intervalle bei der Positionsmeldung verschlechtern die Erkennung von Ankunft und Abfahrt, und niedrige Anmeldequoten des Fahrpersonals lassen viele Fahrten ohne Fahrzeugzuordnung. Warum diese Datenqualität die Grundlage für alles Weitere ist, zeigt unser Artikel darüber, wie KI die Busnetzplanung verändert. Genau diese Ist-Daten liefert das Modul für die Betriebslenkung in Echtzeit, Operations.
2. Offene, dokumentierte Schnittstellen verlangen
Fordern Sie eine öffentliche API-Dokumentation, eine Testumgebung und Standardausgaben: GTFS und GTFS-RT für Fahrpläne und Echtzeitdaten, SIRI und NeTEx, wo das Netz oder das Land sie vorschreibt (siehe welcher Echtzeitdaten-Standard in welchem Land gilt). Verlangen Sie die Liste der Schnittstellen, die bereits im Produktivbetrieb laufen, etwa zu Anzeigen der Fahrgastinformation, Fahrgastzählung oder Planungssoftware, statt Schnittstellen, die nur möglich wären. Pysae hat zum Beispiel veröffentlichte Integrationen mit Hastus oder ABC Planning, mit der Fahrgastzähllösung Iris und mit der Fahrgastinformation von Hanover Displays über eine IP-Verbindung.
3. Hardware und Software entkoppeln
Lassen Sie Standardgeräte wie Smartphones oder Tablets als zulässige Bordlösung zu und schreiben Sie eine Mindestspezifikation für Geräte statt eines Modells. Wenn das Fahrzeug bereits einen Bordrechner hat, lassen Sie den Bieter darlegen, wie sich die Software damit verbindet. In Europa veröffentlicht der Verband ITxPT, dessen Ziel die Interoperabilität zwischen IT-Systemen im öffentlichen Verkehr ist, Spezifikationen für Hardwareschnittstellen, Kommunikationsprotokolle und Dienste an Bord und zertifiziert konforme Fahrzeuge, Software und Geräte mit einem Label. Laut dem Mass-Transit-Beitrag bestellen Helsinki, Paris, Stockholm und Dubai Busse mit ITxPT-zertifizierten Bordrechnern, damit sie Software ohne Herstellerbindung auswählen können. Ruter in Oslo hat sich zu einer offenen, auf ITxPT basierenden Bordarchitektur entwickelt. Für die Hardwareseite siehe das Modul für Bordtelematik, Fleet.
4. Dateneigentum, Export und Ausstieg sichern
Legen Sie im Vertrag fest, dass die Ist-Daten (Positionen, gefahrene Fahrten, Pünktlichkeit, Kilometer) dem Aufgabenträger oder dem Verkehrsunternehmen gehören. Verlangen Sie jederzeit einen Massenexport in einem dokumentierten Format, einen Ausstiegsplan mit Übergangsunterstützung und Klarheit darüber, ob der Export Kosten verursacht. Ein System, dessen Daten sich nicht extrahieren lassen, lässt sich nicht ersetzen. Ein Anbieterwechsel wird dann so teuer, dass er keine glaubwürdige Verhandlungsposition mehr ist.
5. Lebenszykluskosten, ergebnisbasierte Abnahme und einen Test vor der Vergabe verlangen
Fordern Sie von den Bietern die Gesamtkosten über die Vertragslaufzeit, wobei Abonnementleistungen als Betriebskosten behandelt werden, damit sich die Angebote vergleichen lassen: Ein niedrigerer Anschaffungspreis kann zur teureren Option werden, sobald Hardwareersatz, Wartung und Aktualisierungen über zehn Jahre hinzukommen. Stützen Sie die Abnahme auf messbare Ergebnisse wie in Klausel 1. Und führen Sie vor der Vergabe eine kurze Demonstration mit einer gemischten Auswahl Ihrer eigenen Fahrzeuge durch: Verbindung zu einem vorhandenen Gerät herstellen, die API aufrufen, die Daten eines Tages exportieren. Die Empfehlung des Beitrags, marktbewährte Produkte in Demonstrationen statt in Pilotprojekten zu prüfen, folgt derselben Logik.
Wie lässt sich ein „hardwareunabhängig"-Versprechen vor der Unterschrift prüfen?
Vier schnelle Tests trennen echte Offenheit von Marketing.
- Demo mit gemischter Flotte: Lassen Sie die Software auf zwei oder drei unterschiedlichen Fahrzeugtypen und Bordkonfigurationen aus Ihrem eigenen Netz laufen.
- API-Test: Verlangen Sie Zugang zu einer Sandbox und rufen Sie die dokumentierten Endpunkte selbst auf.
- Export-Test: Fordern Sie einen vollständigen Export der Fahrten eines Tages in einem dokumentierten Format an.
- Referenzprüfung: Sprechen Sie mit einem Kunden, der von einem anderen System migriert ist, nicht nur mit einem, der bei null angefangen hat.
Für den gesamten Auswahlprozess siehe unseren Leitfaden, wie Busunternehmen ein RBL auswählen, und unsere RBL-Checkliste 2026.
Pysae ist eine SaaS-Plattform für die Betriebsleitung, die auf Standardgeräten läuft und Standardformate ausgibt. Die Abrechnung erfolgt pro Fahrzeug und wird an jedes Netz angepasst. Wenn Sie Ihre Ausschreibung mit uns durchgehen möchten, nehmen Sie Kontakt auf.
Häufig gestellte Fragen
Was bedeutet hardwareunabhängig bei einem RBL?
Die Software hängt nicht vom proprietären Bordgerät eines einzigen Herstellers ab. Sie läuft auf Standardgeräten wie Smartphones oder Tablets und verbindet sich über offene, dokumentierte Schnittstellen mit der vorhandenen Bordtechnik.
Welche Standards sollte eine Ausschreibung nennen?
GTFS und GTFS-RT für Fahrpläne und Echtzeitdaten, SIRI und NeTEx, wo das Netz oder das Land sie vorschreibt, und ITxPT für die Interoperabilität an Bord in Europa. Die richtige Kombination hängt von Ihrem Netz und den nationalen Vorgaben ab.
Wie vermeide ich die „oder gleichwertig"-Falle?
Formulieren Sie Anforderungen als Ergebnisse und Schnittstellen statt als Produktnamen, wie es die EU-Vergaberichtlinien außer in begründeten Fällen ohnehin verlangen. Legen Sie messbare Schwellenwerte für die Datenqualität fest, spezifizieren Sie offene Schnittstellen und verlangen Sie vor der Vergabe einen Test mit Ihren eigenen Fahrzeugen.
Quellen: Gabriel J. Lopez-Bernal, „The Hardware Trap: Why Transit Can't Buy Tomorrow's Software", Mass Transit (17. Februar 2026); Richtlinie 2014/24/EU, Artikel 42, und Richtlinie 2014/25/EU, Artikel 60 (EUR-Lex); ITxPT, „What is ITxPT?", FAQ und „A Common Vision for a Cost-effective and Sustainable IT Architecture" (itxpt.org); HERE, „What Oslo's buses can teach us about data collection" (Ruter); ITxPT-Spezifikationen (itxpt.org).