50405.jpg

Bild 1: Typischer Datenfluss von der Erfassung über die Verarbeitung bis zur Bewertung.

Bild 1: Typischer Datenfluss von der Erfassung über die Verarbeitung bis zur Bewertung.Xilinx

Dem Automobilsektor wird häufig vorgeworfen, nur langsam auf Trends in der Konsumelektronik zu reagieren, oder es dauere oft mehrere Generationen, um Funktionen zu integrieren, die der Fahrer als Mehrwert wahrnimmt.  Dennoch ist die treibende Kraft hinter fortschrittlichen Fahrerassistenzsystemen (ADAS) im Allgemeinen nicht Druck durch die Konsumenten, sondern eher das Ergebnis der Bemühungen der Automobilhersteller, Sicherheitsfunktionen in ihre Fahrzeuge zu integrieren, die bald gesetzlich vorgeschrieben werden könnten. In erster Linie sind die heute in der Entwicklung befindlichen Fahrerassistenzsysteme stark auf die Integration multipler Kamerabilder fokussiert – und zwar gekoppelt mit fortschrittlichen Sensoren, um gleich eine ganze Anzahl von Hilfen zu bieten: Spurwechselassistent, Spurhalteassistent sowie die Erkennung von Fußgängern bei höheren Geschwindigkeiten. 3D-Panoramabilder der Fahrzeugumgebung mit Bild-in-Bild-Darstellung der Rückfahrkamera unterstützen den Fahrer auch bei geringer Geschwindigkeit. Es gibt bereits Initiativen wie die Euro-NCCAP-Autonome-Emergency Braking-Systems-Initiative, deren Einführung für 2014 geplant ist, die Herstellern dabei helfen, sich auf derartige sicherheitsrelevanten Aspekte zu konzentrieren. Die Implementierung solcher  rechenintensiven Funktionen muss möglichst so erfolgen, dass sich die Materialkosten insgesamt nicht erhöhen.

Die Analyse von Videobildern ist wohl für jedes Embedded-System die wahrscheinlich prozessorintensivste Aufgabe. Daher stellt Videoanalyse in Echtzeit von mehreren Kameras gleichzeitig die größte denkbare technische Herausforderung dar. Bei multiplen Kameras ergibt sich hieraus ein inhärent paralleler Prozess, der nach ausreichend Leistung verlangt.

GemäßBild 1kommt der Datenfluss von (einer ständig steigenden Anzahl) Kameras (einschließlich Infrarot), aber auch von Sensoren die auf Mikrowellentechnik oder Radar basieren. Dies generiert eine Riesenmenge an Daten, die verarbeitet, wieder zusammengefügt und anschließend auf Pixelebene zur Darstellung analysiert werden müssen – ein Vorgang, der zunehmend als Sensordatenfusion bezeichnet wird.

Entwickler-Sicht

Vom Engineering-Standpunkt aus ließe sich dieser Datenfluss auf einen Mikrocontroller, einen DSP und ein FPGA aufteilen (Bild 2). Dieser klassische Datenfluss ist per se korrekt; jede Funktion hat eine spezielle Hardwarestufe, die in der Lage ist, ihre Aufgabe für einen einzelnen Sensor oder eine Gruppe von Sensoren (wie Kameras für Panorama-Aufnahmen) zu übernehmen. In einer Fahrerassistenzapplikation liegt der Nachteil jedoch in der begrenzten Leistungsfähigkeit und Flexibilität dieser Methode.

Bild 2:Herkömmliche Aufteilung der Verarbeitung in mehreren Bausteinen.

Bild 2:Herkömmliche Aufteilung der Verarbeitung in mehreren Bausteinen.Xilinx

Beim Einsatz einer Multi-Chip-Architektur muss das Management der Datenflüsse und Schnittstellenbandbreiten zwischen den Bausteinen mit großer Sorgfalt erfolgen. Darüber hinaus könnte das Ändern einer der Funktionen oder selbst nur das Modifizieren eines Algorithmus‘ innerhalb einer Funktion ein vollständiges Re-Engineering der Baustein-Schnittstellen und eine Verteilung der Funktionen bedeuten – selbst wenn die Systeme sauber aufgebaut sind, um einen geeigneten Datenfluss für einen spezifischen Satz an Funktionen zu bieten. Auch wenn eine höhere Sensor-Fusion und/oder Analyseleistung erforderlich wird, kann eine Plattform mit festgelegten Hardware-Ressourcen nicht ausreichend Leistung aufweisen, um diese zusätzliche Verarbeitung mit zu übernehmen. Dies hebt die Notwendigkeit und den Vorzug der parallelen Datenverarbeitung besonders hervor.

DSP?

DSP-Hersteller entwickeln eifrig Bausteine, die auf den Markt der Fahrerassistenzsysteme abzielen, aber ihr Lösungsvorschlag für die Notwendigkeit einer stärkeren Parallelverarbeitung besteht typischerweise darin, ihre Schaltung um spezielle Hardwarebeschleuniger zu ergänzen. Obwohl dies eine Lösung sein kann, ist ihre Brauchbarkeit nur auf eine relativ eingeschränkte Implementierung begrenzt. Es ist auch prinzipiell schwierig, die auf Universal-DSPs ablaufenden Algorithmen zu optimieren – ein Design-Prozess, der mit dem Hinzufügen von dedizierten hardware-basierten Beschleunigern noch deutlich komplexer werden kann. Eine praktikablere und erweiterbare Lösung bestünde darin, das gesamte ADAS-System in eine einzige Plattform zu integrieren, welche die Leistungsfähigkeit und Flexibilität besitzt, um einen großen Bereich von Fahrerassistenzaufgaben abzudecken, wobei die Plattform mit ihren Aufgaben wächst, wenn sich die Anwendungen weiter entwickeln.

Parallelismus

Das Überführen all dieser Funktionen in ein FPGA nutzt den Vorteil der wichtigsten FPGA-Charakteristik: Parallelismus. Obwohl konventionelle FPGAs bereits so entwickelt sind, dass sie sehr flexibel sind, führt die All-Programmable-SoC-Plattform Zynq-7000 diese Eigenschaft in eine neue Dimension weiter. Als erste programmierbare SoC-Plattform der Branche kombiniert sie die Flexibilität und Erweiterbarkeit eines FPGAs mit der Leistungsfähigkeit dedizierter DSP-Funktionsblöcken und der Vielseitigkeit eines Dual-Core-ARM-Coretx-A0-MPCore-Subsystems.

Im Vergleich zu einer Lösung mit drei Bausteinen kommt ein solcher Einzel-Baustein mit einem geringeren Platzbedarf und einer geringeren Verlustleistung aus. Beide Werte verbessern sich drastisch, wenn ein Zynq-7000-Baustein zum Einsatz kommt, aber die hohe Integration steigert zusätzlich auch noch die Systemleistung. Das All-Programmable-SoC Zynq-7000 hat über 3000 Verbindungen zwischen dem ARM-Core und der FPGA-Fabric, um eine optimierte Schnittstelle zwischen den Hard- und Software-Bereichen zu bieten. Die Methode der Verwendung eines integrierten Chips ist ganz allgemein deutlich effizienter als ein diskreter Aufbau – und zwar unabhängig davon, ob es sich dabei um ein spezielles SoC, ein ASSP oder sogar ein ASIC handelt. Eine programmierbare SoC-Plattform bietet aber all die Vorzüge dieser Bausteine, jedoch ohne ihre Nachteile.

Bild 3: Flexible und effiziente Verarbeitung der Daten im SoC Zynq 7000.

Bild 3: Flexible und effiziente Verarbeitung der Daten im SoC Zynq 7000.Xilinx

Gemäß Bild 3 liefert die FPGA-Fabric die Möglichkeit, wie benötigt spezielle Hardware-Beschleunigungsblöcke zu implementieren; andere Lösungen wären durch die festgelegte Funktion eines ASSPs, ASICs oder konventionellem SoCs eingeschränkt. Mit dieser Methode ergeben sich konfigurierbare Hard-/Software-Partitionen, was es den Entwicklern erlaubt, genau die richtige Datenverarbeitungsleistung auf die optimale Weise zu implementieren.

Erhöhte Design-Produktivität

Die Entwicklung eines Fahrerassistenzsystems auf einer programmierbaren SoC-Plattform ermöglicht nicht nur die Integration aller Funktionen, die in einem ADAS-System benötigt werden und die sonst von einem diskreten DSP und MCU-Baustein übernommen werden müssten, sondern sie senkt auch die gesamten Stückkosten (BOM-Cost) um mehr als 25 Prozent, während sich die reine Datenverarbeitungsleistung verdoppelt. Zusätzlich reduziert diese Einchiplösung den Platzbedarf wesentlich, der zur Implementierung eines kompletten Subsystems wie zum Beispiel einer Rückfahrkamera nötig ist. Dies ist ein Hauptgrund für Automobilhersteller und Tier-1s, ihr Augenmerk darauf zu richten, da neue Systeme diskret und so unauffällig wie nur möglich hinzu gefügt werden müssen.

Die Fokussierung auf eine integrierte Plattform verkürzt auch den Entwicklungsprozess. Xilinx hat mit ausgewählten Anbietern im Automobilmarkt Partnerschaften geschlossen, um die OEMs mit optimierter lizenzierbarer IP zu versorgen, die für die Entwicklung von Fahrerassistenzsystemen auf Basis des Zynq-7000-AP-SoC nötig ist. Dies wird von einer speziellen Entwicklungsplattform unterstützt, dem seit Dezember 2012 erhältlichen „LogiADAK Zynq-7000 SoC Automotive Driver Assistance Kit“ des Xilinx-Partners Xylon.

Auf einen Blick

ADAS mit Zynq
Eine einzige Plattform ist besonders sinnvoll in einer Anwendung, in der ein großer Datenfluss und eine umfassende Datenanalyse die wichtigsten Eigenschaften sind. Nur eine Plattform, die den richtigen Mix an Flexibilität und Leistungsfähigkeit bietet, kann diesen Anwendungsbereich erfolgreich adressieren. Das ADAS-Ecosystem von Xilinx soll es den Automobilherstellern und Tier 1s ermöglichen, sich nicht nur auf die ADAS-Applikation zu konzentrieren sondern auch die Entwicklung zu beschleunigen.

Was die SoC-Plattform Zynq-7000 ist auf Grund ihrer hohen Flexibilität besonders geeignet für diesen Anwendungsbereich. So lassen sich die Grenzen der Hard- und Software in neue Dimensionen verschieben. Dank des vollintegrierten ARM-Cortex-A9-MPCore-Subsystems können Designteams frei entscheiden, ob eine Funktion am besten in der FPGA-Fabric oder im Prozessorsystem implementiert werden soll. Im Falle des ADAS-Kits von Xylon haben Xilinx und seine Partner diese Entscheidung bereits für den Anwender getroffen und ihre gebündelte IP auf die Zynq-7000-SoC-Plattform optimiert.

Algorithmus für den optischen Datenfluss

Der Xilinx-Alliance-Partner Digital-Design-Corporation hat beispielsweise einen Algorithmus für den optischen Datenfluss entwickelt, der für den Zynq-70000-Baustein optimiert wurde. Bisher erfolgte die Portierung dieser Funktionalität typischerweise auf einen DSP, und in diesem Szenario würde die Lösung dann wegen der begrenzten Verarbeitungsressourcen des DSPs den Speicher extensiv nutzen. In der programmierbaren Fabric eines FPGAs sind DSP-Ressourcen praktisch im Überfluss vorhanden, was quasi von selbst zu einer massiv parallelen Datenverarbeitung führt. Diese Implementierung hängt wesentlich mehr von den Verarbeitungsfunktionen selbst ab und weniger von der Speichernutzung, was sich perfekt mit den in einem FPGA vorhandenen Ressourcen deckt. Xylon hat auch bereits eine Erfolgsgeschichte in der Entwicklung und Auslieferung von fortschrittlichen Lösungen für den Automobilmarkt hinter sich, wobei Xylons „Logic-Block-IP“ für die Zynq-7000-Plattform als Basis dient. Diese erlaubt es, neue Funktionen einfach zu integrieren, was wiederum einen direkten Weg zum Prototyp und in die Produktion eröffnet. Durch das Angebot optimierter IP können die Entwickler den Zeitaufwand zur Realisierung eines Fahrerassistenzsystems wesentlich verringern: in einigen Fällen um bis zu 12 Monate.

ADAS = Sicherheit + Komfort

ADAS wird für die Automobilhersteller und Tier-1s schnell zu einer Funktion, die sie unbedingt anbieten müssen – nicht zuletzt wegen der drohenden gesetzlichen Vorschriften. Die Verordnungen treiben die potenziellen Sicherheitsvorteile zwar voran, aber es wird die Nachfrage der Konsumenten sein, die ADAS-Systeme über die reinen Sicherheitsfunktionen hinaus mit Eigenschaften wie Parkkameras, Verkehrszeichenerkennung und fortschrittlicher Navigation ausstattet. Die Anforderungen an die elektronischen Systeme wird über die Zeit mit der schrittweisen Einführung der Funktionen steigen – und zwar auf eine ähnliche Art und Weise wie der mobile Sektor die Evolution von portablen Geräten vorangetrieben hat.

Thorsten Kistler

ist EMEA Automotive Product Marketing Manager bei Xilinx in München.

(av)

Sie möchten gerne weiterlesen?

Unternehmen

Xilinx GmbH

Willy-Brandt-Allee 4
81829 München
Germany