Durch die steigende Aufmerksamkeit für „Mobility on Demand“ (MoD) in Form von Ridepooling- oder Ridehailing-Diensten werden diese auch für die Integration in Verkehrsplanungsmodelle relevant. Dieser Beitrag stellt die Integration von MoD-Angeboten in das mikroskopische  Verkehrsnachfragemodell mobiTopp dar. Durch die individuelle Abbildung von Personen werden diese in persönliche Entscheidungsmodelle, vor allem in die Verkehrsmittelwahl, integriert. Durch eine gleichzeitige mikroskopische Modellierung der MoD‑Fahrzeuge können Effekte unterschiedlicher Flottengrößen und Betreibermodelle ermittelt werden. Mit drei beispielhaften Szenarien in der Stadt Stuttgart werden die Analysemöglichkeiten des neuen mobiTopp-Moduls dargestellt und abschließend weitere Optimierungen des Modellierungsansatzes diskutiert.

Der Beitrag ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.

1 Einleitung

Die Bekanntheit moderner Angebote im Bereich Mobility on Demand (MoD) wie Ridepooling und Ridehailing hat in den letzten Jahren stark zugenommen. Getrieben durch die technologische Entwicklung und neue Marktakteure erhalten diese Lösungen aktuell viel Aufmerksamkeit und sind insbesondere in den Diskussionen aktueller und zukünftiger Mobilitätslösungen in urbanen Räumen ein häufig genanntes Thema. Besonders in den USA sind MoD-Dienste mit Unternehmen wie Uber und Lyft bereits im Massenmarkt angekommen. In Deutschland ist die Entwicklung aktuell in den Anfängen mit verfügbaren Diensten in bisher nur wenigen Städten.

Die Bezeichnung von MoD-Diensten ist bisher nicht einheitlich. Im Folgenden möchten wir uns an die Definitionen von Mehlert [1] anlehnen, wonach MoD ein Oberbegriff für Ridesharing und Rideselling ist. Während unter Ridesharing dabei nicht-kommerzielle Fahrten (hauptsächlich Mitfahrgelegenheiten) verstanden werden, werden unter Rideselling kommerzielle Angebote in Form von Ridepooling und Ridehailing zusammengefasst. Bei Ridepooling findet eine Bündelung unterschiedlicher Fahrtwünsche in einem Fahrzeug statt. Bei Ridehailing steht der Person das Fahrzeug exklusiv zur Verfügung. Als Beispiele für Ridepooling gelten im deutschen Kontext MOIA, Berlkönig und CleverShuttle. Ridehailing-Dienste sind in Deutschland, abgesehen von klassischen Taxi-Diensten, derzeit nicht zulässig.

Bei anderen Autoren und bei einigen verfügbaren Angeboten wird besonders der Begriff Ridesharing auch für das hier als Ridepooling bezeichnete Angebot verwendet. Als weiterer Begriff existiert „Demand Responsive Transportation“ (DRT), welches für MoD (nach [2]) oder Ridepooling (nach [3]) stehen kann. „Mobility as a Service“ wird entsprechend Jittrapirom et al. [4] dem gegenüber als separater Begriff verstanden, bei dem das Ziel ist, verschiedene Verkehrsmodi in einer Plattform zu integrieren und für die Nutzer über ein gemeinsames Interface anzubieten.

Als Ridepooling und Ridehailing werden demnach Dienste bezeichnet, bei denen einzelne Fahrten verkauft werden. Fahrzeuge können also genutzt werden ohne diese selbst zu besitzen. Die Dienste positionieren sich dabei vor allem als Alternative zum klassischen Pkw, dem traditionellen öffentlichen Verkehr (ÖV) und Taxis. Sie grenzen sich in der Regel wie folgt ab:

• Die Fahrzeuge sind im Besitz des Anbieters der Dienstleistung. Damit grenzen sich die Dienste zu Mitfahrzentralen ab, bei denen Privatfahrzeuge für die Mitfahrt vermittelt werden.

• Die Platzkapazität der Fahrzeuge ist in der Regel gleich der eines regulären Pkws. In einigen Fällen werden auch Kleinbusse mit bis zu 12 Personen eingesetzt.

• Im Unterschied zum ÖV verkehren die Fahrzeuge nicht auf einer festen Route, sondern fahren in einem festgelegten Bediengebiet. Die Fahrzeugrouten werden individuell und dynamisch auf Basis der aktuellen Nachfrage ermittelt.

• Fahrtdauern und genaue Routen stehen im Fall von Ridepooling zu Fahrtbeginn meist nicht fest, da durch die dynamische Routensteuerungen eine Umplanung zur Aufnahme neuer Passagiere erfolgen kann.

• Es existieren keine klassischen, erkennbaren Haltestellen. Vielmehr funktionieren die Dienste mit einem engmaschigen Netz virtueller Haltestellen (bspw. jede Straßenkreuzung) innerhalb des Bediengebiets.

• Die Buchung einer Fahrt erfolgt häufig ausschließlich über Smartphone-Apps.

• Die Bepreisung erfolgt oft auf Basis der Nachfrage, das heißt es gibt routen- und zeitabhängige Preisunterschiede. Preislich liegen diese Dienste in der Regel zwischen dem Preis für den ÖV und einer Taxifahrt.

Mit der steigenden Popularität von MoD-Diensten werden diese auch für Akteure der Verkehrsplanung zunehmend relevant. Eine Integration dieser Dienste in die Verkehrsnachfragemodellierung kann helfen, zukünftige Mobilitätslösungen zu dimensionieren und deren Wirkungen ex-ante zu ermitteln. Ridepooling und Ridehailing unterscheiden sich in der Verkehrsmodellierung sowohl vom klassischen Pkw als auch vom öffentlichen Verkehr. Durch den individuell auf spezifische Situationen angepassten Angebotscharakter der Services eignen sich insbesondere Verkehrsplanungsmodelle auf mikroskopischer, agentenbasierter Basis zu deren Abbildung. Diese modellieren Personen mit ihren Haushaltskontexten sowie Fahrzeuge als separate Objekte und grenzen sich damit von konventionellen, makroskopischen Verkehrsnachfrage¬modellen ab. In diesem Beitrag stellen wir die Integration von MoD Diensten in Form von Ridepooling und Ridehailing in das mikroskopische Verkehrsnachfragemodell mobiTopp vor. mobiTopp ist ein Modell basierend auf dem Ansatz der Multi-Agenten-Simulation. Für die Integration der Services wurden neue Algorithmen entwickelt bzw. implementiert, die deren Abbildung ermöglichen. Fahr- und Wartezeiten der Fahrzeuge werden individuell berechnet und die jeweiligen Werte stehen Personen für die Verkehrsmittel¬wahlentscheidungen in der Simulation zur Verfügung. Entscheidungen eines Agenten beeinflussen dabei die von anderen Agenten, indem die Fahrzeugverfügbarkeit der Dienste beeinflusst wird und bspw. andere Wartezeiten oder Umwege entstehen. Das parallele Handling der Fahrzeugflotten wird in mobiTopp in einem neu entwickelten Modul abgewickelt. Im Folgenden werden zunächst theoretische Ansätze zur Integration von MoD-Diensten sowie in anderen Nachfragemodellen verwendeten Ansätze aufgezeigt. Anschließend erfolgt die Beschreibung des für mobiTopp entwickelten Ansatzes mit seinen Vorteilen für die Simulation sowie dessen Limitierungen. Wir fokussieren uns dabei auf die Darstellung von Ridepooling, erwähnen dabei aber auch die Unterschiede zur Abbildung von Ridehailing. Zur Darstellung der technischen Möglichkeiten und der damit verbundenen Analysemöglichkeiten für Verkehrsplanungszwecke wie auch Betreiber von MoD Services werden beispielhafte Szenarien für den Betrieb von Ridepooling Fahrzeugflotten im Bediengebiet der Stadt Stuttgart mit unterschiedlichen Flottengrößen berechnet. Abschließend werden in dem Beitrag weitere Forschungsaktivitäten und geplante Erweiterungen des Ansatzes thematisiert und diskutiert.

2 mobiTopp

mobiTopp ist ein agentenbasiertes mikroskopisches Verkehrsnachfragemodell, das jede Person, jeden Haushalt und jedes Auto des Planungsraums modelliert. Personen sind als selbstständig agierende Agenten repräsentiert, welche Entscheidungen individuell und situationsabhängig basierend auf den aktuellen Gegebenheiten und ihrer Soziodemographie treffen. [5] [6] mobiTopp besteht aus zwei Phasen, einer Initialisierung (Langfristmodell) und einer Simulation (Kurzfristmodell). In der Initialisierung werden langfristige Entscheidungen und Eigenschaften des Agenten modelliert. Diese beinhaltet die Generierung einer synthetischen Bevölkerung basierend auf Strukturdaten der Verkehrszellen des Planungsraums. Die erzeugte Bevölkerung beinhaltet alle Haushalte, Agenten und Autos mit verschiedenen Eigenschaften, wie dem Wohnort. Anschließend werden Ziele für die Aktivitäten Arbeit und Ausbildung definiert. Diese Ziele ändern sich während der Simulationszeit nicht und werden als feste Ziele bezeichnet. Weiterhin wird der Zeitkartenbesitz auf Personenebene und der Autobesitz auf Haushaltsebene modelliert. Als letzter Schritt wird den Agenten ein Aktivitätsprogramm für die Simulation der Ziele und Verkehrsmittel zugewiesen. Die Wahl des Aktivitätsprogramms ist auf zwei Arten möglich. Es können einerseits vordefinierte Aktivitätsprogramme einer Haushaltsbefragung verwendet werden oder mithilfe von actiTopp synthetische Aktivitätsprogramme erzeugt werden. In actiTopp werden in einem mehrstufigen Verfahren, basierend auf logistischen Regressionsmodellen, Aktivitätenpläne für einzelne Agenten erzeugt [7]. In der Simulation wird die Verkehrsnachfrage unter Berücksichtigung des Langfristmodells modelliert. Dazu werden alle Agenten zeitlich synchronisiert über eine Woche simuliert. Die Simulation kann sowohl wegebasiert wie auch tourbasiert durchgeführt werden [8]. Für jeden Weg eines Agenten wird zunächst das Ziel und anschließend das Verkehrsmittel gewählt. Für die Zielwahl wird zwischen festen Zielen aus dem Langfristmodell und flexiblen Zielen unterschieden. Aktivitäten, die während der Simulation an verschiedenen Orten stattfinden können, werden als flexible Ziele modelliert. Standardmäßig wird dazu ein Discrete Choice-Modell eingesetzt. Die Wahlentscheidungen finden auf Verkehrszellenebene, unter Berücksichtigung der Reisezeit und Entfernung zum nächsten Ziel sowie zum nächsten festen Ziel, statt. Nach der Zielwahl wird für jeden Weg das Verkehrsmittel gewählt. In der Basisversion unterstützt mobiTopp die Verkehrsmittel Fuß, Fahrrad, Auto als Fahrer, Auto als Mitfahrer und ÖV. Vor der Verkehrsmittelwahl des Agenten wird die Menge der verfügbaren Verkehrsmittel abhängig von der aktuellen Situation des Agenten bestimmt. Am Wohnort stehen alle Verkehrsmittel zur Verfügung, sofern der Haushalt über ein Auto verfügt und dieses von keinem anderen Haushaltsmitglied gerade in Benutzung ist. Startet ein Agent am Wohnort mit dem Auto oder Fahrrad, muss er dieses für die gesamte Tour nutzen. Startet er am Wohnort zu Fuß, als Mitfahrer oder mit dem ÖV, kann er auf der gesamten Tour zwischen diesen drei Verkehrsmitteln wählen. Wie bei der Zielwahl, wird auch für die Verkehrsmittelwahl ein Discrete Choice Modell verwendet. Bei diesem werden die Distanz, Reisezeit, Kosten und die Soziodemographie des Agenten berücksichtigt. Alternativ zur getrennten Wahl von Ziel und Verkehrsmittel ist auch eine kombinierte Wahl von Ziel und Verkehrsmittel möglich [9]. Eine Umlegung des Verkehrs auf konkrete Routen findet in der Basisversion nicht statt. Die Agenten werden entsprechend der Reisezeit ohne Interaktion mit anderen Agenten an ihr Ziel befördert. Eine Aggregation der Nachfrage zur Umlegung in PTV VISUM ist aktuell der meist genutzte Weg zur Umlegung der mobiTopp Ergebnisse. Für eine Umlegung der Nachfrage auf der Ebene einzelner Agenten kann MATSim verwendet werden. Dabei werden alle Agenten und Wege nach MATSim überführt und dort umgelegt [10]. Der ÖV kann zusätzlich direkt in mobiTopp umgelegt werden. Statt einer Beförderung ohne Interaktion, interagieren die Agenten mithilfe des Fahrplans mit den Fahrzeugen und Haltestellen [11]. Durch den modularen Aufbau von mobiTopp kann die Basisversion in unterschiedlicher Weise erweitert werden. Die Erweiterung der Autos von reinen Verbrennungsmotoren zu Hybrid- und Elektroautos wird in [12] und [13] thematisiert. Das Mitfahrerverhalten wird in [14] von einer impliziten auf eine explizite Modellierung verändert. Hierbei wird für Wege mit gleichem Start und Ziel eine Mitfahrgelegenheit vermittelt. Zusätzlich zu den Verkehrsmitteln der Basisversion wird in [15] eine Integration von Freefloating- und stationsbasiertem Carsharing in mobiTopp beschrieben.

3 Integration von Ridepooling- und Ridehailing-Diensten in mobiTopp

Die folgenden Darstellungen fokussieren sich auf Ridepooling, was das algorithmisch und simulationstechnisch komplexere Problem darstellt. Allgemein besteht bei Ridepooling die Optimierungsaufgabe, die Routen von verschiedenen Fahrzeugen so zu wählen, dass bestimmte Orte (Quellen und Ziele von Wegen) mit möglichst kurzer Fahrzeit hintereinander abgefahren werden, sowie diese Fahrtwünsche unterschiedlicher Personen auf die verschiedenen Fahrzeuge günstig aufzuteilen. Damit liegt eine Nähe zu dem mathematischen Traveling Salesman-Problem (TSP) [16] bzw. Tourenplanungsproblemen (Vehicle Routing Problem, VRP) der Logistik vor. Wichtig für eine Anwendung von derartiger Algorithmen für Ridepooling ist, dass die Reihenfolge der Ziele definierbar ist (erst Einstieg, dann Ausstieg der Agenten), sich frühestmögliche Abfahrtszeitpunkte bestimmen lassen (entspricht der gewünschten Abfahrtszeit der Agenten) und eine Fahrzeugkapazität einstellbar ist (entsprechend der maximal möglichen Fahrgastzahl der Fahrzeuge). Zusätzlich zu oben genannten Voraussetzungen ist jedoch problematisch, dass TSP- bzw. VRP Algorithmen üblicherweise darauf ausgelegt sind, dass die Fahrzeugtouren bereits im Voraus komplett geplant werden. Für die Anwendung in einem Simulationswerkzeug wie im hier vorliegenden Fall ist es jedoch nötig, die Touren im Verlauf der Simulation entsprechend der Fahrtwünsche der Agenten planen und verändern zu können. In der Informatik wird das auch als Dynamic Vehicle Routing Problem bezeichnet [17].

3.1 Ansätze aus der Literatur

Zur Modellierung von Ridepooling- und Ridehailing-Angeboten sind in der Literatur unterschiedliche Ansätze vorhanden. Von Hartl et al. [18] wird ein Algorithmus zur Bildung von Ridepooling-Touren in einem Modell der makroskopischen Verkehrssimulation PTV Visum mit Nachfrage in 15-Minuten-Zeitintervallen entwickelt. Der Kern des Algorithmus besteht in einer Prüfung, ob sich Fahrtwünsche auf Verkehrszellenebene in den kürzesten Weg in eine bereits geplante Tour eingliedern lassen. Heilig et al. [19] fassen die Nachfrage nach OD-Relationen in 15-Minuten-Zeitintervallen zusammen und ermitteln aus den sich ergebenden Kosten und Fahrzeiten die Nutzung und erforderliche Flottenstärke eines Ridepooling-Dienstes. Der Ansatz betrachtet jedoch nur eine nachträgliche Ermittlung der notwendigen Fahrzeugflotten und keine direkte Integration in die Verkehrsnachfragemodellierung. Ein anderer Ansatz wird von dem PTV MaaS Modeller genutzt [20]. Hierbei wird die Nachfrage aus einem VISUM Modell zunächst disaggregiert, anschließend findet eine Fahrtenbündelung statt. Die Fahrtenbündelung erfolgt unter Nutzung von Algorithmen der Logistik im Sinne einer Folge von Problemen der Art „VRP mit Pickup, Delivery und Zeitfenstern“. Auch in der agenten-basierten Simulation MATSim sind Ansätze zur Modellierung von MoD Diensten implementiert [21]. Abhängig von der konkreten Untersuchungssituation werden unterschiedliche Algorithmen genutzt. So wird von Bischoff et al. zur Simulation einer Flotte aus geteilten Taxis für rund 27 000 Fahrtwünsche ein Algorithmus eingesetzt, der die Fahrtwünsche auf die Einfügung in eine bestehende Tour prüft [22]. Mit einem anderen Ansatz wird ein Ridehailing-Szenario mit autonomen Fahrzeugen, in dem alle privaten Pkw ersetzt werden, erstellt [23] .

3.2 Ansatz von mobiTopp MoD

Ziel der nachfolgend dargelegten Arbeit ist die Berücksichtigung von Ridepooling und Ridehailing in der Verkehrsmittelwahl der mikroskopischen Nachfragesimulation mobiTopp. Allgemein sind besonders zwei Aspekte von Relevanz: Zum einen muss die Interdependenz der Buchungen mit den Fahr- und Wartezeiten abgebildet werden. Die Verkehrsmittelwahl wird dafür um eine Funktionalität ergänzt, mit der im Lauf der Simulation (dynamisch) bestimmte Parameter berücksichtigt werden können. Zum anderen ist die Implementierung einer Fahrtenbündelungsstrategie erforderlich.

Es wird im Folgenden zunächst auf den zweiten Aspekt eingegangen und anschließend die Integration in die Verkehrsmittelwahl beschrieben. Für eine fahrzeugfeine Ermittlung der Kennwerte – wie die Belegung der Fahrzeuge im Verlauf der Simulation, die Auswirkungen verschiedener Bündelungsstrategien usw. – sowie ein möglichst genaues Abbild der Realität wird eine mikroskopische Abbildung der einzelnen Fahrzeuge genutzt. Jedes Fahrzeug weist eine Tour auf, d.h. eine Abfolge von nacheinander zu erreichenden Verkehrszellen, die sich durch die Fahrtwünsche der Agenten ergeben. Im Vergleich zum TSP liegt prinzipiell ein vereinfachtes Problem vor, da nicht bei jedem Fahrtwunsch die Touren aller Fahrzeuge neu geplant werden müssen. Es muss lediglich die bestmögliche Integration des vorliegenden Fahrtwunschs in eine bestehende Tour ermittelt werden. Die Zuordnungen von bestehenden Buchungen zu Fahrzeugen und die Reihenfolge der Abarbeitung aller anderen, nicht betroffenen Touren soll nicht geändert werden. Daher lässt sich ein Algorithmus formulieren, der zum Zeitpunkt der Verkehrsmittelwahl eines Agenten angewandt wird, d.h. es sind Start und Ziel des geplanten Weges bekannt. Der Algorithmus wird nachfolgend beschrieben, indem die Integration eines neuen Fahrtwunschs in die bestehenden Touren der Fahrzeugflotte dargestellt wird.

Es wird in allen Fahrzeugen des Ridepooling-Anbieters geprüft, wie sich der Weg in die Tour des jeweiligen Fahrzeugs integrieren lässt. Integration bedeutet, dass Start- und Zielzelle des neuen Wegs zur Tour hinzugefügt werden. In der Tour werden diese als Pickup (Einstieg) und Dropoff (Ausstieg) des Agenten bezeichnet. Je Fahrzeug gibt es zwei mögliche Ausgangssituationen.

Alternative 1: Befördert ein Fahrzeug aktuell keine Fahrgäste gibt es nur eine Möglichkeit zur Integration des aktuellen Fahrtwunschs in die Tour eines Fahrzeugs: eine Fahrt von der aktuellen Position des Fahrzeugs zu der Pickup-Zelle und anschließend weiter zu der Dropoff-Zelle.

Alternative 2: Befördert das Fahrzeug aktuell Fahrgäste, das heißt es gibt mindestens eine aktive Buchung eines anderen Agenten, ergeben sich mehrere Möglichkeiten der Integration. Pickup und Dropoff des „neuen“ Agenten können zwischen allen Pickup- und Dropoff-Vorgängen der vorhandenen Buchungen integriert werden. Dies ergibt eine Menge möglicher Einfügepositionen. Jede dieser Einfügepositionen ist dabei mit unterschiedlich großen Fahrzeitverlängerungen für die anderen, bereits bestehenden Buchungen, verbunden. Für alle möglichen Positionen werden diese Verlängerungen ermittelt und weiterhin geprüft, ob durch die Einfügeposition Restriktionen hinsichtlich Fahrzeugkapazität und maximaler Fahrzeitverlängerungen eingehalten werden. Unter allen Einfügepositionen, die keine Restriktionen verletzen, wird schließlich diejenige gewählt, die die geringste Fahrzeitverlängerung für das Fahrzeug (Umweg) aufweist. Prinzipiell könnten dabei allerdings auch andere Auswahlstrategien eingesetzt werden. Eine grafische Darstellung der Ermittlung der besten Einfügeposition ist in Bild 1 gegeben. Die Verkehrszellen werden dabei als Knoten und die Wege zwischen diesen als Kanten abstrahiert.

Bild 1: Bestimmung der besten Einfügeposition eines Agenten in der Tour eines Fahrzeugs

Die beschriebene Ermittlung der bestmöglichen Einfügeposition wird für alle Fahrzeuge der Flotte ermittelt. Hiermit ist im Ergebnis für jedes Fahrzeug bekannt, wie hoch die Fahrzeitverlängerung wäre, wenn der „neue“ Agent in die Tour eingeplant wird. Im folgenden Schritt muss eines der Fahrzeuge ausgewählt werden. Dies geschieht in der aktuellen Implementierung durch einen Vergleich der erwarteten Ankunftszeit: Es wird dasjenige Fahrzeug ausgewählt, mit dem der Agent am frühesten am Ziel wäre. Auch hier sind alternative Auswahlkriterien denkbar, bspw. das Fahrzeug, das insgesamt den geringsten zusätzlichen Umweg erzeugt. Mit dem gewählten Fahrzeug werden anschließend die Fahrtkosten für den Agenten berechnet. Mit Fahrzeit und Kosten stehen alle Daten für die Verkehrsmittelwahl zur Verfügung und der Agent kann das Verkehrsmittel Ridepooling neben den anderen Verkehrsmitteln in mobiTopp in die Wahlentscheidung einbeziehen.

Wählt ein Agent aus allen Verkehrsmittelalternativen den Modus Ridepooling, werden Pickup und Dropoff des „neuen“ Agenten in die Tour des zuvor ermittelten Fahrzeugs eingefügt. Ab diesem Zeitpunkt ist die veränderte Tour für das Fahrzeug gespeichert und weitere Fahrtwünsche von anderen Agenten basieren dann auf diesem geänderten Tourverlauf. Insgesamt entspricht der dargestellte Algorithmus möglicherweise in der Komplexität nicht real genutzten Algorithmen von MoD-Anbietern, erscheint aber für die Planung vorerst ausreichend genau zu sein.

Der gesamte Prozess der Verkehrsmittelwahl unter Verwendung der MoD-Erweiterung, wie oben erläutert, wird in Bild 2 dargestellt. Wesentlich ist der dreistufige Ansatz: zunächst wird die Verfügbarkeit der Verkehrsmittel bestimmt, anschließend werden für alle Verkehrsmittel die jeweiligen Attribute dieses Wegs ermittelt, einschließlich der potenziellen Fahr- und Wartezeit bei MoD, entsprechend obiger Ausführungen. Hierbei ist noch nicht entschieden, ob es überhaupt zu einer Buchung des MoD-Dienstes kommt. Nur, wenn entsprechend des anschließenden discrete choice-Modells MoD ausgewählt wird, wird der Fahrtwunsch tatsächlich in der Tour eines MoD-Fahrzeugs eingeplant.

Bild 2: Verkehrsmittelwahl bei Verwendung der MoD-Erweiterung

Nachfolgendend listen wir einige weitere Details des implementierten Ansatzes auf:

• Der Dauer eines Pickup- bzw. Dropoff-Vorgangs wird mit einem Zuschlag bei den Berechnungen der Fahrzeitveränderungen von beispielsweise zwei Minuten berücksichtigt (nicht im Beispiel in Bild 1 dargestellt).

• Der Preis je Fahrt ist flexibel konfigurierbar, sowohl zeit- als auch entfernungsabhängige und kombinierte Preisschemen sind möglich.

• Die maximal akzeptierten Verlängerungen aufgrund neuer Buchungen (Restriktionen bei der Ermittlung der optimalen Einfügeposition) sind durch die Parameter t_(max_increase,travel) für die zusätzliche Fahrzeit eines bestehenden Agenten und t_(max_increase,waiting) für die zusätzliche Wartezeit eines Agenten einstellbar.

• Es ist möglich, eine Relocation-Funktionalität zu aktivieren. Dabei werden Fahrzeuge, sobald keine Fahrgäste mehr vorhanden sind, zu einer nahegelegenen „Hotspot“-Zelle verlagert. Eine Übersicht der zur Verfügung stehenden Konfigurationsparameter ist in Tabelle 1 dargestellt.

Tabelle 1: Übersicht über die Konfigurationsparameter bei Ridepooling

Der dargestellte Ablauf gilt für Ridepooling. Für Ridehailing gilt folgende Veränderung: Neue Fahrtwünsche können nur an das Ende bestehender Touren angehängt werden, dementsprechend kommt es nie zu Verlängerungen der Warte- und Fahrzeit von Agenten, die bereits ein Fahrzeug gebucht haben.

Zu beachten ist, dass die Eigenschaften des Agenten bei der Verkehrsmittelwahl bekannt sind. Damit ist die Modellierung von Mitgliedschaften und darauf aufbauenden Verfügbarkeiten oder Rabatten unmittelbar möglich. Die Agenten verfügen jedoch nur eingeschränkt über die Möglichkeit, „vorausschauend“ zu handeln. Ist auf dem Hinweg eine günstige MoD-Option verfügbar, kann diese verwendet werden, ohne dass für die Rückfahrt eine vergleichbare Option besteht. Anders als bei Modellierungsansätzen, welche eine gegebene Nachfrage bestmöglich auf eine Flotte von Fahrzeugen verteilen, ist es außerdem nicht unmittelbar möglich, eine „nicht-bediente Nachfrage“ anzugeben. Dies bedingt sich daraus, dass beispielsweise bei einer hohen Wartezeit für einen Agenten daraus nicht unmittelbar gefolgert werden kann, dass tatsächlich ein potenzieller Fahrgast wegen dieser zu hohen Wartezeit „verloren“ geht. Denn dieser Agent hätte auch bei einer geringeren Wartezeit ein anderes Verkehrsmittel wählen können, bspw. aufgrund preislicher Unterschiede. Im Folgenden werden drei unterschiedliche Szenarien beschrieben, die die Bandbreite der Analysemöglichkeiten durch das neue MoD-Modul für mobiTopp aufzeigen.

3.3 Szenarienvorstellung

Die für diesen Beitrag simulierten Szenarien basieren auf einer mobiTopp-Implementierung für die Region Stuttgart [24]. Für die Szenarien wird auf dem finalen Stand des damaligen Modells aufgesetzt und zusätzlich die neuen Ridepooling-Services integriert. Die Entscheidungs¬parameter der Verkehrsmittelwahl für die Ridepooling-Services entsprechen derzeit noch den Parametern des öffentlichen Verkehrs. Perspektivisch ist es hier natürlich notwendig, Erhebungen zur Zahlungsbereitschaft und weiteren Einflussfaktoren der Nutzung von Ridepooling-Diensten durchzuführen. Diese liegen zum aktuellen Zeitpunkt jedoch noch nicht vor. Dieser Beitrag soll die technischen Möglichkeiten der Analyse und die grundsätzlichen Prinzipien des implementierten Ansatzes darstellen. Es muss daher bedacht werden, dass an dieser Stelle aufgrund der fehlenden Parameter keine Verkehrsverlagerungseffekte oder belastbare Aussagen zu Modal Splits gemacht werden können. Die Parameter sind in allen drei Szenarien gleich. Veränderungen in der Fahrtenanzahl sind daher ausschließlich angebotsbedingt, bspw. durch eine größere Anzahl an Fahrzeuge und damit einhergehenden geringeren Wartezeiten. Die drei verschiedenen Szenarien unterscheiden sich ausschließlich in der Flottengröße der Ridepooling-Dienste. Szenario 1 umfasst 100 Fahrzeuge, Szenario 2 200 Fahrzeuge und in Szenario 3 sind 400 Ridepooling-Fahrzeuge unterwegs. Weiterhin gelten für alle Szenarien die folgenden Eigenschaften:

• Ein Ridepooling-Fahrzeug hat eine maximale Kapazität von vier mitfahrenden Passagieren.

• Das Bediengebiet der Fahrzeuge ist die Stadt Stuttgart. Fahrten können nur innerhalb des Stadtgebiets durchgeführt werden.

• Die Kosten für die Fahrt mit einem Ridepooling-Fahrzeug betragen 0,50 € pro Kilometer (c_s=0,50 €, c_t=0). Zusätzlich entsteht pro Buchung eine Grundgebühr von c_base=1 €. Die Anzahl der Mitfahrer oder die Fahrtdauer beeinflussen die Kosten nicht. Es gilt ein Maximalpreis von c_max=10 €.

• Der maximal akzeptierte Umweg beträgt 15 Minuten für die Fahrzeit (t_(max_increase,travel)) sowie 10 Minuten für die Wartezeit (t_(max_increase,waiting)).

Weiterhin gelten die folgenden Unterschiede zum ursprünglichen mobiTopp-Modell: Es werden ausschließlich Verkehre an einem Montag betrachtet, die Simulationsdauer beträgt 1 Tag. Außerdem werden in der Analyse, analog zum Bediengebiet der Fahrzeuge, nur Fahrten innerhalb des Stadtgebiets Stuttgart betrachtet.

3.4 Ergebnisanalyse

Tabelle 2 betrachtet verschiedene Kennwerte der simulierten Ridepooling-Szenarien. Alle Kennwerte beziehen sich ausschließlich auf Fahrten, die mit Ridepooling-Fahrzeugen zurückgelegt werden. Der durchschnittliche Besetzungsgrad ist mit knapp drei Passagieren in allen Szenarien hoch. Die mittlere Besetzung sinkt mit steigender Fahrzeugzahl leicht. Dies lässt darauf schließen, dass sich mit steigender Fahrzeugzahl das Modell einem Sättigungspunkt nähert. Sättigungspunkt bedeutet in diesem Zusammenhang, dass es eine Anzahl von Fahrzeugen geben kann, ab dem mit weiter steigender Anzahl an Fahrzeuge der Besetzungsgrad stark abnimmt und die Buchungsanzahl nicht mehr zunimmt, da die Nachfrage gesättigt wäre. Dieser Punkt konnte in den aktuellen Szenarien mit 400 Fahrzeugen noch nicht erreicht werden. Die Anzahl der Buchungen steigt nahezu linear mit der Anzahl der Fahrzeuge an, was verdeutlicht, dass eine potentiell noch höhere Nachfrage nach dem Ridepooling-Service besteht. Hier sei nochmals daran erinnert, dass wir bisher auf keine eigene Parameterschätzung zur Entscheidungsfindung der Verkehrsmittelwahl zurückgreifen können. Die hier verwendeten Parameter zeigen demnach technisch mögliche Auswertungen, sind aber kein Indiz für tatsächlich in der Realität zu erwartende Nachfragewerte. (Aufgrund der starken Einschränkungen hinsichtlich der gewählten Parameter der Nutzenfunktion weisen wir an dieser Stelle auch keinen Schwellwert mit besonders großem Nachfragerückgang oder ähnlichem aus.)

Tabelle 2: Kenntwerte der simulierten Ridepooling-Szenarien

Die mittlere zurückgelegte Distanz je Buchung geht insgesamt mit steigender Fahrzeugzahl zurück. Damit einher geht ein geringerer durchschnittlicher Umwegfaktor der Distanz. Mit steigender Anzahl der Fahrzeuge können bessere Tourenoptimierungen durchgeführt werden und die Entfernung sinkt. Dies wird auch durch Bild 3 verdeutlicht. Es zeigt die Verteilung der zurückgelegten Distanzen in allen Szenarien. Der Anteil kurzer Buchungen nimmt dabei mit steigender Anzahl an Fahrzeuge zu und der Anteil längerer Buchungen ab. Der zeitliche Umwegfaktor je Buchung steigt mit der Fahrzeuganzahl leicht an. Dies ist vor allem durch den Anstieg der kürzeren Buchungen zu erklären. Bei kürzeren Buchungen ist der Einfluss eines Umwegs relativ gesehen größer als bei langen Fahrten, weil der maximal mögliche Umweg in den betrachteten Szenarien absolut definiert ist (15 Minuten) und nicht relativ. Die Analysen der Umwegfaktoren (Distanz und Dauer) sowie der Veränderung der geplanten Kosten zu Buchungsbeginn und -ende bieten viel Potential zur Angebotsoptimierung. Planer sowie Betreiber von MoD-Lösungen können diese als Werkzeuge nutzen. Durch Simulationen mit verschiedenen Preisen für das Angebot werden unterschiedliche Nachfragen erzeugt. Diese führen wiederum zu anderen Umwegfaktoren und Kostenveränderungen. Anbietern wird auf diesem Weg ermöglicht ein Angebot nach ihren Zielen zu gestalten und die mögliche Erreichung ihrer Ziele mit mobiTopp zu testen. Ein Angebot lässt sich so bspw. hinsichtlich der Kosten bzw. des Gewinns optimieren oder der bestmöglichen Bedienung der Nachfrage.

Bild 3: Zurückgelegte Distanzen je Buchung nach Szenario

Bild 4 stellt eine weitere Auswertungsmöglichkeit der Ergebnisse des mobiTopp MoD-Moduls vor. In der Abbildung wurde aus dem Szenario mit 200 Fahrzeugen ein zufälliges Fahrzeug extrahiert und dessen Aktionen im Tagesverlauf dargestellt. Damit können Ein- und Ausstiegsvorgänge, Leerfahrten sowie der Besetzungsgrad auf individueller Ebene visuell dargestellt werden. Mit den zugrunde liegenden Daten der einzelnen Tagesverläufe der Fahrzeuge lassen sich ebenfalls räumliche Darstellungen anfertigen, bspw. in welchem Gebieten das Fahrzeug zu welcher Zeit unterwegs ist, um Passagiere zu befördern.

Bild 4: Beispielauswertung Besetzungsgrad

4 Fazit und Ausblick

Durch die steigende Bekanntheit und Bedeutung moderner Angebote im Bereich von Mobility on Demand (MoD) wird deren Berücksichtigung in Modellen der Verkehrsplanung ebenfalls zunehmend relevanter. Dienste der kommerziellen Vermittlung von Fahrten wie Ridehailing (exklusive Fahrzeugnutzung) oder Ridepooling (Nutzung gemeinsam mit anderen Fahrgästen) stellen durch zeit- und routenabhängige Preisgestaltungen eine individuelle Angebotsform dar, für deren Modellierung sich insbesondere mikroskopische Verkehrsnachfragemodelle eignen.

Der vorliegende Beitrag hat gezeigt, wie diese Dienste in das mikroskopische Verkehrsnachfragemodell mobiTopp integriert werden können und welche Auswertemöglichkeiten sich dadurch ergeben. Das neue mobiTopp-Modul für MoD-Dienste ermöglicht durch neu entwickelte Algorithmen das parallele Handling von allen Fahrzeugen eines Dienstanbieters. Fahr- und Wartezeiten der Fahrzeuge werden individuell berechnet und die jeweiligen Werte stehen Personen für die Verkehrsmittel¬wahlentscheidungen in der Simulation zur Verfügung. Entscheidungen der Agenten beeinflussen sich dabei gegenseitig, indem die Fahrzeugverfügbarkeit der Dienste beeinflusst wird und bspw. andere Wartezeiten oder Umwege entstehen. Die Algorithmen des Ridepooling verteilen Buchungen der Personen dabei so auf die Fahrzeuge, dass Umwege möglichst gering ausfallen, die Fahrzeuge gleichzeitig aber bestmöglich ausgelastet werden und möglichst wenig Leerfahrten entstehen. Der Algorithmus zur Optimierung ermittelt hierzu die beste Einfügung von Fahrtwünschen in die Tour aller Fahrzeuge, ohne die Reihenfolge der bereits vorhandenen Buchungen zu verändern.

Durch das neu implementierte Modul ergeben sich vielfältige Auswertemöglichkeiten. Es können Kennwerte für die Buchungen der Agenten ebenso betrachtet werden wie Kennwerte für die Fahrzeuge der Flotte. Durch individuell parametrisierbare Szenarien können die Auswirkungen unterschiedlicher Preisgestaltungen oder Angebotsparameter (bspw. maximal durchgeführte Umwege) auf die Nachfrage sowie auf die Auslastung der Fahrzeuge dargestellt und analysiert werden. Auch die individuelle Analyse einzelner Fahrzeuge und deren Tagesverlauf der Belegung oder der zurückgelegten Routen ist möglich. Anhand von drei Szenarien eines Ridepooling-Dienstes im Stadtgebiet Stuttgart mit unterschiedlichen Flottengrößen wurden diese Auswertemöglichkeiten im Beitrag beispielhaft dargestellt. In den Szenarien wurden für die Entscheidungsparameter der Verkehrsmittelwahl Parameter des öffentlichen Verkehrs übernommen. Zukünftig werden diese durch Parameter aus eigenen Erhebungen (beispielsweise mittels Stated-Choice Befragungen) zur Nutzung von Ridehailing und Ridepooling Fahrzeugen ersetzt. Damit können neben den bereits gezeigten Analysen auch erwartbare Nachfrageveränderungen und Verkehrsverlagerungseffekte in verschiedenen Szenarien analysiert werden.

Neben dem bereits Open Source verfügbaren Basismodell von mobiTopp wird in Kürze auch die MoD-Erweiterung Open Source zur Verfügung stehen. Damit können Angebotsbetreiber und andere Nutzer des Modells mobiTopp zur Simulation verschiedener Angebote nutzen. Weitere Arbeiten zur Optimierung des MoD-Moduls sind im Bereich der Effizienz geplant, um auch größere Fahrzeugflotten und Planungsräume berechnen zu können. Neben den technischen Optimierungen sind auch weitere Szenarien geplant, um die Sensitivität der einstellbaren Parameter besser abschätzen und bewerten zu können. Ebenfalls wird die Integration in den ÖV vertieft. Insgesamt wird mit dem neu entwickelten Modul das Verkehrsnachfragemodel mobiTopp für die Abbildung in Zukunft immer relevanter werdender Mobilitätslösungen verbessert.

5 Literatur

[1] Mehlert, C.: Ridepooling - Hype oder Disruption. Rufbus meets Mobility 4.0. Friedrichshafen 2018

[2] Interreg Europe: Demand-responsive Transport - A Policy Brief from the Policy Learning Platform on Low-carbon economy, 2018

[3] Viergutz, K., Brinkmann, F.: Ridepooling - Ein Erfolgsmodell? - Digitalisierung im Nahverkehr. Signal + Draht (2018) 7+8, S. 13–18

[4] Jittrapirom, P., Caiati, V., Feneri, A.-M., Ebrahimigharehbaghi, S., González, M., Narayan, J.: Mobility as a Service - A Critical Review of Definitions, Assessments of Schemes, and Key Challenges. Urban Planning 2 (2017) 2, S. 13

[5] Mallig, N., Kagerbauer, M., Vortisch, P.: mobiTopp – A Modular Agent-based Travel Demand Modelling Framework. Procedia Computer Science 19 (2013), S. 854–859

[6] Mallig, N. u. Vortisch, P.: Modeling travel demand over a period of one week: The mobiTopp model, 2017

[7] Hilgert, T., Kagerbauer, M., Heilig, M., Vortisch, P.: Modellierung von Wochenaktivitätenplänen für das Multi-Agenten-Modell mobiTopp. Straßenverkehrstechnik (2017) 6, S. 371–380

[8] Mallig, N.: Modellierung von Stabilität in der Verkehrsmittelwahl in einem mikroskopischen Verkehrsnachfragemodell, Karlsruher Institut für Technologie Dissertation. Karlsruhe 2019

[9] Heilig, M., Mallig, N., Hilgert, T., Kagerbauer, M., Vortisch, P.: Entwicklung eines kombinierten Ziel- und Verkehrsmittelwahlmodells für das Multi-Agenten-Modell mobiTopp. HEUREKA '17. Optimierung in Verkehr und Transport. Köln: FGSV 2017

[10] Briem, L., Mallig, N., Vortisch, P.: Creating an integrated agent-based travel demand model by combining mobiTopp and MATSim. Procedia Computer Science: The 8th International Workshop on Agent-based Mobility, Traffic and Transportation Models (2019)

[11] Briem, L., Buck, H. S., Mallig, N., Vortisch, P., Strasser, B., Wagner, D., Zündorf, T.: Integrating public transport into mobiTopp. Procedia Computer Science 109 (2017), S. 855–860

[12] Mallig, N., Heilig, M., Weiss, C., Chlond, B., Vortisch, P.: Modelling the weekly electricity demand caused by electric cars. Future Generation Computer Systems 64 (2016), S. 140–150

[13] Weiss, C., Heilig, M., Mallig, N., Chlond, B., Franke, T., Schneidereit, T., Vortisch, P.: Assessing the effects of a growing electric vehicle fleet using a microscopic travel demand model. European Journal of Transport and Infrastructure Research EJTIR 17 (2017) 3, S. 330–345

[14] Mallig, N., Vortisch, P.: Modeling Car Passenger Trips in mobiTopp. Procedia Computer Science 52 (2015), S. 938–943

[15] Heilig, M., Mallig, N., Schroeder, O., Kagerbauer, M., Vortisch, P.: Implementation of free-floating and station-based carsharing in an agent-based travel demand model. Travel Behaviour and Society (2018)

[16] Näher, S.: 40. Algorithmus der Woche. Das Travelling Salesman Problem (2006)

[17] Pillac, V., Gendreau, M., Guéret, C., Medaglia, A.: A review of dynamic vehicle routing problems. European Journal of Operational Research 225 (2013) 1, S. 1–11

[18] Friedrich, M., Hartl, M., Magg, C.: A modeling approach for matching ridesharing trips within macroscopic travel demand models. Transportation 45 (2018) 6, S. 1639–1653

[19] Heilig, M., Hilgert, T., Mallig, N., Kagerbauer, M., Vortisch, P.: Potentials of Autonomous Vehicles in a Changing Private Transportation System – a Case Study in the Stuttgart Region. Transportation Research Procedia 26 (2017), S. 13–21

[20] Noekel, K.: Modeling Ride Pooling Within State-Of-The-Art Travel Demand Models. Transportation Research Board, Annual Meeting Poster Session. 2018

[21] Maciejewski, M.: Dynamic Transport Services. In: Horni, A., Nagel, K. u. Axhausen, K. (Hrsg.): The Multi-Agent Transport Simulation MATSim. Ubiquity Press 2016, S. 145–152

[22] Bischoff, J., Maciejewski, M., Nagel, K.: City-wide shared taxis - A simulation study in Berlin. 2017 IEEE 20th International Conference on Intelligent Transportation Systems (ITSC). IEEE 2017 - 2017, S. 275–280

[23] Bischoff, J., Maciejewski, M.: Simulation of City-wide Replacement of Private Cars with Autonomous Taxis in Berlin. Procedia Computer Science 83 (2016), S. 237–244

[24] Hautzinger, H., Kagerbauer, M., Mallig, N., Pfeiffer, M. u. Zumkeller, D.: Mikromodellierung für die Region Stuttgart - Schlussbericht, 2013