DE102020124163A1 - Verifizierung von fahrzeugdaten - Google Patents

Verifizierung von fahrzeugdaten Download PDF

Info

Publication number
DE102020124163A1
DE102020124163A1 DE102020124163.1A DE102020124163A DE102020124163A1 DE 102020124163 A1 DE102020124163 A1 DE 102020124163A1 DE 102020124163 A DE102020124163 A DE 102020124163A DE 102020124163 A1 DE102020124163 A1 DE 102020124163A1
Authority
DE
Germany
Prior art keywords
blockchain
ecu
event
data
update
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020124163.1A
Other languages
English (en)
Inventor
Mahmoud Yousef Ghannam
Pramita Mitra
Brian Bennie
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ford Global Technologies LLC
Original Assignee
Ford Global Technologies LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ford Global Technologies LLC filed Critical Ford Global Technologies LLC
Publication of DE102020124163A1 publication Critical patent/DE102020124163A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B60R16/0231—Circuits relating to the driving or the functioning of the vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Automation & Control Theory (AREA)
  • Mechanical Engineering (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Die Offenbarung stellt eine Verifizierung von Fahrzeugdaten bereit. Ein Verfahren beinhaltet Speichern eines erfassten Ereigniscodes in einer ersten Blockchain, wobei jede elektronische Steuereinheit (ECU) in einer Vielzahl von ECU in einem Fahrzeug einen ersten Blockchain-Knoten der ersten Blockchain beinhaltet; Bestimmen einer Validität jedes ersten Blockchain-Knotens der ersten Blockchain durch Bestimmen, dass der Ereigniscode eines von (a) in dem jeweiligen ersten Blockchain-Knoten der ersten Blockchain gespeichert und valide oder (b) nicht in dem jeweiligen ersten Blockchain-Knoten der ersten Blockchain gespeichert und nicht valide ist; und Bereitstellen des Ereigniscodes und der Validität jedes ersten Blockchain-Knotens der ersten Blockchain an eine zweite Blockchain, die in mindestens einem zweiten Blockchain-Knoten verwaltet wird, über ein Netzwerk außerhalb des Fahrzeugs.

Description

  • GEBIET DER TECHNIK
  • Die Offenbarung betrifft im Allgemeinen elektronische Steuereinheiten eines Fahrzeugs.
  • ALLGEMEINER STAND DER TECHNIK
  • Ein Fahrzeug kann eine Vielzahl von elektronischen Steuereinheiten beinhalten. Jede elektronische Steuereinheit kann eine Vielfalt von Daten empfangen, einschließlich Fahrzeugbetriebsdaten, Benutzersteuereingaben, Daten von Sensoren usw. Digitale Daten, die in einer elektronischen Steuereinheit gesammelt und/oder gespeichert werden, können beispielsweise während der Wartung oder des Austauschs der elektronischen Steuereinheit verloren gehen oder verändert werden.
  • KURZDARSTELLUNG
  • Ein Verfahren beinhaltet Speichern eines erfassten Ereigniscodes in einer ersten Blockchain, wobei jede elektronische Steuereinheit (electronic control unit - ECU) in einer Vielzahl von ECU in einem Fahrzeug einen ersten Blockchain-Knoten der ersten Blockchain beinhaltet. Das Verfahren beinhaltet ferner Bestimmen einer Validität jedes ersten Blockchain-Knotens der ersten Blockchain durch Bestimmen, dass der Ereigniscode eines von (a) in dem jeweiligen ersten Blockchain-Knoten der ersten Blockchain gespeichert und valide oder (b) nicht in dem jeweiligen ersten Blockchain-Knoten der ersten Blockchain gespeichert und nicht valide ist, und Bereitstellen des Ereigniscodes und der Validität jedes ersten Blockchain-Knotens der ersten Blockchain an eine zweite Blockchain, die in mindestens einem zweiten Blockchain-Knoten verwaltet wird, über ein Netzwerk außerhalb des Fahrzeugs.
  • Das Bestimmen der Validität jedes ersten Blockchain-Knotens der ersten Blockchain kann durchgeführt werden, wenn bestimmt wird, dass der erfasste Ereigniscode einen Schaden an dem Fahrzeug identifiziert.
  • Das Verfahren kann Identifizieren einer nicht autorisierten ECU in der Vielzahl von ECU auf Grundlage dessen, dass der jeweilige erste Blockchain-Knoten nicht valide ist, beinhalten.
  • Das Verfahren kann Bereitstellen von Daten, die die nicht autorisierte ECU identifizieren, an die zweite Blockchain beinhalten.
  • Das Verfahren kann beim Empfangen eines Aktualisierungscodes von mindestens einem zweiten Blockchain-Knoten über das Netzwerk Speichern des Aktualisierungscodes in der ersten Blockchain beinhalten. Der Aktualisierungscode kann eine Anzahl von autorisierten ECU-Modifikationen spezifizieren.
  • Das Verfahren kann Authentifizieren des zweiten Blockchain-Knotens auf Grundlage einer Kennung, die mit einer autorisierten Kennung übereinstimmt, beinhalten.
  • Das Verfahren kann Validieren des Aktualisierungscodes durch mindestens eine ECU, die den Aktualisierungscode mit einem digitalen Schlüssel entschlüsselt, beinhalten.
  • Das Verfahren kann Bestimmen des erfassten Ereigniscodes auf Grundlage von Sensordaten des Fahrzeugs beinhalten.
  • Jeder Ereigniscode kann in der ersten Blockchain einer und nur einer der ECU zugeordnet sein.
  • Das Verfahren kann Bestimmen des erfassten Ereigniscodes auf Grundlage von Sensordaten des Fahrzeugs beinhalten.
  • Das Verfahren kann nach dem Erfassen des Ereigniscodes Validieren des Ereigniscodes durch mindestens eine ECU, die den Ereigniscode mit einem digitalen Schlüssel entschlüsselt, beinhalten.
  • Ein System beinhaltet eine Vielzahl von elektronischen Steuereinheiten (ECU) in einem Fahrzeug, wobei jede ECU einen Prozessor und einen Speicher aufweist, wobei der Speicher jeder ECU Anweisungen speichert, die durch den Prozessor jeder ECU ausführbar sind, sodass jeder Prozessor dazu programmiert ist, einen erfassten Ereigniscode in einer ersten Blockchain zu speichern, wobei jede der ECU in der Vielzahl von ECU einen ersten Blockchain-Knoten der ersten Blockchain beinhaltet. Die Anweisungen beinhalten ferner Anweisungen zum Bestimmen einer Validität jedes ersten Blockchain-Knotens der ersten Blockchain durch Bestimmen, dass der Ereigniscode eines von (a) in dem jeweiligen ersten Blockchain-Knoten der ersten Blockchain gespeichert und valide oder (b) nicht in dem jeweiligen ersten Blockchain-Knoten der ersten Blockchain gespeichert und nicht valide ist, und zum Bereitstellen des Ereigniscodes und der Validität jedes ersten Blockchain-Knotens der ersten Blockchain an eine zweite Blockchain, die in mindestens einem zweiten Blockchain-Knoten verwaltet wird, über ein Netzwerk außerhalb des Fahrzeugs.
  • Das Bestimmen der Validität jedes ersten Blockchain-Knotens der ersten Blockchain kann durchgeführt werden, wenn bestimmt wird, dass der erfasste Ereigniscode einen Schaden an dem Fahrzeug identifiziert.
  • Die Anweisungen können ferner Anweisungen zum Identifizieren einer nicht autorisierten ECU in der Vielzahl von ECU auf Grundlage dessen, dass der jeweilige erste Blockchain-Knoten nicht valide ist, beinhalten.
  • Die Anweisungen können ferner Anweisungen zum Bereitstellen von Daten, die die nicht autorisierte ECU identifizieren, an die zweite Blockchain beinhalten.
  • Die Anweisungen können ferner Anweisungen beinhalten, um nach dem Empfangen eines Aktualisierungscodes von mindestens einem zweiten Blockchain-Knoten über das Netzwerk den Aktualisierungscode in der ersten Blockchain zu speichern, wobei der Aktualisierungscode eine Anzahl von autorisierten ECU-Modifikationen spezifiziert.
  • Die Anweisungen können ferner Anweisungen zum Authentifizieren des zweiten Blockchain-Knotens auf Grundlage einer Kennung, die mit einer autorisierten Kennung übereinstimmt, beinhalten.
  • Die Anweisungen können ferner Anweisungen zum Validieren des Aktualisierungscodes durch mindestens eine ECU, die den Aktualisierungscode mit einem digitalen Schlüssel entschlüsselt, beinhalten.
  • Die Anweisungen können ferner Anweisungen zum Bestimmen des erfassten Ereigniscodes auf Grundlage von Sensordaten des Fahrzeugs beinhalten.
  • Jeder Ereigniscode kann in der ersten Blockchain einer und nur einer der ECU zugeordnet sein.
  • Die Anweisungen können ferner Anweisungen beinhalten, um nach dem Erfassen des Ereigniscodes den Ereigniscode durch mindestens eine ECU, die den Ereigniscode mit einem digitalen Schlüssel entschlüsselt, zu validieren.
  • Ferner ist in dieser Schrift eine Rechenvorrichtung offenbart, die dazu programmiert ist, einen beliebigen der vorstehenden Verfahrensschritte auszuführen. Noch ferner ist in dieser Schrift ein Computerprogrammprodukt offenbart, das ein computerlesbares Medium beinhaltet, auf dem Anweisungen gespeichert sind, die durch einen Computerprozessor ausführbar sind, um einen beliebigen der vorstehenden Verfahrensschritte auszuführen.
  • Figurenliste
    • 1A ist ein Blockdiagramm, das ein beispielhaftes System zum Authentifizieren und Speichern von Ereigniscodes veranschaulicht.
    • 1B ist ein Blockdiagramm, das ein beispielhaftes erstes Blockchain-Netzwerk veranschaulicht.
    • 1C ist ein Blockdiagramm, das ein beispielhaftes zweites Blockchain-Netzwerk veranschaulicht.
    • 2A ist eine Darstellung eines Abschnitts einer beispielhaften ersten Blockchain.
    • 2B ist eine Darstellung eines Abschnitts einer beispielhaften zweiten Blockchain.
    • 3 ist ein Ablaufdiagramm eines beispielhaften Prozesses zum Aktualisieren der ersten und zweiten Blockchain.
  • DETAILLIERTE BESCHREIBUNG
  • Ein Fahrzeug 105 beinhaltet ein erstes Blockchain-Netzwerk 111, das aus einer Vielzahl von ersten Blockchain-Knoten 127 gebildet ist, die ein erstes elektronisches Ledger, z. B. die Blockchain 201, zum Aufzeichnen von Ereignisdaten (wie nachstehend beschrieben), Sensordaten und Aktualisierungsdaten (wie nachstehend beschrieben) verwaltet. Ein System 100 beinhaltet ein zweites Blockchain-Netzwerk 112, das aus einer Vielzahl von zweiten Blockchain-Knoten 145 gebildet ist, die eine zweite Blockchain 202 zum Aufzeichnen von Fahrzeugereignis- und/oder Aktualisierungsdaten verwaltet. Eine Vielzahl von Rechenvorrichtungen 140 speichert die jeweiligen zweiten Blockchain-Knoten 145.
  • Jeder der ersten Blockchain-Knoten 127 ist in einer von einer Vielzahl von bordeigenen Rechenvorrichtungen beinhaltet, die über ein Netzwerk kommunikativ gekoppelt sind, typischerweise verschiedene elektronische Steuereinheiten (ECU) 126 des Fahrzeugs 105 oder dergleichen in einem Fahrzeugkommunikationsbus oder -netzwerk 130. Als nicht einschränkende Beispiele kann das Netzwerk ein Peer-to-Peer-Netzwerk oder ein Peer-to-Peer-Netzwerk mit einem Überwachungsknoten sein. Die Knoten 127, die zur Teilnahme an dem ersten Blockchain-Netzwerk 111 autorisiert sind, sind in der ersten Blockchain 201 aufgeführt.
  • In dieser Offenbarung bedeutet der Begriff „Netzwerk“ im Kontext eines Blockchain-Netzwerks 111, 112 ein Netzwerk, das durch Blockchain-Knoten gebildet ist, d.h. ein Blockchain-Netzwerk 111, 112 bedeutet die Knoten 127, 145, die die Blockchain bilden, einschließlich Links zu jedem anderen Knoten 127, 145. Andererseits bedeutet ein „Netzwerk“ im Kontext von Vorrichtungen, die miteinander kommunizieren, z. B. die ECU 126 und/oder Vorrichtungen 140, die über ein Fahrzeugnetzwerk 130 und/oder Weitverkehrsnetzwerk 135 kommunizieren, ein physisches Netzwerk, das herkömmliche Netzwerkhardware, Protokolle usw. umfasst.
  • Die Vielzahl von zweiten Blockchain-Knoten 145 ist jeweils in einer von einer Vielzahl von Rechenvorrichtungen 140 beinhaltet, die über ein Netzwerk 135, das sich außerhalb des Fahrzeugs 105 befindet, kommunikativ gekoppelt ist. Die in dem zweiten Blockchain-Netzwerk 112 beinhalteten Knoten sind in der zweiten Blockchain 202 aufgeführt.
  • Ereignisdaten und Aktualisierungsdaten können als jeweilige Datenblöcke in der ersten Blockchain 201 und der zweiten Blockchain 202 gespeichert sein. Die erste und zweite Blockchain 201, 202 sind, wie hierin erörtert, verteilte Datenbanken, einschließlich Blockchains, die einen oder mehrere Datenblöcke speichern, die Ereignisdaten bzw. Aktualisierungsdaten identifizieren. „Verteilt“ bedeutet in diesem Kontext, dass Kopien der Datenbank durch mehrere Knoten in der Vielzahl der ersten und zweiten Blockchain-Knoten verwaltet werden. Die innerhalb der Blockchain gespeicherten Datenblöcke sind in einer Kette durch Hash-Funktionen verlinkt, die einen Link zwischen jeweiligen Blöcken validieren.
  • Eine Blockchain 201, 202 ist ein elektronisches Kontenbuch bzw. ein elektronisches Ledger, das in jedem einer Vielzahl von verteilten Knoten 127, 145 verwaltet wird, die ein Netzwerk 111, 112 bilden, wobei jeweils geteilte Daten auf Grundlage der Erzeugung von Hashes für Datenblöcke gespeichert werden. Im vorliegenden Kontext ist ein Hash eine Einwegverschlüsselung von Daten, d. h. ein Ergebnis einer Ausführung einer Hash-Funktion, die eine feste Anzahl an Bits aufweist. Ein Beispiel für Hash-Verschlüsselung ist SHA-256. Die Hashes, d. h. die Ergebnisse der Hash-Funktionen, stellen Links zu Datenblöcken bereit, indem Orte der entsprechenden Datenblöcke in Speicher (digitalem Speicher) identifiziert werden, zum Beispiel durch Verwendung einer Zuordnungstabelle, die die Hashes jeweiligen Speicherorten zuordnet. Eine Zuordnungstabelle stellt einen Mechanismus zum Zuordnen des Hashes (der auch als Hash-Schlüssel bezeichnet werden kann) zu einer Adresse bereit, die eine physische Speichervorrichtung entweder in einem Fahrzeug oder an einem stationären Ort spezifiziert. Der Hash für den Datenblock stellt ferner einen Code bereit, um die Daten zu verifizieren, mit denen der Hash verlinkt ist. Beim Abrufen des Datenblocks kann ein Computer den Hash des Datenblocks neu berechnen und den resultierenden Hash mit dem Hash vergleichen, der den Link bereitstellt. Für den Fall, dass der neu berechnete Hash mit dem verlinkenden Hash übereinstimmt, kann der Computer bestimmen, dass der Datenblock unverändert ist. Umgekehrt gibt ein neu berechneter Hash, der nicht mit dem verlinkenden Hash übereinstimmt, an, dass der Datenblock oder der Hash verändert wurde, zum Beispiel durch Beschädigung oder Manipulation. Der Hash, der den Link zu einem Datenblock bereitstellt, kann auch als Schlüssel oder Hash-Schlüssel bezeichnet werden. Eine beispielhafte Struktur einer ersten Blockchain 201 und einer zweiten Blockchain wird nachstehend unter Bezugnahme auf die 2A bzw. 2B erörtert.
  • 1 ist ein Blockdiagramm eines beispielhaften Systems 100, das ein Fahrzeug 105 beinhaltet, das eine Vielzahl von ersten Blockchain-Knoten 127 und eine Vielzahl von zweiten Blockchain-Knoten 145 aufweist. Das heißt, das Fahrzeug 105 beinhaltet eine Vielzahl von ECU 126 und jede ECU 126 ist dazu programmiert, einen ersten Blockchain-Knoten 127, der eine erste Blockchain 201 beinhaltet, zu verwalten.
  • Jede ECU 126 ist ferner dazu programmiert, einen erfassten Ereigniscode in der ersten Blockchain 201 zu speichern und eine Validität jedes ersten Blockchain-Knotens 127 der ersten Blockchain 201 zu bestimmen, indem bestimmt wird, dass der Ereigniscode eines von (a) in dem jeweiligen ersten Blockchain-Knoten 127 der ersten Blockchain 201 gespeichert und daher valide ist oder (b) nicht in dem jeweiligen ersten Blockchain-Knoten 127 der ersten Blockchain 201 gespeichert und daher nicht valide ist.
  • Jede ECU 126 ist ferner dazu programmiert, über ein Netzwerk 135 außerhalb des Fahrzeugs 105 den Ereigniscode und die Validität jedes ersten Blockchain-Knotens 127 der ersten Blockchain 201 einer zweiten Blockchain 202 bereitzustellen, die in mindestens einem zweiten Blockchain-Knoten 145 verwaltet wird. Jede ECU 126 empfängt z. B. von einem oder mehreren Sensoren 115 verschiedene Fahrzeugdaten und speichert diese, z. B. Daten der Fahrzeugkomponente 125, Betriebsdaten des Fahrzeugs 105 usw. Vorteilhafterweise speichern die ECU 126 Daten von Sensoren 115 in der ersten Blockchain 201 und stellen den Ereigniscode, der die Daten von Sensoren 115 darstellt, der zweiten Blockchain 202 bereit, wodurch die an der zweiten Blockchain 202 gespeicherte Datenmenge reduziert und die Daten, auf die die zweiten Blockchain-Knoten 145 über die zweite Blockchain 202 zugreifen können, begrenzt werden können.
  • Ein Fahrzeug 105 beinhaltet einen Fahrzeugcomputer 110, Sensoren 115, Aktoren 120, Fahrzeugkomponenten 125 und einen Fahrzeugkommunikationsbus 130. Über ein Netzwerk 135 ermöglicht es der Kommunikationsbus 130 dem Fahrzeugcomputer 110, mit dem einen oder den mehreren zweiten Blockchain-Knoten 145 zu kommunizieren.
  • Der Fahrzeugcomputer 110 beinhaltet einen Prozessor und einen Speicher, wie sie bekannt sind. Der Speicher beinhaltet eine oder mehrere Formen computerlesbarer Medien und speichert Anweisungen, die durch den Fahrzeugcomputer 110 ausführbar sind, um verschiedene Vorgänge durchzuführen, einschließlich der hierin offenbarten.
  • Der Fahrzeugcomputer 110 kann das Fahrzeug 105 in einem autonomen, einem teilautonomen oder einem nicht autonomen (oder manuellen) Modus betreiben. Für die Zwecke dieser Offenbarung ist ein autonomer Modus als einer definiert, bei dem jedes von Antrieb, Bremsung und Lenkung des Fahrzeugs 105 durch den Fahrzeugcomputer 110 gesteuert wird; in einem teilautonomen Modus steuert der Fahrzeugcomputer 110 eines oder zwei von Antrieb, Bremsung und Lenkung des Fahrzeugs 105; in einem nichtautonomen Modus steuert ein menschlicher Fahrzeugführer jedes von Antrieb, Bremsung und Lenkung des Fahrzeugs 105.
  • Der Fahrzeugcomputer 110 kann Programmierung beinhalten, um eines oder mehrere von Bremsen, Antrieb (z. B. Steuerung der Beschleunigung des Fahrzeugs 105 durch Steuern von einem oder mehreren von einer Brennkraftmaschine, einem Elektromotor, Hybridmotor usw.), Lenkung, Getriebe, Klimasteuerung, Innen- und/oder Außenbeleuchtung usw. des Fahrzeugs 105 zu betreiben, sowie um zu bestimmen, ob und wann der Fahrzeugcomputer 110 derartige Vorgänge anstelle eines menschlichen Bedieners steuern soll. Zusätzlich kann der Fahrzeugcomputer 110 dazu programmiert sein, zu bestimmen, ob und wann ein menschlicher Fahrzeugführer derartige Vorgänge steuern soll.
  • Der Fahrzeugcomputer 110 kann mehr als einen Prozessor beinhalten, z. B. in elektronischen Steuereinheiten (ECU) 126 oder dergleichen beinhaltet, die in dem Fahrzeug 105 beinhaltet sind, um verschiedene Fahrzeugkomponenten 125 zu überwachen und/oder zu steuern, z. B. eine Getriebesteuerung, eine Bremssteuerung, eine Lenksteuerung usw., oder kommunikativ daran gekoppelt sein, z. B. über ein Kommunikationsnetzwerk 130 des Fahrzeugs, wie etwa einen nachstehend beschriebenen Kommunikationsbus. Der Fahrzeugcomputer 110 ist im Allgemeinen zur Kommunikation in einem Fahrzeugkommunikationsnetzwerk, das einen Bus in dem Fahrzeug 105 beinhalten kann, wie etwa ein Controller Area Network (CAN) oder dergleichen, und/oder anderen drahtgebundenen und/oder drahtlosen Mechanismen angeordnet.
  • Über das Fahrzeugkommunikationsnetzwerk 130 kann der Fahrzeugcomputer 110 Nachrichten an verschiedene Vorrichtungen in dem Fahrzeug 105 übertragen und/oder Nachrichten (z. B. CAN-Nachrichten) von den verschiedenen Vorrichtungen, z. B. Sensoren 115, einem Aktor 120, ECU 126 usw., empfangen. Alternativ oder zusätzlich dazu kann das Fahrzeugkommunikationsnetzwerk 130 in Fällen, in denen der Fahrzeugcomputer 110 tatsächlich eine Vielzahl von Vorrichtungen umfasst, zur Kommunikation zwischen Vorrichtungen verwendet werden, die in dieser Offenbarung als der Fahrzeugcomputer 110 dargestellt sind. Ferner können, wie nachstehend erwähnt, verschiedene Steuerungen und/oder Sensoren 115 dem Fahrzeugcomputer 110 Daten über das Fahrzeugkommunikationsnetzwerk 130 bereitstellen.
  • Die Sensoren 115 des Fahrzeugs 105 können eine Vielfalt an Vorrichtungen beinhalten, die bekanntermaßen dem Fahrzeugcomputer 110 Daten bereitstellen. Zum Beispiel können die Sensoren 115 (einen) Light-Detection-and-Ranging-Sensor(en) (LIDAR-Sensor(en)) 115 usw. beinhalten, die auf einer Oberseite des Fahrzeugs 105, hinter einer Windschutzscheibe des Fahrzeugs 105, um das Fahrzeug 105 herum usw. angeordnet sind, die relative Standorte, Größen und Formen von Objekten bereitstellen, die das Fahrzeug 105 umgeben. Als weiteres Beispiel können ein oder mehrere Radarsensoren 115, die an Stoßfängern des Fahrzeugs 105 befestigt sind, Daten bereitstellen, um Standorte der Objekte, zweiter Fahrzeuge 105 usw. in Bezug auf den Standort des Fahrzeugs 105 bereitzustellen. Die Sensoren 115 können ferner alternativ oder zusätzlich zum Beispiel (einen) Kamerasensor(en) 115 beinhalten, z.B. Frontkamera, Seitenkamera usw., die Bilder von einem das Fahrzeug 105 umgebenden Bereich bereitstellen. Im Kontext mit dieser Offenbarung ist ein Objekt ein physischer, d. h. materieller, Gegenstand, der durch physikalische Phänomene (z. B. Licht oder andere elektromagnetische Wellen oder Schall usw.), die durch Sensoren 115 erfasst werden können, dargestellt werden kann. Somit fallen die Fahrzeuge 105 sowie andere Gegenstände, einschließlich der nachstehend erörterten, unter die Definition von „Objekt“ in dieser Schrift.
  • Die Aktoren 120 des Fahrzeugs 105 sind über Schaltungen, Chips oder andere elektronische und/oder mechanische Komponenten umgesetzt, die verschiedene Fahrzeugteilsysteme gemäß zweckmäßigen Steuersignalen betätigen können, wie es bekannt ist. Die Aktoren 120 können verwendet werden, um Steuerelemente 125, einschließlich Bremsung, Beschleunigung und Lenkung, eines Fahrzeugs 105 zu steuern.
  • Im Zusammenhang mit der vorliegenden Offenbarung handelt es sich bei einer Fahrzeugkomponente 125 um eine oder mehrere Hardwarekomponenten, einschließlich der ECU 126, die dazu ausgelegt sind, eine(n) mechanische(n) oder elektromechanische(n) Funktion oder Vorgang durchzuführen - wie etwa das Fahrzeug 105 bewegen, das Fahrzeug 105 verlangsamen oder anhalten, das Fahrzeug 105 lenken usw. Nicht einschränkende Beispiele für Komponenten 125 beinhalten eine Antriebskomponente (die z. B. eine Brennkraftmaschine und/oder einen Elektromotor usw. beinhaltet), eine Getriebekomponente, eine Lenkkomponente (die z. B. eines oder mehrere von einem Lenkrad, einer Zahnstange usw. beinhalten kann), eine Bremskomponente (wie nachstehend beschrieben), eine Einparkhilfekomponente, eine Komponente für adaptive Geschwindigkeitsregelung, eine Komponente zum adaptiven Lenken, einen bewegbaren Sitz usw.
  • Das Fahrzeug 105 kann eine beliebige geeignete Anzahl, z. B. eine oder mehrere, von ECU 126 beinhalten. Jede der ECU 126 kann über das Fahrzeugkommunikationsnetzwerk 130 Nachrichten an die anderen übertragen und/oder Nachrichten von den anderen und/oder dem Fahrzeugcomputer 110 empfangen. Jede ECU 126 beinhaltet eine Kennung. In diesem Kontext ist eine „Kennung“ eine alphanumerische Datenfolge, die einer spezifischen ECU 126 entspricht. Anders ausgedrückt identifiziert die Kennung einer spezifischen ECU 126.
  • Die ECU 126 sind mikroprozessorbasierte Computer. Die ECU 126 beinhalten jeweils einen Prozessor, einen Speicher usw. Der Speicher jeder ECU 126 beinhaltet Medien zum Speichern von Anweisungen, die durch den jeweiligen Prozessor ausgeführt werden können, sowie zum elektronischen Speichern von Daten und/oder Datenbanken. Nicht einschränkende Beispiele für ECU 126 beinhalten ein Karosseriesteuermodul, ein Antiblockiersteuermodul, ein Servolenksteuermodul, ein Motorsteuermodul, ein Rückhaltesteuermodul, ein Antriebsstrangsteuermodul, ein Batterieelektroniksteuermodul usw.
  • Zusätzlich kann der Fahrzeugcomputer 110 dazu konfiguriert sein, über einen Fahrzeug-zu-Fahrzeug-Kommunikationsbus 130 oder eine Schnittstelle mit Vorrichtungen außerhalb des Fahrzeugs 105, z. B. über das Netzwerk 135 und/oder über eine Fahrzeug-zu-Fahrzeug-(C2C-) oder eine Fahrzeug-zu-Infrastruktur-(C2X-)Drahtloskommunikation, mit einem anderen Fahrzeug und/oder mit den Blockchain-Knoten 145 (typischerweise über direkte Funkfrequenzkommunikation) zu kommunizieren. Der Kommunikationsbus 130 könnte einen oder mehrere Mechanismen beinhalten, durch die die Computer 110 der Fahrzeuge 105 kommunizieren können, einschließlich einer beliebigen gewünschten Kombination aus drahtlosen (z. B. Mobilfunk-, Drahtlos-, Satelliten-, Mikrowellen- und Funkfrequenz-)Kommunikationsmechanismen und einer beliebigen gewünschten Netztopologie (oder Topologien, wenn eine Vielzahl von Kommunikationsmechanismen verwendet wird). Beispielhafte über den Kommunikationsbus 130 bereitgestellte Kommunikation beinhaltet Mobilfunk, Bluetooth, IEEE 802.11, dedizierte Nahbereichskommunikation (dedicated short range communication - DSRC) und/oder Weitverkehrsnetzwerke (wide area networks - WAN), einschließlich des Internets, die Datenkommunikationsdienste bereitstellen.
  • Das Netzwerk 135 stellt einen oder mehrere Mechanismen dar, durch die die ECU 126 und/oder ein Fahrzeugcomputer 110 mit entfernten Vorrichtungen kommunizieren kann, darunter Vorrichtungen 140, die Blockchain-Knoten 145 hosten. Dementsprechend kann das Netzwerk 135 einer oder mehrere von verschiedenen drahtgebundenen oder drahtlosen Kommunikationsmechanismen sein, einschließlich einer beliebigen gewünschten Kombination aus drahtgebundenen (z. B. Kabel- und Glasfaser-) und/oder drahtlosen (z. B. Mobilfunk-, Drahtlos-, Satelliten-, Mikrowellen- und Hochfrequenz-) Kommunikationsmechanismen und einer beliebigen gewünschten Netzwerktopologie (oder Netzwerktopologien, wenn mehrere Kommunikationsmechanismen genutzt werden). Beispielhafte Kommunikationsnetzwerke beinhalten drahtlose Kommunikationsnetzwerke (z.B. unter Verwendung von Bluetooth®, Bluetooth® Low Energy (BLE), IEEE 802.11, Fahrzeug-zu-Fahrzeug (C2C), wie etwa Dedicated Short Range Communications (DSRC) usw.), lokale Netzwerke (local area network - LAN) und/oder Weitverkehrsnetzwerke (wide area network - WAN), einschließlich des Internets, die Datenkommunikationsdienste bereitstellen.
  • Das erste Blockchain-Netzwerk 111 (wie in 1B gezeigt) beinhaltet die Vielzahl von ersten Blockchain-Knoten 127, d. h. in einem Peer-to-Peer-Netzwerk, wobei jeder Knoten 127 in dem Peer-to-Peer-Netzwerk Links zu anderen Knoten 127 in dem Netzwerk 111 beinhaltet. Die Knoten 127 in dem Netzwerk 111 können durch den Hersteller des Fahrzeugs 105 vorgegeben sein und können in der ersten Blockchain 201 aufgezeichnet sein.
  • Die erste Blockchain 201 ist ein Distributed-Blockchain-Ledger. Das heißt, jeder Blockchain-Knoten 127 speichert z. B. in einem Speicher eine Kopie der ersten Blockchain 201. Die Knoten 127 können zum Beispiel Datenblöcke von anderen Knoten in der Vielzahl von ersten Blockchain-Knoten 127 empfangen und die Datenblöcke in die erste Blockchain 201 hochladen, d. h. die jeweiligen Datenblöcke an jeweiligen Speicherorten in der ersten Blockchain 201 speichern, sodass jeder Datenblock zu einem jeweiligen vorherigen Datenblock verlinkt ist. Jeder Datenblock kann Ereignisdaten und/oder Sensordaten für eine ECU 126 spezifizieren. Die Datenblöcke können auf Grundlage von Anforderungen erzeugt werden, die zum Beispiel durch die ECU 126, die einen Ereigniscode bestimmt, über einen CAN-Bus in dem Fahrzeugkommunikationsnetzwerk 130 übermittelt werden können. Jeder Knoten 127 kann seine gespeicherten Daten der Blockchain 201, d. h. verlinkte Datenblöcke, mit Versionen der Blockchain 201 vergleichen, die durch andere erste Blockchain-Knoten 127 gespeichert werden, um die Datenblöcke zu verifizieren, wie nachstehend beschrieben wird.
  • In diesem Kontext sind Ereignisdaten Daten, die einen Ereigniscode, die dem Ereigniscode zugeordnete Kennung der ECU 126 und die Validität jedes ersten Blockchain-Knotens 127 der ersten Blockchain 201 angeben, z. B. die Kennungen für jede autorisierte ECU 126 (wie nachstehend beschrieben) und die Kennungen für jede nicht autorisierte ECU 126 (wie nachstehend beschrieben).
  • Ein „Ereigniscode“ ist ein Datensatz, typischerweise eine alphanumerische Zeichenfolge, der ein vorbestimmtes Ereignis spezifiziert, einschließlich eines Schadens an dem Fahrzeug 105. Die Ereignisse können auf Grundlage von empirischen Tests bestimmt werden, um Ereignisse zu bestimmen, die die Leistungsfähigkeit und/oder einen Reparaturzustand des Fahrzeugs 105 beeinflussen. Zusätzlich oder alternativ können die Ereignisse durch die Bestimmung von Ereignissen durch einen Hersteller oder Konstrukteur bestimmt werden, die wesentlich sein können, z. B. für die Leistungsfähigkeit einer oder mehrerer Fahrzeugkomponenten 125. Das erste Zeichen der Datenfolge kann eine ganze Zahl sein, die eine Anzahl von Instanzen vorbestimmter Ereignisse angibt. Die folgenden ein oder mehreren Zeichen können alphabetische Zeichen sein, die eine Art von Ereignis angeben, wie etwa Schaden, z. B. Kollision, Überschwemmung, Feuer usw. Jeder Ereigniscode wird durch eine jeweilige ECU 126 bestimmt, wie nachstehend erörtert. Das heißt, jeder Ereigniscode ist in der ersten Blockchain 201 einer und nur einer ECU 126 zugeordnet. Nicht einschränkende Beispiele für „Ereigniscodes“ sind nachstehend in Tabelle 1 gezeigt. Tabelle 1
    Anzahl der Vorkommnisse Ereignisart Ereigniscode
    Null Keine 00
    Eins Frontaufprall 1F
    Zwei Seitenaufprall 2S
    Eins Überschwemmung 1 Überschwemmung
    Eins Feuer 1 Feuer
  • Die ECU 126 sind dazu programmiert, Daten von Sensoren 115 von einem oder mehreren Sensoren 115 zu empfangen, z. B. über das Fahrzeugnetzwerk. Jede ECU 126 kann Daten von unterschiedlichen Sensoren 115 empfangen. Zum Beispiel kann jede ECU 126 dazu programmiert sein, spezifische Fahrzeugkomponenten 125 und/oder Teilsysteme zu steuern und/oder zu überwachen. Unter diesen Umständen empfängt jede ECU 126 Daten von Sensoren 115 bezüglich der jeweiligen Fahrzeugkomponenten 125 und/oder Teilsysteme. Die ECU 126 können dann einen Schaden an dem Fahrzeug, z. B. einem oder mehreren Fahrzeugkomponenten 125 und/oder Teilsystemen, auf Grundlage der Daten von Sensoren 115 bestimmen.
  • Als ein Beispiel können die Daten von Sensoren 115 Bild- und/oder Videodaten sein. In einem derartigen Beispiel können eine oder mehrere ECU 126 die Bild- und/oder Videodaten analysieren, um einen Schaden an dem Fahrzeug zu identifizieren, z. B. durch eine Kollision, eine Überschwemmung, einen Brand usw.
  • Als ein weiteres Beispiel können eine oder mehrere ECU 126 die Daten von Sensoren 115 mit jeweiligen Schwellenwerten vergleichen. Die Schwellenwerte spezifizieren einen normalen Betrieb der Fahrzeugkomponenten 125 des Fahrzeugs. In diesem Zusammenhang bedeutet „normaler Betrieb“, dass die Fahrzeugkomponenten 125 innerhalb vorbestimmter Einstellungen auf Grundlage des Betriebs des Fahrzeugs 105 auf herkömmlichen Straßen betrieben werden. Die Schwellenwerte können durch empirische Tests bestimmt werden, um den Betrieb der Fahrzeugkomponenten 125 während des normalen Betriebs des Fahrzeugs zu bestimmen. Zum Beispiel können die ECU 126 eine Fahrzeugverzögerung mit einem Verzögerungsschwellenwert vergleichen, der z. B. in einem Speicher einer oder mehrerer ECU 126 gespeichert ist. In dem Fall, dass die Fahrzeugverzögerung über dem Verzögerungsschwellenwert liegt, können die ECU 126 bestimmen, dass sich das Fahrzeug in einer Kollision befand.
  • Als weiteres Beispiel können die ECU 126 eine Kabinentemperatur mit einem Temperaturschwellenwert vergleichen, der z. B. in einem Speicher einer oder mehrerer ECU 126 gespeichert ist. In dem Fall, dass die Kabinentemperatur über der Schwellentemperatur liegt, können die ECU 126 bestimmen, dass das Fahrzeug brennt.
  • Zusätzlich kann die jeweilige ECU 126 einen Ereigniscode auf Grundlage der empfangenen Daten von Sensoren 115 bestimmen, z. B. eine Art des erfassten Schadens. Zum Beispiel kann die jeweilige ECU 126 den Ereigniscode aus einer Lookup-Tabelle, z. B. ähnlich der vorstehenden Tabelle 1, auf Grundlage der Schadensart bestimmen, die dem Ereigniscode in der Lookup-Tabelle zugeordnet ist. Die jeweilige ECU 126 speichert dann den Ereigniscode in dem jeweiligen ersten Blockchain-Knoten 127 der ersten Blockchain 201.
  • Die ECU 126, die den Ereigniscode bestimmt, ist dazu programmiert, den Ereigniscode an die anderen ECU 126 zu übertragen. Die anderen ECU 126 authentifizieren dann die Übertragung (oder authentifizieren diese nicht). Um die Authentifizierung durchzuführen, können die anderen ECU 126 dazu programmiert sein, einen jeweiligen Hash-Code zu erzeugen und den jeweiligen Hash-Code an die ECU 126 zu übertragen, die den Ereigniscode übertragen hat. Die ECU 126, die den Ereigniscode übertragen hat, kann die jeweiligen Hash-Codes auf Grundlage eines digitalen Schlüssels, der z. B. in einem Speicher der ECU 126 gespeichert ist, die den Ereigniscode übertragen hat, verschlüsseln, um einen Aufforderungs- bzw. Challenge-Code zu erzeugen und den verschlüsselten Hash-Code an die anderen ECU 126 zu übertragen. Die anderen ECU können dann den verschlüsselten Hash-Code entschlüsseln. In dem Fall, dass der entschlüsselte Hash-Code mit dem Challenge-Code übereinstimmt, genehmigen (authentifizieren) die anderen ECU 126 die Übertragung. Falls umgekehrt der entschlüsselte Hash-Code nicht mit dem Challenge-Code übereinstimmt, lehnen die anderen ECU 126 die Übertragung ab (authentifizieren diese nicht).
  • Nach dem Genehmigen der Übertragung sind die ECU 126 dazu programmiert, den Ereigniscode in der ersten Blockchain 201 zu speichern. Zum Beispiel kann jede ECU 126 dazu programmiert sein, Ereignisdaten und die Sensordaten in einem Ereignisblock einer ersten Blockchain 201 zu speichern, wie nachstehend beschrieben. Die ECU können den Ereigniscode in die erste Blockchain 201 speichern, bevor oder nachdem sich die ersten Blockchain-Knoten 127 gegenseitig validiert haben (wie nachstehend beschrieben). Zum Beispiel können die ECU den Ereigniscode in die erste Blockchain 201 speichern, und dann können sich die ersten Blockchain-Knoten 127 auf Grundlage des Ereigniscodes gegenseitig validieren. Als ein weiteres Beispiel können sich die ersten Blockchain-Knoten 127 auf Grundlage von zuvor gespeicherten Ereigniscodes gegenseitig validieren, und dann können die ECU den Ereigniscode in die erste Blockchain 201 und insbesondere in die validierten ersten Blockchain-Knoten 127 speichern. Zusätzlich sind die ECU 126 dazu programmiert, Ereignisdaten an mindestens einen zweiten Blockchain-Knoten 145 zu übertragen, z. B. über das Netzwerk. Der zweite Blockchain-Knoten 145 kann dann die Ereignisdaten in einen Ereignisblock einer zweiten Blockchain 202 speichern, wie nachstehend beschrieben.
  • Ein erster Blockchain-Knoten 127 ist eine Rechenvorrichtung in der Vielzahl von ersten Blockchain-Knoten 127, die eine Kopie der ersten Blockchain 201 speichert. Jeder erste Blockchain-Knoten 127 ist an einer jeweiligen ECU 126 gehostet. Auf die ersten Blockchain-Knoten 127 kann über das Fahrzeugkommunikationsnetzwerk 130 zugegriffen werden.
  • Die Vielzahl von ersten Blockchain-Knoten 127 verwaltet die erste Blockchain 201. Die Vielzahl von ersten Blockchain-Knoten 127 ist dazu programmiert, jeden ersten Blockchain-Knoten 127 der ersten Blockchain 201 zu validieren. Jeder erste Blockchain-Knoten 127 ist valide, wenn der erste Blockchain-Knoten 127 die gleichen Ereigniscodes wie mindestens ein anderer erster Blockchain-Knoten 127 speichert. Zum Beispiel kann die Vielzahl von ersten Blockchain-Knoten 127 jeden ersten Blockchain-Knoten 127 der ersten Blockchain 201 validieren, indem sie die in den jeweiligen ersten Blockchain-Knoten 127 der ersten Blockchain 201 gespeicherten Ereigniscodes vergleicht. Falls die gleichen Ereigniscodes in jedem ersten Blockchain-Knoten 127 der ersten Blockchain 201 gespeichert sind, bestimmt die Vielzahl von ersten Blockchain-Knoten 127, dass jeder erste Blockchain-Knoten 127 der ersten Blockchain 201 valide ist. Mit anderen Worten ist jeder erste Blockchain-Knoten 127, der den Ereigniscode speichert, valide. Falls im Gegenteil nicht die gleichen Ereigniscodes in jedem ersten Blockchain-Knoten 127 der ersten Blockchain 201 gespeichert sind, bestimmt die Vielzahl von ersten Blockchain-Knoten 127, dass der erste Blockchain-Knoten 127, der den Ereigniscode nicht aufweist, nicht valide ist. Mit anderen Worten ist jeder erste Blockchain-Knoten 127, der den Ereigniscode nicht aufweist, nicht valide.
  • Jede ECU 126, die einen validen ersten Blockchain-Knoten 127 der ersten Blockchain 201 beinhaltet, ist autorisiert, und jede ECU 126, die einen nicht validen ersten Blockchain-Knoten 127 der ersten Blockchain 201 beinhaltet, ist nicht autorisiert. Die autorisierten ECU 126 sind dazu programmiert, Daten zu speichern, die nicht autorisierte ECU identifizieren, z. B. in einem Speicher der jeweiligen ECU. Zum Beispiel können autorisierte ECU 126 die Kennung von nicht autorisierten ECU speichern. Zusätzlich können die ECU 126 die Daten, die jede autorisierte und/oder nicht autorisierte ECU identifizieren, z. B. die Kennung, dem zweiten Blockchain-Knoten 145 bereitstellen, z. B. über das Netzwerk 135. Die ECU 126 können dem zweiten Blockchain-Knoten 145 Daten, die die autorisierten und/oder nicht autorisierten ECU identifizieren, in einer gleichen oder einer anderen Übertragung wie die Ereignisdaten bereitstellen.
  • Das zweite Blockchain-Netzwerk 112 (wie in 1C gezeigt) beinhaltet die Vielzahl von zweiten Blockchain-Knoten 145, d. h. die Vielzahl von zweiten Blockchain-Knoten 145 ist ein Peer-to-Peer-Netzwerk. Knoten in der Vielzahl von zweiten Blockchain-Knoten 145 können durch den Hersteller des Fahrzeugs 105 vorgegeben sein und können in der zweiten Blockchain 202 aufgezeichnet sein.
  • Die zweite Blockchain 202 ist ein Distributed-Blockchain-Ledger. Das heißt, jeder zweite Blockchain-Knoten 145 speichert z. B. in einem Speicher eine Kopie der zweiten Blockchain 202. Die zweiten Blockchain-Knoten 145 können zum Beispiel Datenblöcke von anderen zweiten Blockchain-Knoten 145 empfangen und können die Datenblöcke in ihre jeweiligen Kopien der zweiten Blockchain 202 hochladen, d. h. die jeweiligen Datenblöcke in jeweiligen Speicherorten in ihren jeweiligen zweiten Blockchains 202 speichern. Ein Datenblock in der zweiten Blockchain 202 kann Ereigniscodes und Aktualisierungsdaten für eine ECU 126 darstellen und auf Grundlage einer Anforderung von einem zweiten Blockchain-Knoten 145 erzeugt werden. Jeder zweite Blockchain-Knoten 145 kann seine gespeicherten Blockchain-Daten, d. h. verlinkte Datenblöcke, mit Blockchains vergleichen, die durch andere zweite Blockchain-Knoten 145 gespeichert werden, um die Datenblöcke zu verifizieren. Zum Beispiel kann jeder zweite Blockchain-Knoten 145 einen Hash auf Grundlage der Daten erzeugen, die in einem jeweiligen Datenblock einer Blockchain gespeichert sind, die durch einen anderen zweiten Blockchain-Knoten 145 gespeichert wird. In dem Fall, dass der Hash, der durch den einen zweiten Blockchain-Knoten 145 erzeugt wird, mit dem Hash übereinstimmt, der durch den anderen zweiten Blockchain-Knoten 145 für den jeweiligen Datenblock gespeichert wird, bestimmt der eine zweite Blockchain-Knoten 145, dass der Datenblock verifiziert ist.
  • In diesem Zusammenhang ist ein „Aktualisierungscode“ eine ganze Zahl, z. B. null oder größer. Der Aktualisierungscode spezifiziert, wie oft eine jeweilige ECU 126 ausgetauscht und/oder modifiziert wurde. Insbesondere spezifiziert der Aktualisierungscode eine Anzahl von autorisierten Modifikationen und/oder Austauschen der ECU 126. Ein Austausch und/oder eine Modifikation der ECU 126 ist autorisiert, wenn er bzw. sie durch einen zweiten Blockchain-Knoten 145 durchgeführt wird, der durch die ECU 126 authentifiziert ist, wie nachstehend erörtert. Modifiziert bedeutet im vorliegenden Kontext, dass die Daten im Speicher der jeweiligen ECU verändert oder entfernt wurden.
  • Der Aktualisierungscode und der Ereigniscode können als eine einzelne Datenfolge in der ersten und zweiten Blockchain 201, 202 gespeichert sein. Zum Beispiel können der erste und der zweite Blockchain-Knoten 127, 145 den Aktualisierungscode und den Ereigniscode miteinander kombinieren, d. h. verketten, und die Kombination in den jeweiligen Blockchains 201, 202 speichern. Nach dem Kombinieren kann der Aktualisierungscode neben dem letzten Zeichen des Ereigniscodes gespeichert werden. Nicht einschränkende Beispiele für die kombinierte Datenfolge beinhalten z. B. „000“, „IFO“, „1Überschwemmung1“, „2S1“ usw. (wie aus dem Beispiel in der vorstehenden Tabelle 1 fortgeführt), wobei das letzte Zeichen der jeweiligen Zeichenfolge der Aktualisierungscode ist.
  • Ein zweiter Blockchain-Knoten 145 ist eine Rechenvorrichtung in der Vielzahl von zweiten Blockchain-Knoten 145, die eine Kopie des zweiten Blockchain 202 speichert. Jeder zweite Blockchain-Knoten 145 wird auf einer herkömmlichen Rechenvorrichtung 140 gehostet, d. h. beinhaltet einen oder mehrere Prozessoren und einen oder mehrere Speicher, die dazu programmiert sind, Vorgänge bereitzustellen, wie sie etwa hierin offenbart sind. Auf die zweiten Blockchain-Knoten 145 kann über das Kommunikationsnetzwerk 135 zugegriffen werden. Die Rechenvorrichtung 140, die jeden jeweiligen zweiten Blockchain-Knoten 145 hostet, kann einer Instanz zugeordnet sein, die an der Unterhaltung der zweiten Blockchain 202 beteiligt ist, um z. B. Daten in der zweiten Blockchain 202 zu verifizieren, um Daten in der zweiten Blockchain 202 zu speichern usw. Zum Beispiel kann ein zweiter Blockchain-Knoten 145 auf einem Computer gehostet sein, der einem Hersteller von Fahrzeugen zugeordnet ist, einem Computer, der einem Automobilzulieferer zugeordnet ist, der Fahrzeugkomponenten 125 herstellt usw. Jeder zweite Blockchain-Knoten 145 kann eine Kennung beinhalten. In diesem Kontext ist eine „Kennung“ eine alphanumerische Datenfolge, die einem spezifischen zweiten Blockchain-Knoten 145 entspricht. Anders ausgedrückt identifiziert die Kennung einen spezifischen zweiten Blockchain-Knoten 145.
  • Die Vielzahl von zweiten Blockchain-Knoten 145 verwaltet die zweite Blockchain 202. Das heißt, die Vielzahl von zweiten Blockchain-Knoten 145 kann von Zeit zu Zeit Anforderungen empfangen, um einen Knoten zu der Vielzahl von zweiten Blockchain-Knoten 145 hinzuzufügen. Der Knoten kann zum Beispiel ein externer Knoten von einem Lieferanten einer ECU 126 oder einem Händler von Fahrzeugen 105, wie etwa einem Vertragshändler, sein. Die Knoten in der Vielzahl von zweiten Blockchain-Knoten 145 bewerten die Anforderung. In dem Fall, dass die Anforderung genehmigt wird, z. B. über ein Konsensprotokoll (d. h. eine Mehrheit der zweiten Blockchain-Knoten 145 bestimmt, dass die Anforderung genehmigt wird), fügt die Vielzahl von zweiten Blockchain-Knoten 145 den Knoten zu der Vielzahl von zweiten Blockchain-Knoten 145 hinzu und fügt einen Datenblock zu der zweiten Blockchain 202 hinzu, die die Hinzufügung aufzeichnet.
  • Zusätzlich oder alternativ können die zweiten Blockchain-Knoten 145 einen Aktualisierungscode empfangen, z. B. von einer Benutzereingabe. Der Aktualisierungscode, wie vorstehend angegeben, spezifiziert eine Anzahl von Aktualisierungen, z. B. Austausch oder Modifikation, einer ECU 126. Zum Beispiel kann ein Benutzer während der Fahrzeugwartung in den zweiten Blockchain-Knoten 145, der z. B. durch eine Reparaturinstanz verwaltet wird, eingeben, dass der Benutzer entweder eine ECU 126 des Fahrzeugs 105 entfernt und die eine ECU 126 gegen eine andere ECU ausgetauscht oder Daten in dem Speicher modifiziert hat, z. B. die in dem Speicher der einen ECU 126 gespeicherten Daten gelöscht oder beseitigt hat. In dieser Situation ist der zweite Blockchain-Knoten 145 dazu programmiert, den Aktualisierungscode um einen Wert von 1 zu erhöhen, z. B. von 0 auf 1, von 1 auf 2 usw. Die Knoten der Vielzahl von zweiten Blockchain-Knoten 145 bewerten den Aktualisierungscode. In dem Fall, dass der Aktualisierungscode genehmigt wird, z. B. über ein Konsensprotokoll (d. h. eine Mehrheit der zweiten Blockchain-Knoten 145 bestimmt, dass der Aktualisierungscode genehmigt wird), fügt die Vielzahl von zweiten Blockchain-Knoten 145 einen Datenblock zu der zweiten Blockchain 202 hinzu, die die Autorisierung aufzeichnet. Nach dem Speichern des Aktualisierungscodes in die zweite Blockchain 202 ist der zweite Blockchain-Knoten 145 dazu programmiert, den Aktualisierungscode an die ECU 126 zu übertragen, z. B. über das Netzwerk 135. Die ECU 126 können dazu programmiert sein, einen jeweiligen Hash-Code zu erzeugen und den jeweiligen Hash-Code an den zweiten Blockchain-Knoten 145 zu übertragen. Der zweite Blockchain-Knoten 145 kann die jeweiligen Hash-Codes auf Grundlage eines digitalen Schlüssels verschlüsseln, um einen Challenge-Code zu erzeugen, und den verschlüsselten Hash-Code an die ECU 126 übertragen. Die ECU 126 können dann den verschlüsselten Hash-Code entschlüsseln. In dem Fall, dass der entschlüsselte Hash-Code mit dem Challenge-Code übereinstimmt, bestimmen die ECU 126, dass der zweite Blockchain-Knoten 145 autorisiert ist. Nach dem Bestimmen, dass der zweite Blockchain-Knoten 145 autorisiert ist, können die ECU 126 den Aktualisierungscode in den jeweiligen ersten Blockchain-Knoten 127 der ersten Blockchain 201 speichern.
  • 2A veranschaulicht einen Abschnitt einer ersten Blockchain 201 für das Fahrzeug, wie sie durch einen ersten Blockchain-Knoten 127 in einem ersten Blockchain-Netzwerk 111 gespeichert ist. Die erste Blockchain 201 ist ein Blockchain-Ledger, das Ereignisdaten und Aktualisierungsdaten speichert. Die erste Blockchain 201 beinhaltet Ereignisblöcke 212, 232 und Aktualisierungsblöcke 222, 242.
  • Nach dem Bestimmen, dass die ECU 126 einen Ereigniscode bestimmt, ist der jeweilige erste Blockchain-Knoten 127 dazu programmiert, die Erstellung eines Ereignisblocks 212 in der ersten Blockchain 201 einzuleiten. Ein Ereignisblock 212 ist ein Blockchain-Datenblock, der Ereignisdaten (wie vorstehend beschrieben) und typischerweise auch Daten von Sensoren 115 speichert, die durch die ECU 126 empfangen werden, die den Ereigniscode bestimmen. Der erste Blockchain-Knoten 127 speichert die Ereignisdaten und die Daten von Sensoren 115 in den Ereignisblock 212 in der ersten Blockchain 201. Zum Beispiel kann der erste Blockchain-Knoten 127 eine Kopie der Ereignisdaten und der Daten von Sensoren 115 im Speicher der jeweiligen ECU 126 und eine weitere Kopie der Ereignisdaten und der Daten von Sensoren 115 in den jeweiligen Ereignisblock 212 speichern. Alternativ kann der erste Blockchain-Knoten 127 einen oder mehrere Links erzeugen, die nachstehend erläutert werden, um auf die Ereignisdaten und die Daten von Sensoren 115 zuzugreifen. Jede ECU 126 kann dann den Link zu dem jeweiligen Ereignisblock 212 speichern.
  • Ein Link in diesem Kontext ist eine Adresse zu jeweiligen Ereignisdaten und/oder Daten von Sensoren 115, die an einem Ort außerhalb des Ereignisblocks 212 gespeichert ist. Der Link identifiziert einen Speicherort oder eine Adresse der jeweiligen Ereignisdaten und/oder Daten von Sensoren 115, z.B. einen Speicher der jeweiligen ECU 126, einen Speicher eines Fahrzeugcomputers 110 usw., und stellt ferner einen Code zum Verifizieren der jeweiligen Ereignisdaten und/oder Daten von Sensoren 115 bereit. Der Code des Links kann ein Hash der Daten sein, zu denen er einen Link bereitstellt. Der erste Blockchain-Knoten 127 kann einen oder mehrere Links erzeugen. Zum Beispiel kann der erste Blockchain-Knoten 127 einen Ereignisdatenlink 213 und einen Sensordatenlink 214 erzeugen. In einem derartigen Beispiel identifiziert der Ereignisdatenlink 213 einen Speicherort der Ereignisdaten und identifiziert der Sensordatenlink 214 einen Speicherort der Daten von Sensoren 115. Alternativ kann der erste Blockchain-Knoten 127 einen gemeinsamen Link für die Ereignisdaten und die Daten von Sensoren 115 erzeugen, der z. B. einen gemeinsamen Speicherort der Ereignisdaten und der Daten von Sensoren 115 identifiziert.
  • Der erste Blockchain-Knoten 127 kann einen öffentlichen ECU-Schlüssel speichern, z. B. in einem Speicher der jeweiligen ECU 126. Unter diesen Umständen kann der erste Blockchain-Knoten 127 einen Link 215 zum öffentlichen ECU-Schlüssel erzeugen und kann den Link 215 zum öffentlichen ECU-Schlüssel in dem Ereignisblock 212 speichern. Der öffentliche ECU-Schlüssel ist ein digitaler Schlüssel, der verwendet werden kann, um Übertragungen von der ECU 126 zu authentifizieren. Zum Beispiel können die anderen ECU 126 den öffentlichen ECU-Schlüssel einer ECU 126 verwenden, um Nachrichten von der jeweiligen ECU 126 zu entschlüsseln, wie vorstehend beschrieben. Der Link 215 zum öffentlichen ECU-Schlüssel ist ein Link, der den Speicherort oder die Adresse des öffentlichen ECU-Schlüssels identifiziert und ferner einen Code zum Verifizieren des öffentlichen ECU-Schlüssels bereitstellt. Der Code des Links 215 zum öffentlichen ECU-Schlüssel kann ein Hash des öffentlichen ECU-Schlüssels sein. Alternativ kann der erste Blockchain-Knoten 127 den öffentlichen ECU-Schlüssel in den Ereignisblock 212 speichern.
  • Der erste Blockchain-Knoten 127 kann einen Ereignis-Hash 216 und einen Aktualisierungsblocklink 217 erzeugen und den Ereignis-Hash 216 und den Aktualisierungsblocklink 217 in dem Ereignisblock speichern. Der Aktualisierungsblocklink 217 ist ein Blockchain-Link von einem Blockchain-Datenblock zu einem letzten vorherigen Blockchain-Datenblock. Unter diesen Umständen ist der Aktualisierungsblocklink 217 ein Link zwischen dem Ereignisblock 213 und dem letzten vorherigen Aktualisierungsblock 222. Der Aktualisierungsblocklink 217 ist ein Hash eines Datenspeichers in dem letzten vorherigen Aktualisierungsblock 222. Der Block „Ereignis 1“ 212 ist ein anfänglicher Block in der ersten Blockchain 201, und daher ist der im Block „Ereignis 1'' 212 gespeicherte Aktualisierungsblocklink 217 null (d. h. keine Daten).
  • Der Ereignis-Hash 216 ist eine Kennung eines Blockchain-Datenblocks, im vorliegenden Beispiel des Ereignisblocks 212. Der Ereignis-Hash 216 in diesem Beispiel ist ferner ein Hash der Daten, die in dem Ereignisblock 212 gespeichert sind. Zum Beispiel kann der Ereignis-Hash 216 ein Hash der Ereignisdaten, der Daten von Sensoren 115 und des Aktualisierungsblocklinks 217 sein. Alternativ kann der Ereignis-Hash 216 ein Hash des Ereignisdatenlinks 213, des Sensordatenlinks 214 und des Aktualisierungsblocklinks 217 sein.
  • Der erste Blockchain-Knoten 127 überträgt den Ereignisblock 212 an die anderen ersten Blockchain-Knoten 127 und die anderen ersten Blockchain-Knoten 127 validieren die Übertragung, wie vorstehend beschrieben. Nach dem Validieren der Übertragung speichern die ersten Blockchain-Knoten 127 den Ereignisblock 212 in die erste Blockchain 201. Die ECU 126 übertragen dann die Ereignisdaten an die zweiten Blockchain-Knoten 145, z. B. über das Netzwerk 135. Nach dem Empfangen der Ereignisdaten können die zweiten Blockchain-Knoten 145 die Ereignisdaten gemäß den autorisierten ECU 126 validieren. Das heißt, der zweite Blockchain-Knoten 145 kann die von autorisierten ECU empfangenen Ereignisdaten validieren und kann die von nicht autorisierten ECU empfangenen Ereignisdaten für nicht valide erklären.
  • Nach dem Autorisieren des zweiten Blockchain-Knotens 145 sind die ersten Blockchain-Knoten 127 dazu programmiert, die Erstellung eines Aktualisierungsblocks 222 in der ersten Blockchain 201 einzuleiten. Ein Aktualisierungsblock ist ein Blockchain-Datenblock, der Aktualisierungsdaten speichert, wie nachstehend beschrieben. Die ersten Blockchain-Knoten 127 speichern die Aktualisierungsdaten in den Aktualisierungsblock 222 in der ersten Blockchain 201. Zum Beispiel können die ersten Blockchain-Knoten 127 eine Kopie der Aktualisierungsdaten im Speicher der jeweiligen ECU 126 und eine weitere Kopie der Aktualisierungsdaten in den Aktualisierungsblock 222 speichern. Alternativ können die ersten Blockchain-Knoten 127 einen oder mehrere Links erzeugen, die nachstehend erläutert werden, um auf die Aktualisierungsdaten zuzugreifen. Die ersten Blockchain-Knoten 127 können dann den Link zu dem Aktualisierungsblock 222 speichern.
  • Die ersten Blockchain-Knoten 127 können einen Aktualisierungsdatenlink 263 (wie nachstehend beschrieben), einen Link 264 zum öffentlichen Knotenschlüssel (wie nachstehend beschrieben) und einen Aktualisierungs-Hash 265 (wie nachstehend beschrieben) in dem Aktualisierungsdatenblock 222 speichern.
  • Die ersten Blockchain-Knoten 127 können einen Ereignisblocklink 223 erzeugen und den Ereignisblocklink 223 in den Aktualisierungsblock 222 speichern. Der Ereignisblocklink 223 ist ein Blockchain-Link von einem Blockchain-Datenblock zu einem letzten vorherigen Blockchain-Datenblock. Unter diesen Umständen ist der Ereignisblocklink 223 ein Link zwischen dem Aktualisierungsblock 222 und dem letzten vorherigen Ereignisblock 212. Der Ereignisblocklink 223 ist ein Hash von Daten, die in dem letzten vorherigen Ereignisblock 212 gespeichert sind.
  • 2B veranschaulicht einen Abschnitt einer zweiten Blockchain 202 für das Fahrzeug 105, wie sie durch einen zweiten Blockchain-Knoten 145 in einem zweiten Blockchain-Netzwerk 112 gespeichert ist. Die zweite Blockchain 202 ist ein Blockchain-Ledger, das Ereignisdaten und Aktualisierungsdaten speichert. Die zweite Blockchain 202 beinhaltet Ereignisblöcke 252, 272 und Aktualisierungsblöcke 262, 282.
  • Nach dem Empfangen der Ereignisdaten von den autorisierten ECU 126 ist der zweite Blockchain-Knoten 145 dazu programmiert, die Erstellung eines Ereignisblocks 252 in dem zweiten Blockchain-Knoten 145 der zweiten Blockchain 202 einzuleiten. Ein Ereignisblock ist ein Blockchain-Datenblock, der Ereignisdaten speichert (wie vorstehend beschrieben). Der zweite Blockchain-Knoten 145 speichert die Ereignisdaten in den Ereignisblock 252 in der zweiten Blockchain 202. Zum Beispiel kann der zweite Blockchain-Knoten 145 eine Kopie der Ereignisdaten in dem Speicher des Computers, der den zweiten Blockchain-Knoten 145 hostet, und eine andere Kopie der Ereignisdaten in den jeweiligen Ereignisblock 252 speichern. Alternativ kann der zweite Blockchain-Knoten 145 einen oder mehrere Links erzeugen, die nachstehend erläutert werden, um auf die Ereignisdaten zuzugreifen. Der zweite Blockchain-Knoten 145 kann dann den Link zu dem jeweiligen Ereignisblock 252 speichern.
  • Der zweite Blockchain-Knoten 145 kann den Ereignisdatenlink 213 (wie vorstehend beschrieben) und den Link 215 zum öffentlichen ECU-Schlüssel (wie vorstehend beschrieben) speichern. Der Ereignisblock 252 weist keinen Sensordatenlink 224 auf.
  • Der zweite Blockchain-Knoten 145 kann einen Aktualisierungsblocklink 253 und einen Ereignis-Hash 254 erzeugen und speichert den Aktualisierungsblocklink 253 und den Ereignis-Hash 254 in den Ereignisblock 252. Der Ereignisblocklink 253 ist ein Blockchain-Link von einem Blockchain-Datenblock zu dem letzten vorherigen Blockchain-Datenblock. Unter diesen Umständen ist der Ereignisblocklink 253 ein Link zwischen dem Ereignisblock 252 und dem letzten vorherigen Aktualisierungsblock. Der Ereignisblocklink 253 ist ein Hash von Daten, die in dem letzten vorherigen Aktualisierungsblock gespeichert sind. Der Block „Ereignis 1'' 252 ist ein anfänglicher Block in dem zweiten Blockchain-Ledger 202, und daher ist der im Block „Ereignis 1'' 252 gespeicherte Aktualisierungsblocklink 253 null (d. h. keine Daten).
  • Der Ereignis-Hash 254 ist eine Kennung eines Blockchain-Datenblocks, im vorliegenden Beispiel des Ereignisblocks 252. Der Ereignis-Hash 254 in diesem Beispiel ist ferner ein Hash der Daten, die in dem Ereignisblock 252 gespeichert sind. Zum Beispiel kann der Ereignis-Hash 254 ein Hash der Ereignisdaten, des öffentlichen ECU-Schlüssels und des Aktualisierungsblocklinks 217 sein. Alternativ kann der Ereignis-Hash 216 ein Hash des Ereignisdatenlinks 213, des Links 215 zum öffentlichen ECU-Schlüssel und des Aktualisierungsblocklinks 217 sein.
  • Nach dem Bestimmen eines Aktualisierungscodes ist der zweite Blockchain-Knoten 145 dazu programmiert, die Erstellung des Aktualisierungsblocks 262 einzuleiten. Ein Aktualisierungsblock ist ein Blockchain-Datenblock, der Aktualisierungsdaten speichert. Aktualisierungsdaten sind Daten, die den Aktualisierungscode und die Kennung für den zweiten Blockchain-Knoten 145 angeben. Der zweite Blockchain-Knoten 145 kann die Aktualisierungsdaten in den Aktualisierungsblock 262 speichern. Zum Beispiel kann der zweite Blockchain-Knoten 145 eine Kopie der Aktualisierungsdaten in einem Speicher des Computers, der den zweiten Blockchain-Knoten 145 hostet, und eine andere Kopie der Aktualisierungsdaten in den jeweiligen Aktualisierungsblock 262 speichern. Alternativ kann der zweite Blockchain-Knoten 145 einen oder mehrere Links erzeugen, wie nachstehend erläutert, um auf die Aktualisierungsdaten zuzugreifen. Der zweite Blockchain-Knoten 145 kann die Links in den Aktualisierungsblock 262 speichern.
  • Ein Link in diesem Kontext ist eine Adresse zu jeweiligen Aktualisierungsdaten, die an einem Ort außerhalb des Aktualisierungsblocks gespeichert ist. Der Link identifiziert einen Speicherort der Aktualisierungsdaten, z. B. einen Speicher eines Computers, der einen zweiten Blockchain-Knoten 145 hostet, einen Speicher eines Fahrzeugcomputers usw. und stellt ferner einen Code zum Verifizieren der Aktualisierungsdaten bereit. Der Code des Links kann ein Hash der Daten sein, zu denen er einen Link bereitstellt. Zum Beispiel kann der zweite Blockchain-Knoten 145 einen Aktualisierungsdatenlink 263 erzeugen, der z. B. einen gemeinsamen Speicherort des Aktualisierungscodes und der Kennung für den zweiten Blockchain-Knoten 145 identifiziert. Alternativ kann der zweite Blockchain-Knoten 145 im Wesentlichen eindeutige Aktualisierungslinks für den Aktualisierungscode und die Kennung für den zweiten Blockchain-Knoten 145 erzeugen.
  • Der zweite Blockchain-Knoten 145 kann einen öffentlichen Knotenschlüssel speichern, z. B. in einem Speicher des Computers, der den zweiten Blockchain-Knoten 145 hostet. Unter diesen Umständen kann der zweite Blockchain-Knoten 145 einen Link 264 zum öffentlichen Knotenschlüssel erzeugen und kann den Link 264 zum öffentlichen Knotenschlüssel in den Aktualisierungsblock speichern. Der öffentliche Knotenschlüssel kann ein digitaler Schlüssel sein, der den zweiten Blockchain-Knoten 145 validieren kann. Zum Beispiel können die ECU 126 den öffentlichen Knotenschlüssel verwenden, um Nachrichten von dem zweiten Blockchain-Knoten 145 zu entschlüsseln, wie vorstehend beschrieben. Der Link 264 zum öffentlichen Knotenschlüssel ist ein Link, der den Speicherort oder die Adresse des öffentlichen Knotenschlüssels identifiziert und ferner einen Code zum Verifizieren des öffentlichen Knotenschlüssels bereitstellt. Der Code des Links 264 zum öffentlichen Knotenschlüssel kann ein Hash des öffentlichen Knotenschlüssels sein. Alternativ kann der zweite Blockchain-Knoten 145 den öffentlichen Knotenschlüssel in den Aktualisierungsblock 262 speichern.
  • Der zweite Blockchain-Knoten 145 kann einen Aktualisierungs-Hash 265 und einen Ereignisblocklink 266 erzeugen und speichert den Aktualisierungs-Hash und den Ereignisblocklink 266 in den Aktualisierungsblock 262. Der Ereignisblocklink 266 ist ein Blockchain-Link von einem Blockchain-Datenblock zu dem letzten vorherigen Blockchain-Datenblock. Unter diesen Umständen ist der Ereignisblocklink 266 ein Link zwischen dem Aktualisierungsblock 262 und dem letzten vorherigen Ereignisblock 252. Der Ereignisblocklink 266 ist ein Hash von Daten, die in dem letzten vorherigen Ereignisblock 252 gespeichert sind.
  • Der Aktualisierungs-Hash 265 ist eine Kennung eines Blockchain-Datenblocks, im vorliegenden Beispiel des Aktualisierungblocks 262. Der Aktualisierungs-Hash 265 in diesem Beispiel ist ferner ein Hash der Daten, die in dem Aktualisierungsblock 262 gespeichert sind. Zum Beispiel kann der Aktualisierungs-Hash 265 ein Hash des Aktualisierungscodes, der Kennung für den Blockchain-Knoten 145 und des Ereignisblocklinks 266 sein. Als ein weiteres Beispiel kann der Aktualisierungs-Hash 265 ein Hash des Aktualisierungsdatenlinks 263 und des Ereignisblocklinks 266 sein.
  • Der zweite Blockchain-Knoten 145 speichert die Aktualisierungsblöcke 262 in die zweite Blockchain 202. Der zweite Blockchain-Knoten 145 überträgt dann die Aktualisierungsdaten an die ECU 126, z. B. über das Netzwerk. Die ECU 126 autorisieren den zweiten Blockchain-Knoten 145, wie vorstehend beschrieben. Nachdem die ECU 126 den zweite Blockchain-Knoten 145 autorisiert haben, speichern die ersten Blockchain-Knoten 127 die Aktualisierungsdaten in die erste Blockchain 201, wie vorstehend beschrieben.
  • 3 veranschaulicht einen beispielhaften Prozess 300 zum Aktualisieren der ersten und zweiten Blockchain 201, 202. Der Prozess startet in einem Block 305.
  • In Block 305 bestimmen die ersten Blockchain-Knoten 127 die Validität der jeweiligen anderen. Zum Beispiel können die ersten Blockchain-Knoten 127 die Ereigniscodes, die in jedem ersten Blockchain-Knoten 127 der ersten Blockchain 201 gespeichert sind, vergleichen. Falls die Ereigniscodes in jedem ersten Blockchain-Knoten 127 der ersten Blockchain 201 die gleichen sind, bestimmen die ersten Blockchain-Knoten 127, dass jeder erste Blockchain-Knoten 127 valide ist. Falls die Ereigniscodes in jedem ersten Blockchain-Knoten 127 der ersten Blockchain 201 nicht die gleichen sind, bestimmen die ersten Blockchain-Knoten 127, dass mindestens ein erster Blockchain-Knoten 127 nicht valide ist. Unter diesen Umständen bestimmen die ersten Blockchain-Knoten 127, dass der erste Blockchain-Knoten 127, der den Ereigniscode nicht aufweist, nicht valide ist. Die ersten Blockchain-Knoten 127 bestimmen die Validität über ein Konsensprotokoll, d. h. eine Mehrheit der ersten Blockchain-Knoten 127 bestimmt die Validität des jeweiligen ersten Blockchain-Knotens 127. In dem Fall, dass jeder erste Blockchain-Knoten 127 valide ist, wird der Prozess 300 in einem Block 315 fortgesetzt. In dem Fall, dass mindestens ein erster Blockchain-Knoten 127 nicht valide ist, wird der Prozess 300 in einem Block 310 fortgesetzt.
  • In Block 310 identifizieren die ECU 126 die eine oder mehreren nicht autorisierten ECU. Eine ECU ist nicht autorisiert, wenn die ECU einen nicht validen ersten Blockchain-Knoten 127 beinhaltet, d. h. einen ersten Blockchain-Knoten 127 der ECU mit fehlendem Ereigniscode. Unter diesen Umständen speichern die autorisierten ECU, d. h. die ECU, die erste Blockchain-Knoten 127 beinhalten, die den Ereigniscode speichern, die Kennung der nicht autorisierten ECU, z. B. in einem jeweiligen Speicher. Der Prozess 300 wird in Block 315 fortgesetzt.
  • In Block 315 empfangen die ECU 126 Daten von Sensoren 115. Jede ECU 126 empfängt Daten von Sensoren 115 von einem oder mehreren Sensoren 115, z. B. über das Fahrzeugnetzwerk. Die ECU 126 können Daten von demselben oder von unterschiedlichen Sensoren empfangen. Der Prozess 300 wird in Block 320 fortgesetzt.
  • In Block 320 bestimmen die ECU 126 als Reaktion auf das Empfangen der Daten von Sensoren 115 einen Ereigniscode. Zum Beispiel können die ECU 126 die Daten von Sensoren 115 analysieren, um den Ereigniscode zu bestimmen. Jede ECU 126 kann zum Beispiel den Ereigniscode basierend auf Tabelle 1 bestimmen, wie vorstehend gezeigt. In dem Fall, dass eine ECU 126 einen Ereigniscode bestimmt, überträgt die eine ECU 126 den Ereigniscode an die anderen ECU 126 und der Prozess 300 wird in einem Block 325 fortgesetzt. Andernfalls kehrt der Prozess 300 zu Block 305 zurück.
  • In Block 325 speichern die ECU 126 den Ereigniscode in der ersten Blockchain 201. Zum Beispiel erzeugen die ersten Blockchain-Knoten 127 einen Ereignis-N-Block 232, um Ereignis-N-Daten und Sensor-N-Daten in dem jeweiligen ersten Blockchain-Knoten 127 der ersten Blockchain 201 zu speichern. N ist eine ganze Zahl mit einem Wert von 1 oder größer. Ein Ereignis-N-Block 232 ist ein aktueller und N-ter Ereignisblock, für den Daten in der ersten Blockchain 201 gespeichert sind. Ereignis-N-Daten und Sensor-N-Daten sind Daten, die das N-te Ereignis im Wesentlichen eindeutig identifizieren. Die Ereignis-N-Daten und die Sensor-N-Daten können an einem Ort außerhalb des Ereignis-N-Blocks 232 gespeichert sein, z. B. in einem Speicher des Fahrzeugcomputers 110, einem zentralen Server usw. In dieser Situation können die ersten Blockchain-Knoten 127 einen Ereignisdatenlink 213, einen Sensordatenlink 214 und einen Link 215 zum öffentlichen ECU-Schlüssel erzeugen, die einen Link zu den jeweiligen Daten herstellen. In dieser Situation speichern die ersten Blockchain-Knoten 127 die Links 213, 214, 215 in dem Ereignis-N-Block 232. Alternativ können die ersten Blockchain-Knoten 127 die Ereignis-N-Daten und die Sensor-N-Daten im Ereignis-N-Block 232 speichern.
  • Zusätzlich erzeugen die ersten Blockchain-Knoten 127 einen Aktualisierung-N-1-Blocklink 217 und einen Ereignis-Hash 216. Die ersten Blockchain-Knoten 127 speichern dann den Aktualisierung-N-1-Blocklink 217 und den Ereignis-Hash 216 in den Ereignis N-Block 232. Der Prozess 300 endet nach Block 350. Der Prozess 300 wird in einem Block 330 fortgesetzt.
  • In Block 330 bestimmen die ECU 126, ob ein zweiter Blockchain-Knoten 145 erfasst wird. Zum Beispiel können die ECU 126 den zweiten Blockchain-Knoten 145 basierend auf dem Empfangen einer Nachricht von dem zweiten Blockchain-Knoten 145 erfassen, z. B. über das Netzwerk 135. Die ECU 126 können dann die Ereignisdaten an den zweiten Blockchain-Knoten 145 übertragen. Zusätzlich können die ECU 126 die Kennung der nicht autorisierten ECU, falls vorhanden, an den zweiten Blockchain-Knoten 145 übertragen, z. B. in einer gleichen oder einer anderen Übertragung. In dem Fall, dass die ECU 126 den zweiten Blockchain-Knoten 145 erfassen, wird der Prozess 300 in einem Block 335 fortgesetzt. Andernfalls verbleibt der Prozess 300 in Block 330.
  • In Block 335 kann der zweite Blockchain-Knoten 145 nach dem Empfangen der Ereignisdaten von den ECU 126 die Ereignisdaten in die zweite Blockchain 202 speichern. Zum Beispiel generiert der zweite Blockchain-Knoten 145 einen Ereignis-N-Block 272, um die Ereignisdaten in der zweiten Blockchain 202 zu speichern. N ist eine ganze Zahl von 1 oder größer. Ein Ereignis-N-Block 272 ist ein aktueller und N-ter Ereignisblock, für den Daten in der zweiten Blockchain 202 gespeichert sind. Ereignis-N-Daten sind Daten, die das N-te Ereignis im Wesentlichen eindeutig identifizieren. Die Ereignis-N-Daten können an einem Ort außerhalb des Ereignis-N-Blocks 272 gespeichert sein, z. B. in einem Speicher des Fahrzeugcomputers 110, einem zentralen Server, einem Speicher des zweiten Blockchain-Knotens 145 usw. In dieser Situation kann der zweite Blockchain-Knoten 145 den Ereignisdatenlink 213 und den Link 215 zum öffentlichen ECU-Schlüssel erzeugen, die einen Link zu den jeweiligen Daten herstellen. In dieser Situation speichert der zweite Blockchain-Knoten 145 die Links 213, 215 in dem Ereignis-N-Block 272. Alternativ kann der zweite Blockchain-Knoten 145 die Ereignis-N-Daten im Ereignis-N-Block 272 speichern.
  • Zusätzlich erzeugt der zweite Blockchain-Knoten 145 einen Aktualisierung-N-1-Blocklink 253 und den Ereignis-Hash 254. Der zweite Blockchain-Knoten 145 speichert dann den Aktualisierung-N-1-Blocklink 253 und den Ereignis-Hash 254 in den Ereignis-N-Block 272. Der Prozess 300 wird in einem Block 340 fortgesetzt.
  • In Block 340 kann der zweite Blockchain-Knoten 145 einen Aktualisierungscode bestimmen. Zum Beispiel kann der zweite Blockchain-Knoten 145 eine Benutzereingabe empfangen, die eine Aktualisierung an mindestens einer ECU 126 angibt. Zum Beispiel kann eine ECU 126 gegen eine andere ECU ausgetauscht werden. Als ein weiteres Beispiel können die Daten in dem Speicher einer ECU 126 gelöscht oder verändert werden. In dem Fall, dass der zweite Blockchain-Knoten 145 eine Eingabe empfängt, die eine Aktualisierung an mindestens einer ECU 126 angibt, erzeugt der zweite Blockchain-Knoten 145 den Aktualisierungscode und der Prozess 300 wird in einem Block 345 fortgesetzt. Andernfalls verbleibt der Prozess 300 in Block 340.
  • In Block 345 speichert der zweite Blockchain-Knoten 145 nach dem Bestimmen des Aktualisierungscodes den Aktualisierungscode in den zweiten Blockchain-Knoten 145 der zweiten Blockchain 202. Zum Beispiel erzeugt der zweite Blockchain-Knoten 145 einen Aktualisierung-N-Block 282, um die Aktualisierungsdaten in der zweiten Blockchain 202 zu speichern. N ist eine ganze Zahl von 1 oder größer. Ein Aktualisierung-N-Block 282 ist ein aktueller und N-ter Aktualisierungsblock, für den Daten in der zweiten Blockchain 202 gespeichert sind. Aktualisierung-N-Daten sind Daten, die die N-te Aktualisierung im Wesentlichen eindeutig identifizieren. Die Aktualisierung-N-Daten können an einem Ort außerhalb des Aktualisierung-N-Blocks 282 gespeichert sein, z. B. in einem Speicher des Fahrzeugcomputers 110, einem zentralen Server, einem Speicher des zweiten Blockchain-Knotens 145 usw. In dieser Situation kann der zweite Blockchain-Knoten 145 den Aktualisierungsdatenlink 263 und einen Link 264 zum öffentlichen Knotenschlüssel erzeugen, die einen Link zu den jeweiligen Daten herstellen. In dieser Situation speichert der zweite Blockchain-Knoten 145 die Links 263, 264 in dem Aktualisierung-N-Block 282. Alternativ kann der zweite Blockchain-Knoten 145 die Aktualisierung-N-Daten im Aktualisierung-N-Block 282 speichern.
  • Zusätzlich erzeugt der zweite Blockchain-Knoten 145 einen Ereignis-N-1-Blocklink 266 und einen Aktualisierungs-Hash 265. Der zweite Blockchain-Knoten 145 speichert dann den Ereignis-N-1 -Blocklink 266 und den Aktualisierungs-Hash 265 in den Aktualisierung-N-Block 282. Der zweite Blockchain-Knoten 145 kann dann die Aktualisierungsdaten und den öffentlichen Schlüsselknoten an die ECU 126 übertragen, und der Prozess 300 wird in einem Block 350 fortgesetzt.
  • In Block 350 bestimmen die ECU 126, ob der zweite Blockchain-Knoten 145 valide ist. Zum Beispiel können die ECU 126 einen Challenge-Hash erzeugen und an den zweiten Blockchain-Knoten 145 übertragen. Der zweite Blockchain-Knoten 145 antwortet dann auf die ECU 126. Zum Beispiel kann der zweite Blockchain-Knoten 145 z. B. auf Grundlage eines ersten digitalen Schlüssels den von den ECU 126 empfangenen Challenge-Hash verschlüsseln und/oder kann die Kennung des zweiten Blockchain-Knotens 145 verschlüsseln und kann den verschlüsselten Challenge-Hash und/oder die verschlüsselte Kennung des zweiten Blockchain-Knotens 145 an die ECU 126 übertragen.
  • Die ECU 126 entschlüsseln dann z. B. auf Grundlage eines zweiten digitalen Schlüssels den verschlüsselten Challenge-Hash und die verschlüsselte Kennung des zweiten Blockchain-Knotens 145. In dem Fall, dass der zweite Blockchain-Knoten 145 ein autorisierter zweiter Blockchain-Knoten 145 für das Fahrzeug 105 ist, können sich der erste digitale Schlüssel und der zweite digitale Schlüssel derart entsprechen, dass durch den ersten digitalen Schlüssel verschlüsselte Daten mit dem zweiten digitalen Schlüssel entschlüsselt und wiederhergestellt werden können. Die ECU 126 vergleichen dann den entschlüsselten Hash mit dem Challenge-Hash. In dem Fall, dass der entschlüsselte Hash mit dem Challenge-Hash übereinstimmt, bestimmen die ECU 126, dass der zweite Blockchain-Knoten 145 ein autorisierter zweiter Blockchain-Knoten 145 ist. Alternativ oder zusätzlich können die ECU 126 die entschlüsselte Kennung für den zweiten Blockchain-Knoten 145 mit einer Liste autorisierter Kennungen vergleichen und beim Identifizieren einer Übereinstimmung bestimmen, dass der zweite Blockchain-Knoten 145 ein autorisierter zweiter Blockchain-Knoten 145 ist. In dem Fall, dass die ECU 126 bestimmen, dass der zweite Blockchain-Knoten 145 ein autorisierter zweiter Blockchain-Knoten 145 ist, wird der Prozess 300 in einem Block 355 fortgesetzt. Andernfalls endet der Prozess 300.
  • In Block 355 speichern die ersten Blockchain-Knoten 127 die Aktualisierungsdaten in der ersten Blockchain 201, nachdem die ECU 126 den zweiten Blockchain-Knoten 145 validiert haben. Zum Beispiel erzeugen die ersten Blockchain-Knoten 127 einen Aktualisierung-N-Block 242, um die Daten in dem jeweiligen ersten Blockchain-Knoten 127 der ersten Blockchain 201 zu speichern. N ist eine ganze Zahl von 1 oder größer. Ein Aktualisierung-N-Block 242 ist ein aktueller und N-ter Aktualisierungsblock, für den Daten in der ersten Blockchain 201 gespeichert sind. Aktualisierung-N-Daten sind Daten, die die N-te Aktualisierung eindeutig identifizieren. Die Aktualisierung-N-Daten können an einem Ort außerhalb des Aktualisierung-N-Blocks 242 gespeichert sein, z. B. in einem Speicher des Fahrzeugcomputers 110, einem zentralen Server usw. In dieser Situation können die ersten Blockchain-Knoten 127 den Aktualisierungsdatenlink 263 und den Link 264 zum öffentlichen Knotenschlüssel erzeugen, die einen Link zu den jeweiligen Daten herstellen. In dieser Situation speichern die ersten Blockchain-Knoten 127 die Links 263, 264 in dem Aktualisierung-N-Block 242. Alternativ können die ersten Blockchain-Knoten 127 die Aktualisierung-N-Daten im Aktualisierung-N-Block 242 speichern.
  • Zusätzlich erzeugen die ersten Blockchain-Knoten 127 einen Ereignis-N-1-Blocklink 223 und den Ereignis-Hash 265. Die ersten Blockchain-Knoten 127 speichern dann den Ereignis-N-1-Blocklink 223 und den Aktualisierungs-Hash 265 in den Aktualisierung-N-Block 242. Der Prozess 300 endet nach Block 350.
  • Im vorliegenden Zusammenhang bedeutet das Adverb „im Wesentlichen“, dass eine Form, eine Struktur, ein Maß, eine Menge, eine Zeit usw. aufgrund von Mängeln bei Materialien, Bearbeitung, Herstellung, Datenübertragung, Berechnungszeit usw. von einem bzw. einer genauen beschriebenen Geometrie, Abstand, Maß, Menge, Zeit usw. abweichen kann.
  • Im Allgemeinen können die beschriebenen Rechensysteme und/oder -vorrichtungen ein beliebiges aus einer Reihe von Computerbetriebssystemen einsetzen, einschließlich unter anderem Versionen und/oder Varianten der Anwendung Ford Sync®, der Middleware AppLink/Smart Device Link, des Betriebssystems Microsoft Automotive®, des Betriebssystems Microsoft Windows®, des Betriebssystems Unix (z. B. des Betriebssystems Solaris®, vertrieben durch die Oracle Corporation in Redwood Shores, Kalifornien), des Betriebssystems AIX UNIX, vertrieben durch International Business Machines in Armonk, New York, des Betriebssystems Linux, der Betriebssysteme Mac OSX und iOS, vertrieben durch die Apple Inc. in Cupertino, Kalifornien, des BlackBerry OS, vertrieben durch die Blackberry, Ltd. in Waterloo, Kanada, und des Betriebssystems Android, entwickelt durch die Google, Inc. und die Open Handset Alliance, oder der QNX® CAR Platform for Infotainment, angeboten durch QNX Software Systems. Beispiele für Rechenvorrichtungen schließen unter anderem einen bordeigenen Fahrzeugcomputer, einen Computerarbeitsplatz, einen Server, einen Desktop-, einen Notebook-, einen Laptop- oder einen Handcomputer oder ein anderes Rechensystem und/oder eine andere Rechenvorrichtung ein.
  • Computer und Rechenvorrichtungen beinhalten im Allgemeinen computerausführbare Anweisungen, wobei die Anweisungen durch eine oder mehrere Rechenvorrichtungen ausgeführt werden können, wie etwa durch die vorangehend aufgeführten. Computerausführbare Anweisungen können von Computerprogrammen zusammengestellt oder ausgewertet werden, die unter Verwendung einer Vielfalt von Programmiersprachen und/oder -technologien erstellt werden, einschließlich unter anderem und entweder für sich oder in Kombination Java™, C, C++, Matlab, Simulink, Stateflow, Visual Basic, Java Script, Perl, HTML usw. Einige dieser Anwendungen können auf einer virtuellen Maschine zusammengestellt und ausgeführt werden, wie etwa der Java Virtual Machine, der Dalvik Virtual Machine oder dergleichen. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wodurch er einen oder mehrere Prozesse durchführt, einschließlich eines oder mehrerer der in dieser Schrift beschriebenen Prozesse. Solche Anweisungen und andere Daten können unter Verwendung einer Vielfalt von computerlesbaren Medien gespeichert und übertragen werden. Eine Datei in einer Rechenvorrichtung ist im Allgemeinen eine Sammlung von Daten, die auf einem computerlesbaren Medium, wie etwa einem Speichermedium, einem Direktzugriffsspeicher usw., gespeichert sind.
  • Der Speicher kann ein computerlesbares Medium (auch als prozessorlesbares Medium bezeichnet) beinhalten, das ein beliebiges nichttransitorisches (z. B. materielles) Medium beinhaltet, das am Bereitstellen von Daten (z. B. Anweisungen) beteiligt ist, die durch einen Computer (z. B. durch einen Prozessor eines Computers) ausgelesen werden können. Ein solches Medium kann viele Formen annehmen, einschließlich unter anderem nichtflüchtiger Medien und flüchtiger Medien. Nichtflüchtige Medien können zum Beispiel optische Platten oder Magnetplatten und anderen dauerhaften Speicher beinhalten. Zu flüchtigen Medien kann zum Beispiel dynamischer Direktzugriffsspeicher (dynamic random access memory - DRAM) gehören, der typischerweise einen Hauptspeicher darstellt. Derartige Anweisungen können durch ein oder mehrere Übertragungsmedien übertragen werden, darunter Koaxialkabel, Kupferdraht und Glasfaser, einschließlich der Drähte, aus denen ein Systembus besteht, der an einen Prozessor einer ECU gekoppelt ist. Gängige Formen computerlesbarer Medien schließen zum Beispiel Folgendes ein: eine Diskette, eine Folienspeicherplatte, eine Festplatte, ein Magnetband, ein beliebiges anderes magnetisches Medium, eine CD-ROM, eine DVD, ein beliebiges anderes optisches Medium, Lochkarten, Lochstreifen, ein beliebiges anderes physisches Medium mit Lochmustern, einen RAM, einen PROM, einen EPROM, einen FLASH-EEPROM, einen beliebigen anderen Speicherchip oder eine beliebige andere Speicherkassette oder ein beliebiges anderes Medium, das durch einen Computer ausgelesen werden kann.
  • Datenbanken, Datendepots oder andere Datenspeicher, die in dieser Schrift beschrieben sind, können verschiedene Arten von Mechanismen zum Speichern von, Zugreifen auf und Abrufen von verschiedene(n) Arten von Daten beinhalten, einschließlich einer hierarchischen Datenbank, eines Satzes von Dateien in einem Dateisystem, einer Anwendungsdatenbank in einem anwendereigenen Format, eines relationalen Datenbankverwaltungssystems (relational database management system - RDBMS) usw. Jeder solche Datenspeicher ist im Allgemeinen innerhalb einer Rechenvorrichtung enthalten, die ein Computerbetriebssystem einsetzt, wie etwa eines der vorangehend erwähnten, und es wird auf eine oder mehrere von einer Vielfalt von Weisen über ein Netzwerk darauf zugegriffen. Auf ein Dateisystem kann von einem Computerbetriebssystem zugegriffen werden und es kann in verschiedenen Formaten gespeicherte Dateien beinhalten. Ein RDBMS setzt im Allgemeinen die Structured Query Language (SQL) zusätzlich zu einer Sprache zum Erzeugen, Speichern, Editieren und Ausführen gespeicherter Vorgänge ein, wie etwa die vorangehend erwähnte PL/SQL-Sprache.
  • In einigen Beispielen können Systemelemente als computerlesbare Anweisungen (z. B. Software) auf einer oder mehreren Rechenvorrichtungen (z. B. Servern, Personal Computern usw.) implementiert sein, die auf zugeordneten computerlesbaren Medien (z. B. Platten, Speichern usw.) gespeichert sind. Ein Computerprogrammprodukt kann solche auf computerlesbaren Medien gespeicherte Anweisungen zum Ausführen der in dieser Schrift beschriebenen Funktionen umfassen.
  • Hinsichtlich der in dieser Schrift beschriebenen Medien, Prozesse, Systeme, Verfahren, Heuristiken usw. versteht es sich, dass die Schritte solcher Prozesse usw. zwar als gemäß einer gewissen geordneten Abfolge erfolgend beschrieben worden sind, solche Prozesse jedoch so umgesetzt werden können, dass die beschriebenen Schritte in einer Reihenfolge durchgeführt werden, die von der in dieser Schrift beschriebenen Reihenfolge abweicht. Es versteht sich ferner, dass gewisse Schritte gleichzeitig durchgeführt, andere Schritte hinzugefügt oder gewisse in dieser Schrift beschriebene Schritte weggelassen werden können. Anders ausgedrückt, dienen die Beschreibungen von Prozessen in dieser Schrift dem Zwecke der Veranschaulichung gewisser Ausführungsformen, und sie sollten keinesfalls dahingehend ausgelegt werden, dass sie die Patentansprüche einschränken.
  • Dementsprechend versteht es sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Viele Ausführungsformen und Anwendungen, bei denen es sich nicht um die bereitgestellten Beispiele handelt, wären dem Fachmann nach der Lektüre der vorangehenden Beschreibung ersichtlich. Der Umfang der Erfindung sollte nicht unter Bezugnahme auf die vorstehende Beschreibung festgelegt werden, sondern stattdessen unter Bezugnahme auf die beigefügten Ansprüche in Zusammenhang mit dem vollständigen Umfang von Äquivalenten, zu denen solche Ansprüche berechtigen. Es wird erwartet und ist beabsichtigt, dass es hinsichtlich der hier erörterten Fachgebiete künftige Entwicklungen geben wird und dass die offenbarten Systeme und Verfahren in derartige künftige Ausführungsformen aufgenommen werden. Insgesamt versteht es sich, dass die Erfindung modifiziert und variiert werden kann und ausschließlich durch die folgenden Patentansprüche eingeschränkt ist.
  • Alle in den Patentansprüchen verwendeten Ausdrücke sollen ihre klare und gewöhnliche Bedeutung aufweisen, wie sie von einem Fachmann verstanden wird, sofern hierin nicht ausdrücklich das Gegenteil angegeben wird. Insbesondere ist die Verwendung der Singularartikel, wie etwa „ein“, „eine“, „der“, „die“, „das“ usw., dahingehend auszulegen, dass ein oder mehrere der aufgeführten Elemente genannt werden, sofern ein Anspruch nicht eine ausdrückliche gegenteilige Einschränkung enthält.
  • Gemäß der vorliegenden Erfindung beinhaltet ein Verfahren Speichern eines erfassten Ereigniscodes in einer ersten Blockchain, wobei jede elektronische Steuereinheit (ECU) in einer Vielzahl von ECU in einem Fahrzeug einen ersten Blockchain-Knoten der ersten Blockchain beinhaltet; Bestimmen einer Validität jedes ersten Blockchain-Knotens der ersten Blockchain durch Bestimmen, dass der Ereigniscode eines von (a) in dem jeweiligen ersten Blockchain-Knoten der ersten Blockchain gespeichert und valide oder (b) nicht in dem jeweiligen ersten Blockchain-Knoten der ersten Blockchain gespeichert und nicht valide ist; und Bereitstellen des Ereigniscodes und der Validität jedes ersten Blockchain-Knotens der ersten Blockchain an eine zweite Blockchain, die in mindestens einem zweiten Blockchain-Knoten verwaltet wird, über ein Netzwerk außerhalb des Fahrzeugs.
  • In einem Aspekt der Erfindung beinhaltet das Verfahren, dass das Bestimmen der Validität jedes ersten Blockchain-Knotens der ersten Blockchain durchgeführt wird, wenn bestimmt wird, dass der erfasste Ereigniscode einen Schaden an dem Fahrzeug identifiziert.
  • In einem Aspekt der Erfindung beinhaltet das Verfahren Identifizieren einer nicht autorisierten ECU in der Vielzahl von ECU auf Grundlage dessen, dass der jeweilige erste Blockchain-Knoten nicht valide ist.
  • In einem Aspekt der Erfindung beinhaltet das Verfahren Bereitstellen von Daten, die die nicht autorisierte ECU identifizieren, an die zweite Blockchain.
  • In einem Aspekt der Erfindung beinhaltet das Verfahren nach dem Empfangen eines Aktualisierungscodes von mindestens einem zweiten Blockchain-Knoten über das Netzwerk Speichern des Aktualisierungscodes in der ersten Blockchain, wobei der Aktualisierungscode eine Anzahl von autorisierten ECU-Modifikationen spezifiziert.
  • In einem Aspekt der Erfindung beinhaltet das Verfahren Authentifizieren des zweiten Blockchain-Knotens auf Grundlage einer Kennung, die mit einer autorisierten Kennung übereinstimmt.
  • In einem Aspekt der Erfindung beinhaltet das Verfahren Validieren des Aktualisierungscodes durch mindestens eine ECU, die den Aktualisierungscode mit einem digitalen Schlüssel entschlüsselt.
  • In einem Aspekt der Erfindung ist jeder Ereigniscode in der ersten Blockchain einer und nur einer der ECU zugeordnet.
  • In einem Aspekt der Erfindung beinhaltet das Verfahren Bestimmen des erfassten Ereigniscodes auf Grundlage von Sensordaten des Fahrzeugs.
  • In einem Aspekt der Erfindung beinhaltet das Verfahren nach dem Erfassen des Ereigniscodes Validieren des Ereigniscodes durch mindestens eine ECU, die den Ereigniscode mit einem digitalen Schlüssel entschlüsselt.
  • Gemäß der vorliegenden Erfindung wird ein System bereitgestellt, das Folgendes aufweist:
    • eine Vielzahl von elektronischen Steuereinheiten (ECU) in einem Fahrzeug, wobei jede ECU einen Prozessor und einen Speicher aufweist, wobei der Speicher jeder ECU Anweisungen speichert, die durch den Prozessor jeder ECU ausführbar sind, sodass jeder Prozessor zu Folgendem programmiert ist: Speichern eines erfassten Ereigniscodes in einer ersten Blockchain, wobei jede der ECU in der Vielzahl von ECU einen ersten Blockchain-Knoten der ersten Blockchain beinhaltet; Bestimmen einer Validität jedes ersten Blockchain-Knotens der ersten Blockchain durch Bestimmen, dass der Ereigniscode eines von (a) in dem jeweiligen ersten Blockchain-Knoten der ersten Blockchain gespeichert und valide oder (b) nicht in dem jeweiligen ersten Blockchain-Knoten der ersten Blockchain gespeichert und nicht valide ist: und Bereitstellen des Ereigniscodes und der Validität jedes ersten Blockchain-Knotens der ersten Blockchain an eine zweite Blockchain, die in mindestens einem zweiten Blockchain-Knoten verwaltet wird, über ein Netzwerk außerhalb des Fahrzeugs.
  • Gemäß einer Ausführungsform wird das Bestimmen der Validität jedes ersten Blockchain-Knotens der ersten Blockchain durchgeführt, wenn bestimmt wird, dass der erfasste Ereigniscode einen Schaden an dem Fahrzeug identifiziert.
  • Gemäß einer Ausführungsform beinhalten die Anweisungen ferner Anweisungen zum Identifizieren einer nicht autorisierten ECU in der Vielzahl von ECU auf Grundlage dessen, dass der jeweilige erste Blockchain-Knoten nicht valide ist.
  • Gemäß einer Ausführungsform beinhalten die Anweisungen ferner Anweisungen zum Bereitstellen von Daten, die die nicht autorisierte ECU identifizieren, an die zweite Blockchain.
  • Gemäß einer Ausführungsform beinhalten die Anweisungen ferner Anweisungen, um nach dem Empfangen eines Aktualisierungscodes von mindestens einem zweiten Blockchain-Knoten über das Netzwerk den Aktualisierungscode in der ersten Blockchain zu speichern, wobei der Aktualisierungscode eine Anzahl von autorisierten ECU-Modifikationen spezifiziert.
  • Gemäß einer Ausführungsform beinhalten die Anweisungen ferner Anweisungen zum Authentifizieren des zweiten Blockchain-Knotens auf Grundlage einer Kennung, die mit einer autorisierten Kennung übereinstimmt.
  • Gemäß einer Ausführungsform beinhalten die Anweisungen ferner Anweisungen zum Validieren des Aktualisierungscodes durch mindestens eine ECU, die den Aktualisierungscode mit einem digitalen Schlüssel entschlüsselt.
  • Gemäß einer Ausführungsform ist jeder Ereigniscode in der ersten Blockchain einer und nur einer der ECU zugeordnet.
  • Gemäß einer Ausführungsform beinhalten die Anweisungen ferner Anweisungen zum Bestimmen des erfassten Ereigniscodes auf Grundlage von Sensordaten des Fahrzeugs.
  • Gemäß einer Ausführungsform beinhalten die Anweisungen ferner Anweisungen, um nach dem Erfassen des Ereigniscodes den Ereigniscode durch mindestens eine ECU, die den Ereigniscode mit einem digitalen Schlüssel entschlüsselt, zu validieren.

Claims (13)

  1. Verfahren, das Folgendes umfasst: Speichern eines erfassten Ereigniscodes in einer ersten Blockchain, wobei jede elektronische Steuereinheit (ECU) in einer Vielzahl von ECU in einem Fahrzeug einen ersten Blockchain-Knoten der ersten Blockchain beinhaltet; Bestimmen einer Validität jedes ersten Blockchain-Knotens der ersten Blockchain durch Bestimmen, dass der Ereigniscode eines von (a) in dem jeweiligen ersten Blockchain-Knoten der ersten Blockchain gespeichert und valide oder (b) nicht in dem jeweiligen ersten Blockchain-Knoten der ersten Blockchain gespeichert und nicht valide ist; und Bereitstellen des Ereigniscodes und der Validität jedes ersten Blockchain-Knotens der ersten Blockchain an eine zweite Blockchain, die in mindestens einem zweiten Blockchain-Knoten verwaltet wird, über ein Netzwerk außerhalb des Fahrzeugs.
  2. Verfahren nach Anspruch 1, wobei das Bestimmen der Validität jedes ersten Blockchain-Knotens der ersten Blockchain durchgeführt wird, wenn bestimmt wird, dass der erfasste Ereigniscode einen Schaden an dem Fahrzeug identifiziert.
  3. Verfahren nach Anspruch 1, ferner umfassend Identifizieren einer nicht autorisierten ECU in der Vielzahl von ECU auf Grundlage dessen, dass der jeweilige erste Blockchain-Knoten nicht valide ist.
  4. Verfahren nach Anspruch 3, ferner umfassend Bereitstellen von Daten, die die nicht autorisierte ECU identifizieren, an die zweite Blockchain.
  5. Verfahren nach Anspruch 1, ferner umfassend, nach dem Empfangen eines Aktualisierungscodes von mindestens einem zweiten Blockchain-Knoten über das Netzwerk, Speichern des Aktualisierungscodes in der ersten Blockchain, wobei der Aktualisierungscode eine Anzahl von autorisierten ECU-Modifikationen spezifiziert.
  6. Verfahren nach Anspruch 5, ferner umfassend Authentifizieren des zweiten Blockchain-Knotens auf Grundlage einer Kennung, die mit einer autorisierten Kennung übereinstimmt.
  7. Verfahren nach Anspruch 5, ferner umfassend Validieren des Aktualisierungscodes durch mindestens eine ECU, die den Aktualisierungscode mit einem kryptografischen Schlüssel entschlüsselt.
  8. Verfahren nach Anspruch 1, wobei jeder Ereigniscode in der ersten Blockchain einer und nur einer der ECU zugeordnet ist.
  9. Verfahren nach Anspruch 1, ferner umfassend Bestimmen des erfassten Ereigniscodes auf Grundlage von Fahrzeugsensordaten.
  10. Verfahren nach Anspruch 1, ferner umfassend, nach dem Erfassen des Ereigniscodes, Validieren des Ereigniscodes durch mindestens eine ECU, die den Ereigniscode mit einem kryptografischen Schlüssel entschlüsselt.
  11. Computer, der dazu programmiert ist, das Verfahren nach einem der Ansprüche 1-10 auszuführen.
  12. Computerprogrammprodukt, das Anweisungen umfasst, um das Verfahren nach einem der Ansprüche 1-10 auszuführen.
  13. Fahrzeug, das einen Computer umfasst, der dazu programmiert ist, das Verfahren nach einem der Ansprüche 1-10 auszuführen.
DE102020124163.1A 2019-09-17 2020-09-16 Verifizierung von fahrzeugdaten Pending DE102020124163A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/573,959 US11618395B2 (en) 2019-09-17 2019-09-17 Vehicle data verification
US16/573,959 2019-09-17

Publications (1)

Publication Number Publication Date
DE102020124163A1 true DE102020124163A1 (de) 2021-03-18

Family

ID=74686373

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020124163.1A Pending DE102020124163A1 (de) 2019-09-17 2020-09-16 Verifizierung von fahrzeugdaten

Country Status (3)

Country Link
US (1) US11618395B2 (de)
CN (1) CN112532574A (de)
DE (1) DE102020124163A1 (de)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11456891B2 (en) 2018-12-20 2022-09-27 Rolls-Royce North American Technologies Inc. Apparatus and methods for authenticating cyber secure control system configurations using distributed ledgers
US20200262366A1 (en) 2019-02-14 2020-08-20 Oshkosh Corporation Integrated operator centric controls
US11086769B2 (en) * 2019-03-25 2021-08-10 Aurora Labs Ltd. Proving whether software functionality has changed following a software change
US11217041B2 (en) * 2019-07-29 2022-01-04 Toyota Motor North America, Inc. Tracking of transport data
US11500571B2 (en) 2019-07-29 2022-11-15 Toyota Motor North America, Inc. Tracking of transport data
TWI716135B (zh) * 2019-10-04 2021-01-11 財團法人資訊工業策進會 用於車用網路之安全監控裝置及方法
US11919423B2 (en) * 2020-06-19 2024-03-05 Toyota Motor North America, Inc. Weight and pressure related validation
US20220024423A1 (en) * 2020-07-22 2022-01-27 Toyota Motor North America, Inc. Authorizing functionality of a transport component
US11882222B2 (en) * 2020-07-23 2024-01-23 The Toronto-Dominion Bank Multidirectional synchronization of confidential data using distributed ledgers
US11843667B2 (en) * 2020-08-17 2023-12-12 Toyota Motor North America, Inc. Real time boot for secure distributed systems
CN115730340A (zh) * 2021-08-25 2023-03-03 华为技术有限公司 一种数据处理方法及相关装置
CN113777991B (zh) * 2021-09-15 2023-06-20 杭叉集团股份有限公司 一种工业车辆智能网联控制器及其远程监控***
US12019574B2 (en) * 2022-01-12 2024-06-25 Toyota Motor North America, Inc. Transport component authentication
EP4224778A1 (de) * 2022-02-03 2023-08-09 Siemens Rail Automation S.A.U. Verfahren zum sichern einer maschine gegen diebstahl und gesicherte maschine davon
US11928205B1 (en) * 2022-03-01 2024-03-12 CSP Inc. Systems and methods for implementing cybersecurity using blockchain validation
CN114466050B (zh) * 2022-04-11 2022-11-08 国汽智控(北京)科技有限公司 基于区块链的车载数据处理方法、装置及电子设备

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4600510B2 (ja) * 2008-04-23 2010-12-15 株式会社デンソー 制御装置およびプログラム
JP5310761B2 (ja) * 2011-03-04 2013-10-09 トヨタ自動車株式会社 車両ネットワークシステム
US10284654B2 (en) 2016-09-27 2019-05-07 Intel Corporation Trusted vehicle telematics using blockchain data analytics
US10062277B2 (en) * 2017-01-24 2018-08-28 International Business Machines Corporation Information sharing among mobile apparatus
GB2562054A (en) 2017-05-02 2018-11-07 Bitbond Ltd Automotive electronic blockchain information system - AEBIS
US10956555B2 (en) * 2017-08-01 2021-03-23 Panasonic Intellectual Property Corporation Of America Management system, vehicle, and information processing method
JP7069975B2 (ja) * 2018-03-30 2022-05-18 トヨタ自動車株式会社 制御装置、制御装置用のプログラム、及び制御方法
CN108734592A (zh) 2018-05-11 2018-11-02 深圳市图灵奇点智能科技有限公司 车辆保险业务数据分析方法和***
US11204751B2 (en) * 2018-09-07 2021-12-21 International Business Machines Corporation Mitigating incompatibilities due to code updates in a system containing multiple networked electronic control units
US20200226853A1 (en) * 2019-01-11 2020-07-16 Toyota Motor North America, Inc. Automated accident logging and reporting
US11399268B2 (en) * 2019-03-15 2022-07-26 Toyota Motor North America, Inc. Telematics offloading using V2V and blockchain as trust mechanism
US11240211B2 (en) * 2019-09-12 2022-02-01 Richard Benson System and method to leverage EDR, ECU, CAN and OBD data from vehicles by means of blockchain technology

Also Published As

Publication number Publication date
US20210078512A1 (en) 2021-03-18
US11618395B2 (en) 2023-04-04
CN112532574A (zh) 2021-03-19

Similar Documents

Publication Publication Date Title
DE102020124163A1 (de) Verifizierung von fahrzeugdaten
DE102017125826A1 (de) Nachrichtenauthentifizierung über controller area network
DE102020116438A1 (de) Nutzung von fahrzeugkomponenten
EP2689553B1 (de) Kraftwagen-steuergerät mit kryptographischer einrichtung
DE112017005979T5 (de) Parallelprozessvorrichtung und Parallelprozessprogramm
DE10131395A1 (de) Verfahren zum Übertragen von Software- Modulen
DE102020122489A1 (de) Zugriffsautorisierung für verteiltes fahrzeugnetzwerk
DE102019004726A1 (de) Verfahren, Vorrichtung, System, elektronisches Schloss, digitaler Schlüssel und Speichermedium für die Autorisierung
EP3230131B1 (de) Verfahren zur steuerung des betriebs wenigstens einer funktionskomponente eines kraftfahrzeugs und kraftfahrzeug
DE102020208245A1 (de) Datenspeicherungsvorrichtung und Datenspeicherungsprogramm
DE102019212958B3 (de) Verfahren und Vorrichtung zur Erzeugung von kryptographischen Schlüsseln nach einem Schlüsselableitungsmodell sowie Fahrzeug
DE112020001126T5 (de) Fahrzeugsteuergerät
DE102018222864B3 (de) Verfahren zum Deaktivieren eines Kraftfahrzeugs, Deaktivierungssystem für ein Kraftfahrzeug und Kraftfahrzeug
DE102020114379A1 (de) Speichern von fahrzeugdaten
DE102020126906A1 (de) Validieren von fahrzeugen, die innerhalb bestimmter regionen fahren
DE102020208536A1 (de) Gateway-vorrichtung, abnormitätsüberwachungsverfahren und speichermedium
DE102016219014A1 (de) Verfahren zum gesicherten Zugriff auf Daten eines Fahrzeugs
DE102023107659A1 (de) Unleugbarer verlauf von fahrzeugänderungen
DE102022103553A1 (de) Authentifizierung einer fahrzeugrechenvorrichtung
DE102020124046A1 (de) Dezentral autorisierte fahrzeugvorgänge
DE102019105390A1 (de) Ersetzen von sicherheitsanmeldeinformationen für das fahrzeugsteuermodul
DE112016006524T5 (de) Authentifizierung einer Fahrzeugcomputeraktualisierung
DE102020126909A1 (de) Sitzungsspezifischer zugriffstoken
DE102022105476A1 (de) System und Verfahren zum Aufbauen eines fahrzeugintegrierten Kryptografiemanagers
DE102021129043A1 (de) Diagnoseanforderung über fahrzeugbus-authentifizierung

Legal Events

Date Code Title Description
R082 Change of representative

Representative=s name: LORENZ SEIDLER GOSSEL RECHTSANWAELTE PATENTANW, DE