Big Loop: Wie flottenbasierte Entwicklung zum Erfolg führen kann

Die Daten werden an der Flotte erhoben und dann drahtlos ­– über Backend-Konnektivität – an die datengestützte Entwicklungsplattform übertragen. Big Loops ermöglichen Feldversuche in realer Umgebung, die (im Schattenmodus) an Millionen von Fahrzeugen gleichzeitig durchgeführt werden können. Auf diese Weise werden die Daten bereitgestellt, mit denen sich neue Funktionalitäten entwickeln (und bestehende erweitern) lassen – unter Einsatz von Big Data und Deep Learning. Das Prozedere gleicht dabei einem Kreislauf: ideate, create, deploy, test, analyze result, change, deploy final software, repeat (konzeptionieren, entwickeln, ausrollen, testen, Ergebnisse auswerten, Änderungen umsetzen, finale Software ausrollen, wiederholen).

Welche Vorteile die Big Loop Unternehmen bietet

Wir alle wissen, wie wichtig Daten sind. Aber auf ausreichend hochwertige Daten aus der realen Welt zuzugreifen, die erforderlich sind, um technologische Fortschritte zu erzielen, stellt eine Herausforderung dar. Führende Hersteller und Tier-1-Zulieferer haben unterschiedliche Techniken zur Datenerfassung eingesetzt – von ausschließlich der Entwicklung gewidmeten, kostengünstigen Testfahrzeugen zur Datenerfassung bis hin zu fortgeschrittener KI. Aber was wäre, wenn jedes Fahrzeug einer Flotte als Vehikel zur Datenerfassung und gleichzeitig als Testumgebung genutzt werden könnte? Genau dies schafft die Big Loop:

• Durch vollen Zugriff auf die Flottendaten wird die Entwicklung des autonomen Fahrens – einschließlich des Zulassungsverfahrens – ermöglicht, abgesichert und beschleunigt.
• Die Fahrzeugsoftware der gesamten Flotte kann schnell und häufig aktualisiert werden.
• Reale Daten werden zugänglich gemacht – für Testzwecke wie auch zum Validieren simulierter Umgebungen.

Schauen wir uns einige dieser Punkte genauer an:

• Daten für Software zur Fahrzeugerkennung sammeln: Bei dieser Software werden immer häufiger Algorithmen verwendet, die auf KI und ML basieren. Für die Algorithmen werden Trainingsdaten benötigt, und es wäre zu langsam, diese nur mithilfe von Entwicklungsfahrzeugen zu erfassen – besonders bei speziellen Szenarien, die eher selten eintreffen.
  Ein Beispiel: In Deutschland kollidiert pro Jahr rund 230.000-mal ein Fahrzeug auf der Straße mit einem Reh. Im Rahmen einer gewöhnlichen Datensammlung werden jedoch nur wenige Tiere auf der Straße gesichtet. Nur mithilfe von Daten großer Flotten ist es möglich, ein Erkennungssystem so zu trainieren, dass es alle Arten von Objekten zuverlässig erkennen und an ein Notbremssystem melden kann, das dann – unter Berücksichtigung von Tierart und Größe sowie dem Abstand zum folgenden Fahrzeug – entscheidet, ob für das Tier gebremst werden soll oder nicht.
  Funktionierende künstliche neuronale Netze, sogenannte Deep Neural Networks (DNNs), kommen in übergeordneten Anwendungen zum Einsatz – zum Beispiel um das Fahrverhalten eines Menschen zu kopieren oder um zu verstehen, warum ein Fahrer eine moderne Fahrassistenzfunktion übersteuert. Um solche neuralen Netze zu erschaffen, sind umfangreiche Daten aus der realen Welt erforderlich – über das Verhalten des Fahrers und über seine Umgebung.
• Analysieren, ob sicherheitsrelevante Funktionen in „freier Wildbahn“ korrekt arbeiten: Hierzu werden zunächst kritische Fälle identifiziert, die für Software ein Problem darstellen können – zum Beispiel Schatten von Leitplanken auf der Straße, die den Spurhalteassistenten verwirren. Diese kritischen Fälle führen zu Systemfehlern aufgrund einer Reihe von Stimulationen, die bei der Entwicklung nicht vorausgesehen wurden.
  
• Fehlerhafte sicherheitsrelevante Funktionen unverzüglich deaktivieren oder analysieren: Es ist zwingend erforderlich, zeitnah Kontakt zur Flotte aufnehmen zu können, um alle Fahrzeuge mit solchen fehlerhaften Funktionen schnellstmöglich umzuschulen.
• Flottensicherheit gewährleisten, um Missbrauch, Manipulation oder Angriffe auf Fahrzeugfunktionen zu erkennen, denn die Autos werden immer anfälliger für externe Angriffe.
• Die Frequenz von Software-Updates und Fehlererkennung auf ein Niveau heben, das nur mit der Big Loop möglich ist.
• Funktionen überwachen, die im Schattenmodus laufen, um die Qualität der Implementierung beurteilen zu können (nur möglich bei sogenannten Open-Loop-Funktionen).
• Die Flotte als Back-to-Back-Testsystem für Simulationsumgebungen einsetzen: Komplexe ADAS oder Systeme für autonomes Fahren (Autonomous Driving, kurz AD) werden künftig auf simulierte Entwicklungs- und Testumgebungen angewiesen sein. Um sicherzustellen, dass die Simulation realitätsnah ist, müssen der Output von Simulationen und derjenige von realen Daten miteinander verglichen werden – unter Verwendung des gleichen zu testenden Systems in beiden Umgebungen.

Komponenten der Big Loop

Dir Big Loop bietet viele Vorzüge – sie könnte der beste Weg in Richtung L3–5 sein. Hier eine beispielhafte Aufschlüsselung der Big-Loop-Komponenten, die über das gesamte Automobilentwicklungssystem verteilt sind, und ihrer notwendigen Attribute:

Zentrale Datenerfassung im Fahrzeug

• Die fahrzeugeigene Softwarearchitektur sollte idealerweise eine On-Demand-Datensammlung aller im Fahrzeug verfügbaren Daten unterstützen – von Informationen zum internen Status jeder Funktion bis hin zum durch vollständige Fusion der Sensoren geschaffenen Modellzustand. Das alles ist notwendig und muss zugänglich sein.
• Dies ist derzeit nicht möglich, da die internen Statusinformationen der Software hinter der Hardware der Tier-1-Lieferanten versteckt sind, sodass die Daten für den Hersteller nicht zentral zugänglich sind.

Fahrzeuginterne Logik für Datenerfassung und Steuerimpulse

• Das Speichern aller Daten ist schlicht nicht möglich – das liegt an den Kosten für Speichersysteme und an den Beschränkungen der Bandbreite. Entwickler müssen also mithilfe von Trigger-Logik definieren, welche Daten wann gespeichert werden. Diese Logik muss dann in die Kampagnen implementiert werden, die von den Entwicklern auf jede beliebige Fahrzeugflotte ausgerollt werden können.

Tests im Schattenmodus innerhalb des Fahrzeugs

• Es braucht ein System, um frühere Versionen der Software in einer isolierten Testumgebung („Sandbox“) auszuführen und zu speichern, ohne die Hauptsoftware des Fahrzeugs zu beschädigen. Der Output liefert dem Entwickler Erkenntnisse über die Leistungskennzahlen (Key Performance Indicators, kurz KPIs) der Software. Daten werden per Drahtlosübertragung (over the Air, kurz OTA) sicher und effizient ins Backend transportiert.
• Es ist ein sicherer Zugriff auf das Fahrzeug, um im Backend beliebige Daten zum und vom Fahrzeug zu übertragen, vonnöten.

Backend

• Hier ist ein rund um die Uhr verfügbares Backend-System gefragt, das alle Daten in Echtzeit sammelt, mit Metadaten speichert und mit den Flottenparametern wie Standort, Zeit, Fahrzeugtyp, Softwareversionen usw. verbindet.
• Eine weitere Komponente ist ein Kampagnenmanagementsystem, das auf szenarienbasierte Datenerhebung und Testungen im Schattenmodus spezialisiert ist – direkt verbunden mit Workflows für die datengestützte Entwicklung. Es sollte gut automatisiert sein, aber über Maßnahmen gegen kritische Anfragen verfügen – etwa solche, die die Kommunikation blockieren oder eine sinnlose Ausführung von Kampagnen auslösen.

Entwicklungsumgebung

• Die datengesteuerten Entwicklungsumgebungen müssen erweitert werden, um die Workflows mit Input aus der Flotte und der Erstellung von Kampagnen zu verbinden.
• Um beim Schattentest das Leistungsvermögen einer ganzen Flotte zu nutzen, ist eine spezielle Paketierung des zu testenden Systems vonnöten. Dabei müssen nicht nur Software und DNNs berücksichtigt werden, sondern auch die Abhängigkeiten von der Umgebung und die Gegebenheiten auf der Straße.

Silos aufbrechen – Herausforderungen bei der Umsetzung

Jedes Big-Loop-Element – Backend ebenso wie fahrzeuginterne Software – stellt bei Implementierung, Rollout und Wartung eine Herausforderung für sich dar. Aber die größte Herausforderung besteht darin, wirklich eine ganzheitliche Sichtweise einzunehmen, die komplexen Abhängigkeiten zu verstehen und effiziente Lösungen zu schaffen. Dazu gehört es, lokalen Optimierungen jedes Teilsystems (Silo) zu widerstehen und Führungskräfte zu befähigen, Big-Loop-Anforderungen an alle Organisationseinheiten und deren produzierte Leistung heranzutragen.

Nur durch eine lückenlose Betrachtung des Systems lassen sich Herausforderungen wie transparente fahrzeuginterne Software, Varianten- und Kompatibilitätsprobleme, Einzelkostenoptimierungen, fehlende Hardwarefunktionen, Datenmanagement sowie Sicherheits- und Datenschutzangelegenheiten lösen. Um echten Fortschritt in der sich rasant wandelnden Automobillandschaft zu erzielen, müssen Hersteller über die einzelnen Fachbereiche und Systeme hinweg vernetzt sein.

Sofern ein Unternehmen keine Produktionsgeschichte mit multiplen Marken und vielen verschiedenen Fahrzeugtypen hat, die eine erfolgreiche Implementierung der Big Loop verhindert, besteht eine der größten Herausforderungen in der Unternehmenstradition. Die Herangehensweise sieht hier für gewöhnlich wie folgt aus:

• organische Veränderungen vornehmen (langsam)
• den Weg für eine neue Organisation ebnen
• einen radikalen Greenfield-Ansatz verfolgen

Der Weg in die Zukunft

Die Implementierung einer funktionierenden Big-Loop-Entwicklungsplattform – im Fahrzeug, mit einer stets vernetzten Flotte sowie einer unterstützenden KI-Entwicklungsumgebung – ist der entscheidende Faktor, um die Entwicklung hin zum autonomen Fahren zu beschleunigen. Die Herausforderungen bei der Entwicklung eines solchen Systems bedeuten jedoch letztlich, dass ein Hersteller seine Arbeitsweise massiv ändern müsste, um dies zu verwirklichen. Das könnte sich jedoch lohnen, denn wer den Anfang macht, hat wahrscheinlich auch später die Nase vorn. Es könnte eine „The winner takes it all“-Situation für denjenigen werden, der es schafft, eine solche lückenlose Plattform und ein System für das autonome Fahren zu erschaffen. Der Investitionsbedarf ist gigantisch und es könnte sein, dass nur einmalig in eine Plattform investiert werden kann. Doch der Sieger des Rennens könnte die Plattform ganz leicht für andere lizenzieren – einschließlich der Dienstleistungen, die für fahrzeuginterne Softwarekomponenten benötigt werden.

Es gilt auch, die Entwicklung von Fahrzeugsoftwareplattformen zu beschleunigen – Altsysteme und Rückwärtskompatibilität sind Bremsklötze –, und Hersteller sollten ihre Einkaufsstrategie drastisch ändern: Die unentwegte Kostenoptimierung wird Big-Loop-Funktionalitäten von Anfang an aufgrund fehlender Hardwareleistung blockieren.

Bislang hat es nur ein Hersteller geschafft, eine solche Plattform mit Big Loop zu entwickeln und zu betreiben. Während andere noch Grundsatzdebatten führen, füttert ein Hersteller sein Entwicklungssystem für autonomes Fahren bereits Tag für Tag mit Daten von rund einer Million Fahrzeugen – es ist vielleicht schon zu spät, um in diesem Rennen noch zum Spitzenreiter aufzuschließen. Solch ein System in eine der großen bestehenden Fahrzeugflotten zu integrieren würde jedoch die Möglichkeit eröffnen, riesige Datenmengen in noch nie da gewesenem Tempo zu sammeln.

Darüber hinaus würde der ständige Echtzeitzugriff auf diese großen Flotten auch die Nutzung der Infrastruktur-zu-Fahrzeug-Kommunikation ermöglichen. Das schnelle Ausrollen von On-Demand-Softwarebestandteilen auf ein Fahrzeug könnte auf Parkplätzen oder in zukünftigen Smart Cities genutzt werden, die vielleicht über einen klar abgesteckten und überwachten Raum (Operational Design Domain, kurz ODD) für automatisiertes Fahren verfügen. Intelligente Infrastruktur könnte so mit den Fahrzeugsensoren kombiniert werden, um die ODD viel schneller zu erweitern, als dies ohne Big-Loop-Infrastruktur möglich wäre.

Welcher Automobilhersteller wird sich als nächster ins Abenteuer Big Loop stürzen? Wenn er es richtig macht, stehen seine Chancen gut, dem Hauptfeld so weit vorauszueilen, dass die Mitstreiter keine Chance mehr haben aufzuholen.