-
Die vorliegende Erfindung betrifft ein Verfahren zum Sammeln von Daten mehrerer Datenquellen eines Datensystems für Fahrzeuge. Darüber hinaus betrifft die vorliegende Erfindung ein System zum Sammeln von Daten mehrerer Datenquellen, das eine Zentraleinheit und mindestens ein Fahrzeug aufweist, wobei die mehreren Datenquellen über die Zentraleinheit und das mindestens eine Fahrzeug verteilt sind.
-
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 2020/0219388 A1 offenbart ein Verfahren und ein System zur Kartendatenkonstruktion, bei dem grundlegende Sicherheitsinformationsdaten erfasst und prozessiert werden, um die Kartendaten zu erzeugen.
-
Des Weiteren offenbart die Druckschrift
DE 10 2017 218 561 A1 ein Verfahren zum Auswerten von Verkehrsdaten, bei dem die Verkehrsdaten durch eine zentrale Einrichtung und/oder eine Cloud erfasst und ausgewertet werden.
-
Ferner offenbaren die Druckschriften
US 2020/0263992 A1 ,
US 2020/0263995 A1 und
US 2020/0263993 A1 jeweils ein Verfahren und System zur Bereitstellung einer Kampagnenverwaltungsplattform zur Validierung von Kartendaten, wobei eine Kampagne beispielsweise die Verpflichtung einer Fahrzeugflotte zur Sammlung von Sensordaten ist.
-
Die Druckschrift
EP 3 492 872 A1 offenbart ein Verfahren zum Speichern und Übertragen von Messdaten von Messfahrzeugen. Eine Messkampagne wird mit einer Anzahl von Messfahrzeugen gestartet. Eine Messeinstellung kann geändert werden, wenn eine gewisse Anzahl an benötigten Messungen erreicht worden ist.
-
Des Weiteren offenbart die Druckschrift
DE 10 2020 007 072 A1 ein Verfahren zur Datenerhebung über eine Mehrzahl von verbundenen Dienstanbietern. Eine Datenerhebungskampagne wird mit einem vorgegebenen Startkriterium versehen. Das Startkriterium kann beispielsweise eine Uhrzeit oder auch ein von einer IOT-Vorrichtung erkannter Stau sein.
-
Die Aufgabe der vorliegenden Erfindung besteht darin, Daten von mehreren Datenquellen bedarfsgerecht zu sammeln.
-
Entsprechend der vorliegenden Erfindung wird dazu ein Verfahren zum Sammeln von Daten mehrerer Datenquellen eines Datensystems für Fahrzeuge bereitgestellt. Das Datensystem weist beispielsweise ein (Cloud-)Backend und eines oder mehrere Fahrzeuge sowie gegebenenfalls andere Komponenten eines IOT-Systems (wie Smartphones) auf. Die Datenquellen sind über die Einheiten des Datensystems verteilt. So kann beispielsweise eine Fahrzeugkomponente oder eine Backend-Komponente eine Datenquelle darstellen. Insbesondere kann auch eine Software-Komponente in dem Fahrzeug oder dem Backend-System eine Datenquelle repräsentieren. Die Datenquellen sind mit einer Zentraleinheit des Datensystems zum Datenaustausch verbunden.
-
In einem ersten Schritt des Verfahrens erfolgt ein Erstellen einer Logging-Kampagne, die für jede der mehreren Datenquellen eine spezifische Filterkonfiguration umfasst, welche jeweils eine Kennung für die jeweilige Datenquelle und eine oder mehrere Filterbedingungen für die jeweilige Datenquelle aufweist, in der Zentraleinheit. Beispielsweise weist ein Cloud-Backend ein Logging-Management-System auf, das Teil der Zentraleinheit sein kann. In diesem Logging-Management-System wird beispielsweise die Logging-Kampagne erstellt. Die Logging-Kampagne dient dazu, spezifische Logdaten von den Datenquellen beziehungsweise Software-Komponenten abzurufen und gegebenenfalls zu speichern beziehungsweise zu analysieren. Die Logging-Kampagne enthält für jede der mehreren Datenquellen eine spezifische Filterkonfiguration. Eine spezifische Filterkonfiguration wiederum besitzt eine Kennung der jeweiligen Datenquelle (z.B. Datenquellen-ID) und eine oder mehrere Filterbedingungen, die für die Datenquelle in Bezug auf das Senden von Daten gelten sollen. Beispielsweise besagt die Filterbedingung, dass nur Fehlermeldungen von der Datenquelle zu der Zentraleinheit übertragen werden sollen. Aufgrund dieser Filterbedingungen werden dann andere Daten von der Datenquelle nicht an die Zentraleinheit übermittelt.
-
In einem zweiten Schritt des erfindungsgemäßen Verfahrens erfolgt ein automatisches Verteilen der Filterkonfigurationen der Logging-Kampagne an jede der mehreren Datenquellen. Die in der Zentraleinheit erstellte Logging-Kampagne wird nun bezüglich eines Datenstroms von den Datenquellen zur Zentraleinheit stromaufwärts an die Datenquellen, soweit erforderlich, übermittelt. Dabei ist es nicht notwendig, dass die gesamte Logging-Kampagne an jede Datenquelle übermittelt wird. Vielmehr genügt es, wenn an jede Datenquelle nur diejenige Filterkonfiguration aus der Logging-Kampagne übermittelt wird, die der jeweiligen Kennung der Datenquelle zugeordnet ist. Falls jede Datenquelle die gesamte Logging-Kampagne und damit alle Filterkonfigurationen erhält, muss sie selbst eigene Intelligenz besitzen, um die für sie spezifische Filterkonfiguration zu exzerpieren. Andernfalls, wenn die Datenquelle nur die für sie vorgesehene Filterkonfiguration aus der Logging-Kampagne erhält, muss eine Intelligenz zwischen die Zentraleinheit und die Datenquelle geschaltet sein (z.B. Konzentrationseinrichtung beziehungsweise Konzentrator), die die Verteilung der Filterkonfigurationen aus der Logging-Kampagne auf die verschiedenen Datenquellen realisiert.
-
In einem anschließenden Schritt erfolgt ein automatisches Konfigurieren der jeweiligen Datenquelle mit der jeweils spezifischen Filterkonfiguration. Jede Datenquelle, die ihre spezifische Filterkonfiguration aus der Logging-Kampagne von der Zentraleinheit erhalten hat, muss entsprechend dieser Filterkonfiguration automatisch konfiguriert werden oder sich selbst entsprechend dieser Filterkonfiguration konfigurieren.
-
Schließlich erfolgt in einem weiteren Schritt des erfindungsgemäßen Verfahrens ein Übertragen von Daten durch jede Datenquelle zu einer zentralen Datensammeleinrichtung (Data Lake) des Datensystems entsprechend der jeweiligen Filterkonfiguration. Vorzugsweise ist die zentrale Datensammeleinrichtung auch Teil der Zentraleinheit in dem Cloud-Backend. Dies bedeutet, dass zunächst die Filterkonfigurationen stromaufwärts von der Zentraleinheit zu den Datenquellen und anschließend Daten von den Datenquellen zu der Zentraleinheit stromabwärts übermittelt werden.
-
In vorteilhafter Weise ist somit eine kampagnenbasierte Sammlung, Filterung, gegebenenfalls Zwischenspeicherung, Ausleitung und gegebenenfalls zentrale Auswertung von attributierten Logdaten aus Flotten von „Connected Cars“ optional unter Einbeziehung der Logdaten aus den mit ihnen verbundenen Cloud-Backendsystemen möglich.
-
In einer bevorzugten Ausgestaltung des erfindungsgemäßen Verfahrens ist vorgesehen, dass das Datensystem mindestens zwei Elemente aus der Menge Fahrzeuge, Cloud und Endgeräte aufweist, und die mehreren Datenquellen Software-Komponenten des jeweiligen Elements sind. Dies bedeutet, dass das Datensystem beispielsweise eines oder mehrere Fahrzeuge und eine Cloud umfasst. Gegebenenfalls kann das Datensystem aber auch beispielsweise ein Fahrzeug und ein Endgerät aufweisen. In einer vorteilhaften Ausgestaltung ist die oben genannte Zentraleinheit, in der die Logging-Kampagne erstellt wird, in die Cloud eingebunden. Vorzugsweise sind die genannten Datenquellen Software-Komponenten in den Fahrzeugen, in der Cloud oder in den Endgeräten. Ziel ist es dann beispielsweise, eine Funktionskette von einer Software-Komponente eines Fahrzeugs bis zu einer Software-Komponente in der Cloud beziehungsweise im Endgerät zu analysieren.
-
Bei einer vorteilhaften Ausgestaltung erfolgt das automatische Verteilen der Filterkonfigurationen durch eine Konzentrationseinrichtung, die die Logging-Kampagne aufsplittet, sodass jede Datenquelle nur diejenige der Filterkonfigurationen erhält, die ihrer Kennung entspricht. Die Filterkonfigurationen der Logging-Kampagne werden also in diesem Fall stromaufwärts durch die eine oder mehrere Konzentrationseinrichtungen verteilt. Dadurch erhält jede Datenquelle vorzugsweise nur diejenige oder diejenigen Filterkonfigurationen, die für die jeweilige Datenquelle vorgesehen ist. Wenn also beispielsweise eine Filterkonfiguration einer Datenquellen-ID zugeordnet ist, erhält nur die spezielle Datenquelle mit der bestimmten ID die Filterkonfiguration. Auf diese Weise kann bereits stromaufwärts die Datenmenge bis in die letzten Zweige reduziert werden.
-
Bei einer bevorzugten Weiterbildung des Verfahrens kann vorgesehen sein, dass bei dem Übertragen von Daten von mindestens zweier der Datenquellen jeweils ein Teildatenstrom zu der Konzentrationseinrichtung gesendet wird, die Teildatenströme in der Konzentrationseinrichtung zu einem Gesamtdatenstrom konzentriert werden und der Gesamtdatenstrom zu der zentralen Datensammeleinrichtung übertragen wird. Dies bedeutet, dass die Daten stromabwärts mittels der Konzentrationseinrichtung(en) zu dem Gesamtdatenstrom zusammengefügt beziehungsweise konzentriert werden. Dies wiederum hat den Vorteil, dass bei der in der Regel notwendigen drahtlosen Übertragung des Gesamtdatenstroms zur Zentraleinheit die Effizienz der Datenübermittlung erhöht wird.
-
Darüber hinaus kann vorgesehen sein, dass das Datensystem in einem Datenstrom von einer der Datenquellen zu der zentralen Datensammeleinrichtung zusätzlich zu der Konzentrationseinrichtung mindestens eine weitere Konzentrationseinrichtung der genannten Art aufweist. Da eine Konzentrationseinrichtung eine Verzweigung des Datenstroms repräsentiert, bedeuten mehrere Konzentrationseinrichtungen hintereinander im Datenstrom eine mehrfache Verzweigung des Datenstroms. Grundsätzlich kann so der Datenstrom nach Bedarf verzweigt werden. Beispielsweise kann eine Konzentrationseinrichtung in einem Steuergerät eines Fahrzeugs untergebracht sein. Ein Zentralsteuergerät kann dann entsprechend einen zentralen Logging-Konzentrator aufweisen, von dem dann der gesamte Datenstrom eines Fahrzeugs zu der zentralen Datensammeleinrichtung beziehungsweise Zentraleinheit übertragen wird.
-
Bei einem ebenfalls bevorzugten Ausführungsbeispiel ist vorgesehen, dass die Logging-Kampagne zusätzlich zu den Filterkonfigurationen mindestens ein Element aus Vorverarbeitungsanweisungen, Triggerbedingungen, Laufzeiten, Speichervorgaben und Attributen aufweist, das mindestens eine Element bei dem automatischen Verteilen an eines oder mehrere der Datenquellen verteilt wird und das automatische Konfigurieren sowie das Übertragen der Daten zusätzlich in Abhängigkeit von dem verteilten mindestens einen Element erfolgt. Dies bedeutet, dass die Logging-Kampagne auf der Basis weiterer Attribute erfolgen kann, die mit den Filterkonfigurationen zu den jeweiligen Datenquellen verteilt werden. So können beispielsweise als Vorverarbeitungsanweisungen sogenannte Skripte an die Datenquellen verteilt werden. Triggerbedingungen können den Datenquellenauslöser liefern, wann beispielsweise Daten gesammelt werden sollen. Laufzeiten können definiert sein, um das Datensammeln zeitlich einzugrenzen. Außerdem können im Rahmen der Logging-Kampagne Speichervorgaben erstellt und mit den Filterkonfigurationen an die Datenquellen verteilt werden, um beispielsweise die Größe eines Ringpuffers oder einen Speicherort festzulegen. Darüber hinaus können mit den Filterkonfigurationen auch noch andere Attribute beispielsweise in Bezug auf Authentifizierungen und Verschlüsselungen übermittelt werden. Eines oder mehrere dieser oben genannten Elemente beziehungsweise Attribute werden in diesem Fall neben der jeweiligen Filterkonfiguration an die Datenquelle übertragen und dort für die automatische Konfiguration verwendet. Beispielsweise wird also eine Datenquelle mit einer spezifischen Filterkonfiguration und einem spezifischen Vorverarbeitungsskript und einer spezifischen Triggerbedingung et cetera automatisch konfiguriert.
-
Wie oben dargestellt wurde, besteht eine Filterkonfiguration aus einer Kennung der Datenquelle und aus einer oder mehreren Filterbedingungen. Dabei können die Filterbedingungen ausgewählt sein z.B. aus a) Kritikalitätsstufen der Daten, b) Logging-Kategorien, c) Datenschutz-Kategorien, d) Sicherheits-Kategorien, e) Wertebereichsvorgaben und f) Vorverarbeitungsskripte d.h. ins Fahrzeug als Teil der Kampagnenkonfiguration ladbare Skripte, die erweiterte Filteralgorithmen implementieren können). Es kann also eine oder mehrere dieser Filterbedingungen in der jeweiligen Filterkonfiguration enthalten sein. In der Kritikalitätsstufe werden die Daten beispielsweise unterteilt in Klassen wie Fehler, Warnung, Information und dergleichen. Bei der Logging-Kategorie kann unterschieden werden, wie ausführlich das Logging stattfinden soll und inwieweit beispielsweise Dateien eingebettet werden sollen. Die Datenschutz- und Sicherheitskategorien können dazu verwendet werden, um Persönlichkeitsrechte und Sicherheitsanforderungen zu berücksichtigen. Wertebereichsvorgaben ermöglichen beispielsweise die Eingrenzung von Werten mittels Vergleichsoperatoren. Die Filterbedingungen sind nicht auf die genannten Varianten begrenzt. Sie ermöglichen in ihrer vielfältigen Ausgestaltung, die Logging-Kampagne sehr individuell anzupassen und die nötigen Datenströme auf ein Minimum zu reduzieren.
-
Das Datensystem kann beispielsweise ein Fahrzeug aufweisen, wobei die Logging-Kampagne von der Zentraleinheit drahtlos auf das Fahrzeug übertragen wird und in dem Fahrzeug das Verteilen der Filterkonfigurationen an Software-Komponenten als Datenquellen erfolgt. Beispielsweise wird die Logging-Kampagne über eine sogenannte OTA-Verbindung (Over the Air) von der Zentraleinheit zu dem Fahrzeug übertragen. Solche OTA-Verbindungen können im konventionellen Fahrzeugbetrieb genutzt werden. Alternativ kann auch ein lokales Netz oder ein Memory- bzw. USB-Stick verwendet werden, um die Logging-Kampagne beispielsweise in einer Servicestelle (Backend beziehungsweise Zentraleinheit) auf das Fahrzeug zu übertragen. Die drahtlose Übertragung der Logging-Kampagne erlaubt das Vermeiden mühevoller drahtgebundener Übertragungen der Kampagne-Daten.
-
In einer weiteren bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens weist das Datensystem ein Backend mit Cloud auf, wobei die Zentraleinheit in das Backend integriert ist, die Logging-Kampagne von der Zentraleinheit auf ein Backend-System der Cloud übertragen wird und in dem Backend-System das Verteilen der Filterkonfigurationen an mehrere Cloud-Services als Datenquellen erfolgt. Das Backend mit der Zentraleinheit, die wiederum die zentrale Datensammeleinrichtung aufweist, ist in diesem Fall also an eine Cloud angebunden, mit der das Backend Daten austauschen kann. Wie die Steuergeräte in den Fahrzeugen Softwarekomponenten aufweisen, so können Cloud-Backend-Systeme Cloud-Services als Datenquellen aufweisen. Ein derartiger Cloud-Service kann beispielsweise die Verbindung mit einem Endgerät, insbesondere einem Smartphone oder mit einem anderen IOT-Gerät (Internet of Things) herstellen. Damit ist es möglich, eine Logging-Kampagne nicht nur auf verschiedene Fahrzeuge, sondern auch auf Cloud-Backend-Systeme zu verteilen und sogar auf Endgeräte wie Smartphones. Umgekehrt ermöglicht dies aber auch das Sammeln von Daten stromabwärts von den Cloud-Services zu der zentralen Datensammeleinrichtung gegebenenfalls über Logging-Konzentratoren in den Cloud-Backend-Systemen.
-
Für den Fall, dass das Datensystem ein Fahrzeug aufweist, kann das Fahrzeug einen Ringpuffer besitzen, wobei für das Übertragen der Daten der Ringpuffer entsprechend einer Triggerbedingung der Logging-Kampagne ausgelesen wird. Der Ringpuffer des Fahrzeugs wird in diesem Fall beispielsweise mit einem fortlaufenden Datenstrom gefüllt. Tritt die vorgebbare Triggerbedingung ein, so wird der Ringpuffer ganz oder teilweise ausgelesen. Beispielsweise erfolgt das Auslesen des Ringpuffers, wenn als Triggerbedingung eine Fehlermeldung vorliegt. Dies bedeutet, dass nur dann Logging-Daten übertragen werden, wenn ein Fehler vorliegt. Auf diese Weise lassen sich systematisch Datenübertragungskapazitäten einsparen und die Historie der Log-Einträge, die vor dem Auftreten des Fehlers von den Datenquellen erzeugt wurden, speichern.
-
In einem weiteren vorteilhaften Ausführungsbeispiel versehen sämtliche Datenquellen des Datensystems ihre zu übertragenden Daten mit einem Zeitstempel, der auf einer gemeinsamen Zeitbasis beruht. Ein derartiger zentraler Zeitstempel ermöglicht es, dass alle Daten des Datensystems synchronisiert und damit zielgerichteter ausgewertet werden können.
-
Ferner ist es günstig, wenn sämtliche Datenquellen des Datensystems ihre zu übertragenden Daten mit einer innerhalb des Datensystems eindeutigen Kennung der jeweiligen Datenquelle versehen. Somit kann im Backend beziehungsweise in der Zentraleinheit genau nachvollzogen werden, welche Datenquelle die jeweiligen Daten geliefert hat. Somit kann beispielsweise ein Fehler zielgerichteter gefunden werden.
-
Das Datensystem kann, wie erwähnt, eine oder mehrere Konzentrationseinrichtungen beziehungsweise Konzentratoren aufweisen, mit denen die Logging-Kampagne stromaufwärts verteilt und die Daten stromabwärts konzentriert werden können. Dabei kann jede Konzentrationseinrichtung eine Filterung und/oder eine Vorverarbeitung von Daten gemäß der Logging-Kampagne ausführen. Eine Konzentrationseinrichtung kann damit auch als eine Datenquelle gesehen werden, die mittels der Logging-Kampagne automatisch konfiguriert werden kann. Insbesondere kann eine Konzentrationseinrichtung damit hinsichtlich ihrer Filterwirkung stromabwärts fließender Daten oder auch stromaufwärts gerichteter Filterkonfigurationen konfiguriert werden. Gleiches gilt für etwaige Vorverarbeitungsfunktionen der Konzentrationseinrichtung(en).
-
In einem konkreten Ausführungsbeispiel kann das Datensystem, wie oben angedeutet, ein Fahrzeug mit mehreren Steuergeräten und einem Zentralsteuergerät aufweisen, wobei mehrere Datenquellen des Datensystems auf die mehreren Steuergeräte verteilt sind, und das Zentralsteuergerät das automatische Verteilen der Filterkonfigurationen der Logging-Kampagne an die Steuergeräte übernimmt. Insbesondere kann dabei jeweils ein Steuergerät eine oder mehrere Software-Komponenten als Datenquellen aufweisen, die entsprechend der Logging-Kampagne konfiguriert werden können. Die Daten können dann stromabwärts beispielsweise in jedem Steuergerät durch eine jeweilige Konzentrationseinrichtung konzentriert werden, bevor sie an das Zentralsteuergerät übermittelt werden, wo sie wiederum zentral konzentriert werden können. Auf diese Weise kann eine sehr effiziente Datenübertragung auch innerhalb eines Fahrzeugs erreicht werden.
-
Die oben genannte Aufgabe wird erfindungsgemäß auch gelöst durch ein System zum Sammeln von Daten mehrerer Datenquellen mit
- - einer Zentraleinheit,
- - mindestens einem Fahrzeug,
- - den mehreren Datenquellen verteilt über die Zentraleinheit und das mindestens eine Fahrzeug,
- - einer Managementeinrichtung in der Zentraleinheit zum Erstellen einer Logging-Kampagne, die für jede der mehreren Datenquellen eine spezifische Filterkonfiguration umfasst, welche jeweils eine Kennung für die jeweilige Datenquelle und eine oder mehrere Filterbedingungen für die jeweilige Datenquelle aufweist, und
- - einer Konzentrationseinrichtung zum automatischen Verteilen der Filterkonfigurationen der Logging-Kampagne an jede der mehreren Datenquellen, wobei
- - jede Datenquelle dazu ausgebildet ist, sich automatisch mit der jeweils spezifischen Filterkonfiguration zu konfigurieren und Daten zu einer Datensammeleinrichtung der Zentraleinheit entsprechend der jeweiligen Filterkonfiguration zu übertragen.
-
Die oben im Zusammenhang mit dem erfindungsgemäßen Verfahren geschilderten Vorteile und Variationsmöglichkeiten gelten sinngemäß auch für das erfindungsgemäße System. Insbesondere können die im Zusammenhang mit dem Verfahren geschilderten Verfahrensmerkmale als funktionelle Merkmale entsprechender Komponenten des Systems gesehen werden.
-
Optional kann auch ein Computerprogramm bereitgestellt werden, das Befehle umfasst, die bei der Ausführung des Programms durch eine Steuervorrichtung eines Datensystems nach obiger Art dieses veranlassen, ein oben genanntes Verfahren auszuführen. Ferner kann ein computerlesbares Speichermedium bereitgestellt werden, umfassend Befehle, die bei der Ausführung durch eine Steuervorrichtung eines Datensystems nach obiger Art dieses veranlassen, ein oben genanntes Verfahren auszuführen.
-
Die vorliegende Erfindung wird nun anhand von 1 näher erläutert, die schematisch ein Ausführungsbeispiel eines erfindungsgemäßen Verfahrens zum Sammeln von Daten mehrerer Datenquellen in einem Ablaufdiagramm wiedergibt.
-
Dabei können die einzelnen Blöcke auch als entsprechende Hardware-Komponenten eines Systems zum Sammeln von Daten gesehen werden.
-
Die nachfolgend näher geschilderten Ausführungsbeispiele stellen bevorzugte Ausführungsformen der vorliegenden Erfindung dar.
-
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 Logglevel, 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.
-
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
- 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 20200219388 A1 [0004]
- DE 102017218561 A1 [0005]
- US 20200263992 A1 [0006]
- US 20200263995 A1 [0006]
- US 20200263993 A1 [0006]
- EP 3492872 A1 [0007]
- DE 102020007072 A1 [0008]