DE102019135608A1

DE102019135608A1 - Verfahren, Vorrichtung und System zur Detektion von anomalen Betriebszuständen eines Geräts

Info

Publication number: DE102019135608A1
Application number: DE102019135608.3A
Authority: DE
Inventors: Bernhard Schlegel; Philipp Reinisch; Christoph Weidner
Original assignee: Bayerische Motoren Werke AG
Current assignee: Bayerische Motoren Werke AG
Priority date: 2019-12-20
Filing date: 2019-12-20
Publication date: 2021-06-24
Also published as: CN114585983B; CN114585983A; WO2021121695A1; US20230013544A1

Abstract

Es werden ein Verfahren, eine Vorrichtung sowie ein System zur Detektion von anomalen Betriebszuständen eines Geräts, insbesondere eines Kraftfahrzeugs angegeben. Das Verfahren umfasst die Schritte:a) Bereitstellen von Modelldaten (M) an das Gerät, die repräsentativ sind für einen zu erwartende Betriebszustände wenigstens einer Komponente (2-5) des Geräts,b) Erheben von Messdaten (D) durch das Gerät, die repräsentativ sind für einen tatsächlichen Betriebszustand der wenigstens einen Komponente (2-5) des Geräts,c) Ermitteln von Vergleichsdaten (V) durch das Gerät in Abhängigkeit der Modelldaten (M) und der Messdaten (D), die repräsentativ sind für einen erwarteten Betriebszustand,d) Prüfen abhängig von den Vergleichsdaten (V) und den Messdaten (D), ob eine Abweichung des tatsächlichen Betriebszustands von dem erwarteten Betriebszustand vorliegt, unde) Zuordnen eines anomalen Betriebszustands der wenigstens einen Komponente (2-5) korrespondierend zu einem Zeitpunkt der Erhebung der Messdaten (D) abhängig von der Abweichung.

Description

Die Erfindung betrifft ein Verfahren zur Detektion von anomalen Betriebszuständen eines Geräts, insbesondere eines Kraftfahrzeugs sowie eine korrespondierende Vorrichtung sowie ein korrespondierendes System. Ferner werden ein korrespondierendes Computerprogramm und Speichermedium angegeben.
Heutige Kraftfahrzeuge verfügen über eine Vielzahl an Fahrzeugfunktionen, neben grundlegenden Komfortfunktionen, Assistenz- bzw. fahrdynamischen Einstellungen auch sicherheitskritische Funktionen, die etwa die automatisierte Durchführung von Fahrmanövern, insbesondere teil- oder vollautonomes Fahren erlauben.
Mit zunehmender Komplexität der Fahrzeugfunktionen sowie deren immer höheren Vernetzungsgrad steigt die Menge an Daten, die im Rahmen eines Betriebs der einzelnen Fahrzeugfunktionen erhoben bzw. ausgetauscht werden. Im Zuge dessen wird es immer schwieriger, anomale Betriebszustände, d.h. Fehler sowie Spezifikationsabweichungen im Betrieb der einzelnen Fahrzeugfunktionen, durch manuelle Modellierung zu detektieren und zu evaluieren.
Als manuelle Modellierung wird dabei die Erstellung eines Zustandsautomaten anhand der Fahrzeugspezifikationen bezeichnet, anhand dessen sämtliche Soll-Betriebszustände einzelner Komponenten des Kraftfahrzeugs abgebildet sind. Als Komponente sind hier und im Folgenden sowohl einzelne Software- als auch Hardwarebestandteile des Kraftfahrzeugs sowie eine Kombination mehrerer Software- und/oder Hardwarebestandteile des Kraftfahrzeugs bezeichnet, durch die jeweils eine oder mehrere Fahrzeugfunktionen umgesetzt werden. Während des Betriebs des Kraftfahrzeugs werden die erhobenen bzw. auf einem Bussystem des Kraftfahrzeugs ausgetauschten Daten üblicherweise aufgezeichnet; je nach Fahrzeugfunktion bzw. Komponente kann es sich hierbei um Diagnosedaten wie Status- oder Fehlersignale, Steuersignale zur Steuerung oder Regelung einzelner Komponenten oder um Daten handeln, die repräsentativ sind für erfasste Messwerte wie etwa Geschwindigkeit oder Lenkwinkel des Kraftfahrzeugs. Im Folgenden werden sämtliche vorgenannter erhobener oder ausgetauschter Daten als Messdaten bezeichnet. Im Anschluss an den Betrieb des Kraftfahrzeugs kann dann die gesamte aufgezeichnete Menge an Messdaten ausgelesen werden, um diese auf Abweichungen hinsichtlich der Soll-Betriebszustände anhand eines oder mehrerer Modelle zu prüfen.
Eine Aufgabe, die der Erfindung zugrunde liegt, ist es, ein effizientes sowie zuverlässiges Verfahren zur Detektion von anomalen Betriebszuständen eines Kraftfahrzeugs zu schaffen. Weiter sollen eine korrespondierende Vorrichtung, ein korrespondierendes System sowie ein Computerprogramm und Speichermedium angegeben werden.
Die Aufgabe wird gelöst durch die unabhängigen Patentansprüche. Vorteilhafte Ausgestaltungen sind in den Unteransprüchen gekennzeichnet.
Gemäß einem ersten Aspekt betrifft die Erfindung ein Verfahren zur Detektion von anomalen Betriebszuständen eines Kraftfahrzeugs.
Das Verfahren umfasst die Schritte:

a) Bereitstellen von Modelldaten an das Kraftfahrzeug, die repräsentativ sind für zu erwartende Betriebszustände wenigstens einer Komponente des Kraftfahrzeugs;
b) Erheben von Messdaten durch das Kraftfahrzeug, die repräsentativ sind für einen tatsächlichen Betriebszustand der wenigstens einen Komponente des Kraftfahrzeugs;
c) Ermitteln von Vergleichsdaten durch das Kraftfahrzeug in Abhängigkeit der Modelldaten und der Messdaten, die repräsentativ sind für einen erwarteten Betriebszustand;
d) Prüfen abhängig von den Vergleichsdaten und den Messdaten; ob eine Abweichung des tatsächlichen Betriebszustands von dem erwarteten Betriebszustand vorliegt; und
e) Zuordnen eines anomalen Betriebszustands der wenigstens einen Komponente korrespondierend zu einem Zeitpunkt der Erhebung der Messdaten abhängig von der Abweichung.

Die Modelldaten sind insbesondere repräsentativ für ein statistisches Modell, welches jeweils ausgehend von einem Ausgangszustand bzw. den bereits durchlaufenen Betriebszuständen der wenigstens einen Komponente einen wahrscheinlichsten nächsten Betriebszustand der wenigstens einen Komponente angibt. Der wahrscheinlichste nächste Betriebszustand wird auch als erwarteter Betriebszustand bezeichnet und durch die in dem Schritt c) ermittelten Vergleichsdaten repräsentiert.
Als statistisches Modell kommt bevorzugt ein (tiefes) künstliches neuronales Netzwerk in Betracht. Als Betriebszustand ist insbesondere jegliche Aktion der jeweiligen Komponente, welche durch Ausgabe entsprechender Messdaten repräsentiert ist, sowie das Ausbleiben einer Aktion der jeweiligen Komponente zu verstehen.
Zur Ermittlung der Abweichung in dem Schritt d) kann beispielsweise ein abstands-basiertes Verfahren wie „k-Nearest Neighbours“ (kNN), „Local Outlier Factor“ (LOF), „[Hierarchical]-Density-Based Spatial Clustering of Applications with Noise“ ([H]-DBSCAN) oder „Ordering Points To Identify the Clustering Structure“ (OPTICS), ein ensemblebasiertes Verfahren wie „Isolation Forest“ (IF), ein statistisches Verfahren wie „Gaussian Mixture Models“ (GMM), „Independent Component Analysis“ (ICA) oder „Vector Auto-Regressive (VAR), ein domain-basiertes Verfahren wie „[Oneclass] Support Vectore Machine“ ([OC]-SVM) oder ein rekonstruktions-basiertes Verfahren wie „Extreme Learning Machines“ (ELM) zum Einsatz kommen.
Die Schritte d) und e) können insbesondere gemäß dem in „Advances in Neural Information Processing Systems‟, 2019, S. 12831-12840 von Bertrand Charpentier, Marin Biloš und Stephan Günnemann sowie auf der „Neural Information Processing Systems" Konferenz 2019 vorgestellten Verfahren „Uncertainty on Asynchronous Time Event Prediction“ durchgeführt werden.
In vorteilhafterweise ermöglicht das Verfahren gemäß dem ersten Aspekt eine Detektion von anomalen Betriebszuständen des Kraftfahrzeugs während des Betriebs des Kraftfahrzeugs, insbesondere in Echt-Zeit. Mit Vorteil kann so auf eine Übermittlung der gesamten Menge an Messdaten verzichtet bzw. auf Messdaten beschränkt werden, welche zu einem anomalen Betriebszustand wenigstens einer Komponente korrespondieren. Überdies ist denkbar, bereits während des Betriebs des Kraftfahrzeugs entsprechende Maßnahmen zu ergreifen, falls ein anomaler Betriebszustand einer sicherheitsrelevanten Fahrzeugfunktion erkannt wurde, so dass zu einem besonders sicheren Fahrbetrieb des Kraftfahrzeugs beigetragen werden kann.
Anstelle eines Kraftfahrzeugs kann vorgenanntes Verfahren auch auf andere mit entsprechender Sensorik ausgestattete Vorrichtungen (im folgenden auch als „Gerät“ bezeichnet) herangezogen werden, zur Überwachung von Betriebszuständen der jeweiligen Vorrichtung. Sämtliche hier und im Folgenden im Zusammenhang mit einem Kraftfahrzeug offenbarten merkmale sind sinngemäß auch auf derartige Vorrichtungen übertragbar.
In einer vorteilhaften Ausgestaltung gemäß dem ersten Aspekt werden vor dem Schritt c) dem Kraftfahrzeug eine zu evaluierende Fahrzeugfunktion vorgegeben, und abhängig von der zu evaluierenden Fahrzeugfunktion und den Messdaten gefilterte Messdaten ermittelt. Zum Ermitteln der Vergleichsdaten in dem Schritt c) werden die gefilterten Messdaten herangezogenen.
Insbesondere werden die Messdaten derart gefiltert, dass nur mehr Messdaten von an der am Betrieb der zu evaluierenden Fahrzeugfunktion beteiligten Komponenten von den gefilterten Messdaten umfasst sind.
In einer weiteren vorteilhaften Ausgestaltung gemäß dem ersten Aspekt werden die Schritte b) bis d) jeweils zu mehreren aufeinanderfolgenden Zeitpunkten durchgeführt. Im Falle, dass zu wenigstens N aufeinanderfolgenden Zeitpunkten jeweils eine Abweichung des tatsächlichen Betriebszustands von dem erwarteten Betriebszustand ermittelt wird, wird in dem Schritt e) der wenigstens einen Komponente korrespondierend zu den N aufeinanderfolgenden Zeitpunkten der anomale Betriebszustand zugeordnet, wobei N eine natürliche Zahl größer 1 bezeichnet, insbesondere größer 5, bevorzugt größer 10.
In anderen Worten führt erst eine mehrmalige Abweichung des tatsächlichen Betriebszustands von dem erwarteten Betriebszustand zu einer Einstufung als anomaler Betriebszustand.
In einer weiteren vorteilhaften Ausgestaltung gemäß dem ersten Aspekt werden in einem auf den Schritt e) folgenden Schritt f) im Falle, dass der wenigstens einen Komponente ein anomaler Betriebszustand zugeordnet ist, die zu dem anomalen Betriebszustand korrespondierenden Messdaten gespeichert und/oder ausgegeben.
Insbesondere können in diesem Zusammenhang Messdaten, welche nicht zu einem anomalen Betriebszustand korrespondieren, nach deren Erheben verworfen werden, so dass eine nachfolgende Auswertung vereinfacht und/oder ein Speicheraufwand reduziert werden kann.
In einer weiteren vorteilhaften Ausgestaltung gemäß dem ersten Aspekt umfasst der Schritt a) gemäß einem zweiten Aspekt:

- Bereitstellen von Betriebsdaten eines oder mehrerer Kraftfahrzeuge an ein Rechenzentrum,
- Vorgeben einer zu evaluierenden Fahrzeugfunktion an das Rechenzentrum und Ermitteln von gefilterten Betriebsdaten abhängig von der zu evaluierenden Fahrzeugfunktion und den Betriebsdaten,
- Ermitteln von Modelldaten durch Trainieren eines Modells in Abhängigkeit der gefilterten Betriebsdaten für die zu evaluierende Fahrzeugfunktion, und
- Bereitstellen der ermittelten Modelldaten an das Kraftfahrzeug.

Bei den bereitgestellten Betriebsdaten an das Rechenzentrum handelt es sich insbesondere um historische Betriebsdaten, beispielsweise aufgezeichnete Bussignale im Rahmen von Testfahrten einer Vielzahl an Kraftfahrzeugen.
In vorteilhafter Weise ermöglicht das Verfahren gemäß dem zweiten Aspekt eine automatische Erzeugung eines Modells zur Detektion von anomalen Betriebszuständen des Kraftfahrzeugs. Hierfür ist im Gegensatz zu einer manuellen Modellierung insbesondere eine Kenntnis sämtlicher etwaig auftretender Fehler nicht erforderlich, so dass zu einer Zuverlässigkeit bei der Detektion von anomalen Betriebszuständen sowie einem sicheren Fahrbetrieb des Kraftfahrzeugs beigetragen werden kann.
In einer weiteren vorteilhaften Ausgestaltung gemäß dem zweiten Aspekt werden die zu dem anomalen Betriebszustand korrespondierenden Messdaten in dem Schritt f) dem Rechenzentrum übermittelt.
Beispielsweise ist die Vorrichtung in diesem Zusammenhang signaltechnisch mit dem Rechenzentrum koppelbar, etwa durch Auslesen der Vorrichtung bei einem Werkstattbesuch des Kraftfahrzeugs oder durch eine Internetverbindung.
In einer weiteren vorteilhaften Ausgestaltung gemäß dem ersten oder zweiten Aspekt sind die Modelldaten repräsentativ für ein künstliches neuronales Netz. Bevorzugt handelt es sich hierbei um ein tiefes künstliches neuronales Netz. Derartige Modelle sind insbesondere bei Messdaten von Vorteil, die als kontinuierliche Zeitreihen mit nicht äquidistanten Messwerten vorliegen.
Gemäß einem dritten Aspekt betrifft die Erfindung eine Vorrichtung zur Detektion von anomalen Betriebszuständen für ein Kraftfahrzeug. Die Vorrichtung ist eingerichtet, ein Verfahren gemäß dem ersten Aspekt auszuführen. Insbesondere sind der Vorrichtung in diesem Zusammenhang eine Komponente zum Erheben von Messdaten, eine Empfangseinheit zum Empfang bereitgestellter Modelldaten sowie eine Recheneinehit zur Verarbeitung der Daten zugeordnet.
Gemäß einem vierten Aspekt betrifft die Erfindung ein System zur Detektion von anomalen Betriebszuständen eines Kraftfahrzeugs. Das System umfasst ein Rechenzentrum sowie ein Kraftfahrzeug mit einer Vorrichtung gemäß dem dritten Aspekt. Das System ist eingerichtet, ein Verfahren gemäß dem ersten oder zweiten Aspekt auszuführen.
Gemäß einem fünften Aspekt betrifft die Erfindung ein Computerprogramm umfassend Befehle, die bei der Ausführung des Computerprogramms durch einen Computer diesen veranlassen, das Verfahren gemäß dem ersten oder zweiten Aspekt auszuführen.
Gemäß einem sechsten Aspekt betrifft die Erfindung ein computerlesbares Speichermedium, auf dem das Computerprogramm gemäß dem fünften Aspekt gespeichert ist Ausführungsbeispiele der Erfindung sind im Folgenden anhand der schematischen Zeichnungen näher erläutert.
Es zeigen:

1 System zur Detektion von anomalen Betriebszuständen eines Kraftfahrzeugs, und
2 Verfahren zur Detektion von anomalen Betriebszuständen eines Kraftfahrzeugs gemäß 1.

Elemente gleicher Konstruktion oder Funktion sind figurenübergreifend mit den gleichen Bezugszeichen versehen.
Bereits heute fließen durch Fahrzeuge große Datenmengen, die während der Fahrt aufgezeichnet und beispielsweise zur Erkennung von Fehlfunktionen nach der Fahrt ausgewertet werden können.
Die Menge und Komplexität der Daten wird in künftigen Fahrzeuggenerationen weiter steigen. Daher ist es nicht mehr praktikabel, alle Daten zu erheben und diese individuell mittels manuell erstellter Modelle zu analysieren. Dies gilt insbesondere, weil nicht alle Fehler im Voraus bekannt sind.
Aufgrund dessen wird im Folgenden eine Datenverarbeitung mittels einem neuralen Netzwerk vorgeschlagen.
Zukünftige Systeme setzen auf künstliche Intelligenz bzw. Deep Learning (DL). Hier lernen neuronale Netze eigenständig aus großen Datenmengen und sind in der Lage automatisch Anomalien und Fehler zu erkennen. Kernbestandteil ist ein tiefes neuronales Netz, das in der Lage ist künftige Signale und deren Wert auf Basis historischer Daten vorherzusagen. Wiederholte Abweichungen zwischen Vorhersage und tatsächlichem Wert deuten auf anomale Zustände hin und können dadurch detektiert und evaluiert werden.
Die Anwendung dieser Modelle ist live im Fahrzeug möglich. Dadurch müssen nach der Fahrt nur noch gezielt die anomalen Situationen ausgelesen und gespeichert werden. So reduzieren sich die Aufwände für Datenübertragung und Analyse in erheblichem Maße.
Mit Vorteil werden Modelle automatisch auf Basis historischer Daten generiert. Probleme müssen davor nicht explizit bekannt sein. Eine live Auswertung während der Fahrt wird ferner ermöglicht. Schließlich müssen nur noch Daten von Abweichungen ausgewertet werden.
Anhand 1 ist ein System 100 zur Detektion von anomalen Betriebszuständen eines Kraftfahrzeugs 10 dargestellt. Das System 100 umfasst neben dem Kraftfahrzeug 10 ein Rechenzentrum 20, das beispielhaft mit einer Vielzahl weiterer (nicht dargestellter) Kraftfahrzeuge zur Auswertung ihrer Betriebsdaten signaltechnisch gekoppelt ist.
Dem Kraftfahrzeug 10 ist eine Vorrichtung 1 zur Detektion von anomalen Betriebszuständen zugeordnet, die signaltechnisch mit dem Rechenzentrum 20 koppelbar ist (angedeutet durch den gestrichelten Pfeil). Bei der Vorrichtung 1 handelt es sich beispielsweise um einen sogenannten „Mobile Data Recorder“ (MDR). Überdies weist das Kraftfahrzeug 10 mehrere Komponenten 2, 3, 4, 5 auf die beispielsweise über einen Fahrzeugbus 6 mit der Vorrichtung 1 verbunden sind.
Beispielsweise handelt es sich bei der Komponente 2 um einen Geschwindigkeitssensor, bei der Komponente 3 um einen Lenkwinkelsensor, bei der Komponente 4 um einen Radarsensor, und bei der Komponente 5 um einen Fensterheber. Die Komponenten 2-4 werden beispielhaft zur Umsetzung der Fahrzeugfunktion F „Abstandsassistent“ benötigt während die Komponente 5 keinen Einfluss auf diese Fahrzeugfunktion F hat.
Das System 100 ist eingerichtet, ein Verfahren zur Detektion von anomalen Betriebszuständen A auszuführen wie anhand des schematischen Ablaufdiagramms der 2 im Folgenden näher erläutert:

Zunächst werden dem Rechenzentrum 20 in einem Schritt a1) historische Betriebsdaten B sämtlicher Komponenten 2-5 einer Vielzahl von Kraftfahrzeugen bereitgestellt, die repräsentativ sind für einen zeitlichen Verlauf von Betriebszuständen der entsprechenden Komponenten 2-5. Überdies wird in einem Schritt a2) dem Rechenzentrum 20 die zu evaluierende Fahrzeugfunktion F „Abstandsassistent“ vorgegeben.

Anhand der historischen Betriebsdaten B werden daraufhin beispielsweise durch das Rechenzentrum 20 in einem Schritt a3) gefilterte Betriebsdaten B* ermittelt, die nur mehr historische Betriebsdaten der an der Fahrzeugfunktion F beteiligten Komponenten 2-4 umfassen.
In einem darauffolgenden Schritt a4) wird durch das Rechenzentrum 20 ein künstliches neuronales Netz (knN) anhand der gefilterten Betriebsdaten B* trainiert und beispielsweise Hyperparameter des knN als Modelldaten M an die Vorrichtung 1 des Kraftfahrzeugs 10 ausgegeben. Dem Kraftfahrzeug 10 wird überdies in einem Schritt a5) die zu evaluierende Fahrzeugfunktion F „Abstandsassistent“ vorgegeben.
In einem Schritt b) werden der Vorrichtung 1 Messdaten D der Komponenten 2-5 des Kraftfahrzeugs 10 bereitgestellt. Bei den Messdaten D handelt es sich jeweils um ein mit einem der historischen Betriebsdaten B vergleichbares Betriebsdatum, das repräsentativ ist für einen aktuellen bzw. tatsächlichen Betriebszustand der jeweiligen Komponente 2-5 des Kraftfahrzeugs 10.
In einem darauffolgenden Schritt b2) werden abhängig von der zu evaluierenden Fahrzeugfunktion F und den Messdaten D gefilterte Messdaten D* durch die Vorrichtung 1 ermittelt, die nur mehr Messdaten D der an der Fahrzeugfunktion F beteiligten Komponenten 2-4 umfassen.
In einem Schritt c1) werden Vergleichsdaten V durch die Vorrichtung 1 abhängig von den Modelldaten M und den gefilterten Messdaten D* ermittelt, die repräsentativ sind für einen erwarteten Betriebszustand der entsprechenden Komponenten 2-4.
In einem Schritt d) wird abhängig von den Vergleichsdaten V und den gefilterten Messdaten D* geprüft, ob eine Abweichung des tatsächlichen Betriebszustands von dem erwarteten Betriebszustand vorliegt.
Die Schritte b) bis d) können beispielsweise jeweils zu mehreren aufeinanderfolgenden Zeitpunkten durchgeführt werden. Im Falle, dass zu wenigstens 5 aufeinanderfolgenden Zeitpunkten jeweils eine Abweichung des tatsächlichen Betriebszustands von dem erwarteten Betriebszustand ermittelt wird, wird in einem darauffolgenden Schritt e) der entsprechenden Komponente 2-4 korrespondierend zu den jeweiligen aufeinanderfolgenden Zeitpunkten ein anomaler Betriebszustand zugeordnet, das heißt, lediglich wiederholte Abweichungen werden als anomale Betriebszustände gewertet.
Alternativ hierzu erfolgt in dem Schritt e) bereits bei einer einzigen erfassten Abweichung ein Zuordnen eines anomalen Betriebszustands der jeweiligen Komponente 2-4 korrespondierend zu einem Zeitpunkt der Erhebung der Messdaten D abhängig von der Abweichung.
Schließlich werden in einem Schritt f) durch die Vorrichtung 1 diejenigen Messdaten D, die zu einem ermittelten anomalen Betriebszustand korrespondieren, gespeichert und/oder ausgegeben. Messdaten D, die zu keinem anomalen Betriebszustand korrespondieren, können verworfen werden. Beispielhaft werden die verbliebenen Messdaten D in dem Schritt f) an das Rechenzentrum übermittelt.
Abweichend von dem anhand 1 dargestellten Aufbau bzw. dem anhand 2 geschilderten Verfahren ist es in einer weiteren Ausgestaltung ebenfalls möglich, dass die Kommunikation im Fahrzeug auf mehreren unterschiedlichen Bussystemen erfolgt wie im Folgenden erläutert. Sämtliche im Zusammenhang mit der nachfolgend geschilderten Ausgestaltung offenbarten Merkmale sind für eine Anwendung in dem anhand 1 dargestellten Aufbau bzw. in dem anhand 2 geschilderten Verfahren denkbar. Gemäß der weiteren Ausgestaltung wird jedes einzelne System für den Datenaustausch unterschiedlicher Funktionen und Fahrzeugkomponenten verwendet. Diese verschiedenen Bussysteme können alle vom MDR ausgelesen werden. Dabei interpretiert dieser alle auftretenden Signale und verarbeitet diese weiter. Er kann zum einen unterschiedliche Analyse-Automaten auf den MDR ausführen oder die wichtigsten Informationen gebündelt an das Rechenzentrum übertragen.
Die gesamte Anomalie-Erkennung kann darüber hinaus aus mehreren unterschiedlichen Programmteilen bestehen. Beispielhaft können diese zum einen verschiedene Aufgaben erfüllen und zum anderen können sie auf unterschiedlichen Komponenten ausgeführt werden. Beispielhaft sind die jeweiligen Anwendungen in zwei unterschiedlichen Programmiersprachen aufgeteilt. Gegebenenfalls kann eine bereits vorhandene Anwendung, welche die Daten auf dem MDR weiterverarbeitet, in der Programmiersprache Java entwickelt sein, während der Programmteil, welcher die Anomalie-Erkennung durchführt und die unterschiedlichen Anwendungsmodelle trainiert, mit Python umgesetzt werden kann. Bei Python handelt es sich um die aktuell am weitesten verbreitete Programmiersprache für maschinelles Lernen (ML). Dabei stellt die Sprache unterschiedliche Bibliotheken bereit, welche die Datenvorverarbeitung und die eigentliche Durchführung der Vorhersage unterstützen. Für die Umsetzung einer Deep Learning (DL) Anwendung und/oder Entwicklung des Vorhersagemodells kann etwa das Framework „TensorFlow“ verwendet werden, welches eine Vielzahl von unterstützenden Methoden und bereits vordefinierten Prozessstrukturen abbildet und sich dadurch für die Anwendung besonders eignet.
In 3 wird ein beispielhafter semantischer Aufbau der Kommunikation zwischen den unterschiedlichen Programmteilen dargestellt. Dabei werden auch die drei verschiedenen Anwendungen erkennbar sowie die Aufteilung dieser auf die unterschiedlichen Komponenten. Zum einen ist auf der rechten Seite der 3 die Erstellung eines Anomalie-ErkennungsModells (S1, „Erstellung eines Modells zur AE“) beim Fahrzeughersteller dargestellt. Dieses wird für jeden Anwendungsfall eigenständig erstellt und mit Hilfe der gespeicherten Daten aus der Datenbank DB trainiert (S2, „Trainieren des Modells“) und optimiert (S3, „Optimieren des Modells“). Um die eigentliche Analyse der Daten auf dem MDR durchführen zu können, muss ein Modell erstellt werden, welches die einzelnen Signale analysiert. Um für die unterschiedlichen Arten von Anwendungsfällen das bestmögliche Modell erstellen zu können, werden diese für jeden einzelnen Anwendungsfall speziell entwickelt. Dabei wird das Modell mit den Trainingsdaten für den speziellen Anwendungsfall trainiert. Dieses Training erfolgt dann ebenfalls nochmal mit unterschiedlichen Parameterkonfigurationen. Dabei handelt es sich beispielsweise um sogenannte Hyperparameter, welche bereits vor dem Trainingsstart manuell festgelegt wurden, um das jeweilige Modell zu konfigurieren. Beispielsweise ist ein Klassendiagramm der gesamten Komponenten in drei unterschiedliche Pakete aufgeteilt. Unter dem eigentlichen Quellcodeverzeichnis sind die ausführenden Klassen, die unterschiedliche Arten der Ausführung starten und verwalten. Zudem existiert ein Objekt, welches alle Parameter des Modells definiert und dadurch eine einfache Initialisierung der Modell-Klasse erlaubt, das das eigentliche Modell abbildet. Hier werden alle Vorverarbeitungsschritte durchgeführt, welche für die Daten zur Analyse benötigt werden. Des Weiteren wird das verwendete Modell initialisiert und letztendlich das eigentliche Training des Modells anhand der Daten und der Modellkonfiguration durchgeführt. In einer Klasse werden nacheinander unterschiedliche Modelle mit verschiedener Modellkonfiguration trainiert. Anschließend werden diese erstellten Modelle mit Hilfe der Ergebnisse der einzelnen Modelle verglichen. Dieses Verfahren wird auch als „Grid-Searches“ bezeichnet und liefert letztendlich die Beste Modellkonfiguration für den trainierten Anwendungsfall. Zur Datenverarbeitung und Visualisierung werden abgespeicherte Daten aus der Modell- Klasse heraus aufgerufen und aufbereitet. Für die Anomalie-Erkennung werden die beiden Modelle „Diriclhet“ und „Gaussian“ bereitgestellt, die zwei unterschiedliche Varianten definieren, wie das Modell erstellt werden kann.
Im linken Teil der 3 sind die beiden Anwendungen 1a, 1b dargestellt, welche auf dem MDR ausgeführt werden. Zum einen befindet sich dort in der Python Anwendung 1b die eigentliche on-Board Analyse (S9, „Signale empfangen und mit Modell analysieren“). Diese führt die Anomalie-Erkennung mit Hilfe des trainierten Modells im Auto durch und liefert dabei die Ergebnisse der Anomalie-Erkennung. Zudem existiert noch eine Anwendung, welche die für die Analyse benötigten Signale definiert (S4, „Konfiguration des Anwendungsfalls der Analyse“) und diese an die Java Anwendung 1a auf dem MDR weiterleitet.
Die Anwendung 1b wird im Fahrzeug auf dem MDR ausgeführt und besteht aus zwei unterschiedlichen Komponenten. Eine davon ist für das Übermitteln einer Json Konfigurationsdatei verantwortlich, welche die unterschiedlichen Anwendungsfälle der jeweiligen Modelle definiert. Diese Datei wird an die Java Komponente auf dem MDR übertragen und dort wie im Folgenden beschrieben, weiterverarbeitet. Der Sinn dieser Übertragung liegt darin, dass dadurch die Java Komponente die Anwendung 1a nicht mehr verändert werden muss. Dies hat zum Vorteil, dass nicht bei jeder Änderung der Anwendungsfälle eine neue JAR Datei generiert werden muss, da diese die konfigurierten Signale enthält, sondern die Java Anwendung nach einer einmaligen Initialisierung auf dem System nicht mehr verändert werden muss. Die Python Anwendung 1b muss sowieso um das neu trainierte Modell erweitert werden, sollten sich die zu überwachenden Signale verändern. Aus diesem Grund werden die Informationen in einer Komponente gebündelt und dann von dieser an den eigentlichen Einsatzort, der Java Anwendung 1a, übertragen. Die zweite Softwarekomponente der Anwendung 1b führt die eigentliche on-Board Anomalie-Erkennung auf dem MDR durch. Diese Anwendung wird von der Java Komponente auf dem MDR aus gestartet. Dabei werden beim Start der Anwendung die trainierten Modelle für die Anomalie-Erkennung aus einem konfigurierten Verzeichnis heraus geladen (S8, „Modell auf MDR bereitstellen“). Zusätzlich werden dafür benötigte Diskretisierungsvorschriften übernommen. Für jedes geladene Modell wird ein eigenes Datenobjekt erstellt. In diesem Datenobjekt werden die dafür geladenen Informationen hinterlegt. Eine „Map“ ist vorgesehen, in der die unterschiedlichen Modelle für die jeweiligen Anwendungsfälle gespeichert sind. Als Schlüssel dieser „Map“ dient der eindeutige Anwendungsfallbezeichner oder auch Use-Case Identifier genannt. Dieser spezifiziert, welches Modell für welches Signal verwendet werden soll. Jedes Signal, das von der Java Anwendung übertragen wird, besitzt die Information, für welchen Anwendungsfall dieses Signal benötigt wird. Zudem wird diese eindeutige Bezeichnung dazu verwendet, die gespeicherten Informationen dem richtigen Anwendungsfall zuzuordnen. Sobald ein zu überwachendes Signal im Auto aufgetreten ist und die Konvertierung von der Java Anwendung beendet wurde (S5, „Bussignale des Anwendungsfalls filtern“, S6, „Signale aus Busdaten interpretieren“), werden diese Signale von der Java an die Python Anwendung übertragen (S7, „Signale an Python übertragen“). Dabei wird dann der für das eintreffende Signal benötigte Anwendungsfall geladen und an das Modell zur Anomalie-Erkennung weitergereicht. Es folgt dann die Durchführung der Analyse. Bevor diese Methode (S9) aufgerufen wird, wird das eintreffende Signal noch mit Hilfe der geladenen Informationen des Modells für die Analyse vorbereitet. Die Zeitdauer zwischen dem vorherigen Signal des Anwendungsfalles und des aktuellen wird berechnet und auf einen Wert zwischen null und eins, wie auch während des Trainings des Modells, normiert. Außerdem werden die jeweiligen Signale und deren Werte auf die zum Training verwendeten nummerischen Werte gemappt. Des Weiteren wird der Verlauf der Signale in einem sogenannten Stapel abgespeichert. Dieser Stapel verwaltet die letzten eingetroffenen Signale. Die unterschiedlichen Signaleigenschaften der nacheinander auftretenden Signale werden jeweils dem definierten Stack übergeben. Dabei wird die maximale Anzahl an Attributwerten bereits bei der Initialisierung gesetzt. Ist die maximale Anzahl der Elemente erreicht, so wird das erste Mal eine Prognose für die Anomalie-Erkennung angestoßen, da das Modell diese Informationen über die vorangegangenen Signale benötigt, um eine Aussage über die Plausibilität des nächsten Signals treffen zu können. Außerdem werden, sobald ein weiteres Signal eintrifft, die Attribute des ältesten Signals aus den unterschiedlichen Stack Objekten entfernt und das neu eingetroffene Signal an die erste Stelle gesetzt. Durch dieses Verfahren wird sichergestellt, dass immer nur die letzten x Signale Auswirkung auf die Vorhersage haben. Beispielhaft werden die Daten für einen Zeitraum von fünf Signalattributen gespeichert. Zudem wird durch die Realisierung als Stapel der Verwaltungsaufwand reduziert, da die älteren Objekte beim Hinzufügen von neuen Signalattributen zu den Stack Objekten automatisch entfernt werden. Nach der Durchführung der Analyse wird das Ergebnis für das jeweilige Signal zurückgegeben. Dabei werden neben dem errechneten Anomalie-Score noch weitere Informationen wie das vorhergesagte und das tatsächlich auftretende Signal übermittelt. Diese Informationen werden dann von dort aus an die Java Anwendung übermittelt (S10, „Ergebnisse der AE an Rechenzentrum übertragen“), welche sie automatisch in das BMW-Rechenzentrum überträgt (S11, „Ergebnis an Rechenzentrum übertragen“).
Bei der Anwendung 1a handelt es sich um die Java Entwicklung, welche auf dem MDR läuft und die auf dem MDR auftretenden Bussignale nach den benötigten Signalen filtert (S5, „Bussignale des Anwendungsfalls filtern“) und diese binären Signale dann mit Hilfe der dafür benötigten Konvertierungsvorschriften in reguläre Nachrichten konvertiert, welche den identischen Aufbau wie die Trainingsdaten der Modelle besitzen (S6, „Signale aus Busdaten interpretieren“). Die Java Entwicklung für die Anomalie-Erkennung besteht aus mehreren unterschiedlichen Programmteilen. Es existieren bereits in Java realisierte Anwendungen, welche unterschiedliche Aufgaben auf dem MDR durchführen. Um nun eine neue Anwendung in dieses bestehende Framework einbauen zu können, wird die im Folgenden beschriebene Anwendung aus diesem bereits existierenden Framework heraus gestartet. Es wird die eigentliche Anomalie-Erkennungs-Anwendung gestartet. Dabei werden zudem noch weitere wichtige Informationen für die Anwendung definiert. Definiert werden zum einen die Signalfilter, welche alle Signale auf den MDR nach den für die Anomalie-Erkennung relevanten überprüfen. Die gefilterten Signale werden an die eigentliche Anomalie-Erkennung weitergeleitet (S7, „Signale an Python übertragen“) und zur Analyse verwendet. Außerdem wird der Service gestartet, welcher die Ergebnisse der Anomalie-Erkennung von der Python Anwendung empfängt und diese dann per LTE an das BMW-Rechenzentrum überträgt (S11, „Ergebnisse an Rechenzentrum übertragen“). Ein zentraler Service koordiniert die unterschiedlichen Aufgaben. Zu Beginn der Anwendung wird eine Konfigurationsdatei empfangen, in welcher die unterschiedlichen Signale, die für die AnomalieErkennung von Bedeutung sind, definiert werden. Dabei wird für jedes definierte Signal ein Objekt erstellt. In diesem werden die unterschiedlichen Informationen aus der übertragenen Konfigurationsdatei hinterlegt. Im nächsten Schritt wird dann für jedes Objekt mit Hilfe einer SQL-Lite Datenbank ein weiteres Objekt erstellt. Diese SQL-Lite Datenbank beinhaltet den sogenannten Boardnetzkatalog. In diesem werden alle Informationen über die unterschiedlichen Signale, welche auf den Bussystemen im Auto auftreten können, zentral gespeichert. Mit Hilfe dieser Datenbank werden aus den einzelnen Nachrichten die darin erhaltenen Signale konvertiert. Nachdem für jedes Objekt ein weiteres Objekt erzeugt worden ist, können die unterschiedlichen Nachrichten nun mit Hilfe der gespeicherten Informationen aus der konvertiert werden. Dabei entstehen nun die identischen Signale, welche auch für das Training der Modelle zur Verfügung stehen. Trifft nun eine Bus-Nachricht auf dem MDR ein, so wird diese mit Hilfe der für diese Nachricht hinterlegten Konvertierungsvorschriften interpretiert und ein weiteres Objekt erstellt. Dieses beinhaltet dann alle spezifischen Informationen, die für die nachfolgende Analyse des Signals benötigt werden. Das neu generierte Objekt wird dann mit Hilfe von Socket Kommunikation an die Python Anwendung zur Anomalie-Erkennung übertragen (S7). Nachdem die Anomalie-Erkennung die unterschiedlichen Signale analysiert hat (S9), wird das Ergebnis der einzelnen Analysen zurück an die Java Anwendung mit Hilfe von Socket Kommunikation übermittelt (S10). Der Hauptgrund, warum diese Kommunikation wieder über die Java Anwendung und nicht direkt aus dem Python Programm durchgeführt wird, wird dadurch begründet, dass die Kommunikation zwischen dem MDR und dem Rechenzentrum bereits auf der Java Anwendung realisiert ist. Sie müsste dann nochmals neu für die Python Anwendung speziell entwickelt werden, was durch dieses Vorgehen vermieden werden kann. Dabei wird der Service zum Empfangen der Ergebnisse direkt aus der Python Anwendung heraus aufgerufen. Um die Qualität eines DL Modells gewährleisten zu können, ist neben dem eigentlichen Modell die Qualität der für das Training zur Verfügung stehenden Daten von großer Bedeutung. Aus diesem Grund ist es enorm wichtig, ausreichend viele und möglichst unterschiedliche Trainingsdaten für das Training des Modells zur Verfügung stellen zu können. Um dies gewährleisten zu können, kann mittels einer Anwendung aus zur Verfügung stehenden Datenaufzeichnungen, welche aus reellen Testfahrten einer Vielzahl an Kraftfahrzeugen generiert wurden und zur späteren Analyse in das Rechenzentrum übertragen worden sind, eine unbegrenzte Anzahl von Trainingsdaten erzeugt werden. Die gespeicherten Aufzeichnungen über durchgeführte Testfahrten beinhalten alle Nachrichten, welche auf den unterschiedlichen Bussystemen im Auto während der Fahrt stattgefunden haben, in nicht interpretierter Form. Diese Aufzeichnungen werden geladen und mit Hilfe der Informationen aus dem Boardnetzkatalog in die einzelnen Signale konvertiert. Aus allen sich im Rechenzentrum befindenden und gespeicherten Testfahren können so Trainingsdaten für die verschiedenen Anomalie-Erkennungsmodelle erzeugt werden. Dadurch ist zum einen gewährleistet, dass immer genügend Trainingsdaten zur Verfügung stehen und zum anderen, dass diese aus unterschiedlichen Trainingsfahrten zusammengestellt werden können.
Die Grundlage für ein erfolgreiches DL Verfahren bilden in erste Linie die Daten. Die Qualität dieser ist entscheidend für den Erfolg und die Genauigkeit des entstehenden Modells. Dies ist auch der Grund, weshalb die verwendeten Daten vor der eigentlichen Verwendung bereinigt werden sollten. Bevor die Daten für die Anomalie Erkennung verwendet werden können, sollten diese deshalb aufbereitet werden. Dies dient zum einen dazu, um die eigentliche Verarbeitung der Daten zu Performanz, sowie eines korrekten Ergebnisses sicherzustellen. Dabei werden mit den zur Verfügung stehenden Daten unterschiedliche Aktionen zur Aufbereitung durchgeführt:

• Auswahl der zu verwendenden Merkmale
• Umgang mit fehlenden Werten
• Verknüpfung von Merkmalen
• Merkmale skalieren
• Daten normalisieren
• Entfernen von irreführenden Daten.

Im Nachfolgenden werden die einzelnen Schritte zu Aufbereitung der Daten genauer beschrieben und erklärt. Dabei beziehen sich diese Verfahren und deren Umsetzungsmöglichkeiten immer speziell auf den Anwendungsfall der Anomalie Erkennung von Fahrzeugdaten. Die Auswahl der für die Analyse benötigten Merkmale (sog. „Features“) ist entscheidend für das gesamte Modell. Jedoch sind diese auch stark von dem zu analysierenden Anwendungsfall abhängig. Als Features können in diesem Fall von Anomalie-Erkennung die zu beobachtenden Signale definiert werden. Dabei unterscheiden diese sich nochmal anhand ihrer Signalwerte. Die eindeutige Kombination aus Signal und Signalwert wird als Feature definiert. Zudem ist das gesamte Modell von der Zeit abhängig. Aus diesem Grund ist die Zeitspanne zwischen den nacheinander auftretenden Signalen ebenfalls als ein Feature zu betrachten.
Bei den zu analysierenden Daten handelt es sich um interne Boardnetzkommunikation im Fahrzeug. Dabei werden alle Informationen über den aktuellen Status des Fahrzeuges und der aktuellen Situation, in welcher sich dieses befindet, protokolliert. Zudem werden alle Aktionen, die vom Nutzer des Fahrzeuges angestoßen werden aufgezeichnet. Da diese Informationen erheblichen Einfluss auf das Fahrzeug und den Fahrer haben, kann mit hoher Wahrscheinlichkeit gewährleistet werden, dass diese Informationen vollständig und ohne Datenverlust existieren. Zudem können diese Signale auch sicherheitsrelevante Informationen beinhalten, was wiederum die Relevanz dieser Daten und deren Konsistenz garantiert. Diese Daten werden zur Laufzeit im Auto aufgezeichnet und nach der Durchführung der Testfahrt an den dafür vorgesehenen Auslesestellen ausgelesen und auf ihre Konsistenz und Korrektheit hin überprüft. Anschließend werden diese überprüften Daten dann in eine Datenbank importiert und stehen nun zur Analyse bereit. Durch das gesamte Vorgehen kann gewährleistet werden, dass die für das Training des Modells bereitgestellten Daten vollständig und korrekt sind. Aus diesem Grund kann beim Trainieren des Modells auf die Bereinigung von Ausreißern verzichtet werden. Dasselbe gilt auch bei der eigentlichen Analyse der Daten auf dem MDR, da diese auch auf dieselbe Informationsquelle wie die gespeicherten Daten zurückgreifen. Diese werden sogar direkt von den Bussystemen des Fahrzeuges abgegriffen ohne eine Zwischenspeicherung der Daten auf den Datenspeichern des Rechenzentrums. Des Weiteren überprüft der MDR die eintreffenden Signale auf Konsistenz und Korrektheit, bevor er diese zur Weiterverarbeitung freigibt. Dies ist auch der Grund, weswegen auf die Eliminierung von fehlenden Werten in diesem Fall der Anomalie-Erkennung von Fahrzeugdaten verzichtet werden kann.
Das Normalisieren von Daten ist bei jedem Verfahren von DL notwendig. Werden die Daten nicht normalisiert, so werden Attribute mit einem höherem Definitionsbereich weitaus stärker bewertetet, als Features mit einem kleinen Definitionsbereich. Dies hat dann zur Folge, dass diese Merkmale einen größeren Einfluss auf das Ergebnis des Modells haben, als kleinere. Diese Entscheidungen dürfen nicht von den Daten getroffen werden, sondern durch die Auswertung der Ergebnisse der einzelnen Modelle selbst eruiert werden.
Unter der Normalisierung von Daten versteht man, dass die gesamten Daten in einen gemeinsamen Datenbereich abgebildet werden. Dabei werden die einzelnen Werte z.B.: jeweils auf einen Wert in den Wertebereich von 0 bis 1 normiert. Die Normalisierung der Datenwerte kann ganz einfach durchgeführt werden, indem für jedes einzelne Feature die Differenz zwischen dem maximalen und dem minimalen Wert berechnet wird. Anschließend wird dieser minimale Wert von jedem eigentlichen Wert angezogen und durch die Differenz aus maximalem und minimalem Wert geteilt. Damit wird der maximale Wert auf den Wert 1 abgebildet und der minimale Wert auf 0. Alle dazwischenliegenden Datenwerte werden nun in Abhängigkeit von ihrem eigenen Wert auf einen neuen Wert zwischen 0 und 1 abgebildet. Da bei der Analyse der Signale die Zeit zwischen den nacheinander auftretenden Signalen entscheidend ist, wird dieses Verfahren zur Normalisierung dieser Zeitbereiche eingesetzt. Dabei wird nicht der eigentliche Zeitstempel des Signales normalisiert, sondern die Zeitdifferenz zwischen den aufeinander folgenden Signalen, die sogenannte Δ-Zeit zwischen einem Signal zum Zeitpunkt n und einem Signal zum Zeitpunkt n + 1.
Mit Hilfe von Feature Diskretisierung werden unterschiedliche Merkmale und deren Werte auf kleinere Wertebereich abgebildet. Dadurch werden benachbarte Merkmalwerte zu einer gemeinsamen Kategorie des jeweiligen Merkmals zusammengefasst. Das Hauptziel dieser Funktion besteht darin, die Anzahl der kontinuierlichen Attribute zu verringern. Erstreckt sich beispielsweise ein Wertebereich eines numerischen Merkmals von 0 bis 100, so kann dieser in eine beliebige Anzahl von Kategorien aufgeteilt werden. In diesem Beispiel könnte der Wertebereich in zehn gleichgroße Unterkategorien aufgeteilt werden. Dabei würde nun ein Merkmalswert mit dem realen Wert 13 in dieselbe Kategorie wie einer mit Merkmalswert 19 eingeordnet werden. Mit Hilfe dieses Verfahrens verlieren die Datensätze insgesamt an Genauigkeit. Ziel muss es sein, die jeweiligen Bereiche so aufzuteilen, dass die sich darin befindenden Werte alle gleich interpretiert werden können, dass bedeutet, dass sie als ein Wert verwaltet werden können. Dieser Genauigkeitsverlust muss nicht zwangsläufig negative Auswirkungen haben, sondern kann sich durchaus auch positiv auf die jeweilige Analyse auswirken. Einerseits wird die Genauigkeit des Vorhersagemodells durch die Vereinfachung der Daten besser. Das Modell muss nun keinen genauen Wert mehr vorhersagen, sondern nur noch einen Bereich, in dem sich der vorhergesagte Wert befinden wird. Zum anderen kann die Minimierung der Wertebereiche für jedes einzelne Feature auch die Dauer des Lernvorgangs und der eigentlichen Analyse verkürzen, sowie das gesamte Modell vereinfachen. Ziel dieses Verfahrens ist es, eine minimale Anzahl von Merkmalsbereichen zu definieren, welche die vorhandenen Daten noch akkurat beschreiben und dadurch keinerlei wichtige Informationen verloren gehen. Es muss beachtet werden, je mehr unterschiedliche Signale existieren, desto komplexer ist die Vorhersage des nächsten Signals. Ist es sinnvoll, die Geschwindigkeit eines Fahrzeuges auf eine Nachkommastelle genau vorhersagen zu können oder ist dies nicht so detailliert notwendig. Im Fall der Anomalie-Erkennung ist eine solche genaue Vorhersage nicht sinnvoll und führt eher zu einer Verschlechterung des Ergebnisses, da die Anomalie-Erkennung dann öfter falsche Vorhersagen trifft. Aus diesem Grund wird die Anzahl der unterschiedlichen Signale verringert. Dabei wird jedes Signal mit einem unterschiedlichen Signalwert als eigenes Signal betrachtet. Dies wird mit Hilfe der Diskretisierungsverfahren umgesetzt.
Um die eventbasierten Fahrzeugdaten für das beschriebene Anomalie-Erkennungsmodell verwenden zu können, sollten die Daten noch für die Analyse angepasst werden. Die Buskommunikation im Fahrzeug erfolgt über Nachrichten. Diese einzelnen Nachrichten sind immer gleich aufgebaut und beinhalten immer die gleichen Signale mit den aktuellen Signalwerten. Diese Signale der einzelnen Nachrichten werden dann mit Hilfe des Anomalie-Erkennungsmodells analysiert. Daraus folgt, dass alle Signale einer Nachricht zu einem gemeinsamen Zeitpunkt auftreten. Werden nun mehr als ein Signal aus der Nachricht für die Analyse des Anwendungsfalls benötigt, so besitzen diese Signale den identischen Zeitstempel und können aus diesem Grund nicht ihn der zeitlichen Reihenfolge analysiert werden, da die Δ-Zeit für die beiden Signale null ist.
Für das zur Analyse verwendete Modell ist es jedoch Voraussetzung, dass diese Δ-Zeit niemals null sein darf, da dadurch die Signale nicht mehr in Abhängigkeit von der Zeit dargestellt werden können. Aus diesem Grund können bei der Analyse von Signalen einer Nachricht die Signale immer abgewechselt und dadurch nur ein Signal der Nachricht analysiert werden. Beispielsweise besteht eine Nachricht aus vier unterschiedlichen Signalen. Von diesen vier Signalen werden vier Signale für die Analyse eines Anwendungsfalls benötigt, so wird beim ersten Eintreffen der Nachricht das Signal eins analysiert. Sobald die Nachricht ein weiteres Mal eintrifft, wir nur das Signal zwei analysiert. Beim dritten Eintreffen wir dann wieder das Signal eins analysiert. Mit Hilfe dieses Mechanismus ist es möglich ohne einen großen Genauigkeitsverlust mehrere Signale einer Nachricht zu analysieren.
Anomalien oder Ausreißer sind die zwei häufigsten Bezeichnungen, die im Zusammenhang mit der Erkennung von Anomalien verwendet werden. Die Bedeutung der Anomalieerkennung liegt darin begründet, dass Anomalien in jeder Form der Datenkommunikation auftreten können. Dabei kann es sich um extrem wichtige Informationen handeln, die durch die Anomalien nicht mehr korrekt ausgewertet werden können. So könnte beispielsweise ein anomales Netzwerkkommunikationsmuster in einem Computernetzwerk bedeuten, dass ein gehackter Computer sensible Daten selbst an ein nicht autorisiertes Ziel übermittelt. Auffälligkeiten in den Transaktionsdaten von Kreditkarten können auf Kreditkarten- oder Identitätsdiebstahl hinweisen oder anormale Messwerte von einem Sensor eines Fahrzeuges können einen Fehler in der Komponente des Fahrzeuges bedeuten. Die Erkennung von Ausreißern oder Anomalien in Datensätzen wurde im Bereich der Statistik bereits im 19. Jahrhundert untersucht. Seit dieser Zeit wurden mit Hilfe unterschiedlicher Forschungsgemeinschaften verschiedenen Techniken zur Erkennung von Anomalien entwickelt. Viele dieser unterschiedlichen Verfahren wurden speziell für einen bestimmten Anwendungsbereich entwickelt und optimiert. Erst im Laufe der Zeit wurden immer mehr generische Methoden zur Ausreißererkennung entwickelt. Diese Entwicklung wurde durch die Weiterentwicklung von neuen Möglichkeiten in Bezug auf ML und künstliche Intelligenz (KI) nochmals erheblich vorangetrieben.
Die Ausgangsidee der Anomalie-Erkennung bildet das korrekte Vorhersagen des nächsten Signals im Fahrzeug. Dabei werden unterschiedliche Anwendungsfälle definiert, welche die zu überwachenden Signale beschreiben. Wird in einem Anwendungsfall zum Beispiel definiert, dass das Geschwindigkeitssignal überwacht werden soll, so wird sobald ein Geschwindigkeitssignal auf dem MDR von den Bussystemen abgegriffen wird, versucht dieses Signal mit dem aktuellen Wert vorherzusagen. Stimmen dann das vorhergesagte Signal mit dem tatsächlich anliegenden Signal überein, so wird das Verhalten des Fahrzeuges als normal eingestuft. Das bedeutet, dass das Signal und dessen Signalwert vom Modell korrekt vorhergesagt wurden und sich dadurch das Fahrzeug in einem vom Modell prognostizierten Zustand befindet, welcher als normaler Zustand anhand der Trainingsdaten des Modells erlernt wurde. Wird jedoch ein anders Signal vorhergesagt, so ist dies ein erstes Anzeichen für ein Verhalten, welches das Modell nicht kennt und deshalb als anormal einstuft. Natürlich resultiert nicht aus jedem falsch vorhergesagtem Signal ein anomales Verhalten. Jedoch sind bei einem vermehrten Vorkommen von falschen Prognosen die analysierten Signale nicht mehr als normal zu betrachten. Aus diesem Grund sollte der gesamte Fahrzeugstatus, zu diesem bestimmten Zeitpunkt, genauer betrachtet werden. Das Ergebnis des Modells liefert demnach eine sehr gute Einschätzung zur aktuellen Situation des Fahrzeuges. Tritt vermehrt ein anders Signal ein, als das vom Modell prognostizierte, so bedarf es einer genaueren Betrachtung des Fahrzeugstatus zu diesem bestimmten Zeitpunkt. Die Hauptkomponente des für das Modell zugrundeliegenden Ansatzes bildet ein Rekurrentes neuronales Netz (RNN). Dabei wird dieses RNN mit der Hilfe von „Long Short-Term Memory“ (LSTM) erweitert das bei diesem Modell als Speicher der bereits aufgetretenen Signale dient. Diese bereits vergangenen Signale, sowie die Zeit zwischen den einzelnen Signalen, sind für die Vorhersagewahrscheinlichkeit des nächsten Signals von aller größter Bedeutung. Aus diesem Grund wurde das RNN um die Komponenten eines LSTM erweitert. Da das Auftreten der zu analysierenden Signale in sehr geringen Zeitabständen erfolgt und zudem die Vorhersage während der Fahrt im Fahrzeug auf limitierter Hardware durchgeführt wird, wird die „Gated Recurrent Unit“ (GRU) Variante, ein vereinfachte Form einer LSTM verwendet, da diese ähnlich gute Ergebnisse bei einer geringeren Leistungsaufnahme benötigt. Als weitere Komponente des Modells wird das Dirichlet Modell (Dir-M) dazu verwendet, das Ergebnis des RNN zu verarbeiten. Das Ergebnis des RNN bildet eine Wahrscheinlichkeitsverteilung der einzelnen Signale über die Zeit. Dir-M wird dazu verwendet, das Ergebnis des RNN auf die zu analysierenden Signale anzuwenden. Daraus resultiert dann eine Wahrscheinlichkeitsverteilung zum aktuellen Zeitpunkt des zu analysierenden Signales mit der Wahrscheinlichkeit für das Auftreten jedes einzelnen Signals. Aus dieser Menge an Informationen wird dann letztendlich das Signal mit der höchsten Wahrscheinlichkeit zu diesem Zeitpunkt vom Modell als vorhergesagtes Signal ausgegeben.
Damit das Modell zur Anomalie-Erkennung im Fahrzeug eingesetzt werden kann, müssen neben den beiden beschriebenen Anwendungen 1a, 1b auch andere Komponenten auf dem MDR bereitgestellt werden. Eine dieser Komponenten ist Tensorflow. Tensorflow ist ein Python spezifisches Framework, welches unterschiedliche Bibliotheken und Komponenten für die Entwicklung von DL Anwendungen von ML bekannt und stellte eine große Bandbreite an unterschiedlichen Komponenten zur Verfügung. Aus diesem Grund wurde auch bei der Umsetzung des Anomalie-Erkennungsmodells dieses Framework verwendet. Um das für die jeweiligen Anwendungsfälle trainierte Modell auch auf dem MDR ausführen zu können, wird dieses Framework auch im Fahrzeug benötigt. Dabei ist zu beachten, dass das eigentliche Trainieren des Vorhersagemodells nicht auf dem Zielgerät, auf welchen die Anwendung später im Fahrzeug ausgeführt wird durchgeführt wird, sondern das Training der Anwendung extra auf einem dafür bereitgestellten Rechner durchgeführt wird. Da das Trainieren der Modelle auch mit einem erheblichen Aufwand und einer erhöhten Rechenkapazität verbunden ist, wird dieses Training auch nicht auf der Central processing unit (CPU) ausgeführt. Diese Berechnungen werden aus performancetechnischen Gründen auf den dafür bereitgestellten GPU's der Workstation durchgeführt, da diese bei dieser Art von Berechnungen leistungsstärker und schneller agieren können.
Auf dem im Fahrzeug verbauten MDR wird die Anomalie-Erkennung durchgeführt. Die dort anliegende Verkabelung stellt die Verbindung zu den unterschiedlichen Bussystemen im Auto da. Durch diese Verbindungen werden die Nachrichten der einzelnen Bussysteme an den MDR übermittelt und weiterverarbeitet. Zudem wird der MDR über das Boardnetz im Fahrzeug mit Strom versorgt. Darüber hinaus umfasst der MDR Antennenanschlüsse, welche für unterschiedliche Komponenten im Fahrzeug benötigt werden. Dadurch können die Funkverbindungen im Fahrzeug mit Hilfe der Antennen an einen besseren Ort postiert werden, wodurch der Empfang, sowie die Sendeleistung der Daten besser durchgeführt werden kann. Dabei sind Anschlüsse für ein GPS Modul, zwei LTE Komponenten, eine WLAN und eine BTLE Verbindung vorgesehen.
Aktuell werden im Fahrzeug automatisch Diagnosesignale versendet. Diese werden durch verschiedenen Systeme im Fahrzeug automatisch erstellt. Sie dienen hauptsächlich zur Protokollierung und zur Überprüfung der Funktionalität. Dabei handelt es sich bei diesen Informationen um keine Sicherheitskritischen. Sie sind bei der Diagnose von Fehlern oder undefinierten Fahrzeugsituationen wichtig und liefern kontinuierlich wichtige Statusmeldungen zum Zustand der Fahrzeugkomponenten während der Fahrt. Diese sind für eine reibungslose Fahrt aber unwichtig und werden nur bei der anschließenden Auswertung verwendet.
Mit Hilfe dieses Anwendungsfalls wird das Auftreten von Diagnosesignalen überwacht. Werden vermehrt Diagnosesignale gesendet, so hat dies einen negativen Einfluss auf die gesamte Buskommunikation im Fahrzeug, da diese keine fahrzeugkritischen Informationen beinhalten und nur bei der Auswertung der Anwendungen verwendet werden. Dadurch wird das Bussystem im Auto mit unnötigen Daten belastet. Es ist bereits vorgekommen, dass eine erhöhte Buslast im Fahrzeug während der Fahrt zu einen kompletter Zusammenbruch der Fahrzeugkommunikation geführt hat. Dadurch konnte das Fahrzeug dann nicht mehr fortbewegt werden und musste abgeschleppt werden. Dieser Vorfall wurde anhand einer fehlerhaften Softwareversion auf einem Steuergerät verursacht, welches für das Versenden der Diagnosesignale verantwortlich war. Beim Testen der Software ist dieses fehlerhafte Verhalten der Diagnosesignale nicht aufgefallen, da kein Vergleich zu einer früheren Version, oder zu normalen Diagnosesignalverhalten durchgeführt wurde. Dies hat zum einen den Grund, dass das Testen von Diagnosesignalen selten durchgeführt wird, da dieses keine Sicherheitskritischen Informationen beinhalten und eigentlich nur zu Analysezwecken eingesetzt werden. Zudem ist das Einschätzen von normalem und anormalem Diagnoseverhalten extrem schwierig. Zudem kann durch das Zusammenspiel unterschiedlicher Komponenten das Diagnoseverhalten beeinflusst werden. Diese Zusammenspiel der verwendeten Komponenten und deren unterschiedlicher Softwareversionen kann meist erst in den Testfahrzeugen in Kombination getestet werden. Um diesen Vorgang automatisiert durchführen zu können, wird mit Hilfe der Anomalie-Erkennungsanwendung das Verhalten von Diagnosesignalen erlernt. Mit Hilfe dieses erlernten Modells wird dann das Diagnoseverhalten im Fahrzeug validiert und auf unerwartetes, sowie vermehrtes Diagnoseverhalten hin überprüft. Das Ziel dieses Anwendungsfalls ist also die Überwachung der Diagnosesignale. Dass diese zum einen in einer normalen Anzahl vorkommen und zum anderen, dass diese in einer bekannter und erlernten Reihenfolge auftreten.
Bei der Erstellung eines neuen Anwendungsfalls müssen mehrere Aktionen durchgeführt werden, bevor das erstellte Modell die Daten im Fahrzeug analysieren kann. Es sind insgesamt fünf unterschiedliche Schritte durchzuführen:

Bevor mit der eigentlichen Analyse der Signale begonnen werden kann, müssen zuerst einmal die Signale definiert werden, welche bei diesem Anwendungsfall überwacht werden sollen. Dabei werden diese mit Hilfe der BusId, FrameId und
dem SignalName eindeutig definiert. Die Konfiguration dieser Signale wird in einer Datei hinterlegt. Beim Starten der Anwendung wird diese Konfigurationsdatei an die Java Anwendung im MDR übertragen und die benötigten Signale für die Anomalie-Erkennung definiert. Dabei ist die Konfiguration aus FrameId, BusId und SignalName für jedes Signal eindeutig.
Die Konfiguration wird auch beim Filtern der Bussignale verwendet. Dabei wird sichergestellt, dass nur die definierten Bussignale vom MDR an die Anomalie-Erkennungsanwendung interpretiert und weitergeleitet werden.
Zudem wird für jeden neuen Anwendungsfall ein eigener Schlüssel definiert. Anhand dieses Schlüssels können in den nachfolgenden Schritten die zu analysierenden Signale den jeweiligen Anwendungsfällen zugeordnet werden. Dabei muss dieser Schlüssel dem Anwendungsfall eindeutig zugeordnet sein.

Im nächsten Schritt werden Trainingsdaten für das zu erstellende Modell erstellt. Dabei werden die gespeicherten binären Daten von Fahrzeugfahrtaufzeichnungen aus einer Datenbank exportiert und anschließend mit Hilfe der Konvertierungsvorschriften in Nachrichten und Signale konvertiert. Dabei wird im Wesentlichen der identische Prozess ausgeführt, welcher auch bei der Umwandlung der binären Bussignale auf dem MDR durch die oben beschriebene Anwendung 1a durchgeführt wird. Dabei werden auch wieder nur die Signale konvertiert, welche für den Anwendungsfall von Bedeutung sind. Alle anderen Signale werden bei der Erstellung der Trainingsdaten nicht berücksichtigt und werden aus diesem Grund auch nicht konvertiert. Mit Hilfe der exportierten Daten aus der Datenbank, sowie der gespeicherten Konvertierungsvorschriften und der definierten Signale wird für die exportierten Daten eine neue Datei erstellt. Diese Datei beinhaltet alle Signale, welche für das Training der Daten notwendig sind. Um für das Training Daten mit möglichst allen Fahrzeugsituationen bereitstellen zu können, werden die Trainingsdaten für das Modell aus mehreren einzelnen Testfahrten unterschiedlicher Fahrzeuge erstellt. Dabei werden jeweils unterschiedliche Bereiche der Testfahrt ausgewählt und in eine Datei zusammengefasst. Diese Datei mit Trainingsdaten bildet dann nicht nur ein Fahrzeug mit einer Testfahrt ab, sondern bildet einen Durchschnitt von mehreren Testfahrten aus unterschiedlichen Fahrzeugen. Dadurch wird das Verhalten nicht nur anhand eines Fahrzeuges und einer Testfahrt erlernt, sondern durch eine Vielzahl von unterschiedlichen Fahrten und Fahrzeugen.
Nachdem der zu analysierende Anwendungsfall definiert und ausreichend Trainingsdaten erzeugt wurden, wird anhand des Basismodells das Modell speziell für den konfigurierten Anwendungsfall entwickelt. Dabei wird das Basismodell mit Hilfe der erstellen Trainingsdaten für unterschiedliche Modellkonfigurationen trainiert. Das Training des Modells erfolgt in unterschiedlichen Epochen. Nach jeder Epoche, in denen die internen Gewichte des RNN angepasst wurden, wird das Modell mit ihm unbekannten Daten, den sogenannten Validierungsdaten, evaluiert. Nach einer definierten Anzahl von maximalen Epochen wird das Training des Modells abgebrochen. Dies wird für unterschiedliche Modellkonfigurationen nacheinander durchgeführt. Dabei werden zuerst die unterschiedlichen Parameter und deren mögliche Belegung definiert. Anschließend wird dann die eigentliche Suche der Hyperparameter gestartet. Dabei wird für jeden Parameter eine for-Schleife definiert, in welche die einzelnen Belegungen des Parameters durchlaufen werden. Es wird dann für jede Kombination von Belegungen eine Parameter Liste erstellt. Diese enthält alle Parameter des Modells und wird dann diesem zur Ausführung übergeben. Das Modell wird nun mit dieser Konfiguration ausgeführt und liefert Werte über das Ergebnis des Modells zurück. Diese Ergebnisse werden dann zusammen mit der verwendeten Modellkonfiguration in einer Datei abgespeichert. Diese Datei wird für jede Parameterbelegung, mit welcher das Modell trainiert wurde um einen Datenzeile erweitert.
Neben den Ergebnissen wird auch das erstellte Modell mit den einzelnen Gewichtungen zwischen den verwendeten Knoten sowie zusätzliche Informationen über das Modell und Visualisierungen abgelegt. Diese Daten können danach zusätzlich analysiert werden. Am Ende der Hyperparameter Suche sind alle Ergebnisse mit den jeweiligen Konfigurationen hinterlegt in einer Datei. Anschließend kann dann diese Datei analysiert werden. Dabei wird sie anhand der Ergebnisse des Modells sortiert. Das Modell mit dem besten Ergebnis, sowie die dazu gehörige Modellkonfiguration werden ausgewählt. In den zusätzlich für das Modell gespeicherten Daten wird anschließend das erlernte Modell mit den erlernten Gewichtungen zwischen den einzelnen Knoten an den MDR portiert und für den Anwendungsfall als zu verwendendes Modell hinterlegt.
Nachdem mit Hilfe der Hyperparameter Suche die beste Modellkonfiguration für den Anwendungsfall gefunden worden ist, wird nun das erstellte Modell auf den MDR portiert. Dabei werden neben dem eigentlichen Modell auch weitere Informationen, welche beim Training des Modells definiert wurden portiert. Wurden verschiedene Signale und deren Werte während des Trainings diskretisiert, so müssen diese Signale auch bei der Analyse auf dem MDR in die während des Trainings verwendeten Werte übertragen werden. Diese Diskretisierungsvorschriften werden genauso wie das erlernte Modell in einem Ordner mit dem eindeutigen Anwendungsfallbezeichner abgelegt. Jedes eintreffende Signal ist durch seine Konfiguration mindestens einem Anwendungsfall zugeordnet. Dabei wird das Modell mit dem Anwendungsfall definiert und ein neues Model Objekt erzeugt. Dann wird anhand der bereitgestellten Informationen das trainierte Modell für den Anwendungsfall geladen. Zusätzlich zu dem Modell werden noch die Diskretisierungsvorschriften, sowie weitere wichtige Informationen für die Verarbeitung der Signale bei der Modell Analyse geladen. Anhand dieser geladenen Informationen werden außerdem noch wichtige Parameter für das Modell definiert, welche die geladenen Informationen benötigen. Es werden zum Beispiel die Stapel für die bereits beschriebenen Übergabeparameter für das Modell mit der maximalen länge definiert. Diese Länge definiert die maximale Anzahl an Signalen, welche das Modell für die Vorhersage des nächsten Signals verwendet. Zudem werden die maximale, sowie die minimale Zeit zwischen zwei aufeinander folgenden Signalen geladen. Überdies werden die beiden Werte zum Normalisieren der Zeitdifferenz zwischen den auftretenden Signalen benötigt. Dadurch wird gewährleistet, dass die Normierung der Zeitdifferenz während der Analyse auf dem MDR auf die identischen Werte wie beim Training der Modelle durchgeführt wird. Wird nun ein Signal vom MDR an die Anwendung weitergeleitet wird mit Hilfe des mit übergebenen Parameters, welcher den Anwendungsfall definiert, das für das Signal benötigte Modell geladen und das zu analysierende Signal an das Modell zur Weiterverarbeitung weitergereicht. Dort wird dann je Ausgangslage entschieden, ob schon die minimale Anzahl an benötigten Signalen erreicht ist und ob eine Vorhersage für den Zeitraum des neu eingetroffenen Signals durchgeführt werden kann. Ist die minimale Anzahl an Signalen für eine Vorhersage noch nicht erreicht, so wird das eintreffende Signal mit der normierten Zeitdifferenz zum vorherigen Signal nur den Stapeln hinzugefügt und die Vorhersage nicht aufgerufen. Bei der Methode, welche zur Vorhersage des Modells verwendet wird, werden zuerst Tensor Objekte des Modells geladen und anschließend mit Hilfe des aktuellen Stapels befüllt. Diese nun gefüllten Tensor Objekte werden dem Vorhersagemodell übergeben. Als Ergebnis des Modells werden anschließend das vom Modell vorhergesagte Signal, sowie die Wahrscheinlichkeiten für jedes einzelne Signal zurückgegeben. Diese werden anschließend für die Einordnung des Ergebnisses benötigt. Nachdem die Vorhersage erstellt wurde wird anhand eines sogenannten Anomalie-Scores das Ergebnis des Modells evaluiert.
Der Anomalie-Score sagt aus, wie normal, bzw. anormal das aktuelle Verhalten des Fahrzeuges ist. Dabei hat jedes Signal, welches das Modell analysiert, eine Auswirkung auf den Anomalie-Score. Hierbei sind zwei unterschiedliche Varianten von Anomalie-Scores denkbar.
Die einfachste Variante, um eine Aussage über den aktuellen Zustand des Fahrzeuges treffen zu können, ist das einfache Aufsummieren der falsch vorhergesagten Signale. Dabei werden die falsch vorhergesagten Signale über eine bestimmte Anzahl von Signalen aufsummiert. Zum Beispiel werden bei den letzten 100 Signalen genau 25 dieser falsch vorhergesagt, dann besitzt der aktuelle Anomalie-Score dieses Modells den Wert 25. Dieselbe Variante existiert ebenfalls noch mit einer Gewichtung der Zeitkomponente. Dabei werden Signale, welche schon länger zurückliegen weniger schwer gewichtet, als Signale, welche gerade erst falsch vorhergesagt worden sind. Es werden zum Beispiel wieder die letzten 100 Signale für die Berechnung des Anomalie-Scores verwendet. Dabei werden diese nach ihrem zeitlichen Verlauf gewichtet. Wird zum Beispiel das aktuelle Signal falsch vorhergesagt, so wird dies mit der Gewichtung von eins für den Anomalie-Score mitberücksichtigt. Werden nun jedoch 10 Signale richtig vorhergesagt, dann verändert sich die Gewichtung dieses falsch vorhergesagten Elements ständig. Es verliert dabei an Aussagekraft und nach 10 richtig vorhergesagten Signalen hat es nur noch die Gewichtung von 90/100 für den aktuellen Anomalie-Score. Dadurch wird versucht, die aktuelle Situation des Fahrzeuges besser zu repräsentieren. Dabei wird vermieden, dass eine Fahrzeugsituation, in der das Modell die letzten 50 Signale korrekt vorhergesagt hat, jedoch vor diesen 50 Signalen 20 falsche Vorhersagen getroffen hat genau so bewertet wird, wie als vom Modell die letzten 20 Signale nacheinander falsch vorhergesagt wurden. Ohne Gewichtung der Zeit wären diese beiden doch sehr unterschiedlichen Situationen im Fahrzeug durch einen identischen Anomalie-Score definiert. Um dies zu vermeiden wurde die zeitliche Gewichtung der Anomalien hinzugefügt.
Zudem werden neben den Anomalie-Scores noch weitere Informationen an das Rechenzentrum übermittelt. Diese zusätzlichen Informationen dienen zur weiteren genauen Analyse. Dabei kann man abschätzen, wie falsch die Vorhersage des Modells war. Wird nun ein anderes Signal vorhergesagt als das anliegende Signal, so ist dies nicht immer gleichbedeutend mit einer Anomalie. Dabei müssen die vorangegangenen Signale ebenso betrachtet werden. Ist über einen längeren Zeitraum die Vorhersage des Modells nicht korrekt, so ist die Wahrscheinlichkeit für an anormales Verhalten, bzw. für einen anormale Fahrzeugsituation gegeben. Bei dieser Situation werden die berechneten Anomalie-Scores auch einen erhöhten Wert annehmen. Um die berechneten Anomalie-Scores automatisch überwachen zu können, kann für jeden Anwendungsfall und für jeden Anomalie-Score ein eigener Grenzwert definiert werden. Dadurch wird dann definiert, ab welchem Wert des Anomalie-Scores das Verhalten des Fahrzeuges als anormal eingestuft wird und wann diese noch ein normales Verhalten darstellt. Nachdem alle oben genannten Punkte bearbeitet wurden, kann der Anwendungsfall nun erfolgreich auf dem MDR ausgeführt werden. Dabei werden die definierten Signale überwacht. Tritt nun ein anormales Verhalten bei diesen Signalen auf, so kann dieses anhand der Anomalie-Scores identifiziert werden. Anschließend besteht die Möglichkeit, die Fahrzeugdaten zu diesem speziellen Zeitpunkt der anormalen Daten genauer zu untersuchen und dabei den Grund für das anormale Verhalten festzustellen. Dabei müssen jetzt nicht mehr die gesamten Daten der Testfahrt untersucht werden, sondern es ist ausreichend, wenn die Daten zu dem Zeitpunkt, wo mit Hilfe der Anomalie-Scores ein anormales Verhalten entdeckt wurde, genauer zu untersuchen. Dadurch wird nicht nur Zeit bei der Analyse eingespart, sondern auch die benötigte Rechenkapazität verringert.
Bezugszeichenliste

1: Vorrichtung
2-5: Komponente
6: Fahrzeugbus
10: Fahrzeug
20: Rechenzentrum
100: System
B, B*: Betriebsdaten (gefiltert*)
D, D*: Messdaten (gefiltert*)
F: Fahrzeugfunktion
M: Modelldaten
V: Vergleichsdaten
A: Anomaler Betriebszustand
a1)-f): Programmschritte

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

„Advances in Neural Information Processing Systems‟, 2019, S. 12831-12840 von Bertrand Charpentier, Marin Biloš und Stephan Günnemann sowie auf der „Neural Information Processing Systems“ Konferenz 2019 [0012]

Claims

Verfahren zur Detektion von anomalen Betriebszuständen eines Geräts, insbesondere eines Kraftfahrzeugs (10), mit den Schritten: a) Bereitstellen von Modelldaten (M) an das Gerät, die repräsentativ sind für zu erwartende Betriebszustände wenigstens einer Komponente (2, 3, 4, 5) des Geräts, b) Erheben von Messdaten (D) durch das Gerät, die repräsentativ sind für einen tatsächlichen Betriebszustand der wenigstens einen Komponente (2-5) des Geräts, c) Ermitteln von Vergleichsdaten (V) durch das Gerät in Abhängigkeit der Modelldaten (M) und der Messdaten (D), die repräsentativ sind für einen erwarteten Betriebszustand, d) Prüfen abhängig von den Vergleichsdaten (V) und den Messdaten (D), ob eine Abweichung des tatsächlichen Betriebszustands von dem erwarteten Betriebszustand vorliegt, und e) Zuordnen eines anomalen Betriebszustands der wenigstens einen Komponente (2-5) korrespondierend zu einem Zeitpunkt der Erhebung der Messdaten (D) abhängig von der Abweichung.
Verfahren nach Anspruch 1, wobei das Gerät als Kraftfahrzeug (10) ausgebildet ist.
Verfahren nach einem der vorstehenden Ansprüche, wobei - vor dem Schritt c) dem Kraftfahrzeug (10) eine zu evaluierende Fahrzeugfunktion (F) vorgegeben wird, - abhängig von der zu evaluierenden Fahrzeugfunktion (F) und den Messdaten (D) gefilterte Messdaten (D*) ermittelt werden, und - zum Ermitteln der Vergleichsdaten (V) in dem Schritt c) die gefilterten Messdaten (D*) herangezogenen werden.
Verfahren nach einem der vorstehenden Ansprüche, wobei - die Schritte b) bis d) jeweils zu mehreren aufeinanderfolgenden Zeitpunkten durchgeführt werden, und - im Falle, dass zu wenigstens N aufeinanderfolgenden Zeitpunkten jeweils eine Abweichung des tatsächlichen Betriebszustands von dem erwarteten Betriebszustand ermittelt wird, in dem Schritt e) der wenigstens einen Komponente (2-5) korrespondierend zu den N aufeinanderfolgenden Zeitpunkten der anomale Betriebszustand zugeordnet wird, wobei N eine natürliche Zahl größer 1 bezeichnet, insbesondere größer 5, bevorzugt größer 10.
Verfahren nach einem der vorstehenden Ansprüche, wobei in einem auf den Schritt e) folgenden Schritt f) im Falle, dass der wenigstens einen Komponente (2-5) ein anomaler Betriebszustand zugeordnet ist, die zu dem anomalen Betriebszustand korrespondierenden Messdaten (D) gespeichert und/oder ausgegeben werden.
Verfahren nach einem der vorstehenden Ansprüche, wobei der Schritt a) umfasst: - Bereitstellen von Betriebsdaten (B) eines oder mehrerer Kraftfahrzeuge an ein Rechenzentrum (20), - Vorgeben einer zu evaluierenden Fahrzeugfunktion (F) an das Rechenzentrum (20) und Filtern der Betriebsdaten (B) abhängig von der zu evaluierenden Fahrzeugfunktion (B*), - Ermitteln von Modelldaten (M) durch Trainieren eines Modells in Abhängigkeit der gefilterten Betriebsdaten (B*) für die zu evaluierende Fahrzeugfunktion (F), und - Bereitstellen der ermittelten Modelldaten (M) an das Kraftfahrzeug (10).
Verfahren nach einem der vorstehenden Ansprüche, wobei die zu dem anomalen Betriebszustand korrespondierenden Messdaten (M) in dem Schritt f) dem Rechenzentrum (20) übermittelt werden.
Verfahren nach einem der vorstehenden Ansprüche, wobei die Modelldaten (M) repräsentativ sind für ein künstliches neuronales Netz, insbesondere für ein tiefes neuronales Netz.
Vorrichtung (1) zur Detektion von anomalen Betriebszuständen für ein Gerät, insbesondere für ein Kraftfahrzeug (10), wobei die Vorrichtung (1) eingerichtet ist, das Verfahren nach einem der vorstehenden Ansprüche 1 bis 5 auszuführen.
System (100) zur Detektion von anomalen Betriebszuständen eines Kraftfahrzeugs (10), umfassend ein Rechenzentrum (20) sowie ein Kraftfahrzeug (10) mit einer Vorrichtung (1) nach Anspruch 9, wobei das System (100) eingerichtet ist, das Verfahren nach einem der Ansprüche 2 bis 8 auszuführen.
Computerprogramm umfassend Befehle, die bei der Ausführung des Computerprogramms durch einen Computer diesen veranlassen, das Verfahren nach einem der Ansprüche 1 bis 8 auszuführen.
Computerlesbares Speichermedium, auf dem das Computerprogramm nach Anspruch 11 gespeichert ist.