-
Die vorliegende Erfindung betrifft ein Verfahren zum Übertragen einer Lognachricht in einem Datensystem für Fahrzeuge von einer Datenquelle zu einer Datensammeleinrichtung. Darüber hinaus betrifft die vorliegende Erfindung ein Verfahren zum Übertragen einer Filterkonfigurationsnachricht in einem Datensystem für Fahrzeuge von einer Managementeinheit zu einer Datenquelle von Lognachrichten. Ebenso betrifft die vorliegende Erfindung ein Verfahren zum Sammeln von Lognachrichten mehrerer Datenquellen eines Datensystems für Fahrzeuge. Schließlich betrifft die vorliegende Erfindung auch ein entsprechendes Datensystem, Computerprogramm und computerlesbares Speichermedium.
-
Sogenannte „Connected Cars“ sind drahtlos mit einem Endgerät zur entsprechenden Datenübertragung verbunden. Beispielsweise kann so das Öffnen einer Tür eines Fahrzeugs mit einem Smartphone erfolgen, der Ladezustand des Fahrzeugs von entfernter Stelle abgerufen werden oder eine Ferndiagnose erstellt werden.
-
Die Funktionen von „Connected Cars“ können über viele Software-Komponenten, ECUs (elektronische Steuereinheiten) im Fahrzeug, aber auch in IT-Systemen im (Cloud-)Backend verteilt sein. Für eine einzige Funktion spielen oft mehrere Software-Komponenten über lange Funktionsketten (im Fahrzeug und/oder Cloud-Backend) zusammen. Um das Verhalten dieser langen Funktionsketten im Fehlerfall und auch für Fahrzeuge in der Entwicklung, in der Produktion und „im Feld“ optimal analysieren zu können, sollen Protokoll- beziehungsweise Logdaten (d.h. durch die Software-Komponenten selbst produzierte Logeinträge, die Auskunft über das innere Verhalten der jeweiligen Software-Komponente geben) aus allen beteiligten Komponenten zu einem zentralen Analysepunkt (Data Lake beziehungsweise Datensammeleinrichtung ggf. mit Analysesystem) verbracht und dort zeitlich korrekt einsortiert ausgewertet werden können. Hierbei besteht das Problem von Bandbreiten- und Ressourcenlimitierungen, insbesondere im Fahrzeug auf der Kommunikationsstrecke zwischen Fahrzeug und Cloud-Backend (mobile Drahtlosnetzwerke). Ein naiver Ansatz, alle Logdaten auf dem höchsten Verbositätslevel einzusammeln, ist daher nicht realisierbar.
-
Druckschrift
DE 10 2015 222 179 A1 offenbart ein Verfahren zur zentralen Verwaltung und Bereitstellung von Daten mittels eines mehrere Schnittstellen aufweisenden zentralen Speichersystems eines Fahrzeugs. Es findet eine schnittstellenübergreifende Kommunikation statt. Ein Datenadapter kann empfangene Datenpakete deserialisieren.
-
Darüber hinaus offenbart die Druckschrift
DE 101 40 519 A1 ein Kommunikationsverfahren, bei dem Daten aufbereitet werden. Hierzu erfolgt beispielsweise eine Umformatierung aller Daten aus einem Datenformat einer Steuergeräteapplikationsschnittstelle in ein von der Systemdiagnoseapplikation bekanntes Datenformat.
-
Die Druckschrift
US 2014/0005880 A1 beschreibt ein Verfahren, bei dem Protokolldaten in einem vordefinierten Protokolldatenformat erzeugt werden. Es findet eine Konvertierung empfangener Protokolldaten in ein anderes Datenformat statt.
-
In der Druckschrift
US 2019/0052522 A1 ist ein Verfahren beschrieben, bei dem eine periodische Aufzeichnung von Aktivitätsdaten in einer Protokolldatei vorgesehen ist.
-
Des Weiteren offenbart die Druckschrift
US 2011/0130916 A1 ein Verfahren zur ortsabhängigen Protokollierung von Daten, bei dem Fahrzeugdaten mit Standortdaten korreliert in einer Protokolldatei gespeichert werden.
-
Schließlich offenbart die Druckschrift
DE 10 2020 208 147 A1 ein Verfahren, bei dem Protokolldaten in einem standardisierten Datenformat gespeichert werden. Konvertierungsmodule sind dazu eingerichtet, Daten von einem herstellerspezifischen Datenformat in das standardisierte Datenformat zu konvertieren.
-
Die Aufgabe der vorliegenden Erfindung besteht darin, die Flexibilität beim Sammeln von Lognachrichten in Bezug auf proprietäre Systeme zu verbessern.
-
Entsprechend der vorliegenden Erfindung wird dazu ein Verfahren zum Übertragen einer Lognachricht in einem Datensystem für Fahrzeuge von einer Datenquelle zu einer Datensammeleinrichtung bereitgestellt. Ein Datensystem umfasst beispielsweise eines oder mehrere Fahrzeuge, die datentechnisch mit einem (Cloud-)Backend verbunden sind. Gegebenenfalls weist das Datensystem auch mindestens ein Endgerät (z.B. Smartphone) auf, welches ebenfalls als Datenquellen fungieren kann. Diese Endgeräte beziehungsweise Fahrzeuge sind beispielsweise Teil eines „Internet der Dinge“ (IOT). Von einer oder mehreren Datenquellen, die in den Fahrzeugen beziehungsweise Endgeräten implementiert sein können, sollen gegebenenfalls Lognachrichten in einer Datensammeleinrichtung gesammelt werden. Dementsprechend findet eine Übertragung dieser Lognachrichten von den Datenquellen zu der Datensammeleinrichtung statt.
-
In einem ersten Verfahrensschritt erfolgt ein Empfangen der Lognachricht in einem ersten Format von der Datenquelle. Auf dem Weg von der Datenquelle zu der Datensammeleinrichtung wird die Lognachricht beispielsweise von einem Adapter empfangen. Die Lognachricht besitzt in diesem Rohzustand ein erstes Format.
-
In einem weiteren Schritt erfolgt ein Bereitstellen einer Konvertierungsvorschrift zur Änderung eines Formats von Lognachrichten, wodurch ein Attribut einer jeweiligen Lognachricht geändert wird. Die Konvertierungsvorschrift dient also zur Änderung beziehungsweise Konvertierung des Formats von Lognachrichten. Ein Format einer Lognachricht beschreibt den Aufbau dieser Lognachricht. Beispielsweise besitzt eine Lognachricht einen Nachrichtenteil und eines oder mehrere Attribute. Attribute können Verarbeitungshinweise enthalten beispielsweise in Bezug auf Sicherheit, Datenschutz und dergleichen. Mit der Konvertierungsvorschrift soll eine Änderung des beziehungsweise der Attribute in einer festgelegten Art und Weise erfolgen. Das Ändern kann hier sehr breit interpretiert werden und auch neben einer einfachen Werteänderung ein Hinzufügen oder Entfernen eines Attributs beinhalten.
-
Es erfolgt ein automatisches Ändern des Attributs der Lognachricht in dem ersten Format entsprechend der Konvertierungsvorschrift zu einer konvertierten Lognachricht in einem vom ersten verschiedenen zweiten Format. Das Ändern bewirkt damit eine Transformation der Lognachricht von dem ersten Format in das zweite Format.
-
Schließlich erfolgt ein Weitersenden der konvertierten Lognachricht in dem zweiten Format anstelle der Lognachricht in dem ersten Format zu der Datensammeleinrichtung. Beispielsweise erfolgen sämtliche Schritte des Verfahrens in einem Adapter zwischen der Datenquelle und der Datensammeleinrichtung. Insbesondere erfolgt in dem Adapter dann die Formatkonvertierung.
-
In vorteilhafter Weise können so von proprietären Systemen Lognachrichten komfortabel gesammelt werden. Die Lognachrichten können nämlich auch von proprietären Datenquellen in Abhängigkeit von zentral erstellten Attributeinstellungen gesammelt werden. Dies ermöglicht es, die Datenflut von Lognachrichten auch von proprietären Systemen gezielt einzuschränken.
-
In einer vorteilhaften Ausgestaltung ist vorgesehen, dass bei dem Ändern des Attributs der Lognachricht in dem ersten Format das Attribut der Lognachricht entsprechend der Konvertierungsvorschrift neu hinzugefügt oder entfernt wird, womit sich die konvertierte Lognachricht in dem zweiten Format ergibt. Beispielsweise ist eine Lognachricht einer Datenquelle nicht mit einem Datenschutzattribut versehen. Das Datensammeln soll aber unter Einhaltung von Datenschutzvorschriften erfolgen. In diesem Fall kann die Konvertierungsvorschrift beispielsweise ein Datenschutzattribut zu der Lognachricht hinzufügen. Gegebenenfalls ergibt sich aus dem Kontext der Datenquelle, welcher Datenschutzstufe die Lognachricht zuzuordnen wäre. Beispielsweise unterliegen Videonachrichten einer Innenraumkamera eines Fahrzeugs strengen Datenschutzregeln. Somit könnte mit der Konvertierungsvorschrift einer entsprechenden videobasierten Lognachricht eine passende Datenschutzstufe zugeordnet werden. Basierend darauf könnte die Datenquelle diese Lognachricht überhaupt nicht weitersenden, oder aber sie wird auf dem Weg zur Datensammeleinrichtung durch ein Filter ausgefiltert.
-
Analog zu dem Hinzufügen eines Attributs kann die Konvertierungsvorschrift auch dazu ausgelegt sein, ein Attribut aus einer Lognachricht zu entfernen. Beispielsweise besitzt eine Lognachricht einer Datenquelle zwei Kanäle, einen für die Temperatur und einen für die Geschwindigkeit. Dementsprechend besitzt die Lognachricht auch Attribute, die die jeweiligen Kanäle bezeichnen. Werden nun in einer Kampagne nur die Temperaturdaten gesammelt, so ist es vorteilhaft, bereits in der Datenquelle die Lognachrichten von den Geschwindigkeitsinformationen zu befreien. Dementsprechend kann die Konvertierungsvorschrift dazu dienen, das ursprüngliche Format einer Lognachricht mit den beiden Kanälen Temperatur und Geschwindigkeit in eine Lognachricht mit nur einem Kanal (z.B. Temperatur) zu ändern. Dementsprechend wird das Attribut bezüglich des zweiten Kanals „Geschwindigkeit“ aus der Lognachricht entfernt. Auf diese Weise kann das Datenübertragungsvolumen reduziert werden.
-
Bei einem anderen Ausführungsbeispiel kann das Attribut der Lognachrichten in dem ersten Format einen ersten Wertebereich und nach dem Ändern in dem zweiten Format einen vom ersten verschiedenen, zweiten Wertebereich besitzen. Beispielsweise ist die Datenquelle in der Lage, der Lognachricht eine von fünf Kritikalitätsstufen zuzuordnen. Eine gewählte Logging-Kampagne unterscheidet jedoch nur drei verschiedene Kritikalitätsstufen. In diesem Fall ist die Konvertierungsvorschrift dafür notwendig, die fünf Kritikalitätsstufen der ursprünglichen Lognachricht (erstes Format) in drei Kritikalitätsstufen der konvertierten Lognachricht (zweites Format) „umzurechnen“. Entsprechende Wertebereichsumwandlungen können sich auch für andere Attribute ergeben. Insbesondere können auch kleinere Wertebereiche in größere Wertebereiche umgerechnet werden.
-
In spezifischen Ausführungsbeispielen kann vorgesehen sein, dass das Attribut beziehungsweise eines der Attribute einer Lognachricht eine Kritikalitätsstufe, eine Logging-Kategorie, einen Zeitstempel, eine Sicherheitskennung oder eine Datenschutzkennung betrifft. Wie oben bereits angedeutet wurde, kann mit der Kritikalitätsstufe eine Klassifizierung der Lognachricht in Fehler, Warnung, Information und dergleichen erfolgen. Bei der Logging-Kategorie kann unterschieden werden, wie ausführlich das Logging stattfinden soll und inwieweit beispielsweise Daten eingebettet werden sollen. Die Datenschutz- und Sicherheitskategorien können dazu verwendet werden, um Persönlichkeitsrechte und Sicherheitsanforderungen zu berücksichtigen. Ein Zeitstempel in den Lognachrichten kann dazu verwendet werden, diese zu synchronisieren. Dabei ist es besonders vorteilhaft, wenn es sich um einen zentralen Zeitstempel handelt, der auf einer gemeinsamen Zeitbasis beruht. Ein derartiger zentraler Zeitstempel ermöglicht es, dass alle Daten des Datensystems synchronisiert und damit zielgerichteter ausgewertet werden können.
-
In einem bevorzugten Ausführungsbeispiel ist vorgesehen, dass nach oder bei dem Weitersenden der konvertierten Lognachricht in dem zweiten Format ein Filtern entsprechend dem oder den Attributen der konvertierten Lognachricht erfolgt. Beispielsweise erfolgt das Filtern dergestalt, dass von der Datenquelle Lognachrichten, die einer bestimmten Datenschutzkategorie zugeordnet werden, überhaupt nicht abgesendet werden. In Bezug auf den Datenschutz unkritische Daten hingegen können von der Datenquelle abgesandt werden. Ähnliches kann in Bezug auf die Kritikalitätsstufe erreicht werden. So ist es beispielsweise möglich, dass nur Fehlermeldungen, d.h. Lognachrichten mit Fehlerinhalt, von einer Datenquelle versendet oder von Filtern durchgelassen werden.
-
In einem weiteren Aspekt der vorliegenden Erfindung ist ein Verfahren zum Übertragen einer Filterkonfigurationsnachricht in einem Datensystem für Fahrzeuge von einer Managementeinheit zu einer Datenquelle von Lognachrichten bereitgestellt. In diesem Fall werden Filterkonfigurationsnachrichten stromaufwärts (entgegen den stromabwärts fließenden Lognachrichten) zu einer oder mehreren Datenquellen übertragen. So wird beispielsweise in einem Logging-Management-System, das heißt einer Managementeinheit, eine Logging-Kampagne erstellt. Eine derartige Logging-Kampagne enthält eine Sammlung von Filterkonfigurationen, die beispielsweise aus einem n-Tupel von Objekten (hier Paare) bestehen, wie etwa [Datenquellen-ID, Filterbedienungen] für jede Quelle. Die Filterbedingungen können sich auf eine maximale Kritikalitätsstufe, eine Logging-Kategorie, eine Datenschutzstufe, eine Sicherheitsstufe und so weiter beziehen. Die Filterkonfigurationen können mithilfe von Filterkonfigurationsnachrichten stromaufwärts an die Datenquellen übertragen werden.
-
In einer ersten Stufe des Verfahrens kann ein Empfangen einer ursprünglichen Filterkonfigurationsnachricht in einem ersten Format von der Managementeinheit durch eine Adaptereinrichtung bzw. einen Adapter erfolgen, die/der zwischen der Managementeinheit und der Datenquelle angeordnet ist, wobei die Filterkonfigurationsnachricht zum Konfigurieren der Datenquelle nutzbar ist. Die Managementeinheit kann aber auch diejenige Einheit sein, von der die Filterkonfigurationsnachrichten stromaufwärts verteilt werden. Beispielsweise kann ein Flight Recorder (gegebenenfalls ein Ringpuffer) eines Zentralsteuergeräts eines Fahrzeugs als eine solche Managementeinheit gesehen werden, die zu den einzelnen Steuergeräten stromaufwärts die Filterkonfigurationen verteilt.
-
In einem weiteren Schritt erfolgt ein Bereitstellen einer Konvertierungsvorschrift zur Änderung eines Formats und/oder eines Werts der Filterkonfigurationsnachricht. Die Konvertierungsvorschrift kann in der Adaptereinrichtung beziehungsweise dem Adapter bereitgestellt werden. In der Adaptereinrichtung erfolgt dann auch das automatische Ändern der ursprünglichen Filterkonfigurationsnachricht in dem ersten Format entsprechend der Konvertierungsvorschrift zu einer konvertierten Filterkonfigurationsnachricht in einem von dem ersten verschiedenen zweiten Format und/oder mit einem geänderten Wert. So ist beispielsweise eine Umrechnung von Wertebereichen denkbar. Gegebenenfalls definiert ein spezifisches Datenformat, mit dem die Attribute stromaufwärts gesendet werden, spezifische Zahlenwerte, die jeweils eine Kritikalitätsstufe bestimmen. Es gibt jedoch Quellen, die für dieselbe Kritikalitätsstufe andere Zahlenwerte verwenden. So weist beispielsweise ein erstes Datenformat der Stufe „ERROR“ den Zahlenwert „2“ zu, während ein zweites Datenformat der Stufe „ERROR“ den Zahlenwert „1“ zuweist. Mit der Konvertierung kann ein einheitlicher Zahlenwert für die Stufe „ERROR“ eingestellt werden.
-
Ähnliches ist auch für andere Filterattribute denkbar. Werden beispielsweise Datenschutz- und Sicherheitsstufen neu eingeführt, die in existierenden Logdatenformaten nicht spezifiziert sind, so muss die Adaptereinrichtung entscheiden, ob bei entsprechend gesetzter Stufe gegebenenfalls die Quelle gar keine Logdaten produzieren darf, weil ansonsten eine Verletzung des Schutzes der Daten vorliegen würde. In diesem Fall wird durch die Adaptereinrichtung also ebenfalls das Format der Lognachricht geändert, indem eines oder mehrere Attribute der Lognachricht hinzugefügt werden.
-
Schließlich erfolgt bei dem Verfahren ein Weitersenden der konvertierten Filterkonfigurationsnachricht in dem zweiten Format und/oder mit dem geänderten Wert anstelle der ursprünglichen Filterkonfigurationsnachricht in dem ersten Format von der Adaptereinrichtung zu der Datenquelle. Damit erreicht die Filterkonfigurationsnachricht ihr Ziel, nämlich die entsprechende Datenquelle. Diese wird dann gegebenenfalls automatisch entsprechend der Filterkonfigurationsnachricht umkonfiguriert, oder sie konfiguriert sich selbst um.
-
In einem Ausführungsbeispiel wird bei dem automatischen Ändern der ursprünglichen Filterkonfigurationsnachricht eine Filterbedingung der Filterkonfiguration geändert, wobei die Filterbedingung eine Kritikalitätsstufe, eine Logging-Kategorie, eine Sicherheitskennung beziehungsweise Sicherheitsstufe, eine Datenschutzkennung beziehungsweise Datenschutzstufe von Lognachrichten oder einen Wertebereich betrifft.
-
Optional kann vorgesehen sein, dass die Konvertierungsvorschrift eine Abbildung eines ersten Wertebereichs auf einen zweiten Wertebereich beinhaltet, und das automatische Ändern entsprechend durchgeführt wird. So wird beispielsweise ein Wertebereich von fünf Sicherheits- oder Datenschutzstufen auf einen Wertebereich von drei entsprechenden Stufen abgebildet oder umgekehrt. Ähnliches gilt natürlich auch für andere Filterbedingungen wie etwa Logging-Kategorien, Kritikalitätsstufen und dergleichen.
-
Auch im Fall der Filterkonfigurationen kann vorgesehen sein, dass die Konvertierungsvorschrift beinhaltet, dass in die Filterkonfigurationsnachricht ein Attribut neu eingesetzt oder aus der Filterkonfigurationsnachricht entfernt wird. Wie oben im Zusammenhang mit den Lognachrichten bereits erläutert wurde, kann auch bei Filterkonfigurationsnachrichten ein Attribut komplett neu eingesetzt oder aus der Filterkonfigurationsnachricht gelöscht beziehungsweise entfernt werden. Ist es beispielsweise nicht notwendig, dass Sicherheitsstufen eingehalten werden, so kann das entsprechende Sicherheitsattribut aus der Filterkonfigurationsnachricht genommen werden.
-
Die oben im Zusammenhang mit dem Übertragen von Lognachrichten und dem Übertragen von Filterkonfigurationsnachrichten genannten Verfahren können auch kombiniert werden zu einem Verfahren zum Sammeln von Lognachrichten mehrerer Datenquellen eines Datensystems für Fahrzeuge. Dabei erfolgt ein Erstellen einer Logging-Kampagne, die für eine (in der Regel für alle) der mehreren Datenquellen eine spezifische Filterkonfiguration umfasst, in einer Managementeinheit. Beispielsweise wird eine derartige Logging-Kampagne in einem Logging-Management-System oder in einem Produktionssystem erstellt. Eine Filterkonfiguration kann eine Kennung für die jeweilige Datenquelle und eine oder mehrere Filterbedingungen für die jeweilige Datenquelle aufweisen.
-
Es erfolgt ein automatisches Übertragen der Filterkonfiguration der Logging-Kampagne in einer Filterkonfigurationsnachricht an die Datenquelle gemäß obigem Verfahren (stromaufwärts) und ein automatisches Konfigurieren der jeweiligen Datenquelle mit der spezifischen Filterkonfiguration. Anschließend erfolgt ein Übertragen von Daten durch die Datenquelle entsprechend einem Übertragungsverfahren, wie es oben beschrieben wurde, zu der zentralen Datensammeleinrichtung des Datensystems entsprechend der spezifischen Filterkonfiguration (stromabwärts).
-
Im Rahmen der Erfindung kann damit auch ein Adapter zum Übertragen einer Lognachricht in einem Datensystem für Fahrzeuge bereitgestellt werden, wobei der Adapter ausgebildet ist zur Durchführung des oben beschriebenen Verfahrens zur Übertragung von Lognachrichten. Analog kann auch ein Adapter zum Übertragen von Filterkonfigurationen in dem Datensystem für Fahrzeuge bereitgestellt werden, wobei der Adapter ausgebildet ist zur Durchführung eines oben genannten Verfahrens zur Übertragung von Filterkonfigurationen. Vorzugsweise sind beide Adapter in einer Einheit zusammengefasst, die zur bidirektionalen Datenübertragung ausgebildet ist.
-
Insgesamt kann damit erfindungsgemäß auch ein Datensystem für Fahrzeuge bereitgestellt werden, das eine Managementeinheit (gegebenenfalls in einer Cloud) zum Erstellen einer Logging-Kampagne, mindestens ein Fahrzeug mit mindestens einer Datenquelle und einen Adapter der oben genannten Art aufweist, wobei das Datensystem dazu ausgebildet ist, das Verfahren zum Sammeln von Lognachrichten mittels einer Logging-Kampagne durchzuführen.
-
Erfindungsgemäß wird darüber hinaus bereitgestellt ein Computerprogramm umfassend Befehle, die bei der Ausführung des Programms durch eine Steuervorrichtung eines genannten Datensystems dieses veranlassen, das ebenfalls genannte Verfahren auszuführen. Ferner wird ein computerlesbares Speichermedium bereitgestellt, das Befehle umfasst, welche bei der Ausführung durch eine Steuervorrichtung des Datensystems dieses veranlassen, das genannte Verfahren auszuführen. Die im Zusammenhang mit dem Verfahren geschilderten Vorteile und Weiterbildungen gelten sinngemäß auch für die Adapter beziehungsweise das Datensystem. Dabei können die erwähnten Verfahrensschritte entsprechende funktionale Merkmale der genannten Vorrichtungen darstellen.
-
Die Erfindung umfasst auch die Kombinationen der Merkmale der beschriebenen Ausführungsformen.
-
Die vorliegende Erfindung wird nun anhand von 1 näher erläutert, die schematisch ein Ausführungsbeispiel eines erfindungsgemäßen Verfahrens zum Sammeln von Daten mehrerer Datenquellen in einem Ablaufdiagramm wiedergibt. Dabei können die einzelnen Blöcke auch als entsprechende Hardware-Komponenten eines Systems zum Sammeln von Daten gesehen werden. In der Figur sind funktionsgleiche Elemente jeweils mit denselben Bezugszeichen versehen.
-
Bei den im Folgenden erläuterten Ausführungsbeispielen handelt es sich um bevorzugte Ausführungsbeispiele der Erfindung. Bei den Ausführungsbeispielen stellen die beschriebenen Komponenten jeweils einzelne, unabhängig voneinander zu betrachtende Merkmale der Erfindung dar, welche die Erfindung jeweils auch unabhängig voneinander weiterbilden und damit auch einzeln oder in einer anderen als der gezeigten Kombination als Bestandteil der Erfindung anzusehen sind. Des Weiteren sind die beschriebenen Ausführungsbeispiele auch durch weitere der bereits beschriebenen Merkmale der Erfindung ergänzbar.
-
Die vorliegende Erfindung geht, wie einleitend erwähnt, von der Problematik aus, dass die Software-Landschaft in den Steuergeräten von Fahrzeugen oft sehr heterogen ist. Es werden verschiedene Logdaten-Formate (inklusive Beschreibung von Filterkonfigurationseinstellungen) verwendet, die in der Regel nicht direkt miteinander kompatibel sind und häufig Mängel in der Konfigurierbarkeit aufweisen. Aus diesem Grund war bisher das zentrale Einsammeln und gemeinsame Auswerten von Lognachrichten beziehungsweise Logdaten von sämtlichen (proprietären) Steuergeräten in einem Fahrzeug häufig nicht möglich. Mit einem erfindungsgemäßen System entsprechend 1 ist dies jedoch möglich.
-
1 zeigt eine Zentraleinheit beziehungsweise ein Backend BE, in dem eine Datensammel- beziehungsweise Logging-Kampagne erstellt und die entsprechenden Daten gesammelt werden können. Daneben zeigt 1 als Frontend beispielhaft ein sogenanntes Internet-of-Things IOT auf beiden Seiten des Backend BE. Das IOT ist jedoch als Gesamtheit zu betrachten und nur der Übersicht halber in 1 zweigeteilt. Zum IOT gehören beispielsweise Fahrzeuge beziehungsweise deren Steuergeräte SGP-1, ..., SGP-m (allg. SGP) und Z, aber auch Endgeräte wie Smartphones SP, wie sie in 1 rechts dargestellt sind. Letztere können mit einer zentralen Datensammeleinrichtung DL einer Cloud CL verbunden sein.
-
Eine Logging-Kampagne kann beispielsweise von einem Kampagnenersteller KE mittels eines Logging-Management-Systems LMS im Backend BE beziehungsweise in der Zentraleinheit beispielsweise für den laufenden Betrieb einer Fahrzeugflotte erstellt werden. Alternativ kann die Logging-Kampagne aber auch beispielsweise für die Entwicklungsphase beziehungsweise die Produktionsphase durch einen Entwickler EW beziehungsweise Produktionstechniker in einem Produktionssystem PS erstellt werden.
-
Eine Logging-Kampagne kann als Datenelement gesehen werden und enthält beispielsweise eine oder mehrere der folgenden Komponenten:
- - Eine Sammlung von Filterkonfigurationen beispielsweise in Form eines n-Tupel [Datenquelle-ID, Filterbedingung(en)], wobei die Datenquellen Software-Komponenten (SWC beziehungsweise CS) sein können und die Filterbedingungen unten näher definiert sind.
- - Vorverarbeitungsanweisungen (z.B. Skripte)
- - Triggerbedingungen, mit denen definiert werden kann, wann Logdaten erzeugt werden sollen.
- - Laufzeiten, mit denen definiert werden kann, dass eine Kampagne in einem bestimmten Zeitraum ausgeführt werden soll, wobei beispielsweise pro Fahrzeug auch mehrere Kampagnen parallel ausgeführt werden können.
- - Speichervorgaben beispielsweise für einen Ringpuffer FR (Flight Recorder) in einem Fahrzeug, wie etwa Ablageort im Dateisystem, maximale Größe des Ringpuffers für die Kampagne, maximal nutzbarer Speicher auf einem Flash-Speicher eines Zentralsteuergeräts Z oder auf einem externen Speichermedium (z.B. USB-Stick) z.B. für sogenannte „Snapshots“ (Datenschnappschüsse) der Kampagne und maximale Größe pro Snapshot-Datei.
- - Attribute (Parameter/Werte-Paare) z.B. für die Angabe von Authentifizierungsinformationen oder Schlüsselinformationen für die Verschlüsselung der Snapshot-Dateien.
-
Über die Filterkonfigurationen können die Filterbedingungen für konfigurierbare Datenquellen definiert werden. Als auswählbare und konfigurierbare Datenquellen kommen beispielsweise sogenannte „Log-Kanäle“ von Software-Komponenten SWC in den Software-Partitionen von Steuergeräten SGP-1 bis SGP-m, also entsprechende Quellen mit Quellenindizes Q1-1 ... Q1-n, ..., Qm-1 ... Qm-n in einem Fahrzeug infrage. Die „Log-Kanäle“ können aber auch Teile dieser Datenquellen sein. Ferner können „Log-Kanäle“ auch von sogenannten Cloud-Services CS1-1 ... CS1-n, ..., CSm-1 ... CSm-n (allg. CS) in verschiedenen Cloud-Backendsystemen BES-1, ..., BES-m sein, die z.B. an der Realisierung einer Connected-Car-Funktion beteiligt sind.
-
Als Filterbedingungen können eine oder mehrere der folgenden Bedingungen genutzt werden:
- - Maximaler Log-Level: Z.B. Kategorien wie „Fatal“, „Error“, „Warning“, „Info“, „Debugg“, „Verbose“ (sortiert nach steigendem Datenumfang).
- - Logging-Kategorie: Z.B. die Kategorien „Trace“, „Log“, „Recording“, wobei „Log“ ein standardmäßiges Logging, „Trace“ ein ausführlicheres Logging und „Recording“ ein Logging mit zusätzlich eingebetteten Referenzen (z.B. Videodateien) bedeuten kann.
- - Datenschutzrechtliche Relevanz der Logdaten (z.B. keine Erfassung von personenbezogenen Daten erlaubt, Indikation einer notwendigen Verschleierung von Standortdaten).
- - Sicherheitsrelevanz der Logdaten: Z.B. keine, authentisch, vertraulich
- - Wertebereiche von beliebigen Attributen, d.h. Konfigurationsinformationen: Z.B. Auswahl von Parameter/Werte-Paaren unter Eingabe eines oder mehrerer Vergleichsoperatoren und eines Referenzwerts, mit dem der jeweilige Wert verglichen werden soll.
-
Kampagnen werden im Hauptanwendungsfall, wie oben angedeutet, durch Benutzer (Kampagnenersteller KE) unter Nutzung beispielsweise eines Logging-Management-Systems LMS etwa in einem Cloud-Backend (Backend in einer Cloud) erstellt. Das LMS verteilt die Kampagnen wiederum beispielsweise unter Nutzung eines Auftragsmanagement-Service DCOM eines Fahrzeugflotten-Datensammelsystems GDC automatisch an ausgewählte Fahrzeuge oder ganze Fahrzeugflotten. Das LMS konfiguriert aber auch beispielsweise die mit den Fahrzeugen verbundenen Cloud-Backend-Systeme BES-1, ..., BES-m so, dass die in der Kampagne enthaltenen Filterkonfigurationen für die Backend-Datenquellen (z.B. Smartphone SP) an die betroffenen Cloudservices (CS1-1 ... CS1-n, ..., CSm-1 ... CSm-n) verteilt werden (im Zeitraum, für den eine Kampagne aktiv ist). Dies erfolgt „stromaufwärts“ (durchgezogene Pfeile in 1; entgegen dem stromabwärts fließenden Logdatenstrom(gestrichelte Pfeile)) über eine Kaskade von Logging-Konzentrationseinrichtungen VLK-1, ..., VLK-m bzw. BLK-1, ..., BLK-m (allg. VLK bzw. BLK) bis hin zu den durch eine Kampagne betroffenen Cloud Services CS1-1 ... CS1-n, ..., CSm-1 ... CSm-n (allg. CS), deren Logkanäle entsprechend konfiguriert werden, sodass sie nur die gewünschten Daten produzieren. Dabei erfolgt ggf. eine Weiterleitung von CS zu Endgeräten SP (Smartphone).
-
Die Kampagnen und die darin enthaltenen Filterkonfigurationen für die Software-Komponenten SWC in den Fahrzeugen werden nach Erstellung vom Auftragsmanagement-Service DCOM über Drahtlos-Verbindungen (Over-the-Air, OTA) zum jeweiligen Fahrzeug im IOT gesendet und dort z.B. im Zentralsteuergerät Z (Gateway) vom Datensammlungsmaster DCM entgegengenommen und beispielsweise an den Ringpuffer FR weitergeleitet. Der Ringpuffer FR kann die Laufzeit einer Kampagne im Fahrzeug steuern, d.h. in welchem Zeitraum die Logdatenquellen dort mit den in der Kampagne enthaltenen Filterkonfigurationsdaten konfiguriert werden sollen.
-
Bei aktiver Kampagne werden die Filterkonfigurationsdaten zunächst z.B. vom Ringpuffer FR an die zentrale Logging-Konzentrationseinrichtung VLK-Z im Zentralsteuergerät Z weitergegeben. Danach erfolgt über eine Kaskade von Zwischensammelpunkten, sogenannten „Logging-Konzentrator-Services“ VLK bzw. VLK-1 ... VLK-m, zunächst eine Verteilung (Routing) der Filterkonfigurationen „stromaufwärts“ zu feingranular selektierbaren Logdaten-Quellen („Logkanäle“) in den Softwarekomponenten der Steuergeräte im Fahrzeug. Hieraus ergibt sich eine weitreichende Steuerbarkeit des auftretenden Logdatenvolumens über die in der Kampagne enthaltenen Filterkonfigurationen.
-
Die Filterkonfigurationen sollen möglichst bereits an den Quellen angewendet werden, um stromabwärts nur die minimale Menge an Logdaten verarbeiten zu müssen. In Abhängigkeit von der Leistungsfähigkeit der Systeme (sowohl onbordseitig als auch in der Cloud) kann aber entschieden werden, ob komplexere Filterbedingungen auch in den Logging-Konzentrator-Services VLK umgesetzt werden.
-
Der Vorteil dieser detailliert einstellbaren Filterkonfigurationen ermöglicht, dass selektiv und feingranular genau diejenigen Datenquellen erschlossen werden, die beispielsweise für ein im Feld gemeldetes Fehlerbild in Verdacht stehen, gegebenenfalls einschließlich historischer Logdaten, die zu einem Fehlerereignis geführt haben. Somit kann ressourcenschonend und trotz geringer zur Verfügung stehender Bandbreiten Ressourcen und gegebenenfalls Übertragungsvolumina eine effiziente Fehlersuche beziehungsweise Analyse durchgeführt werden.
-
Das beschriebene System ist offen für weitere Anwendungsfälle mit alternativer Einbringung von Kampagnen. Neben der Definition von Kampagnen über das Logging-Management-System LMS und das Datensammelsystem für Fahrzeugflotten GDC ermöglicht die Erfindung, Kampagnen über einen Diagnosezugang zum Fahrzeug einzubringen. Dafür ist beispielsweise im Fahrzeug eine Komponente mit dem Namen Fahrzeugdiagnoseservice VDS vorgesehen. Dies ermöglicht beispielsweise die beiden folgenden Anwendungsfälle:
- Entwickler EW wollen direkt am Fahrzeug die Logdatenquellen für die Analyse eines beobachteten Fehlers konfigurieren. Sie erstellen hierzu ähnlich wie der Kampagnenhersteller KE eine Kampagne, die in diesem Fall beispielsweise über ein lokales Netz LN oder ein Speichermedium ins Zentralsteuergerät Z des Fahrzeugs übertragen wird. Im Zentralsteuergerät Z empfängt der Fahrzeugdiagnoseservice VDS die Kampagne und übergibt sie an den Ringpuffer FR. Von dort wird die Kampagne stromaufwärts über den Loggingkonzentrator VLK-Z des Zentralsteuergeräts Z an Software-Komponenten SWC QZ-1 ... SWC QZ-n des Steuergeräts Z und/oder an andere Steuergerät-Softwarepartitionen SGP-1 ... SGP-m verteilt. Die Loggingkonzentratoren VLK-1 ... VLK-m der Steuergerät-Softwarepartitionen SGP-1 ... SGP-m verteilen die jeweiligen Filterkonfigurationen der Loggingkampagne an die steuergerätinternen Software-Komponenten SWC Q1-1 ... SWC Q1-n, ..., SWC Qm-1 ... SWC Qm-n.
-
Während der Kampagne fließen die entsprechend den jeweiligen Filterkonfigurationen der Datenquellen erzeugten Logdaten von den Software-Komponenten über die Loggingkonzentratoren entsprechend den gestrichelten Pfeilen in 1 vorzugsweise zu dem Ringpuffer FR. Gemäß der Konfiguration der Kampagne können von dem Ringpuffer Schnappschüsse SN gewonnen werden. Nach Ablauf der Kampagne können die erstellten Schnappschüsse SN über den Fahrzeugdiagnoseservice VDS auf das Entwicklersystem (symbolisiert durch den Entwickler EW) heruntergeladen oder manuell an die zentrale Datensammeleinrichtung DL übertragen werden. Beispielsweise kann diese Übertragung mittels eines USB-Sticks vom zentralen Steuergerät Z zum Entwicklersystem erfolgen.
-
Bei einem weiteren Anwendungsfall soll in der Fahrzeug-Produktion (Fabrik) das innere Verhalten der Software-Komponenten SWC auf den Steuergeräten beziehungsweise den Steuergerätepartitionen SGP während der Inbetriebnahme beobachtet werden, um z.B. Produktionsfehler erkennen zu können. Hierzu können die IT-Systeme der Fabrik, wie etwa ein Produktionssystem-Service PS über das lokale Netz LN Kampagnen via Fahrzeugdiagnoseservice VDS in den Ringpuffer FR beziehungsweise Filterkonfigurationen in den zentralen Loggingkonzentrator VLK-Z zur weiteren Verteilung einbringen. Auf diese Weise können für jeden Produktionsschritt genau die dann relevanten Logkanäle angezapft werden.
-
Nachfolgend wird die Produktion und Weiterleitung der Logdaten näher erläutert. Logdaten bestehen ggf. aus einzelnen Lognachrichten beispielsweise mit folgenden Eigenschaften und Datenfeldern:
- - Eindeutige Angabe der Logdatenquelle (Logkanal) per UUID oder anderer global eindeutiger Identifikationsinformation; beispielsweise besitzt eine Software-Komponente SWC einen oder mehrere Logkanäle.
- - Hochauflösender (z.B. 1µs) und präziser Zeitstempel (z.B. Abweichung maximal +/- 50 µs von der global synchronisierten Referenzzeit SRZ, die beispielsweise in jedem Steuergerät beziehungsweise jedem Cloud-Backend-System BES zur Verfügung steht und auf eine Referenzzeit RZ einer zentralen Zeitbasis bezogen ist). Der Zeitstempel sollte immer in eine absolute Zeit beispielsweise als Differenz zum Datum 01.01.1970 UTC umgerechnet werden können. Hierzu kann es notwendig sein, dass ein Integer-Datentyp mit 64 Bit Größe zur Verfügung gestellt wird. Mit einem derartigen Zeitstempel kann sichergestellt werden, dass in der zentralen Datensammeleinrichtung DL alle Lognachrichten zeitlich korrekt einsortiert werden können. Somit lässt sich eine hohe Datenqualität für gute Auswerteergebnisse beispielsweise in einem großen Datenanalysesystem BDAS, welches mehrere Datenanalysesysteme DAS1 ... DASn aufweisen kann, sicherstellen.
- - Ein sogenannter Loglevel, d.h. eine Kritikalitätsstufe der Lognachrichten, kann beispielsweise folgende Werte annehmen:
- • FATAL (fataler Fehler)
- • ERROR (Fehler in Bezug auf korrekte Funktionalität)
- • WARN (Warnung, wenn korrektes Verhalten nicht sichergestellt werden kann)
- • INFO (hochrangige Information)
- • DEBUG (detaillierte Information für Programmierer)
- • VERBOSE (ausführliche Debug-Nachricht)
- - Nicht-unterdrückbar-Flag: Falls dieses Flag gesetzt ist, darf die Nachricht nicht ausgefiltert werden. Hiermit markierte Lognachrichten werden für die Propagierung interner Fehler des Logging-Systems verwendet.
- - Liste von Attributen (Parameter-Werte-Paare). Eine Lognachricht kann also beispielsweise folgende Attribute aufweisen:
- • „Sicherheitsniveau“ beziehungsweise „Security Level“ (mögliche Werte:
- keines, authentisch, vertraulich): Gibt die Schutzwürdigkeit der Lognachricht an in Bezug auf Cyber-Security-Eigenschaften wie „Authentizität“ und „Vertraulichkeit“. Das Sicherheitsniveau wird zur Filterung und Entscheidung verwendet, ob die Logdaten über bestimmte Verbindungen gesendet beziehungsweise auf Medien gespeichert werden dürfen beziehungsweise in welcher Form (z.B. verschlüsselt). Fehlt die Angabe, so wird die höchste Schutzwürdigkeit angenommen (d.h. vertraulich).
- • „Datenschutzniveau“: Gibt die Schutzwürdigkeitsklasse der Lognachricht in Bezug auf ihre datenschutzrechtliche Relevanz an. Bei fehlender Angabe soll die höchste Schutzwürdigkeitsklasse angenommen werden, da eine datenschutzrechtliche Signifikanz nicht bewertet werden kann.
- • „Kategorie“ mit folgenden möglichen Werten:
- ▪ „Trace“: Diese Kategorie weist beispielsweise darauf hin, dass die Lognachricht instrumentierten Code aufweist.
- ▪ „Log“: Hierbei kann es sich um Standard-Lognachrichten durch Programmablauf handeln.
- ▪ „Recording“: Bei dieser Kategorie kann die Lognachricht eingebettete Dateien im Ereignisstrom aufweisen, wie etwa einen Screenshot.
- ▪ „Referenz“: Die Lognachricht erhält einen Verweis auf eine Datei beziehungsweise Nachricht, die persistent in dem System gespeichert ist (z.B. in Form einer URI, die für ein Log-Ereignis abgelegt ist).
- ▪ „Statistik“: Statistische Informationen
- ▪ „Performance“: Performance-relevante Informationen
- - Nachrichteninhalt(e) („Payload“): Pro Lognachricht, d.h. pro Zeitstempel und gemeinsamen Attributen, können auch mehrere Nachrichteninhalte registriert werden.
-
Die Übertragung und Speicherung der Logdaten kann in einem standardisierten Format erfolgen. Ein solches standardisiertes Format („kanonische Form“) kann bei gegebener Flexibilität die Konvertierung oder Einbettung auch anderer existierender Logdatenformate in diese „kanonische Form“ ermöglichen. Andere Logdatenformate (z.B. AUTOSAR DLT) können aber auch angepasst werden, um die vorstehenden Eigenschaften und Datenfelder zu unterstützen.
-
Die aus der Anwendung der Filterkonfigurationen resultierenden Lognachrichten der jeweiligen Quellen werden „stromabwärts“ über dieselbe Kaskade von LoggingKonzentratoren VLK beziehungsweise BLK - wie oben erwähnt - an eine zentrale Datensammeleinrichtung DL im Backend BE weitergeleitet.
-
Vom Fahrzeug aus gibt es hierbei mehrere Optionen:
- - Direkte Weiterleitung einzelner Lognachrichten vom zentralen Logging-Konzentrator VLK-Z über den Datensammlungsmaster DCM und die Drahtlosschnittstelle OTA via das Datensammelsystem GDC für die Fahrzeugflotte beziehungsweise dessen Datenpumpe DP in die zentrale Datensammeleinrichtung DL.
- - Ringpuffer-Funktionalität („Flight Recorder“ FR): Hierbei zunächst onbordseitige Aufzeichnung und Zwischenspeicherung mehrerer Lognachrichten in Form von Schnappschüssen SN („Log Snapshot Dateien“) in einem persistenten Speicher des Zentralsteuergeräts Z (z.B. Flash-Speicher, am Zentralsteuergerät Z angeschlossener USB-Stick, et cetera). Anschließend erfolgt eine Abgabe der Schnappschüsse SN an den Datensammlungsmaster DCM mit OTA-Weiterleitung an das Datensammelsystem GDC und die Datensammeleinrichtung DL, oder die Schnappschüsse SN werden über die Diagnoseschnittstelle des Fahrzeugs beziehungsweise den Fahrzeugdiagnoseservice VDS ausgelesen.
-
Die Weiterleitung der Logdaten erfolgt in einem vorzugsweise einheitlich standardisierten Format. Eine mögliche Spezifikation des Formats kann z.B. Teil des „AUTOSAR“-Standards werden.
-
Optional kann eine Filterung und Vorverarbeitung in den Loggingkonzentratoren beziehungsweise Konzentratoreinrichtungen VLK und BLK erfolgen. Die Einführung der „Zwischensammelpunkte“ VLK und BLK in der Sammelkaskade ermöglicht durch Aggregation und Zwischenspeicherung der Logdaten (= „Flight Recorder“-Funktionalität) Vorverarbeitungen (z.B. Voranalysen, erweiterte Filterungsmöglichkeiten, Datenkompression et cetera) bereits im Fahrzeug („IOT Edge Computing“).
-
Die auszuführenden Vorverarbeitungsanweisungen werden beispielsweise in Form von Skripten als Teil der Kampagnendaten eingebracht. Als Skript-Sprache kann z.B. LUA verwendet werden.
-
Optional kann weiterhin eine spezielle Triggerung der Schnappschüsse vom Ringpuffer FR erfolgen. Durch die Logdaten-Aggregation in einem oder mehreren Ringpuffern (mindestens einer pro Kampagne und ihrer Filterkonfigurationen) und deren Speicherung als Schnappschuss-Dateien, wenn die in der Kampagne definierten Triggerbedingungen erfüllt sind, kann auch die Historie von Lognachrichten bis zu einem bestimmten Ereignis (z.B. Auftreten eines Fehlers) festgehalten werden. So können beispielsweise immer die letzten zwei Minuten an Lognachrichten im Ringpuffer gespeichert sein und bei Bedarf abgerufen werden.
-
Triggerbedingungen können sein:
- - Der Erhalt einer (bestimmten) Lognachricht auf einem (bestimmten) Logkanal.
- - Eine konfigurierbare Boole'sche Verknüpfung mehrerer Filterbedingungen, die auf die im Ringpuffer FR ankommenden Logdaten angewendet werden.
- - Ein Ergebnis einer Vorverarbeitung per Skript. Dies ermöglicht z.B. auf Statistiken oder Voranalysen der im Ringpuffer FR ankommenden Logdaten basierende Triggerungen.
- - „Manuelle Trigger“: Hierbei handelt es sich um einen expliziten Methodenaufruf am Ringpuffer FR (z.B. durch andere Services im Fahrzeug), der die Speicherung des aktuellen Ringpuffer-Inhalts als Schnappschuss auslöst.
-
Die Speicherung der Logdaten in den Schnappschüssen erfolgt wiederum vorzugsweise in einem einheitlich standardisierten Format, das wiederum Teil des AUTOSAR-Standards sein kann.
-
Durch die optionale Verwendung eines Datensammelsystems GDC für eine ganze Fahrzeugflotte können die Kampagnen entsprechend auf Fahrzeugflotten ausgeweitet werden, um damit auch beispielsweise Analyseverfahren, die auf Maschinenlernen basieren, zum Einsatz bringen zu können (z.B. automatische Fehlermustererkennung, Korrelation mit Umweltereignissen et cetera). Derartige Analysen können in einem großen Datenanalysesystem BDAS durchgeführt werden, welches beispielsweise mehrere Datenanalyseservices DAS1 ... DASn (allg. DAS) aufweist. Das Datenanalysesystem BDAS kann hierzu auf die Loggingdateien der zentralen Datensammeleinrichtung DL zugreifen. Von den entsprechenden Analysesystemen können Kunden KD, Vertrieb VT und Qualitätssicherung QS profitieren.
-
In speziellen Ausführungsbeispielen kann vorgesehen sein, dass die zentrale Auswertbarkeit der Lognachrichten aus den verteilten Quellen durch Vorgabe eines zeitsynchronisierten Zeitstempels (synchronisierte Zeitreferenz SRZ) und einer eindeutigen Kennzeichnung von Lognachrichten mit einer Quell-UUID sichergestellt werden. Vorteilhaft kann ferner sein, die Filterung zusätzlich durch die Anwendung eines Datenschutz-Attributs in den Logdaten zu beeinflussen. Ferner kann eine Auswahl von zwischen den Konzentrationspunkten anzuwendenden Cyber-Security-Verfahren durch die Anwendung eines Sicherheits-Attributs in den Logdaten ermöglicht werden. Bei einer weiteren vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens beziehungsweise Systems kann eine automatische beziehungsweise dynamische Anpassung von Logdatenfiltern erfolgen. Weitere Vorteile können bei der Verwendung eines kanonischen Datenlog- und Konfigurationsdaten-Übertragungsformats beziehungsweise -protokolls erzielt werden.
-
Wie eingangs erwähnt wurde, waren die Steuergeräte in einem Fahrzeug bislang in Bezug auf die Datenkommunikation im übertragenen Sinne Inseln. Eine Datenkommunikation zwischen ihnen war nicht nötig/möglich. Mit dem Bedarf, Daten zentral einzusammeln und zu verarbeiten, ändert sich diese Situation. Hierzu ist es notwendig, dass die Filterkonfigurationen stromaufwärts beispielsweise von einer Datenquelle beziehungsweise einem Steuergerät lesbar beziehungsweise verarbeitbar sind. Umgekehrt ist es auch notwendig, dass beispielsweise ein zentrales Steuergerät die Lognachrichten einer Datenquelle beziehungsweise eines Steuergeräts lesen und verarbeiten kann.
-
In einem Ausführungsbeispiel der vorliegenden Erfindung wird daher eine Konvertierung von protokollspezifischen Filterkonfigurations- und Lognachrichten in Bezug auf ihre Formate durchgeführt. So wird beispielsweise eine steuergerätespezifische beziehungsweise protokollspezifische Filterkonfigurations- oder Lognachricht in ein kanonisches Datenübertragungsformat konvertiert. Umgekehrt kann auch eine Filterkonfigurations- oder Lognachricht aus einem kanonischen Datenübertragungsformat in ein spezifisches beziehungsweise proprietäres Format konvertiert werden. Für die Konvertierung können spezielle Adapter AD (monodirektional oder bidirektional) vorgesehen sein (vergleiche Figur). Es genügt, wenn ein derartiger Adapter in einer Datenverbindung zwischen zwei Steuergeräten beziehungsweise deren Komponenten vorhanden ist. In dem Beispiel der Figur ist in der Datenverbindung zwischen dem Logging-Konzentrator VLK-1 der Steuergeräte-Softwarepartition SGP-1 und dem Logging-Konzentrator VLK-Z des Zentralsteuergeräts Z zur Darstellung der Variantenvielfalt sowohl in der Steuergeräte-Softwarepartition SGP-1 als auch in dem Steuergerät Z jeweils ein bidirektionaler Adapter AD eingezeichnet. Tatsächlich notwendig ist aber nur einer von beiden Adaptern AD. Er nimmt die notwendige Konvertierung zwischen den beiden Nachrichtenformaten der Steuergeräte-Softwarepartition SGP-1 und dem Zentralsteuergerät Z vor. Insbesondere kann er in der Lage sein, sowohl die Filterkonfigurationsnachrichten als auch die Lognachrichten entsprechend zu konvertieren.
-
In einer alternativen Ausführungsform kann auch vorgesehen sein, dass ein monodirektionaler Adapter nur die Filterkonfigurationsnachrichten und ein anderer monodirektionaler Adapter nur die Lognachrichten konvertieren kann. Die beiden Einzeladapter wären dann voneinander unabhängig beziehungsweise getrennt. Gegebenenfalls könnten die Einzeladapter auch lokal voneinander getrennt sein, z.B. ein Einzeladapter in der Steuergeräte-Softwarepartition SGP-1 und der andere Einzeladapter in dem Zentralsteuergerät Z.
-
Falls die Steuergeräte in einem Fahrzeug beispielsweise alle das gleiche Datenübertragungsformat verwenden, ist kein derartiger Adapter notwendig. Falls zwei miteinander kommunizierende Steuergeräte das gleiche Datenübertragungsformat verwenden, ist zwischen ihnen kein Adapter AD notwendig.
-
Der Übersicht halber sind in der Figur lediglich Adapter AD zwischen der Steuergeräte-Softwarepartition SGP-1 und dem Zentralsteuergerät Z eingezeichnet. Derartige Adapter können aber auch bei anderen oder allen Datenverbindungen notwendig sein, bei denen Filterkonfigurationsnachrichten stromaufwärts und Lognachrichten stromabwärts übertragen werden. Insbesondere können solche Adapter auch im Backend BE oder auch an der Schnittstelle vom Backend BE zu einem Endgerät SP (z.B. Smartphone) vorgesehen sein.
-
In einem konkreten Ausführungsbeispiel kann ein kanonisches beziehungsweise Standard-Datenübertragungsformat mit einheitlicher Spezifikation von Lognachrichten und/oder Filterkonfigurationsnachrichten zur Übertragung von Filterkonfigurationsdaten definiert werden. Dieses Format kann beispielsweise den oben genannten Anforderungen genügen.
-
Ein entsprechender Adapter kann dann die folgenden Funktionen aufweisen:
- - Umsetzung der Filterkonfigurationen aus einem kanonischen Datenformat in ein spezifisches Zielformat beziehungsweise Protokoll, z.B. ein Protokoll gemäß dem Standard „AUTOSAR/GENIVI DLT“, eSolutions-Protokoll, TTTech Motionwise, et cetera.
- - Umsetzung der Lognachrichten von einem spezifischen Format beziehungsweise Protokoll in das kanonische Datenformat
- - Ergänzung/Konvertierung von im Ausgangsformat fehlenden/abweichenden Informationen (Zeitstempel, Datenschutzstufe, Sicherheitsstufe, UUID, et cetera). Gegebenenfalls kann auch für die Konvertierung eine Entfernung der genannten Informationen notwendig sein.
-
In einem speziellen Ausführungsbeispiel können die Kommunikationspartner eine unterschiedliche Anzahl an Loglevel verarbeiten. Beispielsweise kennt die Datenquelle drei Stufen von Loglevel, während das Zentralsteuergerät fünf Loglevel-Stufen kennt. Bei der Übertragung der Lognahrichten stromabwärts von der Quelle zum Zentralsteuergerät muss dann ein Adapter die drei Stufen in fünf Stufen konvertieren.
-
In einem anderen Beispiel fügt die Datenquelle in eine Lognachricht als Attribut eine Datenschutzstufe ein. Das Zentralsteuergerät kann aber Datenschutzstufen beispielsweise nicht verarbeiten. In diesem Fall entfernt ein Adapter die Datenschutzstufe. Umgekehrt, wenn die Datenquelle kein Datenschutz-Attribut einfügt, das Zentralsteuergerät jedoch eine benötigt, kann der Adapter eine solche Datenschutzstufe entsprechend einer vorgegebenen Vorschrift einfügen.
-
In einem weiteren Beispiel liefert ein Steuergerät immer Lognachrichten von zwei Kanälen, nämlich Temperatur und Geschwindigkeit. Für eine Logging-Kampagne ist aber nur die Temperatur von Interesse. Die Geschwindigkeitsdaten werden ausgefiltert. Das Steuergerät beziehungsweise die Datenquelle kann aber das Attribut „Temperatur“ nicht den Lognachrichten hinzufügen. Diese Aufgabe kann nun ein Adapter übernehmen, der die temperaturbezogenen Lognachrichten entsprechend ergänzt.
-
In einer weiteren Ausführungsform kann ein Adapter dazu geeignet sein, mehrere Formate in ein Zielformat zu konvertieren. In diesem Fall genügt es, am Zentralsteuergerät einen Adapter vorzusehen, der mehrere proprietäre Formate von verschiedenen Steuergeräten entsprechend konvertiert.
-
Erfindungsgemäß kann somit der Vorteil erzielt werden, dass eine vereinheitlichte Umsetzung der Logdatensammelkette ab dem Adapter beziehungsweise den Adaptern sowie eine gemeinsame Auswertbarkeit ermöglicht wird.
-
Bezugszeichenliste
-
- AD
- Adapter
- BDAS
- großes Datenanalysesystem
- BE
- Backend
- BES
- Cloud-Backend-System
- BLK
- Loggingkonzentrator
- CL
- Cloud
- CS
- Cloud-Service
- DAS
- Datenanalyseservice
- DCM
- Datensammlungsmaster
- DCOM
- Datensammlung-Auftragsverwaltung
- DL
- Datensammeleinrichtung
- DP
- Datenpumpe
- EW
- Entwickler
- FR
- Ringpuffer
- FZ
- Fahrzeug
- GDC
- Datensammelsystem für Fahrzeugflotte
- IOT
- Internet of Things
- KD
- Kundendienst
- KE
- Kampagnenersteller
- LMS
- Logging-Management-System
- LN
- Lokales Netz
- OTA
- Drahtlosverbindung
- PS
- Produktionssystem
- Q1-1 ...Qm-n
- Quellenindex
- QS
- Qualitätssicherung
- QZ-1 ...QZ-n
- Quellenindex
- RZ
- Referenzzeit
- SGP
- Steuergerät-Softwarepartition
- SN
- Schnappschuss
- SRZ
- synchronisierte Zeitreferenz
- SWC
- Softwarekomponente
- VDS
- Fahrzeugdiagnoseservice
- VLK
- Loggingkonzentrator
- VT
- Vertrieb
- Z
- Zentralsteuergerät
- ZZ
- Zentrale Zeitbasis
-
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 Patentliteratur
-
- DE 102015222179 A1 [0004]
- DE 10140519 A1 [0005]
- US 20140005880 A1 [0006]
- US 20190052522 A1 [0007]
- US 20110130916 A1 [0008]
- DE 102020208147 A1 [0009]
