Es gibt einen Moment, den die meisten Automobilingenieure kennen. Während einer Testfahrt tritt ein Fehler auf – eine thermische Anomalie, eine unerwartete Meldung im Fahrzeugnetzwerk, ein vorübergehendes Systemverhalten, das eigentlich nicht auftreten dürfte. Der Ingenieur bemerkt es. Die Testfahrt endet, und bis jemand die Daten auswertet, ist das relevante Signalfenster bereits verschwunden – begraben in undifferenzierten Protokollen oder gar nicht erst erfasst. Also plant das Team eine weitere Testfahrt, um den Fehler zu reproduzieren.
Das ist kein Datenproblem. Ingenieure haben selten mit zu wenig Daten zu kämpfen. Es handelt sich um ein architektonisches Problem – und das zeigt sich nicht nur in Validierungslabors, sondern in jeder Phase des Fahrzeuglebenszyklus, von den Prototypentests bis hin zum Qualitätsmanagement im Feld nach der Markteinführung.
Ich arbeite seit Jahren an der Schnittstelle zwischen Fahrzeugsoftware und intelligenten Systemen, und das Muster ist immer dasselbe: Die Automobilindustrie hat eine hochentwickelte Dateninfrastruktur aufgebaut, ohne die Intelligenzebene zu schaffen, die diese Daten verwertbar macht. Wir erfassen. Wir speichern. Wir analysieren später, falls wir dazu kommen. Wir betrachten Intelligenz als etwas, das nach der Datenerfassung geschieht – in einem Bericht oder einem Dashboard –, anstatt als etwas, das kontinuierlich aus dem Fahrzeug selbst hervorgeht.
Das Problem mit der episodischen Intelligenz
Das derzeit vorherrschende Modell für Fahrzeugdatenanalyse ist episodischer Natur: Es erfasst einen Moment, nicht jedoch dessen Ursache, und erfordert menschliches Urteilsvermögen, um beides miteinander zu verknüpfen.
Bei der Validierung zeigt sich dies als das „Re-Drive“-Problem. Ein Testteam führt einen Prototypen durch ein komplexes Szenario – Einfädelverhalten auf der Autobahn, Kaltstart-Temperaturzyklen, ADAS-Grenzfälle im gemischten Verkehr – und es tritt eine Anomalie auf. Der Datenlogger war nicht so konfiguriert, dass er dieses Signal erfasst. Oder er war es zwar, aber das Erfassungsfenster war zu eng. Oder der richtige domänenübergreifende Kontext wurde einfach nicht mit erfasst. Das Team hat ein Symptom, kennt aber die Ursache nicht, also fährt es erneut los. Bei einer begrenzten Prototypenflotte, bei der jedes Fahrzeug eine erhebliche Investition darstellt und die Testpläne ohnehin schon eng sind, beschränken sich die Kosten einer Wiederholungsfahrt nicht nur auf Kraftstoff und Kilometer. Es geht um Entwicklungszeit, die Verfügbarkeit der Prototypen und das Risiko einer Terminverzögerung im Hinblick auf die Frist bis zur Serienreife (SOP), die sich nachteilig auswirkt.
In der Praxis zeigen sich dieselben architektonischen Einschränkungen auf andere Weise. Es tritt ein Qualitätsproblem in der Flotte auf – Garantieansprüche häufen sich in Bezug auf ein bestimmtes Ausfallverhalten, oder in den Betriebsdaten zeichnet sich ein Muster ab. Bis das Ingenieurteam die für die Diagnose der Grundursache erforderlichen Beweise zusammengetragen hat, hat der Ausfall bereits zahlreiche Kunden betroffen. Die Erkenntnisse kamen zu spät, um den Ausgang noch zu beeinflussen.
Beide Probleme haben dieselbe Ursache: Das System wurde entwickelt, um Daten zu speichern, nicht um Erkenntnisse zu gewinnen. Es besteht ein wesentlicher Unterschied zwischen dem Zugriff auf Daten und dem Zugriff auf Erkenntnisse – und genau diese Lücke zu schließen, ist der Zweck des „Agentic Loop“.
Wir stellen den Agentic Loop vor
Der „Agentic Loop“ ist eine geschlossene Intelligenzarchitektur, bei der jede Stufe die nächste kontinuierlich mit Daten versorgt und verfeinert, ohne dass ein manueller Eingriff erforderlich ist, um den Zyklus auszulösen.
Fünf Schritte. Jeder einzelne präzise und wohlüberlegt:
- Erkennen — Überwachen Sie kontinuierlich Signale aus allen Fahrzeugbereichen, um Anomalien, Abweichungen und untersuchungswürdige Zustände in Echtzeit zu identifizieren.
- Erfassen — Erfassen Sie zielgerichtete, kontextbezogene Daten genau dann und dort, wo es darauf ankommt — keine pauschale Protokollierung, sondern eine intelligente Datenerfassung, die an erkannte Ereignisse gekoppelt ist.
- Begründung — Wenden Sie „AI “-gestützte Analysen auf Daten aus verschiedenen Quellen an, um Hypothesen zu formulieren, Einflussfaktoren zu identifizieren und kausale Schlussfolgerungen zu ziehen.
- Handeln — Stellen Sie dem richtigen Ingenieur Erkenntnisse bereit, führen Sie ein Konfigurationsupdate durch oder lösen Sie eine Serviceempfehlung aus — autonom und zielgerichtet.
- Lernen — die Ergebnisse wieder in die Erkennungs- und Schlussfolgerungsmodelle einfließen zu lassen, damit jeder nachfolgende Zyklus präziser ist als der vorherige.
Die Bezeichnung „Betriebssystem“ ist bewusst gewählt. Genauso wie ein Betriebssystem die Anwendung nicht ausführt – sondern die Voraussetzungen dafür schafft, dass Anwendungen effektiv laufen –, ersetzt der „Agentic Loop“ nicht das technische Urteilsvermögen. Er abstrahiert die Komplexität der Fahrzeugdaten, sodass sich Ingenieure auf Entscheidungen konzentrieren können, anstatt sich mit der Aufbereitung von Daten zu beschäftigen. Validierungsingenieure, Qualitätsmanager und der Kundendienst können alle auf derselben intelligenten Schleife arbeiten – so wie verschiedene Anwendungen auf einem gemeinsamen Betriebssystem laufen –, wobei jeder das, was er benötigt, aus einer gemeinsamen Infrastruktur bezieht.
So lässt sich das Argument zusammenfassen. Doch der Begriff „Betriebssystem“ ist eine Metapher, die sich leicht formulieren, aber viel schwerer erfüllen lässt. Er ist nur dann stichhaltig, wenn jede Phase des Kreislaufs tatsächlich das tut, was oben beschrieben wurde.
In Teil 2 dieses Blogbeitrags gehen wir die Phasen „Erkennen“, „Erfassen“, „Analysieren“, „Handeln“ und „Lernen“ einzeln durch und erläutern, was sich in jeder einzelnen Phase ändert.
