Remote-Analysen bei der Fahrzeugentwicklung und Produktpflege

Der traditionelle Ansatz ist ebenso rudimentär wie unbefriedigend: Log-Dateien und Fehlerprotokolle der Steuergeräte werden in der Werkstatt ausgelesen, dort zur Fehlerdiagnose genutzt und dem OEM anschließend gegebenenfalls zur Verfügung gestellt. Diese Daten sind daher nicht zeitnah verfügbar und ihre Erhebung erfolgt nur dann, wenn der Fahrer ein Problem mit seinem Auto hat oder seinen Händler für eine Routineinspektion besucht. Mit Remote-Diagnosen über eine bestehende Fahrzeugvernetzung lässt sich dieser Prozess erheblich verbessern. Davon profitieren OEMs und die Nutzer beziehungsweise Besitzer der Fahrzeuge gleichermaßen. Auch für Händler und Werkstätten bietet diese Vorgehensweise interessante Geschäftsmodelle. Das Remote-Analytics-System EB Cadian stellt eine Komplettlösung für solche Anwendungen dar, die auf einem eigens entwickelten Workflow basiert und einen On-Demand-Ansatz für die Erfassung und Analyse von Fahrzeugdaten verfolgt.

Im Gegensatz zur kontinuierlichen Datensammlung erhebt EB Cardian nur spezifische, vordefinierte Datensätze. Elektrobit

Im Markt gibt es bereits Verfahren, die kontinuierlich mit einer bestimmten Erfassungsrate einen Satz von Messwerten oder Fahrzeugdaten sammeln und für spätere Analysen vorhalten. Diese Vorgehensweise eignet sich zwar gut dafür, umfassende Erkenntnisse über das Verhalten einer kompletten Fahrzeugflotte zu gewinnen, birgt aber auch Nachteile. So stehen für die Analyse nur vordefinierte Daten zur Verfügung und der Aufwand und die Last für die Mobilfunkübertragung und für die zur Speicherung verwendeten Backendsysteme ist erheblich. In manchen Ländern, einschließlich dem datenschutzsensiblen deutschen Markt, wirft ein solches Vorgehen nicht zu vernachlässigende juristische Fragen auf.

Demgegenüber bietet ein fallbezogener On-Demand-Ansatz für Datenanalysen klare Vorteile: Er unterstützt spezielle Fragestellungen, für die man sehr spezifische Fahrzeugdaten erheben und analysieren muss. Er arbeitet außerdem ressourcenschonend und berücksichtigt das Grundprinzip einer möglichst sparsamen Erhebung von Daten. Allerdings müssen Analysten die von ihnen untersuchten Fragestellungen im Vorfeld exakt spezifizieren. EB Cardian verfolgt genau diesen Ansatz.

Definierter Workflow für Remote-Analysen

Ein eigens entwickelter Workflow beschreibt den detaillierten Ablauf der Datenerfassung und -analyse. Elektrobit

Der typische Workflow einer auf diese Weise durchgeführten Datenanalyse umfasst die Formulierung einer exakten Fragestellung, die Definition der zu berücksichtigenden Daten und Fahrzeuge, die Durchführung der Datenerfassung, eine Qualitätssicherung des gesammelten Datenbestands, die darauf basierende Analyse und die Aufbereitung der Ergebnisse. Die erzeugten Reports und gegebenenfalls Datenexporte sind dann die Basis für weitere Prozessschritte. Dieser Ablauf lässt sich am besten an einem bewusst einfach gehaltenen praktischen Beispiel verdeutlichen: eine Analyse möglicher Ausfälle der Starterbatterien im Winter.

Die für eine solche Analyse formulierte Fragestellung könnte zum Beispiel lauten: „Gibt es in der Fahrzeugflotte Starterbatterien, die sich signifikant anders verhalten als die meisten anderen Batterien?“ Die Annahme hier ist, dass ein solcher Ausreißer im Verhalten einen Indikator für einen potenziellen Ausfall darstellt. Um diese Frage auf Basis quantifizierbarer Daten beantworten zu können, lässt sich zum Beispiel die Aufgabe „Erfasse 900 mal den Spannungspegel der Batterie im Abstand von jeweils 1000 Millisekunden“ ableiten. Typischerweise würde diese Aufgabe zudem auf einen für die Analyse besonders relevanten Teil der Fahrzeugflotte begrenzt – im erwähnten Beispiel könnten dies Fahrzeuge mit Benzinmotoren sein, die älter als drei Jahre sind. Die Analyse-Plattform EB Cadian definiert für solche Aufgaben-Spezifikationen eine domänenspezifische Sprache (domain-specific language – DSL).

Eine DSL ist eine computerinterpretierbare Sprache, die spezifisch für einen Themenschwerpunkt entwickelt wurde, wie beispielsweise die gezielte Sammlung von Fahrzeugdaten durch Analysten. Wichtig bei der Spezifikation der Datensammlungsaufgabe ist, dass diese agnostisch gegenüber einzelnen Fahrzeugen bleibt: Sie darf keinerlei Details über die fahrzeuginterne Herkunft und Repräsentation der Daten enthalten. Die Auswahl der Fahrzeuge aus der gesamten Flotte erfolgt anschließend über Eigenschaften wie Kraftstoffart, Kilometerstand, Modell oder Ausstattungslinie und ähnliche Merkmale. Sofern ein OEM, der Zugriff auf spezifische Daten wie Produktionsdatum, Fahrgestell-, Serien- oder Teilenummern und ähnliches hat, das System einsetzt, kommen auch diese Angaben als Filtermerkmale in Frage.

Aus der so formulierten und auf relevante Flottenmitglieder eingegrenzten Experiment-Definition leitet sich die konkrete Erfassung der Daten ab. Die Analyse-Plattform erzeugt aus der fahrzeugagnostischen Darstellung fahrzeugspezifische Aufgaben und weist diese den durch den Filter bestimmten einzelnen Fahrzeugen zu. Nur in diesen Fahrzeugen führen die betroffenen Steuergeräte diese Aufgabe während der Fahrt aus. Ein Teil der Datenverarbeitung erfolgt bereits lokal im Auto, beispielsweise die Normalisierung und Umrechnung von Messwerten auf SI-Einheiten oder die einfache Verknüpfung mehrerer Messwerte zu einer abgeleiteten Größe. Dabei kommen verschiedene Datenquellen in Betracht, etwa Informationen vom CAN-Bus, Diagnosedaten oder Bedienvorgänge des Fahrers wie beispielsweise ausgelöste Touch-Events des HMI (Human Machine Interface).

Die von den Steuergeräten erfassten Diagnosedaten werden verschlüsselt und signiert an das Backend übertragen und dort gesammelt. Im genannten Batterie-Beispiel wäre dies nun der Spannungsverlauf der Batterie über den definierten Erfassungszeitraum.

Qualitätssicherung und Analysetechniken

Ein weiterer wichtiger Schritt ist die Qualitätssicherung. Es wird immer wieder vorkommen, dass einzelne Messdaten fehlerhaft sind, beispielsweise dass sie außerhalb eines plausiblen Wertebereichs liegen, beschädigte Zeitstempel besitzen oder andere Mängel aufweisen. Vor der Analyse sollte man deshalb die Konsistenz der Daten prüfen und sicherstellen. Dies kann neben der Filterung unplausibler Werte zum Beispiel auch die Interpolation fehlender Messwerte bedeuten. Je nach Aufgabenstellung besteht auch die Möglichkeit, einen Datensatz, der mehr als einen bestimmten Prozentsatz als potenziell falsch erkannter Messwerte enthält, von der weiteren Verarbeitung auszuschließen und den gesamten fehlerhaften Messwertesatz zu ignorieren.

Aus den Zeitreihen der Autos transformierte Histogramme stellen die Vergleichbarkeit zwischen Fahrzeugen oder Fahrzeugflotten her. Elektrobit

Anschließend erfolgt die Analyse der Daten gemäß der ursprünglich formulierten Aufgabenstellung. Dies kann wie im genannten Fall der Starterbatterie eine Identifikation von Ausreißern oder Auffälligkeiten sein: die Zeitreihen der Autos werden hierbei in Histogramme transformiert, um die Vergleichbarkeit zwischen Autos herzustellen. Im nächsten Schritt wertet das System paarweise zwischen jeweils zwei Autos eine sogenannte Distanzfunktion aus, welche ein Maß für die Ähnlichkeit der Spannungshistogramme darstellt. Dieser Vergleich kann zwischen den teilnehmenden Autos eines einzigen Datensammlungslaufs erfolgen, oder auch über mehrere Läufe hinweg. Nach der Auswertung aller Vergleichspaare lassen sich Autos identifizieren, die nur wenige oder keine Nachbarn im Vergleich der Spannungshistogramme haben (k-nearest neighbor).

Dieser im vorliegenden Beispiel bewusst einfach gehaltene Ansatz lässt sich hin zu multivariaten Daten, anwendungsspezifischen Transformationen der Zeitachse oder anderen Mustererkennungsalgorithmen erweitern. Ein Vorteil dieser Methode ist, dass sie eine unüberwachte Variante maschinellen Lernens ist und zur Ausführung keine teuren Trainingsdaten benötigt. Natürlich sind an dieser Stelle auch komplexere Algorithmen denkbar, die problemspezifischer designt sind und somit zusätzliche Informationen in den Analyseprozess einfließen lassen können.

Am Ende steht die Aufbereitung der ermittelten Ergebnisse, beispielsweise in Form von Text- oder Grafikdaten oder auch als numerische Werte in Form von CSV-Dateien, um die Analyseergebnisse nach Bedarf extern weiterzuverarbeiten.

Das Ergebnis steht natürlich in erster Linie demjenigen zur Verfügung, der die ursprüngliche Analyse-Aufgabe definiert und in Auftrag gegeben hat. Analyse-Experten sind jedoch typischerweise Multiplikatoren innerhalb ihres Unternehmens, die spezifische Verfahren, Ergebnisse und Erkenntnisse dann mit anderen Beteiligten teilen sowie gelegentliche Nutzer des Systems in die Lage versetzen, komplexe Aufgabenstellungen zu bearbeiten. Die Konsequenzen aus einer entsprechenden Analyse könnten – teilautomatisiert oder gegebenenfalls auch als Ergebnis eines komplett automatischen Prozesses – zum Beispiel zu einer Benachrichtigung im Fahrzeug führen. Im Batterie-Beispiel käme etwa eine Displaymeldung in Betracht, die auf den möglichen baldigen Ausfall der Batterie hinweist. Hierauf können wiederum weiterführende Geschäftsmodelle gründen, etwa ein Sonderangebot für den Einbau einer neuen Batterie.

Datenschutz und Datensicherheit im Fokus

Datenschutz und Datensicherheit sind wichtige Aspekte, die beim Design von EB Cadian eine zentrale Rolle spielten. So sind die im Rahmen von Remote-Analysen erfassten Daten  anonymisiert. Sowohl der Zugriff auf das Frontend durch den Analysten als auch der Zugriff durch das System auf jedes einzelne Fahrzeug erfordert eine gegenseitige Authentifizierung. Alle Verbindungen und alle übermittelten Datensätze erfahren eine Verschlüsselung nach starken kryptografischen Verfahren. Alle Abfragen und Datenkommunikationsvorgänge dokumentiert man im Hinblick auf gegebenenfalls betroffene Compliance-Richtlinien und möglicherweise erforderliche Audits in ebenfalls verschlüsselten und zugriffsgeschützten Logdateien.

Neben Sicherheitsfragen ist auch die Skalierbarkeit der Plattform und der beigefügten Systeme ein wichtiger Faktor. Elektrobit

Überdies hat Elektrobit für den Einsatz seines Systems und generell für die Sicherheit von Cloud-Anwendungen einige Best Practices definiert: Gerade im Hinblick auf Datenschutz und Datensicherheit sollte eine Risiko- und Bedrohungsanalyse erfolgen, die bei der Identifikation der notwendigen Sicherheitskonzepte und -elemente hilft. Im Rahmen von Software-Entwicklungen sollte man die Code-Qualität durch eine Qualitätsmanagement-Plattform überwachen und sicherstellen. Grundsätzlich ist es ratsam, möglichst viele Teile der Prozesse rund um Entwicklung, Provisionierung, Test, Roll-out und Monitoring zu automatisieren. Reproduzierbarkeit der Ergebnisse, ihre Zuverlässigkeit sowie die mögliche Umsetzungsgeschwindigkeit steigen dadurch deutlich.

Neben Sicherheitsfragen ist auch die Skalierbarkeit der Plattform und der vom OEM beziehungsweise Tier 1 beigefügten Systeme ein wichtiger Faktor. Mit seiner zustandslosen Micro-Service-Architektur ist EB Cadian hier konzeptionell auf dem neuesten Stand der Technik. Für eigene Entwicklungen und Ergänzungen empfiehlt der Hersteller den Grundsatz „Think big“, denn es ist meist sehr schwer, ein nicht von vornherein auf horizontale Skalierbarkeit ausgelegtes System für sehr hohe Last zu skalieren. Der übliche Weg, einfach größere Maschinen zu kaufen führt schnell in eine Sackgasse. Einzig eine von vornherein skalierbare Architektur kann dies leisten. Ein zweiter Aspekt der Skalierbarkeit ist der umgekehrte Fall: In Zeiten geringer Last sollte das System in der Lage sein, nicht genutzte Ressourcen freizugeben und somit Kosten zu sparen.

Um ein möglichst breites Spektrum an Einsatzmöglichkeiten zu unterstützen, ist EB Cadian modular aufgebaut und lässt sich als Modul in bestehende Flotten- und Modell-Management-Systeme oder Analyse-Tools integrieren. Mit On-Demand-Datenanalysen im Feld erschließen sich OEMs und Tier 1 viele neue Möglichkeiten zur Verbesserung ihrer Entwicklungsprozesse und Produkte sowie zur Realisation neuer Dienste und Geschäftsmodelle.

(pet)