DE102022113111A1 - Übertragen einer Lognachricht mit Sicherheitskennung in einem Datensystem für Fahrzeuge - Google Patents

Abstract

Lognachrichten sollen in einem Datensystem für Fahrzeuge mit hinreichender Sicherheit übertragen werden. Dazu wird ein Verfahren bereitgestellt, bei dem eine Lognachricht von einer Datenquelle (SWC, CS, SP) des Datensystems erzeugt wird (S1), wobei die Lognachricht ein Attribut aufweist. Eine Sicherheitskennung wird dem Attribut der Lognachricht durch die Datenquelle (SWC, CS, SP) zugeordnet (S4). Schließlich erfolgt ein Filtern oder Senden (S6) der Lognachricht in Abhängigkeit von der Sicherheitskennung. Somit können einzelne Lognachrichten mit individuellen Sicherheitskennungen versehen werden.

Description

• Die vorliegende Erfindung betrifft ein Verfahren zum Übertragen einer Lognachricht in einem Datensystem für Fahrzeuge. Darüber hinaus betrifft die vorliegende Erfindung ein Verfahren zum Sammeln von Lognachrichten mittels einer Logging-Kampagne. Ferner betrifft die vorliegende Erfindung ein Datensystem mit mindestens einem Fahrzeug einschließlich mindestens einer Datenquelle zum Erzeugen einer Lognachricht sowie ein entsprechendes 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.
• Aus der Druckschrift US 9 843 594 B1 ist ein Verfahren zum Detektieren anormaler Nachrichten in Automobilnetzwerken bekannt. Falls eine derartige anormale Nachricht detektiert wird, wird eine Sicherheitsmaßnahme in dem Datennetz durchgeführt.
• Die Druckschrift DE 10 2007 058 975 A1 offenbart ein Bordnetz eines Kraftfahrzeugs mit einem Master Security Modul. Das Master Security Modul signiert eine Nachricht und sendet sie an mindestens eines von zwei Steuergeräten über einen Datenbus. Eine Datensicherheitsbewertung einer ersten Teilbotschaft wird mittels einer Auswertung einer zweiten Teilbotschaft durchgeführt. Dadurch ergibt sich der Vorteil, dass ein Datensicherheitszertifikat nicht in jeder der Teilbotschaften einzeln versendet werden muss.
• Darüber hinaus offenbart die Druckschrift US 10 523 679 B2 ein Verfahren beziehungsweise System zur Kommunikation in einem Fahrzeug-zu-Fahrzeug-Netzwerk, bei dem für eine Softwareanwendung mittels elektronischer Zertifikate ein Risikobewertungsattribut bestimmt wird, und bei dem ein Kommunikationsempfänger basierend auf dem Risikobewertungsattribut bestimmt wird.
• Ferner offenbart die Druckschrift US 9 984 522 B2 ein Verfahren zur Fahrzeugidentifizierung oder -authentifizierung, bei dem eine Multifaktorauthentifizierung durchgeführt wird.
• Schließlich beschreibt die Druckschrift EP 3 357 262 B1 ein Kommunikationssystem zur V2X-Kommunikation, bei dem Public-Key-Infrastruktur-Zertifikate verwendet werden, um Kommunikationsdaten von zulässigen Kommunikationssystemen zu signieren.
• Die Aufgabe der vorliegenden Erfindung besteht darin, die Sicherheit von zu übertragenden Lognachrichten besser gewährleisten zu können.
• Erfindungsgemäß wird diese Aufgabe gelöst durch ein Verfahren und ein Datensystem entsprechend den unabhängigen Patentansprüchen. Darüber hinaus werden ein entsprechendes Computerprogramm und ein computerlesbares Speichermedium bereitgestellt. Vorteilhafte Weiterbildungen der Erfindung ergeben sich aus den Unteransprüchen.
• Entsprechend der vorliegenden Erfindung wird dazu ein Verfahren zum Übertragen einer Lognachricht in einem Datensystem für Fahrzeuge 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 Datenquelle 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. Dem entsprechend findet eine Übertragung dieser Lognachrichten beispielsweise von den Datenquellen zu der Datensammeleinrichtung statt.
• In einem ersten Verfahrensschritt erfolgt ein Erzeugen der Lognachricht von einer Datenquelle des Datensystems. Die Lognachricht wird von der Datenquelle in der Regel automatisch erzeugt, um den Status (ggf. Fehler) der Datenquelle oder der Umgebung der Datenquelle zu dokumentieren.
• Die 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 Identifikationsinformation für einen von mehreren Logkanälen einer Datenquelle darstellen. Ferner kann ein Attribut auch eine Kritikalitätsstufe in Bezug auf Fehler, eine Logging-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 Sicherheitskennung dem Attribut der Lognachricht durch die Datenquelle. Diese Sicherheitskennung kann vorgegeben sein in Bezug auf eine vorgegebene Sicherheitsverarbeitung der Lognachricht (z.B. Filterung). Es wird der Lognachricht bzw. deren Attribut also automatisch eine Sicherheitskennung, d. h. eine Sicherheitsstufe zugeordnet. Im einfachsten Fall wird die Sicherheitskennung aus den Werten „keiner“, „authentisch“ und „verschlüsselt“ ausgewählt. Das Attribut „Sicherheit“ der Lognachricht erhält also beispielsweise den Wert „verschlüsselt“. Dies bedeutet, dass die Lognachricht beispielsweise als zu verschlüsseln einzustufen ist und daher die Datenquelle oder eine nachgeschaltete Verarbeitungseinheit die Lognachricht beispielsweise nur verschlüsselt nach außen senden darf. D.h. es dürfen für die Lognachricht nur verschlüsselte Übertragungskanäle benutzt werden. Die als zu verschlüsseln gekennzeichnete Lognachricht kann also auch zu einem späteren Zeitpunkt von einem Filter ausgefiltert werden. Beispielsweise filtert erst ein Zentralsteuergerät eines Fahrzeugs zu verschlüsselnde Lognachrichten von anderen Steuergeräten, die Datenquellen darstellen, aus, wenn die Übertragung zwischen den Steuergeräten zwar verschlüsselt erfolgt, aber nach dem Zentralsteuergerät die Übertragung beispielsweise zu der Datensammeleinrichtung nicht mehr verschlüsselt wäre. Andernfalls, wenn die Lognachricht als „keine“ (Sicherheitsstufe) gekennzeichnet ist, d. h. das Sicherheitsattribut besitzt den Wert „keine“, kann die Lognachricht von der Datenquelle beispielsweise ungehindert weiter übermittelt werden. In der Regel werden Lognachrichten mit dem Sicherheitsattribut „keine“ auch von Filtern, die im Lognachrichtenstrom stromabwärts liegen, nicht ausgefiltert.
• Die Datenquelle, die einer Lognachricht, mehreren Lognachrichten oder allen Lognachrichten eine jeweilige Sicherheitskennung zuordnet, ist entsprechend zu konfigurieren. Hierbei erhält die Datenquelle eine entsprechende Zuordnungsvorschrift, die gegebenenfalls veränderbar ist. Diese Zuordnungsvorschrift kann einschlägigen Sicherheitsrichtlinien Rechnung tragen. Da in unterschiedlichen Ländern ggf. voneinander abweichende Sicherheitsrichtlinien gelten, ist es vorteilhaft, wenn die Zuordnungsvorschrift für die Sicherheitskennung in der Datenquelle änderbar ist. Gegebenenfalls ist die Zuordnungsvorschrift über eine zentrale Managementeinrichtung in einem Backend für jede Datenquelle des Datensystems einstellbar. Somit können Loggingnachrichten in Einklang mit den jeweils geltenden Sicherheitsrichtlinien übertragen beziehungsweise gesammelt werden.
• In einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens ist vorgesehen, dass die Sicherheitskennung eine von einer Mehrzahl an vorgegebenen Kennungen ist, die jeweils einen Sicherheitsstatus der Lognachricht kennzeichnet. Die Sicherheitskennungen sind also vielfältig, sodass die Lognachricht beispielsweise mit unterschiedlichen Sicherheitsstufen gekennzeichnet werden kann. Auf diese Weise kann jede Lognachricht in Abhängigkeit von ihrer Sicherheitsstufe eine entsprechende sichere Behandlung erfahren. Das obige Beispiel für Sicherheitsstufen beziehungsweise Sicherheitsstatus beinhaltet die Kennungen: „keiner“, „authentisch“ und „verschlüsselt“. Bei dem Sicherheitsstatus „keiner“ kann die Lognachricht über beliebige Kanäle, insbesondere unverschlüsselt, übertragen werden. Bei dem Sicherheitsstatus „authentisch“ ist gewährleistet, dass die Lognachricht auch tatsächlich von derjenigen Datenquelle stammt, die als solche ausgewiesen ist. Es hat also beispielsweise eine entsprechende Authentifizierung stattgefunden. Der Sicherheitsstatus „verschlüsselt“ kann bedeuten, dass die Lognachricht nur über verschlüsselte Kanäle übertragen werden darf. Unverschlüsselte Kanäle hingegen dürfen für die Lognachricht nicht genutzt werden.
• Bei einem weiteren Ausführungsbeispiel liegt zu einer Lognachricht eine Kontextinformation vor, und die Datenquelle ermittelt die Sicherheitskennung automatisch in Abhängigkeit von der Kontextinformation und weist die so ermittelte Sicherheitskennung der Lognachricht zu. Dies bedeutet, dass die Sicherheitskennung für die Lognachricht der Datenquelle nicht fest vorgegeben ist, sondern von ihr erst in Abhängigkeit von einer zusätzlichen Information, nämlich der Kontextinformation, flexibel erzeugt wird. Dies bedeutet, dass die Sicherheitskennung in Abhängigkeit von der Kontextinformation unterschiedlich ausfallen kann. Die Kontextinformation beschreibt beispielsweise einen Zusammenhang der Lognachricht mit einem äußeren Umstand oder einem Zustand der Datenquelle beziehungsweise eines Logkanals.
• Speziell kann die Kontextinformation eine Information über eine Identität eines Logkanals der Datenquelle beinhalten, und die Datenquelle der Lognachricht ordnet dann die Sicherheitskennung in Abhängigkeit von der Information über die Identität des Logkanals zu. Beispielsweise besitzt eine Datenquelle mehrere Logkanäle, von denen jeder einem spezifischen Sicherheitslevel unterliegt. Dem entsprechend werden die Lognachrichten der einzelnen Logkanäle mit ihren Logkanal-spezifischen Sicherheitskennungen versehen. Besitzt beispielsweise eine Datenquelle einen Videokanal und einen Auswertekanal, so können Lognachrichten des Videokanals einen hohen Sicherheitsbedarf und Lognachrichten des Auswertekanals nur einen geringen Sicherheitsbedarf haben. Dies ist typischerweise bei Innenraumkameras der Fall, die mit anderen Steuergeräten kommunizieren. Daten, die etwa beim Booten oder bei Beschädigungen ausgetauscht werden benötigen typischerweise „keine“ hohe Sicherheitsstufe. Dem gegenüber sind die reinen Videodaten vom Fahrzeuginnenraum sicherheitsrelevant und somit in der Regel als „verschlüsselt“ zu kennzeichnen sowie entsprechend weiter zu übertragen. Aus den Videodaten wiederum gewonnene Ergebnisauswertungen beispielsweise in Bezug auf Objekterkennung und Gestenerkennung besitzen in der Regel „keine“ Sicherheitsrelevanz. Die Lognachrichten der Innenraumkamera können also in Bezug auf ihren Ursprung mit einer entsprechenden Sicherheitskennung versehen werden.
• Bei einer alternativen Ausführungsform ist vorgesehen, dass die Kontextinformation eine Information über eine von mehreren vorgegebenen Klassen in Bezug auf den Inhalt der Lognachricht aufweist, und die Datenquelle der Lognachricht die Sicherheitskennung in Abhängigkeit von der Information über die entsprechende Klasse des Inhalts der Lognachricht zuordnet. Es wird hier also nicht auf den physischen Ursprung der Lognachricht abgestellt, sondern auf den Inhalt der Lognachricht. Lognachrichten können in Bezug auf ihren Inhalt analysiert werden. Beispielsweise gibt das Format einer Lognachricht Auskunft darüber, um welche Klasse von Nachricht es sich handelt. Beispielsweise haben Videodaten ein anderes Format als Auswertungsdaten einer Objekterkennung. Aufgrund einer solchen Analyse kann einer Lognachricht eine korrespondierende, klassenspezifische Sicherheitskennung zugeordnet werden.
• Bei einer spezifischen Ausgestaltung des Verfahrens ist vorgesehen, dass die mehreren Klassen sich jeweils beziehen auf je eine der Kategorien: Fahrzeugidentifikationsnummer, Eigenpositionsdaten, Ortsdaten, Geräteidentifikationsnummer, Audio-/Videodatei, Kommunikationsdaten, Nutzerdaten, andere als die vorhergehenden Kategorien und nicht festgestellte Kategorie. Die Kontextinformation liefert also hier eine Information über die spezielle Klasse der Lognachricht. In Abhängigkeit von dieser Klasse kann die Datenquelle eine entsprechende Sicherheitskennung der Lognachricht zuweisen. Beispielsweise sollte eine Lognachricht, die eine Fahrzeugidentifikationsnummer beinhaltet, in dem Sicherheitsattribut den Wert „verschlüsselt“ aufweisen. Jede Lognachricht lässt sich beispielsweise in diese Klassen einteilen und entsprechend mit einer Sicherheitskennung versehen. Dabei können auch andere Klassen beziehungsweise Kategorien oder nur ein Teil der genannten Kategorien verwendet werden. Die Eigenpositionsdaten können GPS-Daten (global positioning system) sein. Die Eigenpositionsdaten können aber auch über Mobilfunksysteme und dergleichen gewonnen werden. Auch sie sind in der Regel schützenswert. Die Ortsdaten können beispielsweise Adressen einschließlich Postleitzahl, Straße und Hausnummer sein. Es kann sich dabei auch um Einträge aus einem Adressbuch oder Ziele aus einem Navigationssystem handeln. Die Geräteidentifikationsnummer kann die Datenquelle eindeutig identifizieren. Es kann sich hierbei etwa um eine Seriennummer oder um eine benutzergewählte Kennzeichnung eines Endgeräts (z. B. „Smartphone von Günther“) handeln. Letztere Information soll beispielsweise beim Verkauf eines Fahrzeugs nicht weitergegeben werden können. Audio-/Video-Dateien können einem Schutzinteresse unterliegen, falls sie in einem Fahrzeuginnenraum aufgenommen werden, wohingegen Audio-/Videodaten von der Umgebung des Fahrzeugs häufig nicht schutzbedürftig sind. Bei den Kommunikationsdaten kann es sich um Lognachrichten handeln, die beispielsweise bei der Fehlersuche relevant sind, wenn etwa ein Telefon bei der Verwendung unerlaubter Sonderzeichen abstürzt. Falls diese Kommunikationsdaten auch beispielsweise eine Verbindungsübersicht enthalten, sind sie auch schutzrelevant. Bei den Nutzerdaten kann es sich um eine Klasse von Lognachrichten handeln, die auf einen Benutzer bezogen sind, wie etwa ein Adressbuch. Auch in dieser Klasse kann besonderer Schutz, insbesondere Datenschutz, notwendig sein.
• Es kann auch eine spezielle Nachrichtenklasse dafür vorgesehen sein, die eine beispielsweise von der Datenquelle feststellbare Kategorie betreffen, welche aber von den bisher genannten Kategorien verschieden ist. Dies bedeutet, dass die Lognachricht auch einer festen Klasse zugeordnet werden kann, welche ihrerseits eine eigene Sicherheitsrelevanz besitzt. Schließlich kann für die Lognachrichten auch eine separate Klasse vorgesehen sein, die all denjenigen Lognachrichten zugewiesen wird, deren Kategorie nicht eindeutig festgestellt bzw. feststellbar ist. Beispielsweise werden diese nicht klar kategorisierbaren Lognachrichten sicherheitshalber nur für „verschlüsselte“ Kanäle freigegeben, damit auf alle Fälle ein Verstoß gegen Sicherheitsrichtlinien vermieden werden kann.
• In einem weiteren Ausführungsbeispiel kann vorgesehen sein, dass über eine Mensch-Maschine-Schnittstelle eine Information bezüglich einer Einwilligung in das Datensystem eingegeben wird, und die Datenquelle der Lognachricht die Sicherheitskennung in Abhängigkeit von der Information bezüglich der Einwilligung zuordnet. Dies bedeutet, dass beispielsweise der Nutzer eines Fahrzeugs einwilligen kann, dass gewisse Daten aus seinem Fahrzeug nach außen unverschlüsselt übermittelt werden, obwohl sie prinzipiell beispielsweise dem Datenschutz unterliegen würden. Ein Fahrzeugnutzer kann so beispielsweise in seinem Fahrzeug, das dem Datensystem angehört, eine Einwilligung erteilen, dass beispielsweise ein Steuergerät gewisse Daten nach außen unverschlüsselt senden darf. In diesem Fall wird die Datenquelle durch den Fahrzeugnutzer beispielsweise so konfiguriert, dass sie dem Sicherheitsattribut der Lognachricht den Wert „keine“ zuweist.
• Bei einer speziellen Ausgestaltung des Verfahrens kann vorgesehen sein, dass über die Mensch-Maschine-Schnittstelle jeweils eine separate Information bezüglich einer jeweiligen Einwilligung zu jedem von mehreren Logkanälen in das Datensystem eingegeben wird, und jede separate Information zum Zuordnen einer jeweiligen Sicherheitskennung zu der Lognachricht oder weiteren Lognachrichten genutzt wird. Dies bedeutet, dass einzelne Logkanäle einer Datenquelle auf unterschiedliche Weise gesichert übertragen werden können. Es können also Lognachrichten eines ersten Logkanals der Datenquelle als „verschlüsselt“ zu übertragen und Lognachrichten eines zweiten Logkanals der Datenquelle als unverschlüsselt übertragbar („keine“ Sicherheitsrelevanz) gekennzeichnet werden. Die Zuweisung der Sicherheitskennung ist in diesem Fall nicht datenquellenspezifisch, sondern logkanalspezifisch.
• In einer besonders bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens ist vorgesehen, dass die Datenquelle die Lognachricht zu einer Konzentrationseinrichtung sendet, in der Konzentrationseinrichtung eine Sicherheitsinformation über die Sicherheit einer von der Konzentrationseinrichtung weiterführenden Übertragungsverbindung hinterlegt ist, und die Konzentrationseinrichtung die Lognachricht in Abhängigkeit von der Sicherheitsinformation über die weiterführende Übertragungsverbindung weitersendet oder blockiert. Dies bedeutet, dass die Sicherheitskennung in jeder Lognachricht von einer Konzentrationseinrichtung ausgewertet wird. Eine Konzentrationseinrichtung kann Teil eines Steuergeräts sein, in dem die Lognachrichten von mehreren Logkanälen zusammenlaufen. Die Konzentrationseinrichtung konzentriert die Lognachrichten zu einem Lognachrichtenstrom, der über die weiterführende Übertragungsverbindung übermittelt wird. Falls nun beispielsweise die weiterführende Übertragungsverbindung nicht verschlüsselt ist, die Sicherheitskennung im Sicherheitsattribut einer Lognachricht jedoch eine verschlüsselte Übertragung fordert, so wird die Konzentrationseinrichtung die Lognachricht sperren und nicht über die weiterführende Übertragungsverbindung weiterleiten. Andere Lognachrichten hingegen, die mit der Sicherheitskennung „keine“ versehen sind, werden von der Konzentrationseinrichtung über die nicht verschlüsselte Übertragungsverbindung weitergeleitet. Auf diese Weise können insbesondere Luftschnittstellen genau in dem Umfang genutzt werden, wie es ihre Sicherheit erlaubt.
• 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 Sicherheitskennung zu einem Attribut einer Lognachricht der Datenquelle aufweist, und
• - ein Verfahren zum Übertragen der Lognachricht, wie es oben beschrieben wurde, durchgeführt wird. Das Auszeichnen von Lognachrichten mit einer Sicherheitsrelevanz 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 Sicherheits- oder Datenschutzregulierung eingehalten 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 Lognachrichtenstrom) zu den Datenquellen übermittelt werden. In der jeweiligen Datenquelle wird die Filterkonfiguration dazu genutzt, die darin enthaltene Zuordnungsvorschrift in Bezug auf das Zuordnen einer Sicherheitskennung zu dem Attribut einer Lognachricht zu implementieren. Im einfachsten Fall lautet eine Zuordnungsvorschrift, dass jede Lognachricht der betreffenden Datenquelle bzw. das jeweilige Sicherheitsattribut jeder Lognachricht mit einer vorgegebenen Sicherheitskennung (z. B. „verschlüsselt“) versehen wird. Bei einer höher entwickelten Ausführungsform kann die in die Filterkonfigurationsnachricht aufzunehmende Zuordnungsvorschrift beispielsweise vorschreiben, wie die Lognachrichten in Abhängigkeit vom Nachrichteninhalt mit einer jeweiligen Sicherheitskennung zu versehen sind. Auf diese Weise kann das Sammeln von Lognachrichten über Logging-Kampagnen jederzeit an gültige Sicherheits- oder Datenschutzrichtlinien angepasst werden.
• Die oben geschilderte Aufgabe wird erfindungsgemäß auch gelöst durch ein Datensystem aufweisend
• - mindesten ein Fahrzeug mit mindestens einer Datenquelle zum Erzeugen einer Lognachricht, wobei
• - die mindestens eine Datenquelle eine Steuereinrichtung aufweist, mit der eine Sicherheitskennung einem Attribut der Lognachricht zuordenbar ist, so dass
• - mit dem Datensystem ein Verfahren nach oben beschriebener Art durchführbar ist.
• 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.
• Zu der Erfindung gehören auch Weiterbildungen des erfindungsgemäßen Verfahrens, die Merkmale aufweisen, wie sie bereits im Zusammenhang mit den Weiterbildungen des erfindungsgemäßen Kraftfahrzeugs beschrieben worden sind. Aus diesem Grund sind die entsprechenden Weiterbildungen des erfindungsgemäßen Verfahrens hier nicht noch einmal beschrieben.
• 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 schematischen Ablaufdiagramm; und
• 2 ein Blockdiagramm zur schematischen Darstellung eines Ausführungsbeispiels eines erfindungsgemäßen Verfahrens zur Erzeugung von Lognachrichten mit Sicherheitskennung.
• 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 vorliegende Erfindung geht von der Problematik aus, dass schützenswerte Daten nicht über aus Cyber-Security-Sicht unsichere Datenverbindungen übertragen werden sollen. Darüber hinaus sollen solche schützenswerte Daten auch nicht in unsicheren Speichern abgelegt werden. Schützenswerte Daten sind beispielsweise persönliche Daten oder Daten, die einer Geheimhaltung unterliegen. Insbesondere können so auch vertrauliche Daten etwa mit Bezug zu geistigem Eigentum als schützenswerte Daten eingestuft werden.
• Für die Auswertung von Fehlern oder für das Gewinnen von Statistiken besteht einerseits der Bedarf, möglichst viele Daten zu sammeln und andererseits besteht in der Regel die Vorgabe, gewisse Sicherheitskriterien einzuhalten. Die erfindungsgemäße Lösung, gemäß der sämtliche Lognachrichten mit entsprechenden Sicherheitskennungen versehen werden, schafft in dem obigen Spannungsfeld einen Lösungsansatz, bei dem unter Einhaltung von vorgegebenen Sicherheitskriterien möglichst viele Daten gesammelt werden können.
• 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.
• Der erfindungsgemäße Ansatz erlaubt eine automatische Filterung und Absicherung von Lognachrichten über eine Sicherheitskennung beziehungsweise ein Sicherheitsrelevanz-Attribut. Jede Lognachricht besitzt demnach ein Sicherheitsattribut, welches mit einem entsprechenden Wert, d.h. einer Sicherheitskennung, versehen wird. Nachgeschaltete Verarbeitungsstellen können dann die Lognachricht anhand ihrer Sicherheitskennung weiterverarbeiten.
• 2 zeigt ein Blockschaltbild für ein Ausführungsbeispiel eines erfindungsgemäßen Verfahrens, bei dem Lognachrichten mit Sicherheitskennungen versehen und entsprechend übermittelt beziehungsweise gesendet werden. In einem ersten Schritt S1 wird eine Lognachricht erzeugt. Dies geschieht in der Regel in einer Datenquelle, die beispielsweise eine Softwarekomponente eines Steuergeräts eines Fahrzeugs, ein Endgerät oder ein Cloud-Service oder ähnliches sein kann. Entsprechend einem optionalen zweiten Schritt S2 wird eine Kontextinformation bereitgestellt. Diese Kontextinformation beschreibt beispielsweise die Datenquelle oder deren Umgebung näher. Handelt es sich beispielsweise bei der Datenquelle um eine Innenraumkamera eines Fahrzeugs, so sollten die gewonnenen Videodaten beispielsweise nur verschlüsselt übertragen werden.
• In einem weiteren optionalen Schritt S3 erfolgt ein Klassifizieren der Lognachricht. Dieses Klassifizieren kann beispielsweise anhand des Inhalts der Lognachricht beziehungsweise deren Format erfolgen. Alternativ oder zusätzlich kann für das Klassifizieren auch die in Schritt S2 bereitgestellte Kontextinformation verwendet werden. So können beispielsweise Videodaten, die von einer Außenkamera eines Fahrzeugs gewonnen werden, als nicht sicherheitsrelevant klassifiziert werden. Bei dem Klassifizieren in Schritt S3 wird demnach jede Lognachricht einer Sicherheitsklasse bzw. -stufe zugeordnet. Der Schritt des Klassifizierens ist jedoch rein optional. Gegebenenfalls ist die Einstufung der Lognachricht hinsichtlich ihrer Sicherheit fest vorgegeben oder wird über eine andere Schnittstelle vorgegeben.
• In einem Schritt S4 erfolgt das Zuordnen einer Sicherheitskennung zu der Lognachricht bzw. zu einem Attribut der Lognachricht. Dies bedeutet, dass einem Sicherheitsattribut der Lognachricht ein entsprechender Wert, nämlich die Sicherheitskennung, zugewiesen wird. Auf diese Weise erhält jede Lognachricht eine individuelle Sicherheitskennung in Bezug auf die für weitere Übertragungen einzuhaltende Sicherheit. Optional kann dieses Zuordnen auch unmittelbar mit der in Schritt S2 bereitgestellten Kontextinformation erfolgen. Beispielsweise besteht die Kontextinformation darin, dass die Lognachricht aus einer sehr sicheren Quelle stammt. Dementsprechend kann aus der Kontextinformation unmittelbar die Sicherheitskennung „authentisch“ für die Lognachricht in Schritt S4 verwendet werden.
• In einem weiteren Schritt S5 kann eine Information über die Sicherheit einer Übertragungsverbindung bereitgestellt werden. So kann beispielsweise die Information bereitgestellt werden, dass ein Übertragungskanal für die Lognachrichten verschlüsselt ist.
• In einem weiteren Schritt S6 wird die Lognachricht gemäß der in Schritt S4 zugeordneten Sicherheitskennung gesendet oder gefiltert. Dafür kann die in Schritt S5 bereitgestellte Information über die Sicherheit der weiteren Übertragungsverbindung genutzt werden. Beispielsweise ordnet eine Datenquelle einem ersten Logkanal die Sicherheitsstufe „keine“ und einem zweiten Logkanal die Sicherheitsstufe „verschlüsselt“ zu. Falls nun die von der Datenquelle zu einer Datensammeleinrichtung wegführende Übertragungsverbindung nicht verschlüsselt (Information in Schritt S5: „keine verschlüsselte Verbindung“) ist, wird die Datenquelle nur die Lognachrichten des ersten Kanals versenden, denn die Lognachrichten des zweiten Logkanals erfordern eine Verschlüsselung. Andernfalls, wenn die zur Datensammeleinrichtung führende Übertragungsverbindung verschlüsselt ist, kann die Datenquelle die Lognachrichten beider Logkanäle senden. Ähnliches gilt bei einer Konzentrationseinrichtung, die die Lognachrichten mehrerer Datenquellen zur Weiterleitung an eine Datensammeleinrichtung konzentriert. Falls die Übertragungsverbindung zur Datensammeleinrichtung nicht verschlüsselt ist, wird die Konzentrationseinrichtung nur diejenigen Lognachrichten von den Datenquellen weiterleiten, die die Sicherheitskennung „keine“ besitzen. Andere Lognachrichten mit der Sicherheitskennung „verschlüsselt“ wird die Konzentrationseinrichtung ausfiltern beziehungsweise blockieren.
• In vorteilhafter Weise kann somit jeder Logeintrag beziehungsweise jede Lognachricht mit einem Sicherheitsattribut beziehungsweise einer entsprechenden Sicherheitskennung versehen werden, sodass auf den Schaltstellen oder Verzweigungen der Datensammelstrecke beispielsweise vom Fahrzeug bis ins Cloud-Backend automatisch entschieden werden kann, ob der Eintrag als Lognachricht übertragen werden kann oder nicht. Das Attribut kann im einfachsten Fall - wie erwähnt - die Werte: „keine“, „authentisch“ oder „verschlüsselt“ annehmen, um das für die Übertragung zur nächsten Verarbeitungsstufe notwendige Absicherungsverfahren auswählen zu lassen. Diesbezüglich sind weitere Verfeinerungen bzw. Sicherheitskennungen denkbar bis hin zu konkreten erforderlichen Absicherungsverfahren.
• Somit kann in jeder Teilübertragungsstrecke die Übertragung von Lognachrichten auf diejenigen Lognachrichten begrenzt werden, deren Sicherheitsanforderungen gewährleistet werden können. Wenn also beispielsweise eine Kommunikationsstrecke keine Verschlüsselung, aber Authentizität unterstützt, so können Lognachrichten der Kategorie „keine“ oder „authentisch“ übertragen werden, während die mit „verschlüsselt“ gekennzeichneten Lognachrichten verworfen 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 S6

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 9843594 B1 [0004]
• DE 102007058975 A1 [0005]
• US 10523679 B2 [0006]
• US 9984522 B2 [0007]
• EP 3357262 B1 [0008]

Claims (13)

1. Verfahren zum Übertragen einer Lognachricht in einem Datensystem für Fahrzeuge (FZ), gekennzeichnet durch - Erzeugen (S1) der Lognachricht von einer Datenquelle (SWC, CS, SP) des Datensystems, wobei die Lognachricht ein Attribut aufweist, - Zuordnen (S4) einer Sicherheitskennung dem Attribut der Lognachricht durch die Datenquelle (SWC, CS, SP) und - Filtern oder Senden (S6) der Lognachricht in Abhängigkeit von der Sicherheitskennung.
2. Verfahren nach Anspruch 1, wobei die Sicherheitskennung eine von einer Mehrzahl an vorgegebenen Kennungen ist, die jeweils einen Sicherheitsstatus der Lognachricht kennzeichnet.
3. Verfahren nach Anspruch 1 oder 2, wobei zu der Lognachricht eine Kontextinformation vorliegt (S2), und die Datenquelle (SWC, CS, SP) die Sicherheitskennung automatisch in Abhängigkeit von der Kontextinformation ermittelt (S3) und der Lognachricht zuordnet (S4).
4. Verfahren nach Anspruch 3, wobei die Kontextinformation eine Information über eine Identität eines Logkanals der Datenquelle (SWC, CS, SP) beinhaltet, und die Datenquelle (SWC, CS, SP) der Lognachricht die Sicherheitskennung in Abhängigkeit von der Information über die Identität des Logkanals zuordnet (S4).
5. Verfahren nach Anspruch 3, wobei die Kontextinformation eine Klasseninformation über eine von mehreren vorgegebenen Klassen in Bezug auf den Inhalt der Lognachricht aufweist, und die Datenquelle (SWC, CS, SP) der Lognachricht die Sicherheitskennung in Abhängigkeit von der Klasseninformation über die entsprechende Klasse des Inhalts der Lognachricht zuordnet (S4).
6. Verfahren nach Anspruch 5, wobei die mehreren Klassen sich jeweils beziehen auf je eine der Kategorien: Fahrzeugidentifikationsnummer, Eigenpositionsdaten, Ortsdaten, Geräteidentifikationsnummer, Audio/Video-Datei, Kommunikationsdaten, Nutzerdaten, andere als die vorhergehenden Kategorien und nicht festgestellte Kategorie.
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Datenquelle (SWC, CS, SP) mehrere Logkanäle besitzt, und jeder Logkanal seinen jeweiligen Lognachrichtung eine kanalspezifische Sicherheitskennung zuordnet (S4).
8. Verfahren nach einem der vorhergehenden Ansprüche, wobei der Lognachricht neben der Sicherheitskennungen mindestens eine weitere Sicherheitskennung zugeordnet wird.
9. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Datenquelle die Lognachricht zu einer Konzentrationseinrichtung sendet, in der Konzentrationseinrichtung eine Sicherheitsinformation über die Sicherheit einer von der Konzentrationseinrichtung weiterführenden Übertragungsverbindung hinterlegt ist (S5), und die Konzentrationseinrichtung die Lognachricht in Abhängigkeit von der Sicherheitsinformation über die weiterführende Übertragungsverbindung weitersendet oder blockiert (S6).
10. Verfahren zum Sammeln von Lognachricht in einem Datensystem für Fahrzeuge (FZ), aufweisend die Schritte: - Erstellen einer Logging-Kampagne, die mindestens eine Filterkonfigurationsnachricht aufweist, - automatisches Übertragen der Filterkonfigurationsnachricht an eine Datenquelle (SWC, CS, SP) des Datensystems, wobei die Filterkonfigurationsnachricht eine Zuordnungsvorschrift zum Zuordnen einer Sicherheitskennung zu einem Attribut einer Lognachricht der Datenquelle (SWC, CS, SP) aufweist, und - ein Verfahren zum Übertragen der Lognachricht nach einem der vorhergehenden Ansprüche durchgeführt wird.
11. Datensystem aufweisend - mindesten ein Fahrzeug (FZ) mit mindestens einer Datenquelle (SWC, CS, SP) zum Erzeugen einer Lognachricht, dadurch gekennzeichnet, dass - die mindestens eine Datenquelle (SWC, CS, SP) eine Steuereinrichtung aufweist, mit der eine Sicherheitskennung zu einem Attribut der Lognachricht zuordenbar ist, so dass - mit dem Datensystem ein Verfahren nach einem der vorhergehenden Ansprüche durchführbar ist.
12. Computerprogramm umfassend Befehle, die bei der Ausführung des Programms durch eine Steuervorrichtung eines Datensystems nach Anspruch 11 dieses veranlassen, das Verfahren nach einem der Ansprüche 1 bis 10 auszuführen.
13. Computerlesbares Speichermedium, umfassend Befehle, die bei der Ausführung durch eine Steuervorrichtung eines Datensystems nach Anspruch 11 dieses veranlassen, das Verfahren nach einem der Ansprüche 1 bis 10 auszuführen.

Images