Bild 1: Das Datenfusions-basierte Umfeld-Modell ist das Bindeglied zwischen Systeminfrastruktur (Sensoren und Middleware-Software) und den Fahrfunktionen.

Bild 1: Das Datenfusions-basierte Umfeld-Modell ist das Bindeglied zwischen Systeminfrastruktur (Sensoren und Middleware-Software) und den Fahrfunktionen. Baselabs

Um ein möglichst vollständiges und zuverlässiges Abbild der Fahrzeugumgebung, das Umfeld-Modell, zu berechnen, ist eine Fusion der Daten von allen verfügbaren Sensoren erforderlich. Die vom Modell bereitgestellten Informationen werden dann von Assistenzsystemen genutzt, um situationsabhängige Fahrmanöver einzuleiten (Bild 1).

Die Datenfusion steht zwar schon seit längerem im Fokus von Forschung und Entwicklung, doch noch sind längst nicht alle Herausforderungen gelöst. Dieser Artikel konzentriert sich auf die praktische Implementierung der Datenfusion und damit auf den Workflow in den Entwicklungsabteilungen: Wie weit sind hier standardisierte Tools verfügbar? Welche Workflows gibt es, und welche Ideen existieren für deren Weiterentwicklung?

Der Nutzen der Standardisierung

In den unteren beiden Schichten des in Bild 1 gezeigten Modells sind zahlreiche standardisierte Produkte und damit auch entsprechende Workflows verfügbar. So bieten die Sensoren in der untersten Schicht häufig eine Vorverarbeitung der Sensordaten an, bis hin zu „smarten“ Sensoren wie etwa den bekannten Mobileye-Kameras.

Im Bereich der Middleware, also Softwareprodukten, die Sensordaten akquirieren, speichern und wiedergeben können sowie den Benutzer beim Systementwurf unterstützen, sind ebenfalls verschiedene Produkte am Markt verfügbar. Die wichtigsten sind vADASdeveloper (Vector), ADTF (Elektrobit), RTMaps (Intempora), PolySync (PolySync) und ROS (Open Source).

In diesen beiden Schichten profitiert die Industrie schon maßgeblich von der Einführung standardisierter Produkte und Tools. Kein Entwickler muss seine Zeit für die Entwicklung einer eigenen Middleware aufwenden, da sich einige Marktteilnehmer auf die Bereitstellung der genannten Produkte fokussiert haben. Deren Nutzer werden durch die Verteilung der Entwicklungskosten auf viele Schultern entlastet.

Die bisher genannten Produkte leisten allerdings keine aktive Unterstützung bei der Implementierung von Datenfusions-Algorithmen. Sie ermöglichen lediglich die Einbindung von Datenfusions-Softwarekomponenten in die Infrastruktur des Systems. An dieser Stelle setzt das Algorithmen-Softwareframework Baselabs Create an. Es bietet dem Entwickler direkte Unterstützung bei der Implementierung von Algorithmen oder Filtern für die Datenfusion an, indem Standardverfahren wie etwa Kalman-Filter, Zuordnungsverfahren oder Sensormodelle als modulare Softwarebibliothek direkt nutzbar werden. Nach der aktuellen Lage am Markt ist die einzige Alternative zur Verwendung dieses Frameworks die Eigenimplementierung von Umfelderkennungs-Algorithmen.

Der Datenfusions-Prototyping-Workflow

Bild 2: Iterativer Entwicklungs-Workflow in der Datenfusion.

Bild 2: Iterativer Entwicklungs-Workflow in der Datenfusion. Baselabs

Mit der Verwendung einer geeigneten Middleware aus dem Kreis der genannten Anbieter und dem Softwareframework Baselabs Create ist der erste Teil des Datenfusions-Workflows komplett: Als Ergebnis der Anbindung von Sensoren mittels einer geeigneten Middleware und der Implementierung einer Datenfusion steht der Datenfusions-Prototyp. Diese Datenfusions-Applikation nutzt die durch die Middleware bereitgestellten Sensordaten und fusioniert sie zu einem konsistenten Umfeld-Modell. Ein solcher Workflow entspricht den Anforderungen bei Forschungs- und Vorserienprojekten. Durch die Toolunterstützung wird schnell ein Ergebnis erreicht, das sich in die Bewertung beziehungsweise prototypische Erprobung überführen lässt. Im Rahmen des Workflows werden auch typische Herausforderungen der Datenfusion durch das Softwareframework gelöst, wie beispielsweise die Synchronisierung der Sensordaten und die Übergabe von Objekten zwischen verschiedenen Sensoren.

Bei dem auf dem beschriebenen Weg erzielten Ergebnis handelt es sich in der Regel um einen Prototyp, der noch nicht auf die Verwendung in einem eingebetteten System ausgelegt ist – daher auch die Bezeichnung als „Teil-Workflow“. Es besteht aber die Möglichkeit, den Datenfusions-Prototypen mit Unterstützung des Source-Code-Generators Baselabs Code in C-Code zu überführen.

Typischerweise wird der Workflow iterativ durchlaufen: Die Entwicklung startet mit einer begrenzten Anzahl von Sensoren und Fahrfunktionen, die dann schrittweise durch das Hinzufügen von Sensoren (mehr gleichartige Sensoren oder auch andere Sensortechnologien)  und Funktionen fortgesetzt wird. Im Ergebnis steht der Datenfusions-Prototyp, der dann auf einer Prototyping-Hardware eingesetzt wird (Bild 2).

Erprobung des Prototyps im Messfahrzeug

Nach der Implementierung des Prototyps, die in der Regel mit einem begrenzten Set an Messdaten vorgenommen wird, erfolgt der Test im Messfahrzeug, um weitere Erkenntnisse zu gewinnen. So lassen sich die Parameter des Systems variieren oder die Sensorkonfiguration verändern. Die Nutzung des Prototyps aus dem skizzierten Workflow kann dabei in verschiedenen Umgebungen flexibel erfolgen:

  • Softwareseitige Flexibilität: Die Verwendung von unterschiedlichen Middlewares und Betriebssystemen ist möglich, wobei auch ein Wechsel zwischen Labor- und Erprobungsphasen erfolgen kann.
  • Hardwareseitige Flexibilität: Im Messfahrzeug wird in der Regel nicht mehr mit PCs gearbeitet. Der Workflow bietet die Möglichkeit, gängige Prototyping-Hardware wie die dSpace MicroAutobox, Nvidia Drive PX 2 oder TTTech HADP zu nutzen.

Nach der Erprobung oder direkt im Anschluss an die Entwicklung können die Fahrfunktionen implementiert werden, welche auf das Umfeld-Modell zurückgreifen. Hier ist der häufig gewählte Weg die Nutzung von Matlab und Simulink, welche im skizzierten Workflow einfach möglich ist.

Bewertung des vorliegenden Workflows

Der vorgestellte, weitgehend standardisierte Workflow hat klare Vorteile: schnelle Ergebnisse, hohe Flexibilität, erprobte Softwarekomponenten für die Datenfusion sowie eine C-Quellcode-Bereitstellung.

Kundenwünsche an eine Erweiterung beziehungsweise Fortentwicklung des Workflows bestehen vor allem in den folgenden Bereichen:

  • Weitere Vereinfachung der Implementierung – weniger Code schreiben, mehr konfigurieren.
  • Durchgängigkeit der Nutzung von der Vorserien- bis in die Serienentwicklung und eine hohe Laufzeit-Effizienz des Codes.
  • Funktionale Sicherheit und Absicherung.

Die hier aufgelisteten Wünsche beruhen auf Erfahrungen aus zahlreichen Kundenprojekten.

Entwicklungsworkflow der Zukunft

Bild 3: Konfiguration einer Datenfusions-Applikation.

Bild 3: Konfiguration einer Datenfusions-Applikation. Baselabs

Der Wunsch nach einer vereinfachten Implementierung lässt sich vor allem durch eine grafische Unterstützung des Entwurfsprozesses erfüllen (Bild 3). Baselabs Create bietet in der aktuellen Version die Möglichkeit, alle wesentlichen funktionalen Komponenten eines Datenfusionssystems mithilfe einer grafischen Benutzeroberfläche (GUI) zu konfigurieren. Über die GUI lassen sich wichtige Eigenschaften des Systems wie die Fahrzeugdynamik ebenso einstellen wie die Charakteristik jedes verwendeten Sensors, etwa Detektionsleistung und Messfehler.

Eine zentrale Verbesserung des Workflows besteht darin, dass sich ein System einfach um weitere Sensoren ergänzen lässt. Das Hinzufügen (und Entfernen) von Sensoren sowie anderer Einstellungen erfolgt ohne das Schreiben einer einzigen Zeile Code, wodurch die Komplexität reduziert und die Geschwindigkeit signifikant erhöht wird. Nach Abschluss der Konfiguration steht der Quellcode der Applikation für die weitere Verwendung zur Verfügung. Neben der grafischen Konfiguration haben erfahrene Entwickler weiterhin vollen Zugang zur zugrundeliegenden Datenfusionsbibliothek, um etwa speziell angepasste Sensormodelle bereitzustellen.

In Bezug auf die gewünschte durchgängige Nutzung in Vorserien- und Serienentwicklung und die hohe Laufzeiteffizienz des Codes ist in der Praxis heute eine starke Entkopplung zwischen den Entwicklungsphasen zu beobachten. Dies führt unter anderem dazu, dass sehr viel Softwarecode in der Serienentwicklung neu implementiert wird. Gleichzeitig passen etablierte Serienentwicklungstools nicht zu den Anforderungen der Vorserienentwicklung, da sie die Entwicklungsprozesse verkomplizieren und damit verlängern. Für die Zukunft besteht daher der Bedarf für ein Framework, das sich durchgängig im gesamten Entwicklungsprozess verwenden lässt und gleichzeitig maximale Laufzeiteffizienz in Bezug auf Speicherbedarf und CPU-Ressourcen aufweist.

Darüber hinaus ist eine zwingende Voraussetzung für die Serienentwicklung, dass die Datenfusion entsprechend den Anforderungen der funktionalen Sicherheit (ISO26262) entwickelt wird. Nur auf diesem Weg wird für den OEM im Endeffekt der Nachweis für das Gesamtfahrzeug gelingen, dass dessen Entwicklung den Sicherheitsanforderungen genügt. Das skizzierte Framework muss daher nach den Anforderungen der funktionalen Sicherheit qualifizierbar sein, wozu das Integrieren von Coding Guidelines wie Misra-C in den Entwicklungsprozess einen Beitrag leistet.

Workflow-Überblick

Bild 4: Workflow-Vorschlag für die durchgängige Datenfusionsentwicklung in Vorserie und Serie unter Berücksichtigung der funktionalen Absicherung.

Bild 4: Workflow-Vorschlag für die durchgängige Datenfusionsentwicklung in Vorserie und Serie unter Berücksichtigung der funktionalen Absicherung. Baselabs

Die Überlegungen zum Workflow der Zukunft sind in Bild 4 zusammengefasst. Im Kern steht die Bereitstellung wesentlicher, standardisierter Code-Bestandteile wie der mathematischen Beschreibung von Algorithmen und Filtern durch das Framework. Diese Code-Bestandteile machen rund 90 Prozent des erforderlichen Datenfusions-Codes aus und müssen in diesem Workflow-Vorschlag nicht mehr durch den Nutzer implementiert werden. Zusätzlich wird dieser Code abgesichert bereitgestellt.

Der Nutzer hat aber die Möglichkeit, an für die Effizienz besonders wichtigen Teilen Optimierungen vorzunehmen, beispielsweise durch ein an die Zielplattform angepasstes Speicherlayout oder die Verwendung von optimierten Bibliotheken für performancekritische Teilaufgaben. Ein weiterer zentraler Bestandteil des Konzepts ist die durchgängige Berücksichtigung der Anforderungen der funktionalen Sicherheit. In diesem Workflow nutzen Vorserien- und Serienentwicklungsabteilungen das gleiche Framework. Das Ergebnis eines solchen Workflows ist in allen gängigen Middleware-Produkten bis hin zu Autosar nutzbar.

 

Eckdaten-Kasten:

Für die zukünftige Datenfusionsentwicklung werden die Aufwandsreduktion durch Standardisierung und Konfigurierbarkeit sowie die funktionale Sicherheit und Validierung eine zentrale Rolle spielen. Beim Datenfusions-Workflow der Zukunft werden deshalb die Reduktion von manuellen Programmieraufwänden sowie die durchgängige Berücksichtigung von Anforderungen der funktionalen Sicherheit in Vorserien- und Serienentwicklung und eine hohe Laufzeiteffizienz im Mittelpunkt stehen.