Bild 2: Nutzung der standardisierten Datenfusionsbibliothek Baselabs Create Embedded für die Entwicklung von Datenfusionssystemen für automatisierte Fahrfunktionen. Der resultierende C-Quellcode kann entlang der gesamten Entwicklungskette genutzt werden. (Bild: Baselabs)
Die Leistungsfähigkeit, Zuverlässigkeit und Flexibilität der Datenfusionssysteme können den Erfolg der Fahrzeugkommunikation entscheidend beeinflussen. Für die Entwicklung von eingebetteten Datenfusionssystemen ist eine standardisierte Software-Bibliothek verfügbar, die laut einer Referenzrechnung von Baselabs Einsparpotenziale bei der Softwareentwicklung von 50 Prozent ermöglicht und dabei die Entwicklungszeit für die Datenfusion deutlich reduziert. Bereits bei relativ einfachen Zwei-Sensor-Systemen aus zum Beispiel Radar und Kamera betragen die Einsparungen gemäß Referenzrechnung 600.000 Euro. Durch die Zeit- und Kostenvorteile können Automobilunternehmen deutlich flexibler auf Markt- und Kundenanforderungen reagieren, die eigenen Innovationen für die Serienentwicklung mit geringerem Risiko vorantreiben und deutlich schneller auf den Markt bringen.
Datenfusion als Schlüsselkomponente
Datenfusionssysteme werden für spezifische Anwendungsfälle entwickelt: für ein bestimmtes Fahrerassistenzsystem, ein bestimmtes automatisiertes Fahrzeug oder eine spezifische Sensorkonfiguration. Ein einfaches Beispiel ist ein Notbremsassistent (Autonomous Emergency Eraking, AEB). Wesentliche Bausteine dafür sind die Sensoren, die Datenfusion und die eigentliche Fahrfunktion, bestehend aus einer Manöverplanung und der Ansteuerung der Aktuatoren im Fahrzeug.
Bild 1: Datenfusionsschicht im Gesamtsystem: Die Entwicklung der Datenfusionssoftware kann unabhängig von den anderen Systembestandteilen erfolgen. Dabei kommen u.a. die Technologien Objektfusion und Grid-Fusion zum Einsatz, je nachdem, welche Sensordaten verarbeitet und welche Ausgangsgrößen für die Fahrfunktionen benötigt werden. Baselabs
Aufgabe der Datenfusion ist es, die Daten von allen verfügbaren Sensoren zu kombinieren, um so ein möglichst vollständiges und zuverlässiges Abbild der Fahrzeugumgebung – das Umfeld-Modell – zu berechnen. Je nach Komplexität des Gesamtsystems muss die Datenfusionssoftware unterschiedliche Daten verschiedener Sensor-Hersteller und Sensor-Typen verarbeiten. Für die Datenfusion sind zuverlässige und leistungsstarke Datenfusionsalgorithmen und -funktionen für die Sensordatenverarbeitung in Form von Software-Code notwendig (Bild 1).
Für den Einsatz in Serienfahrzeugen muss die Software als C-Quellcode vorliegen und zusätzlich den Anforderungen an sicherheitskritische Anwendungen entsprechen. Notwendige Arbeiten umfassen dabei das Aspice-prozesskonforme Testen (zum Beispiel Software Qualification Tests), die Umsetzungen von Anforderungen aus der funktionalen Sicherheit, sowie die entsprechende Dokumentation. Die Aufwendungen dafür können die eigentliche Entwicklung der Basisfunktionalität der Datenfusion um den Faktor 10 übersteigen. Mit steigender Komplexität des Gesamtsystems, Anzahl der Sensoren im Zielfahrzeug und notwendigen Iterationen für die Fehlerbehebung und Verbesserung des Systems, zum Beispiel den Austausch eines Sensortyps oder eines anderen Herstellers, steigen die Gesamtkosten erneut um ein Vielfaches und die Gesamtdauer der Entwicklung erhöht sich ebenfalls entsprechend.
Projektbasierte Softwareentwicklung
Für die Datenfusionsentwicklung gibt es vereinfachend zwei grundsätzliche Möglichkeiten: Zum einen die projektbasierte Entwicklung, zum anderen besteht die Möglichkeit, standardisierte Softwarebibliotheken einzusetzen.
Projektbasierte Entwicklung: Diese Unternehmen entwickeln die Software individuell pro Projekt. Ein solches Projekt ist zum Beispiel ein Notbremsassistent für einen Mittelklasse-PKW eines bestimmten OEM. Der Code entsteht häufig in einer hardwarenahen Programmiersprache, um den Code direkt auf einem Steuergerät testen und später für die Serie implementieren zu können. Bei der Entwicklung wird nach Möglichkeit auf bestehende Source-Code-Blöcke aus vorigen Projekten zurückgegriffen, die Wiederverwendbarkeit hat aber nicht die höchste Priorität.
Bibliotheksbasierte Softwareentwicklung
Bild 2: Nutzung der standardisierten Datenfusionsbibliothek Baselabs Create Embedded für die Entwicklung von Datenfusionssystemen für automatisierte Fahrfunktionen. Der resultierende C-Quellcode kann entlang der gesamten Entwicklungskette genutzt werden. Baselabs
Bild 3: Typisches Datenfusionsergebnis der Standard-Bibliothek Baselabs Create Embedded. Die Datenfusion kombiniert Detektionen und Objekte der konfigurierten Sensoren zu einer einheitlichen Objektliste der Fahrzeugumgebung. Für jedes Objekt werden Größen wie Position, Geschwindigkeit und Klassifizierung ermittelt. Baselabs
Neben der Entwicklung von eigenen Tools besteht die Möglichkeit, etablierte Werkzeuge für die Entwicklung von Datenfusionssoftware zu nutzen. Bei diesem Modell liegt der Entwicklungs- und Pflegeaufwand für die Bibliothek und komplementäre Tools beim Anbieter der Software und nur ein Anteil davon ist vom jeweiligen Nutzer über eine Lizenzgebühr zu tragen. Die Nutzer können sich auf die Entwicklung und Optimierung des Gesamtsystems und der eigentlichen Fahrfunktionen konzentrieren und differenzieren sich darüber gegenüber ihren Wettbewerbern. Die Standard-Bibliothek liefert die zugrundeliegende Basisfunktionalität in Form des Datenfusionscodes. Durch die entstehenden Zeit- und Kostenvorteile kann das Automobil-Unternehmen deutlich flexibler auf Markt- und Kundenanforderungen reagieren, die eigenen Innovationen für die Serienentwicklung mit geringerem Risiko vorantreiben und deutlich schneller auf den Markt bringen (Bilder 2 und 3).
Kostenrechnung für ein Referenz-Projekt
Baselabs hat anhand eines realen Referenzprojekts am Beispiel eines einfachen Zwei-Sensor-Systems die projektbasierten und bibliotheksbasierten Entwicklungsansätze gegenübergestellt. Im zugrundeliegenden Projekt hat das Unternehmen für einen OEM die Umfelderkennung für ein Notbremsassistenzsystem implementiert. Der Datenfusionscode ist nach Qualitätsprozessen (Aspice) und Sicherheitsanforderungen (ISO 26262) entwickelt. Für die bibliotheks-basierte Entwicklung kommt im Beispiel Software Baselabs Create Embedded zum Einsatz.
Dabei wird gezeigt, dass bereits solche einfachen Systeme Entwicklungskosten von mindestens 1,2 Millionen Euro verursachen. Die Implementierungszeiten für derartige Systeme können dabei schnell deutlich mehr als elf Monate erreichen. Beim Einsatz von standardisierten Softwarebibliotheken mit unterstützendem Tooling lassen sich diese Aufwände deutlich reduzieren. Baselabs ermittelte in der Referenzrechnung mögliche Einsparpotenziale in Höhe von 600.000 EUR, also 50 Prozent der Entwicklungskosten. Die Entwicklungszeit für die Datenfusion wird ebenfalls deutlich reduziert. Die Gesamtkosten und Entwicklungszeiten zeigt Tabelle 1.
Grundlage der Berechnung ist das Constructive Cost Model (Cocomo), ein etablierter Ansatz aus der Software-Entwicklung, um die Kosten- und den Aufwand zu schätzen. Auf der Basis von Einschätzungen der Projekt-Komplexitätsklassen und der Anzahl der Code-Zeilen des Projektes wird mit empirisch abgeleiteten Funktionen der zeitliche Aufwand in Personenmonaten sowie die Gesamtdauer für die Realisierung eines Softwareprojekts bestimmt. Bei der Projektentwicklung entsteht der gesamte benötigte Code inklusive aller Iterationen für die Fehlerbehebung und Verbesserung im Projekt. Diese implizieren einen hohen Arbeitsaufwand und eine lange Umsetzungszeit.
In der bibliotheksbasierten Entwicklung konzentriert sich der Entwickler auf die Konfiguration der Datenfusion und die Verbesserung der Performance, beispielsweise durch die Verbesserung der Sensormodelle. Dadurch ist die absolute Arbeitszeit an der eigentlichen Datenfusion relativ gering. Bei Durchführung am Stück ist auf Basis von Projekterfahrung die Arbeitszeit für das Referenzsystem auf maximal drei Monate zu schätzen, wenn ein erfahrener Entwickler die Implementierung vornimmt. Die eigentlichen Kosten für die Entwicklung der Bibliothek, welche die kurze Entwicklungszeit ermöglicht, wird auf zahlreiche Anwender in der Industrie umgelegt, so dass der Nutzer nur einen Teil dieser Kosten in Form von Lizenzgebühren tragen muss.
Tabelle 1: Gesamtkosten und Entwicklungszeiten projektbasierte und bibliotheksbasierte Entwicklung im Vergleich am Beispiel eines einfachen Zwei-Sensor-Systems für ein Notbremsassistent und bei einmaliger Lizensierung. Baselabs
Neben dem aus der Bibliothek generierten Code für das Zielsystem fallen begleitende Arbeiten für das konkrete Datenfusionssystem an, welche etwa ein halbes Mannjahr Aufwand bedeuten. Diese Arbeiten umfassen das Aspice-prozesskonforme Testen (zum Beispiel Software Qualification Tests), die Umsetzungen von Anforderungen aus der funktionalen Sicherheit, sowie entsprechender Dokumentation. Dieser Aufwand fällt teilweile parallel zur Code-Entwicklung an, so dass die Entwicklungsdauer bei rund acht Monaten insgesamt liegt. Für die Datenfusionsentwickler und -designer, die Create Embedded als eine Softwarebibliothek einsetzen, entfällt neben der Quellcode-Implementierung auch die Notwendigkeit, entsprechend detaillierte Design-Dokumente sowie die korrespondierenden Tests zu erstellen und durchzuführen. In den Design-Dokumenten sind nur die entsprechenden Schnittstellen zu referenzieren beziehungsweise zu beschreiben.
Mithilfe einer Personalkostenschätzung lässt sich in der Folge der finanzielle Aufwand berechnen. In der Vergleichsrechnung werden gesamte Arbeitskosten für ein Mann-Jahr in Höhe von 156.000 EUR angenommen. Darin sind durchschnittliche Personal- und Overheadkosten berücksichtigt.
Die Anzahl der Code-Zeilen im Referenzprojekt ist mit 15.000 Zeilen relativ klein. Davon sind etwa 1000 Zeilen individueller Code, zum Beispiel kundenspezifische Sensormodelle. Die verbleibenden Zeilen stellen überwiegend die erforderlichen mathematischen Implementierungen der Algorithmen dar. Dieser Code ist also kompakt, jedoch inhaltlich herausfordernd. Grundlage für die Berechnung ist ausschließlich der Code für die Datenfusion, das heißt die Aufwände für die Funktionsentwicklung, Integration und Validierung sind nicht erfasst. Cocomo berücksichtigt nur den „delivered code“, also der anfallende Test-Code, der weitere circa 45.000 Zeilen umfasst, ist nicht in der Vergleichsrechnung enthalten.
Fazit
Stark vereinfachende Rechenmodelle wie Cocomo können nur bedingt die Realität komplexer Software-Entwicklungsprojekte und firmenindividuelle Faktoren abbilden. Jedoch geben die vorgestellten Ergebnisse interessante Anhaltspunkte, um Make-or-Buy-Entscheidungen für die Datenfusionsentwicklung zu diskutieren. Nutzer von am Markt verfügbaren Standard-Bibliotheken profitieren von einem erheblich geringeren Implementierungsaufwand, da funktionale und formale Anforderungen bereits in der Bibliothek berücksichtigt und ohne Zusatzaufwand für die Entwicklung verfügbar sind. Weiterhin ermöglichen die deutlich verkürzten Entwicklungszeiten für den Software-Code eine kürzere Time-to-Market und sichern dadurch Wettbewerbsvorteile für das Automobilunternehmen.
Andererseits verbleibt mehr Zeit, um die implementierten Algorithmen zu optimieren, zum Beispiel indem mehr unterschiedliche Parameter-Sätze testbar sind. Außerdem erleichtert das Tool, mit geänderten Systemkonfigurationen und häufigen Change Requests in der Design-Phase umzugehen und wird dadurch den Anforderungen bei der Entwicklung komplexer Software gerecht. Bei der Bewertung der Ergebnisse ist zu beachten, dass das zugrundeliegende Referenzsystem ein vergleichsweise einfaches Zwei-Sensor-System ist. Diese Kostenschätzung ist also als eine untere Grenze für die Entwicklung von Datenfusionssystemen zu verstehen, steigende Systemkomplexität wird die Kosten deutlich darüber hinaussteigen lassen. Der bibliotheksbasierte Ansatz ist bei steigender Komplexität des Systems umso mehr zu bevorzugen.
(na)
