Automobilentwicklung: Der lange Weg vom Prototyp zur Serienreife

Heutzutage sind Automobilhersteller gezwungen, neue Systeme binnen Monaten statt Jahren zu entwickeln. Historisch betrachtet wäre die Entwicklung eines neuen Systems allerdings einem strengen und unflexiblen Prozess gefolgt: Nach der gründlichen Spezifikation eines zu entwickelnden Systems hätten die Verantwortlichen verschiedene Zulieferer angefragt, um ein entsprechendes technisches und kommerzielles Angebot abzugeben. Der aus dieser Riege ausgewählte Zulieferer hätte dann das entsprechende System entwickelt und produziert, wobei er verschiedene Zwischenstufen (A-Muster, B-Muster, C-Muster) geliefert hätte, die über einen zunehmenden Funktionsumfang verfügten und sich dem Endprodukt schrittweise genähert hätten.

Zwei große Änderungen der letzten Jahre

Bild 1. Integrierte Systeme für autonomes Fahren bestehen aus mehreren Sensoren und Subsystemen. shutterstock_1096130420

Die Evolution von fortgeschrittenen Fahrerassistenzsystemen (zum Beispiel Abstandsregeltempomat oder Notbremsassistent) hin zum autonomen Fahren (Fahrzeuge, die komplett oder in spezifischen Situation autonom agieren, beispielsweise bei Autobahnfahrten) ist eine der großen Veränderungen der letzten Jahre. Obwohl die Entwicklung langsamer als ursprünglich prognostiziert voranschreitet, betreibt die Automobilbranche einen erheblichen Aufwand, um unabhängige Fahrerassistenzsysteme, das heißt ein oder wenige Sensoren sowie ein Steuergerät, durch hochintegrierte Kombinationen verschiedener Fahrerassistenzsysteme zu ersetzen, um letztendlich autonomes Fahren zu ermöglichen. Dafür ist es typischerweise nötig, Dutzende von Ultraschall-, Radar-, Lidar- und CMOS-Sensoren mit mehreren Steuergeräten zu verknüpfen, mit dem Ziel einen virtuellen Piloten zu bilden. Es ist offensichtlich, dass die Anforderungen an die verfügbare Rechenleistung hierfür außerordentlich zugenommen haben (Bild 1).

Der zweite große Wandel ist der Weg vom maschinellen Sehen zum maschinellen Lernen. Während die ersten Fahrerassistenzsysteme, die in automobilen Anwendungen zum Einsatz kamen, auf Radar- oder Ultraschallsensoren basierten, bilden mittlerweile Kameras (CMOS-Sensoren) das Rückgrat dieses Anwendungsbereichs. Der Einsatz verschiedener Algorithmen sorgt für die Extraktion von Bildinformationen wie Fahrbahnmarkierungen, Hindernissen oder Verkehrszeichen und ermöglicht so Anwendungen wie Fußgängererkennung, Verkehrszeichenerkennung oder Fahrspurhalteassistenten. Im Zuge der Entwicklung mit immer komplexeren Anwendungen und der vermehrten Integration von Software-Funktionen griff die Industrie auf eine alte und fast vergessene Technologie zurück – neuronale Netze. Seit mittlerweile fast zehn Jahren arbeiten nun Entwickler daran, verschiedene neuronale Netzwerkarchitekturen zu entwickeln, zu trainieren und einzusetzen, und zwar angepasst an eine spezifische Aufgabe und in einer ebenso leistungsfähigen wie effizienten Weise.

Für autonomes Fahren neue Ansätze entwickeln

Wie bereits dargestellt erfordert der evolutionäre Wechsel von Fahrerassistenzsystemen hin zum autonomen Fahren eine deutliche Überarbeitung des existierenden Ansatzes. Systementwickler müssen noch Probleme lösen, die in früheren Produktgenerationen nicht aufgetreten waren. Viele Fahrzeughersteller und Komponentenzulieferer adressieren dies mit Hilfe von Prototypen und Konzeptstudien (Proof of Concept; PoCs). Bei der Prototypenentwicklung lassen sich prinzipiell zwei Ansätze unterscheiden: reine Machbarkeitsstudien, die anschließend verworfen beziehungsweise eingemottet werden, und solche Prototypen, die als Ausgangsbasis für die Entwicklung eines Serienprodukts dienen und demzufolge schrittweise in die Serienproduktentwicklung Einzug erhalten. Die Entscheidung für die eine oder andere Ausprägung eines Prototyps erfolgt projektspezifisch, wobei die Grenzen in der Praxis oft verschwimmen.

Zu einem nicht unerheblichen Teil können Versuchsaufbauten virtuell, das heißt, mit Hilfe moderner Simulationsmethoden erfolgen. Allerdings müssen Algorithmen oder Systemeigenschaften letztendlich ihre Funktion und Umsetzbarkeit auch in einem realen System beweisen. Hierfür die richtige Rechnerplattform zu finden, ist mittlerweile kein leichtes Unterfangen mehr, nachdem die Anforderungen künftiger Systeme in der Regel höher sind, als dass gerade verfügbare Plattformen diese erfüllen könnten. Typischerweise ist bei einem Prototypensystem für eine automobile Anwendung lediglich darauf zu achten, dass es sich im Kofferraum eines regulären Fahrzeugs unterbringen lässt. Deshalb kommen in vielen Fällen Prototypensysteme zum Einsatz, die aus High-end PCs, Servern, GPU-basierten Entwicklungsplattformen oder FPGA-basierten Beschleunigerkarten zusammengesetzt sind.

Dieser Ansatz erscheint sehr praktikabel, wenn es darum geht, die Anwendbarkeit eines neu entwickelten Algorithmus, den Aufbau eines neuronalen Netzes oder ein völlig neues Systemkonzept zu überprüfen. Andererseits können so bei der Überführung des Prototypensystems in ein Serienentwicklungsprojekt schwerwiegende Probleme auftreten, da dort verschiedene Randbedingungen zu berücksichtigen sind.

Wichtige Randbedingungen

Bild 2. Green Hills Software’s Integrity Echtzeitbetriebssystem wurde speziell entwickelt, um die höchsten Anforderungen hinsichtlich Funktions-/Datensicherheit und Leistungsfähigkeit zu erfüllen. Green Hills

In der Regel ist bei prototypischer Hardware aufgrund der Verfügbarkeit von aktiver Kühlung die Verlustleistung kein limitierender Faktor. Eingebettete Systeme, speziell in Automotive-Anwendungen, müssen allerdings meist mit passiver Kühlung auskommen. Deshalb ist eine Hardware-Plattform mit entsprechend geeignetem Verhältnis von Rechenleistung zu Verlustleistung auszuwählen.

Obwohl Sicherheit in Prototypen kaum eine Rolle spielt, kann sie – natürlich abhängig von der finalen Systemarchitektur – im Serienprojekt verbindlich vorgeschrieben sein. Hierfür sind bestimmte Eigenschaften der eingesetzten Hardware- und Software-Komponenten in Betracht zu ziehen: ppm-Raten, (Vor-) Zertifizierungen, Leistungsreserven für Redundanz, spezielle Sicherheitsmechanismen etc.

In der Praxis hat sich gezeigt, dass Datensicherheit in jeder Phase eines Entwicklungsprojekts zu berücksichtigen ist, um eine hohe Widerstandsfähigkeit gegenüber Angriffen gewährleisten zu können. Deshalb ist bereits bei der Auswahl von Hardware- und Software-Komponenten auf entsprechende Eignung zu achten. Versuche, nachträglich Datensicherheit zu implementieren, haben sich in der Praxis als ineffektiv erwiesen. Während bei Prototypen das Ziel darin besteht, eine Funktion zu testen, soll ein Serienentwicklungssystem zusätzlich die Aspekte Sicherheit (Funktions- und Datensicherheit), Integration (in oder mit anderen Systemen), Erweiterungsfähigkeit (OTA-Upgrades) sowie Skalierbarkeit abdecken. Zuletzt erscheinen die Kosten für einen Prototypenaufbau auf den ersten Blick völlig entkoppelt von den Kosten des anschließenden Serienentwicklungsprojekts, wobei diese im ersten Fall nur eine untergeordnete Rolle spielen, im letzten Fall allerdings von großer Bedeutung sind. Trotzdem gibt es eine direkte Verbindung zwischen der technischen Distanz zwischen Prototyp und Serienprodukt, da Unterschiede, zum Beispiel bei Prozessor-/System-Architektur, Betriebssystem oder Middleware, den Aufwand und die Kosten der Portierung der Anwendung auf die Zielplattform beeinflussen.

COTS-Plattform

Eine Möglichkeit, die oben aufgelisteten Aspekte anzugehen, ist der Einsatz einer COTS-Plattform (Custom off the shelf), vor allem wenn diese Plattform einen Weg zur Serienentwicklung aufzeigt, der das Verhältnis von Kosten zu Nutzen verbessert. Als Beispiel für eine derartige Plattform, speziell auf Systeme für autonomes Fahren zugeschnitten, ist die Bluebox von NXP. Sie deckt alle Anforderungen an ein leistungsfähiges Automotive-System ab und erfüllt gleichzeitig weitere Rahmenbedingungen der Bereiche Funktionssicherheit und Zuverlässigkeit. Die Bluebox ist ASIL B (compute and vision acceleration) beziehungsweise ASIL D (subsystem and dedicated interfaces) zertifiziert und nutzt dazu verschiedene NXP-Prozessoren. Zum Beispiel dient ein S32V für Anwendungen im Bereich Vision und Sensordatenfusion, ein Layerscape 2084A stellt seine hoch performanten Rechenfähigkeiten zur Verfügung und ein Mikrocontroller der S32R-Reihe kann für Anwendungen mit harten Echtzeitanforderungen eingesetzt werden.

Um Funktions- und Datensicherheit bereits in Prototypen zu implementieren, lässt sich zudem ein Echtzeitbetriebssystem (RTOS) wie Integrity von Green Hills Software einsetzen, welches die Hardware-Eigenschaften aus diesen Bereichen in die Software-Domäne hinein erweitert. Mit seiner Mikrokernel-Architektur sowie der funktions- und datensicheren Separierungstechnologie kann Integrity sowohl native Anwendungen (generische oder mit hoher Kritikalität) wie auch Gastbetriebssysteme in voneinander isolierten Partitionen ausführen (Bild 2).

Bild 3. Dem Einsatz eines hochentwickelten Entwicklungs- und Debugging-Werkzeugs kommt eine Schlüsselrolle beim Übergang von prototypischen Algorithmen zu produktionsreifen Funktionen zu. Green Hills

Als Ergebnis bietet die Kombination der NXP Bluebox und Green Hills Software Integrity RTOS zahlreiche Vorzüge beim Einsatz in Prototypen. Die heterogene Hardware-Architektur bietet hohe Rechenleistung und Flexibilität, um neue Algorithmen beziehungsweise Anwendungen zu entwickeln und/oder zu testen, speziell für Anwendungen im Bereich autonomes Fahren, SAE Level 3 oder höher.

Der Formfaktor der Bluebox ermöglicht eine einfache Integration in Testfahrzeuge oder -aufbauten, um Algorithmen und Anwendungen gründlich zu testen. Die Eigenschaften des Echtzeitbetriebssystems sollen eine Störfreiheit zwischen verschiedenen Software-Partitionen garantieren und erlauben somit eine mit dem Endprodukt weitgehend identische Software-Architektur.

Die Virtualisierung, zum Beispiel von Linux in einer Integrity-Partition, erlaubt eine einfache Integration von Forschungs- oder Testalgorithmen und -konzepten in eine Serienentwicklungsumgebung. Außerdem sind Hardware- und Software-Architektur nicht auf den Prototypeneinsatz beschränkt, da sich alle Elemente für den Einsatz in einem Serienentwicklungsprojekt eignen oder sich mit minimalem Aufwand entsprechend portieren lassen.

Vom Prototyp zur Produktion

Der Übergang vom Prototyp zur Serienentwicklung ist deutlich komplizierter und aufwendiger als nur ein Aufräumen von Dateien, dem Entfernen von Test-/Debug-Strukturen oder der Wechsel zu automotive-qualifizierten Bauteilen. Grundsätzlich sind die folgenden Fragen zu beantworten:

Welche verfügbare Hardware-Plattform erfüllt alle Anforderungen hinsichtlich Rechenleistung, Leistungsaufnahme, Verfügbarkeit (kurz- und langfristig), Qualität, Support-Strukturen, Kosten sowie Daten- und Funktionssicherheit? Zweitens, welche für die Zielplattform verfügbare Software erfüllt alle Anforderungen hinsichtlich Leistung (Durchsatz, Latenz, …) sowie den oben genannten Anforderungen? Und zuletzt, ist der Zeitplan angemessen, das heißt ist genügend Zeit eingeplant für Entwicklung, Integration, Test und Verifikation sowie Zertifizierung?

Werden von Beginn an bezüglich Hardware und Software die richtigen Entscheidungen getroffen, sinkt die Wahrscheinlichkeit, dass obige Fragen zu unnötig hohen Kosten führen. Zusätzlich ist es an dieser Stelle wichtig, die Zeitpläne des Serienprojekts mit der Verfügbarkeit der verschiedenen Hardware- und Software-Komponenten abzugleichen. Speziell bei Themen, die übergreifende Hardware und Software betreffen – Funktions- und Datensicherheit seien hier stellvertretend genannt –, ist eine enge Abstimmung mit den entsprechenden Zulieferern angeraten.

Zur Veranschaulichung für Funktionssicherheit sei eine Fahrzeugfunktion angenommen, die den Anforderungen nach ASIL B genügen soll. In automobilen Systemen ist dies gewöhnlich mit einem ASIL-zertifizierten Mikrocontroller gelöst, auf dem ein Classic Autosar Stack ausgeführt wird. Handelt es sich um eine komplexere Funktion für eine Anwendung im Bereich autonomes Fahren, kann eventuell ein normaler Mikrocontroller hinsichtlich der geforderten Rechenleistung nicht ausreichen, was letztendlich zu einer veränderten (und teureren) Bauteilliste führen würde. Ein anderer Ansatz wäre allerdings, „ASIL Funktionen“ auf „nicht-ASIL Hardware“ auszuführen. Hierzu braucht es ausgeklügelte Software-Mechanismen, um potenzielle Hardware-Fehler zu kompensieren, wie sie in der Norm ISO26262 beschrieben sind. So lässt sich beispielsweise rechenintensive und gleichzeitig gemäß Funktionssicherheit zertifizierte Software auf der Kombination aus einem ARM-Cortex-A-Kern (NXP Layerscape 2084A) und dem Echtzeitbetriebssystem Integrity (Green Hills Software) ausführen. Die optimale Hardware- und Software-Architektur ist dabei ein Schlüsselelement, um die Systemkosten im Griff zu behalten, die wiederum direkt von der Flexibilität der eingesetzten Hardware-/Software-Module und der Zusammenarbeit mit deren Zulieferern abhängt.

Die eingesetzten Werkzeuge sind entscheidend

Im Zuge des Entwicklungsprojekts und entsprechend der vorgegebenen Meilensteine integrieren die Entwickler die prototypisch entwickelten Merkmale und Funktionen stufenweise in das Serienprodukt und auf das vorgegebene Qualitätsniveau. Um dabei die Vorgaben hinsichtlich Zeitschiene und Projektbudget einzuhalten, ist eine geeignete Entwicklungs- und Debugging-Umgebung unabdingbar (Bild 3). Wichtig ist dies unter anderem bei komplexen Frameworks wie etwa dem Robot Operating System (ROS), das die schnelle Implementierung von für das autonome Fahren benötigten Algorithmen ermöglicht. Das sind typischerweise komplizierte Software-Module, die sich schwer optimieren und debuggen lassen. So nutzt ROS2 beispielsweise ein auf DDS (data distribution service) basierendes System, um Nachrichten weiterzuleiten. Eine zuverlässige Implementierung von DDS, die Daten und Nachrichten direkt vom ROS2-Framework an die Green Hills Software Entwicklungsumgebung weiterleitet, hilft, die beim Debuggen von Algorithmen für das autonome Fahren auftretenden Schwierigkeiten zu beseitigen und das Qualitätsniveau von Prototyp auf serienreif zu heben.

Zu guter Letzt treten erfahrungsgemäß kurz vor Produktionsstart sporadische Fehler auf, die sich nur im Feld reproduzieren lassen. Diese Phase ist geprägt von drohenden Abgabefristen, die alle Projektbeteiligten unter massiven Druck setzen. In der Lage zu sein, die Fehlerursache schnell zu identifizieren, ist hier ein für den Projekterfolg entscheidender Faktor.

(aok)