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.