DE102022113104A1 - Eindeutige Identitätskennung für Lognachrichtenquellen in Fahrzeugen - Google Patents

Abstract

Lognachrichten von Fahrzeugen sollen auf einfache Weise erzeugbar sein und einer Datenquelle eindeutig zugeordnet werden können. Dazu wird ein Datensystem und ein Verfahren zum Erzeugen einer Lognachricht in einem Fahrzeug (FZ), das einer Fahrzeughierarchieebene zugeordnet wird, bereitgestellt. Die Lognachricht wird durch eine Quelleinheit des Fahrzeugs (FZ) die nach einer vorgegebenen Ordnung auf einer Quellhierarchieebene unter der Fahrzeughierarchieebene liegt, erzeugt (S3). Die Lognachricht weist ein Attribut auf. Diesem wird eine bezüglich einer Identität der Quelleinheit eindeutige Identitätskennung zugeordnet (S5). Die Identitätskennung weist eine hierarchische Abfolge von Namen derjeniger Einheiten des Fahrzeugs (FZ) auf, denen die Quelleinheit auf allen Hierarchieebenen der vorgegebenen Ordnung untergeordnet ist, angefangen von einem Namen des Fahrzeugs auf der Fahrzeughierarchieebene bis zu einem Namen der Quelleinheit auf der Quellhierarchieebene.

Description

• Die vorliegende Erfindung betrifft ein Verfahren zum Erzeugen einer Lognachricht in einem Fahrzeug. Darüber hinaus betrifft die vorliegende Erfindung ein Verfahren zum Sammeln von Lognachrichten in einem Datensystem für Fahrzeuge. Ferner betrifft die vorliegende Erfindung ein entsprechendes Datensystem sowie ein Computerprogramm und ein 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.
• Die Druckschrift US 2019/0238587 A1 offenbart ein Verfahren zum Authentifizieren einer Quelle eines Kommunikationssignals, das über einen Netzwerk-BUS übertragen wird. Eine Vorlage wird verwendet, um für jede Nachricht eine Quellkennung zu berechnen.
• Des Weiteren offenbart die Druckschrift IN 2018 410 46 001 A ein Verfahren zum Identifizieren eines oder mehrerer eindeutiger Nutzer von mehreren Datenquellen. Hierzu wird eine Vielzahl von Profildaten von Nutzern in dem System verwendet.
• Zudem beschreibt die Druckschrift DE 10 2018 220 990 A1 ein Verfahren zur Adressierung von Teilnehmern bei einer Kommunikation mit einem Backendserver, bei dem auf einer Fahrzeugidentifikationsnummer und einer Diagnoseadresse basierende namensbasierte UUIDs verwendet werden.
• Die Druckschrift US 2002/018 42 30 A1 offenbart ein Verfahren zur Adressierung von Einträgen in einem Verzeichnisserver, bei dem namensbasierte UUIDs verwendet werden.
• Außerdem offenbart die Druckschrift US 2018/0189328 A1 ein Verfahren zur Datenverwaltung, bei dem UUIDs verwendet werden und bei dem eine UUIDselektive Protokollierung von Daten durchgeführt werden kann.
• Ferner offenbart die Druckschrift US 8 180 814 B1 ein Verfahren zur Dateiverwaltung, bei dem namensbasierte UUIDs verwendet werden können.
• Die Aufgabe der vorliegenden Erfindung besteht darin, Quellen von Lognachrichten auf einfache Weise eindeutig voneinander unterscheiden zu können, um die Lognachrichten den jeweiligen Quellen eindeutig zuordnen zu können.
• Entsprechend der vorliegenden Erfindung wird dazu ein Verfahren zum Erzeugen einer Lognachricht in einem Fahrzeug bereitgestellt, das eine Einheit in einer Fahrzeughierarchieebene darstellt. Lognachrichten sind essentiell bei der Fehlersuche in Fahrzeugen beziehungsweise Fahrzeugsystemen. Mit den Lognachrichten übermitteln die einzelnen Datenquellen ihren jeweiligen Status oder entsprechende kontextbezogene Daten an eine Datensammeleinrichtung. Die gesammelten Lognachrichten können analysiert werden, um Zustände oder Fehler von Fahrzeugen zu ermitteln.
• Die Lognachricht wird hier in einem Fahrzeug erzeugt, das einer Fahrzeughierarchieebene zugeordnet wird. Die Handhabung der Lognachrichten erfolgt also in einem Hierarchieraum.
• In einem ersten Schritt des erfindungsgemäßen Verfahrens wird die Lognachricht durch eine Quelleinheit des Fahrzeugs erzeugt. Diese Quelleinheit liegt nach einer vorgegebenen Ordnung auf einer Quellhierarchieebene unter der Fahrzeughierarchieebene. Dies bedeutet, dass der angesprochene Hierarchieraum mehrere Hierarchieebenen besitzt, darunter die Fahrzeughierarchieebene und die Quellhierarchieebene. Zwischen den letztgenannten Hierarchieebenen können sich eine oder mehrere weitere Hierarchieebenen befinden. Die von der Quelleinheit erzeugte Lognachricht weist ein Attribut auf. Generell können Lognachrichten unterschiedliche Formate besitzen. In der Regel weisen sie einen Nachrichteninhalt und gegebenenfalls ein oder mehrere Attribute auf. Attribute können Verarbeitungshinweise enthalten, beispielsweise in Bezug auf Sicherheit, Datenschutz und dergleichen. Speziell kann ein Attribut aber auch eine Identifikationskennung für eine Lognachrichtenquelle (z. B. einer von mehreren Logkanälen einer Datenquelle) darstellen. Ferner kann ein Attribut auch eine Kritikalitätsstufe in Bezug auf Fehler, eine Loging-Kategorie in Bezug auf die Ausführlichkeit der Lognachricht oder einen Zeitstempel betreffen.
• In einem weiteren Schritt des erfindungsgemäßen Verfahrens erfolgt ein Zuordnen einer bezüglich einer Identität der Quelleinheit eindeutigen Identitätskennung zu dem Attribut der Lognachricht. Es wird der Lognachricht also automatisch in einem Attributfeld eine Identitätskennung, die eine zweifelsfreie Zuordnung zu einer Quelleinheit beziehungsweise Datenquelle ermöglicht, zugeordnet.
• Die Identitätskennung weist eine hierarchische Abfolge von Namen derjeniger Einheiten des Fahrzeugs auf, denen die Quelleinheit auf allen Hierarchieebenen der vorgegebenen Ordnung (direkt) untergeordnet ist, angefangen von einem Namen des Fahrzeugs auf der Fahrzeughierarchieebene bis zu einem Namen der Quelleinheit auf der Quellhierarchieebene. Somit entsteht eine Kette von Namen, die jeweils eine einzig Einheit in jeder Hierarchieebene repräsentieren. Die Identitätskennung besteht also beispielsweise aus einem Textstring mit mehreren aneinander geordneten Namen. Jeder der Namen bezieht sich auf eine Hierarchieebene. Die Namen sind beispielsweise in der Reihenfolge der vorliegenden Hierarchie absteigend oder aufsteigend angeordnet. Beispielsweise stellt die Quelleinheit eine Instanz einer spezifischen Software-Komponente dar. Die Quellhierarchieebene entspricht hier einer Instanzebene, die die niedrigste Hierarchieebene verkörpert. Da die Instanz Teil der spezifischen Software-Komponente ist, ist die Software-Komponente einer höheren Hierarchieebene, z. B. der Software-Komponentenhierarchieebene, zuzuordnen. Die Software-Komponente kann wiederum Teil einer Software-Partition sein, welche wiederum die Partitionshierarchieebene verkörpert. Die Partition ihrerseits kann Teil eines elektronischen Steuergeräts des Fahrzeugs sein, so dass sich die Steuergerätehierarchieebene über der Partitionsebene befindet. Über letzterer kann die Fahrzeughierarchieebene angeordnet sein, was letztlich bedeutet, dass das Steuergerät Teil des Fahrzeugs ist. In der Hierarchie müssen nicht alle Hierarchieebenen realisiert sein. Darüber hinaus können die Hierarchieebenen auch andere Klassen von Einheiten betreffen. Jede verwendete Hierarchieebene wird in der Identitätskennung mit einem eigenen Namen repräsentiert. Eine solche namensbasierte Identitätskennung einer Quelleinheit in der Lognachricht kann also beispielsweise lauten:
• Fahrzeugname/Steuergerätname/Partitionsname/Software-Komponentenname/Instanzname.
• In einem speziellen Ausführungsbeispiel ist vorgesehen, dass die Identitätskennung als ersten Namen einen Markennamen erhält, der in einer Hierarchieebene der vorgegebenen Ordnung über der Fahrzeughierarchieebene angeordnet ist, wobei das Fahrzeug einer Fahrzeugmarke mit dem Markennamen zugeordnet ist. Ist der Markenname des Fahrzeugs beispielsweise „Porsche“, so ist dieser Name „Porsche“ der erste Name in der Identitätskennung. Danach kann der Name des Fahrzeugs beziehungsweise der Name für das Fahrzeugmodell folgen, wie etwa „po426“. Eine mit einer derartigen Identitätskennung versehene Lognachricht stammt also von einer Quelleinheit beziehungsweise Datenquelle eines Fahrzeugs der Marke Porsche und dem Modelltyp „po426“. Optional kann dem Markennamen eine Bezeichnung einer Verzeichniswurzel, z.B. „tIr“ vorangestellt werden.
• Bei einem weiteren Ausführungsbeispiel des erfindungsgemäßen Verfahrens kann nach der Fahrzeughierarchieebene und vor der Quellhierarchieebene in der vorgegebenen Ordnung mindestens eine Hierarchieebene für Steuergeräte, Software-Partitionen oder Software-Komponenten vorgesehen sein. Wie oben bereits angedeutet wurde, kann die Anzahl der Hierarchieebenen zwischen Fahrzeughierarchieebene und Quellhierarchieebene unterschiedlich sein. In dem vorliegenden Beispiel liegt mindestens eine Hierarchieebene zwischen der Fahrzeughierarchieebene und der Quellhierarchieebene. Diese eine Hierarchieebene bezieht sich beispielsweise auf die Klasse der Steuergeräte, der Software-Partitionen oder der Software-Komponenten. Gegebenenfalls befinden sich auch zwei (oder mehrere) Hierarchieebenen zwischen der Fahrzeughierarchieebene und der Quellhierarchieebene. Diese zwei Hierarchieebenen beziehen sich dann beispielsweise auf zwei der Elemente: Steuergeräte, Software-Partitionen und Software-Komponenten. Optional können auch für all die genannten Elemente jeweilige Hierarchieebenen vorgesehen sein.
• In einer speziellen Ausgestaltung des Verfahrens wird die eindeutige Identitätskennung entsprechend dem Standard RFC4122 erzeugt. Der Algorithmus zur Generierung der eindeutigen Identitätskennung (UUID: Universal Unique Identifier) sollte auf SHA-1-Hashwerten beruhen (Version 5UUID).
• In einem weiteren Ausführungsbeispiel kann vorgesehen sein, dass für die Erzeugung der eindeutigen Identitätskennung die Codierung UTF-8 verwendet wird. Dieses 8-Bit-UCS-Transformationsformat ist für die Codierung von Unicode-Zeichen geeignet.
• Entsprechend der vorliegenden Erfindung kann auch ein Verfahren zum Sammeln von Lognachrichten in einem Datensystem für Fahrzeuge bereitgestellt werden, das die folgenden Schritte aufweist:
• - Erstellen einer Logging-Kampagne, die mindestens eine Filterkonfigurationsnachricht aufweist,
• - automatisches Übertragen der Filterkonfigurationsnachricht an eine Datenquelle des Datensystems, wobei die Filterkonfigurationsnachricht eine Zuordnungsvorschrift zum Zuordnen einer Identitätskennung zu dem Attribut einer Lognachricht der Datenquelle aufweist, und
• - Durchführen eines Verfahrens zum Erzeugen der Lognachricht, wie es oben beschrieben wurde.
• Das Auszeichnen von Lognachrichten mit einer eindeutigen Identitätskennung für die Datenquelle beziehungsweise eine Quelleinheit, die Teil der Datenquelle sein kann, kann also auch vorteilhaft beim Sammeln von Lognachrichten mittels einer Logging-Kampagne verwendet werden. Auf diese Weise kann beispielsweise auch beim Sammeln von Lognachrichten mittels Logging-Kampagnen eine eindeutige Zuordnung jeder Lognachricht zu ihrer spezifischen Quelle auch nachträglich gewährleistet werden. Dabei wird beispielsweise von einer Managementeinrichtung in einem Cloud-basierten Backend eine Logging-Kampagne erstellt, welche mindestens eine Filterkonfiguration beziehungsweise Filterkonfigurationsnachricht beinhaltet. Eine solche Filterkonfiguration kann in einer Filterkonfigurationsnachricht von der Managementeinrichtung stromaufwärts (entgegen dem Loging-Nachrichtenstrom) zu den Datenquellen übermittelt werden. In der jeweiligen Datenquelle wird die Filterkonfiguration dazu genutzt, die darin enthaltene Zuordnungsvorschrift in Bezug auf das Zuordnen einer Identitätskennung als Attribut zu einer Lognachricht zu implementieren. Somit kann jeder Lognachricht eine eindeutige namensbasierte Identitätskennung zugeordnet werden. Folglich kann jederzeit auch nach dem Sammeln der Lognachrichten der Ursprung jeder Lognachricht ermittelt werden.
• Wie bereits angedeutet wurde, können die Lognachrichten von mehreren Datenquellen entsprechend einem Verfahren, wie es oben dargestellt wurde, erzeugt und in einer Datensammeleinrichtung zentral gesammelt werden. Die Lognachrichten sind dann stets individuell ihren ursprünglichen Datenquellen eindeutig zuordenbar. Eine Auswertung der Lognachrichten kann also unter Berücksichtigung der jeweiligen Identitätskennung erfolgen.
• Die oben geschilderte Aufgabe wird erfindungsgemäß auch gelöst durch ein Datensystem aufweisend mindestens ein Fahrzeug (FZ) mit mindestens einer Datenquelle (SWC, CS, SP) (Quelleinheit ist Teil der Datenquelle) zum Erzeugen einer Lognachricht, wobei die mindestens eine Datenquelle (SWC, CS, SP) eine Steuereinrichtung aufweist, mit der eine Identitätskennung dem Attribut der Lognachricht zuordenbar ist, so dass mit dem Datensystem ein Verfahren nach einem der vorhergehenden Ansprüche durchführbar ist.
• Das Datensystem kann eine Datenverarbeitungsvorrichtung oder eine Prozessoreinrichtung aufweisen, die dazu eingerichtet ist, eine Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Die Prozessoreinrichtung kann hierzu zumindest einen Mikroprozessor und/oder zumindest einen Mikrocontroller und/oder zumindest einen FPGA (Field Programmable Gate Array) und/oder zumindest einen DSP (Digital Signal Processor) aufweisen. Des Weiteren kann die Prozessoreinrichtung Programmcode aufweisen, der dazu eingerichtet ist, bei Ausführen durch die Prozessoreinrichtung die Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen. Der Programmcode kann in einem Datenspeicher der Prozessoreinrichtung gespeichert sein.
• Die oben im Zusammenhang mit dem erfindungsgemäßen Verfahren geschilderten Vorteile und Weiterbildungen gelten sinngemäß auch für das erfindungsgemäße Datensystem. Die geschilderten Verfahrensschritte stellen in diesem Fall entsprechende funktionale Merkmale der jeweiligen Mittel des Datensystems dar.
• Erfindungsgemäß wird auch ein Computerprogramm bereitgestellt, das Befehle umfasst, die bei der Ausführung des Programms durch eine Steuervorrichtung eines Datensystems nach oben genannter Art dieses veranlassen, ein ebenfalls oben geschildertes Verfahren auszuführen. In gleicher Weise kann ein computerlesbares Speichermedium bereitgestellt werden, das Befehle umfasst, die bei der Ausführung durch eine Steuervorrichtung eines Datensystems nach obiger Art dieses veranlassen, ein Verfahren, wie es oben geschildert wurde, auszuführen. Das Speichermedium kann z.B. zumindest teilweise als ein nichtflüchtiger Datenspeicher (z.B. als ein Flash-Speicher und/oder als SSD - solid state drive) und/oder zumindest teilweise als ein flüchtiger Datenspeicher (z.B. als ein RAM - random access memory) ausgestaltet sein. Das Speichermedium kann in der Prozessorschaltung in deren Datenspeicher realisiert sein. Das Speichermedium kann aber auch beispielsweise als sogenannter Appstore-Server im Internet betrieben sein. Durch den Computer oder Computerverbund kann eine Prozessorschaltung mit zumindest einem Mikroprozessor bereitgestellt sein. Die Befehle können als Binärcode oder Assembler und/oder als Quellcode einer Programmiersprache (z.B. C) bereitgestellt sein.
• Für Anwendungsfälle oder Anwendungssituationen, die sich bei dem Verfahren ergeben können und die hier nicht explizit beschrieben sind, kann vorgesehen sein, dass gemäß dem Verfahren eine Fehlermeldung und/oder eine Aufforderung zur Eingabe einer Nutzerrückmeldung ausgegeben und/oder eine Standardeinstellung und/oder ein vorbestimmter Initialzustand eingestellt wird.
• Die Erfindung umfasst auch die Kombinationen der Merkmale der beschriebenen Ausführungsformen.
• Im Folgenden werden Ausführungsbeispiele der Erfindung beschrieben. Hierzu zeigt:
• 1 ein Ausführungsbeispiel eines erfindungsgemäßen Verfahrens zum Sammeln von Daten mehrerer Datenquellen in einem Ablaufdiagramm; und
• 2 ein schematisches Blockdiagramm zum Ablauf eines Ausführungsbeispiels eines erfindungsgemäßen Verfahrens zum Erzeugen einer Lognachricht.
• Dabei können die einzelnen Blöcke auch als entsprechende Hardware-Komponenten eines Systems zum Sammeln von Daten gesehen werden.
• 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 Problematik, auf der die vorliegende Erfindung beruht, besteht darin, dass Quellen von Lognachrichten (z. B. Software-Komponenten beziehungsweise spezifische „Logkanäle“ dieser Software-Komponenten) global eindeutig unterschieden werden sollten, um die Lognachrichten diesen Quellen eindeutig zuordnen zu können. Bislang wurden hier UUIDs verwendet und es bedurfte einer Registrierungsstelle oder -datenbank, in der eine Zuordnung zwischen Quelle und UUID hinterlegt ist. Der erfindungsgemäße Lösungsansatz besteht darin, UUIDs für Lognachrichtenquellen ohne Notwendigkeit einer zentralen Registrierungsstelle/-datenbank vergeben zu können. Jede Lognachricht trägt demnach die jeweilige Quellen-UUID als Attribut, mit der ihre eindeutige Herkunft (Software-Komponente beziehungsweise spezifischer Logkanal) bestimmt werden kann.
• 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 CloudServices 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 LogdatenQuellen („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 Logging-Konzentratoren 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.
• Entsprechend dem erfindungsgemäßen Lösungsansatz kann ein spezifisches Namensschema als Eingabe für den Algorithmus zur Bildung von namensbasierten UUIDs beispielsweise gemäß dem Standard RFC4122 verwendet werden, bei dem die textuelle Bezeichnung der Quelle als Teil des Namens genutzt wird.
• Die eindeutigen Identitätskennungen beziehungsweise UUIDs der Lognachrichten sind also namensbasiert, um ihr Erstellen ohne die Notwendigkeit einer zentralisierten UUID-Registrierung zu ermöglichen. Die Namen, die im Algorithmus zum Erstellen von namensbasierten UUIDs beispielsweise gemäß dem Standard RFC4122 verwendet werden sollen, folgen z.B. diesem Schema für marken- und fahrzeugspezifische Namensräume:
• Marke/Fahrzeugmodell/Steuergerät/Software-Partition/Software-Komponente/Instanz
• All diese Namen betreffend die Marke, das Fahrzeugmodell, etc., repräsentieren jeweils eine eigene Hierarchieebene. Entsprechend ergeben sich eine Markenhierarchieebene, eine Fahrzeughierarchieebene, eine Steuerhierarchieebene, eine Partitionshierarchieebene, eine Software-Komponenten-Hierarchieebene und eine Instanzhierarchieebene. Diese Hierarchieebenen sind entsprechend hierarchisch geordnet. Die gesamte eindeutige Identitätskennung der Quelleinheit ergibt sich also aus einer Aneinanderreihung von je einem Namen beispielsweise aus jeder gewählten der genannten Hierarchieebenen.
• Beispielsweise kann der Name der Marke lauten: VW, Audi, Porsche, Bentley, VW-Nutzfahrzeug, Lamborghini, Bugatti, Ducati, Scania, Skoda, Seat oder MAN.
• Der Name für das Fahrzeugmodell kann beispielsweise eine markenspezifische Modelllinie wie „po426“ für ein spezifisches Porsche-Modell sein.
• Der Name für das Steuergerät kann beispielsweise ein eindeutiger Name einer spezifischen Steuergeräteinstanz bei einer speziellen Fahrzeugmodellarchitektur sein, wie etwa „hcp1“, „conmod“, etc..
• Der Name für eine Partition kann ein eindeutiger Name einer spezifischen Software-Partition innerhalb des speziellen Steuergeräts sein, z. B. „e3-sw-pac-aar“ für eine E³-Softwareplattform basierend auf der Architektur AUTOSAR.
• Der Name für die Software-Komponente kann ein eindeutiger Name einer spezifischen Software-Komponente innerhalb der spezifischen Software-Partition sein, etwa für einen Applikationsprozess und dergleichen, z. B. „tlrlocalserver“.
• Der Name für die Instanz kann ein eindeutiger Name einer spezifischen aber festen Instanz der Software-Komponente sein, z. B. „1“, „2“, „3“, etc.. In dynamischen Umgebungen, in denen die Anzahl der möglichen Instanzen nicht im Voraus bekannt ist, kann die Instanz weggelassen oder auf einen Platzhalter „*“ gesetzt werden.
• Namen eines Namenraums (z. B. Fahrzeugmodellreihe einer Marke) sollten konsequent verwendet werden, damit unabhängige Berechnungen der entsprechenden UUIDs stets das gleiche Ergebnis liefern. Es liegt in der Verantwortung des einzelnen Fahrzeugprojekts, die Regeln seines jeweiligen Namensraums zu spezifizieren und die Zuweisung von Namen zu UUIDs zu dokumentieren. Ein konkretes Beispiel für eine namensbasierte Identitätskennung für eine TLRLocalServer-lnstanz in einer E³-Software-Plattformpartition, basierend auf AUTOSAR-Adaptive, in einem HCP5-Steuergerät eines auf E³ 1.2-architekturbasierenden Porsche-Fahrzeugs (PO426) kann folgendermaßen aussehen:
• tlr://porsche/po426/hcp5/e3-sw-pac-aar/tlrlocalserver/1.
• 2 zeigt in einem Blockdiagramm ein Ausführungsbeispiel eines erfindungsgemäßen Verfahrens, bei dem exemplarisch im Rahmen einer Logging-Kampagne Lognachrichten mit namensbasierten Identitätskennungen erstellt werden. In einem ersten Schritt S1 erfolgt das Erstellen einer Logging-Kampagne, die mindestens eine Filterkonfigurationsnachricht aufweist. Diese Logging-Kampagne wird beispielsweise an zentraler Stelle erstellt und an eine Vielzahl an Fahrzeugen einer Fahrzeugflotte gemäß Schritt S2 übertragen. Hierzu wird die in Schritt S1 erzeugte Filterkonfiguration an die jeweilige Datenquelle beziehungsweise Quelleinheit übertragen.
• Die Quelleinheit des jeweiligen Fahrzeugs erzeugt in einem Schritt S3 eine Lognachricht. Nach einer vorgegebenen Ordnung liegt das Fahrzeug in einer Fahrzeughierarchieebene und die Quelleinheit in einer Quellhierarchieebene unterhalb der Fahrzeughierarchieebene. Außerdem weist die Lognachricht ein Attribut auf. Die Lognachricht kann auch mehrere Attribute aufweisen, die mit Werten in Bezug auf die Identität der Quelle, den Datenschutz, die Sicherheit, etc. belegt werden können. Gegebenenfalls trägt somit jede einzelne Lognachricht eine entsprechende Information in Bezug auf die Identität der Quelle, des Datenschutzes, der Sicherheit und dergleichen. Diesen Schritt des Zuordnens einer bezüglich der Identität der Quelleinheit eindeutigen Identitätskennung zu dem Attribut der Lognachricht spiegelt der Schritt S5 in 2 wider. Diesem Schritt S5 geht der Schritt S4 voran, bei dem die namensbasierte Identitätskennung für die jeweilige Lognachricht erzeugt wird. Diese Identitätskennung besteht aus einer hierarchischen Abfolge von Namen all derjeniger Einheiten des Fahrzeugs, denen die Quelleinheit auf allen Hierarchieebenen der vorgegebenen Ordnung untergeordnet ist, angefangen von einem Namen des Fahrzeugs auf der Fahrzeughierarchieebene, bis zu einem Namen der Quelleinheit auf der Quellhierarchieebene. Die Identitätskennung kann auch weitere Namen für dazwischenliegende Ebenen aufweisen. Darüber hinaus kann die Identitätskennung auch jeweils einen Namen für eine oder mehrere Hierarchieebenen über der Fahrzeughierarchieebene aufweisen. Beispielsweise könnte die Identitätskennung vor dem Namen des Fahrzeugs beziehungsweise Fahrzeugmodells einen Markennamen für eine Markenhierarchieebene aufweisen. In dem obigen Beispiel beinhaltet die namensbasierte Identitätskennung den Markennamen „Porsche“ vor dem Fahrzeugmodellnamen „PO426“.
• Die so erstellte Lognachricht mit der namensbasierten Identitätskennung wird optional von der jeweiligen Datenquelle beziehungsweise Quelleinheit zu einer Datensammeleinrichtung gemäß Schritt S6 übertragen. In gleicher Weise werden im Rahmen der Logging-Kampagne auch von anderen Datenquellen Lognachrichten an die Datensammeleinrichtung übertragen.
• In einem weiteren optionalen Schritt S7 werden die in der Datensammeleinrichtung gesammelten Lognachrichten in Abhängigkeit von ihren jeweiligen Identitätskennungen ausgewertet. Sollen beispielsweise innerhalb der Logging-Kampagne Temperaturen einer bestimmten Einheit in jedem Fahrzeug einer Fahrzeugflotte aufgezeichnet werden, und eine Lognachricht spiegelt eine überhöhte Temperatur wider, so kann anhand der namensbasierten Identitätskennung sofort erkannt werden, in welcher Einheit (z. B. Steuergerät, Software-Komponente, Instanz) die überhöhte Temperatur aufgetreten ist. Auch andere Fehler können auf diese Art und Weise exakt geortet werden.
• Der Vorteil der namensbasierten Identitätskennung besteht darin, dass Software-Entwickler beziehungsweise verantwortliche Fachbereiche aufgrund des vorgegebenen Namensschemas konfliktfrei UUIDs selbst vergeben können, indem die Bezeichnung der Quelle als Teil des Namens verwendet wird. Derartige namensbasierte eindeutige Identitätskennungen können auch ohne weiteres in Standards integriert werden.
• Bezugszeichenliste

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

S1 bis S7

Schritte

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
• US 2019/0238587 A1 [0004]
• IN 201841046001 A [0005]
• DE 102018220990 A1 [0006]
• US 2002/0184230 A1 [0007]
• US 2018/0189328 A1 [0008]
• US 8180814 B1 [0009]

Claims (10)

1. Verfahren zum Erzeugen einer Lognachricht in einem Fahrzeug (FZ), das einer Fahrzeughierarchieebene zugeordnet wird, gekennzeichnet durch - Erzeugen (S3) der Lognachricht durch eine Quelleinheit des Fahrzeugs (FZ), die nach einer vorgegeben Ordnung auf einer Quellhierarchieebene unter der Fahrzeughierarchieebene liegt, wobei die Lognachricht ein Attribut aufweist, und - Zuordnen (S5) einer bezüglich einer Identität der Quelleinheit eindeutigen Identitätskennung zu dem Attribut der Lognachricht, wobei - die Identitätskennung eine hierarchische Abfolge von Namen derjeniger Einheiten des Fahrzeugs (FZ) aufweist, denen die Quelleinheit auf allen Hierarchieebenen der vorgegebenen Ordnung untergeordnet ist, angefangen von einem Namen des Fahrzeugs (FZ) auf der Fahrzeughierarchieebene bis zu einem Namen der Quelleinheit auf der Quellhierarchieebene.
2. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Identitätskennung als ersten Namen einen Markennamen erhält, der in einer Hierarchieebene der vorgegebenen Ordnung über der Fahrzeughierarchieebene angeordnet ist, wobei das Fahrzeug (FZ) einer Fahrzeugmarke mit dem Markennamen zugeordnet ist.
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass nach der Fahrzeughierarchieebene und vor der Quellhierarchieebene in der vorgegebenen Ordnung mindestens eine Hierarchieebne für Steuergeräte, Softwarepartitionen oder Softwarekomponenten vorgesehen ist.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die eindeutige Identitätskennung entsprechend dem Standard RFC4122 erzeugt wird.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass für die Erzeugung der eindeutigen Identitätskennung die Kodierung UTF-8 verwendet wird.
6. Verfahren zum Sammeln von Lognachricht in einem Datensystem für Fahrzeuge (FZ), aufweisend die Schritte: - Erstellen (S1) einer Logging-Kampagne, die mindestens eine Filterkonfigurationsnachricht aufweist, - automatisches Übertragen (S2) der Filterkonfigurationsnachricht an eine Datenquelle (SWC, CS, SP) des Datensystems, wobei die Filterkonfigurationsnachricht eine Zuordnungsvorschrift zum Zuordnen (S5) einer Identitätskennung zu dem Attribut einer Lognachricht der Datenquelle (SWC, CS, SP) aufweist, und - Durchführen eines Verfahrens zum Erzeugen der Lognachricht nach einem der vorhergehenden Ansprüche.
7. Verfahren nach Anspruch 6, wobei Lognachrichten von mehreren Datenquellen nach einem der Ansprüche 1 bis 5 erzeugt und in einer Datensammeleinrichtung zentral gesammelt werden.
8. Datensystem aufweisend - mindesten ein Fahrzeug (FZ) mit mindestens einer Datenquelle (SWC, CS, SP) zum Erzeugen (S3) einer Lognachricht, wobei - die mindestens eine Datenquelle (SWC, CS, SP) eine Steuereinrichtung aufweist, mit der eine Identitätskennung dem Attribut der Lognachricht zuordenbar (S5) ist, so dass - mit dem Datensystem ein Verfahren nach einem der vorhergehenden Ansprüche durchführbar ist.
9. Computerprogramm umfassend Befehle, die bei der Ausführung des Programms durch eine Steuervorrichtung eines Datensystems nach Anspruch 8 dieses veranlassen, das Verfahren nach einem der Ansprüche 1 bis 7 auszuführen.
10. Computerlesbares Speichermedium, umfassend Befehle, die bei der Ausführung durch eine Steuervorrichtung eines Datensystems nach Anspruch 8 dieses veranlassen, das Verfahren nach einem der Ansprüche 1 bis 7 auszuführen.

Images