Praktische Umsetzung der Überwachung der Fahrer-Aufmerksamkeit

Wie lässt sich die Überwachung der Fahrer-Aufmerksamkeit umsetzen? (Bild: AdobeStock_68048485)

Auf dem Weg von einer futuristischen Idee zu einem EU-weit vorgeschriebenen Standard-Feature liegen oft erste Implementierungen in Oberklasse-Fahrzeugen, und so dürften die derzeit in Entwicklung befindlichen Systeme zum automatisierten Fahren eine Vorschau auf die zukünftigen Anforderungen an Testsysteme bieten. Spitzenreiter ist hierbei Mercedes-Benz, deren Drive Pilot als erstes System dieser Art die gesetzlichen Anforderungen der internationalen UN-R157 für ein System nach SAE-Level 3 („hochautomatisiertes Fahren“) erfüllt – und an dem nochmals deutlich anspruchsvolleren Level 4 („vollautomatisiertes Fahren“) wird bereits gearbeitet. Zentraler Bestandteil solcher Funktionen ist in jedem Fall das Umfeldmodell, ein aktuelles und präzises Bild der Fahrzeugumgebung, auf dessen Basis die Algorithmen des Systems die auszuführenden Fahrmanöver berechnet. Beim Drive Pilot setzt Mercedes-Benz auf die Fusion der Daten aus Lidar-, Kamera-, Radar- und Ultraschallsensoren sowie einem Nässesensor im Radkasten. Konkurrent Tesla wollte sein „Full Self-Driving“-System zwischenzeitlich auf reiner Kamera-Basis realisieren, doch auch wenn das Unternehmen mittlerweile wieder von dieser Idee absieht, bleibt ein Faktum vorerst klar: ohne Kameras geht’s nicht!

Mercedes-Benz setzt sechs davon ein, Tesla gleich acht – Multiplikatoren, die in Kombination mit den hochauflösenden Sensoren und den zwingend nötigen hohen Bildraten in jeder Sekunde eine immense Datenflut produzieren, die nicht nur vom AD-Steuergerät im Auto, sondern ebenso vom Validierungssystem zur Funktionsabsicherung in Echtzeit bewältigt werden müssen. Dies ist eine gewaltige Aufgabe! Das gilt dabei ebenso für die initialen Testfahrten, in denen Datenlogger die Videostreams verlustfrei aufzeichnen (Bild 1), als auch für die späteren HiL-Tests, bei denen die aufgezeichneten Daten über alle Videokanäle hinweg synchron wiedergegeben werden müssen, um die korrekte Reaktion der zu testenden Fahrfunktion zu verifizieren.

Was muss ein Testsystem können?

Bei der Gestaltung eines solchen Validierungssystems spielen Skalierbarkeit, Wiederverwendbarkeit, Flexibilität und letztendlich Kostenoptimierung eine bedeutende Rolle. So sollte das eingesetzte System für die Erfassung und Wiedergabe von Videodaten möglichst viele der für den Einsatzzweck relevanten Übertragungsprotokolle in den jeweils aktuellen Generationen unterstützen und auch für zu-künftige Standards kostengünstig sowie ohne nennenswerten technischen Aufwand adaptierbar sein. Der Anschluss einer großen Anzahl von Kameras und die synchrone Wiedergabe ebenso vieler Videostreams muss genauso unterstützt werden wie hohe Bild- und Datenraten und die Synchronisierung mit anderen im Fahrzeug verbauten Aufzeichnungsgeräten, etwa für die Buskommunikation (OABR, CAN, FlexRay). Für den Einsatz in einem Datenlogger bei teils anspruchsvollen äußeren Bedingungen muss es eine gewisse Vibrationsfestigkeit und Hitzebeständigkeit erfüllen. Und wenn dann plötzlich eine neue Funktion wie der Müdigkeitswarner unterstützt werden muss, die über die reine Bilddatenerfassung hinausgeht, sollte in der Hinsicht die nötige Flexibilität drin sein.

 

Anwendungsbeispiel proFRAME als Datenlogger für Testfahrten.
Bild 1: Anwendungsbeispiel proFRAME als Datenlogger für Testfahrten. (Bild: Solectrix)

Der modulare Ansatz: proFRAME

Eine umfassende Lösung stellt hier das Video-Grabber- und Playback-System proFRAME von Solectrix dar, das mittlerweile in der dritten Generation existiert. Durch sein modulares Konzept bietet es die für solche Testsysteme zwingend nötige Vielseitigkeit und ist daher bei führenden Fahrzeugherstellern und deren Zulieferern im Einsatz. Der Kern des proFRAME-Systems ist das sogenannte Base Board: eine FPGA-basierte Einsteckkarte, die in den Formaten PCI Express und CompactPCI Serial (CPCI-S.0) erhältlich ist. Beide Bauarten sind bestückbar mit einer großen Auswahl an eigens entwickelten Adapter-Modulen (Bild 2), die den Anschluss vieler Automotive-Kameras ermöglichen – oder eben den Anschluss einer Infrarot-LED, die mit dem Shutter einer angeschlossenen Kamera synchron geschaltet wird. Neue Adapter sind ständig in Arbeit.

proFRAME 3.0 Base Board PCIe bestückt mit zwei Kamera-Adaptern.
Bild 2: proFRAME 3.0 Base Board PCIe bestückt mit zwei Kamera-Adaptern. (Bild: Solectrix)

Der Griff in den Datenstrom

Im Automotive-Bereich sind die gängigsten Übertragungsprotokolle GMSL (Gigabit Multimedia Serial Link) von Maxim und FPD-Link (Flat Panel Display Link) von Texas Instruments. Dabei werden die Bilddaten auf der Kameraseite durch einen Serializer eines dieser Typen geschickt, um Videoübertragung über kostengünstige Koaxialleitungen (bzw. Shielded Twisted Pair, STP) bei Leitungslängen bis zu 10 m mit sehr hohen Bandbreiten (bis 12 Gbps bei GMSL3) mit Backchannel-/Sideband-Kommunikation und Stromversorgung (PoC, Power over Coax) zu ermöglichen. Der Kamera-Adapter auf der Video-Grabber-Seite (Input) muss also das passende Gegenstück zum Serializer bereitstellen: einen Deserializer für das jeweilige Übertragungsprotokoll.

Für die Wiedergabe im HiL-Betrieb gilt dies umgekehrt: Kamera-Adapter mit Output-Funktion müssen über einen Serializer verfügen, mit dem sie dem zu verifizierenden ADAS/AD-Steuergerät perfekt vorgaukeln können, dass es gerade Daten von exakt diesem Kameratyp mit exakt dessen Konfiguration erhält. Das bedeutet auch: Wenn eine Kamera auf eine neue Implementierung eines Protokolls setzt, verlangt dies bei einem modularen System lediglich nach neuen Adaptern mit technisch ebenso aktuellen Maxim- oder TI-Chips und einer entsprechend angepassten Firmware. Das Base Board kann dagegen mitsamt Treibern und Softwarebibliotheken beibehalten werden. Die proFRAME-Reihe hat bereits den Sprung von GMSL zu GMSL2 und GMSL3 sowie von FPD-Link III zu FPD-Link IV mitgemacht. Adapter für Sonys GVIF2-Standard sind in Arbeit, Modelle für GigE Vision und Camera Link können auf Anfrage realisiert werden.

Flexibel konfigurieren

Idealerweise sollte es je nach verwendeten Adaptern möglich sein, das System als reinen Video-Grabber, reines Playback-Gerät oder als „Man in the Middle“ zwischen einer Kamera und einem Steuergerät zu konfigurieren. Im Fall von proFRAME kann ein Base Board mit zwei Adaptern bestückt werden, wobei ein Standard-Adapter vier FAKRA-Stecker bereitstellt. Je nach Adaptertyp sind hier vier Ein- bzw. Ausgänge oder eine Kombination von beiden möglich.

So kann ein einzelnes Base Board die Bildsignale von bis zu acht Kameras erfassen, diese im FPGA hochpräzise mit Zeitstempeln versehen, und sie dann nahezu latenzfrei zur weiteren Verarbeitung und Speicherung ans Hostsystem weitergeben. Letzteres geschieht mit einer Datenrate von bis zu 10 Gbit/s pro Videokanal, was etwa einem 10-Megapixel-Sensor mit 16 Bit Dynamik bei einer Bildrate von 60 Frames/s entspricht. Bei der typischen Konfiguration für Testfahrten nutzt das proFRAME-System mit entsprechender Adapter-Bestückung einige seiner Kanäle als Outputs und leitet die empfangenen Daten gleichzeitig an das angeschlossene ADAS/AD-Steuergerät im Fahrzeug weiter –“pass-through mode“ oder auch „tap mode“ genannt.

Durch ein derart modular aufgebautes Video-Grabber- und Playback-System sind Anpassungen und Upgrades eines Testsystems möglich, ohne Kernkomponenten austauschen zu müssen. (av)         

Sie möchten gerne weiterlesen?