-
TECHNISCHES GEBIET
-
Die vorliegende Offenlegung bezieht sich auf das Sammeln und Verwalten von Daten, die von einer Vielzahl von Fahrzeugen erzeugt werden.
-
HINTERGRUND
-
Die Angaben in diesem Abschnitt liefern lediglich Hintergrundinformationen im Zusammenhang mit der vorliegenden Offenbarung und stellen nicht unbedingt den Stand der Technik dar.
-
Ein Ereignisdatenrekorder (EDR) ist so konfiguriert, dass er einen Unfall oder ein ähnliches Ereignis erkennt und Informationen über den Fahrzustand eines Fahrzeugs oder die Bedienung durch einen Fahrer innerhalb einer bestimmten Zeit vor und nach dem Ereignis speichert. Mindestens mehrere Parameter, einschließlich Geschwindigkeit, Sicherheitsgurtstatus und Airbag-Auslösestatus, werden für die Rekonstruktion bei forensischen Untersuchungen gespeichert.
-
Die forensische Untersuchung erfolgt in der Regel über einen Fahrzeug-Diagnoseanschluss, z. B. einen On-Board-Computer (OBD)-II-Anschluss, oder durch physische Entnahme eines EDR-Datenspeichers und Auslesen von Daten aus diesem. Die Daten im EDR sind anfällig für Beschädigungen oder Veränderungen aufgrund fehlerhafter Lesetechnik und können nach dem Speichern böswillig manipuliert oder gelöscht werden, was die Gewährleistung der vollständigen Datenintegrität der gespeicherten Daten erschwert.
-
Da immer mehr Fahrzeuge mit ADAS (Advanced Driver Assistance Systems) oder autonomen Fahrfunktionen ausgestattet werden, werden Verkehrsunfälle immer häufiger den Fahrzeugen und nicht den Fahrern zugeschrieben. Um die Unfallursachen richtig zu klären, besteht ein zunehmender Bedarf an Daten, die zusätzlich zu den vom bestehenden Event Data Recorder (Ereignisdatenrekorder; EDR) aufgezeichneten Daten gesammelt werden, wie z. B. zusätzliche Informationen über den Betriebsstatus der ADAS- oder autonomen Fahrfunktionen, die detaillierte Bestimmung des Fahrzeugsystems anhand des Sensoreingangs usw.
-
Mit der Entwicklung der Informations- und Kommunikationstechnologie können solche Fahrzeugdaten in verschiedenen Formen von einem Datenserver in einem Netzwerk gesammelt und verschiedenen Dienstleistern zur Verfügung gestellt werden. Einige der von dem Datenserver gesammelten Informationen können im Hinblick auf den Schutz der Privatsphäre sensibel sein. Da der Betreiber echte Kontroll- und Verkaufsrechte für persönliche Informationen in diesen Datenservern hatte, musste der Einzelne viele Risiken eingehen.
-
Da außerdem Rechtsvorschriften zum Schutz der Privatsphäre, wie die Europäische Datenschutzgrundverordnung (GDPR), umgesetzt wurden, ist es erforderlich, ein System einzuführen, das fahrzeuggenerierte Daten innerhalb der gesetzlichen Grenzen effizient erfassen und nutzen kann.
-
ZUSAMMENFASSUNG
-
[Technisches Problem]
-
Die vorliegende Offenlegung stellt ein allgemeines Konzept für ein Datenspeichersystem eines Fahrzeugs mit einer Kommunikationsfunktion und einem Cloud-Speichersystem vor, das fahrzeuggenerierte Daten sammelt und verwaltet. Das Konzept konzentriert sich auf die Überwindung der Einschränkungen der Datenspeicherung im Fahrzeug und die Maximierung des Benutzerzugriffs auf fahrzeuggenerierte Daten. Die vorliegende Offenlegung stellt insbesondere Verfahren zur Datenspeicherung und -verwaltung vor, die die persönliche Privatsphäre in einem Cloud-System schützen können.
-
[Technische Lösung]
-
Gemäß einem Aspekt der vorliegenden Offenbarung wird ein Verfahren vorgestellt, das von mindestens einem Server in einem Netzwerk durchgeführt wird, zum Sammeln und Verwalten von fahrzeuggenerierten Daten von Fahrzeugen, wobei das Verfahren den Empfang einer Ereignisberichtsnachricht und einer Interaktionsberichtsnachricht von einem Fahrzeug umfasst. Die Ereignisberichtsnachricht umfasst Fahrzeugidentifikationsinformationen und Ereignisdaten, die von einem Ereignisdatenrekorder des Fahrzeugs gespeichert werden, und die Interaktionsberichtsnachricht umfasst die Fahrzeugidentifikationsinformationen und Interaktionsdaten, die auf eine Interaktion zwischen einem autonomen Fahrsystem des Fahrzeugs und einem Fahrer hinweisen. Das Verfahren umfasst ferner das Erzeugen von Verbindungsdaten aus den Fahrzeugidentifikationsinformationen und einem Salt, das Speichern der Fahrzeugidentifikationsinformationen und des Salts in einer ersten Datenbank, das Speichern der Ereignisdaten und der Verbindungsdaten in einer zweiten Datenbank und das Speichern der Interaktionsdaten und der Verbindungsdaten in einer dritten Datenbank.
-
Ausführungsformen des Verfahrens können eines oder mehrere der folgenden Merkmale aufweisen.
-
In einigen Ausführungsformen umfasst das Verfahren ferner das Löschen der Fahrzeugidentifizierungsinformationen oder des Salts aus der ersten Datenbank, wenn es erforderlich ist, eine Verbindung zwischen den Fahrzeugidentifizierungsinformationen und den Ereignisdaten und eine Verbindung zwischen den Fahrzeugidentifizierungsinformationen und den Interaktionsdaten zu entfernen.
-
In einigen Ausführungsformen umfasst das Verfahren ferner das Beibehalten der Ereignisdaten und der Interaktionsdaten in der zweiten Datenbank und der dritten Datenbank und das Löschen der Fahrzeugidentifikationsinformationen des Fahrzeugs oder des Salts aus der ersten Datenbank als Reaktion auf den Ablauf einer von einem Fahrzeugeigentümer des Fahrzeugs festgelegten Gültigkeitsdauer.
-
In einigen Ausführungsformen umfasst das Verfahren ferner das Empfangen einer Anforderungsnachricht von einem Fahrzeugeigentümer des Fahrzeugs, die das Löschen von mindestens einer der Fahrzeugidentifikationsinformationen, der Ereignisdaten und der Interaktionsdaten anfordert, und das Verfahren umfasst ferner das Löschen von mindestens einer der Fahrzeugidentifikationsinformationen, der Verbindungsdaten, der Ereignisdaten und der Interaktionsdaten aus einer zugehörigen Datenbank als Reaktion auf den Empfang der Anforderungsnachricht.
-
In einigen Ausführungsformen umfasst das Verfahren ferner die Abschwächung eines Sicherheitsgrads eines Rechts auf die Nutzung von Ereignisdaten und Interaktionsdaten, die in der zweiten Datenbank und der dritten Datenbank gespeichert sind, im Falle des Löschens der Fahrzeugidentifikationsinformationen oder des Salts aus der ersten Datenbank.
-
In einigen Ausführungsformen können die Ereignisdaten oder Interaktionsdaten, für die den Sicherheitsgrad nicht abgeschwächt ist, aus der zweiten Datenbank oder der dritten Datenbank auf der Grundlage der Verbindungsdaten abgerufen werden, die aus dem in der ersten Datenbank gespeicherten Salt und zugehörigen Fahrzeugidentifizierungsinformationen rekonstruiert wurden, und die Ereignisdaten oder Interaktionsdaten, für die die Sicherheitsstufe abgeschwächt ist, können direkt aus der zweiten Datenbank oder der dritten Datenbank ohne die rekonstruierten Verbindungsdaten abgerufen werden.
-
In einigen Ausführungsformen werden die Verbindungsdaten durch Anwendung einer Einweg-Hash-Funktion auf die Fahrzeugidentifikationsdaten und den Salt erzeugt.
-
In einigen Ausführungsformen ist die Fahrzeugidentifizierungsinformation eine Fahrzeugidentifizierungsnummer (VIN), und die Verbindungsdaten sind eine de-identifizierten Version der VIN, die aus dem Salt und der VIN erzeugt wird. Die de-identifizierte Version der Fahrzeugidentifizierungsnummer wird erzeugt, indem (1) ein Hash-Wert erzeugt wird, indem eine Einweg-Hash-Funktion auf eine Verkettung des Salts und einiger Ziffern der Fahrzeugidentifizierungsnummer angewendet wird, und (2) die einigen Ziffern der Fahrzeugidentifizierungsnummer durch den Hash-Wert ersetzt werden.
-
Gemäß einem Aspekt der vorliegenden Offenbarung wird ein Cloud-Speichersystem zum Sammeln und Verwalten von fahrzeuggenerierten Daten von Fahrzeugen bereitgestellt. Das Cloud-Speichersystem wird durch mindestens einen Server in einem Netzwerk implementiert und umfasst Mittel zum Empfangen einer Ereignisberichtsnachricht und einer Interaktionsberichtsnachricht von einem Fahrzeug. Die Ereignisberichtsnachricht umfasst Fahrzeugidentifikationsinformationen und Ereignisdaten, die von einem Ereignisdatenrekorder des Fahrzeugs gespeichert werden, und die Interaktionsberichtsnachricht umfasst die Fahrzeugidentifikationsinformationen und Interaktionsdaten, die eine Interaktion zwischen einem autonomen Fahrsystem des Fahrzeugs und einem Fahrer anzeigen. Das System umfasst ferner Mittel zum Erzeugen von Verbindungsdaten aus den Fahrzeugidentifikationsinformationen und einem Salt, Mittel zum Speichern der Fahrzeugidentifikationsinformationen und des Salts in einer ersten Datenbank, und Mittel zum Speichern der Ereignisdaten und der Verbindungsdaten in einer zweiten Datenbank und zum Speichern der Interaktionsdaten und der Verbindungsdaten in einer dritten Datenbank.
-
[Vorteilhafte Effekte]
-
Ein zentralisiertes System, das EDR/DSSAD-Daten (Datenspeichersystem für automatisiert fahrende Fahrzeuge) von Fahrzeugen sammelt und verwaltet, kann Fahrzeugdatenrekorder von Speicherplatzbeschränkungen befreien. Ein Ereignisdatenrekorder kann beispielsweise so konzipiert sein, dass er EDR-Daten zu einem zuvor ignorierten geringfügigen Zwischenfall unter Verwendung von mehr Auslösebedingungen als herkömmlich sammelt, und er kann so konzipiert sein, dass er eine größere Vielfalt von Datenelementen sammelt (z. B. Radar-/Lidardaten, die vor und nach einem Ereignis gewonnen wurden, V2X-Nachrichten usw.), was die Ex-post-Analyse eines Ereignisses weiter erleichtern kann.
-
Einzelpersonen oder Institutionen können interessierende EDR/DSSAD-Daten leicht und zeitnah von einem zentralisierten System abrufen. Darüber hinaus können EDR-/DSSAD-Daten, die in einem vertrauenswürdigen Netz gespeichert sind, für forensische Untersuchungen nützlich sein, bei denen die Integrität der Daten sichergestellt werden muss. EDR-Daten und DSSAD-Daten ergänzen sich gegenseitig. Insbesondere DSSAD-Daten sind nützlich, um eine Person zu identifizieren, die das Fahrzeug zum Zeitpunkt des Zusammenstoßes gesteuert hat.
-
In dem vorgeschlagenen zentralisierten System werden die in jedem Fahrzeug aufgezeichneten EDR/DSSAD-Daten in Datenbanken des Netzes zusammen mit Verbindungsdaten gespeichert und verwaltet, die von Fahrzeugidentifizierungsinformationen (VII) getrennt sind, was es einem Dritten ermöglicht, das betreffende Fahrzeug zu identifizieren oder zu verfolgen. Die Verbindungsdaten können auf der Grundlage der Fahrzeugidentifizierungsinformationen und des in einer VII-Datenbank gespeicherten Salts kryptografisch (neu) erzeugt werden. Dementsprechend kann durch Löschen der Fahrzeugidentifizierungsinformationen oder des Salts aus der VII-Datenbank die Assoziation zwischen den Fahrzeugidentifizierungsinformationen und den zugehörigen EDR/DSSAD-Daten aufgehoben werden.
-
Figurenliste
-
- 1 ist ein schematisches Diagramm, das ein zentralisiertes System zum Sammeln und Verwalten von Ereignisdaten von Fahrzeugen gemäß einer Ausführungsform der vorliegenden Offenbarung zeigt.
- 2 ist ein konzeptionelles Diagramm, das ein beispielhaftes Verfahren zur getrennten Speicherung von Fahrzeugidentifizierungsinformationen (VII), EDR-Daten und DSSAD-Daten in Datenbanken gemäß einer Ausführungsform der vorliegenden Offenbarung zeigt.
- 3 ist ein Diagramm zur Erläuterung der Details einer Fahrzeugidentifikationsnummer (VIN).
- 4 zeigt ein Beispiel für eine de-identifizierte Version der Fahrgestellnummer und einen dadurch identifizierten EDR gemäß einer Ausführungsform der vorliegenden Offenbarung.
- 5 ist ein konzeptionelles Diagramm, das ein beispielhaftes Verfahren zur Abfrage und Bereitstellung von EDR/DSSAD-Daten für ein bestimmtes Fahrzeug durch ein Cloud-Speichersystem gemäß einer Ausführungsform der vorliegenden Offenbarung veranschaulicht.
- 6 ist ein konzeptionelles Diagramm, das ein beispielhaftes Verfahren für ein Cloud-Speichersystem zum Löschen von VII/EDR/DSSAD-Daten auf Anfrage eines Fahrzeugbesitzers gemäß einer Ausführungsform der vorliegenden Offenlegung veranschaulicht.
- 7 ist ein Flussdiagramm, das einen EDR-Datensammlungsprozess des in 1 gezeigten Systems in Übereinstimmung mit einer Ausführungsform der vorliegenden Offenbarung illustriert.
-
DETAILLIERTE BESCHREIBUNG
-
Nachstehend werden einige Ausführungsformen der vorliegenden Offenbarung unter Bezugnahme auf die beiliegenden Zeichnungen ausführlich beschrieben. In der nachstehenden Beschreibung bezeichnen gleiche Bezugsziffern gleiche Elemente, auch wenn die Elemente in verschiedenen Zeichnungen dargestellt sind. Ferner wird in der folgenden Beschreibung einiger Ausführungsformen aus Gründen der Übersichtlichkeit und der Kürze auf eine detaillierte Beschreibung bekannter Funktionen und Konfigurationen verzichtet.
-
1 ist ein schematisches Diagramm, das ein zentralisiertes System zum Sammeln und Verwalten von fahrzeuggenerierten Daten von Fahrzeugen gemäß einer Ausführungsform der vorliegenden Offenbarung zeigt.
-
Das System umfasst ein fahrzeuginternes Datenaufzeichnungssystem 10, das in einem Fahrzeug bereitgestellt wird, und ein Cloud-Speichersystem 20, das als Server in einem Netzwerk implementiert ist/sind. Bei dem/den Server(n), die das Cloud-Speichersystem 20 implementieren, kann es sich um Server handeln, die von einem Fahrzeughersteller betrieben werden, oder um Server, die von einem vom Fahrzeughersteller unabhängigen Betreiber betrieben werden, oder um eine Kombination davon.
-
Ein Fahrzeug ist so konfiguriert, dass es ganz oder teilweise in einem autonomen Fahrmodus betrieben werden kann und kann daher als „autonom fahrendes Fahrzeug“ bezeichnet werden. Beispielsweise kann ein autonomes Fahrsystem 14 Informationen von einem Sensorsystem 13 empfangen und auf der Grundlage der empfangenen Informationen einen oder mehrere Steuerprozesse automatisiert ausführen (z. B. die Lenkung so einstellen, dass erkannte Hindernisse umfahren werden).
-
Ein Fahrzeug kann völlig autonom oder teilautonom sein. Bei einem teilautonomen Fahrzeug können einige Funktionen vorübergehend oder ständig manuell von einem Fahrer gesteuert werden. Darüber hinaus kann das vollständig autonome Fahrzeug so konfiguriert sein, dass es zwischen einem vollständig manuellen Betriebsmodus und einem teilautonomen Betriebsmodus und/oder einem vollständig autonomen Betriebsmodus umschaltbar ist.
-
Das bordeigene d. h. fahrzeuginterne Datenaufzeichnungssystem 10 kann so konfiguriert sein, dass es verschiedene Arten von Daten in Bezug auf den Fahrzeugbetrieb oder das Fahrerverhalten erzeugt, aufzeichnet oder speichert. Das bordeigene Datenaufzeichnungssystem 10 umfasst zwei Arten von Datenaufzeichnungsgeräten: einen Ereignisdatenrekorder (EDR) 11 und ein Datenspeichersystem für automatisiert fahrende Fahrzeuge (DSSAD) 12. Sie zeichnen fahrzeuggenerierte Daten für unterschiedliche Zwecke auf.
-
Der Zweck des EDR 11 besteht darin, Fahrzeuginformationen zu bestimmten Ereignissen wie der Auslösung des Airbags zu speichern. Die Daten des EDR 11 werden für die Analyse und Rekonstruktion von Kollisionen verwendet. Der Zweck des DSSAD 12 ist die Aufzeichnung aller vordefinierten Interaktionen zwischen einem Fahrer und einem autonomen Fahrsystem. Die Daten des DSSAD 12, die in der Regel im Zeitstempelformat gespeichert werden, dienen der Identifizierung einer Person, die das Fahrzeug zu einem bestimmten Zeitpunkt gesteuert hat. Die Daten des EDR 11 und die Daten des DSSAD 12 werden bei forensischen Untersuchungen komplementär zueinander verwendet, und insbesondere die Daten des DSSAD 12 sind nützlich, um eine Person zu identifizieren, die das Fahrzeug zum Zeitpunkt der Kollision gesteuert hat.
-
Der EDR 11 kann so konfiguriert sein, dass er Daten von verschiedenen Sensoren und/oder elektronischen Steuergeräten (ECU), die im Fahrzeug eingebaut sind, empfängt. Der EDR 11 verfügt über einen flüchtigen Speicher des EDR 11, in dem Daten für einen bestimmten Zeitraum vorübergehend gespeichert sind, während sie ständig aktualisiert werden. Der EDR 11 kann auf eine Erkennung des Auftretens eines oder mehrerer vordefinierter Ereignisse reagieren, um die Daten aufzuzeichnen, die in dem flüchtigen Speicher innerhalb einer vorgegebenen Zeit vor und nach der Erkennung gespeichert werden. Ein solches Ereignis kann insbesondere eine Verkehrskollision sein. Eine Verkehrskollision kann beispielsweise erkannt werden, wenn eine irreversible Sicherheitseinrichtung wie ein Airbag oder eine Gurtstraffervorrichtung ausgelöst wird. Eine Verkehrskollision kann auch beim Auftreten einer Beschleunigung/Verzögerung erkannt werden, die einen vordefinierten Schwellenwert überschreitet (z. B. eine Geschwindigkeitsänderung von 8 km/h oder mehr innerhalb von etwa 150 ms). Das/die vordefinierte(n) Ereignis(e) kann/können auch eine Fehlfunktion der Hauptfunktion des Fahrzeugs umfassen.
-
Der EDR 11 kann so konfiguriert sein, dass er ein oder mehrere Auslösesignale empfängt, die das Auftreten eines Ereignisses von der/den elektronischen Steuereinheit(en), wie z. B. einer Airbag-Steuereinheit (ACU), melden. Auf den EDR 11 kann für Werte zugegriffen werden, die von mindestens einem oder mehreren Sensoren des Sensorsystems 13 gemessen werden. Mindestens ein Sensor des Sensorsystems 13 kann so konfiguriert sein, dass er die Fahrzeuggeschwindigkeit/Beschleunigung/Verzögerung/Fahrstrecke/geografische Position und Ähnliches erfasst. Der EDR 11 kann als Funktionsmodul in die Airbag-Steuereinheit (ACU) integriert werden.
-
Bei den vom EDR 11 aufgezeichneten Daten kann es sich um Daten handeln, die für die Analyse von Verkehrskollisionen geeignet sind, wie z. B. Daten zur Fahrzeugdynamik, zum Fahrerverhalten und zum Betriebszustand eines Fahrzeugsicherheitssystems. Der EDR 11 kann so konfiguriert sein, dass er aufgezeichnete Daten (nachstehend als „EDR-Daten“ oder „Ereignisdaten“ bezeichnet) an ein Telekommunikationsgerät 15 überträgt, damit sie an das Cloud-Speichersystem 20 übermittelt werden.
-
Das autonome Fahrsystem 14 kann so konfiguriert sein, dass es Interaktionssignale erzeugt, die auf Interaktionen zwischen einem Fahrer und dem autonomen Fahrsystem 14 hinweisen. Diese Interaktionssignale können ein Signal enthalten, das anzeigt, ob eine oder mehrere autonome Fahrfunktionen gerade aktiv sind. Zum Beispiel kann das autonome Fahrsystem 14 ein Signal erzeugen, das anzeigt, ob eine adaptive Geschwindigkeitsregelungsfunktion (ACC) gerade aktiv ist. Ein weiteres Beispiel: Das autonome Fahrsystem 14 kann ein Signal erzeugen, das anzeigt, ob das Fahren eines Fahrzeugs derzeit vollautomatisch und nicht manuell gesteuert wird. Darüber hinaus können diese Interaktionssignale auch Signale enthalten, die eine Übergangsanforderung anzeigen, die angibt, dass eine Steuerung der Fahraufgabe an einen Fahrer übernommen werden muss, und Signale, die anzeigen, dass eine Steuerung der Fahraufgabe an den Fahrer übernommen wurde. Das autonome Fahrsystem 14 kann Interaktionssignale über einen Datenbus (z. B. CAN-Bus, Ethernet-Bus usw.) an das DSSAD 12 übermitteln.
-
Das DSSAD 12 kann Interaktionsdaten, die eine Interaktion zwischen einem Fahrer und dem autonomen Fahrsystem darstellen, in einem internen nichtflüchtigen Speicher auf der Grundlage der vom autonomen Fahrsystem 14 empfangenen Interaktionssignale speichern. Das DSSAD 12 ist in einem Fahrzeug installiert, das mit einem hochautomatisierten Fahrsystem ausgestattet ist (z. B. SAE-Klassifizierung Stufe 3, 4, 5), und ist ein Datenspeichersystem, das darauf abzielt, zu klären, „welche Personen zum Fahren aufgefordert wurden“ und „welche Personen tatsächlich gefahren sind“. Während des Übergangsprozesses (d. h. nach der Aufforderung zum Übergang und bis zur tatsächlichen Übernahme der Steuerung durch einen Fahrer) können die „zum Fahren aufgeforderte Person“ und die „Person, die tatsächlich gefahren ist“ voneinander abweichen.
-
Zu den Interaktionsdaten können mit Zeitstempeln versehene Datenelemente gehören, die bestimmte Interaktionsereignisse darstellen, wie z. B. die Änderung des Zustands (ausgeschaltet, aktiviert, Übergangsanforderung, Übernahme) des autonomen Fahrsystems, das Starten und Beenden des Minimal-Risk-Manövers (MRM) durch das autonome Fahrsystem und die Übernahme der Steuerung einer Fahraufgabe durch einen Fahrer. Das DSSAD 12 kann die gespeicherten Interaktionsdaten (nachstehend auch als „DSSAD-Daten“ bezeichnet) an das Telekommunikationsgerät 15 zur Übertragung an das Cloud-Speichersystem 20 übermitteln.
-
DSSAD-Daten können drei Felder enthalten, darunter einen Zeitstempel, ein Typkennzeichen und ein Auftritts-Ursache-Feld. Das Zeitstempelfeld gibt den Zeitpunkt an, zu dem eine bestimmte Interaktion zwischen einem Fahrer und einem System stattgefunden hat. DSSAD-Daten erfordern zu diesem Zweck einen hochpräzisen Zeitstempel. Das Feld Typkennzeichen gibt die Art der Interaktion zwischen dem Fahrer und dem System an, z. B. eine Übergangsanforderung oder ein Manöver mit minimalem Risiko. Das Auftritts-Ursache-Feld gibt die Ursache der Interaktion an. Das Auftritts-Ursache-Feld kann ein optionales Feld sein.
-
Das Telekommunikationsgerät 15 kann ein drahtgebundenes oder drahtloses Telekommunikationsgerät sein, das das interne Netzwerk des Fahrzeugs mit einem externen Kommunikationsnetzwerk verbindet. Bei dem Telekommunikationsgerät 15 kann es sich beispielsweise um eine Telematikeinheit (TMU) oder einen kabelgebundenen/drahtlosen Dongle handeln, der in einen OBD-II-Anschluss eingesteckt wird. Das Telekommunikationsgerät 15 kann einen drahtlosen Transceiver enthalten, der zur zellularen Kommunikation wie GSM/WCDMA/LTE/5G oder zur drahtlosen Kommunikation im Nahbereich wie WLAN, c-V2X, WAVE, DSRC, Bluetooth usw. fähig ist.
-
Das Telekommunikationsgerät 15 kann so konfiguriert sein, dass es eine Ereignisberichtsnachricht erzeugt, wenn EDR-Daten vom EDR 11 empfangen werden. Das Telekommunikationsgerät 15 kann so konfiguriert sein, dass es die Ereignisberichtsnachricht über das Kommunikationsnetz an das Cloud-Speichersystem 20 übermittelt. Die Ereignisberichtsnachricht kann Fahrzeugidentifizierungsinformationen (VII) und EDR-Daten enthalten, die vom EDR 11 empfangen wurden. In einer typischen Ausführungsform können die VII eine Fahrzeugidentifikationsnummer (VIN) sein, die eine 17-stellige eindeutige Kennung aus Zahlen und Buchstaben ist, die einzelnen Fahrzeugen von den Fahrzeugherstellern zugewiesen wird. Alternativ kann es sich bei den VII um eine Fahrzeugregistrierungsnummer (oder Kennzeicheninformationen), eine eindeutige Kennung, die von dem Telekommunikationsgerät 15 für die Kommunikation verwendet wird, ein (langfristiges oder kurzfristiges) Zertifikat, das einem Fahrzeug für die V2X-Kommunikation zugewiesen wurde, und Ähnliches handeln. Die Ereignisberichtsnachricht kann darüber hinaus zusätzliche Informationen wie den geografischen Ort, das Datum und die Uhrzeit des Auftretens eines Ereignisses enthalten.
-
Das Telekommunikationsgerät 15 kann eine Interaktionsberichtsnachricht erzeugen, wenn DSSAD-Daten von dem DSSAD 12 empfangen werden. Das Telekommunikationsgerät 15 kann die Interaktionsberichtsnachricht über das Kommunikationsnetz an das Cloud-Speichersystem 20 übertragen. Die Interaktionsberichtsnachricht kann die Fahrzeugidentifikationsinformationen (VII) und die vom DSSAD 12 empfangenen DSSAD-Daten enthalten.
-
Das Cloud-Speichersystem 20 ist ein Datenverwaltungssystem, das mit Servern in einem Netzwerk implementiert ist und EDR-Daten und DSSAD-Daten von mehreren Fahrzeugen sammelt und verwaltet.
-
Das Cloud-Speichersystem 20 kann eine Ereignisberichtsnachricht und eine Interaktionsberichtsnachricht von einer Vielzahl von Fahrzeugen empfangen. Bei Berichtsmeldungen, die von dem Fahrzeug empfangen werden, trennt das Cloud-Speichersystem 20 die VII von den EDR/DSSAD-Daten, die es einem Dritten ermöglichen, das zugehörige Fahrzeug oder die zugehörige Person zu identifizieren oder zu verfolgen, so dass die VII und die EDR/DSSAD-Daten in unterschiedlichen Datenbanken gespeichert werden können.
-
Das Cloud-Speichersystem 20 kann als Reaktion auf eine Anfrage eines Nutzers 30, der die EDR/DSSAD-Daten nutzen möchte, anonymisierte EDR/DSSAD-Daten bereitstellen, in denen ein bestimmtes Fahrzeug oder eine bestimmte Person nicht identifiziert wird, oder EDR/DSSAD-Daten bereitstellen, in denen ein bestimmtes Fahrzeug oder eine bestimmte Person identifiziert wird. Der Nutzer 30 kann ein Fahrzeugeigentümer, ein Fahrer, eine Versicherungsgesellschaft, eine Regierungsbehörde, ein Forscher oder ein Fahrzeughersteller sein, der EDR/DSSAD-Daten nutzen möchte. Für EDR/DSSAD-Daten, in denen ein bestimmtes Fahrzeug oder eine bestimmte Person identifiziert wurde, muss das Cloud-Speichersystem 20 nur Ermittlern oder anderen vom jeweiligen Fahrzeugeigentümer autorisierten Nutzern zur Verfügung gestellt werden, es sei denn, dies ist durch einen Gerichtsbeschluss, einen Durchsuchungsbefehl und/oder andere geltende Gesetze und Vorschriften gestattet.
-
Das Cloud-Speicher-System 20 kann so implementiert werden, dass es einen Dienstmanager 21, einen Regel-/Richtlinienmanager 23, einen Repository-Koordinator 25, eine Cloud-Schnittstelle 27 und ein Daten-Repository 29 umfasst. Die Datenablage 29 kann durch mindestens einen Datenserver implementiert werden.
-
Der Dienstmanager 21 ist eine funktionale Einheit, die EDR/DSSAD-Daten von Fahrzeugen sammelt und verwaltet und einem Nutzer anonymisierte EDR/DSSAD-Daten, in denen ein bestimmtes Fahrzeug oder eine bestimmte Person nicht identifiziert ist, oder EDR/DSSAD-Daten, in denen ein bestimmtes Fahrzeug oder eine bestimmte Person identifiziert ist, zur Verfügung stellt. Der Regel-/Richtlinienmanager 23 ist eine funktionale Einheit zur Verwaltung von Benutzerprofilen und Datenschutzrichtlinien, die in dem Daten-Repository 29 gespeichert sind. Der Repository-Koordinator 25 ist eine funktionale Einheit zur getrennten Speicherung der EDR-Daten, der DSSAD-Daten und der VII-Daten in den Datenbanken des Daten-Repository 29 und zum Abrufen der EDR-Daten, der DSSAD-Daten und der VII-Daten aus den Datenbanken des Datenspeichers 29. Die Cloud-Schnittstelle 27 ist eine funktionale Einheit, die als Gateway des Cloud-Speichersystems 20 dient.
-
Das Daten-Repository 29 verfügt über Datenbanken, die Benutzerprofile, Datenschutzrichtlinien, VII-Daten, EDR-Daten und DSSAD-Daten aufzeichnen. Das Benutzerprofil enthält Abonnementinformationen von Einzelpersonen, Unternehmen oder Organisationen, die das Cloud-Speichersystem 20 abonniert haben. Die Datenschutzrichtlinie enthält eine Reihe von Datenschutzregeln, die für die Erfassung und Verwaltung der EDR-/DSSAD-Daten der einzelnen Fahrzeuge gelten.
-
Der Regel-/Richtlinienmanager 23 kann so konfiguriert sein, dass er von einem Fahrzeugeigentümer Einstellungen für Datenschutzoptionen für personenbezogene Daten (VII/EDR/DSSAD-Daten) empfängt, die vom Fahrzeug des Eigentümers erfasst werden, und einen Satz von Datenschutzregeln (d. h. Datenschutzrichtlinien) erzeugt, die auf die Erfassung, Verwaltung und Verwendung personenbezogener Daten gemäß den empfangenen Einstellungen für Datenschutzoptionen anzuwenden sind.
-
Unter Bezugnahme auf 2 wird ein beispielhaftes Verfahren beschrieben, bei dem das Cloud-Speichersystem 20 die VII, die EDR-Daten und die DSSAD-Daten, die in von einem Fahrzeug empfangenen Berichtsnachrichten enthalten sind, getrennt in Datenbanken speichert.
-
Die Cloud-Schnittstelle 27 kann eine Ereignismeldung oder eine Interaktionsmeldung von einem Fahrzeug über einen Sicherheitskanal empfangen. Jede Berichtsnachricht kann die EDR-Daten und die VII enthalten oder die DSSAD-Daten und die VII enthalten.
-
Der Repository-Koordinator 25 kann Verbindungsdaten zur Aufrechterhaltung einer Assoziation zwischen den EDR/DSSAD-Daten und der VII generieren, die in verschiedenen Datenbanken gespeichert werden würden. Die Verbindungsdaten können zumindest teilweise auf der Grundlage der VII und eines zufällig generierten Wertes (nachstehend als „Sait“ bezeichnet) erzeugt werden. Die Verbindungsdaten selbst enthalten jedoch keine aussagekräftigen Informationen zur Identifizierung eines Fahrzeugs oder einer Person.
-
Der Repository-Koordinator 25 kann die in jeder Berichtsmeldung enthaltenen Informationen in zwei Datensätze aufteilen. Ein erster Datensatz enthält EDR/DSSAD-Daten, aber nicht die VII, und ein zweiter Datensatz enthält die VII, aber keine EDR/DSSAD-Daten. Mit anderen Worten, eine Fahrzeugidentifikationsnummer (VIN) oder andere eindeutige Daten, die die Identifizierung oder Verfolgung eines Fahrzeugs oder einer beteiligten Person ermöglichen, werden von den EDR/DSSAD-Daten getrennt.
-
Der Repository-Koordinator 25 kann den ersten Datensatz, zu dem Verbindungsdaten hinzugefügt werden (d. h. Verbindungsdaten und EDR/DSSAD-Daten), in EDR/DSSAD-Datenbanken speichern. Der Repository-Koordinator 25 kann den zweiten Datensatz, zu dem der Salt hinzugefügt wird (d. h. Salt und VII), in der VII-Datenbank speichern.
-
Bei den Verbindungsdaten kann es sich um einen Pseudonym-Identifikator handeln, der zumindest teilweise auf der Grundlage der VII erzeugt wird. In einigen Ausführungsformen kann der Pseudonym-Identifikator durch die Anwendung einer Einweg-Hash-Funktion auf die VII erzeugt werden. Die Einweg-Hash-Funktion macht es unmöglich, die VII oder andere nützliche Informationen aus dem Pseudonym-Identifikator zu extrahieren. Vorzugsweise kann der Pseudonym-Identifikator durch Anwendung einer Einweg-Hash-Funktion auf die Verkettung von VII und einem Salt erzeugt werden. Der zur Erzeugung des Pseudonym-Identifikators verwendete Salt kann in der VII-Datenbank zusammen mit der zugehörigen VII gespeichert werden. Eine Einweg-Hash-Funktion wurde hier als Beispiel beschrieben, es können aber auch andere Arten von kryptographischen Algorithmen zur Erzeugung pseudonymer Identifikatoren verwendet werden.
-
In einigen Fällen kann es sich bei den Verbindungsdaten um eine de-identifizierte Version der Fahrzeugidentifikationsnummer (VIN) handeln. Wie voranstehend beschrieben, ist die VIN ein 17-stelliger eindeutiger Identifizierer, der sich aus Zahlen und Buchstaben zusammensetzt und den einzelnen Fahrzeugen von den Fahrzeugherstellern zugewiesen wird. Die de-identifizierte Version der VIN kann durch kryptografische De-Identifizierung mindestens einiger Ziffern einer ursprünglichen VIN einschließlich einer Produktionsseriennummer erzeugt werden.
-
Wie nachstehend erläutert wird, hat jede Ziffer einer VIN einen bestimmten Zweck.
-
3 ist ein Diagramm zur Erläuterung der Details einer Fahrzeugidentifikationsnummer (VIN).
-
Die ersten drei Ziffern der Fahrgestellnummer (VIN), die als WMI (World Manufacturer Identifier) oder WMI-Code bezeichnet werden, geben Auskunft über den Hersteller eines Fahrzeugs und den geografischen Standort, an dem das Fahrzeug hergestellt wurde.
-
Die erste Ziffer der VIN steht für das Land, in dem das Fahrzeug hergestellt wurde. Diese Ziffer kann ein Buchstabe oder eine Zahl sein. Zum Beispiel steht „1“, „4“ oder „5“ in der ersten Ziffer für das Ursprungsland Amerika. „2“ steht für Kanada, „3“ für Mexiko, „6“ für Australien, „A“ für Südafrika, „J“ für Japan, „L“ für China und „K“ für Korea.
-
Die zweite Ziffer der VIN steht für den Fahrzeughersteller, sollte aber mit der ersten Ziffer (für das Herstellungsland) gepaart werden, um den Hersteller genau zu entschlüsseln. Zum Beispiel steht eine VIN, die mit „1C“ beginnt, für ein von Chrysler in Amerika hergestelltes Fahrzeug, und eine VIN, die mit „AC“ beginnt, für ein von Hyundai in Südafrika hergestelltes Fahrzeug.
-
Die dritte Ziffer steht für einen Fahrzeugtyp oder einen Fertigungsbereich. Bei einer VIN, die mit „WV1“ beginnt, steht „W“ für Deutschland als Herstellerland und „V“ für Volkswagen als Hersteller. Die „1“ steht für ein Nutzfahrzeug von Volkswagen. Die VINs von Volkswagen Bussen oder Transportern beginnen mit „WV2“, und die VINs von Volkswagen Lastwagen beginnen mit „WV3“.
-
Die vierte bis achte Ziffer der Fahrgestellnummer (VIN) bildet einen Fahrzeugbeschreibungsabschnitt (VDS) und steht für Fahrzeugmerkmale wie Karosserieform, Motortyp, Modell und Baureihe. Jeder Hersteller verwendet diese fünfstelligen Felder auf seine eigene Weise.
-
Die neunte Ziffer ist eine Prüfziffer zur Identifizierung einer ungültigen Fahrgestellnummer. Diese Ziffer wird aus den Zahlenwerten der ersten acht Ziffern und der letzten acht Ziffern nach einer mathematischen Formel ermittelt.
-
Die zehnten bis siebzehnten Ziffern der VIN sind als Fahrzeugidentifizierungsabschnitt (VIS) bekannt. Sie enthalten eine wesentlich detailliertere Beschreibung des jeweiligen Fahrzeugs.
-
Die zehnte Ziffer steht für das Modelljahr des Fahrzeugs. Die Buchstaben von B bis Y entsprechen den Modellen zwischen 1981 und 2000. VINs verwenden kein I, O, Q, U oder Z. Zwischen den Jahren 2001 und 2009 wurden Ziffern von 1 bis 9 anstelle von Buchstaben verwendet. Für die Jahre 2010 bis 2030 wird das englische Alphabet verwendet, beginnend mit A. Modelljahre von 2000 oder später sind wie folgt: Y=2000, 1=2001, 2=2002, 3=2003, ..., 9=2009, A=2010, B=2011, C=2012, ..., K=2019, und L=2020.
-
Die elfte Ziffer steht für ein Montagewerk, in dem das Fahrzeug montiert wurde. Jede VM hat ihren eigenen Satz von Werkscodes. Die letzten sechs Ziffern (von der zwölften bis zur siebzehnten Stelle) stehen für die Produktionsseriennummer des Fahrzeugs.
-
Der Repository-Koordinator 25 analysiert die VIN, um eine Seriennummer zu extrahieren, und wendet eine Einweg-Hash-Funktion auf die Verkettung des Salts und der Seriennummer an, um einen Hash-Wert zu erzeugen. Der Repository- Koordinator 25 kann eine anonymisierte d. h. de-identifizierte Version der VIN erzeugen, indem er die Seriennummer der VIN durch den erzeugten Hash-Wert ersetzt. Mit anderen Worten, die de-identifizierte Version der VIN kann eine maskierte Produktionsseriennummer aufweisen.
-
4 zeigt ein Beispiel für eine de-identifizierte d. h. anonymisierte Version einer VIB. In der de-identifizierten Version einer VIN sind andere Ziffern als die Produktionsseriennummer Klartext und ermöglichen so eine aussagekräftige statistische Analyse von EDR-Daten, die von mehreren Fahrzeugen gesammelt wurden. So ist es beispielsweise möglich, EDR-Daten zu analysieren, die von Fahrzeugen des „Modells 2018 Avante, hergestellt in Nordamerika“ stammen.
-
Im Falle eines Modells mit einer sehr kleinen Produktionsnummer können Informationen wie Modell, Serie und Modelljahr eines Fahrzeugs die Rückverfolgung des Fahrzeugs oder eines zugehörigen Eigentümers ermöglichen. Dementsprechend kann im Falle eines solchen Modells ein ähnliches Verfahren wie bei der De-Identifizierung einer Produktionsseriennummer zumindest für einige der zehnten bis siebzehnten Ziffern einer VIN, die einem VIS entsprechen, und für die vierten bis achten Ziffern der Fahrgestellnummer, die einer VIS entsprechen, weiter durchgeführt werden.
-
Die Verbindungsdaten (insbesondere die pseudonymen Kennungen d.h. Identifizierer) selbst enthalten keine aussagekräftigen Informationen zur Identifizierung eines Fahrzeugs oder einer Person, aber die Verbindungsdaten können auf der Grundlage der in der VII-Datenbank gespeicherten Fahrzeugidentifizierungsinformationen (VII) und des Salts kryptografisch rekonstruiert werden. Dementsprechend kann die Beziehung zwischen den VII- und den EDR/DSSAD-Daten von der VII-Datenbank zu den EDR/DSSAD-Datenbanken verfolgt werden, in umgekehrter Richtung ist eine Verfolgung jedoch unmöglich. Es sei darauf hingewiesen, dass in einigen Ausführungsformen ein Betreiber von EDR/DSSAD-Datenbanken ein Dienstanbieter sein kann, der unabhängig vom Betreiber anderer funktionaler Elemente des Cloud-Speichersystems 20 einschließlich der Vll-Datenbank ist. Solange die VII-Datenbank sicher verwaltet wird, können solche unabhängigen Diensteanbieter EDR/DSSAD-Daten mit geringem Risiko für die Privatsphäre des Fahrzeugeigentümers nutzen oder weitergeben.
-
Durch das Löschen der Fahrzeugidentifizierungsinformationen oder des zur Rekonstruktion der Verbindungsdaten verwendeten Salts aus der VII-Datenbank kann außerdem die Assoziation zwischen den Fahrzeugidentifizierungsinformationen und den zugehörigen EDR/DSSAD-Daten aufgehoben werden. Wenn es erforderlich ist, eine Assoziation zwischen den Fahrzeugidentifizierungsinformationen und den EDR/DSSAD-Daten aufzuheben, behält der Repository-Koordinator 25 die EDR/DSSAD-Daten in den zugehörigen Datenbanken bei, kann aber die Fahrzeugidentifizierungsinformationen oder den Salt aus der Vll-Datenbank löschen. Dies kann nützlich sein, wenn die Betreiber der VII-Datenbank und der EDR/DSSAD-Datenbanken unterschiedlich sind.
-
Unter Bezugnahme auf 5 wird ein beispielhaftes Verfahren für das Cloud-Speichersystem 20 zur Abfrage und Bereitstellung von EDR/DSSAD-Daten für ein bestimmtes Fahrzeug beschrieben.
-
Beim Empfang einer Datenanforderungsnachricht, in der EDR/DSSAD-Daten für ein bestimmtes Fahrzeug über den Sicherheitskanal angefordert werden, kann die Cloud-Schnittstelle 27 authentifizieren, ob es sich bei dem Anforderer um einen Fahrzeugeigentümer handelt, der das Datensubjekt ist, oder um einen Dritten mit legitimer Befugnis. Die Datenanforderungsnachricht kann Authentifizierungsinformationen und VII eines bestimmten Fahrzeugs enthalten. Wenn die Authentifizierung erfolgreich ist, kann der Repository-Koordinator 25 den Salt, der zusammen mit dem VII eines Fahrzeugs gespeichert ist, durch Abfrage der VII-Datenbank erhalten. Der Repository-Koordinator 25 kann die Verbindungsdaten aus VII und dem Salt rekonstruieren. Der Repository-Koordinator 25 kann EDR-Daten und DSSAD-Daten aus der EDR-Datenbank bzw. der DSSAD-Datenbank unter Verwendung der Verbindungsdaten abrufen. Der Repository-Koordinator kann Datenanfragen und daraus resultierende Abfrageaufgaben protokollieren und die EDR-Daten und DSSAD-Daten an einen Anfrager zurücksenden.
-
Die meisten datenschutzrechtlichen Vorschriften, wie z. B. die DSGVO, gewährleisten, dass die betroffenen Personen das Recht haben, die Verwendung, Verwaltung und Verfügung über die Daten zu kontrollieren. Zu diesem Zweck kann das Cloud-Speichersystem 20 eine Datenschutzrichtlinie mit einer Reihe von Datenschutzregeln festlegen, die für ein Verfahren zur Sammlung und Verwaltung von EDR/DSSAD-Daten von jedem Fahrzeug anzuwenden sind.
-
Der Regel-/Richtlinienmanager 23 kann einen Webserver betreiben, der eine grafische Benutzeroberfläche bereitstellt, über die ein Fahrzeugeigentümer eine oder mehrere Datenschutzoptionen auswählen kann, die für EDR/DSSAD-Daten gelten sollen. Der Regel-/Richtlinienmanager 23 des Cloud-Speichersystems 20 kann von dem Fahrzeugeigentümer eine Auswahl von Datenschutzoptionen für die EDR/DSSAD-Daten des Fahrzeugs erhalten. Die Auswahl der Datenschutzoptionen kann erfolgen, wenn der Fahrzeugeigentümer das Cloud-Speichersystem 20 abonniert oder sein Fahrzeug registriert, oder zu einem späteren Zeitpunkt nach der Registrierung. Beispielhafte Datenschutzoptionen, die ausgewählt werden können, sind aufgeführt.
- - Opt-out: eine Option für den Fahrzeughalter (d. h. den Fahrzeugeigentümer), um ein oder mehrere Datenelemente anzugeben, die nicht am Fahrzeug des Halters gesammelt werden dürfen.
- - Opt-in: eine Option für den Fahrzeughalter, ein oder mehrere Datenelemente anzugeben, die von seinem Fahrzeug gesammelt werden dürfen.
- - Eingeschränkte Nutzung: eine Option für den Fahrzeughalter, um die Zwecke, für die die gesammelten Daten verwendet werden dürfen, einzuschränken.
- - De-Identifizierung (Anonymisierung): eine Option für den Fahrzeughalter, um die Erlaubnis zu erteilen, Daten von seinem Fahrzeug zu sammeln, aber vorher jede Assoziation mit dem Fahrzeug oder der Person zu entfernen, um die Verwendung der Daten durch einen Dritten zu ermöglichen.
-
Der Regel-/Richtlinienmanager 23 kann einen Satz von Datenschutzregeln generieren, die auf die EDR/DSSAD-Daten des Fahrzeugs entsprechend der Auswahl (oder den privaten Optionen) eines Fahrzeugbesitzers anwendbar sind, und den generierten Satz von Datenschutzregeln in der Datenbank für Datenschutzrichtlinien speichern. Der Satz von Datenschutzregeln kann in einer Auszeichnungs-(Markup-)Sprache wie der Extensible Markup Language (XML) definiert werden.
-
Auch nach der Anmeldung beim Cloud-Speichersystem 20 hat der Fahrzeughalter das Recht, das Cloud-Speichersystem aufzufordern, personenbezogene Daten (VII/EDR/DSSAD-Daten) zu löschen, und das Cloud-Speichersystem 20 verpflichtet sich, auf die Aufforderung hin personenbezogene Daten unverzüglich zu löschen.
-
Unter Bezugnahme auf 6 wird ein beispielhaftes Verfahren beschrieben, bei dem das Cloud-Speichersystem 20 VII/EDR/DSSAD-Daten auf Anforderung eines Fahrzeugbesitzers löscht.
-
Beim Empfang einer Löschanforderungsnachricht, die die Löschung von fahrzeuggenerierten Daten über den Sicherheitskanal anfordert, kann die Cloud-Schnittstelle 27 authentifizieren, ob ein Anforderer ein Fahrzeugeigentümer ist, der das Datensubjekt ist. Die Löschanforderungsnachricht kann Authentifizierungsinformationen und die VII eines zugehörigen Fahrzeugs enthalten. Ist die Authentifizierung erfolgreich, kann der Repository-Koordinator 25 den zusammen mit der VII des Fahrzeugs gespeicherte Salt durch Abfrage der Vll-Datenbank ermitteln. Der Repository-Koordinator 25 kann die Verbindungsdaten aus der VII und dem Salt rekonstruieren. Der Repository-Koordinator 25 kann EDR-Daten und DSSAD-Daten aus der EDR-Datenbank bzw. der DSSAD-Datenbank unter Verwendung der Verbindungsdaten abrufen und die den Verbindungsdaten entsprechenden EDR/DSSAD-Daten löschen. Der Repository-Koordinator kann ein Protokoll für eine Löschanforderung und eine entsprechende Löschaufgabe aufzeichnen und einem Anforderer ein Ergebnis der Ausführung mitteilen.
-
Die Löschanforderung von einem Fahrzeugeigentümer kann ferner die Auswahl der zu löschenden Daten aus den VII- und EDR/DSSAD-Daten umfassen. Auf die Auswahl des Fahrzeugeigentümers hin kann das Cloud-Speichersystem 20 selektiv VII- und EDR/DSSAD-Daten aus den Datenbanken löschen.
-
Ein Fahrzeugeigentümer kann die Löschung nur der VI I- oder Verbindungsdaten anfordern, damit die EDR/DSSAD-Daten von Dritten genutzt werden können, ohne dass eine Assoziation zu einem Fahrzeug oder einer Person besteht. Wenn nur die VII- oder Verbindungsdaten gelöscht werden, kann das Cloud-Speichersystem 20 einen Sicherheitsgrad für die Datenschutzregel (z. B. ein Nutzungsrecht oder ein Zugriffsrecht) der zugehörigen EDR/DSSAD-Daten abschwächen. So kann das Cloud-Speichersystem 20 beispielsweise EDR/DSSAD-Daten mit gelöschtem VII aufbewahren, für Forschungszwecke verwenden oder Dritten zur Verfügung stellen, ohne dass der Fahrzeugeigentümer Einschränkungen hinsichtlich des Zwecks oder der Nutzungsdauer vornimmt. Dementsprechend können Ereignisdaten oder Interaktionsdaten, deren Sicherheitsgrad abgeschwächt ist, direkt aus der zweiten oder dritten Datenbank ohne rekonstruierte Verbindungsdaten abgerufen werden.
-
In einigen Ausführungsformen kann das Cloud-Speichersystem 20 nach Ablauf einer vom Fahrzeugeigentümer festgelegten Gültigkeitsdauer die zugehörigen EDR/DSSAD-Daten in den EDR/DSSAD-Datenbanken beibehalten, aber die zugehörigen VII- oder Salt-Daten aus der VII-Datenbank löschen. Dementsprechend können die EDR/DSSAD-Daten auch nach Ablauf der vom Fahrzeugeigentümer festgelegten Gültigkeitsdauer für statistische Analysen verwendet werden, ohne dass eine Assoziation zu den VII-Daten besteht. Selbst in einem solchen Fall muss das Cloud-Speichersystem 20 nach Erhalt einer ausdrücklichen Löschforderung des Fahrzeugeigentümers auch die EDR/DSSAD-Daten löschen. In einigen anderen Ausführungsformen kann das Cloud-Speichersystem nach Ablauf des vom Fahrzeugeigentümer festgelegten Nutzungszeitraums selektiv nur die EDR/DSSAD-Daten löschen, deren Nutzungszeitraum abgelaufen ist, während die zugehörigen VII-Daten erhalten bleiben.
-
Nachstehend wird unter Bezugnahme auf 7 ein Verfahren zur Sammlung und Speicherung von EDR-Daten in dem in 1 dargestellten System beschrieben. Ein ähnlicher Prozess kann zur Erfassung und Speicherung von DSSAD-Daten durchgeführt werden.
-
7 ist ein Flussdiagramm, das einen EDR-Datenerfassungsprozess des in 1 dargestellten Systems veranschaulicht.
-
In S702 erfasst das Telekommunikationsgerät 15 des bordeigenen Datenaufzeichnungssystems 10 die Ereignisdaten von mindestens einem Modul, einschließlich des EDR 11, der ECU, der Komponente, des Programms oder dergleichen. Beispielsweise kann das Telekommunikationsgerät 15 vom EDR 11 die EDR-Daten empfangen, die aufgezeichnet werden, wenn sie beim Auftreten eines Ereignisses ausgelöst werden, und zusätzlich den geografischen Ort, das Datum, die Uhrzeit usw. erfassen d. h. sammeln, wo und wann das Ereignis aufgetreten ist.
-
In S704 erzeugt das Telekommunikationsgerät 15 eine Ereignisberichtsnachricht und überträgt die Ereignisberichtsnachricht drahtlos über ein Netzwerk an das Cloud-Speichersystem 20. Die Ereignisberichtsnachricht kann EDR-Daten und Fahrzeugidentifikationsinformationen enthalten. Die Ereignisberichtsnachricht kann außerdem zusätzliche Informationen enthalten, wie z. B. den geografischen Ort, das Datum und die Uhrzeit des aufgetretenen Ereignisses, das Fahrzeugmodell, das Baujahr, den Hersteller und so weiter.
-
In S706 ermittelt der Repository-Koordinator 25 des Cloud-Speichersystems 20 die Datenschutzregeln in Bezug auf das Fahrzeug aus der Datenbank für Datenschutzrichtlinien des Datenspeichers 29. In Übereinstimmung mit den Datenschutzregeln kann der Repository-Koordinator 25 so konfiguriert sein, dass er eine Vorverarbeitung (d. h. eine Datenfilterung) der Ereignisberichtsnachricht durchführt, wie z. B. das Extrahieren von Datenelementen, die gesammelt werden dürfen, oder das Entfernen von Datenelementen, die nicht gesammelt werden dürfen, aus der vom Fahrzeug empfangenen Ereignisberichtsnachricht.
-
In S708 kann der Repository-Koordinator 25 für die vorverarbeitete Ereignisberichtsnachricht Verknüpfungs- d.h. Verbindungsdaten zur Aufrechterhaltung der Assoziation zwischen den EDR-Daten und den Fahrzeugidentifizierungsinformationen (VII) generieren, die in verschiedenen Datenbanken gespeichert werden würden. Die Verbindungsdaten können auf der Grundlage der VII und eines zufällig generierten Werts erzeugt werden.
-
In S710 kann der Repository-Koordinator 25 den ersten Datensatz einschließlich der VII und des Salts in der Vll-Datenbank speichern. Darüber hinaus kann der Repository-Koordinator 25 den zweiten Datensatz mit den EDR-Daten und den Verbindungsdaten in einer Ereignisdatenbank speichern.
-
In S712 kann das Cloud-Speichersystem 20 eine Antwortnachricht an das bordeigene Datenaufzeichnungssystem 10 senden, die den Erfolg der Speicherung der Ereignisdaten anzeigt.
-
Es sollte klar sein, dass die oben beschriebenen beispielhaften Ausführungsformen auf viele verschiedene Arten implementiert werden können. In einigen Beispielen können die verschiedenen Verfahren, Einrichtungen/Geräte, Server, (Sub-)Systeme, die in dieser Offenbarung beschrieben werden, durch mindestens einen Allzweckcomputer mit einem Prozessor, Speicher, Diskette oder anderem Massenspeicher, Kommunikationsschnittstelle, Eingabe-/Ausgabegeräten und anderer Peripherie implementiert werden. Ein Mehrzweckcomputer kann als eine Vorrichtung, ein Server, ein System usw. arbeiten,die/das die oben beschriebenen Verfahren durch Laden von Softwarebefehlen in einen Prozessor und anschließendes Ausführen von Befehlen zur Ausführung der in dieser Offenbarung beschriebenen Funktionen durchführt.
-
Zudem können die verschiedenen Verfahren oder Funktionen, die in Ausführungsformen der vorliegenden Offenbarung beschrieben werden, mit Anweisungen implementiert werden, die in einem nicht-transitorischen Aufzeichnungsmedium gespeichert sind, das von einem oder mehreren Prozessoren gelesen und ausgeführt werden können. Nicht-transitorische Aufzeichnungsmedien umfassen beispielsweise alle Arten von Aufzeichnungseinrichtungen, in denen Daten in einer von einem Computersystem lesbaren Form gespeichert sind. Zu den nicht-transitorischen Aufzeichnungsmedien gehören beispielsweise Speichermedien wie löschbare programmierbare Festwertspeicher (EPROM), elektrisch löschbare programmierbare Festwertspeicher (EEPROM), Flash-Laufwerke, optische Laufwerke, magnetische Festplatten und Solid-State-Laufwerke (SSDs).
-
Obwohl beispielhafte Ausführungsformen der vorliegenden Offenbarung zu Veranschaulichungszwecken beschrieben wurden, wird der Durchschnittsfachmann erkennen, dass verschiedene Änderungen, Ergänzungen und Ersetzungen möglich sind, ohne von der Idee und dem Umfang der beanspruchten Erfindung abzuweichen. Daher wurden beispielhafte Ausführungsformen der vorliegenden Offenbarung der Kürze und Klarheit halber beschrieben. Der Umfang der technischen Idee der vorliegenden Ausführungsformen wird durch die Abbildungen nicht eingeschränkt. Dementsprechend würde ein Durchschnittsfachmann verstehen, dass der Umfang der beanspruchten Erfindung nicht durch die voranstehend ausdrücklich beschriebenen Ausführungsformen, sondern durch die Ansprüche und deren Äquivalente beschränkt wird.
-
QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
-
Die vorliegende Anmeldung basiert auf der koreanischen Patentanmeldung Nr.
10-2020-0027455 , die am 4. März 2020 eingereicht wurde, und der koreanischen Patentanmeldung Nr.
10-2021-0025820 , die am 25. Februar 2021 eingereicht wurde, und beansprucht die Priorität dieser Anmeldungen, deren Offenbarungen hier vollständig Teil der vorliegenden Anmeldung sind.
-
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
-
- KR 1020200027455 [0091]
- KR 1020210025820 [0091]
