Disposition für On-Demand-Ridepooling und bedarfsgesteuerten Verkehr

Feste Buslinien sind im ländlichen Raum und nachts ineffizient, individuelle Taxis dagegen teuer. Beim On-Demand-Ridepooling (bedarfsgesteuerter Verkehr, DRT) buchen Fahrgäste eine Fahrt per App oder Telefon; eine Dispositionsmaschine bündelt zueinander passende Anfragen in gemeinsam genutzten Fahrzeugen, wählt virtuelle Haltestellen und aktualisiert Routen innerhalb von Sekunden. Der Optimierungskern ist klassisch (Heuristiken und Solver), zunehmend kombiniert mit ML-Nachfrageprognosen und gelernten Umverteilungsstrategien. Es ist ein starkes Thema für den öffentlichen Sektor in der EU, weil Kommunen und Verkehrsverbünde es finanzieren und regulieren.

Problem & Nutzen

• Heute: Der ÖPNV im ländlichen Raum und in Nebenverkehrszeiten fährt mit leeren Bussen nach festen Fahrplänen oder mit Rufbus-/Anruf-Sammeltaxi-Angeboten, die Stunden im Voraus gebucht und von Hand disponiert werden. Sonderverkehr (barrierefreie Beförderung) wird vielerorts manuell disponiert.
• KI-/Optimierungsnutzen: mehr Fahrgäste je Fahrzeugstunde durch Pooling bedienen, Wartezeit und Umweg innerhalb der Servicezusagen halten, Leerkilometer durch nachfrageorientierte Umverteilung verringern und Betreiber Änderungen an Bediengebiet, Flottengröße und Tarif in der Simulation testen lassen, bevor Mittel ausgegeben werden.
• Belege: Deutsche Forschung zum Ridepooling (z. B. die Begleitforschung von KIT/TUM zu MOIA in Hamburg, 2019–2021, und bundesgeförderte Evaluierungen) berichtet, dass Pooling-Effizienz und Auslastung stark von der Nachfragedichte abhängen; DRT ergänzt typischerweise den Linienverkehr, ersetzt ihn nicht. Betrachten Sie Herstellerkennzahlen als szenariospezifisch und verlangen Sie Evaluierungen vergleichbarer Gebiete [1][2].
• Rechtlicher Rahmen (DE): Die Reform des Personenbeförderungsgesetzes (PBefG) von 2021 schuf den „gebündelten Bedarfsverkehr“ (§50) als genehmigungsfähige Verkehrsform und erlaubt die Einbindung in Nahverkehrspläne und Tarife [3].

Varianten

• DRT im ländlichen Raum / ÖPNV-Zubringer: virtuelle Haltestellen, Bediengebiete und Zeitfenster, abgestimmt auf Bahnfahrpläne.
• Städtisches Ridepooling: dichte gemeinsame Fahrten, dynamische Preise innerhalb der Tarifregeln (siehe OPT-004).
• Sonderverkehr / barrierefreie Beförderung: Rollstuhlplätze, Begleitpersonen, strenge Regeln; oft abonnementbasiert.
• Autonome Shuttles: dieselbe Dispositionsschicht mit Fernüberwachung und Betrieb in abgegrenzten Zonen (Geofencing).
• Betriebs-/Campus-Shuttles und Krankentransport: geschlossene Nutzergruppen, geplante Vorbuchungen.
• Privatnutzung: nicht anwendbar; Endnutzer interagieren nur über Apps.

So funktioniert es

1. request (app / phone / voice bot)
2. geocoding + virtual-stop snapping + eligibility/fare check
3. insertion heuristic: feasible vehicle/route candidates under wait, detour, capacity, shift limits
4. assignment (batched matching every few seconds | greedy insertion)
5. quote & confirm
6. driver app routing, live ETA updates, no-show/late handling
7. rebalancing of idle vehicles using demand forecast
8. offline: simulation, fleet sizing, service-area tuning, reporting

• Dispositionskern: löst ein dynamisches Dial-a-Ride-Problem. Produktivsysteme nutzen Einfügeheuristiken plus lokale Suche oder gebündelte Zuordnung; exakte MIP-Solver kommen vor allem für die Offline-Planung und für Vergleichsmessungen zum Einsatz. Das Latenzziel liegt bei Sekunden je Anfrage.
• Prognose: Gradient Boosting oder tiefe Zeitreihen-/Raummodelle sagen die Nachfrage je Zone und Zeitfenster voraus (Veranstaltungen, Wetter, Schulzeiten), um Umverteilung und Schichtplanung zu steuern (PRED-019).
• Lernbasierte Strategien: Reinforcement Learning für Umverteilung und Preisgestaltung ist ein aktives Forschungsfeld mit einigen Piloten; die meisten Produktivmaschinen verlassen sich weiterhin auf abgestimmte Heuristiken, weil diese vorhersehbar und prüfbar sind.
• Rolle des LLM: Buchung im Dialog per Chat/Sprache, mehrsprachige Fahrgastunterstützung und Copilots für Betreiber, die Veränderungen der Kennzahlen erklären; LLMs treffen die Dispositionsentscheidung nicht.
• Mensch-in-der-Schleife (Human-in-the-Loop): Mitarbeitende der Leitstelle bearbeiten Ausnahmen (Pannen, besondere Bedürfnisse, Störungen), geben Änderungen an Bediengebiet/Tarif frei und übernehmen die manuelle Disposition.

Datenaufbereitung

Benötigte Daten: Nachfragehistorie (Buchungen, Anfragen), Fahrzeug- und Schichtdaten, Straßennetz und Reisezeiten, Haltestellenstandorte und virtuelle Haltestellen, Bedarfe an Barrierefreiheit und Tarifregeln. In einem Verkehrsunternehmen oder einer Kommune liegen diese in Buchungs- und Dispositionssystemen, im Flottenmanagement- oder Telematikwerkzeug, in der Schichtplanung in Excel, im ERP und, für die Historie des Linienverkehrs, in Fahrplandateien (GTFS) und Fahrerprotokollen auf Papier.

Typische Lücken: keine Historie vor dem Start (Kaltstart), Buchungsdaten mit persönlichen Kennungen, uneinheitliche Haltestellennamen, Schichtpläne als Tabellen, veraltete Straßennetze und fehlende Daten zu Nichterscheinen und Stornierungen.

Aufbereitungsschritte: eine Nachfrageschätzung aus Ticketing-, Schüler- und Pendlerdaten oder aus einem Pilot ableiten; eine saubere Haltestellen- und Zonentabelle aufbauen; OpenStreetMap- und GTFS-Daten laden und Reisezeiten gegen reale GPS-Spuren validieren; Schichtpläne strukturieren; Buchungsdaten vor der Analyse pseudonymisieren. Da GPS- und Buchungsdaten Fahrgäste und Fahrer betreffen, legen Sie Speicherfristen früh fest.

Rechnen Sie mit einem mittleren Anteil am Aufwand, etwa 20-30 Prozent. Siehe PREP-005 für Exporte aus Buchungssystemen, PREP-011 für Schichttabellen, PREP-022 für Pseudonymisierung, DATA-003 und GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• public (A): Kommunen und Verkehrsverbünde brauchen schnell einen funktionierenden Dienst; ausgereifte, in der EU gehostete Plattformen (z. B. ioki, Via) bringen Disposition, Buchungs-App, Know-how zur Personenbeförderungsgenehmigung und Betriebsunterstützung als Dienst mit.
• enterprise (B): Betreiber mit vorhandenen Flotten-, Ticketing- und Telematiksystemen benötigen meist eine in die eigene Landschaft integrierte Disposition mit Routing- und VRP-Solvern plus Cloud-APIs.
• developer (C): Offene Solver wie VROOM, OR-Tools und OSRM laufen auf bescheidener Hardware und geben volle Kontrolle über die Pooling-Logik, bei datensouveränem Aufbau.

Weg A — Kaufen (Standardsoftware) (empfohlen für Betreiber und Kommunen)

• Spezialisierte DRT-Plattformen: ioki (DE; Verkauf durch die Deutsche Bahn an die Benteler-Gruppe im Januar 2026 angekündigt), MOIA (Volkswagen, DE), door2door (DE), Padam Mobility (FR), Spare (CA, in Europa weit verbreitet), Via (USA, viele EU- Verträge), Liftango (AU). Typischer Umfang: Routing-Engine, Fahrgast- und Fahrer-Apps, Backoffice, APIs zu Ticketing und Clearing.
• Prüfen: EU-Hosting und DSGVO-Auftragsverarbeitungsvertrag, Einbindung von PBefG/regionalen Tarifen (z. B. Umgang mit dem Deutschlandticket), Barrierefreiheit, offene Schnittstellen (GTFS-Flex, NeTEx, VDV 463/ OJP), Dateneigentum beim Ausstieg und Evaluierungsreferenzen aus vergleichbaren Gebieten.
• Wählen Sie A, wenn: Sie ein Aufgabenträger oder Betreiber ohne eigenes Routing-Team sind.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Routing/ETA: Google Maps Platform Routes API, HERE, TomTom oder Mapbox-Matrix-APIs; für Datenhaltung in der EU siehe auch die offenen Optionen unten.
• Optimierung: Google OR-Tools (Routing-Bibliothek), Gurobi/CP-SAT für Planungsmodelle oder kommerzielle Routenmaschinen wie Hexaly oder PTV (DE) für Touren; Einfügelogik in Echtzeit erfordert meist eigenen Code.
• LLM-Schicht: ein Spitzenmodell oder EU-Modell (Mistral, Claude, GPT, Gemini in EU-Regionen) für Buchungsdialog und Betreiber-Copilot mit Funktionsaufrufen in die Buchungs-API.
• Wählen Sie B, wenn: Sie eigene Betriebsregeln benötigen oder in eine bestehende MaaS-App integrieren möchten.

Weg C — Selbst betreiben (Open Source)

• Routing: OSRM, Valhalla oder GraphHopper auf OpenStreetMap-Daten; OpenTripPlanner für multimodale Reiseplanung mit GTFS-Flex.
• Solver: Google OR-Tools, VROOM (Tourenplanung), PyVRP (HGS-basiert), OptaPlanner/Timefold (Java).
• Simulation: MATSim mit seinem DRT-Modul und SUMO für Szenariostudien; Forschungscode für Pooling-Strategien.
• Prognose: LightGBM, Prophet oder Zeitreihen-Foundation-Modelle (Chronos, TimesFM).
• Hardware: HW1 genügt (CPU-Server); GPU nur für die LLM-Sprach-/Chat-Schicht (HW2) oder RL-Training.

Weg D — Eigenes Training

Lohnt sich für große Betreiber mit mehreren Monaten Buchungsprotokollen: Nachfragemodelle auf Zonenebene und RL-basierte Strategien für Umverteilung/Preisgestaltung trainieren, stets in einem Simulator validiert, der echte Anfragen nachspielt, bevor Live-A/B-Tests laufen. Erfordert Anfrageprotokolle, Fahrtspuren und Fahrzeugzustände; mindestens einige Monate Daten, idealerweise über mehrere Jahreszeiten.

Stand der Technik (2026)

• Disposition: Gebündelte Zuordnung mit Einfügeheuristiken bleibt das Arbeitspferd im Produktivbetrieb; gelernte Wertfunktionen und Graph-Neuronale-Netze verbessern die Zuordnung in der Forschung und in einigen Anbieter-Piloten, doch belastbare Gewinne gegenüber abgestimmten Heuristiken hängen vom Kontext ab.
• Zuerst simulieren: Agentenbasierte Simulatoren (MATSim, SUMO) sind Standard für die Flottengröße und Entscheidungen zur Angebotsgestaltung vor dem Start.
• Interoperabilität: GTFS-Flex sowie NeTEx-/VDV-Standards bringen DRT in Reiseplaner und Ticketing, sodass Bedarfsfahrten neben festen Linien erscheinen.
• Autonomer Betrieb: Piloten mit fahrerlosen Shuttles in Europa (z. B. KIRA, ALIKE und ähnliche bundesgeförderte Projekte) halten einen Fernbediener in der Schleife; der Maßstab bleibt begrenzt.
• Grenzen: Die Pooling-Effizienz bricht bei geringer Nachfragedichte ein; Prognosefehler rund um Veranstaltungen; Fairnessprobleme (unterversorgte Gebiete oder Fahrgäste mit Behinderungen werden häufiger abgelehnt); die Kosten je Fahrgast bleiben oft über denen fester Linien, der Nutzen liegt also in der Barrierefreiheit, nicht in Einsparungen.

Gemeinsame Bausteine & Kombinationen

• Gleiche Technik (Optimierungs-Solver + Zeitreihen): OPT-001 Tourenplanung, OPT-019 Außendienst-Disposition, OPT-005 Nachschubplanung teilen Solver- und Routing-Infrastruktur.
• Vorgelagert: PRED-019 Prognose von Verkehrs- und Mobilitätsnachfrage, OPT-013 Fahrplanung für die Einbindung in feste Linien.
• Nachgelagert/angrenzend: OPT-021 Laden von E-Flotten (elektrische DRT-Flotten), OPT-020 Störungsbewältigung, OPT-025 Lichtsignalsteuerung (Busbevorrechtigung).
• Routing-Engines und OSM-Auszüge lassen sich über alle Mobilitäts-Anwendungsfälle hinweg teilen.

Aufwand, Kosten & Kennzahlen

• Weg A: 3–6 Monate von der Ausschreibung bis zum Start, einschließlich Lizenzen, Fahrzeugverträgen und Integration; die Kosten fallen typischerweise je Fahrzeugstunde oder je Fahrt plus Betreiberkosten an. Fahrzeug- und Fahrerbetrieb, nicht die Software, bestimmt das Budget.
• Weg B: 6–12 Monate für ein MVP mit eigenem Team.
• Weg C/D: 12+ Monate, spezialisiertes OR-/ML-Team erforderlich.
• Kennzahlen: Fahrgäste je Fahrzeugstunde, Poolingquote, mittlere Wartezeit und mittlerer Umweg, Ablehnungsquote, Anteil der Leerkilometer, Kosten je Fahrgast, Anteil bedienter Gruppen mit Bedarf an Barrierefreiheit, CO2 je Personenkilometer, Anteil der Zubringerfahrten zu Bahnhöfen.

Menschen & Veränderung

Die Leitung und die politischen oder verbandlichen Träger legen die Serviceziele und das Budget fest. Die Betriebsleitung verantwortet die Dispositionsregeln; Fahrer und Disponenten der Leitstelle sind die Anwender und müssen früh eingebunden werden, da das System ihre Routen und Pausen zuweist. Die IT verantwortet Telematik und Schnittstellen. Kunden (Fahrgäste) müssen in der App über die Datennutzung informiert werden, und bei barrierefreien Angeboten sind Vertretungen der Nutzenden einzubeziehen.

Betriebsrat: in den meisten Fällen ja. GPS-Ortung der Fahrer sowie Schicht- und Leistungsdaten machen das System objektiv zur Verhaltensüberwachung geeignet, daher greift die Mitbestimmung nach §87 Abs. 1 Nr. 6 BetrVG; eine Betriebsvereinbarung zu Datennutzung, Speicherfristen und zum Verzicht auf individuelle Leistungsbewertung ist ratsam. Informieren Sie den Betriebsrat rechtzeitig (§90 BetrVG) und ziehen Sie einen KI-Sachverständigen hinzu (§80 Abs. 3). Öffentliche Betreiber beziehen den Personalrat ein.

Datenschutz: Bewegungsdaten von Fahrgästen sind personenbezogen und in der Summe sensibel; beziehen Sie die Datenschutzbeauftragte bzw. den Datenschutzbeauftragten früh ein, schließen Sie mit dem Plattformanbieter einen AVV und führen Sie eine DSFA durch. Führen Sie einen Pilot in einer Zone oder einem Zeitfenster durch, in dem Disponenten Zuordnungen übersteuern können. Typische Bedenken sind Arbeitsplatzverlust und Überwachung; begegnen Sie ihnen mit transparenten Regeln, begrenztem Datenzugriff und Rückkopplungsschleifen mit den Fahrern. Bieten Sie Disponenten und Fahrern Unterstützung bei der KI-Kompetenz. Siehe GUIDE-004, GUIDE-005 und GUIDE-008.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Minimalrisiko für die Dispositionsoptimierung; kein System nach Anhang III. Sicherheitsbauteile des Straßenverkehrsmanagements in Anhang III betreffen die Steuerung kritischer Infrastruktur, nicht die Fahrgastbuchung. Werden vollautonome Fahrzeuge eingesetzt, gelten die Vorschriften zur Fahrzeugtypgenehmigung gesondert. Fahrgast-Chatbots benötigen die Offenlegung nach Art. 50; die KI-Kompetenz (Art. 4) gilt für das Personal [4].
• DSGVO: Standortdaten von Fahrten sind personenbezogen und aufschlussreich (Wohnort, Arbeitsplatz, Gesundheitseinrichtungen, Religion). Datenminimierung, kurze Speicherfristen, pseudonymisierte Analysen, aggregierte offene Daten für die Planung; für Bedarfe an Barrierefreiheit sind besondere Kategorien möglich (Art. 9), daher ausdrückliche Einwilligung und eingeschränkter Zugriff. Für die systematische Verarbeitung von Standortdaten ist eine DSFA ratsam [5].
• Verkehrsrecht: PBefG-Genehmigungen, Tarif- und Fördervorschriften, Arbeitszeitregeln für Fahrer.
• Fairness und Bedienpflicht: algorithmisches Redlining von nachfrageschwachen Gebieten vermeiden; Mindest- Servicezusagen festlegen und Ablehnungsquoten je Zone prüfen.
• Betriebliche Risiken: Ausfall der Maschine (Rückfall auf manuelle Disposition), Akzeptanz bei den Fahrern, Anbieterbindung.

Erste Schritte

1. Ziele (Barrierefreiheit, Zubringer, Kosten) und das Bediengebiet festlegen; Nachfrage mit vorhandenem Ticketing, Mobilfunkdaten oder Befragungen prüfen.
2. Den Dienst in MATSim/SUMO mit synthetischer Nachfrage simulieren, um Flotte und virtuelle Haltestellen zu dimensionieren.
3. 2–3 Anbieter aus Weg A in die engere Wahl nehmen; Evaluierungen aus vergleichbaren Regionen und den Nachweis offener Schnittstellen anfordern.
4. Einen zeitlich begrenzten Pilot mit klaren Kennzahlen und einer DSFA durchführen; eine manuelle Disposition als Rückfallebene behalten.
5. Nach über 3 Monaten Buchungsdaten Nachfrageprognose und Umverteilung ergänzen.

Quellen

1. BMDV / German federal mobility research on on-demand ridepooling (mFUND, Modellvorhaben) — https://www.bmv.de/DE/Themen/Mobilitaet/mobilitaet.html
2. ioki — on-demand mobility platform — https://ioki.com
3. Personenbeförderungsgesetz (PBefG) — https://www.gesetze-im-internet.de/pbefg/
4. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
5. Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
6. Google OR-Tools — https://developers.google.com/optimization
7. VROOM project — https://github.com/VROOM-Project/vroom
8. MATSim DRT contrib — https://matsim.org
9. GTFS-Flex specification — https://gtfs.org/extensions/flex/
10. MOIA — Forschung (accompanying research on ridepooling with KIT/TUM) — https://www.moia.io/de-DE/forschung