DE102019113185A1 - Einbettung von blockchain-informationen in digitale bilder - Google Patents

Einbettung von blockchain-informationen in digitale bilder Download PDF

Info

Publication number
DE102019113185A1
DE102019113185A1 DE102019113185.5A DE102019113185A DE102019113185A1 DE 102019113185 A1 DE102019113185 A1 DE 102019113185A1 DE 102019113185 A DE102019113185 A DE 102019113185A DE 102019113185 A1 DE102019113185 A1 DE 102019113185A1
Authority
DE
Germany
Prior art keywords
vehicle
blockchain
hash
data
domain server
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
DE102019113185.5A
Other languages
English (en)
Inventor
Christopher L. Zachary
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.)
GM Global Technology Operations LLC
General Motors LLC
Original Assignee
GM Global Technology Operations LLC
General Motors 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 GM Global Technology Operations LLC, General Motors LLC filed Critical GM Global Technology Operations LLC
Publication of DE102019113185A1 publication Critical patent/DE102019113185A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/0021—Image watermarking
    • G06T1/0085—Time domain based watermarking, e.g. watermarks spread over several images
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N1/00—Scanning, transmission or reproduction of documents or the like, e.g. facsimile transmission; Details thereof
    • H04N1/32—Circuits or arrangements for control or supervision between transmitter and receiver or between image input and image output device, e.g. between a still-image camera and its memory or between a still-image camera and a printer device
    • H04N1/32101—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title
    • H04N1/32144—Display, printing, storage or transmission of additional information, e.g. ID code, date and time or title embedded in the image data, i.e. enclosed or integrated in the image, e.g. watermark, super-imposed logo or stamp
    • H04N1/32149—Methods relating to embedding, encoding, decoding, detection or retrieval operations
    • H04N1/32267—Methods relating to embedding, encoding, decoding, detection or retrieval operations combined with processing of the image
    • H04N1/32283—Hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T1/00—General purpose image data processing
    • G06T1/0021—Image watermarking
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G07C5/085—Registering performance data using electronic data carriers
    • G07C5/0866—Registering performance data using electronic data carriers the electronic data carrier being a digital video recorder in combination with video camera
    • 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
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/18—Closed-circuit television [CCTV] systems, i.e. systems in which the video signal is not broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/18—Closed-circuit television [CCTV] systems, i.e. systems in which the video signal is not broadcast
    • H04N7/188—Capturing isolated or intermittent images triggered by the occurrence of a predetermined event, e.g. an object reaching a predetermined position
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • 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]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • 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/60—Digital content management, e.g. content distribution
    • H04L2209/608—Watermarking
    • 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
    • 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]
    • H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • Medical Informatics (AREA)
  • Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Bioethics (AREA)
  • Software Systems (AREA)
  • Traffic Control Systems (AREA)

Abstract

Es ist ein System und Verfahren zum Herstellen von Sichtdaten vorgesehen, die mit einem auf einer Blockchain gespeicherten Blockchain-Hash eingebettet sind, wobei das Verfahren Folgendes beinhaltet: Erkennen eines Fahrzeugereignisses an einem Fahrzeug unter Verwendung einer im Fahrzeug eingeschlossenen Fahrzeugelektronik; Senden einer Fahrzeugereignismeldung an einen Blockchain-Domänenserver als Reaktion auf das erfasste Fahrzeugereignis, wobei die Fahrzeug-Ereignismeldung Informationen über das erkannte Fahrzeugereignis beinhaltet, und worin der Blockchain-Domänenserver konfiguriert ist, um das erfasste Fahrzeugereignis als Teil einer Blockchain basierend auf der Fahrzeug-Ereignismeldung aufzuzeichnen; Empfangen eines Blockchain-Hash am Fahrzeug von dem Blockchain-Domänenserver; und Einbetten des Blockchain-Hash in Sichtdaten am Fahrzeug unter Verwendung der Fahrzeugelektronik, worin die Sichtdaten von einem Sichtsensor erfasst werden, der am Fahrzeug angebracht und als Teil der Fahrzeugelektronik aufgenommen ist.

Description

  • EINLEITUNG
  • Die vorliegende Erfindung betrifft die von einem Fahrzeug erfassten Sichtdaten mit Wasserzeichen.
  • Fahrzeuge beinhalten Hard- und Software, die in der Lage sind, verschiedene Informationen zu erhalten und zu verarbeiten, einschließlich Bilderfassungsfunktionen. Das Fahrzeug kann Bilddaten für den autonomen Fahrzeugbetrieb sowie für andere Vorgänge erfassen. Diese Informationen können in verschiedenen Datenbanken gespeichert werden, die Teil des Fahrzeugkommunikationssystems sind.
  • KURZDARSTELLUNG
  • Gemäß einem Aspekt der Erfindung ist ein Verfahren zum Herstellen von Sichtdaten vorgesehen, die mit einem auf einer Blockchain gespeicherten Blockchain-Hash eingebettet sind, wobei das Verfahren Folgendes beinhaltet: Erfassen eines Fahrzeugereignisses an einem Fahrzeug unter Verwendung einer im Fahrzeug eingeschlossenen Fahrzeugelektronik; Senden einer Fahrzeug-Ereignismeldung an einen Blockchain-Domänenserver als Reaktion auf das erfasste Fahrzeugereignis, wobei die Fahrzeug-Ereignismeldung Informationen über das erfasste Fahrzeugereignis beinhaltet, und worin der Blockchain-Domänenserver konfiguriert ist, um das erfasste Fahrzeugereignis als Teil einer Blockchain basierend auf der Fahrzeug-Ereignismeldung aufzuzeichnen; Empfangen eines Blockchain-Hash am Fahrzeug von dem Blockchain-Domänenserver; und Einbetten des Blockchain-Hash in Sichtdaten am Fahrzeug unter Verwendung der Fahrzeugelektronik, worin die Sichtdaten von einem Sichtsensor erfasst werden, der am Fahrzeug angebracht und als Teil der Fahrzeugelektronik aufgenommen ist.
    • • Gemäß verschiedenen Ausführungsformen kann dieses Verfahren eines oder mehrere der folgenden Merkmale in jeder technisch möglichen Kombination dieser Merkmale beinhalten:
      • • der Blockchain-Hash ein ereignisspezifischer Hash ist, der am Blockchain-Domänenserver als Teil der Aufzeichnung des erfassten Fahrzeugereignisses am Blockchain-Domänenserver erzeugt wird, und worin der Blockchain-Hash als Reaktion auf die Aufzeichnung des erfassten Fahrzeugereignisses am Blockchain-Domänenserver empfangen wird;
      • • das Senden der Sichtdaten mit dem eingebetteten Blockchain-Hash an eine entfernte Einrichtung, die vom Blockchain-Domänenserver getrennt ist;
      • • die Fahrzeug-Ereignismeldung beinhaltet einen Fahrzeugstandort, einen Zeitstempel und mindestens ein weiteres Fahrzeugzustandsdatum, und worin der Fahrzeugstandort, der Zeitstempel und das mindestens eine weitere Fahrzeugzustandsdatum einer Zeit des erfassten Fahrzeugereignisses entsprechen;
      • • Registrieren des Fahrzeugs bei einem Blockchain-Domänenserver als Reaktion auf das Fahrzeug, das sich einer dem Blockchain-Domänenserver zugeordneten geografischen Domäne nähert oder diese betritt;
      • • die Sichtdaten sind Bilddaten, und worin der Blockchain-Hash als Wasserzeichen auf die Bilddaten aufgebracht wird;
      • • der Blockchain-Hash ist in die Bilddaten unter Verwendung einer reversiblen Steganographietechnik eingebettet, sodass alle oder im Wesentlichen alle Daten, die in den Bilddaten vor dem Wasserzeichen dargestellt werden, erhalten bleiben, nachdem die Bilddaten mit dem Blockchain-Hash mit einem Wasserzeichen versehen worden sind,
      • • die Bilddaten werden durch einen Bildsensor erfasst, der als Teil der Fahrzeugelektronik aufgenommen ist, und worin der Bildsensor den Blockchain-Hash auf die Bilddaten anwendet, während er die Bilddaten unter Verwendung eines Codecs codiert;
      • • der Blockchain-Hash ist ein Hash, der durch Ausführen einer Hash-Funktion unter Verwendung von Informationen erzeugt wird, die in einem Block der Blockchain als Eingabe enthalten sind; und/oder
      • • der Blockchain-Domänenserver ist so konfiguriert, dass er den Block der Blockchain unter Verwendung von Ereignisdaten, die in der Fahrzeug-Ereignismeldung empfangen werden, erzeugt.
  • Gemäß einem weiteren Aspekt der Erfindung ist ein Verfahren zum Erzeugen von Visionsdaten vorgesehen, die mit einem auf einer Blockchain gespeicherten Blockchain-Hash eingebettet sind, wobei das Verfahren Folgendes beinhaltet: Registrieren eines Fahrzeugs bei einem Blockchain-Domänenserver als Reaktion auf das Annähern des Fahrzeugs an oder Eintreten in eine dem Blockchain-Domänenserver zugeordnete geografische Domäne; Empfangen eines Blockchain-Hash am Fahrzeug vom Blockchain-Domänenserver, worin der Blockchain-Domänenserver konfiguriert ist, um vom Fahrzeug empfangene Informationen in einer Blockchain aufzuzeichnen, und worin der Blockchain-Hash durch Ausführen einer Hash-Funktion unter Verwendung von Informationen, die in einem der Blockchain als Eingabe hinzugefügt werden soll, erzeugt wird; und Einbetten des Blockchain-Hash in Visionsdaten, die am Fahrzeug unter Verwendung der Fahrzeugelektronik erfasst werden, wobei die Visionsdaten von einem Visionssensor erfasst werden, der am Fahrzeug angebracht und als Teil der Fahrzeugelektronik beinhaltet ist.
    • • Gemäß verschiedenen Ausführungsformen kann dieses Verfahren eines oder mehrere der folgenden Merkmale in jeder technisch möglichen Kombination dieser Merkmale beinhalten:
      • • der Blockchain-Hash ist ein Registrierungs-Hash, welcher der Registrierung des Fahrzeugs zugeordnet ist und der zum Zeitpunkt der Registrierung des Fahrzeugs erzeugt wird;
      • • der Blockchain-Domänenserver ist konfiguriert, um vom Fahrzeug empfangene Fahrzeugregistrierungsinformationen in der Blockchain aufzuzeichnen, und worin die Fahrzeugregistrierungsinformationen vom Fahrzeug als Teil des Registrierungsschritts gesendet werden;
      • • der Registrierungsschritt beinhaltet das Herstellen einer drahtlosen Kommunikationsverbindung zwischen dem Fahrzeug und dem Blockchain-Domänenserver;
      • • die drahtlose Kommunikationsverbindung wird unter Verwendung von Mobilfunkkommunikation hergestellt; und/oder
      • • Erfassen eines Fahrzeugereignisses am Fahrzeug unter Verwendung einer im Fahrzeug enthaltenen Fahrzeugelektronik, worin die Visionsdaten Bilddaten sind und der Visionssensor ein Bildsensor ist, und worin der Einbettungsschritt das Wasserzeichen jedes einer Anzahl von Einzelbildern der Bilddaten mit dem Blockchain-Hash und das Speichern der Einzelbilder als Videoclip als Reaktion auf das Erfassen des Fahrzeugereignisses umfasst.
  • Gemäß einem weiteren Aspekt der Erfindung ist ein Fahrzeugelektroniksystem vorgesehen, das Folgendes beinhaltet: eine drahtlose Kommunikationsvorrichtung, die eine drahtlose Kommunikationsschaltung, einen Prozessor und einen Speicher beinhaltet; und einen Visionssensor, der einen Prozessor und einen Speicher beinhaltet; worin das Fahrzeugelektroniksystem Computeranweisungen beinhaltet, die, wenn sie durch einen oder mehrere Prozessoren ausgeführt werden, das Fahrzeugelektroniksystem veranlassen zum: (i) Erfassen eines Fahrzeugereignisses an einem Fahrzeug, welches das Fahrzeugelektroniksystem beinhaltet; (ii) Senden einer Fahrzeug-Ereignismeldung an einen Blockchain-Domänenserver unter Verwendung der drahtlosen Kommunikationsschaltung, wobei die Fahrzeug-Ereignismeldung Informationen bezüglich des erfassten Fahrzeugereignisses beinhaltet, und worin der Blockchain-Domänenserver konfiguriert ist, das erfasste Fahrzeugereignis basierend auf der Fahrzeug-Ereignismeldung als Teil einer Blockchain aufzuzeichnen; (iii) Empfangen eines Blockchain-Hash am Fahrzeug vom Blockchain-Domänenserver unter Verwendung der drahtlosen Kommunikationsschaltung; und (iv) einbetten des Blockchain-Hash in die Visionsdaten am Fahrzeug unter Verwendung des Sichtsensors.
  • Gemäß verschiedenen Ausführungsformen kann dieses Fahrzeugelektroniksystem eines oder mehrere der folgenden Merkmale in jeder technisch möglichen Kombination dieser Merkmale beinhalten:
    • • mindestens einige der Computeranweisungen werden durch ein Fahrzeugsystemmodul (VSM) des Fahrzeugs ausgeführt, das nicht der Visionssensor und die drahtlose Kommunikationsvorrichtung ist;
    • • der Visionssensor ist eine Kamera, die konfiguriert ist, um Bilddaten zu erfassen, und/oder
    • • ein globales Navigationssatellitensystem (GNSS), das konfiguriert ist, um einen Fahrzeugstandort des Fahrzeugs zu bestimmen, basierend auf dem Empfangen einer Vielzahl von GNSS-Signalen von einer Vielzahl von GNSS-Satelliten, worin der Fahrzeugstandort als Teil der Fahrzeug-Ereignismeldung einbezogen ist.
  • Figurenliste
  • Eine oder mehrere Ausführungsformen der Erfindung werden im Folgenden in Verbindung mit den beigefügten Zeichnungen beschrieben, wobei gleiche Bezeichnungen gleiche Elemente bezeichnen, und wobei Folgendes gilt:
    • 1 ist ein Blockdiagramm, das eine Ausführungsform eines Kommunikationssystems darstellt, das in der Lage ist, das hierin offenbarte Verfahren zu verwenden;
    • 2 ist ein Blockdiagramm, das eine Vielzahl von geografischen Bereichen darstellt, die in Verbindung mit dem exemplarischen Kommunikationssystem von 1 verwendet werden können;
    • 3 ist ein Flussdiagramm einer Ausführungsform eines Verfahrens zum Erzeugen von Visionsdaten, das mit einem in einer Blockchain gespeicherten Blockchain-Hash eingebettet ist; und
    • 4 ist ein Flussdiagramm einer weiteren Ausführungsform eines Verfahrens zum Erzeugen von Visionsdaten, das mit einem auf einer Blockchain gespeicherten Blockchain-Hash eingebettet ist.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Das im Folgenden beschriebene System und Verfahren ermöglicht die Validierung von mit einem Fahrzeug oder einem Fahrzeugereignis verbundenen Visionsdaten durch die Verwendung der Blockchain-Technologie. Visionsdaten, die Bilddaten (z. B. Bilder, Videos) sein können, können an einem Fahrzeug mit einem Visionssensor, wie beispielsweise einer Kamera oder einem Lidar, erfasst werden. Die Visionsdaten können dann mit einem Wasserzeichen mit einem Blockchain-Hash versehen werden, das registriert oder anderweitig in einer Blockchain gespeichert ist. Die Blockchain ermöglicht es, den Blockchain-Hash sicher mit Fahrzeuginformationen zu verknüpfen, die in die Blockchain aufgenommen und zum Erzeugen des Blockchain-Hash verwendet werden können. Auf diese Weise können die mit Wasserzeichen versehenen Visionsdaten (d. h. die Visionsdaten, die mit dem Blockchain-Hash kodiert oder anderweitig eingebettet sind) mit bestimmten in der Blockchain gespeicherten Fahrzeuginformationen verknüpft werden. In einer Ausführungsform entsprechen die Fahrzeuginformationen dem Fahrzeug, das sich bei einer bestimmten geografischen Domäne registriert; jede geografische Domäne kann eine andere Blockchain beinhalten oder mit ihr verbunden sein. In einer weiteren Ausführungsform entsprechen die Fahrzeuginformationen Informationen, die sich auf ein erkanntes Fahrzeugereignis beziehen. Nachdem das Fahrzeugereignis erkannt wurde, kann ein Blockchain-Domänenserver (der einer bestimmten geografischen Domäne zugeordnet sein kann) den Blockchain-Hash erzeugen, der spezifisch für das erkannte Fahrzeugereignis sein kann. Die Verwendung der Blockchain kann zum Überprüfen verwendet werden, ob die in der Blockchain gespeicherten Fahrzeuginformationen den mit Wasserzeichen versehenen Visionsdaten über die Zuordnung des Blockchain-Hash zugeordnet sind.
  • Unter Bezugnahme auf 1, wird eine Betriebsumgebung dargestellt, die ein Kommunikationssystem 10 umfasst und die zum Implementieren des hierin offenbarten Verfahrens verwendet werden kann. Das Kommunikationssystem 10 beinhaltet im Allgemeinen ein Fahrzeug 12, das die Fahrzeugelektronik 20, einen Blockchain-Domänenserver 14, eine Konstellation von GNSS-Satelliten 60, ein oder mehrere Drahtlosträgersysteme 70, ein Festnetz-Kommunikationsnetzwerk 76, einen Computer oder Server 78 und eine Fahrzeug-Backend-Diensteeinrichtung 80 beinhaltet. Es versteht sich, dass das offenbarte Verfahren mit einer beliebigen Anzahl an unterschiedlichen Systemen verwendet werden kann und nicht speziell auf die hier gezeigte Betriebsumgebung eingeschränkt ist. Somit stellen die folgenden Absätze lediglich einen kurzen Überblick über ein solches Kommunikationssystem 10 bereit; aber auch andere, hier nicht dargestellte Systeme könnten die offenbarten Verfahren einsetzen.
  • Das Fahrzeug 12 ist in der veranschaulichten Ausführungsform als ein Personenkraftwagen dargestellt, es sollte jedoch beachtet werden, dass jedes andere Fahrzeug, einschließlich Motorräder, Lastwagen, Geländewagen (SUV), Campingfahrzeuge (RV), Wasserfahrzeuge, Flugzeuge, einschließlich unbemannter Luftfahrzeuge (UAVs) usw. ebenfalls verwendet werden kann. Einige Fahrzeugelektroniken 20 werden im Allgemeinen in 1 dargestellt und beinhalten einen globalen Navigationssatellitensytem-(GNSS)-Empfänger 22, ein Karosseriesteuermodul oder -einheit (BCM) 24, ein Motorsteuergerät (ECM) 26, andere Fahrzeugsystemmodule (VSMs) 28, eine drahtlose Kommunikationsvorrichtung 30 und Fahrzeug-Benutzeroberflächen 50-56. Ein Teil oder die gesamte Fahrzeugelektronik kann zur Kommunikation miteinander über eine oder mehrere Kommunikationsbusse, wie beispielsweise den Kommunikationsbus 40, verbunden werden. Der Kommunikationsbus 40 stellt den Fahrzeugelektroniken unter Verwendung einer oder mehrerer Netzwerkprotokolle Netzwerkverbindungen bereit und kann eine serielle Datenkommunikationsarchitektur verwenden. Beispiele geeigneter Netzwerkverbindungen beinhalten ein Controller Area Network (CAN), einen medienorientierten Systemtransfer (MOST), ein lokales Kopplungsstrukturnetzwerk (LIN), ein lokales Netzwerk (LAN) und andere geeignete Verbindungen, wie z. B. Ethernet oder andere, die u. a. den bekannten ISO-, SAE- und IEEE-Standards und -Spezifikationen entsprechen. In weiteren Ausführungsformen kann ein drahtloses Kommunikationsnetzwerk verwendet werden, das die drahtlose Nahbereichskommunikation (SRWC) zur Kommunikation mit einem oder mehreren VSMs des Fahrzeugs verwendet. In einer Ausführungsform kann das Fahrzeug 12 eine Kombination aus einem festverdrahteten Kommunikationsbus 40 und SRWCs verwenden. Die SRWCs können beispielsweise unter Verwendung der drahtlosen Kommunikationsvorrichtung 30 ausgeführt werden.
  • Das Fahrzeug 12 kann zahlreiche Fahrzeugsystemmodule (VSMs) als Teil der Fahrzeugelektroniken 20 beinhalten, wie beispielsweise den GNSS-Empfänger 22, das BCM 24, das ECM 26, die drahtlose Kommunikationsvorrichtung 30, sowie die Fahrzeugbenutzeroberflächen 50-56, wie im Folgenden näher beschrieben wird. Das Fahrzeug 12 kann auch andere VSMs 28 in Form von elektronischen Hardwarekomponenten beinhalten, die sich im gesamten Fahrzeug befinden und eine Eingabe von einem oder mehreren Sensoren empfangen und die erfassten Eingaben verwenden, um Diagnose-, Überwachungs-, Steuerungs-, Berichterstattungs- und/oder andere Funktionen auszuführen. Jedes der VSMs 28 wird vorzugsweise über den Kommunikationsbus 40 mit den anderen VSMs, einschließlich der drahtlosen Kommunikationsvorrichtung 30, verbunden. Darüber hinaus kann jedes der VSMs eine geeignete Hardware beinhalten und/oder kommunikativ gekoppelt werden, die es ermöglicht, die Kommunikation innerhalb des Fahrzeugs über den Kommunikationsbus 40 durchzuführen; diese Hardware kann beispielsweise Busschnittstellenstecker und/oder Modems beinhalten. Ein oder mehrere VSMs 28 können ihre Software oder Firmware periodisch oder gelegentlich aktualisieren lassen und, in einigen Ausführungsformen können derartige Fahrzeug-Updates Over-the-Air-(OTA)-Updates sein, die von einem Computer 78 oder einer entfernten Einrichtung 80 über das Festnetz 76 und Kommunikationsvorrichtungen 30 empfangen werden. Fachleute auf dem Fachgebiet werden erkennen, dass es sich bei den vorgenannten VSMs nur um Beispiele von einigen der Module handelt, die im Fahrzeug 12 verwendet werden können, zahlreiche andere Module jedoch ebenfalls möglich sind.
  • Der globale Navigationssatellitensystem-(GNSS)-Empfänger 22 empfängt Funksignale von einer Konstellation von GNSS-Satelliten 60. Der GNSS-Empfänger 22 kann zur Verwendung mit verschiedenen GNSS-Implementierungen konfiguriert werden, darunter das globale Positionierungssystem (GPS) für die Vereinigten Staaten, das BeiDou Navigationssatellitensystem (BDS) für China, das globale Navigationssatellitensystem (GLONASS) für Russland, Galileo für die Europäische Union sowie verschiedene andere Satellitennavigationssysteme. Der GNSS-Empfänger 22 kann beispielsweise ein GPS-Empfänger sein, der GPS-Signale von einer Konstellation von GPS-Satelliten 60 empfängt. Und in einem weiteren Beispiel kann der GNSS-Empfänger 22 ein BDS-Empfänger sein, der eine Vielzahl von GNSS-(oder BDS)-Signalen von einer Konstellation von GNSS-(oder BDS)-Satelliten 60 empfängt. Der GNSS-Empfang kann einen aktuellen Fahrzeugstandort basierend auf dem Empfangen einer Vielzahl von GNSS-Signalen aus der Konstellation der GNSS-Satelliten 60 bestimmen. Die Fahrzeugstandortinformationen können dann an die drahtlose Kommunikationsvorrichtung 30 oder ein anderes VSM übermittelt werden.
  • Das Karosseriesteuermodul (BCM) 24 kann verwendet werden, um verschiedene VSMs des Fahrzeugs zu steuern sowie Informationen zu den VSMs, einschließlich ihres gegenwärtigen Zustands oder Status sowie Sensorinformationen zu erhalten. Das BCM 24 wird in der exemplarischen Ausführungsform aus 1 als mit dem Kommunikationsbus 40 elektrisch verbunden, dargestellt. In einigen Ausführungsformen kann das BCM 24 mit oder als Teil eines Mittelstapelmoduls (CSM) integriert werden und/oder kann mit der drahtlosen Kommunikationsvorrichtung 30 integriert werden. Oder das BCM kann eine getrennte Vorrichtung sein, die über den Bus 40 mit anderen VSMs verbunden ist. Das BCM 24 kann einen Prozessor und/oder Speicher beinhalten, der dem Prozessor 36 und dem Speicher 38 der drahtlosen Kommunikationsvorrichtung 30 ähnlich sein kann, wie nachfolgend erläutert wird. Das BCM 24 kann mit der drahtlosen Vorrichtung 30 und/oder einem oder mehreren Fahrzeugsystemmodulen, wie dem Motorsteuermodul (ECM) 26, dem Audiosystem 56 oder anderen VSMs 28 kommunizieren; in einigen Ausführungsformen kann das BCM 24 mit diesen Modulen über den Kommunikationsbus 40 kommunizieren. Das BCM 24 kann einen Prozessor und einen Speicher beinhalten, auf den der Prozessor zugreifen kann. Die im Speicher gespeicherte und durch den Prozessor ausführbare Software ermöglicht es dem BCM, einen oder mehrere Fahrzeugfunktionen zu steuern, darunter beispielsweise auch das Steuern der Zentralverriegelung, der Klimaanlage, der elektrischen Spiegel, das Steuern des primären Antriebs des Fahrzeugs (z. B. Motor, primäres Antriebssystem) und/oder der Steuerung verschiedener anderer Fahrzeugmodule, steuern kann. In einer Ausführungsform kann das BCM 24 (zumindest teilweise) verwendet werden, um ein Fahrzeugereignis basierend auf einer oder mehreren fahrzeugseitigen Sensorwerten zu erfassen, wie im Folgenden näher erläutert wird.
  • Das Motorsteuergerät (ECM) 26 kann verschiedene Aspekte des Motorbetriebs, wie beispielsweise Kraftstoffzündung und Zündzeitpunkt, steuern. Das ECM 26 wird mit dem Kommunikationsbus 40 verbunden und kann Betriebsanweisungen (oder Fahrzeugbefehle) vom BCM 24 oder anderen Fahrzeugsystemmodulen, wie beispielsweise der drahtlosen Kommunikationsvorrichtung 30 oder den VSMs 28, empfangen. In einem Szenario kann das ECM 26 einen Befehl vom BCM empfangen, das Fahrzeug zu starten-d. h. die Zündung des Fahrzeugs oder ein anderes primäres Antriebssystem (z. B. einen batteriebetriebenen Motor) auszulösen. Darüber hinaus kann das ECM 26 als fahrzeugseitiger Sensor verwendet werden, der Fahrzeugsensorinformationen des Fahrzeugmotors erhalten kann, wie beispielsweise vom Motordrehzahlsensor 62, Motortemperatursensor 64 und Motorzündungszeitsensor 66, die alle auch fahrzeugseitige Sensoren sind. In Ausführungsformen, wenn es sich bei dem Fahrzeug um ein Hybrid- oder Elektrofahrzeug handelt, kann das ECM 26 verwendet werden, um Statusinformationen über den Primärantrieb zu erhalten (einschließlich Elektromotoren und Batterieinformationen). Diese Fahrzeugsensorinformationen können an das BCM 24 oder das drahtlose Kommunikationsmodul 30 gesendet werden, um ein Fahrzeugereignis zu erkennen.
  • Wie hierin verwendet, ist ein „eingeschalteter Zustand“ ein Zustand des Fahrzeugs, in dem das Zünd- oder Primärantriebssystem des Fahrzeugs eingeschaltet ist und, wie hierin verwendet, ist ein „abgeschalteter Zustand“ ein Zustand des Fahrzeugs, in dem die Zündung oder das Primärantriebssystem des Fahrzeugs nicht eingeschaltet ist. Darüber hinaus kann der eingeschaltete Zustand Situationen beinhalten, in denen die Hilfselektronik des Fahrzeugs mit elektrischer Energie versorgt wird.
  • Die Sichtsensoren 42-46 sind jeweils ein fahrzeugseitiger Sensor, und jeder Sichtsensor 42-46 erhält Sichtdaten bezüglich eines Bereichs innerhalb, in der Nähe oder in der Umgebung des Fahrzeugs 12. In mindestens einigen Ausführungsformen können die Sichtsensoren jeweils jede Art von Sensor sein, der visuelle oder räumliche Informationen über einen Bereich innerhalb oder in der Umgebung des Fahrzeugs 12 erhält. Und in vielen Ausführungsformen kann der Sichtsensor ein Bildsensor sein, der Bilddaten über einen Bereich innerhalb, in der Nähe oder in der Umgebung des Fahrzeugs 12 erfasst. Die von den Sichtsensoren 42-46 erhaltenen Sichtdaten können über den Kommunikationsbus 40 an ein anderes Fahrzeugsystemmodul (VSM), wie beispielsweise eine drahtlose Kommunikationsvorrichtung 30 und/oder das BCM 24, gesendet werden. In einer Ausführungsform können die Sichtsensoren 42-46 jeweils eine Speichervorrichtung zum Speichern der Sichtdaten und eine Verarbeitungsvorrichtung zum Verarbeiten der Sichtdaten beinhalten.
  • Die Verarbeitungsvorrichtung der Sichtsensoren 42-46 kann jede Art von Vorrichtung sein, die fähig ist elektronische Befehle zu verarbeiten, einschließlich Mikroprozessoren, Mikrocontrollern, Hostprozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Die Prozessoren können ein dedizierter Prozessor sein, der nur für den Sichtsensor verwendet wird, oder er kann mit anderen Fahrzeugsystemmodulen gemeinsam genutzt werden. Jeder der Prozessoren der Sichtsensoren 42-46 führt verschiedene Arten von digital gespeicherten Anweisungen aus, wie beispielsweise Software oder Firmwareprogramme, die im Speicher gespeichert sind. Außerdem beinhaltet jeder der Sichtsensoren 42-46 einen Speicher, der jedes nicht-flüchtige, computerlesbare Medium beinhaltet; diese beinhalten verschiedene Arten von RAM (Random Access Memory, einschließlich verschiedener Arten von dynamischem RAM (DRAM) und statischem RAM (SRAM)), ROM (Nur-Lese-Speicher), Festkörperlaufwerke (SSDs) (einschließlich anderer Festkörperspeicher, wie beispielsweise Halbleiter-Hybridlaufwerke (SSHDs)), Festplatten (HDDs), magnetische oder optische Diskettenlaufwerke, die einen Teil oder die gesamte Software speichern, die zum Ausführen der verschiedenen hierin beschriebenen Funktionen von Vorrichtungen erforderlich ist. Außerdem können die Sichtsensoren 42-46 in mindestens einigen Ausführungsformen jeweils ein Modem zum Übermitteln von Informationen über den Kommunikationsbus 40 beinhalten. Zusätzlich oder alternativ können die Sichtsensoren 42-46 in mindestens einigen Ausführungsformen jeweils eine Nahbereichsschaltung für drahtlose Kommunikation (SRWC) beinhalten, die es dem Sichtsensor ermöglicht, drahtlos mit einer oder mehreren anderen SRWC-Vorrichtungen, wie beispielsweise der drahtlosen Kommunikationsvorrichtung 30, zu kommunizieren. Diese SRWC-Schaltung kann die gleiche sein oder eine oder mehrere der nachfolgend beschriebenen Merkmale der SRWC-Schaltung 32 in Bezug auf die drahtlose Kommunikationsvorrichtung 30 beinhalten.
  • In einer Ausführungsform beinhaltet einer oder mehrere der Sichtsensoren 42-46 Computeranweisungen, die, wenn sie ausgeführt werden, den Prozessor veranlassen, Sichtdaten zu erfassen und, in mindestens einigen Ausführungsformen, die erfassten Sichtdaten zu komprimieren oder anderweitig in ein standardisiertes oder proprietäres Format zu kodieren. Die komprimierten Sichtdaten können dann an andere Fahrzeugsystemmodule (VSMs), wie beispielsweise die drahtlose Kommunikationsvorrichtung 30, gesendet werden. Wie im Folgenden erläutert, kann ein eindeutiger Hash als Wasserzeichen zu den erfassten Sichtdaten hinzugefügt oder anderweitig in diese eingebettet werden. In einigen Ausführungsformen kann dieses Wasserzeichen vom Sensorsystem selbst vorgenommen werden, entweder als Teil einer Kompression oder eines anderen Codecs, der auf die Sichtdaten angewendet wird, oder separat. Zu diesem Zweck kann der Codec, der zum Kodieren der erfassten Sichtdaten verwendet wird, in seinem Algorithmus Anweisungen zum Einbetten des Hash in die erfassten Sichtdaten beinhalten. Techniken zur Wasserzeichenkennzeichnung von Bilddaten als Teil des Kodierungsalgorithmus sind den Fachleuten bekannt. In anderen Ausführungsformen können die Sichtsensoren 42-46 Rohbilddaten erfassen und dann die roh erfassten Sichtdaten an ein anderes Fahrzeugsystemmodul senden, das dann die Sichtdaten komprimieren/kodieren und den Hash als Wasserzeichen hinzufügen kann. Die Sichtsensoren 42-46 (oder ein anderes VSM, das die Kompression durchführt) können eine Vielzahl von Kompressionstechniken verwenden, einschließlich verschiedener Arten von verlustfreier Kompression oder verlustbehafteter Kompression. So kann beispielsweise einer oder mehrere der Sichtsensoren 42-46 die Laufzeitkodierung, Flächenbildkompression, DEFLATE, Entropiekodierung, adaptive Dictionary-Algorithmen, Transformationskodierung, fraktale Kompression, Farbraumreduktion usw. verwenden. Diese können auf eine Weise implementiert werden, die das Wasserzeichen des Haschs in die Sichtdaten in einer Weise beinhaltet, die eine spätere Extraktion des Haschs zur Überprüfung der Sichtdaten ermöglicht, wie im Folgenden erläutert wird. In anderen Ausführungsformen kann der Hash in die Sichtdaten eingebettet werden, nachdem er komprimiert oder anderweitig mit einem Codec verarbeitet wurde.
  • In einer Ausführungsform ist einer oder mehrere der Sichtsensoren 42-46 konfiguriert, um Sichtdaten beim Auftreten eines Befehls oder einer Anforderung von einem anderen Fahrzeugsystemmodul (VSM) in Bezug auf die Sichtdatenerfassung zu erfassen. So kann beispielsweise einer der Sichtsensoren 42-46 einen Aufnahmebefehl empfangen, der den Sichtsensor anweist (oder anfordert), Sichtdaten zu erfassen, was das Betreiben bestimmter elektronischer Komponenten, das Umschalten in einen Aufnahmemodus und/oder andere Vorgänge beinhalten kann. Und in mindestens einer Ausführungsform kann der Aufnahmebefehl einen Hash-Einschlussindikator beinhalten oder von diesem begleitet werden, der den Sichtsensor darüber informiert oder anweist, ob er beim Komprimieren der Sichtdaten einen Hash einbeziehen soll. Darüber hinaus kann der Aufnahmebefehl in diesen Fällen den einzubettenden Hash beinhalten oder von einer Nachricht mit dem einzubettenden Hash gefolgt oder vorangestellt werden. So können beispielsweise der Aufnahmebefehl, der Hash-Einschlussindikator und der Hash in gleichen oder verschiedenen Nachrichten zu gleichen oder unterschiedlichen Zeiten gesendet werden. In einem Szenario kann der Hash an den Sichtsensor 42-46 als Teil oder als Reaktion auf die Registrierung des Fahrzeugs (oder des Sichtsensors) am Blockchain-Domänenserver 14 gesendet werden. Zu diesem Zeitpunkt kann der Sichtsensor 42-46 den Hash speichern, und wenn ein Aufnahmebefehl empfangen wird, kann der Sichtsensor 42-46 den Hash aus seinem Speicher abrufen, sowie andere Informationen, die in die Sichtdaten eingebettet oder in den Aufnahme- und/oder Kompressionsprozessen verwendet werden sollen. In anderen Ausführungsformen kann der Sichtsensor, sobald er den Hash empfängt, den Hash automatisch in jedes der Einzelbilder oder andere Sichtdaten einbetten, ohne dass ein separater Befehl dafür erforderlich ist.
  • In mindestens einer Ausführungsform umfasst der Hash, der in das Bild oder andere Sichtdaten eingebettet ist, ein Wasserzeichen, das sichtbar oder unsichtbar sein kann (d. h. für einen Benutzer, der das Bild betrachtet, nicht visuell wahrnehmbar oder erkennbar ist). Und das Wasserzeichen (das in die Sichtdaten eingebettet ist) kann mit alphanumerischen Zeichen (oder anderen ähnlichen Zeichen (z. B. ASCII-Zeichen)) in die Sichtdaten eingefügt werden oder durch Ändern einer oder mehrerer Eigenschaften eines oder mehrerer Teile (z. B. eines Satzes benachbarter Pixel, einzelner Pixel) der Sichtdaten. So kann beispielsweise künstliches Rauschen entsprechend dem Hash in die Bilddaten (oder andere Sichtdaten) eingebracht werden. In einer Ausführungsform kann das Wasserzeichen in die räumliche Domäne (z. B. unter Verwendung von Wasserzeichentechniken mit niedrigstwertigen Bit (LSB)) oder in den Frequenzbereich der Sichtdaten eingebettet sein. Einige Beispiele für das Einbetten des Hash in den Frequenzbereich beinhalten die Verwendung von Techniken der diskreten Wavelet-Transformation (DWT), Techniken der diskreten Cosinus-Transformation (DCT) und Techniken der diskreten Fourier-Transformation (DFT). Außerdem können in mindestens einigen Ausführungsformen Steganographietechniken zum Kodieren des Hash in den Bilddaten (oder anderen Sichtdaten) verwendet werden. In einer bestimmten Ausführungsform können reversible Steganographietechniken verwendet werden, die es einem Benutzer der Bilddaten (oder anderer Sichtdaten) ermöglichen, sowohl den eingebetteten Hash als auch das im Originalbild (roh oder unkomprimiert) dargestellte Bild (oder andere physikalische Eigenschaften) zu erhalten. Andere geeignete Techniken zum Einbetten des Hash in die Bilddaten (oder andere Sichtdaten) können ebenfalls verwendet werden. In mindestens einer Ausführungsform, wenn die Bilddaten (oder andere Sichtdaten) mit dem Hash komprimiert werden (sodass die Daten nun das Wasserzeichen oder den eingebetteten Hash beinhalten), sind die zugrundeliegenden (oder ursprünglichen) Bilddaten untrennbar (oder zumindest dazu bestimmt, untrennbar mit dem Wasserzeichen verbunden zu sein) vom Wasserzeichen ohne Erkennung (d. h. ohne Erkennung oder Bestimmung, dass der Hash entfernt oder verändert wurde, durch Prüfung der Bilddaten (oder der anderen Sichtdaten)).
  • In einer Ausführungsform erfassen die Sichtsensoren 42-46 Bilddaten (oder andere Sichtdaten), die dann verwendet werden, um das Fahrzeug 12 über Verkehrsbedingungen und/oder andere Umgebungsinformationen zu informieren. Umgebungsinformationen beziehen sich auf Informationen zu einem Bereich in der Umgebung oder in der Nähe des Fahrzeugs, die bei einem oder mehreren Fahrzeugvorgängen, wie beispielsweise einem autonomen Fahrbetrieb, nützlich sind oder sein können. So beinhalten Umgebungsinformationen beispielsweise Fahrbahnmerkmale wie Strecken- oder Weginformationen (z. B. Krümmung, Fahrbahnbreite, Schulterbreite, Anzahl der Fahrspuren, Fahrspurtypen), Fahrbahnbeschilderungen (z. B. Geschwindigkeitsbegrenzungsschilder, Passier-/Nichtpassierschilder, Gewichtsbegrenzungsschilder, Stoppschilder, Ampeln oder andere Lichtsignale, Straßenschilder, Ausfahrtsschilder), Wetterbedingungen (z. B. Umgebungstemperatur, Niederschläge) und dergleichen. In einer Ausführungsform können die Sichtsensoren 42-44 (Kameras 42 und/oder Lidar 44) Bilddaten erfassen, die dann mit verschiedenen Bilderkennungstechniken (oder anderen Verarbeitungstechniken) verarbeitet werden können, um das Fahrzeug 12 über Verkehrsbedingungen und/oder andere Umgebungsinformationen zu informieren. Das Fahrzeug 12 kann dann einen oder mehrere autonome Fahrzeugvorgänge durchführen, die zumindest teilweise auf diesen Informationen basieren, einschließlich des Erhöhens der Fahrzeuggeschwindigkeit (z. B. durch Betätigen eines Gaspedals), des Verringerns der Fahrzeuggeschwindigkeit (z. B. durch das Betätigen von Fahrzeugbremsen), des Änderns des Lenkwinkels, usw.
  • Die Kamera 42 ist ein Sichtsensor wie vorstehend beschrieben und kann jeder geeignete Kameratyp mit jedem geeigneten Objektiv sein. So kann beispielsweise die Kamera 42 eine ladungsgekoppelte Vorrichtung (CCD), ein komplementärer Metalloxid-Halbleiter (CMOS) oder eine andere Digitalkamera sein. Die Kamera 42 kann verwendet werden, um Fotos, Videos und/oder andere Informationen in Bezug auf sichtbares Licht aufzunehmen, das hierin zusammengefasst als Bilddaten bezeichnet wird. Die Bilddaten sind Sichtdaten, die in einer Pixelanordnung oder einer anderen grafischen Form dargestellt werden können, die physikalische Eigenschaften von Objekten im Sichtfeld des Bildsensors vermittelt. In einer Ausführungsform können die Bilddaten Videodaten (eine Vielzahl von sequentiellen Bildern) oder Bilder (d. h. statische Bilddaten) sein. In mindestens einigen Ausführungsformen können die Bilddaten mittels Interlacing- oder Progressive-Scan-Techniken erfasst werden; wobei jedoch auch andere geeignete Techniken verwendet werden können. Die Bilddaten können bei einem Satz oder mit einer vorkonfigurierten Abtastfrequenz erfasst werden, und die Kamera kann konfiguriert werden, um Bilddaten mit einer bestimmten Auflösung zu erhalten. Nach dem Erhalten der Bilddaten durch die Verwendung der Kamera 42 können die Bilddaten verarbeitet und anschließend an einen oder mehrere andere VSMs, einschließlich der drahtlosen Kommunikationsvorrichtungen 30 und/oder des BCM 24, gesendet werden. Die Kamera 42 können Verarbeitungsfunktionen beinhalten, die es ermöglichen, Bildverarbeitungstechniken, einschließlich Objekterkennungstechniken, an der Kamera 42 durchzuführen. Oder die Kameras können in anderen Ausführungsformen rohe, unkomprimierte oder komprimierte Bilddaten an ein anderes VSM, wie beispielsweise die Vorrichtung 30 (oder einen anderen zentralen Fahrzeugcomputer), senden, das dann die Bildverarbeitungstechniken ausführen kann. Das Fahrzeug 12 kann eine oder mehrere Kameras 42 beinhalten, einschließlich einer Backup- oder Rückfahrkamera, die Bilddaten erfasst, wenn sich das Fahrzeug in einem Rückwärtsgang oder einer Rückwärtsfahrt befindet. Eine oder mehrere der Kameras 42 können am Fahrzeug an verschiedenen Stellen angebracht oder installiert werden, einschließlich der Vorderseite des Fahrzeugs, den Seiten des Fahrzeugs und/oder der Rückseite des Fahrzeugs.
  • Darüber hinaus können die Kameras 42 so konfiguriert oder angebracht werden, dass das Sichtfeld der Kamera eine bestimmte Position in Bezug auf das Fahrzeug erfasst, wie beispielsweise einen Bereich hinter dem Fahrzeug (nach hinten gerichtete Kamera), einen Bereich vor dem Fahrzeug (nach vorne gerichtete Kamera) oder einen Bereich zu den Seiten des Fahrzeugs (seitwärts gerichtete Kamera). In einer Ausführungsform kann die Kamera 42 verwendet werden, um statische Bilder einer Fahrzeugkabine aufzunehmen. In einer anderen Ausführungsform kann die Kamera 42 verwendet werden, um einen Videostream der Fahrbahn aufzunehmen. Und in einer weiteren Ausführungsform kann die Kamera 42 Bilder mit einer Nachtsichtfunktion aufnehmen und in einigen Ausführungsformen eine Wärmebildkamera sein, die zum Aufnehmen von Wärmebildern verwendet wird. Darüber hinaus können die Bilddaten vom Fahrzeug (oder anderen verbundenen Systemen) für eine Vielzahl von Funktionen genutzt werden. So kann beispielsweise das Fahrzeug 12 Bilddaten von den Kameras 42 erhalten und die aufgenommenen Bilddaten verwenden, um Informationen zu den Verkehrsbedingungen oder anderen Umgebungsbedingungen um das Fahrzeug herum zu erhalten. Diese Verkehrsinformationen (oder andere Umgebungsinformationen) können verwendet werden, um ein autonomes Antriebssystem des Fahrzeugs zu informieren, das mit einem oder mehreren der hierin beschriebenen VSMs implementiert werden kann.
  • Der Lidar 44 ist ein Sichtsensor, wie vorstehend beschrieben, und insbesondere ein Lidar, der nicht sichtbare Lichtwellen verwendet, um räumliche oder andere physikalische Informationen bezüglich eines oder mehrerer Objekte im Sichtfeld des Lidars 44 zu erhalten. In vielen Ausführungsformen sendet der Lidar 44 eine Vielzahl von Lichtimpulsen (oder gepulstes Laserlicht) und empfängt die reflektierten Lichtimpulse über einen Lichtsensor. Der Lidar 44 beinhaltet einen Sender, der Lichtwellen unter Verwendung einer Lichtquelle aussendet und kann verschiedene Schaltungen und/oder elektronische Komponenten beinhalten, die eine Anpassung der Eigenschaften der erzeugten Lichtwellen oder Impulse ermöglichen. Der Lidar 44 kann seinen Prozessor nutzen, um die roh erfassten Bilddaten zu komprimieren und andere Vorgänge durchzuführen. Obwohl ein einzelner Lidar 44 dargestellt ist, kann das Fahrzeug 12 ein oder mehrere Lidare beinhalten. Darüber hinaus können die vom Lidar 44 erfassten Sichtdaten Bilddaten sein, die in einer Pixelanordnung (oder einer ähnlichen visuellen Darstellung) dargestellt werden und somit als Bildsensor betrachtet werden können. Der Lidar 44 kann statische Lidarbilder und/oder Lidarbild- oder Videostreams aufzeichnen.
  • Das Radar 46 ist ein Sichtsensor, wie vorstehend beschrieben, und insbesondere ein Radar, das mittels Funkwellen räumliche oder andere physikalische Informationen bezüglich eines oder mehrerer Objekte im Sichtfeld des Radars 46 erhält. Das Radar 46 beinhaltet einen Sender, der elektromagnetische Funkwellen unter Verwendung einer Sendeantenne sendet, und kann verschiedene elektronische Schaltungen beinhalten, die das Erzeugen und Modulieren eines elektromagnetischen Trägersignals ermöglichen. In anderen Ausführungsformen kann das Radar 46 elektromagnetische Wellen in einem anderen Frequenzbereich, wie beispielsweise dem Mikrowellenbereich, übertragen. Das Radar 46 beinhaltet einen Signalprozessor, der zumindest teilweise (z. B. vollständig) mit dem vorstehend beschriebenen Prozessor implementiert werden kann, oder der zumindest teilweise (z. B. vollständig) mit einer speziellen Schaltung implementiert werden kann. Das Radar 46 kann eine separate Empfangsantenne beinhalten, oder das Radar 46 kann eine einzelne Antenne sowohl zum Empfangen als auch zum Senden von Funksignalen beinhalten. Und in anderen Ausführungsformen kann das Radar 46 eine Vielzahl von Sendeantennen, eine Vielzahl von Empfangsantennen oder eine Kombination derselben beinhalten, um Multiple-Input-Multiple-Output (MIMO), Single-Input-Multi-Output (SIMO) oder Multiple-Input-Single-Output (MISO) Techniken zu implementieren. Obwohl ein einzelnes Radar 46 dargestellt ist, kann das Fahrzeug 12 ein oder mehrere Radare beinhalten, die an den gleichen oder unterschiedlichen Stellen am Fahrzeug 12 angebracht werden können.
  • Die drahtlose Kommunikationsvorrichtung 30 ist in der Lage, Daten über die drahtlose Nahbereichskommunikation (SRWC) unter Verwendung der SRWC-Schaltung 32 und/oder über die Mobilfunkkommunikation unter Verwendung eines Mobilfunk-Chipsatzes 34 zu übertragen, wie in der veranschaulichten Ausführungsform dargestellt. In einer Ausführungsform ist die drahtlose Kommunikationsvorrichtung 30 ein zentraler Fahrzeugcomputer, der verwendet werden kann, um verschiedene Fahrzeugaufgaben durchzuführen. In der veranschaulichten Ausführungsform beinhaltet eine drahtlose Kommunikationsvorrichtung 30 eine SRWC-Schaltung 32, einen Mobilfunk-Chipsatz 34, einen Prozessor 36, einen Speicher 38 und die Antennen 33 und 35. In einer Ausführungsform kann die drahtlose Kommunikationsvorrichtung 30 ein selbständiges Modul sein oder die Vorrichtung 30 kann in anderen Ausführungsformen als Teil eines oder mehrerer anderer Fahrzeugsystemmodule integriert oder mit einbezogen werden, wie beispielsweise eines Center-Stack-Moduls (CSM), eines Bordnetzsteuergeräts (BCM) 24, eines Infotainment-Moduls, einer Kopfeinheit, und/oder eines Gateway-Moduls. In einigen Ausführungsformen, kann die Vorrichtung 30 als eine OEM-installierte (eingebettete) oder als eine Aftermarket-Vorrichtung, die in das Fahrzeug installiert wird, implementiert werden. In einigen Ausführungsformen ist die drahtlose Kommunikationsvorrichtung 30 eine Telematikeinheit (oder Telematiksteuereinheit), die in der Lage ist, eine Mobilfunkkommunikation mit einem oder mehreren Mobilfunk-Trägersystemen 70 durchzuführen. Oder es kann in anderen Ausführungsformen eine separate Telematikeinheit in das Fahrzeug integriert und kommunikativ mit der drahtlosen Kommunikationsvorrichtung 30 gekoppelt werden. Das drahtlose Kommunikationsmodul 30 und/oder die Telematikeinheit können mit dem GNSS-Empfänger 22 integriert werden, sodass beispielsweise der GNSS-Empfänger 22 und die drahtlose Kommunikationsvorrichtung 30 (oder Telematikeinheit) direkt miteinander verbunden sind, anstatt über den Kommunikationsbus 40 verbunden zu sein.
  • Die drahtlose Kommunikationsvorrichtung 30 kann für die drahtlose Kommunikation gemäß einem oder mehreren drahtlosen Protokollen, einschließlich drahtloser Nahbereichskommunikation (SRWC), wie beispielsweise eines der Wi-Fi™, WiMAX™, Wi-Fi™ Direkt oder andere IEEE 802.11-Protokolle, ZigBee™, Bluetooth™, Bluetooth™ Low Energy (BLE) oder Nahfeldkommunikation (NFC), konfiguriert sein. Wie hierin verwendet, bezieht sich Bluetooth™ auf jede der Bluetooth™-Technologien, wie beispielsweise Bluetooth Low Energy™ (BLE), Bluetooth™ 4.1, Bluetooth™ 4.2, Bluetooth™ 5.0 und andere Bluetooth™-Technologien, die entwickelt werden können. Wie hierin verwendet, bezieht sich Wi-Fi™ oder Wi-Fi™-Technologie auf jede der Wi-Fi™-Technologien, wie beispielsweise IEEE 802.11b/g/n/ac oder jede andere IEEE 802.11-Technologie. Und in einigen Ausführungsformen kann die drahtlose Kommunikationsvorrichtung 30 konfiguriert werden, um unter Verwendung von IEEE 802.11p so zu kommunizieren, dass das Fahrzeug eine Fahrzeug-zu-Fahrzeug-(V2V)-Kommunikation oder eine Fahrzeug-zu-Infrastruktur-(V2I)-Kommunikation mit Infrastruktursystemen oder -vorrichtungen, wie beispielsweise dem Blockchain-Domänenserver 14, durchführen kann. Und in anderen Ausführungsformen können andere Protokolle für die V2V- oder V2I-Kommunikation verwendet werden. Die drahtlose Nahbereichskommunikations-(SRWC)-Schaltung 32 ermöglicht der drahtlosen Kommunikationsvorrichtung 30 das Senden und Empfangen von SRWC-Signalen, wie beispielsweise BLE-Signale. Die SRWC-Schaltung kann es der Vorrichtung 30 ermöglichen, sich mit einer anderen SRWC-Vorrichtung zu verbinden, wie beispielsweise dem Blockchain-Domänenserver 14. Darüber hinaus enthält die drahtlose Kommunikationsvorrichtung 30 in einigen Ausführungsformen einen Mobilfunk-Chipsatz 34, wodurch der Vorrichtung ermöglicht wird, über ein oder mehrere Mobilfunkprotokolle zu kommunizieren, wie sie beispielsweise vom Mobilfunkträgersystem 70 verwendet werden. In einem derartigen Fall ist die drahtlose Kommunikationsvorrichtung 30 eine Benutzervorrichtung (UE), die zum Ausführen einer Mobilfunkkommunikation über das Mobilfunkträgersystem 70 verwendet werden kann.
  • Die drahtlose Kommunikationsvorrichtung 30 kann dem Fahrzeug 12 ermöglichen, über paketvermittelte Datenkommunikation mit einem oder mehreren lokalen (z. B. dem Blockchain-Domänenserver 14) oder entfernten Netzwerken (z. B. ein oder mehrere Netzwerke in der entfernten Einrichtung 80 oder Computer 78) verbunden sein. Diese paketvermittelte Datenkommunikation kann durch die Nutzung eines nicht fahrzeuggebundenen drahtlosen Zugangspunkts oder einem Mobilfunksystem erfolgen, der über einen Router oder ein Modem mit einem Festnetz verbunden ist. Wenn die Kommunikationsvorrichtung 30 für paketvermittelte Datenkommunikation, wie etwa TCP/IP, verwendet wird, kann sie mit einer statischen Internetprotokoll-(IP)-Adresse konfiguriert oder eingerichtet werden, um eine zugewiesene IP-Adresse von einer anderen Vorrichtung im Netzwerk, wie z. B. einem Router oder einem Netzwerkadressenserver, automatisch zu empfangen. In einer Ausführungsform wird dem Fahrzeug 12 vom Blockchain-Domänenserver 14 eine IP-Adresse zugewiesen, wenn das Fahrzeug eine Verbindung herstellt oder den Blockchain-Domänenserver 14 über die Anwesenheit des Fahrzeugs informiert, beispielsweise durch Senden eines drahtlosen Signals.
  • Paketvermittelte Datenübertragungen können auch über die Verwendung eines Mobilfunknetzes durchgeführt werden, auf das die Vorrichtung 30 zugreifen kann. Die Kommunikationsvorrichtung 30 kann Daten mittels einem Mobilfunk-Chipsatz 34 über das Drahtlosträgersystem 70 übertragen. In einer derartigen Ausführungsform können Funkübertragungen dazu verwendet werden, einen Kommunikationskanal, wie beispielsweise einen Sprachkanal und/oder einen Datenkanal, mit dem Drahtlosträgersystem 70 einzurichten, sodass Sprach- und/oder Datenübertragungen über den Kanal gesendet und empfangen werden können. Daten können entweder über eine Datenverbindung, wie Paketdatenübertragung über einen Datenkanal oder über einen Sprachkanal, unter Verwendung von auf dem Fachgebiet bekannten Techniken gesendet werden. Für kombinierte Dienste, die sowohl Sprach- als auch Datenkommunikation einschließen, kann das System einen einzelnen Anruf über einen Sprachkanal verwenden und nach Bedarf zwischen Sprach- und Datenübertragung über den Sprachkanal umschalten, auch hier kommen Techniken zum Einsatz, die unter Fachleuten bekannt sind.
  • Der Prozessor 36 kann jede Geräteart sein, die fähig ist elektronische Befehle zu verarbeiten, einschließlich Mikroprozessoren, Mikrocontrollern, Hostprozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Er kann ein speziell für die Datenübertragungsvorrichtung 30 vorgesehener Prozessor sein oder er kann mit anderen Fahrzeugsystemen gemeinsam genutzt werden. Der Prozessor 36 führt verschiedene Arten von digital gespeicherten Befehlen aus, wie Software oder Firmwareprogramme, die im Speicher 38 gespeichert sind, welche dem Gerät 30 ermöglichen, eine große Vielfalt von Diensten bereitzustellen. Zum Beispiel kann der Prozessor 36 Programme ausführen oder Daten verarbeiten, um mindestens einen Teil des Verfahrens auszuführen, das hierin beschrieben ist. Der Speicher 38 kann jedes geeignete nichtflüchtige, computerlesbare Medium beinhalten; diese beinhalten verschiedene Arten von RAM (Random Access Memory, einschließlich verschiedener Arten von dynamischem RAM (DRAM) und statischem RAM (SRAM)), ROM (Nur-Lese-Speicher), Festkörperlaufwerke (SSDs) (einschließlich anderer Festkörperspeicher, wie beispielsweise Halbleiter-Hybridlaufwerke (SSHDs)), Festplatten (HDDs), magnetische oder optische Diskettenlaufwerke, die einen Teil oder die gesamte Software speichern, die zum Ausführen der verschiedenen hierin beschriebenen Funktionen von externen Vorrichtungen erforderlich ist. In einer Ausführungsform beinhaltet die drahtlose Kommunikationsvorrichtung 30 auch ein Modem zum Übertragen von Informationen über den Kommunikationsbus 40.
  • Die drahtlose Kommunikationsvorrichtung 30 kann eine Schnittstelle zwischen verschiedenen VSMs des Fahrzeugs 12 und einer oder mehreren Vorrichtungen außerhalb des Fahrzeugs 12 bereitstellen, wie beispielsweise einem oder mehreren Netzwerken oder Systemen in der entfernten Einrichtung 80. Dies ermöglicht es dem Fahrzeug, Daten oder Informationen mit entfernten Systemen, wie beispielsweise der entfernten Einrichtung 80, zu kommunizieren. In einer Ausführungsform führt die drahtlose Kommunikationsvorrichtung 30 einen Domain-Registrierungsprozess mit dem Blockchain-Domänenserver 14 durch. Und die drahtlose Kommunikationsvorrichtung 30 kann zusätzlich Fahrzeugereignisse erkennen und einen Erfassungsbefehl an einen oder mehrere Sichtsensoren 42-46 senden, wodurch der empfangende Sichtsensor 42-46 angewiesen wird, Sichtdaten zu erfassen. In einer Ausführungsform sendet die drahtlose Kommunikationsvorrichtung 30 einen Erfassungsbefehl an die Kamera 42 sowie einen sensorspezifischen Hash, einen fahrzeugspezifischen Hash, einen Registrierungshash oder einen anderen hierin beschriebenen Hash. Die Kamera 42 kann dann die erfassten Bilddaten komprimieren, die vor dem Komprimieren als Rohbilddaten bezeichnet werden können. Als Teil des Kompressionsprozesses durch die Kamera 42 kann die Kamera 42 den empfangenen Hash in die resultierenden komprimierten Bilddaten einbetten oder beinhalten. Diese komprimierten Bilddaten können dann lokal im Speicher der Kamera 42 gespeichert und/oder über den Kommunikationsbus 40 an die drahtlose Kommunikationsvorrichtung 30 gesendet werden. In einigen Ausführungsformen verteilt die drahtlose Kommunikationsvorrichtung 30 während (oder nach Beendigung) des Domain-Registrierungsprozesses mit dem Blockchain-Domänenserver 14 einen oder mehrere Hashs an verschiedene VSMs des Fahrzeugs, wie beispielsweise die Sichtsensoren 42-46. Diese Hashs können dann vom empfangenden VSM im Speicher des VSM gespeichert werden. Im Fall der Bildsensoren 42-46 können diese Hashs zu Beginn (oder während) des Kompressionsprozesses abgerufen werden.
  • Die Fahrzeugelektroniken 20 beinhalten auch einige Benutzeroberflächen für die Fahrzeuginsassen, die dem Empfang und/oder Abruf von Informationen dienen, darunter eine optische Anzeige 50, eine oder mehrere Drucktasten 52, ein Mikrofon 54 und ein Audiosystem 56. Wie hierin verwendet, umfasst der Begriff „Fahrzeugbenutzeroberfläche“ weitgehend jede geeignete Form von elektronischer Vorrichtung, zu dem sowohl im Fahrzeug befindliche Hardware- als auch Softwarekomponenten gehören und einem Fahrzeugbenutzer wird ermöglicht, mit oder durch eine(r) Komponente des Fahrzeugs zu kommunizieren. Die Drucktaste(n) 52 ermöglichen eine manuelle Benutzereingabe in die Kommunikationsvorrichtung 30, um weitere Daten, Reaktionen und/oder Steuereingänge bereitzustellen. Das Audiosystem 56 stellt eine Audioausgabe an einen Fahrzeuginsassen bereit und kann ein zugehöriges selbstständiges System oder Teil des primären Fahrzeugaudiosystems sein. Gemäß einer Ausführungsform ist das Audiosystem 56 operativ sowohl mit dem Fahrzeugbus 40 als auch mit einem Entertainmentbus (nicht dargestellt) gekoppelt und kann AM-, FM- und Satellitenradio, CD-, DVD- und andere Multimediafunktionalität bereitstellen. Diese Funktionalität kann in Verbindung mit dem Infotainmentmodul oder davon unabhängig bereitgestellt werden. Das Mikrofon 54 stellt eine Audioeingabe an die drahtlose Kommunikationsvorrichtung 30 bereit, um dem Fahrer oder anderen Insassen zu ermöglichen, Sprachsteuerungen bereitzustellen und Freisprechen über das Drahtlosträgersystem 70 auszuführen. Für diesen Zweck kann es mit einer integrierten automatischen Sprachverarbeitungseinheit verbunden sein, welche die unter Fachleuten auf dem Gebiet bekannte Mensch-Maschinen-Schnittstellen (HMI)-Technologie verwendet. Die optische Anzeige oder der Touchscreen 50 ist bevorzugt eine Grafikanzeige und kann verwendet werden, um eine Vielzahl von Eingabe- und Ausgabefunktionen bereitzustellen. Die Anzeige 50 kann ein Touchscreen auf dem Armaturenbrett, ein Heads-up-Display, das von der Windschutzscheibe reflektiert wird, oder ein Projektor sein, der Grafiken zum Betrachten durch einen Fahrzeuginsassen projizieren kann. Verschiedene andere Fahrzeugbenutzeroberflächen können ebenfalls zum Einsatz kommen, die Schnittstellen in 1 dienen lediglich als Beispiel für eine bestimmte Implementierung.
  • Das Drahtlosträgersystem 70 kann jedes geeignete Mobiltelefonsystem sein. Das Trägersystem 70 ist mit einem Mobilfunkmast 72 dargestellt; jedoch kann das Trägersystem 70 eine oder mehrere der folgenden Komponenten beinhalten (z. B. abhängig von der Mobilfunktechnologie): Mobilfunkmasten, Basisübertragungsstationen, Mobilvermittlungszentralen, Basisstationssteuerungen, entwickelte Knotenpunkte (z. B. eNodeBs), Mobilitätsmanagement-Einheiten (MMEs), Serving- und PGN-Gateways usw. sowie alle anderen Netzwerkkomponenten, die erforderlich sind, um das Drahtlosträgersystem 70 mit dem Festnetz 76 zu verbinden oder das Drahtlosträgersystem mit der Benutzerausrüstung (UEs, die z. B. die Telematikausrüstung im Fahrzeug 12 beinhalten können) zu verbinden. Das Trägersystem 70 kann jede geeignete Kommunikationstechnik realisieren, einschließlich GSM/GPRS-Technologie, CDMA- oder CDMA2000-Technologie, LTE-Technologie, usw. Im Allgemeinen sind Drahtlosträgersysteme 70, deren Komponenten, die Anordnung ihrer Komponenten, das Zusammenwirken der Komponenten usw. weitgehend im dem Stand der Technik bekannt.
  • Abgesehen vom Verwenden des Drahtlosträgersystems 70 kann ein unterschiedliches Drahtlosträgersystem in der Form von Satellitenkommunikation verwendet werden, um unidirektionale oder bidirektionale Kommunikation mit dem Fahrzeug bereitzustellen. Dies kann unter Verwendung von einem oder mehreren Kommunikationssatelliten (nicht dargestellt) und einer aufwärts gerichteten Sendestation (nicht dargestellt) erfolgen. Die unidirektionale Kommunikation können beispielsweise Satellitenradiodienste sein, worin programmierte Inhaltsdaten (Nachrichten, Musik usw.) von der Uplink-Sendestation erhalten werden, für das Hochladen gepackt und anschließend zum Satelliten gesendet werden, der die Programmierung an die Teilnehmer sendet. Bidirektionale Kommunikation kann beispielsweise Satellitentelefoniedienste unter Verwendung ein oder mehrerer Kommunikationssatelliten sein, um Telefonkommunikationen zwischen dem Fahrzeug 12 und der Aufwärtssendestation weiterzugeben. Bei Verwendung kann diese Satellitentelefonie entweder zusätzlich oder anstatt des Drahtlosträgersystems 70 verwendet werden.
  • Das Festnetz 76 kann ein herkömmliches landgebundenes Telekommunikationsnetzwerk sein, das mit einem oder mehreren Festnetztelefonen verbunden ist und das Drahtlosträgersystem 70 mit der entfernten Einrichtung 80 und/oder dem Blockchain-Domänenserver 14 verbindet. Zum Beispiel kann das Festnetz 76 ein Fernsprechnetz (PSTN) beinhalten, wie es verwendet wird, um die Festnetz-Telefonie, die paketvermittelte Datenkommunikation und die Internet-Infrastruktur bereitzustellen. Ein oder mehrere Segmente des Festnetzes 76 könnten durch Verwenden eines normalen drahtgebundenen Netzwerks, eines Lichtleiter- oder eines anderen optischen Netzwerks, eines Kabelnetzes, Stromleitungen, anderen drahtlosen Netzwerken, wie drahtlose lokale Netzwerke (WLANs) oder Netzwerke, die drahtlosen Breitbandzugang (BWA) bereitstellen oder jeder Kombination davon implementiert sein.
  • Die Computer 78 (nur einer davon ist dargestellt) können für einen oder mehrere Zwecke verwendet werden, wie beispielsweise zum Bereitstellen von Backend-Fahrzeugdiensten für eine Vielzahl von Fahrzeugen (wie beispielsweise das Fahrzeug 12) und/oder zum Bereitstellen anderer fahrzeugbezogener Dienste, wie sie beispielsweise für den Blockchain-Domänenserver 14 verwendet werden. Die Computer 78 können einige von einer Anzahl an Computern sein, die über ein privates oder öffentliches Netzwerk, wie das Internet, zugänglich sind. Bei anderen derartig zugänglichen Computern 78 kann es sich beispielsweise um Folgende handeln: ein Computer in einem Kundendienstzentrum, bei dem Diagnoseinformationen und andere Fahrzeugdaten vom Fahrzeug hochgeladen werden können; ein Clientcomputer, der von dem Fahrzeugbesitzer oder einem anderen Teilnehmer für verschiedene Zwecke, wie etwa das Zugreifen auf und/oder Empfangen von Fahrzeugsensordaten (z. B. Bilddaten oder andere Sichtdaten), sowie das Einrichten und/oder Konfigurieren von Teilnehmerpräferenzen oder das Steuern von Fahrzeugfunktionen; oder ein Fahrzeugtelemetriedatenserver, der Daten von einer Vielzahl von Fahrzeugen empfängt und speichert. Ein Computer 78 kann auch für das Bereitstellen von Internetkonnektivität, wie DNS-Dienste oder als ein Netzwerkadressenserver, verwendet werden, der DHCP oder ein anderes geeignetes Protokoll verwendet, um dem Fahrzeug 12 eine IP-Adresse zuzuweisen.
  • Die Fahrzeug-Backend-Serviceeinrichtung 80 ist eine entfernte Einrichtung, d. h. sie befindet sich an einem physischen Standort, der sich entfernt vom Fahrzeug 12 befindet. Die Fahrzeug-Backend-Serviceeinrichtung 80 (oder kurz „entfernte Einrichtung 80“) kann so konzipiert sein, dass sie der Fahrzeugelektronik 20 eine Reihe von verschiedenen System-Backend-Funktionen unter Verwendung eines oder mehrerer elektronischer Server 82 bereitstellt. Die Fahrzeug-Backend-Serviceeinrichtung 80 beinhaltet Fahrzeug-Backend-Dienstleistungsserver 82 und Datenbanken 84, die auf einer Vielzahl von Speichervorrichtungen gespeichert werden können. Die entfernte Einrichtung 80 empfängt und überträgt Daten über ein mit dem Festnetz 76 verbundenes Modem. Datenübertragungen können auch durch drahtlose Systeme, wie z. B. IEEE 802.11x, GPRS und dergleichen, erfolgen. Fachleute auf dem Gebiet werden erkennen, dass, obwohl nur eine entfernte Einrichtung 80 und ein Computer 78 in der veranschaulichten Ausführungsform dargestellt sind, jedoch zahlreiche entfernte Einrichtungen 80 und/oder Computer 78 verwendet werden können.
  • Die Server 82 können Computer oder andere Computervorrichtungen sein, die mindestens einen Prozessor und einen Speicher beinhalten. Der Prozessor kann jede Art von Vorrichtung sein, die fähig ist elektronische Befehle zu verarbeiten, einschließlich Mikroprozessoren, Mikrocontrollern, Hostprozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Die Prozessoren können dedizierte Prozessoren sein, die nur für die Server 82 verwendet werden oder mit anderen Systemen gemeinsam genutzt werden können. Der mindestens eine Prozessor kann verschiedene Arten von digital gespeicherten Anweisungen ausführen, wie beispielsweise Software oder Firmware, die es den Servern 82 ermöglichen, eine Vielzahl von Diensten bereitzustellen. Für die Netzwerkkommunikation (z. B. Intra-Netzwerk-Kommunikation, Inter-Netzwerk-Kommunikation einschließlich Internetverbindungen) können die Server eine oder mehrere Netzwerkschnittstellenkarten (NICs) (einschließlich zum Beispiel drahtloser NICs (WNICs)) beinhalten, die für den Datentransport zu und von den Computern verwendet werden können. Diese NICs können es einem oder mehreren Servern 82 ermöglichen, sich untereinander, mit Datenbanken 84 oder anderen Netzwerkvorrichtungen, einschließlich Routern, Modems und/oder Switches, zu verbinden. In einer bestimmten Ausführungsform können die NICs (einschließlich WNICs) der Server 82 das Herstellen von SRWC-Verbindungen ermöglichen und/oder Ethernet-Ports (IEEE 802.3) beinhalten, an die Ethernet-Kabel angeschlossen werden können, die eine Datenverbindung zwischen zwei oder mehr Vorrichtungen vorsehen können. Die entfernte Einrichtung 80 kann eine Reihe von Routern, Modems, Switches oder anderen Netzwerkvorrichtungen beinhalten, die zum Bereitstellen von Netzwerkfunktionen verwendet werden können, wie beispielsweise die Verbindung mit dem Festnetz 76 und/oder dem Mobilfunkträgersystem 70.
  • Die Datenbanken 84 können auf einer Vielzahl von Speichern gespeichert werden, wie beispielsweise einem betriebenen temporären Speicher oder einem geeigneten nichtflüchtigen, computerlesbaren Medium; diese beinhalten verschiedene Arten von RAM (Random Access Memory, einschließlich verschiedener Arten von dynamischem RAM (DRAM) und statischem RAM (SRAM)), ROM (Nur-Lese-Speicher), Festkörperlaufwerke (SSDs) (einschließlich anderer Festkörperspeicher, wie beispielsweise Halbleiter-Hybridlaufwerke (SSHDs)), Festplatten (HDDs), magnetische oder optische Diskettenlaufwerke, die einen Teil oder die gesamte Software speichern, die zum Ausführen der verschiedenen hierin beschriebenen Funktionen von externen Vorrichtungen erforderlich ist. Eine oder mehrere Datenbanken in der Backend-Einrichtung 80 können verschiedene Informationen speichern und können eine Blockchain-Management-Datenbank und eine Fahrzeugtelemetriedatenbank beinhalten. Die Blockchain-Management-Datenbank kann Informationen zur Verwendung beim Ausführen der Blockchain(s) speichern, die von den Blockchain-Domänenservern 14 verwendet werden. In einigen Ausführungsformen wird keine Blockchain-Management-Datenbank verwendet, da die Blockchain-Domänenserver 14 die Blockchain verteilt implementieren, ohne dass zentrale Dienste erforderlich sind. Und in einigen Ausführungsformen kann die Blockchain-Management-Datenbank Aufzeichnungen über die verschiedenen Blockchain-Domänenserver 14 führen und/oder Software zur Verwendung durch die Blockchain-Management-Datenbank beinhalten. Der Fernserver 14 kann somit agieren, um Software (und/oder Software-Updates) an die verschiedenen Blockchain-Domänenserver 14 zu verteilen. Die Fahrzeugtelemetriedatenbank beinhaltet Informationen, die von einer Vielzahl von Fahrzeugen, wie beispielsweise dem Fahrzeug 12, empfangen wurden, und kann zum Speichern von Bilddaten oder anderen Sichtdaten verwendet werden, die mit einem Hash eingebettet sind. Sichtdaten gelten als „Wasserzeichen“, wenn die Sichtdaten manipuliert (z. B. komprimiert, kodiert) werden, um einen eingebetteten Hash oder ein Wasserzeichen aufzunehmen. Und in mindestens einigen Ausführungsformen sind die Sichtdaten mit einem Wasserzeichen versehen, sodass der Hash nicht dazu bestimmt ist, ohne Erkennung aus den Sichtdaten entfernt zu werden.
  • Der Blockchain-Domänenserver 14 implementiert eine Blockchain, die Sichtdaten mit einem oder mehreren Hashs beinhaltet. In mindestens einigen Ausführungsformen werden die Sichtdaten erfasst und an einem Fahrzeug mit einem Hash versehen, der als Teil einer Blockchain erzeugt wird. Die mit einem Wasserzeichen versehenen Bilddaten können dann in einer entfernten Einrichtung (z. B. einer zentralen Datenbank oder Datenspeichereinrichtung) gespeichert und/oder auf dem Blockchain-Domänenserver 14 gespeichert werden. In einer Ausführungsform werden die mit einem Wasserzeichen versehenen Sichtdaten an den Blockchain-Domänenserver 14 gesendet, sodass die Sichtdaten als Teil der Blockchain (z. B. innerhalb eines Blocks der Blockchain) aufgezeichnet werden. Die Blockchain-Domänenserver 14 können geografisch an Standorten angrenzend an oder in der Nähe von Fahrbahnen verteilt und je nach Bevölkerungs- oder Verkehrsdichte verteilt werden. In einer Ausführungsform kann der Blockchain-Domänenserver 14 mit Hardwarekomponenten (z. B. der Hardware 92, 94 und 96) implementiert werden, die mit anderen Systemen gemeinsam genutzt werden, wie beispielsweise Straßeneinheiten (RSUs), Verkehrssteuerungs- oder Überwachungssysteme, Mobilfunkinfrastrukturen, persönliche elektronische Vorrichtungen (z. B. Smartphones, Laptops, Tablets, PCs), Computer 78, usw. Und in einer weiteren Ausführungsform kann der Blockchain-Domänenserver 14 mit speziellen Hardwarekomponenten implementiert werden, die nur zum Ausführen der hierin beschriebenen Blockchain-Domänenserverfunktionalität und anderer verwandter Funktionen verwendet werden (oder primär für diese verwendet werden).
  • Der Blockchain-Domänenserver 14 beinhaltet ein drahtloses Kommunikationsmodul 92, einen Prozessor 94 und einen Speicher 96. Obwohl ein einzelner Blockchain-Domänenserver 14 in der veranschaulichten Ausführungsform von 1 veranschaulicht ist, beinhaltet das System 10 eine Vielzahl von Blockchain-Domänenservern 14 (2). Das drahtlose Kommunikationsmodul 92 kann sowohl für die drahtlose Nahbereichskommunikation (SRWCs) als auch für die Mobilfunkkommunikation sowie für andere Funk- oder Drahtloskommunikation verwendet werden. Das drahtlose Kommunikationsmodul 92 kann SRWC-Schaltungen und einen Mobilfunk-Chipsatz beinhalten. In anderen Ausführungsformen kann das drahtlose Kommunikationsmodul 92 entweder SRWC-Schaltungen oder einen Mobilfunk-Chipsatz beinhalten. Die SRWC-Schaltung ermöglicht es dem drahtlosen Kommunikationsmodul 92 drahtlos gemäß einer oder mehreren drahtlosen Nahbereichskommunikation (SRWC) zu kommunizieren, wie beispielsweise Wi-Fi™, WiMAX™, Wi-Fi™ Direkt oder andere IEEE 802.11-Protokolle, ZigBee™, Bluetooth™, Bluetooth™ Low Energy (BLE) oder Nahfeldkommunikation (NFC). Und in einigen Ausführungsformen kann das drahtlose Kommunikationsmodul 92 konfiguriert werden, um unter Verwendung von IEEE 802.1 1p so zu kommunizieren, dass der Blockchain-Domänenserver 14 eine Fahrzeug-zu-Infrastruktur-(V2I)-Kommunikation mit einer Vielzahl von Fahrzeugen, wie beispielsweise dem Fahrzeug 12, durchführen kann. Der Mobilfunk-Chipsatz des drahtlosen Kommunikationsmoduls 92 ermöglicht es dem Blockchain-Domänenserver 14, über ein oder mehrere Mobilfunkprotokolle zu kommunizieren, wie sie beispielsweise vom Mobilfunk-Trägersystem 70 verwendet werden. In einem derartigen Fall ist das drahtlose Kommunikationsmodul 92 eine Benutzervorrichtung (UE), die zum Ausführen einer Mobilfunkkommunikation über das Mobilfunkträgersystem 70 verwendet werden kann.
  • Der Prozessor 94 kann jede Art von Vorrichtung sein, die fähig ist elektronische Befehle zu verarbeiten, einschließlich Mikroprozessoren, Mikrocontrollern, Hostprozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Die Prozessoren können dedizierte Prozessoren sein, die nur für den Blockchain-Domänenserver 14 verwendet werden oder mit anderen Infrastruktursystemen gemeinsam genutzt werden können. Der mindestens eine Prozessor kann verschiedene Arten von digital gespeicherten Anweisungen, wie beispielsweise Software oder Firmware, ausführen, die es dem Blockchain-Domänenserver 14 ermöglichen, verschiedene Funktionen auszuführen, wie sie im folgenden Verfahren (3) beschrieben sind. Der Speicher 96 kann jedes nicht-flüchtige, computerlesbare Medium beinhalten; diese beinhalten verschiedene Arten von RAM (Random Access Memory, einschließlich verschiedener Arten von dynamischem RAM (DRAM) und statischem RAM (SRAM)), ROM (Nur-Lese-Speicher), Festkörperlaufwerke (SSDs) (einschließlich anderer Festkörperspeicher, wie beispielsweise Halbleiter-Hybridlaufwerke (SSHDs)), Festplatten (HDDs), magnetische oder optische Diskettenlaufwerke, die einen Teil oder die gesamte Software speichern, die zum Ausführen der verschiedenen hierin beschriebenen Funktionen von Vorrichtungen erforderlich ist.
  • Unter Bezugnahme auf 2 ist eine Vielzahl von Blockchain-Domänenservern dargestellt, von denen jeder einer geografischen Domäne 100, 110, 120, 130 140, 150 und 160 zugeordnet ist. Die geografischen Domänen können einen oder mehrere Blockchain-Domänenserver 14 und/oder eine oder mehrere Speichervorrichtungen, wie beispielsweise den Speicher 96 der Server 14, beinhalten (und/oder mit ihnen verbunden sein). Die geografischen Domänen 100, 110, 120, 130, 140, 150 und 160 sind jeweils einer einzigen Blockchain 104, 114, 124, 134, 144, 154 und 164 zugeordnet. Diese Blockchains sind jeweils in einer Datenbank 102, 112, 132, 146, 152 und 162 gespeichert, die jeweils von einem Blockchain-Domänenserver (z. B. dem Server 14) auf einer Speichervorrichtung (z. B. dem Speicher 96) verwaltet werden können. In anderen Ausführungsformen kann jede geografische Domäne mit zahlreichen Blockchains verknüpft werden, oder eine einzelne Blockchain kann mit einer Vielzahl von geografischen Domänen verwendet (oder verknüpft) werden. Jede der geografischen Domänen 100, 110, 120, 130 140, 150 und 160 entspricht einer geografischen Region oder einer Zelle. Die Begrenzungen der geografischen Regionen können auf eine feste Größe oder einen festen Durchmesser eingestellt werden, oder die Größen (oder Begrenzungen) der geografischen Regionen können aufgrund anderer Faktoren, wie beispielsweise der Bevölkerungsdichte oder der Verkehrsdichte (Fahrzeugdichte), variieren. In einer Ausführungsform beinhaltet jede geografische Domäne eine Mobilfunk- oder andere drahtlose Schaltung (z. B. SRWC-Schaltung), um mit einer Vielzahl von Fahrzeugen zu kommunizieren, die sich derzeit innerhalb der geografischen Domäne befinden (oder sich ihr nähern); diese Schaltung kann die des vorstehend erläuterten Mobilfunkmoduls 92 sein. Und in einer derartigen Ausführungsform kann jede geografische Domäne einer Zelle des Drahtlosträgersystems 70 entsprechen.
  • Jede Blockchain 104, 114, 124, 134, 144, 154 und 164 beinhaltet einen oder mehrere Blöcke, von denen jeder in einer kettenartigen Weise verbunden ist, wie nachfolgend erläutert wird. Die Blockchains können kopiert und in einer Vielzahl von elektronischen Vorrichtungen gespeichert werden, die andere Blockchain-Domänenserver oder andere hierin erläuterte elektronische Vorrichtungen beinhalten können. So kann beispielsweise eine Kopie der Blockchain von verschiedenen Organisationen aufbewahrt (und in einigen Ausführungsformen separat überprüft) oder in verschiedenen Datenbanken gespeichert werden, darunter ein oder mehrere OEMs, verschiedene Datenbanken eines OEMs (z. B. die Datenbanken 84 verschiedener entfernter Einrichtungen 80), staatliche oder verwaltete Datenbanken und andere Datenspeichereinheiten. In einem Szenario registriert sich das Fahrzeug 12 bei einer geografischen Domäne 100, wenn das Fahrzeug 12 über den Blockchain-Domänenserver 14 in die Domäne 100 eintritt. Die Registrierung kann Authentifizierungsinformationen vom Fahrzeug 12 auswerten. Sobald die Authentifizierungsinformationen überprüft wurden, kann dem Fahrzeug 12 durch die geografische Domäne 100 vertraut werden und Transaktionen, die das Fahrzeug 12 betreffen, können über die zugehörige Blockchain 104 protokolliert werden.
  • Jeder Block der Blockchain beinhaltet einen Blockchain-Header und Blockchain-Daten. Der Blockchain-Header beinhaltet eine Blockkennung, einen Zeitindikator, einen Blockhash und einen vorherigen Blockhash. Die Blockkennung kann jede beliebige Kennung sein, die eine Reihenfolge des Blocks identifiziert. So kann beispielsweise der erste Block der Blockchain (manchmal auch als „Genesis-Block“ bezeichnet) eine Blockkennung von „1“ oder „Block 1“ beinhalten. Der nächste Block der Blockchain kann dann eine Blockkennung von „2“ oder „Block 2“ beinhalten. Der Zeitindikator kann ein Wert sein, der eine bestimmte Zeit und ein bestimmtes Datum für den Block identifiziert, was eine Zeit eines Fahrzeugereignisses, eine Zeit, in welcher der Block aufgebaut wurde, oder die Zeit, in welcher der Block validiert wurde, sein kann. In einigen Ausführungsformen können mehrere Zeitstempel enthalten sein. Die Blöcke können unter Verwendung verschiedener Techniken, wie beispielsweise dem Nachweis der Arbeit (z. B. „Mining“), dem Nachweis des Einsatzes (oder anderen Konsenstechniken) oder anderen Validierungstechniken, validiert werden. Der Blockhash (d. h. eine Art von Blockchain-Hash) ist ein Hash, der unter Verwendung einer Hash-Funktion mit den Blockchain-Daten des Blocks als Eingabe erzeugt wird. Der Blockhash kann verschiedene Hash (oder Hashing) Funktionen verwenden, einschließlich beispielsweise SHA-256 (oder andere SHA-Hash-Algorithmen) oder MD5. In vielen Ausführungsformen wird eine kryptographische Hashfunktion oder eine Einweg-Hashfunktion verwendet. Und in einigen Ausführungsformen können die Blockchain-Daten mit verschiedenen Techniken gehasht werden, wie beispielsweise unter Verwendung eines Merkle-Baums (oder Hash-Baums). In einer Ausführungsform ist jeder Block einer einzelnen Blockchain-Transaktion und einem entsprechenden Fahrzeugereignis zugeordnet. In anderen Ausführungsformen kann jeder Block eine Vielzahl von Blockchain-Transaktionen beinhalten, von denen jede gehasht und dann (unter Verwendung eines oder mehrerer übergeordneter Hashs) kombiniert werden kann, um den Blockchain-Hash (oder Root-Hash) zu bilden. Der vorherige Blockchain-Hash ist der Blockchain-Hash des vorherigen Blocks in der Blockchain. So ist beispielsweise der vorherige Blockchain-Hash für den zweiten Block („Block 2“) der Blockchain-Hash des ersten Blocks („Block 1“).
  • Die Blockchain-Daten jedes Blocks können eine oder mehrere Blockchain-Transaktionen beinhalten. Jede Blockchain-Transaktion ist einem einzelnen Fahrzeugereignis zugeordnet; in anderen Ausführungsformen kann jedoch jede Blockchain-Transaktion einem oder mehreren Fahrzeugereignissen oder einer Vielzahl von Fahrzeugereignissen zugeordnet werden. Ein Fahrzeugereignis kann jeder erkennbare Fahrzeugzustand (oder eine Reihe von Fahrzeugzuständen) sein, und das Erkennen des Fahrzeugereignisses kann einem vordefinierten Auslöser zugeordnet werden. Jede Blockchain-Transaktion kann eine Fahrzeugkennung und Ereignisdaten beinhalten. Die Fahrzeugereignisdaten können Fahrzeugzustandsinformationen, einen Fahrzeugereignistyp (z. B. Fahrzeugereignistypkennung), eine Fahrzeugereigniskennung (d. h. eine Kennung, die das Fahrzeugereignis eindeutig identifiziert), eine oder mehrere Sichtsensorkennungen (d. h. Kennungen, die jeweils zur eindeutigen Identifizierung des Sichtsensors verwendet werden können, der Sichtdaten erfassen oder Wasserzeichenbilddaten erfassen soll) und verschiedene andere Informationen beinhalten. Die Fahrzeugkennung kann eine Fahrzeugidentifikationsnummer (VIN), eine Kennung der drahtlosen Kommunikationsvorrichtung 30 (z. B. eine Mobilfunkteilnehmerkennung, eine Bluetooth™-Adresse (BD_ADDR), eine internationale Mobilgerätekennung (IMEI)-Nummer) oder andere Informationen sein, die zur eindeutigen Identifizierung des Fahrzeugs 12 verwendet werden können. Die Fahrzeugzustandsinformationen können eine oder mehrere Fahrzeugsensorablesungen oder Daten von einem oder mehreren fahrzeugseitigen Sensoren des Fahrzeugs 12 sein, wie beispielsweise ein Kollisionssensor, Sichtsensoren 42-46, Motordrehzahlsensor 62, Motortemperatursensor 64, Motorzündzeitpunktgeber 66, Raddrehzahlsensor, GNSS-Empfänger 22, Touchscreen-Anzeige 50, Drucktaste 52 und/oder Mikrofon 54. Ebenso können die Fahrzeugzustandsinformationen (entweder zusätzlich oder alternativ) Informationen von der drahtlosen Kommunikationsvorrichtung 30, BCM 24 oder anderen VSMs 28 beinhalten. Die Fahrzeugzustandsinformationen können Umgebungsinformationen, wie beispielsweise Verkehrsinformationen oder Fahrbahninformationen, beinhalten. In einer Ausführungsform beinhalten die in den Blockchain-Daten enthaltenen Fahrzeugzustandsinformationen einen Fahrzeugstandort und mindestens ein weiteres Datum für Fahrzeugzustandsinformationen. Der Fahrzeugstandort kann durch das Fahrzeug unter Verwendung des GNSS-Empfängers 22 oder durch die Verwendung anderer Ortungsdienste bestimmt werden.
  • Der Blockchain-Domänenserver 14 kann Fahrzeugereignisdaten von einer Vielzahl von Fahrzeugen, wie beispielsweise dem Fahrzeug 12, empfangen. Sobald der Blockchain-Domänenserver 14 die Fahrzeugereignisdaten empfangen hat, kann der Blockchain-Domänenserver 14 das Fahrzeugereignis in der Blockchain-Datenbank, wie beispielsweise der Blockchain-Datenbank 102, aufzeichnen. Diese Aufzeichnung kann das Erstellen eines neuen Blocks beinhalten, welcher der Blockchain 104 hinzugefügt wird, was das Erzeugen eines Hash der Blockchain-Daten sowie das Erhalten eines früheren Blockchain-Hash beinhaltet. Dieser Blockhash ist somit spezifisch für das Fahrzeugereignis, da der Hash basierend auf den Fahrzeugereignisdaten (oder den Fahrzeugzustandsinformationen, die mindestens einen Teil der Fahrzeugereignisdaten beinhalten) erzeugt wird; dieser Hash kann als ereignisspezifischer Blockchain-Hash bezeichnet werden. Der ereignisspezifische Blockchain-Hash kann dann an das Fahrzeug 12 zurückgemeldet und vom Fahrzeug 12 beim Komprimieren von Sichtdaten verwendet werden, wie beispielsweise beim Komprimieren von Bilddaten, die von den Kameras 42 oder Lidar 44 erhalten wurden.
  • Unter Bezugnahme auf 3 ist eine Ausführungsform eines Verfahrens 300 zum Erzeugen von Sichtdaten dargestellt, das mit einem auf einer Blockchain gespeicherten Blockchain-Hash eingebettet ist. In mindestens einer Ausführungsform wird das Verfahren 300 vom Fahrzeug 12 durchgeführt. Obwohl die Schritte des Verfahrens 300 als in einer bestimmten Reihenfolge durchgeführt beschrieben werden, wird hierdurch in Betracht gezogen, dass die Schritte des Verfahrens 300 in jeder geeigneten oder technisch realisierbaren Reihenfolge durchgeführt werden können, wie es von Fachleuten als sinnvoll erachtet wird.
  • In Schritt 310 wird das Fahrzeug als Teil einer geografischen Domäne registriert. In einer Ausführungsform registriert sich das Fahrzeug 12 beim Blockchain-Domänenserver 14 der geografischen Domäne 100. In mindestens einer Ausführungsform kann die Registrierung des Fahrzeugs 12 mit der Navigations-Domäne das Fahrzeug 12 beinhalten, das eine Verbindung mit dem Blockchain-Domänenserver 14 herstellt, Registrierungsinformationen an den Blockchain-Domänenserver 14 sendet, einen oder mehrere Hashs vom Blockchain-Domänenserver 14 als Reaktion auf eine erfolgreiche Registrierung des Fahrzeugs an der Blockchain 104 empfängt und die empfangenen Hashs auf einem oder mehreren VSMs des Fahrzeugs 12 speichert (z. B. der drahtlosen Kommunikationsvorrichtung 30, einem oder mehreren Sichtsensoren 42-46).
  • Zunächst kann sich das Fahrzeug 12 in mindestens einigen Ausführungsformen, wenn das Fahrzeug 12 in die geografische Domäne 100 eintritt, mit dem Blockchain-Domänenserver 14 verbinden, welcher der geografischen Domäne 100 zugeordnet ist. In einer Ausführungsform kann das Fahrzeug 12 die Mobilfunkkommunikation verwenden, um mit dem drahtlosen Kommunikationsmodul 92 des Blockchain-Domänenservers 14 zu kommunizieren, was die Verwendung eines Mobilfunkmastes oder einer anderen Hardware beinhalten kann, die Teil des Drahtlos-Trägersystems 70 ist. In weiteren Ausführungsformen kann das Fahrzeug 12 die drahtlose Nahbereichskommunikation (SRWCs) verwenden, um eine drahtlose Kommunikationsverbindung mit dem Blockchain-Domänenserver 14 herzustellen. Das Fahrzeug 12 und der Blockchain-Domänenserver 14 können eine sichere Verbindung unter Verwendung eines Handshake, wie beispielsweise eines Vierwege-Handshake, herstellen. Verbindungsinformationen können im Fahrzeug 12 und/oder dem Blockchain-Domänenserver 14 im Rahmen des Verbindungsaufbaus oder nach dem Verbindungsaufbau gespeichert werden.
  • In mindestens einigen Ausführungsformen sendet das Fahrzeug Registrierungsinformationen an den Blockchain-Domänenserver 14. Die Registrierungsinformationen können eine eindeutige Fahrzeugkennung (z. B. eine VIN, IMEI der Kommunikationsvorrichtung 30), ein Passwort oder andere geheime Informationen (z. B. ein digitales Zertifikat oder andere Authentifizierungsinformationen), Fahrzeugzustandsinformationen (z. B. Fahrzeugstandort) und/oder verschiedene andere Informationen beinhalten. In einer Ausführungsform können die Registrierungsinformationen eine oder mehrere vorherige geografische Domänen angeben, in denen sich das Fahrzeug 12 befand oder mit denen es registriert war. Der Blockchain-Domänenserver 14 kann dann die Fahrzeuganmeldeinformationen (z. B. die Fahrzeugkennung (oder den Benutzernamen), das Passwort oder das digitale Zertifikat) mit in der Datenbank 102 gespeicherten Informationen oder Informationen, die von der entfernten Einrichtung 80 über das Festnetz 76 (und/oder das Drahtlos-Trägersystem 70) empfangen wurden, überprüfen. Nach der Überprüfung kann der Blockchain-Domänenserver 14 einen neuen Transaktionseintrag (der Teil eines Blocks ist) oder einen neuen Block erstellen, welcher der Blockchain 104 hinzugefügt wird. Der Block, sobald er zum Einfügen in die Blockchain bereit ist, kann mit einer oder mehreren Hash-Funktionen (z. B. SHA-256, MD5) gehasht und an das Ende der Blockchain angehängt werden. Anschließend können ein oder mehrere Verifizierungsprozesse (z. B. Arbeitsnachweis, Einsatznachweis) verwendet werden, um das Einbringen des Blocks in die Blockchain 104 zu validieren. In einer Ausführungsform kann diese Überprüfung durch eine Vielzahl von Blockchain-Domänenservern 14, die Teil der geografischen Domäne 100 sind, durch eine Vielzahl von anderen Vorrichtungen, die Teil der geografischen Domäne 100 sind, oder durch eine Vielzahl von anderen Computervorrichtungen durchgeführt werden, die eine Kopie der Blockchain 104 beinhalten. Das Verfahren 300 fährt mit Schritt 320 fort.
  • In Schritt 320 empfängt das Fahrzeug einen Blockchain-Hash vom Blockchain-Domänenserver. Wie bereits erwähnt, kann der Blockchain-Domänenserver 14 nach erfolgreicher Überprüfung der Fahrzeuganmeldeinformationen (und/oder anderer Registrierungsinformationen) einen oder mehrere Hashs erzeugen. In einer Ausführungsform wird ein einzelner Hash (oder Registrierungshash) erzeugt, welcher der Fahrzeugregistrierung mit der geografischen Domäne 100 entspricht. Sobald das Fahrzeug 12 den Blockchain-Hash vom Blockchain-Domänenserver 14 empfängt, speichert das Fahrzeug 12 den Hash im Speicher. In einer Ausführungsform kann das Fahrzeug 12 den Hash im Speicher 38 der drahtlosen Kommunikationsvorrichtungen 30 speichern. Zusätzlich oder alternativ kann das Fahrzeug 12 den Hash an andere VSMs senden, wie beispielsweise die Sichtsensoren 42-46. Die anderen VSMs können dann den Hash in einer Speichervorrichtung speichern, beispielsweise in einer oder mehreren Speichervorrichtungen der Kameras 42 oder des Lidars 44. Das Verfahren 300 fährt mit Schritt 330 fort.
  • In Schritt 330 erfasst das Fahrzeug Sichtdaten. In einer Ausführungsform erfasst das Fahrzeug 12 Sichtdaten als Reaktion auf das Erkennen eines Fahrzeugereignisses. In weiteren Ausführungsformen erfasst das Fahrzeug 12 bereits Sichtdaten, wenn (und vor) dem Erkennen des Fahrzeugereignisses. In einer bestimmten Ausführungsform, in der das Fahrzeug 12 bereits Sichtdaten erfasst, wenn (und vor) dem Erkennen des Fahrzeugereignisses, kann das Fahrzeug 12 dann bestimmen, dass bestimmte erfasste Sichtdaten als Reaktion auf das Erkennen des Fahrzeugereignisses gespeichert und/oder aufbewahrt werden. So erfasst das Fahrzeug 12 beispielsweise in einer Ausführungsform Bilddaten (oder andere Sichtdaten) vor dem erkannten Fahrzeugereignis, hält diese erfassten Bilddaten (oder andere Sichtdaten) jedoch nur für eine vorbestimmte Zeitspanne (z. B. fünf Minuten) im Speicher, woraufhin die Bilddaten gelöscht werden, um Speicherplatz in der Speichervorrichtung zu schaffen. Nach dem Erkennen des Fahrzeugereignisses kann das Fahrzeug 12 jedoch bestimmen, dass es diese zwischengespeicherten Bilddaten (oder andere Sichtdaten) und andere Bilddaten (oder andere Sichtdaten), die nach dem Erkennen des Fahrzeugereignisses erfasst werden sollen, speichert.
  • In einer Ausführungsform kann die drahtlose Kommunikationsvorrichtung 30 (oder ein anderes VSM, wie beispielsweise ein VSM, welches das Fahrzeugereignis erkannt hat) einen Erfassungsbefehl an einen oder mehrere der Sichtsensoren 42-46 senden, der den Sichtsensor informiert, Sichtdaten zu erfassen (oder Sichtdaten, wie vorstehend beschrieben, zu speichern). Dieser Erfassungsbefehl kann als Reaktion auf das Erkennen des Fahrzeugereignisses erzeugt und/oder an die Sichtsensoren gesendet werden. Der Erfassungsbefehl kann den Registrierungshash beinhalten oder einen oder mehrere der Hashs angeben, die in die Bilddaten oder andere Sichtdaten aufgenommen werden sollen. In einer Ausführungsform kann das erkannte Fahrzeugereignis bestimmten Sichtsensoren 42-46 zugeordnet sein, und in diesem Fall wird ein Erfassungsbefehl nur an die zugehörigen Sichtsensoren gesendet. Das Verfahren 300 fährt mit Schritt 340 fort.
  • In Schritt 340 werden die erfassten Sichtdaten mit dem Blockchain-Hash eingebettet. In einer Ausführungsform ist der Blockchain-Hash der Registrierungshash. Die erfassten Sichtdaten können die Sichtdaten sein, die als Reaktion auf den Erfassungsbefehl erfasst wurden, und/oder die Daten, die als Reaktion auf den Erfassungsbefehl gespeichert wurden. In vielen Ausführungsformen liegen diese erfassten Sichtdaten in einem unkomprimierten oder „rohen“ Zustand vor, bevor die Kompression von Schritt 340 durchgeführt wird. Die Rohbilddaten beziehen sich auf Sichtdaten, die vom Sichtsensor erfasst werden und die unverarbeitet oder minimal vom Bildsensor verarbeitet werden; beispielsweise beziehen sich Rohbilddaten auf Bilddaten im Rohzustand und können in eine Rohbilddatei aufgenommen werden. Der Hash kann unter Verwendung einer Wasserzeichentechnik, wie sie vorstehend beschrieben wurde, in die erfassten Sichtdaten aufgenommen werden. In einer Ausführungsform kann diese Wasserzeichentechnik als Teil der Komprimierung oder anderweitigen Kodierung der Rohbilddaten in kodierte Sichtdaten durchgeführt werden. In anderen Ausführungsformen können die erfassten Sichtdaten vor Schritt 340 komprimiert/kodiert werden, und während Schritt 340 werden die eine oder die mehreren Hashs unter Verwendung der einen oder mehreren Wasserzeichen- oder Steganographietechniken (oder anderer Wasserzeichentechniken) in die kodierten Sichtdaten eingebettet. Wie vorstehend erwähnt, kann der Sichtsensor 42-46, der die Sichtdaten erfasst, die Sichtdaten kodieren, oder die Sichtdaten können von einem anderen VSM, wie beispielsweise der drahtlosen Kommunikationsvorrichtung 30, kodiert und/oder mit Wasserzeichen versehen werden. In einer Ausführungsform kann die Kodierung ausgeführt werden, während die Sichtdaten erfasst werden, oder sie kann Folgendes beinhalten: Abrufen der Sichtdaten aus dem Speicher (z. B. eine Speichervorrichtung der Kamera 42), Kodieren der abgerufenen Sichtdaten und dann die Sichtdaten mit einem Wasserzeichen versehen werden. In weiteren Ausführungsformen sind der Kodierungsschritt und der Wasserzeichenschritt integrierte Wasserzeichenkodierungstechnik. In einer weiteren Ausführungsform kann eine Wasserzeichentechnik an den Rohdaten und eine Kompressionstechnik an den wasserzeichenbehafteten Daten durchgeführt werden - wobei in derartigen Ausführungsformen eine verlustfreie Kompressionstechnik verwendet werden kann.
  • Eine oder mehrere der vorstehend in Bezug auf die Sichtsensoren 42-46 erläuterten Techniken können verwendet werden, um die Sichtdaten mit dem Blockchain-Hash mit einem Wasserzeichen zu versehen. In einigen Ausführungsformen können die Sichtsensoren 42-46 eine Vielzahl der Hashs in die Sichtdaten einbetten. Das Verfahren 300 fährt mit Schritt 350 fort.
  • In Schritt 350 werden die mit Wasserzeichen versehenen Sichtdaten an die entfernte Einrichtung gesendet. In einer Ausführungsform werden die mit Wasserzeichen versehenen Sichtdaten über das Drahtlos-Trägersystem 70 und das Festnetz 76 direkt an die entfernte Einrichtung gesendet, d. h. die mit Wasserzeichen versehenen Sichtdaten werden an die entfernte Einrichtung gesendet, ohne über den Blockchain-Domänenserver 14 übermittelt zu werden. In einer weiteren Ausführungsform werden die mit Wasserzeichen versehenen Sichtdaten über den Blockchain-Domänenserver 14 an die entfernte Einrichtung gesendet. Und in mindestens einer Ausführungsform werden die mit Wasserzeichen versehenen Sichtdaten an den Blockchain-Domänenserver 14 gesendet, der dann die mit Wasserzeichen versehenen Sichtdaten aufzeichnet. So können beispielsweise die mit Wasserzeichen versehenen Sichtdaten in einen Block der Blockchain 104 oder als Teil einer anderen Blockchain aufgenommen werden. In einer weiteren Ausführungsform können die mit Wasserzeichen versehenen Sichtdaten in einer Datenbank 102 gespeichert werden. Die mit Wasserzeichen versehenen Sichtdaten können zusammen mit einer Datendarstellung des eingebetteten Hash und/oder anderen verwandten Informationen, wie beispielsweise einer Ereignis- oder Registrierungskennung, gespeichert werden. Die mit Wasserzeichen versehenen Sichtdaten können (auch oder alternativ) in der Datenbank 84 der entfernten Einrichtung 80 gespeichert werden.
  • Somit werden die gespeicherten mit Wasserzeichen versehenen Sichtdaten einer Transaktion (oder Eingabe) auf der Blockchain (z. B. der Blockchain 104) zugeordnet. Diese Transaktion auf der Blockchain beinhaltet den eingebetteten Hash(s) (oder Informationen, aus denen der eingebettete Hash(s) abgeleitet werden kann), und daher kann die Transaktion auf der Blockchain verwendet werden, um die Authentizität der mit Wasserzeichen versehenen Sichtdaten zu validieren oder zu überprüfen, indem der eingebettete Hash(s) mit dem Hash(s) der Transaktion (d. h. dem in der Blockchain gespeicherten Hash(s)) verglichen wird. Auf diese Weise können zumindest in einigen Ausführungsformen die eingebetteten Hash(s) der mit Wasserzeichen versehenen Sichtdaten verwendet werden, um die Sichtdaten (z. B. Bilddaten) mit bestimmten Fahrzeugregistrierungen, die in der Blockchain erfasst sind, zu vergleichen und zu validieren. Das Verfahren 300 endet dann.
  • Unter Bezugnahme auf 4 ist eine Ausführungsform eines Verfahrens 400 zum Erzeugen von Sichtdaten dargestellt, das mit einem auf einer Blockchain gespeicherten Blockchain-Hash eingebettet ist. In mindestens einer Ausführungsform wird das Verfahren 400 vom Fahrzeug 12 durchgeführt. Obwohl die Schritte des Verfahrens 400 als in einer bestimmten Reihenfolge durchgeführt beschrieben werden, wird hierdurch in Betracht gezogen, dass die Schritte des Verfahrens 400 in jeder geeigneten oder technisch realisierbaren Reihenfolge durchgeführt werden können, wie es von Fachleuten als sinnvoll erachtet wird.
  • In Schritt 410 erkennt das Fahrzeug das Auftreten eines Fahrzeugereignisses. Eine Vielzahl von Fahrzeugereignissen kann durch eine oder mehrere Bedingungen in Bezug auf Fahrzeugzustände vorgegeben werden, die beispielsweise einen Fahrzeugumgebungszustand beinhalten können. In einer Ausführungsform kann der aktuelle Fahrzeugzustand durch Auswerten eines oder mehrerer Sensormesswerte von einem oder mehreren fahrzeugseitigen Sensoren, wie vorstehend beschrieben, bestimmt werden. Darüber hinaus kann der Fahrzeugzustand in einigen Ausführungsformen (zumindest teilweise) auf Umgebungsinformationen und/oder Informationen beruhen, die von anderen externen Vorrichtungen empfangen werden (z. B. der entfernten Einrichtung 80, dem Blockchain-Domänenserver 14, anderen Fahrzeugen). Das Fahrzeug 12 erkennt das Eintreten eines Fahrzeugereignisses, wenn das Fahrzeug 12 bestimmt, dass der aktuelle Fahrzeugzustand mit einem vordefinierten Fahrzeugereigniszustand übereinstimmt oder diesem entspricht. In einigen Fällen kann das Fahrzeug 12 gleichzeitig das Auftreten einer Vielzahl von Fahrzeugereignissen erkennen. Das Verfahren 400 fährt mit Schritt 420 fort.
  • In Schritt 420 erfasst das Fahrzeug Sichtdaten. In einer Ausführungsform erfasst das Fahrzeug 12 Sichtdaten als Reaktion auf das Erkennen des Fahrzeugereignisses. In weiteren Ausführungsformen erfasst das Fahrzeug 12 bereits Sichtdaten, wenn (und vor) dem Erkennen des Fahrzeugereignisses. In einer bestimmten Ausführungsform, in der das Fahrzeug 12 bereits Sichtdaten erfasst, wenn (und vor) dem Erkennen des Fahrzeugereignisses, kann das Fahrzeug 12 dann bestimmen, dass bestimmte erfasste Sichtdaten als Reaktion auf das Erkennen des Fahrzeugereignisses gespeichert und/oder aufbewahrt werden. So erfasst das Fahrzeug 12 beispielsweise in einer Ausführungsform Bilddaten (oder andere Sichtdaten) vor dem erkannten Fahrzeugereignis, hält diese erfassten Bilddaten (oder andere Sichtdaten) jedoch nur für eine vorbestimmte Zeitspanne (z. B. fünf Minuten) im Speicher, woraufhin die Bilddaten gelöscht werden, um Speicherplatz in der Speichervorrichtung zu schaffen. Nach dem Erkennen des Fahrzeugereignisses kann das Fahrzeug 12 jedoch bestimmen, dass es diese zwischengespeicherten Bilddaten (oder andere Sichtdaten) und andere Bilddaten (oder andere Sichtdaten), die nach dem Erkennen des Fahrzeugereignisses erfasst werden sollen, speichert. Das Verfahren 400 fährt mit Schritt 430 fort.
  • In Schritt 430 sendet das Fahrzeug Ereignisdaten an den Blockchain-Domänenserver. In einer Ausführungsform kann das Fahrzeug 12, sobald das Fahrzeug das Auftreten eines Fahrzeugereignisses erkennt, eine Fahrzeugereignismeldung erzeugen, die Ereignisdaten beinhaltet. Die Fahrzeug-Ereignisdaten können Fahrzeugzustandsinformationen, einen Ereignistyp, Registrierungsinformationen (z. B. ein oder mehrere Hashs, die Sitzungsinformationen), mindestens einen Zeitstempel (oder eine andere Zeitanzeige) (z. B. den Zeitpunkt des erkannten Fahrzeugereignisses, den Zeitpunkt der Erstellung des Fahrzeug-Ereignisberichts), Fahrzeugidentifizierungsinformationen (z. B. eindeutige Identifikatoren (MAC-Adressen) des Sichtsensors, VIN des Fahrzeugs) und/oder verschiedene andere Informationen beinhalten. Die Fahrzeugzustandsinformationen können Fahrzeugstandortinformationen (z. B. Standort, Trajektorie, projektierte/geschätzte Route oder Weg, vorherige Standortinformationen), Fahrzeugbetriebsinformationen (z. B. Zündstatus, Gangstatus, Raddrehzahl, Motortemperatur, Lenkradwinkel, Kilometerstand, Motordrehzahl), weitere Fahrzeuginformationen (z. B. Anzahl und/oder Identität der Fahrgäste) und Umgebungsinformationen (z. B. Verkehrsbedingungen, andere nahegelegene Fahrzeuge (einschließlich ihrer Identität, die beispielsweise über die Kommunikation zwischen Fahrzeugen (V2V) bestimmt werden kann), Beschilderung, Vorhandensein von Objekten, die über Bilderkennungstechniken erfasst wurden, andere Informationen über erfasste Bilddaten oder andere Sichtdaten).
  • In einer Ausführungsform kann die Fahrzeug-Ereignismeldung (und/oder die Ereignisdaten selbst) sichtbezogene Daten beinhalten, die zu oder um einen Zeitpunkt des Ereignisses erfasst werden, wie beispielsweise einen Zeitraum, der vor dem Ereignis beginnt. Diese sichtbezogenen Daten können mindestens ein Teil von Bilddaten (oder anderen Sichtdaten) sein, die von einem oder mehreren Sichtsensoren am Fahrzeug 12 erfasst werden. Oder die sichtbezogenen Daten können auch andere Daten beinhalten, die mit den Sichtdaten in Beziehung stehen, wie beispielsweise Metadaten der erfassten Sichtdaten. In einer weiteren Ausführungsform können die sichtbezogenen Daten auch Daten sein, die ein Wasserzeichen darstellen, das in die Bilddaten eingebettet ist, wie beispielsweise durch die Verwendung eines Wasserzeichenalgorithmus. Die im Wasserzeichen dargestellten Daten können in die Meldung über den Fahrzeugereignisbericht aufgenommen werden, die an den Blockchain-Domänenserver 14 gesendet werden kann. Der Blockchain-Domänenserver 14 kann diese sichtbezogenen Daten in eine ereignisspezifische Transaktion einbinden, die in der Blockchain aufgezeichnet wird. Aus diesen sichtbezogenen Daten kann dann der Blockchain-Hash erzeugt werden. Das Verfahren 400 fährt dann mit Schritt 440 fort.
  • In Schritt 440 empfängt das Fahrzeug einen Blockchain-Hash. In einer Ausführungsform ist der Blockchain-Hash ein ereignisspezifischer Hash. Sobald beispielsweise der Blockchain-Domänenserver 14 die Meldung über den Fahrzeugereignisbericht empfängt, kann der Blockchain-Domänenserver 14 eine ereignisspezifische Transaktion erzeugen, die in einen Block aufgenommen werden soll, oder einen neuen Block erzeugen, welcher der Blockchain 104 hinzugefügt werden soll; im letzteren Fall wird für jede ereignisspezifische Transaktion ein Block erzeugt. Als Teil des Hinzufügens dieses Blocks (der die ereignisspezifische Transaktion beinhaltet) zur Blockchain wird ein ereignisspezifischer Hash basierend auf dem Block oder zumindest einigen im Block enthaltenen Fahrzeuginformationen erzeugt. Der ereignisspezifische Hash wird dann an das Fahrzeug 12 gesendet, das den Hash im Speicher 38 (oder einem anderen Speicher) speichern und/oder den Hash auf eines oder mehrere VSMs verteilen kann. Das Verfahren 400 fährt mit Schritt 450 fort.
  • In Schritt 450 werden die erfassten Sichtdaten mit dem Blockchain-Hash eingebettet. In einer Ausführungsform können die erfassten Sichtdaten die Sichtdaten sein, die als Reaktion auf den Erfassungsbefehl erfasst wurden, und/oder die Daten, die als Reaktion auf den Erfassungsbefehl gespeichert wurden. In vielen Ausführungsformen liegen diese erfassten Sichtdaten in einem unkomprimierten oder „rohen“ Zustand vor, bevor die Kompression von Schritt 450 durchgeführt wird. Der Hash kann unter Verwendung einer Wasserzeichentechnik, wie sie vorstehend beschrieben wurde, in die erfassten Sichtdaten aufgenommen werden. In einer Ausführungsform kann diese Wasserzeichentechnik als Teil der Komprimierung der rohen Sichtdaten in komprimierte Sichtdaten durchgeführt werden. In anderen Ausführungsformen können die erfassten Sichtdaten vor Schritt 450 komprimiert werden, und während Schritt 450 werden die eine oder die mehreren Hashs unter Verwendung der einen oder mehreren Wasserzeichen- oder Steganographietechniken (oder anderer Wasserzeichentechniken) in die komprimierten Sichtdaten eingebettet. Jede der anderen vorstehend beschriebenen Wasserzeichentechniken, wie beispielsweise in Bezug auf Schritt 340 (3), kann ebenfalls verwendet werden. Das Verfahren 400 fährt mit Schritt 460 fort.
  • In Schritt 460 werden die mit Wasserzeichen versehenen Sichtdaten an die entfernte Einrichtung gesendet. In einer Ausführungsform werden die mit Wasserzeichen versehenen Sichtdaten über das Drahtlos-Trägersystem 70 und das Festnetz 76 direkt an die entfernte Einrichtung gesendet, d. h. die mit Wasserzeichen versehenen Sichtdaten werden an die entfernte Einrichtung gesendet, ohne über den Blockchain-Domänenserver 14 übermittelt zu werden. In einer weiteren Ausführungsform werden die mit Wasserzeichen versehenen Sichtdaten über den Blockchain-Domänenserver 14 an die entfernte Einrichtung gesendet. Wie vorstehend erwähnt, können die mit Wasserzeichen versehenen Sichtdaten als Reaktion auf (oder in Verbindung mit) einem bestimmten Fahrzeugereignis und/oder von einem bestimmten Fahrzeug (oder Sichtsensor) erfasst überprüft werden. Außerdem können, wie bereits erwähnt, verschiedene Informationen, wie beispielsweise Fahrzeugzustandsinformationen, auf der Blockchain gespeichert werden, mit denen bestimmte Aspekte der mit Wasserzeichen versehenen Sichtdaten, wie der Standort des Fahrzeugs, der Zeitpunkt der Ereignis- oder Sichtdatenerfassung oder andere Fahrzeugzustands- oder Umgebungsinformationen, überprüft werden können. Somit werden die gespeicherten mit Wasserzeichen versehenen Sichtdaten einer ereignisspezifischen Transaktion (oder Eingabe) auf der Blockchain (z. B. der Blockchain 104) zugeordnet. Diese ereignisspezifische Transaktion auf der Blockchain beinhaltet den eingebetteten Hash(s) (oder Informationen, aus denen der eingebettete Hash(s) abgeleitet werden kann) und die ereignisspezifischen Daten, die vom Fahrzeug empfangen wurden (z. B. zusammen mit einem Zeitstempel). Daher kann die Transaktion auf der Blockchain verwendet werden, um die Authentizität der mit Wasserzeichen versehenen Sichtdaten zu validieren oder zu überprüfen, indem die eingebetteten Hash(s) mit den Hash(s) der ereignisspezifischen Transaktion (d. h. der in der Blockchain gespeicherten Hash(s)) verglichen werden.
  • In einer Ausführungsform kann das Verfahren 300, das Verfahren 400 und/oder Teile davon in einem Computerprogrammprodukt (oder einer „Anwendung“ oder „Skript“) implementiert werden, das in einem computerlesbaren Medium verkörpert ist und Anweisungen beinhaltet, die von einem oder mehreren Prozessoren eines oder mehrerer Computer eines oder mehrerer Systeme verwendet werden können (z. B. ausführbar). Das/die Computerprogramm(e) können ein oder mehrere Softwareprogramme beinhalten, die aus Programmanweisungen im Quellcode, Objektcode, ausführbarem Code oder anderen Formaten bestehen. In einer Ausführungsform kann jedes oder mehrere der Computerprogramme ein oder mehrere Firmwareprogramme und/oder Hardwarebeschreibungssprache-(HDL)-Dateien beinhalten. Des Weiteren können die Computerprogramme jeweils mit programmbezogenen Daten verknüpft werden und in einigen Ausführungsformen können die Computerprogramme mit den programmbezogenen Daten verpackt werden. Die programmbezogenen Daten können Datenstrukturen, Nachschlagetabellen, Konfigurationsdateien, Zertifikate oder andere relevante Daten beinhalten, die in einem anderen geeigneten Format dargestellt werden. Die Programmanweisungen können Programmmodule, Routinen, Programme, Funktionen, Vorgänge, Verfahren, Objekte, Komponenten und/oder dergleichen beinhalten. Das/die Computerprogramm(e) können auf einem oder mehreren Computern (oder VSMs) ausgeführt werden, beispielsweise auf mehreren Computern (oder VSMs), die miteinander in Verbindung stehen.
  • Das/die Computerprogramm(e) können in computerlesbaren Medien (z. B. Speicher eines oder mehrerer Server in der entfernten Einrichtung 80, Speicher 38 der drahtlosen Kommunikationsvorrichtung 30, Speicher eines oder mehrerer Sichtsensoren 42-46, Speicher 96 des Blockchain-Domänenservers 14) ausgeführt werden, die nicht-flüchtig sein können und eine oder mehrere Speichervorrichtungen, Herstellungsgegenstände oder dergleichen beinhalten können. Zu den Beispielen für computerlesbare Medien gehören Systemspeicher von Computern, z. B. RAM (Speicher mit wahlfreiem Zugriff), ROM (Nur-Lese-Speicher); Halbleiterspeicher, z. B. EPROM (löschbarer, programmierbarer ROM), EEPROM (elektrisch löschbarer, programmierbarer ROM), Flash-Speicher; magnetische oder optische Platten oder Bänder; und/oder dergleichen. Ein computerlesbares Medium kann außerdem Verbindungen von Rechner zu Rechner beinhalten, wenn beispielsweise Daten über ein Netzwerk oder eine andere Kommunikationsverbindung (drahtgebunden, drahtlos oder in einer Kombination von beiden) übertragen oder bereitgestellt werden. Sämtliche Kombinationen aus den vorstehenden Beispielen fallen ebenfalls in den Umfang der computerlesbaren Medien. Es versteht sich daher, dass das Verfahren zumindest teilweise durch elektronische Artikel und/oder Geräte ausgeführt werden kann, die Anweisungen gemäß eines oder mehrerer Schritte des offenbarten Verfahrens ausführen können.
  • Es versteht sich, dass das Vorstehende eine Beschreibung einer oder mehrerer Ausführungsformen der Erfindung ist. Die Erfindung ist nicht auf die besondere(n) hierin offenbarte(n) Ausführungsform(en) beschränkt, sondern ausschließlich durch die folgenden Patentansprüche definiert. Darüber hinaus beziehen sich die in der vorstehenden Beschreibung gemachten Aussagen auf bestimmte Ausführungsformen und sind nicht als Einschränkungen des Umfangs der Erfindung oder der Definition der in den Patentansprüchen verwendeten Begriffe zu verstehen, außer dort, wo ein Begriff oder Ausdruck ausdrücklich vorstehend definiert wurde. Verschiedene andere Ausführungsformen und verschiedene Änderungen und Modifikationen an der/den ausgewiesenen Ausführungsform(en) sind für Fachleute offensichtlich. Alle diese anderen Ausführungsformen, Änderungen und Modifikationen sollten im Geltungsbereich der angehängten Patentansprüche verstanden werden.
  • Wie in dieser Spezifikation und den Patentansprüchen verwendet, sind die Begriffe „z. B.“, „beispielsweise“, „zum Beispiel“, „wie z. B.“ und „wie“ und die Verben „umfassend“, „einschließend“ „aufweisend“ und deren andere Verbformen, wenn sie in Verbindung mit einer Auflistung von einer oder mehreren Komponenten oder anderen Elementen verwendet werden, jeweils als offen auszulegen, was bedeutet, dass die Auflistung andere zusätzliche Komponenten oder Elemente nicht ausschließt. Andere Begriffe sind in deren weitesten vernünftigen Sinn auszulegen, es sei denn, diese werden in einem Kontext verwendet, der eine andere Auslegung erfordert. Zusätzlich versteht sich der Ausdruck „und/oder“ als ein inklusives ODER. Somit ist der Ausdruck „A, B, und/oder C“ beispielsweise so zu verstehen, dass die folgenden Möglichkeiten abgedeckt werden: „A“; „B“; „C“; „A und B“; „A und C“; „B und C“ und „A, Bund C“.

Claims (9)

  1. Verfahren zum Erzeugen von Sichtdaten, die mit einem auf einer Blockchain gespeicherten Blockchain-Hash eingebettet sind, wobei das Verfahren Folgendes umfasst: Erkennen eines Fahrzeugereignisses an einem Fahrzeug unter Verwendung der im Fahrzeug enthaltenen Fahrzeugelektronik; Senden einer Fahrzeugereignismeldung an einen Blockchain-Domänenserver als Reaktion auf das erkannte Fahrzeugereignis, wobei die Fahrzeugereignismeldung Informationen über das erkannte Fahrzeugereignis beinhaltet, und worin der Blockchain-Domänenserver konfiguriert ist, das erkannte Fahrzeugereignis als Teil einer Blockchain basierend auf der Fahrzeugereignismeldung aufzuzeichnen; Empfangen eines Blockchain-Hashes am Fahrzeug vom Blockchain-Domänenserver; und Einbetten des Blockchain-Hashes in Sichtdaten am Fahrzeug unter Verwendung der Fahrzeugelektronik, worin die Sichtdaten von einem Sichtsensor erfasst werden, der am Fahrzeug angebracht und als Teil der Fahrzeugelektronik aufgenommen ist.
  2. Verfahren nach Anspruch 1, worin der Blockchain-Hash ein ereignisspezifischer Hash ist, der am Blockchain-Domänenserver als Teil der Aufzeichnung des erfassten Fahrzeugereignisses am Blockchain-Domänenserver erzeugt wird, und worin der Blockchain-Hash als Reaktion auf das Aufzeichnen des erkannten Fahrzeugereignisses am Blockchain-Domänenserver empfangen wird.
  3. Verfahren nach Anspruch 1, ferner umfassend den Schritt des Registrierens des Fahrzeugs bei einem Blockchain-Domänenserver als Reaktion auf das Fahrzeug, das sich einer dem Blockchain-Domänenserver zugeordneten geografischen Domäne nähert oder diese betritt.
  4. Verfahren nach Anspruch 1, worin die Sichtdaten Bilddaten sind und worin der Blockchain-Hash in die Bilddaten eingebettet ist, durch Wasserzeichen der Bilddaten unter Verwendung einer reversiblen Steganographietechnik, sodass alle oder im Wesentlichen alle in den Bilddaten vor dem Wasserzeichen dargestellten Daten erhalten bleiben, nachdem die Bilddaten mit dem Blockchain-Hash mit Wasserzeichen versehen wurden.
  5. Verfahren nach Anspruch 1, worin die Sichtdaten Bilddaten sind, die von einem Bildsensor erfasst werden, der als Teil der Fahrzeugelektronik integriert ist, und worin der Bildsensor den Blockchain-Hash auf die Bilddaten aufbringt, während er die Bilddaten unter Verwendung eines Codecs codiert.
  6. Verfahren nach Anspruch 1, worin der Blockchain-Hash ein Hash ist, der durch Ausführen einer Hashfunktion unter Verwendung von Informationen, die in einem Block der Blockchain als Eingabe enthalten sind, erzeugt wird.
  7. Verfahren nach Anspruch 6, worin der Blockchain-Domänenserver konfiguriert ist, um den Block der Blockchain unter Verwendung von Ereignisdaten, die in der Fahrzeugereignismeldung empfangen werden, zu erzeugen.
  8. Verfahren zum Erzeugen von Sichtdaten, die mit einem auf einer Blockchain gespeicherten Blockchain-Hash eingebettet sind, wobei das Verfahren Folgendes umfasst: Registrieren eines Fahrzeugs bei einem Blockchain-Domänenserver als Reaktion auf das Fahrzeug, das sich einer dem Blockchain-Domänenserver zugeordneten geografischen Domäne nähert oder diese betritt; Empfangen eines Blockchain-Hash am Fahrzeug vom Blockchain-Domänenserver, worin der Blockchain-Domänenserver konfiguriert ist, um vom Fahrzeug empfangene Informationen in einer Blockchain aufzuzeichnen, und worin der Blockchain-Hash durch Ausführen einer Hashfunktion unter Verwendung von Informationen, die in einer der Blockchain als Eingabe hinzugefügt werden soll, erzeugt wird, und Einbetten des Blockchain-Hash in Sichtdaten, die am Fahrzeug unter Verwendung der Fahrzeugelektronik erfasst werden, worin die Sichtdaten von einem Sichtsensor erfasst werden, der am Fahrzeug angebracht und als Teil der Fahrzeugelektronik enthalten ist.
  9. Verfahren nach Anspruch 8, ferner umfassend den Schritt des Erfassens eines Fahrzeugereignisses am Fahrzeug unter Verwendung einer im Fahrzeug enthaltenen Fahrzeugelektronik, worin die Sichtdaten Bilddaten sind und der Sichtsensor ein Bildsensor ist, und worin der Einbettungsschritt das Wasserzeichen jedes einer Anzahl von Einzelbildern
DE102019113185.5A 2018-06-18 2019-05-17 Einbettung von blockchain-informationen in digitale bilder Pending DE102019113185A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/011,348 2018-06-18
US16/011,348 US10628906B2 (en) 2018-06-18 2018-06-18 Embedding blockchain information in digital images

Publications (1)

Publication Number Publication Date
DE102019113185A1 true DE102019113185A1 (de) 2019-12-19

Family

ID=68724845

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102019113185.5A Pending DE102019113185A1 (de) 2018-06-18 2019-05-17 Einbettung von blockchain-informationen in digitale bilder

Country Status (3)

Country Link
US (1) US10628906B2 (de)
CN (1) CN110619592B (de)
DE (1) DE102019113185A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021123970A1 (de) 2021-09-16 2023-03-16 Audi Aktiengesellschaft Nutzerauthentifizierung mittels fahrzeugbezogener Daten

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10977493B2 (en) 2018-01-31 2021-04-13 ImageKeeper LLC Automatic location-based media capture tracking
GB201811263D0 (en) * 2018-07-10 2018-08-29 Netmaster Solutions Ltd A method and system for managing digital using a blockchain
US11442926B2 (en) * 2018-09-05 2022-09-13 Nhn Corporation Method and system for storing driving record data based on block chain
US10752207B2 (en) * 2018-09-07 2020-08-25 Ford Global Technologies, Llc Multi-factor authentication of a hardware assembly
US11501483B2 (en) 2018-12-10 2022-11-15 ImageKeeper, LLC Removable sensor payload system for unmanned aerial vehicle performing media capture and property analysis
US11550928B2 (en) * 2019-01-11 2023-01-10 Combined Conditional Access Development And Support, Llc Distributed ledger-based digital content tracing
US11238478B2 (en) * 2019-01-25 2022-02-01 Toyota Motor North America, Inc. Commercializing user patterns via blockchain
US11093628B2 (en) * 2019-02-14 2021-08-17 International Business Machines Corporation Cross-domain content-lifecycle management
DE102019001100A1 (de) * 2019-02-14 2020-08-20 Daimler Ag Verfahren zur Überwachung einer Funktionalität eines Fahrzeuginformationssystems eines Kraftfahrzeugs, sowie elektronische Recheneinrichtung, Computerprogramm und Datenträger
US11628788B2 (en) * 2019-03-25 2023-04-18 Micron Technology, Inc. Vehicle accident management using peer-to-peer networks and systems
US11397814B2 (en) * 2019-03-25 2022-07-26 Micron Technology, Inc. Local ledger block chain for secure electronic control unit updates
US10839682B1 (en) * 2019-04-26 2020-11-17 Blackberry Limited Method and system for traffic behavior detection and warnings
SG11202002100TA (en) * 2019-05-20 2020-04-29 Alibaba Group Holding Ltd Copyright protection based on hidden copyright information
US11044580B2 (en) * 2019-06-10 2021-06-22 Ford Global Technologies, Llc Systems and method for potentially enhanced vehicle safety for passengers using blockchain
US11783697B2 (en) * 2019-06-13 2023-10-10 Here Global B.V. Method, apparatus, and system for ensuring privacy while maintaining floating car data accuracy
US11812451B2 (en) * 2019-06-25 2023-11-07 Ford Global Technologies, Llc Vehicle component usage
US11088828B2 (en) 2019-07-18 2021-08-10 Advanced New Technologies Co., Ltd. Blockchain-based data evidence storage method and apparatus
US11838400B2 (en) * 2019-11-19 2023-12-05 International Business Machines Corporation Image encoding for blockchain
CN113254947B (zh) * 2020-02-13 2023-04-14 宁波吉利汽车研究开发有限公司 一种车辆数据保护方法、系统、设备和存储介质
CN111583447B (zh) * 2020-04-30 2023-03-24 深圳市元征科技股份有限公司 事故车辆信息记录方法及相关装置
EP3934222A1 (de) * 2020-06-30 2022-01-05 Basf Se Verfahren zum aufbau einer blockchain
US20230237479A1 (en) * 2020-06-30 2023-07-27 Basf Se A method for building a blockchain
US12017649B2 (en) * 2020-09-25 2024-06-25 Ford Global Technologies, Llc Blockchain system to aid vehicle actions
CN112905667A (zh) * 2021-03-08 2021-06-04 黑芝麻智能科技(上海)有限公司 无人驾驶信息存储和回放方法、装置及存储介质
CN113382204A (zh) * 2021-05-22 2021-09-10 特斯联科技集团有限公司 一种消防隐患智能处理方法和装置
CN114724368B (zh) * 2022-03-31 2023-04-25 海南龙超信息科技集团有限公司 智慧城市交通管理系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8639234B2 (en) * 2008-03-31 2014-01-28 General Motors Llc System and method for processing vehicle communications
US9659499B2 (en) * 2008-12-22 2017-05-23 General Motors Llc Method of communicating vehicle messages using short message system messages
US9501875B2 (en) * 2013-10-31 2016-11-22 GM Global Technology Operations LLC Methods, systems and apparatus for determining whether any vehicle events specified in notification preferences have occurred
US10732621B2 (en) * 2016-05-09 2020-08-04 Strong Force Iot Portfolio 2016, Llc Methods and systems for process adaptation in an internet of things downstream oil and gas environment
US10284654B2 (en) * 2016-09-27 2019-05-07 Intel Corporation Trusted vehicle telematics using blockchain data analytics
CA2943762C (en) * 2016-09-30 2022-05-03 The Toronto-Dominion Bank Automated implementation of provisioned services based on captured sensor data
US20180108189A1 (en) * 2016-10-13 2018-04-19 General Motors Llc Telematics-based vehicle value reports
US10176309B2 (en) * 2016-10-28 2019-01-08 Acronis International Gmbh Systems and methods for authenticating video using watermarks
US10611474B2 (en) * 2017-03-20 2020-04-07 International Business Machines Corporation Unmanned aerial vehicle data management
GB2562054A (en) * 2017-05-02 2018-11-07 Bitbond Ltd Automotive electronic blockchain information system - AEBIS
CN107945090A (zh) * 2017-11-30 2018-04-20 深圳市轱辘车联数据技术有限公司 基于区块链的车辆尾气数据分析方法、装置及服务器

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021123970A1 (de) 2021-09-16 2023-03-16 Audi Aktiengesellschaft Nutzerauthentifizierung mittels fahrzeugbezogener Daten
WO2023041210A1 (de) 2021-09-16 2023-03-23 Audi Ag Nutzerauthentifizierung mittels fahrzeugbezogener daten
DE102021123970B4 (de) 2021-09-16 2023-04-20 Audi Aktiengesellschaft Nutzerauthentifizierung mittels fahrzeugbezogener Daten

Also Published As

Publication number Publication date
US10628906B2 (en) 2020-04-21
CN110619592B (zh) 2023-07-18
US20190385269A1 (en) 2019-12-19
CN110619592A (zh) 2019-12-27

Similar Documents

Publication Publication Date Title
DE102019113185A1 (de) Einbettung von blockchain-informationen in digitale bilder
DE102017121076B4 (de) Verfahren zum Identifizieren eines Zielfahrzeugs unter Verwendung von Anwendungssoftware auf einer mobilen Vorrichtung
DE102013203357B4 (de) Verfahren zum herstellen einer kommunikation zwischen einrichtungen in einem fahrzeug
DE102016101327B4 (de) Verfahren zum Reagieren auf einen nicht autorisierten elektronischen Zugriff auf ein Fahrzeug
DE102019114720A1 (de) Erweiterte realität (augmented reality - ar) entfernte fahrzeugassistenz
DE102015100606B4 (de) Verfahren zum verwalten von drahtlosen nahbereichsverbindungen zwischen einer primären drahtlosen einrichtung und mehreren sekundären drahtlosen einrichtungen
DE102018129843A1 (de) Einrichten einer sicheren drahtlosen Nahbereichs-Kommunikationsverbindung an einem Fahrzeug
DE102018130216A1 (de) Fahrzeugkommunikation unter Verwendung eines Publish-Subscribe-Messaging-Protokolls
DE102018100153B4 (de) Verfahren und system zur fernbetätigten änderung von informationen für eine geräteaktivierungsübertragung
DE102015103550A1 (de) Sichern von elektronischen steuereinheiten unter verwendung von nachrichtenauthentifizierungscodes
DE102015101044B4 (de) Fahrzeugtelematik-Suchratensteuerung
DE102018113258A1 (de) Fahrzeugortung und -führung
DE102019113709A1 (de) Lidar-objekterkennung und datenkommunikation
DE102018113058A1 (de) Verwaltung einer drahtlosen geräteverbindung
DE102012222435B4 (de) Verfahren zum Übertragen und Authentifizieren von SMS-Nachrichten, die zwischen einem Fahrzeug und einer zentralen Einrichtung gesendet werden
DE102014118306A1 (de) Verarbeitung sicherer SMS-Nachrichten
DE102019107797A1 (de) FAHRZEUGPROGNOSEN UND ABHILFEMAßNAHMEN
DE102019111576A1 (de) System und verfahren zur übertragung von in der warteschlange befindlichen over-the-air-software-updates
DE102018123488A1 (de) Strahlenbündelung basierend auf lokalisierungsmodulinformationen
DE102019115033A1 (de) Benutzerdefinierte kraftfahrzeugbenachrichtigung
DE102018111813A1 (de) Aktualisieren der fahrzeuguhr
DE102019105451A1 (de) Durchführung von entfernten Fahrzeugbefehlen und Verwendung einer Live-Kameraüberwachung
DE102018128286A1 (de) Fahrzeugführung basierend auf dem räumlichen modell des standorts
DE102017119451A1 (de) Verfahren zum Telematikkonnektivitätsmanagement
DE102019115675A1 (de) Aktualisieren von fahrzeugelektronik basierend auf der kompatibilität mit einer mobilen vorrichtung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: MANITZ FINSTERWALD PATENT- UND RECHTSANWALTSPA, DE

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0016580000

Ipc: G06F0021640000