Konzipierung eines HIL-Systems für die Validierung autonomer Fahrfunktionen

Interview mit Christoph Funda und Paul Schmidl, Zukunft Mobility GmbH

Wir haben mit Christoph Funda und Paul Schmidl von der Zukunft Mobility GmbH, ein Kompetenzzentrum der ZF Friedrichshafen AG für die Bereiche Fahrerassistenz, integrale Fahrzeugsicherheit und autonomes Fahren, über die Entwicklung eines HIL-Systems für die Validierung autonomer Fahrfunktionen gesprochen. Bei den TECH WEEKS 2020 haben sie den Aufbau eines HIL-Prototyps zur Closed-Loop-Simulation eines autonom fahrenden Bus-Shuttles mit einem großen Sensordatensatz präsentiert.

In der ZF-Familie wurde ein Projekt für autonom fahrende Shuttle-Busse ins Leben gerufen. Was genau hat es damit auf sich?

Funda: Mit diesem Projekt wollen wir die Entwicklung elektrischer Shuttles bis hin zum SAE-Level 4 erforschen, um eine nachhaltige Entlastung der Innenstädte durch ein fahrerloses, elektrisches und flexibles Mobilitätsangebot zu erreichen. Die Mobilität, wie wir sie kennen, soll revolutioniert werden, indem wir sie sauber, effizient, komfortabel und bezahlbar machen.

In zwei deutschen Städten, Mannheim und Friedrichshafen, soll das Konzept bis Ende 2023 erprobt werden. In Mannheim liegt der Fokus auf innerstädtischem Mischverkehr, während in Friedrichshafen der Überlandbetrieb erprobt werden soll.

Könnten Sie bitte Ihr Tätigkeitsfeld in diesem Zusammenhang näher beschreiben?

Funda: Unser Team für die Testsystem-Entwicklung konzipiert die entsprechenden Hardware-in-the-Loop (HIL)-Prototypen-Systeme auf Basis der National Instruments (NI)-Technologie. Das Ziel der Systeme ist die Validierung von ZF-Steuergeräten im Kontext der Umfeldsensorik und des autonomen Fahrens. Diese Prototypen-Systeme werden dann reproduziert. Anschließend validieren sie in HIL-Farmen in sechs- bis achtwöchigen Softwarezyklen durch Regressionstest die Steuergeräte und deren Software, um Produktfreigaben erteilen zu können.

Wir verwenden dabei einen Sensordatensatz, der von unseren Kollegen von ZF Friedrichshafen erstellt wurde. Dieser basiert auf dem Sensordatensatz von IPG Automotive. Das Besondere daran ist, dass er bei einer großen Anzahl von Sensoren − circa 21 Stück − sehr hohe Datenraten von mehr als 20 Gbps liefert. Der Datensatz ermöglicht so eine sehr anwendungsnahe Sensorkonfiguration für ein hochautonomes Fahrzeug, welches perspektivisch die Anforderungen von SAE-Level 4/5 erfüllen kann.

Welche Besonderheiten mussten Sie bei den Kamera-, Radar- und LIDAR-Modellen berücksichtigen?

Funda:Die Kamera-, Radar- und Lidarmodelle müssen sehr viele Qualitätskriterien, Anforderungen und Randbedingungen erfüllen. Diese wurden aus den Eigenschaften der realen Sensoren und der Simulations-Toolchain abgeleitet – das war ein sehr umfangreiches Vorhaben. Darüber hinaus mussten die Sensormodelle an die notwendigen Schnittstellen angepasst werden. Die Modelle wurden dabei so gestaltet, dass eine Closed-loop-Simulation ermöglicht wurde.

Welche Vorteile können Sie daraus ziehen, dass Sie die gleichen Modelle wie bei Software-in-the-Loop (SIL) verwenden?

Funda:Wir profitieren stark von der Reproduzierbarkeit und der Vergleichbarkeit der Testergebnisse im V-Modell. Darüber hinaus können auch die Entwicklungszeiten stark verkürzt und verhältnismäßig teure HIL-Tests auf günstigere Software-in-the-Loop-Tests verlagert werden. Diese lassen sich deutlich besser skalieren und sind deshalb günstiger in der Durchführung.

Wie kann man sich das von Ihnen verwendete HIL-Setup vorstellen: Greifen Sie auf etablierte Technik zurück, oder gehen sie hier neue Wege?

Funda:Sowohl als auch: Als Basis haben wir auf bewährte NI-Technik gesetzt und dann eng mit National Instruments und IPG Automotive zusammengearbeitet, um geeignete Optimierungen vorzunehmen und neue Möglichkeiten zu entwickeln. Außerdem kommen neue Betriebssysteme wie Linux RT sowie neue Hardware- und Softwareprototypen wie die 40G-Ethernetkarte zum Einsatz, um die benötigte hohe Datenrate zu realisieren.

Konnten Sie so trotz der großen Menge an Sensoren die Echtzeitfähigkeit auf Ihrem HIL-System gewährleisten?

Schmidl:Durch umfassende Analysen mit der SIL-Simulation konnten wir bereits eine positive Abschätzung der Echtzeitfähigkeit der Sensormodelle in der HIL-Simulation erzielen. Ausgehend von der SIL-Simulation konnten wir die Performancetests von CPU und GPU zunächst mit einzelnen und anschließend mit mehreren Sensoren durchführen. Anhand der Ergebnisse konnten dann entsprechende Hardware-Anforderungen an den benötigten, hoch performanten Simulations-PC abgeleitet werden.

Funda:Eine generelle Gewährleistung der Echtzeitfähigkeit kann im Allgemeinen aber nicht gegeben werden. Sie ist stark abhängig von der Anzahl der Objekte in der Umgebungssimulation − für CPU-lastige Sensormodelle wie etwa Objektsensoren − sowie der Auflösung der Sensoren. Auch die Anzahl der empfangenen Reflexionen für GPU-lastige Sensoren, beispielsweise RSI-Sensoren für Lidar und Radar, spielt eine große Rolle. Das heißt, die Szenarien sind hier entscheidend.

Für das von Herrn Schmidl erwähnte Konzept, aus Messungen einer SIL-Simulation Rückschlüsse auf die Echtzeitfähigkeit der HIL-Simulation ziehen zu können, sind wir sehr eng mit IPG Automotive im Austausch. Mit dieser Vorgehensweise könnte man sich zumindest die Zeit am HIL sparen, die zu Overruns und Echtzeitverletzungen führt. Gegebenenfalls können dann die Szenarien soweit vereinfacht werden, dass sie echtzeitfähig am HIL simuliert werden können.

Wie sind Sie vorgegangen, um die Simulation der rechenintensiven Sensormodelle, die Sie angesprochen haben, zu beschleunigen?

Schmidl: Da die verwendeten Kamera- und Lidar-Modelle besonders hochauflösend sind, konnten diese nicht in nur einer einzigen GPU-Instanz berechnet werden. Die entsprechenden CPU-Prozesse der GPU-Instanzen konnten die Punktewolken und Kamera-Frames nicht schnell genug prozessieren − höhere CPU-Taktraten verbessern das Verhalten.

Durch eine Aufteilung eines Sensormodells in eine definierte Anzahl an Teilmodellen konnten wir sicherstellen, dass die CPU-Prozesse der GPU-Instanzen die Datenmenge in weniger als einer Millisekunde verarbeiten, um die Echtzeitfähigkeit des Systems sicherstellen zu können. Bis zu einem gewissen maximalen Wert ist eine Beschleunigung der Simulation durch so eine beschriebene Aufteilung möglich.

Sie haben zusammen mit National Instruments und IPG Automotive einen Workshop zu diesem Thema durchgeführt. Welches Ziel wurde damit verfolgt?

Funda: Der Workshop sollte dazu dienen, eine geeignete Architektur der Closed-Loop-Simulation auf dem HIL-System zu erarbeiten und anschließend in einem Proof-of-Concept in kleinen Paketen direkt zu erproben.

Wir haben beispielsweise Performance-Messungen durchgeführt, um den Delay der Kamera-Daten festzustellen. Diese waren am kritischsten, da sie die größten Datenraten vorweisen. Die Daten müssen also von der Grafikkarte über die Netzwerkkarte zum HIL übertragen werden, was wiederum zusätzliche Latenzen und Bottlenecks auf der CPU mit sich bringt. Falls wir da in Zukunft noch Bedarf sehen sollten, könnten wir auf andere Technologien wie beispielsweise Direct Memory Access umsteigen.

Abschließend haben wir einen Zeitplan ausgearbeitet, um die besprochene Architektur und die Gesamtsimulation kurzfristig auf einer Beta-Version von CarMaker zu erproben, da wir bei den NI-HIL-Systemen von Windows/Pharlab auf Linux-RT umgestiegen sind. Der Umstieg war notwendig, da wir das vollständige Sensorset mit Pharlab nicht in Echtzeit applizieren konnten.

Im nächsten Schritt möchten wir messdatenbasierte und simulative Studien durchführen, um festzustellen, ob die Qualitätsanforderungen im Hinblick auf das System erfüllt sind.

Wie sollen diese Studien aufgebaut sein?

Funda:Wir validieren unsere HIL-Systeme aktuell hauptsächlich mit Messungen mittels Six-Sigma-Methoden. Für die Reinjektion von Messdaten in die Open-Loop-Simulation gehen wir aktuell auch neue Wege und bauen zusätzlich eine diskrete Eventsimulation mit dem Lehrstuhl Informatik 7 der FAU Erlangen-Nürnberg auf. Damit möchten wir erreichen, gesicherte Aussagen über die Echtzeitfähigkeit unserer Streaming-Kette geben zu können.

Dazu werden die gewonnenen Messdaten zum erweiterten Input-Modelling so aufbereitet, dass wir mindestens empirische Verteilungen erzeugen. Optimal sind aber theoretische Verteilungen, um auch Ausreißer mit der Simulation erzeugen zu können. Wir nutzen die Methode auch entwicklungsbegleitend, um die Größen der Buffer und Queues designen zu können.

Unser Ziel ist es, an den Interfaces vom HIL zum System-under-Test die Echtzeitfähigkeit und das korrekte Timing in vorgegebenen Toleranzen gewährleisten zu können.

Vielen Dank, dass Sie sich die Zeit für dieses aufschlussreiche Gespräch genommen haben.

Das komplette Interview als Download

© RABus/2getthere