Vorhersage der Laufzeit von Software zur Sensordatenfusion

Software spielt bei der Entwicklung von Fahrzeugplattformen eine zentrale Rolle. Im Bereich des automatisierten Fahrens wird dies durch verschiedene technologische Fortschritte unterstützt. Zum einen stellen immer mehr Sensoren immer reichhaltigere Informationen der Fahrzeugumgebung zur Verfügung. Das Mehr an Informationen ermöglicht größere Umfänge der Automatisierung, da das digitale Abbild der Fahrzeugumgebung von höherer Güte ist, als es in der Vergangenheit der Fall war. Die bessere Güte der Ergebnisse kommt zu dem Preis, dass für die gesteigerte Menge an Eingangsdaten unter anderem auch mehr Rechenleistung für die Verarbeitung benötigt wird. Diese zusätzliche Rechenleistung ist mit der Weiterentwicklung der Hardware-Plattformen grundsätzlich verfügbar.

Eine zentrale algorithmische Herausforderung bei der Entwicklung neuer Funktionen für das automatisierte Fahren ist die Sensorfusion. Die Sensorfusion kombiniert die Eingangsdaten verschiedener Sensoren bzw. Sensormodalitäten, wie z.B. Radare, Kameras oder Lidare, zu einem vereinheitlichten Abbild des Fahrzeugumfeldes. Auf Basis dieses Umfeldmodells wird dann von der Software im Fahrzeug entschieden, welche Manöver dieses gegebenenfalls fahren soll.

In der Regel stehen grundsätzlich Implementierungen der Algorithmen für die Sensorfusion bereit. Eine interessante Frage bei der Entwicklung und Laufzeitabschätzung ist jedoch, inwieweit sich Laufzeitmessungen der Algorithmen von der einen Hardware, z. B. von einem Entwicklungscomputer oder einer vorangegangenen Generation von Steuergeräten, für die Vorhersage der Laufzeit desselben Algorithmus auf einer anderen Hardware übertragen lassen.

Planung von Hardware und Laufzeit-Budgets

Beim Entwurf und der Entwicklung von Funktionen für das automatische Fahren findet grundsätzlich ein Co-Design von Hardware und Software statt. Daraus leiten sich zwei Perspektiven auf dieselbe Fragenstellung ab. Zum einen wird die Frage betrachtet, welcher Mikroprozessor bzw. -controller zur Berechnung eines bestimmten Algorithmus benötigt wird. Diese Herangehensweise kommt zum Einsatz, wenn bekannt ist, dass ein Algorithmus die Anforderungen des Systems erfüllt und damit im Lösungsraum ist. Zum anderen lässt sich die Frage stellen, welcher Algorithmus bei gegebener Hardware gerade noch im Zeitbudget berechnet werden kann. Diese Herangehensweise kommt zum Einsatz, wenn die Hardware durch andere Überlegungen in einer frühen Entwicklungsphase festgelegt ist oder mehrere Algorithmen zur Problemlösung zur Auswahl stehen.

Was das Problem mit DMIPS als Hilfsgröße ist

Sowohl bei der Bewertung der Leistungsfähigkeit von Universal-Rechenhardware wie Mikrocontrollern bzw. -prozessoren, als auch bei der Zuteilung von Rechenzeit-Budgets wird in der Automobilindustrie häufig die Größe „DMIPS“ verwendet. Diese DMIPS korrespondieren mit der Anzahl der Iterationen der Berechnungen des synthetischen Dhrystone-Benchmarks pro Sekunde, normalisiert auf einen typischen Computer der 70er Jahre mit MIPS-Befehlssatzarchitektur (Microprocessor without Interlocked Pipeline Stages). Daraus ergab sich historisch der Name DMIPS. Die Dhrystone-Leistung eines Prozessorkerns kann auch im Verhältnis zur Taktfrequenz angegeben werden, typischerweise in DMIPS/MHz.

Das Dhrystone-Benchmark basiert jedoch auf einem Programm, welches Ganzzahl-Arithmetik und keine Fließkomma-Berechnungen verwendet. Gleichzeitig ist es so, dass Implementierungen von Algorithmen zur Sensorfusion praktisch ausschließlich auf Fließkomma-Berechnungen basieren. Insofern ist hier eine Übertragbarkeit der Laufzeiten bei der Berechnung von Sensorfusions-Algorithmen zu untersuchen. Des Weiteren können sich auch die Mikroarchitekturen der Prozessorkerne stark unterscheiden, selbst wenn sie dieselbe Befehlssatzarchitektur wie beispielsweise Armv8-A verwenden. Dies wiederum hätte gegebenenfalls auch Einfluss darauf, wie effizient die jeweilige Mikroarchitektur des Prozessorkerns mit Sensorfusionscode umgehen kann.

Bewertung anhand realer Sensorfusionen und Hardware

Baselabs hat im Zuge der Entwicklung seiner Produkte die Übertragbarkeit domänenspezifischer Laufzeitbudgets mittels DMIPS untersucht. Grundlage der Bewertung bildete Baselabs Create Embedded. Create Embedded ist eine Bibliothek für die Sensorfusion und ermöglicht die Erzeugung und Erweiterung von maßgeschneidertem C-Code. Dieser C-Code ist spezifisch für die Sensorkonfigurationen und Umgebungsbedingungen und erfüllt die Anforderungen des Einsatzes im sicherheitskritischen Umfeld nach ISO26262.

Im Zuge der Qualifikationstests der Software-Bibliothek werden unter anderem verschiedene Sensorfusionskonfigurationen erzeugt und auf verschiedener Zielhardware ausgeführt. Die Testvektoren für die Ausführung der verschiedenen Konfigurationen triggern jeweils den Programmpfad mit der maximalen Laufzeit. Die verschiedenen Sensorkonfigurationen der exemplarischen Datenfusionen umfassen beispielsweise die Fusion für eine Kamera und ein Radar, eine Datenfusion für eine Kamera und drei Radare sowie eine Datenfusion für eine Kamera und fünf Radare. Bild 1 zeigt schematisch die angenommene Anordnung der Sensoren.

Der mit Create Embedded erzeugte C-Code wird vor der Messung der Laufzeit der Sensorfusion nicht händisch optimiert und nur auf jeweils einem Prozessorkern ausgeführt. Compiler-Optimierungen werden aktiviert. Die maximale Laufzeit der drei verschieden komplexen Sensorfusionen wurde auf verschiedenen Microcontroller- bzw. Prozessor-Kernen gemessen: Einem Arm Cortex-A53, einem Arm Cortex-A72, einem Intel Core i7 der 6. Generation, einem TriCore v1.6P eines Infineon Aurix TC277 und eines Aurix TC397 sowie einem TriCore v1.6E des TC277.

Software für Sensordatenfusion wird im Produktivsystem typischerweise zyklisch, vielfach pro Sekunde, aufgerufen. Die nachfolgend erwähnten Laufzeiten der Sensorfusionen beziehen sich auf die Verarbeitung einer Menge von Sensordaten, welche in einem Real-System innerhalb einer Sekunde anfallen würden. Dauert die Verarbeitung also z. B. 100 ms/s, so ergäbe sich bei kontinuierlichem Betrieb eine mittlere Auslastung von zehn Prozent. Dauert die Verarbeitung länger als eine Sekunde, wäre der Prozessor im praktischen Einsatz in jedem Falle überlastet.

Ergebnisse

Die gemessenen Laufzeiten wurden mit öffentlich verfügbaren DMIPS-Leistungsangaben der Mikrocontroller- bzw. Prozessorkerne ins Verhältnis gesetzt, um ein DMIPS-Äquivalent jeder Konfiguration der Sensorfusion auf jeder der genannten Hardware zu bestimmen. Beispielhaft ergäben sich für die 3R1C-Sensorfusion bei einer Laufzeit von 100 ms/s auf einem Prozessor A mit 4500 DMIPS damit ein DMIPS-Äquivalent von 450, für Prozessor B mit 2750 DMIPS und 200 ms/s Laufzeit entsprechend ein DMIPS-Äquivalent von 550, und so weiter. Je näher diese DMIPS-Äquivalente pro Sensorfusionskonfiguration beieinanderliegen, desto besser eignet sich DMIPS praktisch zur Übertragung von Laufzeitmessung von Sensorfusionscode zwischen verschiedener Hardware.

Um einen Eindruck dieser Unterschiede zwischen den verschiedenen Prozessoren bekommen zu können, wurde als Referenzwert ein geschätztes DMIPS-Äquivalent berechnet. Dieser Referenzwert lässt sich auch als allgemeine, hardware-unabhängige Angabe der Rechenzeit in DMIPS interpretieren. Dazu wurde jeweils pro Sensorfusionskonfiguration der quadratische Fehler zwischen den Einzelmessungen auf den sechs Mikrocontroller- bzw. Prozessorkernen und dem zu ermittelnden Referenzwert minimiert. In dem Beispiel oben ergäbe sich also für die 3R1C-Sensorfusion ein Referenzwert von 500 DMIPS aus den Einzelmessungen von 450 und 550 DMIPS. Die Einzelmessungen für jeden Prozessor können dann ins Verhältnis zum Referenzwert gesetzt werden. Je besser sich DMIPS zur Übertragung bzw. Vorhersage der Laufzeit eignet, desto näher liegt dieses Verhältnis für alle Prozessoren und Sensorfusionen bei 100 Prozent.

Bild 2 zeigt die Ergebnisse der Messungen, das Verhältnis der auf der jeweiligen Hardware gemessenen DMIPS-Äquivalente zum mittels der Kleinste-Quadrate-Methode bestimmten Referenzwert jeder Konfiguration der Sensorfusion.

Insgesamt lässt sich festhalten, dass mit einer Abweichung von maximal ca. 20 Prozent der gemessenen Laufzeit im Vergleich zum ermittelten Referenzwert die Verwendung von DMIPS grundsätzlich tauglich erscheint für Algorithmen der Sensorfusion und die untersuchten Prozessoren, auch wenn die Differenz bei der Betrachtung der einzelnen Hardwarekombinationen größer sein kann. Die konkrete Komplexität bzw. Konfiguration der Sensorfusion hat dagegen nur untergeordneten Einfluss auf Abweichungen zwischen der betrachteten Hardware. Für eine mit Create Embedded entwickelte Sensorfusion lässt damit bereits während der Entwicklung auf einem PC eine solide Aussage zur erwarteten Laufzeit auf einem Embedded-Target treffen.

Einige abschließende Bemerkungen: Die für die Betrachtung verwendeten Dhrystone-Leistungsangaben der Mikrocontroller- bzw. Prozessorkerne wurden teilweise in Materialien der Hersteller veröffentlicht, teilweise von Dritten gemessen. Basierend auf den öffentlichen Informationen zur jeweiligen Leistungsfähigkeit wurden folgende Annahmen für die verschiedenen Rechenkerne getroffen: Arm Cortex-A53: 2,3 DMIPS/MHz; Arm Cortex-A72: 4,2 DMIPS/MHz; Infineon Aurix TC277 TriCore v1.6E: 1,4 DMIPS/MHz; Infineon Aurix TC277 TriCore v1.6P: 1,6 DMIPS/MHz; Infineon Aurix TC397 TriCore v1.6P: 2,17 DMIPS/MHz; Intel Core i7 der 6. Generation: 9 DMIPS/MHz (unsichere Angabe).

Des Weiteren dienten die Betrachtungen relativer Laufzeiten ausschließlich der Bewertung der Tauglichkeit der Übertragung der Laufzeiten des Sensorfusionscodes von einer Befehlssatz-Architektur auf eine andere auf Basis der Leistungsangaben in DMIPS/MHz der jeweiligen Rechenkerne. Es fand ausdrücklich keine Bewertung der relativen Leistungsfähigkeit oder Effizienz der Rechenkerne statt. Es wurden des Weiteren auch keine Hardware-spezifischen Optimierungen untersucht. (na)