Abgesehen von den noch zu eliminierenden Risiken überwiegen die Vorzüge des automatisierten Fahrens, vor allem die Vermeidung von Unfällen. Jährlich sterben 1,3 Millionen Menschen im Straßenverkehr, und die Mehrzahl der Unfälle basiert auf menschlichem Versagen, dem mit heute bereits verfügbarer Technologie vorgebeugt werden könnte. Weltweit entwickeln Ingenieure und Softwarespezialisten die nächste Generation von Radarsensoren, die es Fahrzeugen zunehmend ermöglicht, ihre Umwelt zu sehen und zu begreifen. Die Anforderungen sind hoch, denn es gilt, die aufgenommenen Daten fehlerfrei zu interpretieren und in Sekundenbruchteilen in korrekte und sichere Entscheidungen umzusetzen. Sowohl bei den Fahrerassistenzsystemen (ADAS), die schon heute dabei helfen können, 45 % der Unfälle zu vermeiden, als auch bei autonomen Fahrzeugen (AV, Autonomous Vehicles) spielt hier hochtechnisierte Sensorik eine entscheidende Rolle.

DP²4R erfasst bis zu 4 x 320 MBit/s.

DP²4R erfasst bis zu 4 x 320 MBit/s.Embedded Brains

Um die Sensoren praxistauglich und kostenoptimiert realisieren zu können, ist der Einsatz von hochintegrierten Controllern erforderlich. Sie vereinen geeignete Schnittstellen zur mehrkanaligen Radar-Signalerfassung mit der notwendigen Speicherkapazität für die anfallenden Rohdatenmengen und ausreichender Rechenleistung zur Datenauswertung auf einem Chip. Der chipinterne A/D-Wandler digitalisiert die über die Radarantenne empfangenen Signale mit bis zu 320 MBit/s. Auch das Speichern, Verarbeiten und Auswerten der Daten erfolgt auf dem Controllerchip, sodass die Daten den Chip erst wieder in abstrahierter Form verlassen, um sie problemlos auch über langsame Schnittstellen wie CAN weitergegeben zu können.

So elegant und effizient der vollintegrierte Aufbau im endgültigen Produkt ist, so tückisch ist er für die Entwicklungsteams, denn zur anspruchsvollen Aufgabe, einen so komplexen Chip optimal zu programmieren, kommt noch die Problematik, dass die Radar-Rohdaten den Chip nie verlassen. Auf diesen Chips gibt es keine Kommunikationsschnittstelle, die schnell genug ist, um diesen Datenstrom in Echtzeit auszugeben. Aber wie können die Ingenieure dann einen Algorithmus zur Datenaufbereitung entwickeln und vor allem verifizieren, wenn sie die zugehörigen Rohdaten nicht extern analysieren können?

Praxisbezug durch Testfahrten

Sehr aussagekräftig für den Entwicklungszyklus sind reale Testfahrten. Nur im Einsatz unter realen Bedingungen kann geprüft werden, ob die Sensoren alle relevanten Objekte im Erfassungsfeld wirklich erkennen, klassifizieren und verfolgen können. Ist die Hardware empfindlich genug, um gut auswertbare Rohdaten zu liefern? Sind die Algorithmen fein genug abgestimmt, um nicht nur Fahrzeuge in der Nähe sondern auch weiter entfernte Objekte zu erkennen? Wie gut gelingt die Trennung benachbarter Objekte? Und wie stark beeinflusst die Witterung die Resultate?

Testfahrzeuge sind viele Stunden unterwegs, um eine ausreichende Anzahl kritischer Situationen durchfahren zu können. Die Erkennungsrate der Sensoren lässt sich damit zwar punktuell bewerten, aber mehr Resultate liefert eine Testfahrt nicht. Wird ein Objekt nicht oder nicht richtig erkannt, so ist das Entwicklerteam erst einmal auf Mutmaßungen angewiesen, wo in der Auswertung der Fehler liegt. Und noch schlimmer: Nach einer Verbesserung der Algorithmen gibt es keine Möglichkeit, dieselbe Fahrsituation noch einmal durchzuspielen.

Lösung maßgeschneidert

Datenlogger wie der DP²4R (direct prototyping data processor for radar systems) ermöglichen den Entwicklerteams die erforderliche Transparenz. Das Unternehmen Embedded-Brains konzipierte dieses System von Grund auf so, dass es im Automotive-Umfeld Daten verteilt, mit hoher Bandbreite erfasst, zentral speichert und für die Offline-Verarbeitung bereitstellt. Der DP²4R ermöglicht es, während einer Testfahrt gleichzeitig bei bis zu vier Sensoreinheiten beliebige Daten abzuziehen, an den zentralen DP²-Controller zu übertragen, dort lückenlos zu speichern und nach Abschluss der Fahrt extern auszuwerten. Pro Sensor kann das Gerät dabei 320 MBit/s erfassen.

Neben der Erfassung der Sensordaten kann das System auch die Testfahrt automatisch dokumentieren. Bei Bedarf kann es laufend sowohl die GPS-Koordinaten als auch ein Kameravideo mit speichern, das die Fahrsituationen aufzeichnet. Dies erleichtert später die Auswertung der Daten, da es das Geschehen auf der Straße zeigt.

Dezentral erfassen

An jedem Radarsensor-System sitzt dezentral ein spezialisierter, etwa 40 x 60 mm2 großer Erfassungskopf (DP²4R Head Unit), der sowohl über ein FPGA zur Datenerfassung und -formatierung als auch über ein lokales RAM als Zwischenspeicher verfügt. Das Layout des Erfassungskopfes wird jeweils speziell für die Hauptplatine des Radarsensors angepasst und als Piggyback-Einheit auf diese aufgesteckt. Er koppelt sich dabei mit dem High-Speed-Debugging-Interface (zum Beispiel Nexus/Aurora) des zentralen Mikrocontrollers. Damit lassen sich über das Debugging-Interface sowohl die Radar-Rohdaten als auch weitere notwendige Informationen kontinuierlich abziehen.

Zentral speichern

Das Herzstück des Datenloggers DP²4R ist der DP²-Controller, der sowohl für die Datenspeicherung als auch für die gesamte Steuerung verantwortlich ist. Die Erfassungsköpfe senden die gesammelten Nutzdaten als seriellen LVDS-Strom an den DP²-Controller, wobei die Verbindungen dazu bis zu 7 m lang sein können. Bis zu vier Headunits lassen sich an einen DP²-Controller ankoppeln, sodass dieser gleichzeitig und synchron die Daten von vier Radarsensoren sammeln und auf wechselbaren SSD-Massenspeichern ablegen kann.

Offline auswerten

Die gesammelten Daten liegen auf SSD-Massenspeichern. Ausgewertet werden sie jedoch auf externen Rechnern. Der Datentransfer dorthin kann über Ethernet mit 1 GBit/s erfolgen. Eine sinnvolle Option ist der gute alte „Turnschuhbus“: Die SSD-Massenspeicher lassen sich mit geringem Aufwand aus dem DP²-Controller entnehmen und in externe Laufwerksschächte der Auswerterechner einsetzen. Damit sind dann (je nach Entfernung zwischen Fahrzeug und Auswertungsrechner) Übertragungsraten von 2 TByte/15 s beziehungsweise 1 TBit/s erreichbar.

Danach ist Fleißarbeit angesagt: Aus den stundenlangen Aufzeichnungen müssen die Ingenieure die Situationen extrahieren, die sie näher untersuchen wollen; die lückenlosen Zeitmarken und die Kameraprotokolle der Testfahrten erleichtern dieses Prozedere. Darauf aufbauend können die Entwicklerteams dann die ursprünglichen Simulationsmodelle mit den relevanten Rohdaten versorgen und das Verhalten der Sensoren nachvollziehen. So lassen sich die Algorithmen zur Auswertungs zukünftig noch besser abstimmen.

Playback optional

Ein angepasstes Software-Update macht die Sensoren fit für die nächsten Tests. Im „Injection Mode“ kann das System dazu dienen, um die ursprünglich erfassten Radar-Rohdaten wieder in die Sensoren einzuspeisen. In einer Art Virtual-Reality durchfahren die Sensoren die vorher erlebten Situationen erneut, können jetzt aber zeigen, was sie durch das Software-Update gelernt haben. Für die systematische Verifikation der Systeme ist das ein entscheidendes Hilfsmittel – vor allem, weil die Ingenieure sich so mit der Zeit eine Daten-Bibliothek der kritischen Fahrsituationen aufbauen können.