6. Direkte Pipeline vom Datenlogger in die Cloud legen. So kann der Fahrer Aufzeichnungsausschnitte nach ungewöhnlichen Ereignissen teilen.
Die direkte Pipeline stellt sicher, dass ein Ingenieur den Sachverhalt schnellstmöglich prüfen, Einblicke liefern und gegebenenfalls Probleme beheben kann. Darüber hinaus lässt sich ermitteln, ob die Testfahrt weiterhin relevant ist. Dies ist entscheidend, um nicht benötigte Daten zu vermeiden. Die Beispiele reichen von der falschen Softwareversion auf einem Steuergerät bis hin zu aktualisierter Software, die unter bestimmten Bedingungen (zum Beispiel bei wenig Licht) ein ungewöhnliches Verhalten aufweist.
7. Mehr Daten sind nicht zwangsläufig besser – die Vielfalt des Datensatzes ist der Schlüssel zum Erfolg.
Die Fähigkeit, den Umfang der Testabdeckung zu ermitteln, sowie eine kritische Einstellung zum Trainingsdatensatz ermöglichen optimale Ergebnisse. Metriken zur Einstufung und Auswertung der Daten müssen klar definiert werden. Der Wert von Tools zur Analyse der Aufzeichnungen und Datensätze ist nicht zu unterschätzen. Diese erfolgt anhand verschiedener Kriterien wie einer Heatmap der Position von Verkehrszeichen, die zeigt, wann und wo sie erfasst wurden.
Manche Unternehmen sammeln und archivieren für Hardware in the Loop (HiL)-Tests so viele Daten wie möglich. Bei der Analyse der archivierten Daten eines Herstellers war jedoch festzustellen, dass nur ein Bruchteil einen tatsächlichen Wert hatte. Da es sich bei den übrigen Daten um Duplikate handelte, war ein sehr teurer, zeitintensiver Prozess die Folge. Ein weiterer wichtiger Aspekt ist also die Qualität der aufgezeichneten Daten. Die Aufzeichnung muss mit hoher Genauigkeit (25 ns) erfolgen, damit sich die Daten später auf die Mikrosekunde genau in HiL-Farmen wiedergeben lassen.
8. Gleichbehandlung von Daten aus Testfahrten und Simulationen.
Die Fähigkeit, Daten aus Testfahrten und Simulationen gleichermaßen zu adressieren, ist von zentraler Bedeutung. Damit ist gemeint, dass das Datenmanagementsystem in der Lage sein sollte, unabhängig von der Datenquelle zu suchen. Dabei sollten relevante Daten unbedingt vor Dritten geschützt werden. Auch wenn das Sensor-Set-up nicht dasselbe ist, bietet ein extrahiertes Szenario dennoch wertvolle Informationen.
9. Ungewöhnliche Szenarien aus der realen Welt eröffnen neue Möglichkeiten.
Beispiele für solche ungewöhnlichen Szenarien sind beispielsweise lebensgroße Bilder an der Seite eines großen Sattelzugs; Verchromung, die wie ein Spiegel wirkt; eine Schaufensterpuppe, die von der Ladefläche eines Pick-ups geschleudert wird; ein Pflug mit Anhänger, der seitwärts driftet; eine ausgezogene Leiter im Straßenverkehr; und schließlich ein Polizeiauto, das die Geschwindigkeit des Verkehrs reduziert, indem es bei laufender Sirene dauernd die Spur wechselt.
Derartige Beispiele können später in Simulationen reproduziert und tausendfach variiert werden. Die Herausforderung besteht darin, nur plausible Szenarien zu erstellen, die durch die Simulations-Engine und deren Regeln und/oder die Beschreibungssprache eines verwendeten Szenarios umgesetzt werden können.
10. Die Toolchain mit Industriestandards zukunftssicher machen.
Um zu gewährleisten, dass die Toolchain zukunftssicher und für andere nutzbar ist, sollte auf Industriestandards wie Open Drive, Open Scenario und Open Label gesetzt werden. So lässt sich außerdem die Interoperabilität der Werkzeugkette mit anderen Systemen sicherstellen, die gegebenenfalls zu einem späteren Zeitpunkt eingesetzt werden sollen. Wenn die Ziele mit sauberen Schnittstellen und Standards erreicht werden, ist es darüber hinaus einfacher, neue Partner mit ins Boot holen.
Der Autor
Jérémy Dahan
ist Head of Technology Research bei Elektrobit (EB). Er steuert die Geschäftsentwicklung, Aktivitäten und Partnerschaften des Unternehmens im Silicon Valley. In den Jahren 2019 und 2020 legte er im EB-Erprobungsfahrzeug lange Strecken in den USA und in Japan zurück.