Bildverarbeitung - HANSER automotive

12lA UTOMOTIVE
3-4.2009l TITEL
© Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern
ENTWICKLUNG VON FAHRERASSISTENZSYSTEMEN MIT FPGAS
Bildverarbeitung
mit Methode
Mit AIDA, dem Advanced Integrated Driver Assistance System von Altera
wird zum einen eine integrierte Systemarchitektur zur kostengünstigen
Umsetzung von Fahrerassistenzsystemen und zum anderen eine neue
Methodik vorgestellt, die eine direkte Schnittstelle von der PC Entwicklun
zur Hardware realisiert.
Moderne Fahrzeuge bieten heute schon Lösungen
basierend auf Radar oder Kamerasystemen,
die den Fahrer in Gefahrensituationen
warnen und unterstützen sollen. Die erste Generation
solcher Systeme sind Spurwechselassistenten (LDW –
Lane Departure Warning), Adaptive Abstandssysteme
(ACC – Adaptive Cruise Control), Rückschaukameras als
Einparkhilfe und Nachtsichthilfen. Die nächste Generation
wird über mehr Sensoren mit noch höherer Auflösung
und über deutlich komplexere Funktionen verfügen.
Systementwickler stehen dabei vor großen Herausforderungen,
da die aufwendigen Algorithmen eine
sehr hohe Verarbeitungsleistung erfordern, im Fahrzeug
aber weder viel Platz noch ausreichende Kühlmöglichkeit
für stromhungrige Prozessoren besteht. Dazu kommen
noch die üblichen Randbedingungen wie minimale
Kosten und maximale Ausfallsicherheit. Eine Reihe von
Halbleiterbausteinen adressiert diese Probleme auf
unterschiedliche Art. Heute werden sowohl spezielle
Bildverabeitungs-Controller, als auch Signalprozessoren
(DSPs), Standard-Prozessoren und Programmierbare
Logik (FPGAs) in neuen Systemkonzepten untersucht.
Beispiel eines Spurwechselassistenten
Das Beispiel in Bild 1 zeigt den prinzipiellen Aufbau von
Fahrerassistenzsystemen. In diesem Fall wird eine nach
vorne schauende Kamera eingesetzt, die eine Auflösung
von mindestens 640x480 Bildpunkten und eine Bildrate
von 15-30 fps (Bilder pro Sekunde) aufweist. Der
LDW-Algorithmus verarbeitet das Kamerasignal in ver-

TITELl AUTOMOTIVE
3-4.2009l13
© Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern
Bild 1: Verarbeitungsblöcke und Signalfluss für einen Spurwechsel-Assi-
© automotive
schiedenen Schritten. Zunächst werden
relevante Messpunkte gesucht und
extrahiert, anhand derer dann Kandidaten
identifiziert werden, die auf einer
Spurgrenze liegen könnten. Mit einer
Reihe von Filterfunktionen und der
Betrachtung vorausgehender Bilder wird
diese Information zur Spurkennzeichnung
verwendet. Schließlich wird die
Lage des Fahrzeugs auf der Spur berechnet.
Je nachdem wie nahe das Fahrzeug
der Spurgrenze kommt wird ein Warnsignal
generiert.
stenten.
Prinzipiell kann man zwei Arten der Signalverarbeitung
unterscheiden. Die
ersten Berechnungsschritte verarbeiten den Strom der
Bilddaten direkt und müssen daher sehr schnell ablaufen.
Dabei werden im Pixeltakt mehrere Linien gleichzeitig
gefiltert, um z.B. Kanten zu erkennen. Diese sogenannte
Bildvorverarbeitung (Pre-Processing) wird in der
Regel parallel in Hardware implementiert. Der Signalfluss
geht als Strom durch die Blöcke hindurch. Die
Anforderungen an die Hardware sind dabei recht
beachtlich. Ein einfaches 3-Tap-Filter für ein VGA-Signal
mit 30 fps erzeugt einen Rechenaufwand von 30 Millionen
Multiplizier-Akkumulier-Zyklen pro Se-kunde. Die
Ergebnisse der Berechnung werden wieder zu einem
Bild zusammengesetzt und im Speicher abgelegt. Das
ist notwendig, weil die folgenden Verarbeitungsschritte
wahlfrei auf einzelne Bildpunkte zugreifen müssen und
daher nicht direkt im Bildstrom arbeiten können. Diese
Bildnachverarbeitung (Backend-Processing) ist nur mit
hohem Aufwand parallel zu implementieren und wird
daher meist in einer Prozessorarchitektur als Programm
durchlaufen. Dabei ist die Speicherbandbreite des
Systems entsprechend leistungsfähig auszulegen,
denn nur ein einziger wahlfreier Zugriff pro Bildpunkt
erzeugt schon eine Buslast von etwa 150 MByte/s.
Bild 2: Aufbau des AIDA-Prozessors.
Um den oben genannten Anforderungen gerecht zu
werden, bestehen leistungsfähige Fahrerassistenzsysteme
heute aus mindestens zwei Bausteinen, dem Vorverarbeitungsbaustein
an der Kamera und einem oder
mehreren DSPs zur Bildnachverarbeitung. Die Architektur
der Vorverarbeitungseinheit hängt von der Fahrerassistenzfunktion
ab, die realisiert werden soll. Es gibt
zwar eine Reihe von Standardfiltern, die auch in einigen
Spezialbausteinen in Hardware integriert sind - die Qualität
eines Systems wird jedoch entscheidend von der
Bildvorverarbeitung beeinflusst. Damit ist es meist
unerlässlich spezielle Filterfunktionen zu implementieren.
Besonders flexibel geht das mit FPGAs.
AIDA-Controller
Fahrerassistenzsysteme werden aufgrund des hohen
Bauteileaufwands derzeit nur in Oberklasse- und einigen
Mittelklasse-Fahrzeugen als Option angeboten. Ein
breiter Einsatz auch in Volumenbaureihen erfordert eine
grundlegende Optimierung der Systemarchitektur. Eine
deutliche Kostenreduktion ergibt sich durch die Integration
einer flexiblen Bildvorverarbeitung und einer programmierbaren
Bildnachverarbeitung in einen Baustein.
Der AIDA-Prozessor (Bild 2) bietet
sowohl die Flexibilität der programmierbaren
Hardware als auch die
Programmierbarkeit und die Verarbeitungsleistung
eines DSPs.
Die dargestellten Funktionsblöcke
sind Hardware-Module, die entweder
fest vorgegeben oder anwenderspezifisch
konfigurierbar sind.
Dabei implementiert die linke Funktionsblockreihe
die Signalvorverarbeitungsmodule
mit vier unabhängigen
Kameraeingängen, die mittlere
Reihe realisiert das Back-end-Processing
mit drei unabhängigen
CPUs für verschiedene Algorithmen
und die rechte Reihe stellt einen
System Kommunikationscontroller
zur Verfügung, um den AIDA-Controller
mit den im Fahrzeug vorhan-
© automotive
denen Schnittstellen zu verbinden.

14lA UTOMOTIVE
3-4.2009l TITEL
© Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern
Bild 3: FPGA-Entwicklungssystem.
Am unteren Rand ist die Speicherverwaltung mit zwei
DDR2-Speichercontrollern und einem Flash-Controller
abgebildet. Zusätzlich zum externen Speicher steht noch
ein internes SRAM zur Verfügung. Der dargestellte Funktionsumfang
stellt den Maximalausbau dar. Je nach Anforderungen
werden alle oder nur ein Teil der Blöcke in den
Controller integriert.
Design-Methodik
Der AIDA-Controller wird auf der Basis von Programmierbarer
Logik entwickelt und steht dem Entwickler als sogenanntes
Design-Template zur Verfügung. Die festen Funktionsmodule
sind dabei bereits im Design vorhanden und
miteinander verbunden. Die konfigurierbaren Blöcke werden
mithilfe von Design Werkzeugen weitgehend automatisch
generiert und in das Design eingebaut. Am Beispiel
des oben genannten Spurwechselassistenten soll
hier der Entwicklungsvorgang näher betrachtet werden.
Der verwendete LDW-Algorithmus stammt dabei von der
Firma Elektrobit Automotive und basiert auf dem PRE-
VENT SAFELANE Projekt der Europäischen Gemeinschaft.
Die Entwicklung eines LDW-Systems erfolgt zunächst am
PC und benutzt eine Reihe von Test-Videos, um die Qualität
des Algorithmus direkt überprüfen zu können. Das Entwicklungssystem
kann dazu Echtzeitvideos von Fahrszenen auf
eine Festplatte aufzeichnen und dem Algorithmus zur Bearbeitung
anschließend wiedergeben. Die Hardware für beide
Entwicklungsphasen ist in einem FPGA integriert. Dabei ist
das FPGA aufgeteilt in einen Video-Streamingblock und in
den eigentlichen AIDA-Block. Beide Blöcke arbeiten dabei
unabhängig voneinander und beeinflussen sich auch bezüglich
der Verarbeitungsleistung nicht gegenseitig. Während
der Entwicklung wird hauptsächlich der Video-Streamingblock
für die Fahrszenenwiedergabe verwendet. Im endgültigen
AIDA-Controller werden dann die Streaming-Eingänge
direkt mit Kameras verbunden.
Der Streamingblock hat ein Anwenderinterface mit Bildschirm
und Touchscreen. Sein Festplatteninterface und die
dazugehörige Software stellt ein Filesystem zur Verfügung,
aus dem bis zu vier VGA-Videokanäle gleichzeitig
auf den AIDA-Block aufgespielt werden
können.
Der AIDA-Teil ist rund um den Nios II-Prozessor
aufgebaut, einen flexiblen 32-bit
RISC Controller mit folgenden zusätzlichen
Basiselementen
■ Performance Counter für das Code
Profiling,
■ Nachrichtenspeicher zur Kommunikation
mit der Streaming-Schnittstelle,
■ Grafikcontroller, um verarbeitete Bildszenen
abspielen zu können.
Auch für die Software des AIDA-Controllers
steht eine Designvorlage zur Verfügung, die
aus vordefinierten Elementen besteht und
© automotive nur um den Anwendercode erweitert werden
muss. Eine Profiling-Phase dient zur
Identifikation von Softwareteilen, die eine
Hardwarebeschleunigung erforderlich machen. Dabei gibt es
zwei verschiedene Fälle zu berücksichtigen:
■ Verarbeitet der Algorithmusteil die Pixeldaten des Videosignals
nacheinander, dann wird dieser Teil zu einem Vorverarbeitungsblock
im Systemgenerator, dem sogenannten
SOPC-Builder. Der Eingang eines solchen Blockes ist die
Video-Streamingschnittstelle. Die verarbeiteten Daten werden
in einem Bildspeicher abgelegt. Dieser Teil des Algorithmus
wird oft in Tools wie MATLAB/SIMULINK entwickelt.
■ Benötigt der Algorithmusteil den wahlfreien Zugriff auf
die Punkte in einem Bildspeicher mit einem weiteren Bildspeicher
für die Ergebnisse, dann handelt es sich um eine
Backend-Verarbeitung. Dieser Teil des Algorithmus ist in der
Regel C/C++ Softwarecode.
Diese beiden Fälle treten in realen Fahrerassistenzalgorithmen
in der Regel gleichzeitig und teilweise auch mehrfach
auf. Zur Hardware-Beschleunigung von Signalvorverarbeitung
und der Backend-Verarbeitung werden zwei
unterschiedliche Methoden eingesetzt.
Die Signalvorverarbeitung berechnet Operationen direkt auf
dem Videostream und ist daher sehr rechenintensiv. Eine
Hardwarebeschleunigung ist meist unumgänglich, da sehr
viele arithmetische Operationen durchzuführen sind. Wird
zum Beispiel eine einzige MAC-Instruktion mit Multiplikation
und Aufsummierung für jeden der 307.200 Pixel eines VGA-
Bildes verlangt, so benötigt ein Standard-DSP mit einer Verarbeitungseinheit
genau 307.200 Zyklen zu deren Berechnung.
Ein Signalvorverarbeitungsblock in Hardware kann
jedoch viele dieser Operationen parallel ausführen und benötigt
deswegen wesentlich weniger Zeit für die Verarbeitung
eines kompletten Bildes. Die Algorithmen der Signalvorverarbeitung
werden oft in MATLAB/SIMULINK entwickelt,
bevor sie in C++ übersetzt werden. Das Tool DSP Builder
arbeitet direkt mit MATLAB/SIMULINK zusammen und kann
aus der grafischen Darstellung des Algorithmus automatisch
einen Hardwarebeschleunigungs-Block generieren. Im Beispiel
der LDW-Funktion benötigt der Signalvorverarbeitungsblock
etwa 70 % der gesamten Rechenzeit. Eine Implementierung
in Hardware mithilfe des automatischen Design
Flows benötigt nur noch ca. 1% der Rechenzeit und ver-

TITELl AUTOMOTIVE
3-4.2009l15
© Carl Hanser Verlag GmbH & Co.KG, München, www.hanser-automotive.de; Nicht zur Verfügung in Intranet- u.Internet-Angeboten oder elektron. Verteilern
braucht 2500 Logikelemente, das sind etwa
3% der zur Verfügung stehenden Ressourcen
eines AIDA-Controllers.
Im Unterschied zur Signalvorverarbeitung arbeitet
das Backend-Processing mit wahlfreiem
Zugriff auf die einzelnen Pixel eines Videobildes.
Ein Beispiel dafür ist die Korrektur des Bildes
von einer Weitwinkellinse, wie sie oft in Rükkschaukameras
zum Einsatz kommt. Dieser
Algorithmus ordnet die Pixel des Eingangsbildes
neu an und führt eine Interpolationsfunktion
aus. Die Pixelzuordnung selbst ist ideal für
eine sequentielle Abarbeitung in einem RISC
Prozessor geeignet. Da die Interpolation einige
Rechenzeit benötigt, wird hier direkt aus dem
C-Code mithilfe des Tools C2H automatisch
Hardware zur Beschleunigung generiert. Dieser Block wird
dabei mit einem DMA-Mechanismus an das Prozessorsystem
angeschlossen und die Funktion im C-Code ist dann nur
noch ein Kommunikationsaufruf zur Hardware.
Entwicklungsplattform
Bei Fahrerassistenzsystemen ist es besonders wichtig, möglichst
früh einen Prototyp auf der Zielhardware zu testen, um
damit die voraussichtlichen Kosten und den Systemumfang
abschätzen zu können. Der AIDA-Controller wurde für die
PARIS-Infotainment Plattform (Bild 4) entwickelt, die zum
Aufbau von Prototypen für Head-Units und Fahrerassistenzsysteme
eingesetzt werden kann. Dazu stehen zwei LCD-
Bildschirme, das Mainboard mit den Systemschnittstellen
und dem Prozessormodul mit dem FPGA sowie eine Festplatte
zur Verfügung. Das Mainboard hat eine ganze Reihe von
Anschlüssen für alle gebräuchlichen Infotainment Schnittstellen,
die in dem FPGA integriert werden können.
National Instruments Germany GmbH
Konrad-Celtis-Str. 79 • 81369 München
Tel.: 089 7413130 • Fax: 089 7146035
ni.com/germany • info.germany@ni.com
Bild 4: PARIS Entwicklungsplattform für Fahrerassistenzsystem Prototypen.
Zusammenfassung
Die FPGAs und HardCopy-ASICs von Altera stellen eine
attraktive Lösung für Fahrerassistenzsysteme dar. Mit paralleler
Signalverarbeitung in Hardware sowie prozessorbasierter
Verarbeitung wird im Vergleich zu konventionellen
Systemarchitekturen eine weitaus höhere Systemleistung
zu signifikant niedrigeren Kosten erreicht. Die vorgestellte
Design-Methodik ermöglicht darüber hinaus einen direkten
und automatischen Übergang von C++ Code oder MAT-
LAB/SIMULINK Modellen in die Hardware, ohne dass eine
Hardware-Beschreibungssprache verwendet werden muss.
(oe)
Simulation - Prüftechnik - Versuchsauswertung
Dr. Axel Zimmermann ist Market Development
Manager Europe Automotive bei
Altera.
Altera
@ www.altera.com
7. Technologietag “Prüfstandskonzepte in der Automobilindustrie”
Am 26. Mai 2009 im CongressPark Wolfsburg
Agenda und kostenfreie Anmeldung: ni.com/germany/automotivetag
© automotive
Der NI-Technologietag bietet Ihnen:
• ein hochkarätiges Vortragsprogramm
• zwei begleitende Workshops
• eine umfangreiche Fachausstellung
Diskutieren Sie mit NI-Experten sowie zahlreichen Ausstellern und Fachkollegen und holen Sie sich neue Impulse für Ihre
Aufgabenstellungen! Die Teilnahme an der ganztägigen Veranstaltung ist kostenfrei.
© 2009 National Instruments Corporation. Alle Rechte vorbehalten. National Instruments, NI und ni.com sind Warenzeichen von National Instruments. Andere erwähnte Produkt- und Firmennamen sind Warenzeichen oder Handelsbezeichnungen der jeweiligen Unternehmen. Druckfehler, Irrtümer und Änderunge vorbehalten.