Pressemitteilung von Thomas Dörfler

ADAS-Sensoren testen mit Überschallgeschwindigkeit

---

---

Moderne Automobile sind ohne intelligente Sensoren undenkbar. Nur mit zuverlässiger Umwelterfassung können Fahrerassistenzsysteme und autonome Fahrzeuge sicher und fehlerfrei funktionieren. Die Validierung der Sensorik ist damit ein zentraler Schritt auf dem Weg zum automatisierten Fahren und muss bereits während der Sensorkonzeption mit eingeplant werden.

Aktuell beschäftigen zwei unabhängige Umwälzungen die Automobilindustrie: auf der einen Seite die Ablösung der Verbrennungsmotoren durch Elektroantriebe und auf der anderen Seite die Automatisierung des Fahrbetriebs über "Advanced Driver Assistance Systems" (ADAS) hin zum "Autonomous Vehicle" (AV). Ein Fahrzeug sicher und zuverlässig zu steuern erfordert eine Vielzahl von Fähigkeiten; nicht umsonst darf ein Mensch erst mit einem bestimmten Maß an Reife und nach einer entsprechenden Ausbildung Fahrzeuge führen. Eine Grundvoraussetzung für den automatisierten Fahrbetrieb ist, die Umwelt nicht nur erfassen, sondern auch ausreichend verstehen zu können: Wo befinden sich Fahrbahn, feste Begrenzungen und Hindernisse, welche Objekte bewegen sich im Umfeld, wo sind potentielle Gefahrensituationen?

Entsprechend intelligente Sensorsysteme sind in Entwicklung und auch schon in einigen Fahrzeugen im Einsatz. Optische Kamerasysteme, laserbasierte LIDARs und Sensoren auf Radar-Basis haben unterschiedliche Stärken und ergänzen sich in modernen Fahrzeugen. Wer die extrem hohen Anforderungen an die Zuverlässigkeit ernst nimmt und sich der Komplexität der Sensorsysteme bewusst ist, befasst sich frühzeitig mit der methodischen Validierung dieser Systeme. Im Hinblick auf den Projektzeitplan, ist die Effizienz der Validierung sogar entscheidend für den Projekterfolg.

Struktur intelligenter Sensorsysteme
Allen Sensor-Funktionsprinzipien ist eine Zweiteilung gemein: das jeweilige Frontend liefert Rohinformationen mit hoher Datenrate, hier sind heute Werte zwischen 100 und 800MBit/sec üblich. Die Rohdaten werden noch innerhalb des Sensorsystems aufbereitet und analysiert. Ans Fahrzeug werden dann die erkannten Objekte gesendet. Das Datenvolumen dieser Objektliste ist wesentlich geringer, es bleibt typischerweise unter 5KByte.

In der Black-Box-Betrachtung hat ein intelligenter Sensor also eine relativ überschaubare Funktion: Rohdaten erfassen, erkannte Objektliste ausgeben. Die Interna sind jedoch ausgesprochen kompliziert: Filterung der Eingangsdaten, Anpassung an die Umweltbedingungen, Störunterdrückung, Objekterkennung, -plausibilisierung, -klassifizierung und -verfolgung basieren auf komplexen Algorithmen und deren adaptiver Parametrierung. Hinzu kommen auch noch die Echtzeitanforderungen der gesamten Verarbeitungskette und, aus Sicht der Wertschöpfung, der Druck zur Kostenoptimierung.

Für die Implementierung dieser Algorithmen brauchen die Entwickler umfassendes Know-how, auch über die Sensorprinzipien, ihre Möglichkeiten und Grenzen. Eine noch größere Herausforderung ist die Validierung des Sensorsystems. Hier sind mehrere Vorgehensweisen denkbar.

Statische Labor-Aufbauten
Erste Funktionstests kann man recht einfach mit entsprechenden Laboraufbauten machen: Statische Bilder für Kamerasysteme, Metall-Reflektoren für Radarsensoren, Testkörper für LIDAR-Systeme. Allerdings lassen sich damit bewegte Objekte nur sehr begrenzt einsetzen. Sobald man vielfältige Szenarien prüfen möchte, stößt man hier an praktische Grenzen.

Testfahrten
Am Ende muss das Sensorsystem sich auf der Straße bewähren. Also ist es auch naheliegend, für die Validierung Testfahrten durchzuführen. Autobahn, Landstraße, Stadtverkehr, schwedische Fernstraßen, die Betriebsamkeit italienischer Städte oder das Durcheinander einer asiatischen Großstadt: Die Vielfalt der Szenarien kann nur in der realen Welt er-fahren werden.

Aber die korrekte Erkennung aller relevanten Objekte ist während der Fahrt schwer zu prüfen: Ein Echtzeitvergleich von Umgebung und erkannter Objektliste über mehrere Stunden, Tage und Wochen überfordert die Konzentrationsfähigkeit der Testingenieure. Und: wenn Abweichungen und Fehlfunktionen festgestellt werden, die Software und Parametrierung daraufhin verbessert werden, verlieren die bisher absolvierten Testfahrten ihre Aussagekraft und müssen wiederholt werden. Und hier zeigen sich die Schwachpunkte dieser Methodik: Weder kann man exakt die gleichen Objektszenarien für die Validierung der Verbesserung herstellen, noch lassen sich auf Kommando die gleichen Wetterbedingungen wieder und wieder hervorzaubern. Testfahrten stellen also einen wertvollen Random-Test dar, sind aber nicht exakt wiederholbar.

Simulation
Testszenarien per Simulation zu erzeugen, hat gegenüber Testfahrten offensichtliche Vorteile: Die Testdaten sind nicht mehr von den zufällig angetroffenen Bedingungen abhängig, sondern können gezielt erzeugt werden. Einmal erstellte Szenarien und Sequenzen lassen sich beliebig oft wiederholen. Bei digitaler Einkopplung der Simulationsdaten finden aufeinanderfolgende Tests sogar bitgenau mit dem selben Input statt. Damit sind zum einen Testergebnisse jederzeit wiederholbar und nachvollziehbar. Zum anderen kann eine verbesserte Sensorsoftware unter exakt den selben Bedingungen geprüft werden wie ihre Vorgänger. Das Labor braucht dabei nicht verlassen zu werden. Neue, als kritisch erkannte Szenarien, können jederzeit hinzugefügt werden. Und: anders als bei Testfahrten, lassen sich auch Szenarien erzeugen, denen man ein reales Testfahrzeug nicht aussetzen kann oder will, etwa Unfallsituationen, extreme Wetterbedingungen oder ähnliches. Ein oft unterschätzter Nachteil der Simulation ist jedoch, dass die Simulationsszenarien durch die Phantasie der Testingenieure begrenzt sind. Die Vielfalt und Komplexität der realen Welt fehlen hier.

Realdaten-Injektion
Die Realdaten-Injektion vereint die Vorteile von Testfahrten mit der Simulation, denn sie bringt reale Umweltszenarien ins Labor. Für diese Validierungsmethode werden während einmalig durchgeführter Fahrten die Rohdaten der Sensorfrontends lückenlos und bitgenau aufgezeichnet. Diese Rohdatensammlung kann dann im Labor in die Sensoren zurückgespeist und zur Validierung neuerer Softwarestände herangezogen werden. Damit werden die Vorteile von Testfahrten und Simulation kombiniert: die Situationsvielfalt der Testfahrten kann beliebig oft in die Sensorsysteme eingespeist werden, und das jedes mal bitgenau.

Aufzeichnung von Realdaten
Wie kann ein System zur Realdatenaufzeichnung aussehen? Für die aufzuzeichnenden Rohdaten eines Sensorsystems stehen praktisch nie fahrzeugtaugliche Schnittstellen zur Verfügung, daher ist ein System, das Realdaten aufzeichnen soll, direkt an das jeweilige Sensorsystem anzukoppeln. Ausserdem sollte es entsprechend kompakt und robust angelegt werden, denn es muss bei den unterschiedlichsten Witterungsbedingungen funktionsfähig bleiben.

Bewährt hat sich ein gesplitteter Aufbau, wie er für das Gigabit-Datenloggersystem DP²4R ausgearbeitet wurde: Eine Zentraleinheit (Controller) wird im Fahrzeug verbaut, diese ist mit großen, wechselbaren SSD-Speichern ausgerüstet und für die Initialisierung, Steuerung und Datenaufzeichnung von bis zu vier abgesetzten Erfassungsköpfen (Head Units) zuständig. Über Gigabit-taugliche Kabel wird der Controller mit den Head Units verbunden. Jede Head Unit wird ihrerseits direkt an die Sensorelektronik angekoppelt und ist auch in deren Gehäuse integriert.

Die Head Unit mit ihrem FPGA ist zuständig für die Datenübernahme von der jeweiligen Sensorelektronik. Da hier je nach Sensorkonzept die verschiedensten Schnittstellen zum Einsatz kommen, muss die Head Unit leicht an die Kundenanforderungen anpassbar sein. Das Designkonzept sollte auch eine mechanische Adaption an die Gegebenheiten des Verbauraums erlauben.

Im Fahrbetrieb sind die Head Units dafür verantwortlich, die Daten von der Sensorelektronik abzuziehen, mit einem Zeitstempel zu versehen, zu formatieren und an den Controller zu senden. Der Controller wiederum aggregiert die Daten aller Head Units und speichert sie gemeinsam ab. Bei der Konzeption ist relativ viel Feinabstimmung nötig, denn die aggregierte Datenrate in einem solchen System übersteigt schnell 1GBit/sec, Konzeptschwächen führen schnell zu Flaschenhälsen. Neben den Sensor-Rohdaten sollten auch Mechanismen zur Dokumentation der Fahrtstrecke vorgesehen sein: GPS-Tracker und eine zusätzliche Kamera-Erfassung der Fahrtstrecke erleichtern die Nachbereitung der Daten.

Archivierung und Upload
Zur Archivierung der Daten dienen handelsübliche NAS("Network Attached Storage")-Systeme am Entwicklungsstandort. Allerdings werden sehr hohe Kapazitäten benötigt: Ein Jahr lückenlose Aufzeichnung benötigt eine Speicherkapazität im einstelligen Petabyte-Bereich. Der elegante Weg, um die Daten vom Testfahrzeug zum NAS zu transportieren, wäre ganz klar ein Netzwerkinterface. Allerdings ist damit die praktisch erzielbare Datenrate auf ca. 10Gbit/sec begrenzt. Daher lohnt es sich, stattdessen auf den guten alten "Turnschuhbus" umzusatteln: die SSDs werden manuell aus der Erfassungs-Zentraleinheit entnommen und direkt ins NAS eingesetzt. Bei fünf Minuten Fußweg vom Fahrzeug zum NAS und zwei SSDs mit je acht TByte Kapazität entspricht das einer Datenrate von etwa 430 Gbit/sec, mit Netzwerkkabeln ist das kaum zu übertreffen. Damit liegen die auf den Testfahrten gesammelten Daten bereit zur weiteren Nutzung, Aufbereitung und Auswertung.

Rohdaten-Injektion
Die gesammelten Rohdaten können vielfältig ausgewertet werden. Der Hauptnutzen liegt jedoch in der Möglichkeit, die Daten wieder in die Sensoren einzuspeisen und deren Reaktionen auszuwerten, in einem klassischen Hardware-in-the-Loop-(HiL)-Aufbau. In diesem Aufbau werden letztendlich wieder ähnliche Komponenten genutzt: An die Sensorsysteme, die validiert werden sollen, werden Head Units angekoppelt, die die Rohdaten jetzt nicht aufzeichnen, sondern statt dem Frontend ins Sensorsystem einspeisen. Die Head Units ihrerseits empfangen die Rohdaten synchron vom Controller, der sie wiederum direkt vom NAS holt.

Automatisierte Qualitätsmetrik
Mit diesem Aufbau durchfahren die Sensorsysteme also die früher aufgezeichneten Sequenzen, und dies sogar noch miteinander synchronisiert. Wird ihr Output Richtung Fahrzeug-Bussystem überwacht und mit den relevanten Objekten verglichen, so kann man die entscheidenden Fähigkeiten der Software nachprüfbar quantifizieren.
Noch existierende Schwachpunkte wie nicht oder falsch erkannte Objekte werden in einem erzeugten Report ausgewiesen. Dieser Report dokumentiert für jeden geprüften Softwarestand nachvollziehbar den erreichten Qualitätslevel.

Beschleunigung
Das Testprinzip anhand der erfassten Rohdaten hat einen praxisrelevanten Nachteil: Die Testsequenzen werden am HiL-Prüfstand in Echtzeit durchfahren, damit dauert der Test allerdings auch genauso lange wie alle zu durchfahrenden Fahrtszenen. In Summe kommt man dann leicht auf einige Monate oder sogar Jahre Prüfzeit, zu lange für einen Abnahmetest und für ein Projekt katastrophal, wenn relevante Lücken in der Erkennungsrate ermittelt werden.

Aber auch diese Herausforderung lässt sich meistern: Mehrere identische HiL-Prüfstände können parallel aufgebaut werden, in einem kompakten Aufbau auch als Farm von bis zu 50 parallelen Clustern. Die Fahrtszenen lassen sich dann auf die HiL-Cluster verteilen, die Testfahrten werden quasi mit 50-facher Geschwindigkeit abgefahren: Aus einer Durchschnittsgeschwindigkeit von 60km/h werden virtuelle 3.000km/h, also etwa dreifache Schallgeschwindigkeit. Eine vollständige Qualifizierung von 12 Monaten Testdaten ist damit innerhalb von 1 Woche möglich. Teiltests (etwa als Vortest nach Softwaremodifikationen) sind eine Frage von Stunden.

Fazit
Intelligente Sensorsysteme als Basis der Fahrzeuge von morgen stellen neue Herausforderungen an die Validierung und Qualitätssicherung der Software. Eine System-Validierung auf Basis von realen Fahrdaten ist für OEMS schon aus versicherungstechnischen Gründen unumgänglich und erlaubt bereits vor der Markteinführung verlässliche Aussagen über die Robustheit der Sensorik.
Verfahren und Systeme hierzu stehen bereit und sind damit als Stand der Technik zu betrachten. Deren Integration sollte frühzeitig in den Entwicklungsprojekten berücksichtigt werden, um die Projektziele rechtzeitig, mit der gebotenen Sorgfalt und sicher zu erreichen.

Bildquelle: embedded brains GmbH Firmen- & Pressekontakt