Autonomes Fahren ist eines der wichtigsten Zukunftsthemen. Auch die Technische Universität München ist mit einer selbst entwickelten Künstlichen Intelligenz (KI) in diesem Bereich aktiv und hat sich 2018 im Wettrennen für autonome Fahrzeuge "Roborace" den ersten Platz gesichert. Projektmitarbeiter Leonhard Hermansdorfer spricht im Interview über die Herausforderungen, Deep Learning und ehtisch korrekte Entscheidungen von Maschinen.

Dieser Beitrag ist zuerst in eMobilJournal 01/2019 erschienen.

Sieben Nachwuchswissenschaftler der Technischen Universität München (TUM) haben eine Software für autonom fahrende Fahrzeuge entwickelt. Mit der Künstlichen Intelligenz (KI) sicherten sich die Forscher im Mai 2018 den ersten Platz beim Wettrennen für autonome Fahrzeuge „Roborace“ in Berlin. Dabei traten ein menschlicher Fahrer und die Künstliche Intelligenz der TUM und der Universität Pisa gegeneinander an. Mit der kumulierten Bestzeit von Mensch und Maschine fuhren die Münchner den Sieg ein. Welche Erkenntnisse lassen sich daraus für die Autos der Zukunft gewinnen? Leonhard Hermansdorfer vom Lehrstuhl für Fahrzeugtechnik der TUM ist wissenschaftlicher Mitarbeiter im Projekt und gibt im eMobilJournal-Interview spannende Einblicke in das Themenfeld „Autonomes Fahren“.

Herr Hermansdorfer, Glückwunsch zum ers­ten Platz beim Roborace. Wie optimistisch waren Sie und Ihre Kollegen, dass es klap­pen könnte?

Vielen Dank. Das ganze Team stand von Anfang an unter großem Druck, da das Projekt bei uns am Lehr­stuhl erst knapp ein Jahr vor dem Berlin-Event ins Leben gerufen wurde. Hinzu kommt, dass das Projekt und das gesetzte Ziel viele Unbekannte mit sich brachte. Wir konnten weder auf bisherige Erfahrungswerte, noch auf wissenschaftliche Arbeiten genau auf diesem Gebiet zurückgreifen. Untersuchungen zum automatisierten Fahren am fahrdynamischen Limit für den Einsatz in einem Rennszenario gibt es bisher sehr wenige und es war von Anfang an ein hohes Maß an Ideenreichtum notwendig.

Wir waren uns der Komplexität des Forschungsvorha­bens durchaus bewusst und dennoch optimistisch, dass wir bis zum Event in Berlin eine funktionierende Soft­ware entwickeln können. Die Entwicklungsphase war natürlich von Höhen und Tiefen geprägt, wir hatten jedoch nie das Gefühl, dass wir nicht rechtzeitig fertig werden würden und nicht teilnehmen könnten. Durch eine Vielzahl an Simulationen und einige Test-tage mit dem Realfahrzeug war uns bereits im Voraus klar, dass wir ein funktionierendes Software-Paket ent­wickelt hatten. Dennoch bestanden viele Unsicherhei­ten, die wir bis zum Rennwochenende in Berlin nicht hundertprozentig lösen konnten. Aus diesem Grund war selbst nach den erfolgreichen Tests noch lange nicht alles in trockenen Tüchern und die Anspannung groß, vor allem, weil es der erste Einsatz unserer Software vor so großem Publikum war.

Letztendlich können wir zufrieden feststellen, dass wir unser Minimalziel, eine funktionierende Basis-Soft­ware zu entwickeln, weit übertroffen haben und unse­rem Maximalziel, als Schnellster aller vier Teilnehmer, das heißt auch schneller als beide menschliche Fahrer abzuschließen, sehr nahegekommen sind.

Das Roborace-Team der TUM (v.l.): Felix Nobis, Leonhard Hermansdorfer, Alexander Wischnewski, Johannes Betz, Tim Stahl, Alexander Heilmeier (Quelle: Roborace)

Können Sie kurz beschreiben, wie Ihre Soft­ware funktioniert und wie lange die Ent­wicklung gedauert hat?

Die Struktur der Software baut auf den drei Säulen Per­ception, Planning und Control auf. Die Software befin­det sich in ständiger Weiterentwicklung, wobei ich hier auf die wichtigsten Funktionen der jeweiligen Module eingehen will – diese sind bereits umgesetzt, in Entwick­lung oder geplant. Das Perception-Modul stellt die Schnittstelle zur Um­welt dar. In diesem werden die Signale, die die Senso­ren erfassen, aufbereitet und zur Weiterverarbeitung zur Verfügung gestellt. Zum Einsatz kommt eine Vielzahl an unterschiedlichen Senso­ren, darunter Kamera, Lidar, Radar, Ultraschall, dGPS und Beschleunigungssensoren.

Eine weitere Aufgabe des Perception-Moduls ist es, eine Karte der Umgebung zu erstellen und sich während der Fahrt mithilfe dieser Karte im Raum zu lokalisieren. Das geschieht unter Ein­bezug der gesamten zur Verfügung stehenden Sensorik. Außerdem ist das Perception-Modul dafür zuständig, statische und dynamische Hindernisse (andere Renn­fahrzeuge) zu detektieren, und im Falle von dynami­schen Objekten deren Bewegung vorherzusagen. Zusammenfassend beantwortet das Perception-Modul für uns die Frage, wo wir uns auf der Strecke befinden und was im Umfeld unseres Fahrzeugs passiert bzw. wahrscheinlich passieren wird.

Das Planning-Modul greift die Informationen des Perception-Moduls unmittelbar auf. In diesem werden auf Grundlage der vorliegenden Informationen über die aktuelle sowie die vorhergesagte zukünftige Situation Aktionen geplant, die unser Fahrzeug durchführen soll. Die Auswahl der Aktionen geschieht immer im Hinblick auf die hinterlegte Rennstrategie mit dem Hauptziel, das Rennen

Das Planning-Modul greift die Informationen des Perception-Moduls unmittelbar auf. In diesem werden auf Grundlage der vorliegenden Informationen über die aktuelle sowie die vorhergesagte zukünftige Situation Aktionen geplant, die unser Fahrzeug durchführen soll. Die Auswahl der Aktionen geschieht immer im Hinblick auf die hinterlegte Rennstrategie mit dem Hauptziel, das Rennen so schnell wie möglich zu beenden. In diesem Modul arbeiten wir mit verschiedenen Me­thoden der Künstlichen Intelligenz, um die Entschei­dungen anhand der zur Verfügung stehenden Daten und unter Berücksichtigung der gemachten Erfahrungen zu treffen. Das ist für uns ein wichtigter Schritt, da wir wäh­rend eines Rennens keinen Zu­griff auf das Fahrzeug haben.

Das bedeutet also, dass das Fahrzeug selbst die „Rennin­telligenz“ besitzen muss, um die richtigen Entscheidungen, sowohl kurz- als auch langfristig, zu treffen. Output des Moduls ist die Wunsch-Trajektorie, die das Fahrzeug im nächsten Zeitschritt fahren soll. Das Control-Modul ist als letzte Instanz dafür zu­ständig, die berechnete Aktion bzw. die Trajektorie des Planning-Moduls umzusetzen. Das bedeutet, die Akto­ren Lenkung, Elektromaschinen und mechanische Brem­sen so anzusteuern, dass das Fahrzeug die vorgegebene Aktion umsetzt, also beispielsweise der geplanten Ideal­linie folgt. Das beinhaltet auch, auf Störungen und Ab­weichungen vom geplanten Fahrweg zu reagieren und korrigierend einzugreifen.

Mit der Software-Entwicklung begonnen wurde erst im Dezember 2017, parallel dazu wurden seit Herbst 2017 weitere Teammitglieder angeworben. Das Team war erst im Laufe des Frühjahrs 2018 komplett. Die bis­herige Entwicklungsdauer kann also auf ca. ein halbes bis dreiviertel Jahr beziffert werden. Der in Berlin verwendete Software-Stand dient jetzt als Basis für alle weiteren Ent­wicklungen, die wir als Team und im Rahmen unserer je­weiligen Forschungsprojekte verfolgen werden.

Sie konnten Ihre Software vor einem ersten Testeinsatz in England nur an einem kleinen Modellauto erproben. Hat sich die Skalie­rung vor Ort auf den lebensgroßen Maßstab, das Rennauto DevBot, als Herausforderung gestaltet?

Die Software auf dem Dev-Bot zum Laufen zu bekommen, stellte kein großes Problem dar, da wir die Schnittstellen zwischen unserer Software und der Software von Roborace vollständig simulieren können.   Diese Schnittstellen haben wir auch auf unserem Mo­dellfahrzeug identisch gestaltet, um möglichst viele gleiche Software-Teile auf beiden Fahrzeugen nutzen zu können. Tatsächlich ist es so, dass ungefähr 90 Prozent des Codes, der auf dem DevBot läuft, ohne Änderungen auf das Modellfahrzeug übertragen werden können und umgekehrt. Das heißt, aus Sicht der Inbetriebnahme gibt es keinen großen Unterschied zwi­schen Modellauto und DevBot.

Große Unterschiede ergeben sich dann im Betrieb der Software auf dem DevBot und dem Modellfahrzeug. Das fängt bei den physikalischen Parame­tern wie Masse und Trägheiten an und hört bei der Anzahl und Art der zur Verfügung stehenden Sensoren auf. Auf dem DevBot bekommen wir durch die Vielzahl an verschiedenen Sensoren erheblich mehr Feedback als auf den kleinen Modellfahrzeugen, was uns ganz andere Möglichkeiten gibt.

Der enorme Vorteil der Modellfahr­zeuge ist, dass sie uns immer zur Ver­fügung stehen und dass wir mit sehr geringem finanziellen Aufwand da­rauf testen können. Außerdem können wir auch Algorithmen auf ihnen testen, die sich noch mitten in der Entwicklung befinden, ohne dabei ein großes Risiko eingehen zu müssen. Das ist auf dem gro­ßen Fahrzeug nicht möglich. Zusätzlich haben wir die Möglichkeit, mit vergleichs­weise geringem Aufwand mehrere Modellfahrzeuge aufzurüsten und diese dann am Lehrstuhl gegeneinander fahren zu lassen – sozusagen ein Mini-Roborace zu ver­anstalten. Das hilft uns in der Entwicklung natürlich enorm weiter, weil wir so den kompetitiven Charakter der Events simulieren können. Das kann mit den Dev-Bots nur mit sehr hohem Aufwand umgesetzt werden.

Das Rennfahrzeug DevBot mit Fahrer beim Formel-E-Event in Berlin (Quelle: Roborace)

Beim autonomen Fahren unterscheidet man sechs verschiedene Autonomiestufen. Von Stufe 0, bei der noch alles manuell gesteuert werden muss, bis Stufe 5 – sprich Vollauto­matisierung. Die meisten derzeit verfügbaren Autos sind mit Technik der Stufe 1 ausge­stattet, mehr Automatisierung in Serienfahr­zeugen ist aktuell noch die Ausnahme. Was ist Ihrer Erfahrung nach die größte Heraus­forderung bei der Entwicklung von Techni­ken, die autonomes Fahren möglich machen?

Die größte Herausforderung bei der Vollautomatisierung von Fahrfunktionen ist die Verschiedenartigkeit der Sze­narien, die im Straßenverkehr auftreten. Am deutlichs­ten wird das im Stadtverkehr, wo neben den anderen Fahrzeugen eine große Zahl anderer Verkehrsteilnehmer anwesend ist, beispielsweise Fußgänger und Radfahrer. Es existieren viele unterschiedliche Fahrbahnarten und -kreuzungen, es gibt Linksabbieger und Parkplatzsucher, die sich teilweise deutlich anders verhalten als „normal“ fahrende Fahrzeuge und vieles mehr. Die Umwelt des Fahrzeugs im Stadtverkehr ist sehr abwechslungsreich im Vergleich zu Fahrsituationen außerhalb von Städten.

Es gibt heute bereits viele Situationen, in denen sich ein Fahrzeug komplett selbstständig bewegen kann. Ein gutes Beispiel dafür ist das Fahren auf der Autobahn. Diese Umgebung ist strukturisiert im Vergleich zum abwechslungsreichen Stadtverkehr. Auf der Autobahn kann bis auf Ausnahmen viel besser einge­schränkt werden, was an möglichen Szenarien auftre­ten kann. Das bedeutet, die Wahrscheinlichkeit, dass etwas „Unerwartetes“ auftritt, ist deutlich geringer als im Stadtverkehr, was das automatisierte Fahren in dieser Umgebung erleichtert. Wenn die Rahmenbedingungen stimmen (Wetterbe­dingungen, Fahrbahnqualität, Fahrbahnmarkierungen, usw.), können schon heute auf der Autobahn große Distanzen mit automatisierten Fahrfunktionen zurück­gelegt werden.

Außer Acht gelassen werden dann aber Situationen, die plötzlich auftreten und nicht dem „Erwarteten“ entsprechen. In solchen Fällen ist es schwierig, dass die Software die Situation richtig interpretiert und die richtigen Schlüsse daraus zieht, weshalb aktuell dann der Fahrer in die Pflicht genommen wird, der ständig eingriffsbereit am Steuer sein muss. Schlussendlich wird man sich damit abfinden müssen, dass die Software im selbstfahrenden Auto nahezu alle auftretenden Situationen im Straßen­verkehr bewältigen kann, allerdings bei einem geringen Bruchteil an Situationen überfordert ist. Denkbar wäre dann, dass das Fahrzeug in so einer Situation einfach an­hält und auf einen Befehl des Passagiers wartet. Nichts­destotrotz wird das automatisierte Fahren die Sicherheit im Straßenverkehr erheblich steigern und zu einer Re­duzierung von Personen- und Sachschäden führen.

Für die Streckenplanung und die Umfeld­erkennung verarbeitet Ihre Software in Sekundenbruchteilen Informationen aus GPS-Daten, Kamera, Lidar-System, Radar und Ultraschallsensoren. Wie viel „Deep Learning“ steckt in Ihrer Arbeit?

Aufgrund der Tatsache, dass erst die großen Fortschritte im Bereich der Künstlichen Intelligenz den Entwick­lungsboom selbstfahrender Fahrzeuge in dem Umfang ermöglichen, wie wir ihn seit einigen Jahren sehen, liegt auf der Hand, dass auch wir sehr stark darauf auf­bauen. Künstliche Intelligenz erlaubt es uns, Unmengen an Daten, die man mit einem konventionellen Algorith­mus nur sehr schwer oder gar nicht erfassen kann, zu analysieren und zu verarbeiten, um daraus die richtigen Schlüsse zu ziehen.

In ihrer Frage erwähnen Sie konkret das sogenannte „Deep Learning“, was eine spezielle Klasse von Opti­mierungsmethoden künstlicher neuronaler Netze be­schreibt. Dieses Verfahren eignet sich unter anderem gut zur Objekterkennung aus Bilddateien, weshalb es ein zentraler Bestandteil des Perception-Moduls ist. Grundsätzlich ist unser Forschungsziel, neben dem reinen Einsatz von Methoden der Künstlichen Intelli­genz auch, die bisher bewährten „konventionellen“ Verfahren mit den auf Methoden der Künstlichen Intel­ligenz basierenden Ansätzen zu vergleichen. Momen­tan sind wir noch ganz am Anfang der Entwicklung, was den Einsatz Künstlicher Intelligenz in unserem Fahrzeug betrifft. Der Einsatz solcher Methoden wird sich später durch alle der drei bereits genannten Säu­len der Software-Architektur ziehen und dort eine ent­scheidende Rolle spielen.

Das Perception-Modul wird überwiegend auf Metho­den der Künstlichen Intelligenz basieren, vor allem zur Bildsegmentierung und Objekterkennung. Gleiches gilt für das Planning-Modul, sozusagen das „Gehirn“ des Fahrzeugs, das die Entscheidung trifft, welche Aktion jetzt ausgeführt werden soll. Vor allem das Planning-Modul muss die „Rennintelli­genz“ widerspiegeln, die in einem konventi­onellen Rennen sowohl der Rennfahrer als auch dessen Renningenieure darstellen.  Auch im Control-Modul, das hauptsäch­lich auf die etablierten Verfahren der Regelungstechnik zurückgreift, haben wir Ansätze aus der KI eingebet­tet. Damit erreichen wir, dass unsere Regelung ständig trainiert, dazulernt und sich selbst verbessert. Das führt dazu, dass das Fahrzeug mit jeder Runde ohne Zutun von außen besser und schneller über die Rennstrecke fahren können wird.

Angesichts der wachsenden Digitalisierung und Vernetzung von Fahrzeugen stellt sich beinahe zwangsläufig die Frage: Wie sicher kann autonomes Fahren sein? Stichwort Soft­ware-Manipulation...

Das Thema Sicherheit gegen Eingriffe von außen ist na­türlich in der Serienentwicklung extrem wichtig, weil die potentielle Anzahl an be­troffenen Fahrzeugen sehr groß ist, beispielsweise alle Fahrzeuge einer Modellreihe oder alle Fahrzeuge eines Herstellers. Für uns spielt dieses The­ma im Moment eine geordnete Rolle. Sicherheit bei uns bedeutet, wie können wir Absichern, dass die Künstliche Intelligenz keine „falschen“ Entscheidungen trifft. Wir beschränken uns auf unser Fahrzeug und die Software-Funktionen, die darauf laufen. Das schließt das umfangreiche Gebiet der Security gegenüber An­griffen von außen bisher aus.

Solange wir nicht dazu „gezwungen“ sind, uns mit dem Thema intensiver zu beschäftigen, liegt der Fokus unserer Arbeit klar auf anderen Gebieten. Sollte es zu­künftig im Rahmen eines Roborace-Events Challenges geben, die auf solche Security-Anwendungen abzielen, dann wäre das Thema der Software-Manipulation durch Dritte auch für uns hochrelevant. Ein Beispiel dafür wäre, das Fahrzeug der jeweils anderen Teams während der Fahrt zu hacken und die Software so zu manipulieren, dass das Fahrzeug langsamer fährt oder stehen bleibt. Solange solche Szenarien nicht der Fall sind, werden wir in dieses Gebiet nicht weiter als bisher einsteigen.

Letztendlich wird man – im Hinblick auf Straßenfahr­zeuge – akzeptieren müssen, dass kein System vollkom­men sicher gestaltbar ist. Es werden einzelne erfolgreiche Angriffe auf Fahrzeuge in Kauf genommen werden müs­sen – man wird sie nicht verhindern können. Wichtig ist, dass ein Massenangriff, zum Beispiel auf eine ganze Mo­dellreihe eines Herstellers, unterbunden werden kann.

Fahrer im DevBot-Cockpit (Quelle: Roborace)

Künstliche Intelligenz kann bei Hindernissen aufgrund ihrer kurzen Reaktionszeit im Stra­ßenverkehr das Autofahren sicherer machen. Wie geht Ihre Software mit „unsichtbaren“Gefahren wie Schnee, Schlaglöchern, Öl oder Glatteis um?

Das ist eine gute Frage, die uns vor allem im Rennsport sehr beschäftigt. Mit Schnee und Glatteis werden wir im jetzigen Renn­format vermutlich nicht konfrontiert werden. Öl und Schlaglöcher bzw. Bodenwellen können auf den aktuellen Formel-E-Rennstrecken aber durchaus vorkommen. Das gleiche gilt für eine nasse Fahrbahn aufgrund von Regen.

Die angesprochenen „unsichtbaren“ Gefahren haben alle gemeinsam, dass sie einen sprunghaften Abfall des Reibwertpotenzials zwischen Fahrbahn und Reifen zur Folge haben. Das bedeutet, dass die maximal übertrag­baren Kräfte zwischen Reifen und Fahrbahn plötzlich niedriger ausfallen. Das hat zur Folge, dass beispielsweise der Bremsweg länger oder das Fahrzeug beim Lenken unkontrollierbar wird.

Im Rennsport ist das Reibwertpotenzial deshalb so entscheidend, weil es optimal ausgenutzt werden muss, um die beste Rundenzeit zu erzielen. Dadurch ist die „Reifenkraft-Reserve“, um auf einen Abfall des Reib­wertpotenzials reagieren zu können, sehr gering. Das führt dazu, dass schon bei geringen Reibwertpotenzial-Schwankungen die maximal übertragbare Kraft über­schritten werden kann und die Räder blockieren oder das Fahrzeug in Kurven ausbricht.

Für uns von großer Bedeutung ist es, das Potenzial bereits im Vorhinein bestmöglich zu ermitteln, da es sonst in der Regel zu spät ist, auf ein plötzlich niedri­geres Reibwertpotenzial zu reagieren, beispielsweise wenn sich das Fahrzeug schon im Bremsvorgang befin­det. Dadurch, dass sich auf den Formel-E-Strecken die Streckenbegrenzung häufig direkt neben der Fahrbahn befindet, würde eine solche Situation meist mit einer Kollision enden und das Rennende für uns bedeuten.

Im normalen Straßenverkehr bewegt sich der Fah­rer in der Regel weit unterhalb des maximal nutzbaren Reibwerts, das heißt diese Thematik ist für ihn weniger relevant. Wo es allerdings sehr relevant wird, sind die erwähnten Beispiele mit Öl, Eis, usw., da hier das Reib­wertpotenzial plötzlich soweit abfällt, dass es auch den gewöhnlichen Fahrer betrifft. In solchen Situationen wäre die Prädiktion des Reibwertpotenzials, wie wir sie für unser Rennfahr­zeug umsetzen wollen, von großem Nutzen für die Sicherheit. Denkbar für die Übertragbarkeit auf den Straßenverkehr wäre, das Reibwertpotenzial der Straße unabhängig vom Reifen zu quantifizieren. Diese Information könnte dann nämlich al­len Verkehrsteilnehmern zur Verfügung gestellt werden.

Die gute Qualität der Informationen über den Fahr­bahnzustand, die wir durch das häufige Überfahren desselben Abschnitts erreichen, kann im Straßenverkehr dadurch erlangt werden, dass hier viele Fahrzeuge hinter­einander denselben Fahrbahnabschnitt überfahren. Der entscheidende Unterschied ist, dass sich die Fahrzeuge alle voneinander unterscheiden, was die reifenunab­hängige Darstellung des Fahrbahnzustands erfordert. Die Straßenqualität im Voraus zu kennen, wäre ein gro­ßer Sicherheitsgewinn im Straßenverkehr.

Der DevBot, ein Rennfahrzeug mit Auto­nomiestufe 5, fuhr mit Ihrer Software in der zweiten Runde des Roborace 150 km/h schnell: ein Hochgeschwindigkeitsauto auf einer abgeriegelten und präparierten Stre­cke. Wie verwertbar sind die gewonnenen Erkenntnisse für einen durchschnittlichen Alltags-Pkw?

Es stimmt insofern, dass wir uns im Rennszenario fern vom alltäglichen Straßenverkehr bewegen, der ja den Fokus von automatisierten Fahrfunktionen darstellt. Wir werden beispielsweise nicht mit der Situation kon­frontiert werden, einem plötzlich auf die Straße laufen­den Kind ausweichen zu müssen. Ein großer Vorteil für unsere Entwicklung ist, dass die riesige Variantenviel­falt an möglichen Verkehrsszenarien, wie ich sie bereits skizziert habe, entfällt. Die Umgebung, in der wir uns durch den Renneinsatz bewegen, stellt allerdings eine Kondensation von wichtigen Teilaspekten des automa­tisierten Fahrens in extremer Ausprägung dar.

Allem voran steht das Fahren im fahrdynamischen Grenzbereich. Dieser tritt im Straßenverkehr dann auf, wenn extreme Fahrmanöver ausgeführt werden müssen, zum Beispiel bei einer Gefahrenbremsung oder einem Ausweichmanöver zur Unfallvermeidung. Diese Situa­tionen treten zwar vergleichsweise selten auf, sind al­lerdings umso wichtiger für die Sicherheit. Beim Fahren auf der Rennstrecke befinden wir uns mit dem Fahrzeug im Optimalfall immer am fahrdynami­schen Limit, was bedeutet, dass das ganze Fahrzeug und die darauf laufenden Algorithmen ständig mit einer „Gefahrensituation“ umgehen können müssen. Dass wir uns dabei künftig mit über 200 km/h bewegen, ver­schärft die Anforderungen an die Software zusätzlich.

Errolson Hugh, der Fahrer des TUM-Roborace-Teams (Quelle: Roborace)

Genau dadurch, dass wir diesen extremen Fahr­zustand ständig haben, müssen wir in der Lage sein, unsere Software in solchen Situationen zuverlässig zu betreiben. Daraus resultiert eine große Chance, die Al­gorithmen ausführlich testen zu können. Insofern er­hoffen wir uns dadurch umfassende Erkenntnisse, die wir in die Serienentwicklung einfließen lassen können. Durch die Rennsportumgebung kommen auch ganz neue Herausforderungen hinzu, die uns zwar Vorteile bieten, auf der anderen Seite aber eine deutlich straf­fere Entwicklung als in der Serie erfordern. Neben dem Stresstest für Komponenten und Algorithmen gewin­nen wir sehr gut vergleichbare Messdaten, da wir nach jeder Runde die gleichen Fahrbahnabschnitte wieder und wieder überfah­ren. Außerdem haben wir sehr kurze Entwick­lungszyklen während einer Saison, da zwischen den einzelnen Events nur wenige Wochen liegen.

Das heißt, dass der Entwurf von neuen Software-Funktionen, die Implementierung und der Test in schneller Abfolge passieren müssen, was uns einen schnellen Entwicklungsfortschritt erlaubt. Für uns als Universität ist die Zusammenarbeit mit Roborace außerdem ein riesiger Vorteil, da uns die Ent­wicklung, der Aufbau und der Betrieb der Fahrzeuge komplett abgenommen werden. Wir können uns voll­ständig auf die Entwicklung neuer Software für auto­matisiertes Fahren konzentrieren. Wäre dieser Rahmen nicht gegeben, wäre es für eine Universität unmöglich, solche Prototypen aufzubauen und ein solches Projekt finanziell zu stemmen. Neben dem bereits genannten Know-how-Gewinn lernen wir auch abseits der Rennstrecke viel über die Entwicklung von automatisierten Fahrfunktionen. Ein Beispiel ist unsere Hardware-in-the-Loop-Simulation, in der wir die gesamte Fahrzeugumgebung mit statischer und dynamischer Umwelt und die Fahrdynamik simu­lieren. Unsere Software läuft dabei auf den originalen Steuergeräten des DevBots.

Vor allem Technologiekonzerne und Software-Firmen – wie zum Beispiel Google und Apple – haben das Thema Künstliche Intelligenz für sich entdeckt und zeigen sich experimentier­freudig. Die klassischen Autohersteller schei­nen sich da schwerer zu tun. Woran könnte das Ihrer Meinung nach liegen?

Der entscheidende Punkt ist meiner Meinung nach, dass dieses Thema für die IT-Konzerne zum alltäglichen Geschäft gehört. Der Know-how-Aufbau findet dort in viel größerem Umfang und viel schneller statt und startete vor allem viel früher als bei den Automobilherstellern. Dort war zu Beginn dieses Entwicklungsbooms rund um das automatisierte Fahren schlicht und ergreifend das nötige Know-how nicht oder nur begrenzt vorhanden. Gleiches gilt für die Fach­leute und die internen Strukturen, die so umfangreiche Software-Projekte erst ermöglichen.

In der Automobilbranche war man viel mehr darauf bedacht, Schritt für Schritt immer umfassendere Fahrer­assistenzfunktionen einzuführen, die dann letztend­lich in einem selbstfahrenden Auto münden. Allerdings war dieser Entwicklungszyklus von den entsprechenden Fahrzeugmodell-Zyklen abhängig, das heißt, dass neue Funktionen mit neu auf den Markt kommenden Fahr­zeugmodellen eingeführt wurden. Für die Entwicklung von automatisierten Fahrfunktionen ist dieses Vorgehen viel zu langsam und zu unflexibel. Die Weiterentwick­lung der Software muss kontinuierlich erfolgen und die Fahrzeuge müssen ständig mit Updates versorgt wer­den. Für die Automobilhersteller heißt das, dass sie die Entwicklungsgeschwindigkeit enorm hochschrauben und die nötige Infrastruktur aufbauen mussten.

Ein wichtiger Aspekt, den es bei der ganzen Diskus­sion zu berücksichtigen gilt, ist die Tatsache, dass die IT-Unternehmen ja nicht daran interessiert sind, selbst Fahrzeuge herzustellen, sondern nur die Software dafür entwickeln wollen. Worauf sie eigentlich abzielen, ist die Unmenge an Daten, die beim Fahren mit autono­men Fahrzeugen (zwangsläufig) anfällt, um sie für die eigenen Dienste zu nutzen.

Die Lage ist allerdings bei weitem nicht so drama­tisch, wie sie gerne dargestellt wird, wenn von der abgehängten oder rückständigen deutschen Auto­mobilindustrie gesprochen wird. Alle Hersteller haben enorme Investitionen getätigt und strategisch wich­tige Partnerschaften geschlossen, um auf dem Gebiet konkurrenzfähig mitspielen zu können. Alle Fahrzueghersteller und IT-Unternehmen bewegen sich ungefähr vergleichbarem Niveau mit unterschiedlich stark ausgeprägten Kern­kompetenzen. Einzig Google sticht wirklich heraus und ist, was die Software-Entwicklung betrifft, ver­mutlich „am weitesten“. Die große Unbekannte ist Apple, von denen sehr wenig bekannt ist.

Es bleibt abzuwarten, welches System bzw. welche Sys­teme sich langfristig am Markt durchsetzen werden. Dass jeder Hersteller sein komplett eigenes System am Markt etablieren kann, ist allerdings sehr unwahrscheinlich.

Sollte sich das autonome Fahren immer mehr als Standard etablieren, brauchen wir auch international einen rechtlichen Rahmen da­für, wie sich das Fahrzeug in bestimmten Situationen verhalten soll. Wie bringt man einer Künstlichen Intelligenz bei, ethisch „korrekte“ Entscheidungen zu treffen?

Der erste Schritt ist, einen rechtlichen Rahmen für den Einsatz von automatisierten Fahrfunktionen zu schaffen, so wie das für den heutigen, manuellen Straßenverkehr seit Jahrzehnten der Fall ist. Die wichtigste notwendige Änderung ist vergleichsweise einfach zu benennen, nämlich, dass der Fahrer die Erlaubnis bekommen muss, nicht aufmerksam am Steuer zu sitzen und bei­spielsweise das Handy benutzen darf. Viel schwieriger wird das Thema, wenn es darum geht, Verantwortlich­keiten festzulegen. Das wirft unter anderem die Frage auf, wer für einen Unfall haftet, wenn der Fahrer die Fahraufgabe an das Fahrzeug übergeben hat und damit nicht für den Unfall verantwortlich ist.

Wenn es darum geht, dass Fahrzeuge „ethisch kor­rekte“ Entscheidungen treffen sollen, wird die Ange­legenheit deutlich komplizierter. Soll der Gesetzgeber ähnlich der Straßenverkehrsordnung bestimmte Ver­haltensweisen und Aktionen definieren und vorge­ben? Dabei stellt sich schon alleine die Frage, was genau „ethisch korrekt“ bedeutet. Ein vor allem aus technischer Sicht nicht fassbarer Begriff, der auch von verschiedenen Menschen sehr unterschiedlich interpretiert werden kann. Für die Behandlung dieses wichtigen, aber schwierigen Themas wurde durch das Verkehrsministerium eine Ethikkommission unter der Leitung des ehemaligen Bundesverfassungsrichters Prof. Dr. Dr. Udo Di Fabio berufen. Diese Kommission beschäftigte sich ausführlich mit dem Thema des au­tomatisierten Fahrens und erarbeitete Leitlinien für die Programmierung solcher Fahrsysteme, die 2017 in einem Abschlussbericht vorgelegt wurden.

Das schwierige Thema, dass unser Rennfahrzeug ethisch „korrekte“ Entscheidungen treffen können muss, können wir aktuell zum Glück vernachlässigen. In der abgeschlossenen Umgebung, in der wir uns derzeit bewegen, muss das Fahrzeug  Entscheidungen treffen,die mit dem Reglement der Rennserie konform sind. Das ist auch vollkommen ausreichend, da sich zu keiner Zeit Menschen in Gefahr befinden.

In der Serienentwicklung von selbstfahrenden Fahr­zeugen ist die Entwicklung noch weit davon entfernt, bei einem bevorstehenden Unfall eine „ethisch korrekte“ Entscheidung zu treffen. Im Falle einer unvermeidlichen Kollision wird zuerst versucht, mögliche Ausweichmanö­ver zu fahren. Ist das nicht mehr möglich, so wird das Fahrzeug unter Einhaltung der aktuellen Fahrspur ma­ximal verzögert, um die Kollisionsschwere so stark wie möglich zu verringern.

Bei der Diskussion über „ethisch korrekte“ Ent­scheidungen wird stets auf das Ziel verwiesen, mit dem automatisierten Fahren Unfälle in Zukunft kom­plett zu vermeiden, um solche Entscheidungen nicht treffen zu müssen. Außerdem ist es derzeit rein aus technischer Sicht nicht möglich, die genaue Anzahl an Personen in einer Menschengruppe zu erfassen. Glei­ches gilt für die Qualifizierung von Menschen anhand ihrer Merkmale, weshalb die häufig herangezogenen Dilemma-Situationen für „ethisch korrektes“ Handeln eher theoretischer Natur sind.

Welche nächsten Schritte haben Sie für Ihre Software geplant? Sehen Sie Vermarktungs­potenzial für die Industrie?

Wir konzentrieren uns seit dem Roborace-Event in Berlin wieder voll auf unsere Forschungsthemen am Lehrstuhl. Berlin war für uns erst der Anfang, um zu zeigen, dass wir eine leistungsfähige Software entwi­ckelt haben. Auf Basis derer können wir jetzt in die Funktionsentwicklung einsteigen, die dazu führen wird, dass das Fahrzeug schneller wird. Zum einen können wir die Sicherheiten, die aktuell noch berück­sichtigt werden, schrittweise verringern. Zum anderen wird das Fahrzeug immer „intelligenter“, was einen großen Leistungssprung bedeutet. Das heißt kon­kret, dass das Fahrzeug zunehmend präziser auf die Umweltbedingungen – hier stehen aktuell vor allem statische und dynamische Objekte im Fokus – einge­hen und daraus die richtigen Schlüsse ziehen können wird. Das geschieht durch Entwicklung von neuen Funktio­nen und durch das Sammeln von Erfahrungswerten, auf die das Fahrzueg zurückgreifen kann.

Natürlich entsteht hier sehr viel Know-how, das für die Industrie inter­essant ist. Vor allem auch, weil wir die Gelegenheit haben, unsere Forschungsergebnisse im Einsatz unter Extrembedingungen zu überprüfen. Ohne Roborace wäre das für uns als Forschungseinrichtung schlicht unmöglich, wenn man bedenkt, was Entwicklung, Be­trieb und Logistik rund um die Rennfahrzeuge kosten würden. Dadurch, dass wir aber diese einzigartige Möglich­keit haben, können wir valide Forschungsergebnisse produzieren, die anschließend in die Serienentwicklung zurückgespielt werden können. Das Thema des automatisierten Fahrens ist natür­lich sehr viel weitreichender als die Szenarios, die wir in unserer Forschung berücksichtigen.

Allerdings leistet das sichere Steuern des Fahrzeugs in hochdy­namischen Situationen einen entscheidenden Beitrag zur Sicherheit der automatisierten Fahrfunktionen. Neben der Entwicklung von Algorithmen, die dazu in der Lage sind, spielt auch der Aspekt der Echtzeitfä­higkeit eine große Rolle. Wir können davon ausgehen, dass die Algorithmen im Straßenverkehr garantiert schnell genug sind, wenn wir sie für die Rennszena­rien echtzeitfähig implementieren können. Aus die­sen Gründen ist die Relevanz unserer Forschung trotz oder gerade wegen des reinen Renneinsatzes sehr hoch. Daher sehen wir für unsere entwickelten Algo­rithmen ein hohes Vermarktungspotenzial.

Werden Sie beim nächsten Roborace wieder an den Start gehen?

Definitiv. Wir stehen derzeit in engem Kontakt mit Roborace und planen die Saison 2019, an der wir wie­der teilnehmen werden. Geplant sind mehrere Events, die im Rahmen der FIA-Formel-E-Weltmeisterschaft stattfinden. An den Events sollen mehrere Teams teil­nehmen, die sowohl mit menschlichen Fahrern als auch mit ihrer Software gegeneinander antreten werden. Neben dem reinen Zeitfahren, wie beim diesjährigen Berlin-Event, sind weitere, neue Wettbewerbsformate in Planung.

Unser Team befindet sich aktuell in der Abstimmungs­phase über neue Funktionen und Verbesserungen unserer Software. Hauptentwicklungsziele sind dabei das Deketieren von und der Umgang mit dynamischen Objekten sowie eine deutliche Steigerung der Fahrzeug-Performance. Durch den Einstieg weiterer Teams steigt der kom­petitive Charakter der Events weiter an, was für mehr Spannung für die Zuschauer und vor allem für uns als Team sorgt. Wir freuen uns sehr über die neue Konkur­renz und den Wettbewerb.

Es bleibt auf jeden Fall spannend – sowohl für uns im Roborace als auch für die Entwicklung von selbstfahren­den Fahrzeugen im Allgemeinen.

Herzlichen Dank für das Gespräch, Herr Hermansdorfer. (aho)