Für das Absichern von Fahrzeugfunktionen musste bislang auf Fahrroboter mit hohem
mechanischem Anteil und entsprechenden Installations- und Kalibrieraufwand
zurückgegriffen werden. Jetzt gibt es von e:fs TechHub eine deutlich schlankere
und trotzdem leistungsfähige Alternative: LeanDRA. Sie nutzt im Fahrzeug
vorhandene Hard- und Software, um automatisierte Fahrfunktionen autonom
auszuführen. In den meisten Fällen, können Entwickler und Tester von Funktionen
wie ADAS damit auf den Einsatz konventioneller Fahrroboter verzichten.
AEEmobility: Welche Idee steckt hinter dem softwaredefinierten
Lenkroboter LeanDRA?
Niklas Jester: Es kam die Frage im Unternehmen auf, wie man Fahrzeugfunktionen validieren könnte, wenn zukünftige autonome Fahrzeug kein Lenkrad haben und damit die Möglichkeit entfällt, einen konventionellen Lenkroboter einzusetzen. Wir haben dann – anfangs auf die reine Lenkfunktion bezogen – untersucht, was wir schon heute mit der vorhandenen Hard- und Software im Auto diesbezüglich implementieren können. Die Ausgangslage war für uns günstig, weil wir im Rahmen der zahlreichen gemeinsamen Entwicklungsprojekte mit dem VW Konzern umfassendes und tiefgreifendes Know-how aufbauen konnten.
Niklas Jester ist Product Owner bei der e:fs TechHub GmbH, einem Joint Venture der Akkodis Germany Solutions GmbH und CARIAD SE.
Zu welchen Ergebnissen kamen Sie?
Es kristallisierte sich schnell heraus, dass wir bei Zugriff auf die Fahrzeugkommunikation und durch Sensormanipulation mit dem Auto in Bezug auf das Lenken und darüber hinaus eine ganze Menge anstellen können. Dabei haben wir gesehen, dass wir den klassischen Lenkroboter in vielen Anwendungsfällen ersetzen können.
Was heißt das konkret?
Zum Beispiel ist es möglich, einen softwaredefinierten Roboter bei der Validierung von ESC-Systemen und dort abzudeckende Testszenarien wie das Kurvenbremsen einzusetzen. Bei diesem Test muss das Fahrzeug bis in den dynamischen Grenzbereich in einer Kreisbahn gefahren und dann stark abgebremst werden. Der von uns entwickelte softwaredefinierte Lenkroboter LeanDRA kann diese Fahraufgabe ohne Einschränkung erledigen. Unsere Hardware mit dem Fahrzeugbus verbinden, die vorbereitete Trajektorie aufrufen und auf Play drücken und schon läuft die Testfahrt automatisch ab. Ein Fahrer oder einen zusätzlichen mechanischen Lenkroboter wird dafür nicht benötigt.
Teil dieses Testszenarios ist aber auch, herauszufinden, wie sich die ESC-Funktion verhält, wie sich das Fahrzeug nach dem Bremsen weiterbewegt und wo es am Ende zum Stillstand kommt. Die dafür erforderliche Verarbeitung kommt unserer Auffassung nach bei vielen bislang verfügbaren Lösungen, viel zu kurz und Tester bleiben auf sich gestellt. Wir haben im Falle des Kurvenbremsens beispielsweise erlebt, das Tester Kreisbahnen gezeichnet und mit dem Lineal ausgemessen haben, um den Versatz zu ermitteln. Das kann ja nicht die Lösung sein.
Das LeanDRA System bedarf keiner
Veränderungen am
Serienfahrzeug. Die Straßenzulassung
kann bestehen bleiben, sodass ein
Wechsel des Testgeländes besonders
einfach möglich ist. © e:fs
Welchen Weg gehen Sie da?
Wir haben ja GPS in den Fahrzeugen, mit dem wir mit 2 cm Genauigkeit den zurückgelegten Weg präzise und automatisiert während des Versuchs aufzeichnen können. Das nutzen wir und werten die Daten dann automatisiert aus. Das bedeutet für die Anwender einen großen Mehrwert.
D.h., bei konkreten Testaufgaben ist dann eine klassische Lösung zum Aufzeichnen und Analysieren der Daten nicht erforderlich!
Genau. Die Idee war, nicht erst die Daten extern aufzuzeichnen und danach zu verarbeiten, sondern sie fallen ja bei unserem Ansatz im System ohnehin an und werden verarbeitet. Dann können wir sie auch gleich noch mitaufzeichnen und je nachdem, um welche Daten es sich dabei handelt, live oder im Nachgang analysieren und das Ergebnis dem Tester präsentieren.
Das beschränkt sich aber auf die für den Test erforderlichen Daten, oder?
Ja. Wir zeichnen und verarbeiten die Daten selektiv. Dedizierte Datenerfassungssysteme, wie sie in der Fahrzeugentwicklung und der Validierung verwendet werden, zeichnen in der Regel viel mehr Daten auf, sodass auch noch im Nachgang ganz unterschiedliche Analysen durchgeführt werden können. Wir sind natürlich gebunden an das, was wir auch aufgezeichnet haben. Das heißt, wir konzentrieren uns wirklich auf einen bestimmten, vorher festgelegten Anwendungsfall.
Sie können also mit LeanDRA deutlich mehr, als dynamische Fahrunktionen ohne Fahrer oder Lenkroboter auszuführen?
Anfänglich hatten wir uns mit unserem Konzept auf den Einsatz in dynamischen Tests wie ESC-Applikationen konzentriert. Das ist aber ein sehr spezifischer, in der Verantwortung des OEMs liegender und auch aus Marktsicht überschaubarer Bereich. Das sieht ganz anders aus, wenn wir ADAS-Fahrfunktionen betrachten und das Fahrzeug als Roboter verstehen. Alles, was irgendwie im Fahrzeug ansteuerbar ist, ist für uns auch grundsätzlich auslesbar bzw. manipulierbar.
Das heißt, wir haben nicht nur das klassische Testen bzw. Validieren von ADAS-Fahrfunktionen im Blick, sondern alle Anwendungen, bei denen Autos bewegt werden und Daten ausgewertet werden müssen. Das reicht von der Entwicklung und den Test von Fahrzeugkomponenten wie LiDARs und Radarsensoren, über Teilfunktionen bis hin zu kompletten ADAS-Lösungen.
Das LeaNDRA System ist sehr kompakt. Alle notwendigen Komponenten sind in einem System
integriert. Zum Teststart reicht eine einzige gesicherte Steckerverbindung mit
dem Fahrzeug. © e:fs
Wie sieht die LeanDRA-Lösung stand heute aus?
Wir haben ein Basissystem, das die Roboterfunktion übernimmt und für alle Anwendungen gleich ist. Darüber hinaus gibt es einen Teil, mit dem wir die Lösung an die spezifischen Anforderungen des individuellen Anwendungsfalls anpassen können. Zum Beispiel bezüglich der geforderten Regelung von Trajektorien, Ansteuerung von Aktoren oder eine zusätzliche Möglichkeit, dem Fahrer über das Kombiinstrument etwas zu visualisieren.
Können Sie das bitte noch etwas detaillierter erläutern?
Das Basissystem ist die Steuereinheit, mit der wir das Fahrzeug im sicheren, also abgeschalteten Zustand übernehmen, dann den Motor starten, den Gang einlegen, das Fahrzeug längs und quer bewegen und dabei auch Zusatzfunktionen wie Blinken, Hupen, Scheibenwischer bedienen können. Am Ende übergeben wir das Fahrzeug wieder im sicheren Zustand, also mit ausgeschaltetem Motor. Diese ganze Kette beschreibt kurz zusammengefasst die Funktion des Basissystems.
Auf dieses Modul baut dann ein weiteres Modul auf, mit dem wir unsere Lösung an die verschiedenen Fahrzeug-Plattformen adaptieren. Das ist erforderlich, weil die Fahrzeuge unterschiedliche Kommunikationskonzepte verfolgen. So nutzt der von uns als Demonstrator genutzte Audi Q8 Flexray als Bussystem, die Fahrzeuge auf MEB-Basis, dagegen CAN/CAN FD. Wir adaptieren hier entsprechend die zweite Komponente unseres Systems, die dann aber im Falle von VW jeweils viele Modelle auf einmal abdeckt. Wenn zukünftig Anforderungen in Richtung Automotive Ethernet oder sonstige Kommunikationslösungen kommen, können wir auch das wieder über eine Anpassung der zweiten Komponente unseres Systems erledigen, ohne das Basissystem anfassen zu müssen. Das ist auch der Grund, warum wir eine Modularisierung des LeanDRA gewählt haben.
Für welche Fahrzeuge ist LeanDRA aktuell verfügbar?
Da wir die Fahrzeugsysteme ansteuern, sind wir sehr tief in der Fahrzeugvernetzung unterwegs. Wir haben uns aus diesem Grund anfangs historisch bedingt auf die Fahrzeuge aus dem VW-Konzern konzentriert. VW hat zudem den Vorteil, dass das Unternehmen eine riesige Bandbreite an Fahrzeugen – vom Kleinfahrzeug über Elektrofahrzeuge und Allradfahrzeuge bis hin zu Nutzfahrzeugen – alles im Programm hat, sodass Anwender ihre Produkte mit den unterschiedlichsten an Fahrzeugtypen und -klassen testen können.
Mittlerweile sind wir aber dabei, LeanDRA über Fahrzeuge des VW-Konzerns hinaus auszurollen. Dabei setzen wir auch auf die Unterstützung der OEMs, um über einen Zugriff auf entsprechende Datenbasen die für eine Integration aufzuwendenden Entwicklungszeiten in einem überschaubaren Rahmen zu halten. Natürlich stellt dies eine gewisse Herausforderung dar, da die Datenbasen schließlich für viele deutsche OEMS immer noch der „heilige Grahl“ sind.
Wir sind aber überzeugt, dass wir wegen des Potenzials unserer Technik, damit erfolgreich sein werden. Auch aus dem Grund, weil wir keine Fahrzeugdaten an den Anwender rausgeben, die über die klassischen Daten hinausgehen, die ohnehin jeder auslesen könnten – z.B. über die OBD-Schnittstelle oder die Anzeigen des Fahrzeugs.
Dank zweistufigem Sicherheitskonzept kann der Fahrer beim softwaredefinierten Lenkroboter LeanDRA die Kontrolle jederzeit übernehmen. © e:fs
Welche Anforderungen stellt Ihr System an ein Fahrzeug, damit es prinzipiell genutzt werden kann?
Damit unser System vollumfänglich genutzt werden kann, muss das Fahrzeug nur über zwei Funktionen verfügen, die heute in fast jedem Fahrzeug zu finden sind: Einmal ein Tempomat, besser eine ACC-Funktion, und irgendeine Querfunktion wie ein Parkassistent oder eine Spurmittenführung. Verfügt das Fahrzeug allerdings über eine manuelle Gangschaltung, gibt es Limitierungen bzw. muss ein Fahrer ggf. den Gang wechseln. Handelt es sich um ein Fahrzeug mit Automatikgetriebe, können wir das mit automatisieren. Benötigt ein Test z.B. nur eine Querfunktion, brauchen wir natürlich auch kein ACC.
Wo liegen die Grenzen des Systems?
Es gibt nur wenige Grenzen. Ein Punkt ist: Wir haben im Gegensatz zu einem Lenkroboter nicht die Möglichkeit, mit einem eigenen Motor zusätzliche Druck in das System zu bringen. Wir haben dafür auch eine Lösung, die wir noch nicht öffentlich gezeigt haben. Von daher gibt es eigentlich keine Dynamiklimits. Anwendungen, bei denen diese extrem hohe Dynamik gefragt ist, sind aber auch absolute Randbereiche.
Ein anderer Punkt ist, wenn der Anwender das ACC im Fahrzeug selbst prüfen möchte und wir gleichzeitig die ACC-Schnittstelle nutzen, um das Fahrzeug anzusteuern. Allgemein gesagt: Wir können alle Systeme im Fahrzeug prüfen, nur in der Regel nicht die, die wir gerade verwenden.
Aber auch da lohnt sich ein genauerer Blick: im Falle des Spurhalteassistent können wir beispielsweise mit unserem System in die Testsituation fahren, es dann deaktivieren und die Kontrolle an das Fahrzeug übergeben und trotzdem weiterhin die Reaktionen des Fahrzeugs erfassen und auswerten. Hier müssen wir gemeinsam mit dem Kunden genau prüfen, ob diese Art der Ansteuerung für den gewünschten Einsatzbereit zulässig ist.. So gibt es in den USA im NCAP-Bereich Tests, bei denen ein Lenkroboter beschrieben wird, um dieses Tests zu fahren. Den nutzen die OEMs dann auch lieber, um auf der sicheren Seite zu sein.
Wenn ich Sie richtig verstehe, können Sie mit minimalem Aufwand aus einem Serienfahrzeug ein robotergesteuertes Fahrzeug machen?
Das war für uns immer wichtig. Für uns stand fest, wenn wir schon keine zusätzliche Sensorik, Aktuatorik und Mechanik einbauen müssen, soll es auch möglich sein, das Fahrzeug mit unserem System mit minimalem Aufwand auszurüsten und mit wenigen Handgriffen auf den Roboterbetrieb umzustellen bzw. den geplanten Test zu starten. Sobald unsere Hardware im Kofferraum oder auf dem Rücksitz montiert ist, kann ein Fahren das Fahrzeug über öffentliche Straßen auf das Prüfgelände fahren, da es sich um ein unverändertes Serienfahrzeug handelt. Sobald der Test gestartet werden soll, muss nur noch die Hardware mit dem Fahrzeugbus über einen zentralen Stecker am System verbunden werden, die Hardware eingeschaltet werden und dann kann es mit dem Test schon losgehen.
Die e:fs TechHub GmbH
Die e:fs TechHub GmbH ist ein Joint Venture der Akkodis Germany Solutions GmbH und CARIAD SE, das heute mit über 700 Mitarbeitenden Lösungen für die Automobilindustrie realisiert. Gegründet wurde das Unternehmen 2009 als EFS von Audi Electronics Venture und Gigatronik, um im Rahmen von Einzelbeauftragungen – vorwiegend durch den VW-Konzern – elektronische Fahrwerkssysteme zu entwickeln.
Mittlerweile hat das Unternehmen den Kompetenzspektrum mit Themen wie ADAS, KI und Datenmanagement deutlich vergrößert, versteht sich heute als unabhängiger Partner von OEMs sowie Zulieferern und bietet eigene Produktlösungen an.
Dafür steht der Begriff TechHub im Firmennamen. Das Unternehmen mit Hauptsitz in Gaimersheim (Ingolstadt) unterhält daneben Standorte in Erlangen und Wolfsburg.
Wie können Anwender Testfahrten planen und ausführen?
An dieser Stelle halten wir uns bewusst zurück. Wir wollten nicht die hundertste Software auf den Markt bringen. Es gibt dafür einfach schon mehr als genug kommerzielle Softwareprodukte. Wir haben gesehen, dass die meisten Anwender eine eigene Hardware installieren, mit der sie Dinge wie die Wahrnehmung, die Situationsinterpretation und die gewünschten Trajektorien generieren. Diese Systeme können sich über CAN oder Ethernet mit unserem System verbinden und darüber die Fahrbefehle schicken. Für Demonstrationen und einfache Anwendungen bieten wir einen Webserver, mit dem die Basiseinstellung vorgenommen werden, aber auch einfache Aufgaben wie das Anfahren, das Folgen eines GPS-Tracks und das Anhalten erledigt werden können. Wer möchte, kann das Fahrzeug auch über eine drahtlose Spielekonsole steuern. Darüber hinaus wollen wir nicht gehen, sondern uns auf die Bereitstellung des Fahrroboters mit Zugriff auf alle Bewegungs- und sonstige Funktionen des Fahrzeugs konzentrieren.
Daher gehört zu unserer Strategie, möglichst kompatibel zu sein und vorhandene Schnittstellen wie die von IMAR Navigation für szenarienbasiertes Testen, die ja auch in die ISO überführt wird, zu unterstützen. Weitere Schnittstellen sind in Arbeit.
Inwieweit werden zukünftige Fahrzeugarchitekturen – Stichwort SDV – und zunehmende Maßnahmen zur Gewährleistung der Datensicherheit LeanDRA beeinträchtigen?
Es wird natürlich eine Herausforderung werden, weil aus Sicherheitsgründen die Busverschlüsselung und andere Cybersecurity-Themen ins Spiel kommen. Gleichzeitig muss ja zumindest der OEM auch weiterhin die Möglichkeit des Zugriffs haben. Darüber hinaus denken die verschiedensten OEMs über Schnittstellen nach, die es verifizierten Apps ermöglichen, z.B. das Fahrzeug mit dem Smart Home zu verbinden, damit es sich eigenständig in die Garage abstellen kann. Wir gehen daher davon aus, dass es immer Schnittstellen geben wird, die wir für unsere Zwecke nutzen können. In dem Thema ist allerdings aktuelle so viel Bewegung und es ist mit noch so vielen Unwägbarkeiten behaftet, dass wir hier die weitere Entwicklung erst einmal abwarten wollen.
Und vor allen Dingen für den aktuellen Kernbereich, also die Entwicklung von Fahrerassistenzfunktionen, in dem LeanDRA aktuell in erster Linie angewendet wird, wie auch im Einsatz in Hasenfahrzeugen auf dem Prüfgelände, muss nicht immer das fortschrittlichste Fahrzeug automatisiert werden – oft reicht auch die Vorgängergeneration, die LeanDRA keine Probleme macht.
Wenn sich jemand für den Einsatz Ihres Systems interessiert, wie läuft dann ein Projekt ab?
In der Regel müssen mit dem Interessenten erst einmal seinen Anwendungsfall durchgehen, um zu klären, was wir mit unserem Basispaket bereits abdecken können und welche Anpassungen wir gegebenenfalls vornehmen müssen. Dabei geht es vor allem darum, die Grenzen des Systems gemeinsam so festzulegen, dass der Anwendungsfall des Kunden nicht eingeschränkt wird und gleichzeitig sicher durchführbar ist.
Wenn wir keine größeren Anpassungen vornehmen müssen, dann können wir ein vom Kunden beigestelltes und mit unserem System ausgerüstetes und getestetes Fahrzeug innerhalb weniger Wochen zur Verfügung stellen. Die eigentliche erstmalige Einrüstung dauert dabei nur ca. zwei Stunden. Das System kann fest im Kofferraum– das ist die meist gewählte Variante – oder auf dem Rücksitz montiert sein, falls ein einfacher Wechsel zwischen Fahrzeugen erwünscht ist.
Damit das System in beiden Varianten einsatzfähig ist, muss es dann nur noch, wie erwähnt, mit dem Fahrzeugbus des Autos verbunden werden.
Das reine Rüsten eines Fahrzeugs für den Test ist mit LeanDRA demnach deutlich einfacher und schneller als bei der Verwendung eines mechatronischen Lenkroboters, insbesondere wenn ich zwischen mehreren Testfahrzeugen wechseln will?
Der wiederholte physikalische Einbau eines konventionellen Lenkroboters – meist braucht es noch weitere Roboter z.B. zur Betätigung der Pedale – ist das eine, was bei uns auf jeden Fall schon einmal entfällt, da wir nur einmalig einrüsten müssen. Das andere ist der nachfolgende Kalibrieraufwand bei den mechatronischen Lösungen. Dafür ist geschultes Personal erforderlich. Bei uns entfällt auch dieser Schritt, weil ja der OEM schon dafür gesorgt hat, dass der entsprechende Steuerbefehl, einen bestimmten Lenkwinkel einzuschlagen, auch präzise ausgeführt wird.
Fairerweise muss gesagt werden, es gibt auch Schnittstellen, die für beide Lösungen eine Herausforderung darstellen. So ist beispielsweise die Beschleunigungskurve beim Verbrenner nicht linear und entsprechend schwieriger in den Griff zu bekommen.
Durch den Zugriff auf den Fahrzeugbus sollte der Umfang der möglichen Tests bei LeanDRA aber deutlich größer sein, als bei einem mechatronischen Lenkroboter?
Wir können auf jeden Fall eine größere Vielfalt abbilden. Alles was in Buskommunikation abgebildet ist, können wir grundsätzlich für Kundenanwendungen nutzbar machen. Wenn ich zum Beispiel die Reaktion des Fahrzeugs beim und nach dem Auslösen eines Notbremsvorgangs beobachten will, können wir dem Fahrzeug einfach ein virtuelles Hindernis vorgaukeln. Das ist so mit einem konventionellen Lenkroboter gar nicht möglich. Andere Aufgaben sind mit einem Lenkroboter nur sehr aufwändig zu adressieren. Dazu gehört das Setzen des Blinkers oder des Scheibenwischers – oder noch komplexer wegen der erforderlichen 3D-Bewegung – das Einschalten des Fernlichts. Bei uns ist das nur eine Sache des Setzens einiger Bits.
Bleibt die Frage der Kosten!
Im Vergleich zu einem Lenkroboter, der ja am ehesten eine Funktionalität bietet, die an den unseres Basismoduls heranreicht, erfordert unsere Lösung weniger Komponenten. Wie erwähnt brauchen wir beispielsweise keinen Pedalroboter und ähnliche, unterstützende Hilfsapparturen – ggf- mit der Ausnahme eines Gear-Shift-Roboters im Falle eines rein mechanischen Schaltgetriebes. Wir benötigen auch keine zusätzliche Batterie, um die ganzen Aggregate betreiben zu können. Wir liegen im Vergleich zu so einem mechatronischen Fahrroboter etwa bei einem Drittel der Kosten. Zudem habe ich deutlich mehr Platz im Fahrzeug, der Fahrersitz bleibt frei und ich kann das Fahrzeug normal weiterbenutzen – auch auf öffentlichen Straßen, und habe zudem einen größeren Funktionsumfang. Unter dem Strich bekommen Anwender als deutlich mehr für ihr Geld.
Niklas Jester – Product Owner LeanDRA (Im Hintergrund
Kundensystem Leitner ConnX) © e:fs
Was haben Sie für LeanDRA noch in der Pipeline?
Unser nächstes Ziel sind Projekte mit weiteren OEMs. Darüber hinaus sehen wir für unser System viele Anwendungsfälle jenseits der klassischen Straßenfahrzeuge. Die zugrundeliegenden Logiken, insbesondere die Sicherheitsmechanismen, lassen sich grundsätzlich auf jegliche Bewegungsplattformen applizieren.
So haben wir bereits mit dem Seilbahnhersteller Leitner das Urban Mobility Projekt ConnX, realisiert, bei dem es darum ging, eine Seilbahngondel, die zuvor am Seil hing, auf eine Fahrplattform zu setzen und automatisiert zu bewegen, um die letzte Meile zu überbrücken. Denkbar sind entsprechende Anwendungen im Hafenbereich, um Container autonom zu bewegen, oder autonome Fahrzeuge in der Landwirtschaft. Hier lassen sich unsere Konzepte tatsächlich jeweils eins zu eins übertragen. (jr)
