In bisherigen Simulationsstudien von autonomen Robotertaxis wurde herausgefunden, dass Leerfahrten einen erheblichen Anteil von ungefähr 10% an der gesamten, während eines Tages von der Flotte zurückgelegten Strecke ausmachen werden. Meist wurden bei diesen Studien zeitlich konstante Reisezeiten angenommen. Außerdem wurden die verkehrlichen Auswirkungen bisher nur für den Fall untersucht, dass der komplette Verkehr durch diese Robotertaxis abgedeckt wird. In dieser Arbeit werden durch die Simulation des autonomen Taxisystems als Teil einer Verkehrsmikrosimulation sowohl die Auswirkungen von variablen, der Verkehrssituation entsprechenden Reisezeiten auf die Flottenperformance, als auch die Effekte der zusätzlichen Leerfahrten auf den städtischen Straßenverkehr untersucht.

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

1 Einleitung

In den letzten Monaten wurde berichtet, dass sich die meisten Automobilhersteller in Ridesharing-Dienste eingekauft haben, um sich für den Betrieb einer Flotte von Robotertaxis vorzubereiten [1]. Es wird erwartet, dass diese Robotertaxis für ein „Mobility-on-Demand“ System verwendet werden, bei dem die Fahrzeuge nicht mehr im privaten Besitz, sondern Teil von Fahrzeugflotten von Mobilitätsanbietern sein werden. Kunden werden per Smartphone-App ihren Standort und ihr gewünschtes Ziel an den Mobilitätsdienstleister übermitteln und dieser wird schnellstmöglich ein Fahrzeug zum Kunden aussenden. Dieses Prinzip entspricht einer Verschmelzung von heutigen Taxi und Carsharing Diensten, aber wird wegen des fehlenden Fahrers im Betrieb günstiger als Taxis und wegen der automatischen Anfahrten zum Kunden komfortabler als Carsharing sein.

Mit nuTonomy werden in Singapur und bald auch in Boston die ersten dieser Fahrzeuge im Einsatz sein, wenn auch noch mit Sicherheitsfahrer und in eingeschränkten Bereichen der jeweiligen Städte [2].

Vorteile von diesen geteilten autonomen Fahrzeugen (SAVs, im Englischen für shared autonomous vehicles) wurden bereits in einigen wissenschaftlichen Publikationen in unterschiedlichen Szenarien ausgearbeitet, zum Beispiel von Burns et al. [3] oder Fagnant und Kockelman [4]. Wegen der hohen Flexibilität bei akzeptablen Preisen wird vermutet, dass viele Kunden ihre privaten Fahrzeuge abschaffen beziehungsweise keine neuen privaten Fahrzeuge anschaffen; Einsparungen an der Gesamtzahl an Fahrzeugen können einen Faktor 10 erreichen. Untersuchungen haben weiterhin ergeben, dass jedes Fahrzeug in Privatbesitz ungefähr 90% der Zeit parkt [5] und zwischen 3 und 4 Parkplätze benötigt [6]. Wenn man diese Ergebnisse kombiniert, entsteht ein sehr großes Potential an freiwerdenden Parkflächen, die für eine bessere urbane Gestaltung genutzt werden können.

Weitere Vorteile sowohl für den Betreiber als auch für die Umwelt kann durch den Betrieb einer Flotte von elektrisch betriebenen Fahrzeugen erreicht werden: neben den offensichtlichen Reduktionen von Treibhausgasen erleichtern vor allem automatische Ladeprozesse, zum Beispiel durch induktives Laden, erheblich den Betrieb, weil kein Personal an Tankstellen benötigt wird. Wegen der kürzeren Reichweiten und den im Vergleich zu Tankvorgängen längeren Ladezeiten verschlechtert sich zwar die Performance des Systems, aber dies kann durch einige zusätzliche Fahrzeuge wieder ausgeglichen werden. Das International Transport Forum schätzte eine notwendige Flottenvergrößerung von 2% [7] und Chen et al. benötigten bei ihren Simulationen mit batteriebetriebenen Fahrzeugen mit 320 km Reichweite und Ladezeiten von 30 Minuten 6,6 % mehr elektrische als benzinbetriebene Fahrzeuge [8].

Der Betrieb einer autonomen Fahrzeugflotte bringt viele Variablen und Fragestellungen mit sich. Dazu zählen unter anderem das Verhalten möglicher Kunden, die zurückzulegenden Wege, die Zuweisung von Fahrzeugen zu Kunden, das explizite Fahrzeugrouting, die strategische Umpositionierung (Reallokation) von Fahrzeugen um künftige Kundenanfragen besser zu bedienen und die zeitliche und örtliche Verteilung von Ladeprozessen.

Viele dieser Fragestellungen wurden jeweils unterschiedlich detailliert in verschiedenen Forschungsarbeiten untersucht. Besonders das Thema „Reallokationen“ ist ein in der Carsharing-Forschung oft behandeltes Thema (siehe z.B. [9]) und wurde auch mit autonomen Flotten bereits mit verschiedenen Ansätzen angegangen. Falls die Kundenanfragen in Form von Reservierungen vorliegen, kann man die Wartezeiten aller Kunden [10], die zwischen den Kunden zurückgelegten Strecken oder auch eine Kostenfunktion, die diese und zusätzliche Größen enthält, optimieren. Für den Fall, dass die Kundenanfragen „on-Demand“ dem Flottenbetreiber bekannt werden, kann auf Basis historischer Daten der künftige Demand geschätzt werden und Fahrzeuge regelbasiert repositioniert werden [4]. In letztgenannter Studie zeigen Fagnant und Kockelman, dass Leerfahrten circa 10% der gesamten von der Flotte gefahrenen Strecke ausmachen.

In den bisher vorhandenen Untersuchungen zu autonomen Robotertaxis wurden die für die Simulation benötigten Reisezeiten meist als (räumlich oder zeitlich) konstant angenommen oder aus Carsharingoder Taxi-Buchungsdaten abgelesen. Bei räumlich konstanten Reisezeiten werden Schnellstraßen und Anwohnerstraßen gleich behandelt, während bei zeitlich konstanten Reisezeiten die Systemperformance während der Spitzenstunden tendenziell überschätzt wird. Bei der Verwendung von Buchungsdaten müssen immer noch die Leerfahrten, die in Realität nicht stattgefunden haben, geschätzt werden. In dieser Arbeit soll unter anderem abgeschätzt werden, wie sich variable Reisezeiten im Vergleich zu zeitlich konstanten Reisezeiten auswirken.

Die Belastung des Straßennetzes durch den Betrieb von SAVs wurden für den Fall, dass alle Fahrzeuge im Netzwerk Flottenfahrzeuge sind, von Levin et al. [11] berücksichtigt und von Rossi et al. [12] spezifisch untersucht. Letztere haben mathematisch bewiesen, dass für symmetrische Netzwerke und dem 100% SAV Fall durch Leerfahrten keine zusätzlichen Verkehrsstörungen entstehen. Die Idee hinter dem Beweis ist, dass Leerfahrten vom Fahrzeugüberschuss, der das Ziel der Hauptverkehrsrichtungen definiert, weg und damit entgegen den Hauptverkehrsströmen gerichtet sind. Nach dem Wissen der Autoren gibt es bis jetzt noch keine Arbeit, die die verkehrlichen Auswirkungen der Zusatzfahrten in einem gemischten Szenario untersucht, in dem es sowohl Fahrten privater Fahrzeuge, als auch ein SAV-System gibt. Grundsätzlich kann diese Untersuchung in einer makroskopischen oder mikroskopischen Verkehrssimulation erfolgen. Wegen den zu erzeugenden Einzelfahrten des SAV-Systems scheint eine Mikrosimulation allerdings angebrachter, wenn auch aufwendiger. Um verkehrliche Auswirkungen in Verkehrsspitzen zu sehen, die Rechenzeit aber gering zu halten, wird für diese Untersuchung das Zeitintervall zwischen 05:00 und 11:00 simuliert.

Der Rest dieser Arbeit ist wie folgt aufgebaut: In Kapitel 2 wird ein mikroskopisches Verkehrsflussmodell der Stadt München beschrieben und in Kapitel 3 wird auf ein in Python programmiertes SAEV-Modul (shared autonomous electric vehicle) eingegangen. Wegen der vielen Freiheitsgrade, die keine eindeutig optimalen Lösungen haben, wird die Flottensteuerung in dieser Arbeit möglichst einfach gehalten und mögliche Erweiterungen und Strategien nur erwähnt. Im Kapitel 4 werden kurz zwei alternative Simulationsumgebungen mit anderen Reisezeitenmodellen vorgestellt. Kapitel 5 enthält die Beschreibung der untersuchten Szenarien, deren Ergebnisse in Kapitel 6 vorgestellt werden. Im Schlusskapitel werden die wichtigsten Ergebnisse zusammengefasst und ihre Signifikanz eingeordnet.

2 Mikroskopisches Verkehrsflussmodell der Stadt München

Um die Auswirkungen der SAEV-Fahrten auf das Verkehrssystem untersuchen zu können, wurde eine mikroskopische Verkehrssimulation der Stadt und des Umlandes von München erstellt.

Das Netzwerk umfasst ca. 30x25 km und beinhaltet das weitere Umfeld Münchens. Das Netzwerk enthält neben der Bundesautobahn A99, welche einen unvollständigen Ring um die Stadt bildet, auch die Hauptzuflussrouten der Autobahnen A8, A9, A92, A94, A95 und A96. Die genauen Grenzen des Untersuchungsgebietes sind in Bild 1 zu sehen.

 Bild 1: Übersicht über das modellierte Straßennetzwerk der Stadt München und ein detaillierter Ausschnitt in Aimsun

Zusätzlich sind auch die nachgeordneten Hauptund Nebenstraßen im Netzwerk enthalten. Innerhalb des Mittleren Ringes B2R wurde das Netzwerk zusätzlich verdichtet und enthält alle Haupt-, Nebenund Anwohnerstraßen. Somit ist im Innenstadtbereich auch eine kleinräumige Umlagerung des Verkehrs möglich, wodurch auch Anwohnerverkehr und Schleichverkehrsfahrten abgebildet werden können.

Insgesamt besteht das gesamte Netzwerk aus über 37000 einzelnen Streckenabschnitten, bei welchen die für die jeweiligen Straßen entsprechende Verbindungsfunktionsstufe, Fahrstreifenanzahl, Kapazität und die zulässige Fahrgeschwindigkeit hinterlegt sind. Die Geometrien der Kreuzungen, die Fahrstreifenaufteilung, die erlaubten Abbiegebeziehungen und die Länge und Position der Abbiegestreifen wurden anhand von Lageplänen, oder falls diese nicht vorhanden waren anhand von Luftaufnahmen, der Realität entsprechend eingebunden. Hier wurde wieder spezielles Augenmerk auf den innerstädtischen Bereich gelegt, da hier durch den geringen Kreuzungsabstand eine korrekte Abbildung der Kreuzungen von besonderer Bedeutung für die Gesamtleistungsfähigkeit des Netzwerkes ist. Zusätzlich zur wirklichkeitsgetreuen Topografie der Knotenpunkte konnten für 75 Lichtsignalanlagen die aktuellen laufenden Lichtsignalpläne von der Stadt München eingebunden werden. Diese befinden sich an den wichtigsten Knotenpunkten der Hauptverkehrsstraßen, wie der B2R, B13 und B11. Diese wurden als Festzeitprogramm in die Simulation eingebunden. Zusätzlich wurden für 508 weitere Knotenpunkte anhand der Knotenbelastung, welche aus der makroskopischen Verkehrsumlegung ermittelt wurde, Lichtsignalpläne erstellt, und ebenfalls als Festzeitsteuerung eingebunden.

Die hinterlegte Verkehrsnachfrage deckt einen Zeitraum von 24 Stunden ab und wurde aus einem Validate-Modell der Firma PTV AG generiert. Um eine korrekte Abbildung des innerstädtischen Verkehrs auf dem dort feineren Netzwerk zu gewährleisten, ist dort eine entsprechend detailliertere Definition der Verkehrsnachfrage und der Verkehrsbeziehungen der Verkehrszellen zueinander notwendig, was die dort dichteren Quelle-Ziel-Punkte – auch Zentroide genannt – widerspiegeln. Das Modell wurde anhand von Verkehrszähldaten von 621 Detektoren verteilt auf 174 Kreuzungen im Innenstadtbereich kalibriert. Die Zählwerte der Detektoren liegen in Viertelstunden-Intervallen vor. Um eventuelle Tagesschwankungen der Messdaten auszugleichen wurden die Daten von 14 Tagen gemittelt. Hier wurde darauf geachtet, dass es sich ausschließlich um Dienstage, Mittwoche und Donnerstage handelte, an denen auch keine besonderen Störfälle oder außergewöhnliche Veranstaltungen stattfanden, um die durchschnittliche werktägliche Verkehrsnachfrage bestmöglich zu erfassen und Störungen zu eliminieren. Zusätzlich wurde die zeitliche Auflösung der QuelleZiel-Matrizen anhand der gemessenen Verkehrsnachfrage verbessert, so dass auch die Verkehrsnachfrage in Viertelstundenscheiben variiert wird.

3 Modell zur Flottensteuerung

3.1 Maßnahmen am mikroskopischen Verkehrsflussmodell

Im Aimsun Modell wurden zusätzlich mögliche Haltestellen für Kunden des SAEV-Systems definiert. Diese werden anhand von Quelle-Ziel-Punkten dargestellt. Da es sich um freefloating Carsharing handeln soll, wurden die nötigen Zentroide flächendeckend verteilt. Dazu wurden Zuund Ausstiegmöglichkeiten für Nutzer an Nebenund Anwohnerstraßen definiert. In Realität ist das Halten und Zusteigen an Hauptverkehrswegen wie den Autobahnen, dem Mittleren Ring oder größeren Straßen praktisch nicht möglich beziehungsweise verboten. Daher wurden mögliche Haltestellen an Knoten definiert, die nur mit Anwohneroder Nebenstraßen verbunden sind. Zusätzlich wurde ein Mindestabstand zur nächsten möglich Haltestelle von 125 Metern bei Anwohnerund 250 Metern bei Nebenstraßen gefordert. Durch ein Skript wurden im untersuchten Bereich 1238 mögliche Startund Zielpunkte für Kunden erstellt. Zum Vergleich: die MVG betreibt in München 974 Bushaltestellen, und gibt einen mittleren Abstand zur nächsten Haltestelle von 500 Metern aus [13]. Dadurch sollte „free-floating“ gut genug dargestellt sein.

Zur Modellierung von Ladeprozessen wurde die öffentlich verfügbare Ladeinfrastruktur, die aus einem gpx-File ausgelesen wurde [14], auf die nächstgelegenen Zentroide projiziert.

3.2 Funktionsweise des Flottenbetriebs

Der Betrieb einer SAEV-Flotte wird anhand einer agentenbasierten Simulation abgebildet. Dazu werden je nach Szenario Datensets mit Kundenanfragen erstellt, die reale App-Aufrufe modellieren sollen. Darin sind neben Startund Zielzentroiden auch die Zeitpunkte enthalten, zu welchen die Anfragen gestellt werden. Der Flottenbetrieb wird hier möglichst allgemein gehalten und enthält keine spezielle Reallokationsstrategie, auch wenn das Framework dies zulassen würde. Dadurch wird ein System abgebildet, in dem der Flottenbetreiber kein Vorwissen über künftige Anfragen hat. Es wird nur auf Kundenanfragen reagiert und das für den jeweiligen Kunden optimale Fahrzeug gesucht. Schematisch ist der Ablauf in Bild 2 dargestellt. Dieser Ansatz liefert im Allgemeinen keine systemoptimalen Zuweisungen – weder im lokalen, noch im zeitlichen Sinne – hat jedoch den Vorteil, dass ein Kunde sofort einem Fahrzeug zugewiesen wird und eine auf den berechneten Routen basierende Schätzung erhält, wann ein Flottenfahrzeug bei ihm sein kann. Anschließend hat der Kunde die Wahl, ob er sich von der Flotte transportieren lassen will, oder ob ihm die Wartezeit zu lange ist. Falls die vom Betreiber mitgeteilte Fahrzeugankunftszeit unter der akzeptierten Wartezeit liegt, wird der potentielle zu einem tatsächlichen Kunden und das Fahrzeug bekommt die Anweisung, diesen zu bedienen. Andernfalls wird die Fahrt nicht von der Flotte ausgeführt. In dieser Arbeit werden nicht erfüllte Anfragen durch gewöhnliche PKW-Fahrten in Aimsun dargestellt.

Bild 2: Reaktion auf eine Kundenanfrage.

Generell können Fahrzeuge im Betrieb eines SAEV-Systems als Roboter angesehen werden, die eine Sequenz von Aufträgen abarbeiten. In der Regel enthält ein Auftrag die Anweisung, eine Strecke von A nach B zu fahren. Dies kann aus verschiedenen Gründen notwendig sein: Fahrten von Kunden, Anfahrten zu Kunden, Fahrten zu Ladestationen und Reallokationen. Zusätzlich werden sowohl das Aufladen der Batterie, als auch das Einund Aussteigen von Kunden als Job oder Aufgabe aufgefasst. Jede dieser Fahrzeugaufgaben hat eine definierte Endposition und es ist möglich abzuschätzen, wann sie erledigt sein wird und welchen Ladestatus die Fahrzeugbatterie am Ende besitzen wird. Der Zielort des aktuell letzten Jobs eines Fahrzeugs j heißt Fahrzeugendposition x_f^j(t); die aktuell geschätzte Ankunftszeit an diesem Ort wird mit T_f^j(t) und das am Ankunftsort geschätzte Energieniveau der Batterie wird mit E_f^j(t) bezeichnet. All diese Informationen sind unentbehrlich, um die optimale Fahrzeugauswahl für eine Kundenanfrage zu treffen. Es wird dasjenige Fahrzeug gesucht, das am schnellsten beim Kunden ist und genügend elektrische Energie hat, um nach der Anfahrt auch noch die Strecke vom Startzum Zielpunkt des Kunden zurücklegen zu können. Um ein Stranden der Elektrofahrzeuge an Kundenzielen zu vermeiden, soll außerdem ein Energiepuffer E_p vorgehalten werden, der sich an dem maximalen Abstand zwischen den Ladestationen orientiert. Um das bestmögliche Fahrzeug auszuwählen, müssen neben den im Moment der Anfrage verfügbaren Fahrzeugen auch alle Fahrzeuge betrachtet werden, die in Kürze ihren letzten Auftrag beenden. Gesucht wird also dasjenige Fahrzeug, das

Formel siehe PDF.

erfüllt, wobei T^jk(t) die Reisezeit und E^jk(t) den Energiebedarf zwischen der Fahrzeugendposition des j-ten Fahrzeugs und dem Startpunkt des k-ten Kunden repräsentiert und E^k(t) dem Energiebedarf für die Strecke zwischen dem Start und Ziel des k-ten Kunden bezeichnet. Zur Lösung dieser Aufgabe wird ein modifizierter Rückwärts-Dijkstra mit der Kundenposition als Start und den Fahrzeugendpositionen als möglichen Zielen berechnet. Die geschätzten Ankunftszeiten der einzelnen Fahrzeuge an den Fahrzeugendpositionen T_f^j werden als Kosten-Offset aufgebracht. So werden sowohl die Zeit, die das Fahrzeug braucht, um an die Fahrzeugendposition zu gelangen, als auch die Anfahrtszeit von der Fahrzeugendposition zum neuen Kundenstandort berücksichtigt. Zur Berechnung der Dijkstras werden geschätzte Reisezeiten als Kosten für die Streckenabschnitte benötigt.

Wenn das optimale Fahrzeug bestimmt ist und der Kunde dem Service zustimmt, werden diesem Fahrzeug die Jobs „Anfahrt zum Kunden“, „Einsteigen“, „Fahrt des Kunden“ und „Aussteigen“ mit den jeweiligen Routen und geschätzten Endzeiten und Ladezuständen zugewiesen.

Da der Simulationszeitraum in dieser Arbeit nur 6 Stunden beträgt, ist die Ladestrategie bei genügend elektrischer Reichweite zweitrangig und wird möglichst einfach gewählt. Falls der Ladezustand am Ende des letzten Jobs unter ein Auflade-Level E_L fällt, wird zusätzlich per Dijkstra die nächste Ladestation gesucht und die Jobs „Fahrt zur Ladestation“ und „Aufladen der Batterie“ hinzugefügt. Dieses Auflade-Niveau ist wesentlich höher als der Energiepuffer im ersten Reichweitencheck anzusetzen und soll sich an der mittleren Länge von Kundenfahrten orientieren. Während der Puffer notwendig ist, um das Stranden von Fahrzeugen zu verhindern, ist das Auflade-Niveau dafür zuständig, dass die Fahrzeuge sich wieder aufladen, bevor sie wahrscheinlich keine Kundenfahrten mehr verrichten können. Im Allgemeinen wird diese Strategie wohl nicht optimal sein, weil bei gleichmäßiger Flottenbelastung Peaks in der Anzahl der Ladeprozesse entstehen werden. Für detaillierte Betrachtungen des Ladeaspekts bei elektrischen Flotten (unter anderem auch der Positionierung von Ladesäulen) wird auf Arbeiten von Jung et al. [15] und Kang et al. [16] verwiesen.

Weiter werden die Themen „Routing“ und Umgang mit Verspätungen („Delay-Management“) in dieser Arbeit sehr einfach behandelt. Es wird pro Fahrt einmal die kürzeste Route berechnet und zwar zum Zeitpunkt der Jobzuweisung. Die Reisezeiten entlang dieser Route werden zwar auf Basis aktueller Fahrzeugpositionen aktualisiert, aber es werden unterwegs keine Alternativrouten berechnet. Dies hat zur Folge, dass Flottenfahrzeuge Verkehrsstaus, die nach der Zuweisung der Fahraufgabe entstehen, nicht ausweichen. Dies kann wiederum zur Folge haben, dass Nachfolgekunden in diesen Fahrzeugen größere Wartezeiten haben, als sie eigentlich akzeptiert hätten. Es gibt nach Wissen des Autors kein typisches Standardvorgehen, wie damit umgegangen werden soll. Horn schlug für Taxiservices in zeitlich regelmäßigen Abständen eine globale Zuweisungsoptimierung vor, um diesem Phänomen entgegenzuwirken [17]. Eine andere mögliche Alternative, die vor allem bei geteilten Fahrten („Ridesharing“) sehr gut funktioniert, wurde von Alonso-Mora et al. aufgezeigt [18]: Kundenanfragen bekommen in einem globalen systemoptimalen Fahrzeugzuweisungs-verfahren innerhalb von 60 Sekunden eine Antwort, wann ihr spätester Abholzeitpunkt sein wird. Bevor ihr zugewiesenes Fahrzeug allerdings vor Ort ist, können sie in jedem späteren Optimierungsschritt einem anderen Fahrzeug zugewiesen werden, so lange dieses vor dem zuerst zugewiesenen Fahrzeug am Kundenstandort ist.

3.3 Schnittstellen zwischen dem Verkehrsmikrosimulator und dem Flottensteuerungsmodul

Die Schnittstellen, die zur Kommunikation zwischen Aimsun und dem SAEV-Modul notwendig sind, werden in Bild 3 schematisch dargestellt.

Bild 3: Schnittstellen zwischen dem Verkehrsmikrosimulator und dem SAEV-Modul. Die geklammerten Prozesse sind in dieser Arbeit nicht enthalten.

Die Simulationszeit wird durch Zeitschritte von 0,8 Sekunden von Aimsun gesteuert und das SAEV-Modul als API-Skript bei der Szenariendefinition in Aimsun aktiviert. Das Modul wird mit dem Beginn der Simulation initiiert. Dabei werden zum Beispiel die Startpositionen der Flottenfahrzeuge festgelegt und die künftigen Kundenanfragen im Speicher abgelegt. Sie werden für den Flottenbetreiber aber erst zum Zeitpunkt der Anfrage sichtbar.

Nach dem Eingang einer Kundenanfrage werden auf Basis aktueller Reisezeiten im Netzwerk die Fahraufgaben an Fahrzeuge zugewiesen. Die Aktualisierung der Streckenreisezeiten im Netzwerk wird in dieser Arbeit alle 5 Minuten vorgenommen. Die Flottenfahrzeuge sind nicht dauerhaft im System. Es wird immer dann, wenn eine Fahrt stattfinden soll, im Startzentroid ein Flottenfahrzeug erstellt, das zum Zielzentroid fährt.

Wenn ein Flottenfahrzeug unterwegs ist, meldet es immer beim Einfahren in einen neuen Streckenabschnitt seine Position. Dadurch kann die Abschätzung, wann das Fahrzeug wieder verfügbar ist, in regelmäßigen Abständen nachgeschärft werden. Bei großen Verzögerungen könnten an dieser Stelle Veränderungen an Routen und an Zuweisungen von Nachfolgejobs durchgeführt werden.

4 Alternative Simulationen ohne Verkehrsmikrosimulation

In den bisherigen Arbeiten zu autonomen Taxis wurden Reisezeiten meist auf Basis von angenommenen Geschwindigkeiten geschätzt oder aus Buchungsdaten abgeleitet. Flussund Geschwindigkeitsänderungen durch den motorisierten Individualverkehr oder den zusätzlich von der Flotte erzeugten Verkehr werden dabei vernachlässigt.

Um die Auswirkungen der Mikrosimulation auf die Flottenperformance zu untersuchen, werden wie in Tabelle 1 zusammengefasst zwei weitere Simulationsumgebungen für den Verkehr erstellt. In „NoMicroSim_75pc“ werden wie bei Burghout et al. [19] streckenabhängige, aber zeitlich konstante Reisezeiten verwendet, die sich ergeben, wenn mit 75% der maximal zulässigen Geschwindigkeit gefahren wird. Außerdem werden in der zweiten Vergleichssimulation zeitlich variable, streckenabhängige Reisezeiten verwendet. Diese werden im konkreten Fall aus dem Aimsun-Basismodell abgeleitet, indem alle 5 Minuten in der Simulation die durchschnittlichen Streckenreisezeiten ausgelesen werden. Diese Simulationen werden im folgenden „NoMicroSim_TT“ genannt.

Die gemittelten Streckenreisezeiten werden in allen drei Simulationsumgebungen verwendet, um Routenberechnungen und Aktualisierung von Fahrtdauern im SAEV-Modul durchzuführen. Die Verzögerungen, die durch das Warten an Kreuzungen auftreten, werden implizit mitbetrachtet, weil diese Zeit auf den jeweils letzten Stücken der Streckenabschnitte verbracht wird. Allerdings werden bei diesem Ansatz alle Fahrstreifen gleich behandelt.

Während sich die gemessenen Fahrtdauern als Ergebnis der Mikrosimulation ergeben, werden die Fahrten in den „NoMicroSim“-Umgebungen möglichst einfach dargestellt: bei einem Zeitschritt von 1,0 Sekunden wird die Fahrzeugposition immer dann aktualisiert, wenn laut berechneter (und bei neuer Netzwerkstatistik aktualisierter) Route eines Fahrzeugs der nächste Streckenabschnitt erreicht werden sollte.

Tabelle 1: Vergleich der Simulationsumgebungen.

5 Beschreibung der simulierten Szenarien

5.1 Allgemeines zu Verkehrsnachfragemodellen

Für die Simulationen des Betriebs ist es notwendig, die Kundenanfragen auf Basis sinnvoller Daten zu generieren. Da ein System mit autonomen Taxis in München noch nicht existiert, stehen keine realen Buchungsdaten zur Verfügung. Daher muss der Demand über Daten aus ähnlichen Systemen oder über ein Verkehrsnachfragemodell abgeschätzt werden.

Da ein SAEV-System eine Art Verschmelzung von Carsharing und Taxis darstellt, erscheinen Kundenfahrten aus diesen beiden Systemen als Datenbasis sinnvoll. Dies wurde zum Beispiel von Spieser et al. [20] mit Buchungsdaten von Carsharing Flotten in vier nordamerikanischen Städten und Alonso-Mora et al. [18] mit anonymisierten Kundenfahrten von Taxidiensten in New York genutzt. Beide Arbeiten stellen Potentialanalysen der Systeme dar und machen daher keine Abschätzungen, inwiefern die Automatisierung und der neue Mobilitätsdienst sich auf die Nachfrage auswirken.

Ohne verfügbare Buchungsdaten ist es der einfachste Ansatz, irgendwelche Fahrten ohne Datenbasis frei anzunehmen [8]. Die nächste Komplexitätsstufe ist eine zufällige Auswahl von Fahrten aus einem kalibrierten Verkehrsmodell. Zum Beispiel wählen Fagnant et al. [21] zufällig 1,3% der Fahrten aus ihrem Verkehrsmodell von Austin in Texas aus. Eine weitere Verbesserung wäre die Darstellung verschiedener Verkehrsmodi in einem Modell und eine Funktionalität, die Fahrten je nach Sinnhaftigkeit und möglichst realer Wahrscheinlichkeit den verschiedenen Modi zuweist und im optimalen Fall auch multimodale Ansätze zulässt. Dies ist insofern interessant, weil die hier untersuchten Robotertaxis eventuell auch als „Last-MileLösung“ verwendet werden können. Für weitere Details zu diesem Thema wird auf die Fachliteratur verwiesen, zum Beispiel auf die Arbeit von Friedrich und Noekel über eine multimodale Einbindung von Sharing-Systemen in Verkehrsnachfragemodelle [22] oder auf die Nachfragegenerierung eines autonomes Carsharing System in Austin mit MatSim von Liu et al [23].

5.2 Simulierte Szenarien

Da die PTV Validate Matrizen bereits den gesamten heute existierenden Straßenverkehr abbilden, werden diese als Grundlage für die Nachfrage an dem Robotertaxisystem verwendet. Um die verkehrlichen Auswirkungen der Flotte zu untersuchen, wird ein Teil des bisherigen Verkehrs von privaten Fahrzeugen auf die Flotte verlagert.

Die Erstellung der Nachfrage und die Modifikationen an den Quelle-Ziel-Matrizen (O/DMatrizen) des motorisierten Individualverkehrs (mIV) sind schematisch in Bild 4 dargestellt. Es wird angenommen, dass das SAEV System nur ein begrenztes Geschäftsgebiet hat und nur Binnenfahrten (Fahrten, die im Untersuchungsgebiet starten und enden) bedient werden.

Für diese Arbeit wird angenommen, dass 10% des bisherigen PKW-Binnenverkehrs durch die Einführung des Robotertaxisystems entfallen wird und die Basis für mögliche SAEVAnfragen bildet. Die restlichen 90% des PKW-Binnenverkehrs zusammen mit den unveränderten Matrixeinträgen der Einpendler, Auspendler und des Transitverkehrs bilden den modifizierten mIV ab.

Bild 4: Erstellung der mIV O/D Matrizen und der Nachfrage an das Robotertaxisystem für die simulierten Szenarien.

Ausgehend von der SAEV-Basisnachfrage werden sechs Szenarien (50-100) untersucht, indem zwischen 50 und 100% dieser Matrixeinträge auf naheliegende SAEV-Zentroide projiziert werden. Anschließend werden mit diesen Werten als Erwartungswert zeitlich poissonverteilte Kundenanfragen erstellt. Dieser Vorgang wird für jede Zeitscheibe und mit 3 verschiedenen Startwerten für Zufallszahlen je Szenario wiederholt, um die finalen Datensets mit Kundenanfragen zu erhalten.

Im Szenario 100 ersetzt jede mit dem Robotertaxi zurückgelegte Fahrt eine Fahrt mit dem privaten Fahrzeug, während die niedrigeren Niveaus eine Veränderung im Mobilitätsverhalten darstellen. Im Szenario 50 ersetzt eine Fahrt mit dem Robotertaxi zwei bisherige Fahrten mit dem privaten Fahrzeug. Dies bedeutet implizit, dass die zweite Fahrt mit dem ÖV, dem Fahrrad oder zu Fuß zurückgelegt wird.

Eine Studie von Elliot und Shaheen [24] über car2go Mitglieder in vier Städten in den USA zeigt, dass viele Mitglieder ihr Mobilitätsverhalten nur geringfügig ändern. Nur ein geringer Teil der Mitglieder schaffen ihr Fahrzeug ab oder unterlassen den Neukauf aufgrund der Carsharing Mitgliedschaft. Aber genau diese Menschen haben einen sehr großen Einfluss auf die auf der Straße zurückgelegten Kilometer. In ihrer als pessimistisch angegeben Schätzung ersetzt ein im Carsharing Fahrzeug zurückgelegter Kilometer zwischen 1,2 (Vancouver) und 4 (San Diego) in privaten Fahrzeugen zurückgelegte Kilometer.

Die Wahl von 10% des gesamten Binnen-PKW-Verkehrs als SAEV-Nachfrage erscheint im Vergleich zu heutigen Carsharing-Zahlen sehr hoch gegriffen. Alleine im Zeitraum von 5 bis 11 Uhr sind dies ungefähr 40 000 Fahrten. Da aber der Einfluss der Flotte auf den restlichen Verkehr mit steigender Fahrtenzahl zunimmt und dies die erste Untersuchung dieser Art ist, wurde diese Annahme getroffen. Die dazu benötigte Flottengröße wird für gewöhnlich anhand der Flottenperformance und der Kosten optimiert. In dieser Arbeit wird ohne einen Optimierungsprozess die Annahme getroffen, dass ein Fahrzeug 10 private Fahrzeuge ersetzen soll und jedes private Fahrzeug nur eine Fahrt im Zeitraum von 5 bis 11 Uhr zurücklegt (siehe Tabelle 2).

Tabelle 2: Skalierung von Nachfrage und Fahrzeugflotte in den Szenarien.

Der zeitliche Verlauf der Datensets der Szenarien 50 und 100 sind in Bild 5 dargestellt. Der statistische Charakter der durch Poissonprozesse erstellten Datensets wird ersichtlich. Von sehr wenigen Nachfragen gegen 5 Uhr wird die Morgenspitze gegen 8 Uhr erreicht und bleibt bis circa 9 Uhr auf einem konstanten Niveau, bevor die Anzahl der Anfragen wieder leicht abnimmt.

Bild 5: Zeitliche Verteilung der Nachfragen. Erstellt über Poissonverteilungen je 15 Minuten Zeitintervall und O/D-Matrixeintrag. Gemittelt über die 3 Datensets für Nachfrageniveaus der Szenarien 50 (dunkelblau) und 100 (hellblau).

In dieser Arbeit wird weiter angenommen, dass Kunden geschätzte Ankunftszeiten von Flottenfahrzeugen von bis zu 10 Minuten akzeptieren. In Realität ist dieser Parameter keine Konstante. An sich ist sie nicht einmal bei einem einzelnen Menschen konstant. Es hängt davon ab, welche alternativen Verkehrsmodi zur Verfügung stehen, wie die generellen Einstellungen gegenüber diesen Modi sind, wie hoch die Kosten ausfallen, sowie von vielen weiteren Parametern. Die 10 Minuten sind vergleichsweise groß gewählt, weil möglichst viele der Kundenanfragen vom Robotertaxisystem übernommen werden sollen. Für einen Vergleich der Simulationsumgebungen genügt diese einfache Modellierung ebenfalls.

Zusätzlich müssen noch Fahrzeugparameter festgelegt werden. Die Flotte besteht in dieser Untersuchung aus rein elektrisch angetriebenen Fahrzeugen, deren Batterien jeweils 27.2 kWh Energie speichern und damit eine Reichweite von 200 km zurücklegen können. Das Energieverbrauchsmodell wurde möglichst einfach gehalten und ist rein distanzabhängig.

Zur Bestimmung der Anfangspositionen der Flotte wurde das Gebiet in mehrere Teilgebiete aufgeteilt und die Fahrzeuge nach einer Anfragenschätzung der ersten zwei Stunden auf diese Gebiete verteilt.

6 Simulationsergebnisse

Die für die Verkehrsmikrosimulation benötigten Rechenzeiten sind von der vorhandenen Hardware abhängig. Das SAEV-Modul selbst verhält sich bezüglich der Rechenzeit additiv, d.h. ausgehend von der Rechenzeit für das Basismodell kamen zwischen 2,5 (Szenario 50) und 4,5 (Szenario 100) Stunden für die Berechnung der Flottenoperationen hinzu. Diese Zeiten entsprechen auch den Rechenzeiten für die alternativen Simulationsumgebungen.

Die Flottenperformance wird vorwiegend anhand der durchschnittlichen Kundenwartezeiten gemessen. Da Anfragen, die aufgrund zu langer erwarteter Kundenwartezeiten nicht von der Flotte abgedeckt werden, die Anzahl der verfügbaren Fahrzeuge nicht senken und damit zu kleineren Wartezeiten für die restlichen Kunden führen, ist es sinnvoll, die nicht bedienten Anfragen mit einer „Strafzeit“ zu belegen und mit in die Auswertung der durchschnittlichen Wartezeiten einfließen zu lassen. Diese Logik veranlasste Jung et al. in [15] auch zur Einführung einer Strafzeit bei ihrem Algorithmus zur Fahrzeugzuweisung, der auf einer Optimierung der Wartezeit basiert.

Im Weiteren werden drei verschiedene Wartezeiten unterschieden. Die „geschätzte Wartezeit“ wird durch den Flottenbetreiber bei der Bestimmung des (dynamisch) optimalen Fahrzeugs berechnet und ist entscheidend, ob ein Kunde die Flotte benutzt oder nicht. Die „reale“ oder auch „gemessene Wartezeit“ existiert nur für Anfragen, die von der Flotte bedient werden. Sie ist die in der Simulation tatsächlich gemessene Wartezeit, also die Zeit, die zwischen Anfrage und Ankunft des Flottenfahrzeugs vergehen. Die „effektive Wartezeit“ ist für alle bedienten Kunden gleich der realen Wartezeit, aber für die nicht bedienten Anfragen die Strafzeit, die hier auf 20 Minuten gesetzt wird.

6.1 Vergleich der simulierten Szenarien mit mikroskopischem Verkehrsflussmodell

Bei der Auswertung der Flottenperformance für die verschiedenen Szenarien ist zu erwarten, dass das gleiche Verhältnis zwischen Nachfrage und Anzahl an Flottenfahrzeugen zumindest zu ähnlichen Ergebnissen führt. In Bild 6 ist ersichtlich, dass die stündlichen effektiven Wartezeiten bis ungefähr 8 Uhr nahezu identisch sind, dann zwar noch ähnliche Verläufe besitzen, aber Unterschiede von bis zu circa 1 Minute aufweisen. Bis 7 Uhr werden praktisch alle Anfragen bedient und es kommt auch zu keinen Verzögerungen, so dass in diesem Zeitraum geschätzte, gemessene und effektive Wartezeit alle bei einem sehr niedrigen Wert von 2 Minuten liegen.

Im Vergleich zur zeitlichen Nachfragekurve (Bild 5) ist der Peak der effektiven Wartezeit später. Dies kann zum einen damit begründet werden, dass eine bediente Anfrage die Flotte nicht nur zum Zeitpunkt der Buchung beeinflusst. Ein Fahrzeug ist in den simulierten Szenarien durch eine Kundenbuchung im Schnitt circa 21 Minuten belegt. Außerdem wirken sich Verzögerungen wegen des fehlenden Delay-Managements in dieser Arbeit auf spätere, zum Zeitpunkt der Verzögerung bereits zugewiesene, Fahrten eines Flottenfahrzeugs aus. Dass verkehrsbedingte Verspätungen auftreten, ist daran zu sehen, dass die geschätzten Wartezeiten auch zwischen 8 und 11 Uhr bei allen Szenarien sehr ähnlich und unter 5,5 Minuten bleiben, die gemessenen Wartezeiten aber auf 7-8 Minuten (8-9 Uhr in der Simulation), 7,5-9 Minuten (9-10 Uhr in der Simulation) und 6-7,5 Minuten (10-11 Uhr in der Simulation) ansteigen.

Bild 6: Stündlich gemittelte effektive Wartezeiten für die verschiedenen Szenarien in der Aimsun Simulationsumgebung.

Geringere Geschwindigkeiten der Flottenfahrzeuge und höhere durchschnittliche Verzögerungen aller Fahrzeuge im Netzwerk wirken sich mehrfach auf die effektiven Wartezeiten aus. Einerseits steigen die gemessenen Kundenwartezeiten an, andererseits steigen wegen der höheren geschätzten Reisezeiten auch die Anteile der nicht bedienten Anfragen und damit die aufgebrachten Strafminuten.

Die Unterschiede zwischen den verschiedenen Szenarien sind dabei allerdings relativ gering (siehe Tabelle 3). Die Standardabweichungen der Verzögerungen im Netzwerk stellt die Streuung zwischen den Szenarien dar. Die zeitliche und räumliche Streuung der Verzögerungen in einem Szenario ist im Vergleich zur Streuung der Mittelwerte der Szenarien viel größer. Die Streuung der gemessenen Verzögerungen aller Fahrten ist für die einzelnen Szenarien um ein Vielfaches größer als der Mittelwert. Dies deutet darauf hin, dass Fahrzeuge entweder praktisch keine oder viel mehr Zeit als die angegebene mittlere Verzögerung verlieren. Eine zeitliche Analyse zeigt, dass die Verzögerungen ab 7:30 Uhr stark ansteigen und erst gegen 9:30 ihr Maximum erreichen, also deutlich nach dem Maximum des Zuflusses im Netzwerk. Das Maximum der örtlich gemittelten Verzögerung liegt bei Szenario 50 ungefähr bei 98 Sekunden pro Kilometer, beim Szenario 100 bei 108 Sekunden pro Kilometer.

Ein weiteres Resultat der Simulationen ist, dass der Anteil an Leerfahrten mit steigender Nachfrage und Flottengröße sinkt. Der Grund dafür ist eine bessere Abdeckung des Gebiets mit Fahrzeugen. Die Wahrscheinlichkeit, dass ein Fahrzeug in unmittelbarer Nähe einer Kundenanfrage ist, steigt mit der Fahrzeugzahl.

Weiterhin ist trotz in den Szenarien gleicher O/D-Matrizen für den PKW-Verkehr ein Anstieg der im Netzwerk zurückgelegten Strecke von privaten Fahrzeugen erkennbar. Die Anzahl der nicht bedienten Anfragen steigt und diese fahren in dem hier beschriebenen Modell ebenfalls mit dem PKW. Die entsprechenden Strecken bei Simulation ohne Robotertaxis sind 7,95 Millionen Kilometer bei der Verwendung der Ursprungsmatrizen und 7,60 Millionen Kilometer bei den im Untersuchungsgebiet reduzierten Matrizen. In dieser Arbeit werden also maximal 4,4% der gefahrenen Kilometer durch Fahrten mit dem Robotertaxi ersetzt.

Unter den Annahmen einer Flottenzusammensetzung von ungefähr 2/3 Benziner und 1/3 Dieselfahrzeugen [25], von Lebenszyklen abgeleiteten pro-km-CO2-Äquivalenzwerten aus [26], Strom für die Elektrofahrzeuge aus erneuerbaren Quellen und einer Vernachlässigung der Treibhausgase durch die implizit gewählten alternativen Verkehrsmodi, ergeben sich Treibhausgaseinsparungen zwischen 2,0% (Szenario 100) und 3,0% (Szenario 50). Dies entspricht Einsparungen von 42 bis 61 Tonnen CO2-äquivalenter Emissionen im Untersuchungsgebiet während des Zeitraums von 5 bis 11 Uhr.

Tabelle 3: Vergleich von über den gesamten Simulationszeitraum aggregierten Mittelwerten (und Standardabweichungen) der in Aimsun simulierten Szenarien.

6.2 Vergleich der drei Simulationsumgebungen

Zuerst werden wieder die Wartezeiten analysiert. In Bild 7 ist zu sehen, dass ein konstantes Nachfrage-zu-Fahrzeug Verhältnis ohne Mikrosimulation für verschiedene Nachfrageniveaus zu nahezu gleichen Wartezeiten führt, weil der durch die Flotte induzierte Verkehr keine Auswirkungen auf Reisezeiten hat.

Die mittleren geschätzten Wartezeiten sind bei den NoMicroSim_TT Szenarien und der Mikrosimulation sehr ähnlich, während sie bei NoMicroSim_75pc Szenarien ungefähr 20% darunter liegen. Dies liegt wie erwartet an den Verkehrsspitzenzeiten, in denen die Reisezeiten deutlich von den Reisezeiten bei Freifahrt abweichen und dadurch die Flottenperformance verschlechtern (siehe Bild 8).

 Bild 7: Über den Simulationszeitraum gemittelte Wartezeiten für die verschiedenen Szenarien in den verschiedenen Simulationsumgebungen.

 Bild 8: Zeitliche Abhängigkeit der über alle Szenarien gemittelten effektiven Wartezeiten in den verschiedenen Simulationsumgebungen.

Da die abgeschätzten Wartezeiten auch für die Anzahl der nicht bedienten Anfragen verantwortlich sind, sind die mittleren zusätzlichen Strafminuten durch nicht erfüllte Kundenanfragen bei NoMicroSim_TT und Aimsun praktisch gleich, während sie in der NoMicroSim_75pc Umgebung deutlich darunter liegen. Grundsätzlich scheint die Flotte für die betrachtete Nachfrage jeweils etwas zu klein zu sein, allerdings könnte sich dies durch die Verwendung einer Reallokationsstrategie noch ändern.

Durch die zeitlich konstanten Reisezeiten sind zudem bei den NoMicroSim_75pc Szenarien die geschätzten und gemessenen Kundewartezeiten praktisch identisch. Ähnlich verhält es sich bei den NoMicroSim_TT Szenarien. Allerdings werden die Fahrtdauern bei einem Update der Reisezeiten im Netzwerk aktualisiert. Wegen des mit der Zeit tendenziell steigenden Verkehrsaufkommens sind die gemessenen Wartezeiten mit durchschnittlich ungefähr 20 Sekunden etwas höher als die geschätzten.

Dagegen ist der Unterschied in den Aimsun Szenarien mit 1,6 bis 2,0 Minuten deutlich größer. Für diesen großen Unterschied sind einerseits seit der letzten Aktualisierung der Reisezeiten neu gestaute Streckenabschnitte zuständig. Andererseits sind durch die Schaltungen von Lichtsignalanlagen und speziell für abbiegende Fahrzeuge große Unterschiede zwischen gemittelten und tatsächlichen Reisezeiten möglich. Diese große Differenz zwischen geschätzter und gemessener Zeit zeigt die Schwäche des verwendeten Reisezeit-Prognosemodells im städtischen Bereich auf. Bei Mittelung über alle Fahrstreifen und 5 Minuten stimmen geschätzte Reisezeiten mit der konkreten Reisezeit eines einzelnen Fahrzeugs, das an der nächsten Kreuzung links abbiegen will, in der Regel nicht überein.

Die durchschnittlich gemessenen Geschwindigkeiten der Flottenfahrzeuge betragen 38 km/h (NoMicroSim_75pc), 28 km/h (NoMicroSim_TT) und 25 km/h (Aimsun). Dass der Unterschied zwischen den gemessenen Wartezeiten von den Aimsun und NoMicroSim_TT Szenarien trotz ähnlichener Geschwindigkeiten größer ist als zwischen den NoMicroSim Szenarien untereinander, zeigt die Wichtigkeit eines besseren Prognosemodells und eines Delay-Managements.

Bild 9: Über alle Szenarien gemittelte Flottenauslastung pro Minute in den verschiedenen Simulationsumgebungen.

Das Verhältnis der Geschwindigkeitsunterschiede spiegelt sich dagegen in der Flottennutzung deutlicher wider (siehe Bild 9). Die Auslastung des SAEV-Systems wird bei NoMicroSim_75pc mit unter 60% deutlich unterschätzt. Das System befindet sich noch in einem tendenziell unkritischen Zustand und die Auslastung folgt der Demandkurve, während bei den NoMicroSim_TT und den Aimsun Szenarien die Flotte deutlich stärker ausgelastet ist.

7 Zusammenfassung und abschließende Kommentare

Der Vergleich der Simulationsumgebungen ergibt, dass bei agentenbasierten Simulationen zur Flottensteuerung von Robotertaxi-Systemen eine Verwendung von zeitlich konstanten Reisezeiten wie bei Burghout et al. [19] die Gefahr birgt, die verkehrliche Auswirkung der Spitzenzeit deutlich zu unterschätzen. Zudem wird ersichtlich, dass in der Mikrosimulation (wie auch in Realität zu erwarten ist) Linksabbiegereffekte und neu auftretende Stauungen zu Reisezeitverzögerungen führen können, die explizit behandelt werden müssen. Kunden wären mit dem Ergebnis, dass sie durchschnittlich 2 Minuten länger warten müssten, als mit dem Betreiber vereinbart wurde, sehr unzufrieden.

Die Reisezeit-Verzögerungen im gesamten Netzwerk steigen trotz der induzierten Leerfahrten bei einer 1-zu-1 Ersetzung von 10% des gesamten PKW-Verkehrs, der sowohl Start und Ziel innerhalb der A99 in München hat, nur geringfügig an. Dies steht nicht im Gegensatz zur Aussage von gleichbleibenden Reisezeiten von Rossi et al. in [12]. Bei ihrer Arbeit deckte die Flotte den kompletten Verkehr ab, es wurde explizit ein Augenmerk auf Routing gelegt und zudem ist das Münchner Netzwerk nicht symmetrisch, wie es für ihren Beweis gefordert ist.

Zudem wurde berechnet, dass sich die Gesamtverzögerungen bereits reduzieren, sobald die Fahrten nicht 1-zu-1 ersetzt werden, sondern ein Teil (hier: 20% 50%) der ersetzten Fahrten durch andere Verkehrsmodi abgedeckt wird. Allen voran könnte dies der öffentliche Verkehr sein, der die dementsprechenden Kapazitäten liefern muss. Dass Carsharing die Gesamtzahl der Fahrten reduzieren kann, ist für Carsharing Nutzer in [24] gezeigt worden. Wegen des ähnlichen Betriebskonzepts kann auch für Robotertaxis davon ausgegangen werden.

Die Verwendung einer elektrischen Flotte sorgt im Vergleich zu privaten Fahrzeugen mit gewöhnlichem Antrieb in den simulierten Szenarien dafür, dass trotz der zusätzlichen Leerfahrten, die im Bereich von 10% der gesamten von der Flotte zurückgelegten Strecken liegen, Treibhausgase um 2-3% reduziert werden können.

Leider sind die in dieser Arbeit dargestellten Ergebnisse des Robotertaxisystems in der Stadt München nur unter sehr starken Annahmen entstanden:

·  Allen voran ist das Nachfragemodell viel zu simpel. Deshalb zeigen die Ergebnisse nur Tendenzen auf. Eine sinnvolle Abschätzung des künftigen Modalsplits und der zeitlichen und lokalen Verteilung von Anfragen an ein Robotertaxi-System ist allerdings eine sehr schwere Aufgabe. Es handelt sich um ein noch nicht vorhandenes System und die Akzeptanz und Verwendung ist noch fraglich.

·  Der Flottenbetrieb ist hier möglichst einfach gehalten. Der FahrzeugZuweisungsalgorithmus ist dynamisch und liefert für jeden Kunden möglichst schnell Informationen, wann das für ihn optimale Fahrzeug zur Verfügung steht. Dadurch wird jedoch global gesehen nicht die optimale Flottenverwendung erzeugt. Zusammen mit dem fehlenden Delay-Management wird dies vor allem bei Verzögerungen im Netzwerk spürbar. Da es nach Wissen der Autoren keine eindeutigen Lösungen für Reallokationsund Ladestrategien gibt, wurden diese ebenfalls nicht implementiert, um eine größere Allgemeinheit zu gewährleisten.

Der Beitrag dieser Arbeit ist vorwiegend die Demonstration einer autonomen Taxiflotte in einem mikroskopischen Verkehrsflussmodell einer Großstadt wie München. Die Verwendung eines Mikrosimulators für eine Betrachtung des Flottenbetriebs empfiehlt sich für die zwei bisher in der Forschung wenig beachteten Themen Delay-Management und Auswirkungen auf den Stadtverkehr. Dagegen sollte es (vor allem aus Zeitgründen) genügen, die anderen den Betrieb betreffenden Strategien (Flottengröße, Reallokationsstrategie, Ladestrategie, Positionierung der Ladesäulen, etc.) wie bisher auch ohne Mikrosimulator auszulegen.

8 Literaturverzeichnis

[1] [Online]. Available: https://www.abiresearch.com/market-research/product/1025509-ridesharing-galore-here-come-the-car-oems/. [Zugriff am 26 Juli 2016].

[2] nuTonomy. [Online]. Available: http://nutonomy.com/press.html. [Zugriff am 11 Januar 2017].

[3] L. Burns, W. Jordan und B. Scarborough, „Transforming Personal Mobility,“ The Earth Institute, 2013.

[4] D. Fagnant und K. Kockelman, „The travel and environmental implications of shared autonomous vehicles, using agent-based model scenarios,“ Transportation Research Part C: Emerging Technologies, Nr. vol. 40, pp. 1-13, 2014.

[5] A. Santos, N. McGucking, Y. Nakamoto, D. Gray und S. Liss, „Summary of Travel Trends: 2009 National Household Travel Survey,“ Federal Highway Administration Report #FHWA-PL-11-022, 2011.

[6] M. F. A. Chester, J. Matute, C. Flower und R. Pendyala, „Parking Infrastructure: A Constraint on or Opportunity for Urban Redevelopment? A Study of Los Angeles County Parking Supply and Growth,“ Journal of the American Planning Association, Nr. 81:4, pp. 268-286,, 2015.

[7] International Transport Forum, „Urban Mobility System Upgrade: How Shared Self-Driving Cars Could Change City Traffic,“ OECD Corporate Partnership, 2015.

[8] T. Chen, K. Kockelman und J. Hanna, „Operations of a Shared Autonomous Electric Vehicle Fleet: Implications of Vehicle & Charging Infrastructure Decisions,“ Presented at the 95th annual meeting of the Transportation Research Board, 2016.

[9] S. Weikl und K. Bogenberger, „Relocation Strategies and Algorithms for Free-Floating Carsharing Systems,“ IEEE Intelligent Transportation Systems, Nr. 4, pp. 100-111, 2013.

[10] K. Spieser, S. Samaranayake, W. Gruel und E. Frazzoli, „Shared-Vehicle Mobility-on-Demand System: Fleet Operator's Guide to Rebalancing Empty Vehicles,“ Presented at the 95th annual meeting of the Transportation Research Board, 2016.

[11] M. Levin, L. Tianxin, S. Boyles und K. Kockelman, „A general framework for modeling shared autonomous vehicles,“ Presented at the 95th annual meeting of the Transportation Research Board, 2016.

[12] F. Rossi, R. Zhang und M. Pavone, „Autonomous Vehicle Routing in Congested Road Networks,“ in preperation for journal submission, 2016.

[13] MVG, „MVG in Zahlen,“ August 2016. [Online]. Available: https://www.mvg.de/dam/mvg/ueber/unternehmensprofil/mvg_in_zahlen_s. [Zugriff am 28 September 2016].

[14] „http://lemnet.org/de,“ [Online]. [Zugriff am 16 März 2016].

[15] J. Jung, J. Y. Chow, R. Jayakrishnan und Y. Ji, „Stochastic dynamic itinerary interception refueling location problem with queue delay for electric taxi charging stations,“ Transportation Research Part C: Emerging Technologies, Nr. 40, pp. 123-142, 2014.

[16] N. Kang, F. M. Feinberg und P. Y. Papalambros, „Autonomous Electric Vehicle Sharing System Design“.ASME 2015 International Design Engineering Technical Conferences and Computers andInformation in Engineering Conference.

[17] M. E. Horn, „Fleet scheduling and dispatching for demand-responsive passenger services,“ Transportation Research Part C: Emerging Technologies, Nr. 10, pp. 35-63, 2002.

[18] J. Alonso-Mora, S. Samaranayake, A. Wallar, E. Frazzoli und D. Rus, „On-demand high-capacity ride-sharing via dynamic trip-vehicle assignment,“ PNAS, 2017.

[19] W. Burghout, P.-J. Rigole und I. Andreasson, „Impacts of Shared Autonomous Taxis in a Metropolitan Area,“ Presented at the 94th annual meeting of the Transportation Research Board, 2015.

[20] K. Spieser, K. Treleaven, R. Zhang, E. Frazzoli, D. Morton and M. Pavone, "Singapore, Toward a Systematic Approach to the Design and Evaluation of Automated Mobility-on-Demand Systems: A Case Study in," in Road Vehicle Automation, 2014, p. 229–245.

[21] D. Fagnant, K. Kockelman and P. Bansal, "Operations of Shared Autonomous Vehicle Fleet for Austin, Texas, Market," Transportation Research Record: Journal of the Transportation Research Board, no. 2536, p. 98–106, 2015.

[22] M. Friedrich und K. Noekel, „Modeling intermodal Networks with Public Transport and Vehicle Sharing Systems,“ Presented at the 94th annual meeting of the Transportation Research Board, 2015.

[23] L. Jun, K. Kockelman, P. Boesch und F. Ciari, „Tracking a System of Shared Autonomous Vehicles Across The Austin, Texas Network Using Agent-Based Simulation,“ Presented at the 96th annual meeting of the Transportation Research Board, 2017.

[24] M. Elliot und S. Shaheen, „Impacts of car2go on Vehicle Ownership, Modal Shift, Vehicle Miles Traveled, and Greenhouse Gas Emissions: An Analysis of Five North American Cities,“ [Online]. Available: http://innovativemobility.org/. [Zugriff am 15 Juli 2016].

[25] Kraftfahrbundesamt. [Online]. Available: http://www.kba.de/DE/Statistik/Fahrzeuge/Bestand/Umwelt/b_umwelt_z.html. [Zugriff am 12 Januar 2017].

[26] Umweltbundesamt, „Weiterentwicklung und vertiefte Analyse der Umweltbilanz von Elektrofahrzeugen,“ [Online]. Available: http://www.umweltbundesamt.de/publikationen/weiterentwicklung-vertiefte-analyse-der. [Zugriff am 16 Dezember 2016].