DE102019120937A1

DE102019120937A1 - Verfahren und vorrichtung zum bereitstellen von kartenaktualisierungen unter verwendung einer blockchainplattform

Info

Publication number: DE102019120937A1
Application number: DE102019120937.4A
Authority: DE
Inventors: Justyna Zander
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2018-08-02
Filing date: 2019-08-02
Publication date: 2020-02-06
Also published as: US11703348B2; US20230314168A1; US20210124369A1; US20200042012A1; US10915115B2; CN110795439A

Abstract

Eine halböffentliche Blockchain, die auf einem oder mehreren Knoten in einer Karten-Cloudplattform unterhalten wird, umfasst Daten zum Unterhalt einer globalen Karte eines vorbestimmten geografischen Bereichs. Die Blockchain umfasst auch eine Vielzahl von Datensätzen, wobei jeder Datensatz im Zusammenhang mit einer Aktualisierung einer globalen Karte steht. Wenn eine im Zusammenhang mit einer Kartenaktualisierung für die globale Karte stehende Nachricht empfangen wird, bestimmen die Knoten der Blockchain einen Konsens durch Auswertung der Kartenaktualisierung, wobei die Auswertung das Durchführen einer Vielzahl von Nachweisen umfasst, einschließlich eines Ortsnachweises, eines Wiederholungsnachweises, eines Nachweises einer physischen Lieferung und eines Sicherheitsnachweises. Wenn ein Konsens erzielt wurde und die Kartenaktualisierung validiert ist, wird ein mit der Kartenaktualisierung in Zusammenhang stehender Datensatz erzeugt und der Blockchain mit einem Zeitstempel und einer Verknüpfung zu früheren Datensätzen in der Blockchain hinzugefügt.

Description

BEREICH DER ERFINDUNG
Diese vorliegende Erfindung bezieht sich ganz allgemein auf Verfahren zur Durchführung von elektronischen Kartenaktualisierungen in autonomen Fahrzeugen. Konkret zielt die vorliegende Erfindung auf eine Lösung zur weltweiten Bereitstellung und Validierung von Kartenaktualisierungen für autonome Fahrzeuge mittels Blockchain-Technologie ab.
HINTERGRUND
Autonome Fahrzeuge können zur kartengestützten Navigation stark von vorab gespeicherten Kartendaten abhängen. Da die Verbreitung autonomer Fahrzeuge zunimmt ist es überaus wichtig, die Fahrzeuge in Echtzeit mit zuverlässigen und aktuellen Kartenaktualisierungen zu versorgen, damit sie zeitkritisch auf sich ändernde Bedingungen reagieren können, die z.B. durch Straßensperrungen, Verkehrsbedingungen usw. verursacht werden.
Insbesondere Bereiche wie Bauzonen ändern sich oft schnell - so dass vorherige Kartendaten der Bereiche ungenau oder veraltet sind. Daher muss das autonome Fahrzeug nicht nur die Bauzonen erkennen können, sondern auch entscheiden können, wie das Fahrzeug durch diese Zonen manövrieren soll. Die Bereitstellung der aktuellsten verfügbaren Karteninformationen für autonome Fahrzeuge in Echtzeit ist daher für den Betrieb der Fahrzeuge unerlässlich.
Derzeit verwenden alle bekannten Anbieter von Kartendaten für autonome Fahrzeuge ihr eigenes proprietäres Format, wenn sie sowohl Karten als auch Kartenaktualisierungen an autonome Fahrzeuge übermitteln. Innerhalb der Anbietergruppe hat sich keine einheitliche Kartografieplattform oder ein einheitliches Format für die Kartenaktualisierung als Standard herausgestellt. Infolgedessen gibt es heute in der Branche keine standardisierte und skalierbare Arbeitslösung für eine Kartenaktualisierungsunterstützung, und die von den jeweiligen Anbietern angebotenen Lösungen unterscheiden sich und bleiben voneinander getrennt. Darüber hinaus können die entstehenden getrennten Lösungen von mindestens einem Unternehmen und/oder einer Organisation auf eine ausgewählte Geo-Region reguliert werden. Diese Art der Kontrolle hindert die Industrie des autonomen Fahrens daran, umgehend in jeder Geo-Region korrekte Karten und Kartenaktualisierungen zu erwerben.
In einem typischen Szenario werden Kartenaktualisierungsinformationen an einen herstellerspezifischen Server gesendet, der nicht für den Empfang von Kartenaktualisierungen von außerhalb des Ecosystems des Herstellers geöffnet ist. Dementsprechend gibt es keine gemeinsame Plattform oder ein gemeinsames Format, das das Problem der Kartenaktualisierung global löst und Kartenaktualisierungen oder die Validierung der Kartenaktualisierungen demokratisiert. Darüber hinaus gibt es keine Möglichkeit, die Genauigkeit der von einem bestimmten Anbieter bereitgestellten Kartenaktualisierungen zu überprüfen, was die branchenweite Einführung einer bestimmten Lösung unmöglich macht. Dies ist angesichts der zunehmenden Verbreitung autonomer Fahrzeuge problematisch, da ohne ein einheitliches Format oder eine einheitliche Plattform für den Austausch und die Validierung von Kartenaktualisierungen verhindert wird, dass Fahrzeuge wichtige standort- und streckenbezogene Informationen nahtlos untereinander austauschen.
ZUSAMMENFASSUNG DER ERFINDUNG
Diese Zusammenfassung soll eine Auswahl von Konzepten in vereinfachter Form vorstellen, welche im Folgenden in der detaillierten Beschreibung näher erläutert werden. Diese Zusammenfassung zielt nicht darauf ab, Schlüssel- oder wesentlichen Merkmale der Erfindung zu bezeichnen, noch soll sie dazu verwendet werden, den Schutzbereich der Erfindung einzuschränken.
Aspekte der vorliegenden Erfindung richten sich auf Verfahren zur Verwendung eines Blockchainmechanismus, um eine einheitliche Plattform und ein einheitliches Format für die Verarbeitung, den Austausch und die Validierung von Kartenaktualisierungen im Zusammenhang mit einer elektronischen Karte bereitzustellen, die von autonomen Fahrzeugen verwendet werden kann. Die Blockchain bietet eine sichere, transparente und dezentral verteilte Datenbank und Plattform, die von diversen verschiedenen Anbietern aktualisiert werden kann (z.B. Erstausrüster oder Automobilhersteller (OEMs), Kartografiefirmen, Firmen, die Kartenaktualisierungen bzw. Feldvergleichsdaten liefern, Halbleiterfirmen, Softwareanbieterfirmen, Unternehmen, die auf Daten von GPS-Einrichtungen angewiesen sind, und Lieferanten, die Bauteile, z.B. Sensoren oder Systeme, an die OEMs liefern (z.B. Tier 1-, Tier 2- und Tier 3-Lieferanten), usw.), die die einheitliche Kartenplattform und das mit der Blockchain verbundene Aktualisierungsformat verwenden.
Gemäß einem Aspekt der vorliegenden Erfindung können ein oder mehrere Kartenserver als Knoten der Blockchain konfiguriert werden - die Knoten nehmen eine Kartenaktualisierungskommunikation von diversen verschiedenen Anbietern und Quellen (einschließlich Sensoren und Kameras an autonomen und nicht autonomen Fahrzeugen) auf, um eine serverbasierte elektronische Karte zu aktualisieren und zu unterhalten.
Gemäß einem Aspekt der Erfindung werden die Kartendaten in der Blockchain in einem vernetzten Computernetzwerk gespeichert, das nicht unbedingt einer zentralen Behörde gehört oder von dieser betrieben wird. Während mehrere Mitglieder eines Kartografieecosystems dazu eingerichtet sein können, Aktualisierungen an den Kartendaten vorzunehmen, kann in einer Ausführungsform ein einziger Anbieter für den Betrieb der Cloudplattform verantwortlich sein, auf der die Blockchain implementiert ist. Jeder Mitwirkende am Ecosystem, der versucht, eine Aktualisierung der Blockchain durchzuführen, muss normalerweise dazu eingerichtet sein, mittels des einheitlichen Formats und Protokolls der Blockchain zu kommunizieren. Alternativ kann in einer Ausführungsform der Betreiber der Cloudplattform den verschiedenen Beitragenden am Ecosystem eine Anwendungsprogrammierschnittstelle (API) zur Verfügung stellen, die unter anderem Daten, die in einem herstellerspezifischen Format vorliegen, in ein einheitliches Format konvertiert, das mit der Blockchain vereinbar ist.
Nach noch einem weiteren Aspekt der Erfindung wäre die Blockchain-Plattform für Kartenaktualisierungen ein halböffentliches Hauptbuch, auf das nur Benutzer zugreifen können, die berechtigt sind, z.B. autonome Fahrzeuge, Messwagen usw. oder Anbieter, die Teil des Ecosystems sind und aktive Abonnements der Kartografieplattform haben.
Gemäß einer oder mehrerer Ausführungsformen werden Kartenaktualisierungen als eine Art Krypto-Asset behandelt und die Blockchain-Plattform wird zum Austausch von Kartenaktualisierungen zwischen den Fahrzeugeinheiten verwendet. So kann beispielsweise ein Krypto-Asset, das als Kartenaktualisierungs-Token (MUT) bezeichnet wird, dazu verwendet werden, Informationen zur Aktualisierung von Karten zwischen autonomen Fahrzeugeinheiten auszutauschen. Die MUTs können unter anderem dazu verwendet werden, Anbieter und Endverbraucher (oder Fahrer) für die Bereitstellung gültiger Kartenaktualisierungen für die Blockchain zu belohnen. Die MUTs können auch dazu verwendet werden, die Reputationswerte von Fahrern und Anbietern zu ermitteln. Weiterhin können die MUTs dazu verwendet werden, einen Zugriff auf die Kartografiedaten in der Blockchain zu steuern.
Gemäß einem Aspekt der vorliegenden Erfindung wird eine Lösung vorgeschlagen, um einen Konsens für Kartenaktualisierungen zwischen den verschiedenen miteinander verbundenen Knoten der Blockchain zu erzielen. Ausführungsformen der vorliegenden Erfindung erzielen einen Konsens über die der Blockchain bereitgestellten Kartenaktualisierungen, indem sie dynamisch mindestens einen von einem Tupel mehrerer Nachweise auswählen und durchführen, nämlich: a) einen Ortsnachweis (wobei der Ort einer Kartenaktualisierung durch andere Fahrzeuge verifiziert wird); b) einen Wiederholungsnachweis (wobei eine bestimmte Aktualisierung erst nach Erhalt einer Reihe ähnlicher Aktualisierungen als wahr bestätigt wird); c) einen Sicherheitsnachweis, der mindestens einen Nachweis aufweisen kann, wie beispielsweise (ohne Einschränkung): Nachweis einer funktionalen Sicherheit, Nachweis einer Sicherheit einer vorgesehenen Funktion, Nachweis einer Systemsicherheit und dergleichen (jede Kombination von Risikovermeidung, Risikominderung, Prävention, Validierung, Autorisierungsverfahren kann zur Anwendung kommen) und d) Nachweis einer physischen Lieferung (die Daten bestätigen ihre Herkunft und Genauigkeit). In einer Ausführungsform kann die Auswahl eines oder mehrerer Nachweise dynamisch erfolgen und zumindest teilweise von einer Reihe von Faktoren abhängig sein, wie beispielsweise von verfügbaren Sensorausführungen, externen Bedingungen und der Komplexität der Umgebung.
Speziell wird in einer Ausführungsform ein serverbasiertes Verfahren zum Aktualisieren von Kartendaten unter Verwendung einer Blockchain vorgestellt. Die Blockchain umfasst Daten zum Unterhalt der globalen Karte eines vorbestimmten geografischen Bereichs. Das Verfahren umfasst ein Speichern der Blockchain auf einem Server, wobei die Blockchain eine halböffentliche verteilte Datenbank ist, welche eine Vielzahl von Datensätzen aufweist, wobei jeder Datensatz mit einer Aktualisierung der globalen Karte verknüpft ist. Das Verfahren umfasst ferner das Empfangen einer Nachricht, die einer Kartenaktualisierung auf der globalen Karte zugeordnet ist, wobei die Nachricht Informationen über eine Kartenaktualisierung für eine bestimmte Fahrtroute umfasst. Ein Konsens über die Kartenaktualisierung wird durch eine Auswertung der Kartenaktualisierung bestimmt. Die Auswertung umfasst eine dynamische Auswahl und Durchführung von mindestens einem aus einer Vielzahl von „Nachweisen“. Die Vielzahl der Nachweise kann einen oder mehrere aus einem Ortsnachweis, einem Wiederholungsnachweis, einem Nachweis einer physischen Lieferung und einem Sicherheitsnachweis aufweisen. In Antwort auf eine Validierung der Kartenaktualisierung durch die Vielzahl von Nachweisen umfasst das Verfahren ein Erzeugen eines der Kartenaktualisierung zugeordneten Datensatzes. Anschließend wird die Blockchain aktualisiert, um den erzeugten Datensatz aufzunehmen, und danach wird der erzeugte Datensatz elektronisch an eine Vielzahl von Knoten der Blockchain übertragen.
In einigen Ausführungsformen wird die Nachricht basierend auf einem Datenformatstandard formatiert, der mit der Blockchain vereinbar ist. In anderen Ausführungsformen wird die Nachricht basierend auf einem proprietären Datenformatstandard eines Herstellers formatiert, wobei die Nachricht von dem proprietären Datenformat des Herstellers in den mit der Blockchain vereinbaren Datenformatstandard umgewandelt wird, bevor ein Konsens über die Kartenaktualisierung erzielt wird.
In einigen Ausführungsformen umfasst eine Durchführung des Ortsnachweises eine Validierung einer von einer ersten mobilen Einheit empfangenen Kartenaktualisierung, nachdem ein Standort der ersten mobilen Einheit durch eine Kartenaktualisierung einer zweiten mobilen Einheit verifiziert wurde.
In einigen Ausführungsformen umfasst eine Durchführung des Wiederholungsnachweises eine Validierung einer von einer ersten mobilen Einheit empfangenen Kartenaktualisierung, nachdem die Kartenaktualisierung der ersten mobilen Einheit durch eine analoge Kartenaktualisierung einer zweiten mobilen Einheit verifiziert wurde, und nachdem eine mit der Kartenaktualisierung der ersten mobilen Einheit verbundene Fahrtroute eine Schwellenanzahl von Malen durch eine oder mehrere mobile Einheiten überprüft wurde.
In einigen Ausführungsformen umfasst ein Durchführen eines Nachweises einer physischen Lieferung eine Automatisierung einer Lieferung von der globalen Karte zugeordneten Daten und zugehöriger Kartenaktualisierungen an ein Rechenzentrum, in dem der Server unterhalten wird, und ein Hinzufügen einer mit der Lieferung an die Blockchain verbundenen Nachverfolgungsnummer.
In einigen Ausführungsformen umfasst eine Durchführung eines Sicherheitsnachweises eine Durchführung mehrerer Iterationen für den Ortsnachweis und den Wiederholungsnachweis.
Figurenliste
Die beiliegenden Zeichnungen sind in dieser Spezifikation verkörpert und bilden einen Teil davon. Die Zeichnungen veranschaulichen Ausführungsformen. Zusammen mit der Beschreibung dienen die Zeichnungen dazu, die Prinzipien der Ausführungsformen zu erklären:

1 ist ein Diagramm, das die Herausforderungen veranschaulicht, die mit den herkömmlichen Verfahren verbunden sind, mit welchen Kartenaktualisierungen durchgeführt werden.
2A ist ein Diagramm, das die Art und Weise veranschaulicht, in welcher die Blockchain-Technologie verwendet werden kann, um einen standardisierten Mechanismus für eine Bereitstellung von Kartenaktualisierungen in einem Kartografieecosystem in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung bereitzustellen.
2B ist ein Diagramm, das eine alternative Ausführungsform zum Speichern elektronischer Karten und Aktualisierungen in einem Kartografieecosystem in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
3 veranschaulicht die Art und Weise, in welcher Fahrzeuge mit der Karten-Cloudplattform verbunden werden können, auf der die Blockchain implementiert ist, um Kartenaktualisierungen in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung bereitzustellen.
4 ist ein Diagramm, das veranschaulicht, wie ein Ortsnachweis in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung erbracht werden kann.
5 veranschaulicht die Art und Weise, in welcher ein Wiederholungsnachweis in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung erbracht werden kann.
6 ist ein Flussdiagramm, das ein beispielhaftes rechnerimplementiertes Verfahren veranschaulicht, bei dem in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ein Nachweis einer physischen Lieferung erbracht werden kann.
7 zeigt ein Flussdiagramm eines beispielhaften rechnerimplementierten Verfahrens zur Validierung von Kartenaktualisierungen unter Verwendung einer Blockchain in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
8 zeigt ein Flussdiagramm eines beispielhaften rechnerimplementierten Verfahrens zum Unterhalt von Kartendaten unter Verwendung einer Blockchain in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
9 ist ein Datenflussdiagramm, das ein beispielhaftes rechnerimplementiertes Verfahren veranschaulicht, welches zur Aktualisierung eines einem Client zuzuordnenden Token-Kontos in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung dient.
10 veranschaulicht ein beispielhaftes Rechnersystem zur Realisierung von Ausführungsformen der vorliegenden Erfindung.

DETAILLIERTE BESCHREIBUNG
Nun erfolgt eine detaillierte Bezugnahme auf die bevorzugten Ausführungsformen der Erfindung, ein Verfahren und ein System zur Verwendung eines Blockchainmechanismus zur Bereitstellung einer einheitlichen Plattform und eines einheitlichen Formats für eine Verarbeitung, einen Austausch und eine Validierung von Kartenaktualisierungen im Zusammenhang mit einer elektronischen Karte, die von autonomen Fahrzeugen verwendet werden kann, wobei Beispiele hierfür in den beiliegenden Zeichnungen dargestellt sind. Obwohl die Erfindung in Verbindung mit den bevorzugten Ausführungsformen beschrieben wird, versteht es sich, dass diese nicht auf die Ausführungsformen beschränkt sein soll. Im Gegenteil soll die Erfindung Alternativen, Änderungen und Äquivalente umfassen, die in den Geist und den Anwendungsbereich einbezogen werden können, wie er durch die beigefügten Ansprüche definiert ist.
Darüber hinaus werden in den folgenden detaillierten Beschreibungen der Ausführungsformen der Erfindung zahlreiche spezifische Details dargelegt, um ein gründliches Verständnis der Erfindung zu vermitteln. Eine durchschnittliche Fachperson auf dem Gebiet wird jedoch erkennen, dass die Erfindung ohne diese spezifischen Details ausführbar ist. In anderen Fällen wurden bekannte Methoden, Verfahren, Komponenten und Schaltungen nicht detailliert beschrieben, um Aspekte der Erfindung nicht unnötigerweise zu verdecken.
Einige Abschnitte der folgenden detaillierten Beschreibungen werden in Form von Vorgängen, Schritten, Logikblöcken, Verarbeitungen und anderen symbolischen Darstellungen von Datenbit-Operationen dargestellt, die in Rechnerspeicher ausführbar sind. Diese Beschreibungen und Darstellungen sind die Mittel, mit denen das Fachpersonal der Datenverarbeitungsbranche ihren Arbeitsinhalt am effektivsten an andere Fachkräfte weitergeben kann. Ein Vorgang, ein rechnererzeugter Schritt, ein Logikblock, ein Verfahren usw. ist hier und ganz allgemein als eine selbstkonsistente Folge von Schritten oder Anweisungen gedacht, die zu einem gewünschten Ergebnis führen. Die Schritte sind solche, die eine physikalische Beeinflussung physikalischer Größen erfordern. Normalerweise, wenn auch nicht notwendigerweise, liegen diese Größen in Form von elektrischen oder magnetischen Signalen vor, welche in einem Rechnersystem speicher-, übertrag-, kombinier-, vergleich- und anderweitig manipulierbar sind. Es hat sich bisweilen als günstig erwiesen, diese Signale, vor allem aus Gründen der allgemeinen Nutzung, als Bits, Werte, Elemente, Symbole, Zeichen, Begriffe, Zahlen oder dergleichen zu bezeichnen.
Es sollte jedoch nicht außer Acht gelassen werden, dass alle diese und ähnliche Begriffe mit den entsprechenden physikalischen Größen zu verknüpfen sind und lediglich geeignete Bezeichnungen für diese Größen sind. Sofern aus den folgenden Erörterungen nicht ausdrücklich etwas anderes hervorgeht, wird anerkannt, dass sich Diskussionen, die Begriffe wie „Speichern“, „Empfangen“, „Authentifizieren“, „Konvertieren“, „Bewerten“, „Aktualisieren“, „Verfeinern“ oder dergleichen verwenden, in der vorliegenden Erfindung durchgängig auf die Handlung und Verfahren eines Rechnersystems oder einer integrierten Schaltung beziehen, oder einer ähnlichen elektronischen Berechnungseinrichtung, einschließlich eines eingebetteten Systems, die als physische (elektronische) Größen innerhalb der Register und Speicher des Rechnersystems dargestellte Daten manipulieren und in andere Daten umwandeln, die ähnlich als physische Größen innerhalb der Speicher oder Register des Rechnersystems oder anderer solcher Informationsspeicher-, Übertragungs- oder Anzeigeeinrichtungen dargestellt werden.
Ausführungsformen der Erfindung richten sich auf neuartige Lösungen zur Bereitstellung einer einheitlichen Plattform und eines einheitlichen Formats für eine Verarbeitung und Validierung von Kartenaktualisierungen im Zusammenhang mit einer elektronischen Karte für autonome Fahrzeuge unter Verwendung eines Blockchainmechanismus.
KONVENTIONELLE KARTOGRAFIESYSTEME UND DAMIT VERBUNDENE HERAUSFORDERUNGEN
Anbieter von herkömmlichen Kartografiesystemen, die in autonomen Fahrzeugen verwendet werden, verwenden in der Regel ihr eigenes Format, wenn sie sowohl Karteninformationen als auch Kartenaktualisierungen an autonome Fahrzeuge übermitteln. Dementsprechend gibt es in der Kartografiebranche derzeit keine standardisierte Kartografieplattform und kein standardisiertes Format für Karten oder für Kartenaktualisierungen.
Da es derzeit keine standardisierte, skalierbare Lösung zur Unterstützung von Kartenaktualisierungen gibt, die auch mehrere Geo-Regionen unterstützt und nationalen Richtlinien entspricht, unterscheiden sich alle von den verschiedenen Anbietern vorgestellten Lösungen und bleiben voneinander isoliert. Da die Anbieter nicht dazu eingerichtet sind, Informationen frei auszutauschen, sind sie gezwungen, sich auf eine bruchstückhafte Abdeckung und/oder teure Mittel wie die Verwendung von Messwagen zur Aktualisierung ihrer Karteninformationen zu verlassen.
Zu den Anbietern, die Kartografielösungen für autonome Fahrzeuge anbieten können, gehören Kartografiefirmen, Kartenaktualisierungsfirmen, Automobilhersteller (OEMs), Firmen, die Feldvergleichsdaten liefern, Halbleiterfirmen, Softwareanbieterfirmen, Firmen, die auf Daten von GPS-Einrichtungen angewiesen sind, und Lieferanten, die Bauteile, z.B. Sensoren oder Systeme, an die OEMs liefern (z.B. Tier 1-, Tier 2- und Tier 3-Lieferanten). Es sollte beachtet werden, dass Hersteller der autonomen Auto-Entwicklungsplattformen, wie z.B. NVIDIA DRIVE™, auch eigene Kartografielösungen anbieten können, die technisch und regional skalierbar sind. Die autonome Fahrzeugentwicklungsplattform kann eine skalierbare, künstliche Intelligenz (KI) getriebene - um Deep Learning herum aufgebaute - Plattform sein, die unter anderem Kartografietechnologie für autonome Fahrzeuge bereitstellt und es Automobilherstellern und Kartografiefirmen ermöglicht, schnell hochauflösende (HD) Karten, detailärmere HD-Karten, detailärmere Karten, Standardnavigationskarten und dergleichen zu erstellen und zu unterhalten. Normalerweise ist die Plattform dazu eingerichtet, Daten von mindestens einer oder mehreren Kameras sowie Lidar-, Radar- und Ultraschallsensoren, die im autonomen Fahrzeug vorgesehen sind, zu verschmelzen, um die gesamte 360-Grad-Umgebung um das Auto herum zu erfassen und eine robuste Darstellung zu erzeugen, einschließlich statischer und dynamischer Objekte. Darüber hinaus ist ein mit der Plattform versehenes autonomes Fahrzeug auch dazu eingerichtet, sich präzise auf einer HD-Karte zu lokalisieren (auch bekannt als „Lokalisierung“) und einen sicheren Vorwärtsweg zu planen. Mehrschichtige neuronale Netze werden für die Erkennung und Klassifizierung von Objekten verwendet, um die Genauigkeit der verschmolzenen Sensordaten zu erhöhen.
1 ist ein Diagramm, das die Herausforderungen veranschaulicht, die mit den herkömmlichen Verfahren verbunden sind, mit welchen Kartenaktualisierungen durchgeführt werden. Fahrer von nichtautonomen Fahrzeugen erhalten ihre Kartografiedaten normalerweise von den in ihren Fahrzeugen vorgesehenen (vom OEM bereitgestellten) GPS-Systemen oder durch unabhängige Kartografiefirmen (z.B. Kartografiefirmen, die GPS-Einrichtungsherstellern Daten bereitstellen). Beispielsweise erhält ein herkömmliches Auto A in 1 Kartografieinformationen aus einer OEM-Cloud 110 (unterhalten durch den Hersteller des Autos A), wobei die Daten im proprietären Format A formatiert sind, das vom jeweiligen OEM verwendet wird. Ebenso erhält das herkömmliche Auto B Kartografiedaten aus der Kartografiefirmen-Cloud 120 (unterhalten von einer Firma, die Kartografiedaten und -dienste bereitstellt), wobei die Daten in dem proprietären Format B formatiert sind, das von der jeweiligen Kartografiefirma verwendet wird.
Ein Entwickler einer autonomen Fahrzeugentwicklungsplattform 190 für das autonome Fahrzeug C kann auch über ein eigenes proprietäres Format C verfügen, das zum Speichern und Austauschen von Kartografiedaten verwendet wird, die auf dem Cloud-Server 130 gespeichert sind. Entwickler der autonomen Fahrzeugentwicklungsplattform 190 können dennoch dazu eingerichtet sein, mit OEMs und Kartografiefirmen zusammenzuarbeiten und Partnerschaften eingehen, um die Genauigkeit der Kartografiedaten zu erhöhen - was zu einer genaueren Lokalisierung und einer robusteren Darstellung der Umgebung führt. Wie in 1 dargestellt kann die autonome Fahrzeugentwicklungsplattform 190 dazu eingerichtet sein, Kartografiedaten aus anderen proprietären Formaten, z.B. den proprietären Formaten A und B, zu integrieren. Während Partnerschaften mit anderen Anbietern zum Empfang und zur Einbindung genauer Kartografiedaten von Vorteil sind, sind erhebliche Herausforderungen damit verbunden. Am wichtigsten ist, dass es keine gemeinsame Plattform oder ein gemeinsames Format gibt, das die Aufgabe der Kartenaktualisierung global löst und Kartenaktualisierungen, Autorisierung und/oder die Validierung der Kartenaktualisierungen demokratisiert. Ohne ein einheitliches Format oder eine einheitliche Plattform für einen Austausch von Kartenaktualisierungen und eine Validierung von Kartenaktualisierungen in Echtzeit werden autonome Fahrzeuge daran gehindert, untereinander lebenswichtige Orts- und streckenbezogene Informationen in Echtzeit auszutauschen.
Andere weniger offensichtliche Herausforderungen, die mit der Schaffung eines gemeinsamen Kartografieecosystems zwischen den Anbietern verbunden sind, umfassen die Schwierigkeit, die von jedem bestimmten Anbieter gemeldeten Kartenaktualisierungen zuverlässig zu überprüfen. Die von einem vorgegebenen Anbieter bereitgestellten Kartenaktualisierungen müssen vertrauenswürdig sein. Um die Vertrauenswürdigkeit zu gewährleisten, muss die Quelle der Kartografiedaten einschließlich der Aktualisierungen nachvollziehbar sein. Darüber hinaus ist ein Mechanismus erforderlich, um eine Güte der Kartendaten zu bewerten und die Anbieter für die Glaubwürdigkeit der von ihren jeweiligen Plattformen bereitgestellten Aktualisierungen zur Verantwortung zu ziehen.
Außerdem muss das Ecosystem dazu eingerichtet sein, verschiedenen Zugangsebenen zu den Kartografiedaten bereitzustellen. Beispielsweise kann ein Fahrer eines autonomen Fahrzeugs mit einer integrierten autonomen Fahrzeugentwicklungsplattform lediglich einen Sichtzugriff auf die Kartenaktualisierungen benötigen, ohne sich um den Inhalt des Beitrags zu sorgen. Ein Kartografiepartner, z.B. eine Kartografiefirma, kann jedoch möglicherweise einen Zugriff auf den Inhalt der bereitgestellten Kartenaktualisierungen erfordern, um den Inhalt zu authentifizieren oder Entscheidungen auf der Grundlage des Inhalts zu treffen.
Die Kartografiedaten im Ecosystem und ihren Quellen müssen transparent sein und gleichzeitig die Privatsphäre der Anbieter und der Nutzer des Ecosystems schützen. Weitere Anforderungen an das Navigations-Ecosystem können eine transparente Preisgestaltung für einen Zugang zum Ecosystem, eine genaue Abrechnung und ein Mechanismus zur Belohnung von Fahrern und Anbietern für eine Bereitstellung genauer Kartenaktualisierungen sein.
Wie bereits erwähnt werden sich schließlich die meisten Anbieter auf teure Mittel wie z.B. Messwagen verlassen, um ihre Karteninformationen zu aktualisieren. Zwar sind Messwagen mit mehreren Sensoren ausgestattet sind und dazu eingerichtet, genaue Kartografiedaten zu erzeugen, sie sind aber auch teuer und ineffizient. Messwagen zum Beispiel erfassen Fahrtroutenänderungen in Echtzeit, fahren aber nur eine begrenzte Zeit und auf einer begrenzten Anzahl von Straßen. Wenn sich eine bestimmte Fahrtroute aufgrund von Bauarbeiten ändert, kann ein Messwagen die Karteninformationen möglicherweise nicht aktualisieren, bis es mindestens eine oder mehrere Durchfahrten durch die Fahrtroute macht. Derzeit ist aufgrund der Unmöglichkeit, kartenbezogene Informationen frei auszutauschen, kein Anbieter dazu eingerichtet, einen zuverlässigen Weg für eine Schwarmbeschaffung von Informationen zu finden, um Kartenaktualisierungen im großen Maßstab und in allen Regionen zu erzeugen. Mit anderen Worten gibt es derzeit keinen zuverlässigen und effizienten Mechanismus sowohl für nichtautonome Fahrzeuge als auch für autonome Fahrzeuge, um Kartenaktualisierungen in ein Kartografieecosystem auf der ganzen Welt in einer Weise einbringen zu können, die allen Interessengruppen zugutekommt und auch zu gültigen, sicheren und autorisierten Kartenaktualisierungen führt.
BLOCKCHAIN-MECHANISMUS ZUM AUSTAUSCH UND ZUR VALIDIERUNG VON KARTENAKTUALISIERUNGEN IN ECHTZEIT
Ausführungsformen der vorliegenden Erfindung bieten eine einheitliche Plattform und ein einheitliches Format für eine Verarbeitung und Validierung von Kartenaktualisierungen zur Aktualisierung einer elektronischen Karte, die unter anderem durch autonome Fahrzeuge nutzbar ist. Darüber hinaus lösen Ausführungsformen der vorliegenden Erfindung das Problem der Kartenaktualisierung durch ein Aktualisierungsformat und Kartenserver, die die Blockchain-Technologie nutzen - insbesondere eine Blockchain, die dazu eingerichtet ist, Kartenaktualisierungskommunikation von diversen verschiedenen Anbietern zu akzeptieren, um eine serverbasierte elektronische Karte zu aktualisieren und zu unterhalten. In einer Ausführungsform werden Kartenaktualisierungen als eine Art Krypto-Asset behandelt, und eine mit einer Blockchain verbundene Krypto-Engine wird verwendet, um Kartenaktualisierungen zwischen den Autoeinheiten zu auszutauschen.
2A ist ein Diagramm die Art und Weise veranschaulicht, in welcher die Blockchain-Technologie verwendet werden kann, um einen standardisierten Mechanismus für eine Bereitstellung von Kartenaktualisierungen in einem Kartografieecosystem in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung bereitzustellen. Wie in 2A dargestellt ist können Kartenaktualisierungen von verschiedenen Fahrzeugen (z.B. Auto A 201, Auto B 202, autonomes Fahrzeug C 203 usw.) mit Hilfe einer Blockchain 280 gespeichert und validiert werden, die ein vernetztes Netzwerk von Cloud Computing-Ressourcen und/oder -Servern überspannend implementierbar ist (z.B. einen OEM-Server 210, einen Kartografiefirmenserver 220, einen autonomen Fahrzeugentwicklungsplattformserver 230 usw. umfassend). Alternativ kann die Blockchain (wie in 2B dargestellt) in einer anderen Ausführungsform auf Knoten implementiert werden, die von den vom Hersteller verwalteten Servern getrennt sind. Es ist zu beachten, dass das auf der Kartografieplattform 250 unterhaltene vernetzte Servernetzwerk auch Server von Kartografiefirmen, Firmen, die Feldvergleichsdaten liefern, Softwareanbieterfirmen, Halbleiterfirmen, Tier-1-Firmen, Firmen, die für ihre Produkte und Dienstleistungen auf GPS-Daten angewiesen sind und andere Anbieter, die Teil der Lieferkette für autonome Fahrzeug- oder Kartografiedaten sind, umfassen kann.
In einer Ausführungsform können Daten von OEMs, Kartografiefirmen, Firmen, die Feldvergleichsdaten liefern, Halbleiterfirmen, Softwareanbieterfirmen, Tier-1-Lieferanten, Firmen, die GPS-Daten verwenden, usw. ein Teil der Karten-Cloudplattform 250 auf einem einzelnen und/oder verteilten Server sein. In einer weiteren Ausführungsform können ein Server oder Daten von mindestens einer der repräsentativen Anbieterfirmen Teil der Kartografie-Cloudplattform 250 auf einem einzelnen und/oder verteilten Server sein.
In noch einer weiteren Ausführungsform kann mindestens eine der repräsentativen Firmen aus einem Pool von OEMs, Kartografiefirmen, Firmen, die Feldvergleichsdaten liefern, Halbleiterfirmen, Softwareanbieterfirmen, Tier-1-Lieferanten, Firmen, die GPS-Daten nutzen, Regierungsorganisationen, dedizierte Softwareanbieter usw. Teil der Karten-Cloudplattform 250 auf einem einzelnen und/oder verteilten Server sein. Diese Ausführungsform wäre besonders nützlich in geografischen Gebieten, in denen staatliche Stellen Teil der Kartografieecosystem-Lieferkette wären.
Die Blockchain 280 verwendet eine sichere, transparente und dezentrale verteilte Datenbank, die durch diverse verschiedene Kartenanbieter und/oder andere Einheiten aktualisierbar ist, wobei der Blockchain 280 die Kartenaktualisierungen in einem einheitlichen Format und/oder nach einer Konvertierung in ein einheitliches Format hinzugefügt werden. Es ist zu beachten, dass Transaktionen, z.B. Kartenaktualisierungen, die der Blockchain bereitgestellt werden, in der Regel relativ klein sind, und große Datenmengen, die die Blockchain betreffen, „abseits der Kette“ mit innerhalb der Kette und/oder in einem Cache-Speicher gespeicherten Zeigern und Referenzen und dergleichen gespeichert werden, da Blockchains nicht dazu konzipiert sind, als Speichermedium zu dienen.
In einer Ausführungsform kommuniziert jede Entität, die versucht, der Blockchain eine Kartenaktualisierung zuzuführen, unter Verwendung des von der Blockchain verwendeten Formats und Protokolls, wodurch die Konsistenz zwischen den verschiedenen Anbietern gewährleistet wird. Alternativ können in einer anderen Ausführungsform, wie in 2A dargestellt, von mindestens einem der Anbieter übermittelte Kartenaktualisierungsdaten einer Umwandlung in ein einheitliches Format bedürfen, bevor sie der Blockchain 280 hinzugefügt werden können. Wie in 2A dargestellt ist verwenden Kartenaktualisierungen des autonomen Fahrzeugs C 203 das Blockchainformat C, und dementsprechend kann das Datenerfassungsmodul 240 für die Übertragung von Daten aus dem autonomen Fahrzeug C einfach eine Daten- und Zeitsynchronisation bereitstellen. Mit anderen Worten muss das Format der Daten des autonomen Fahrzeugs C vor der Aktualisierung der Blockchain 280 nicht konvertiert werden, aber die Daten müssen möglicherweise durch das Datenerfassungsmodul 240 synchronisiert werden. Im Gegensatz dazu werden Aktualisierungen aus einem nichtautonomen Fahrzeug A 201 mit einem proprietären Format A und einem nichtautonomen Fahrzeug B 202 mit einem proprietären Format B mit dem Datenerfassungsmodul 240 in der Karten-Cloudplattform 250 konvertiert und in die Blockchain aufgenommen. Es ist zu beachten, dass nicht autonome Fahrzeuge (z.B. Auto A 201 und Auto B 202), um Kartenaktualisierungen vornehmen zu können, möglicherweise mit Kameras und anderen Arten von Sensoren (z.B. Lidar-, Radar- und Ultraschallsensoren) ausgestattet sein müssen, die zur Erfassung von Orts- und Fahrtrouteninformationen kalibriert sind.
In einer Ausführungsform sind Server 210, 220 und 230 Rechnersystemknoten der Blockchain 280, die zusammenarbeiten, um kartenbezogene Daten und Transaktionen zu verwalten, z.B. Kartenaktualisierungen bezüglich der Kartendaten. Es ist zu beachten, dass die hierin enthaltene Diskussion zwar auf drei beispielhafte Knoten beschränkt ist, eine typische Blockchain jedoch mehreren Knoten umfasst. Jede Transaktion, z.B. eine Kartenaktualisierung, die einem der Knoten - von einem autonomen oder nicht autonomen Fahrzeug aus - übermittelt wird, kann an einen oder alle anderen Knoten übertragen werden. Die Knoten, die die Transaktion empfangen, müssen die Transaktion bestätigen und verifizieren, um sicherzustellen, dass die Transaktion echt ist. Wenn die Empfängerknoten einen Konsens darüber erzielt haben, dass die Transaktion legitim und akzeptabel ist, kann der Blockchain 280 ein neuer Block hinzugefügt werden. Der Block kann normalerweise auch andere bestätigte Transaktionen aufweisen. Anschließend wird der Block von bestätigten Transaktionen, z.B. bestätigte Kartenaktualisierungen, in der Blockchain 280 verzeichnet. Mit anderen Worten wird der Block wird mit einem Zeitstempel versehen, mit dem unmittelbar vorhergehenden Block verknüpft und der Blockchain hinzugefügt.
In einer Ausführungsform wäre die Blockchain-Plattform 280 für Kartenaktualisierungen ein halböffentliches Hauptbuch und nur für autorisierte Benutzer zugänglich, z.B. Fahrer von autorisierten autonomen Fahrzeugen oder Anbieter, die abonnierende Mitglieder des Ecosystems sind, z.B. OEMs, Tier-1-Lieferanten, usw. Darüber hinaus können in einer Ausführungsform private Schlüssel für einen Zugriff auf die und Beiträge zur Blockchain-Plattform nur Anbietern oder Abonnenten der Kartografieplattform zugewiesen werden, die genaue und zuverlässige Kartenaktualisierungen beitragen. In einer solchen Ausführungsform können alle abonnierenden Mitglieder Einblick in jeden auf der Plattform geleisteten Datenbeitrag haben, aber Zugangskontrollmechanismen wie (ohne Einschränkung) verschlüsselte Schlüssel und intelligente Verträge können verwendet werden, um den Zugriff auf die Inhalte der Beiträge auf die Mitglieder zu beschränken, die über die privaten Schlüssel verfügen. Darüber hinaus kann die Möglichkeit, Updates durchzuführen, auf Mitglieder beschränkt sein, die über private Schlüssel verfügen.
In einer oder mehreren Ausführungsformen gehört die Blockchain 280 nicht notwendigerweise einer zentralen Behörde oder von dieser betrieben, in einer Ausführungsform kann einer der Anbieter, z.B. die Entwickler der autonomen Fahrzeugentwicklungsplattform 290 (oder ein anderer Anbieter oder eine andere Partei, die Teil des Kartografieecosystems ist), eine Karten-Cloudplattform 250 einrichten und verwalten, auf deren Grundlage die Blockchain unterhalten werden kann. In einer solchen Ausführungsform kann der die Cloudplattform 250 verwaltende Anbieter den anderen Anbietern im Ecosystem eine Anwendungsprogrammierschnittstelle (API) zur Verfügung stellen, wobei die API unter anderem so programmierbar ist, dass die vom Anbieter betriebenen Server mit der Blockchain 280 kommunizieren können. Beispielsweise kann den mit den Servern 210 und 220 verbundenen Anbietern eine API bereitgestellt werden, die es ihnen ermöglicht, die Daten aus ihrem proprietären Format in das einheitliche Format der Blockchain 280 zu konvertieren.
In einer Ausführungsform können die von der Blockchain gehaltenen elektronischen Karten entweder traditionelle HD-Karten 276 (z.B. von digitalen Kartografiefirmen) oder schwarmbeschaffte Karten 275 (z.B. von Geo-Startup-Firmen) sein. Diese elektronischen Karten werden auf das einheitliche Format normiert, bevor sie in die Blockchain integriert werden. Die Blockchain speichert die grundlegenden HD-Karten (z.B. Feldvergleichskarten) und auch alle Aktualisierungen dieser HD-Karten (die beispielsweise über das Datenerfassungsmodul 240 empfangen werden können).
2B ist ein Diagramm, das eine alternative Ausführungsform zum Speichern von elektronischen Karten und Aktualisierungen in einem Kartografieecosystem in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Wie bereits erwähnt kann die Blockchain in einigen Ausführungsformen auf von den Herstellerservern separaten Knoten der Karten-Cloudplattform 250 implementiert werden. Wie in 2B dargestellt wird die Blockchain-Plattform 260 - welche die Knoten der Blockchain umfasst - separat von den Herstellerservern, z.B. dem externen Herstellerserver 262, auf der Karten-Cloudplattform 250 implementiert. In dieser Ausführungsform speichert, verschmilzt und verarbeitet die Blockchain-Plattform 260 die Daten von den verschiedenen Anbietern auf einer Ecosystem-Blockchain. Die Blockchain-Plattform speichert auch die Grundkarten (z.B. Feldvergleichsdaten, HD-Karten, detailärmere HD-Karten, SD-Karten, 3D-Karteninhalte, Wetterbedingungen, Tages- und Nachtbedingungen, interessierende Punkte usw.) und aktualisiert diese Karten. Wie bereits erwähnt können die Basiskarten entweder herkömmliche HD-Karten 276 oder schwarmbeschaffte Karten 275 sein.
Das Datenerfassungsmodul 240 ist dazu eingerichtet, Daten zu empfangen und Aktualisierungen der Karten zu erzeugen. Wie in Verbindung mit 2A erläutert wird das Datenerfassungsmodul unter anderem die Daten von einem herstellerspezifischen Format in das einheitliche Format der Blockchain umsetzen. Beispielsweise kann so im Falle eines nicht autonomen Fahrzeugs 201 das Datenerfassungsmodul so betrieben werden, dass es die Daten in einem herstellerspezifischen Format aufnimmt und die Daten in das Blockchain-Format umsetzt. Im Falle des autonomen Fahrzeugs 203 können die Daten jedoch bereits im Blockchain-Format vorliegen. In diesem Fall kann das Datenerfassungsmodul 240 Daten- und Zeitsynchronisationsdienste bereitstellen, bevor die Daten zur Blockchain hinzugefügt werden.
Jeder der Anbieterserver, einschließlich Server 262, verwendet die vom Verwalter der Karten-Cloudplattform 250 bereitgestellte API 261, um mit der Blockchain zu kommunizieren und ihre Kartenaktualisierungen in das von der Blockchain benötigte einheitliche Format umzusetzen. Darüber hinaus ermöglicht die API es den Anbietern auch, nahtlos von der Blockchain Kartenaktualisierungen in einem Format und Protokoll zu erhalten, das von den jeweiligen Anbietern verarbeitet werden kann.
Normalerweise sind Blockchains mit Krypto-Assets verbunden, die als Tauschmittel konzipierte digitale Assets sind, welche Kryptographie nutzen um Transaktionen in der Blockchain zu sichern und zu verifizieren sowie die Schaffung zusätzlicher Einheiten zu steuern. Wie bereits erwähnt verwenden Ausführungsformen der vorliegenden Erfindung Kartenaktualisierungen als eine Art Krypto-Asset, und eine der Blockchain zugeordnete Krypto-Engine wird verwendet, um Kartenaktualisierungen zwischen den Fahrzeugeinheiten zu auszutauschen. In einer Ausführungsform würden die Assets der Blockchain der vorliegenden Erfindung auch kartenbezogene Daten und Kartenkacheln umfassen. So kann beispielsweise ein Krypto-Asset, das als Kartenaktualisierungs-Token (MUT) bezeichnet wird, als Austauschmedium für einen Austausch von Assets verwendet werden, z.B. für einen Austausch von Kartenaktualisierungsinformationen zwischen autonomen Fahrzeugeinheiten. Die MUTs werden mittels der Karten-Cloudplattform 310 in einem einheitlichen Format gespeichert und ausgetauscht. Die MUTs können unter anderem dazu verwendet werden, Anbieter und Endverbraucher (oder Fahrer) für eine Bereitstellung gültiger Kartenaktualisierungen für die Blockchain zu belohnen. Mit anderen Worten, MUTs werden verwendet, um Fahrern und Anbietern Werte zuzuweisen, um zuverlässige und genaue Kartenaktualisierungen für das Kartografieecosystem bereitzustellen. In einer Ausführungsform können die MUTs zwischen den beteiligten Parteien mit gewichteten Beiträgen geteilt werden.
Gemäß einer oder mehrerer Ausführungsformen können die MUTs an einen finanziellen Anreiz gebunden sein, den ein Fahrer oder Anbieter erhält, um eine bestimmte Anzahl genauer Kartenaktualisierungen bereitzustellen. Alternativ können die MUTs gegen Gutschriften eingetauscht werden, die einen Fahrer oder Anbieter dazu berechtigen, eine bestimmte Anzahl von Kartenaktualisierungen kostenlos aus dem Kartografiesystem zu beziehen.
Gemäß einer weiteren Ausführungsform können MUTs auch verwendet werden, um die Reputation und die Glaubwürdigkeit eines bestimmten Fahrers, einer bestimmten Fahrereinheit und/oder eines bestimmten Anbieters zu ermitteln. Ein Fahrer kann sich einen Reputationswert aufbauen, indem er Aktualisierungen einbringt, die nicht im Widerspruch stehen zu oder mit genaueren Daten aus anderen Quellen unvereinbar sind. So kann beispielsweise ein Fahrer mit einem hohen Reputationswert einen Messwagen mit genaueren und hochentwickelten Sensoren fahren. Dementsprechend werden genauere Informationen aus anderen Fahrzeugen selten an die Stelle von Kartenaktualisierungen von diesem Fahrer treten. Fahrer mit hohen Reputationswerten können wie bereits erwähnt mit MUTs belohnt und mit einem privaten Schlüssel für eine Bereitstellung ihrer Aktualisierungen für die Cloudplattform 250 versehen werden.
Die MUTs können in einer oder mehreren Ausführungsformen auch dazu verwendet werden, einen Zugriff auf die Kartografiedaten der Blockchain zu steuern. So kann die Karten-Cloudplattform 250 (beispielhaft und ohne Einschränkung) beispielsweise mittels verschlüsselten Schlüsseln und intelligenten Verträgen nur solchen Mitgliedern des Ecosystems Kartenaktualisierungen zur Verfügung stellen, die über eine für einen Erwerb der Updates erforderliche Anzahl von MUTs verfügen. Mit anderen Worten können die MUTs als Währung zum Kauf, Tausch und/oder Verkauf von Kartenaktualisierungen verwendet werden. In einer Ausführungsform dürfen die MUTs nur Mitgliedern zur Verfügung gestellt werden, die ihre eigenen Kartenaktualisierungen zur Cloudplattform 250 beitragen. Um Kartenaktualisierungen zu erhalten, können die Mitglieder beispielsweise verpflichtet werden, auch beitragende Mitglieder des Ecosystems zu sein.
Gemäß einer oder mehrerer Ausführungsformen kann es mehrere Szenarien geben, in denen MUTs zum Austausch von Kartenaktualisierungen verwendet werden können. Ein autonomes oder nichtautonomes Fahrzeug kann ein MUT für eine Bereitstellung genauer Daten über eine bestimmte Strecke oder genauer Standortinformationen über ein anderes Fahrzeug auf der Straße erlangen. Ebenso kann ein Fahrzeug ein MUT dann erlangen, wenn es eine festgelegte Fahrtroute durchläuft und bestätigt. Mit anderen Worten, MUTs können für ein Durchlaufen bekannter Fahrtrouten erlangt werden.
Ein von einem Anbieter betriebenes Fahrzeug, z.B. ein Messwagen, kann Token erlangen, indem es/er neue Fahrtrouten erstellt und die Fahrtrouten mehrfach durchläuft. Ebenso können anbieterbetriebene Fahrzeuge auch für eine Erstellung regelmäßiger Kartenaktualisierungen Token erlangen. Ein autonomes Fahrzeug, z.B. eine in Betrieb befindliche autonome Fahrzeugentwicklungsplattform 230, kann Token erlangen, indem sie Deep Learning oder andere Kl-Verfahren zur Verbesserung der Kartenaktualisierung einsetzt. MUTs können von allen Fahrzeugtypen aufgebraucht werden, indem entweder kartenbezogene Daten aus der Blockchain oder Kartenaktualisierungen bezogen werden.
3 veranschaulicht die Art und Weise, in welcher sich Fahrzeuge aus der Ferne mit der Karten-Cloudplattform verbinden können, auf der die Blockchain implementiert ist, um Kartenaktualisierungen in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung bereitzustellen. Sowohl autonomen als auch nichtautonomen Fahrzeugen mag gestattet sein, Aktualisierungen von der auf der Karten-Cloudplattform 310 implementierten Blockchain zu beziehen oder für diese bereitzustellen. Wie bereits erwähnt werden die nichtautonomen Fahrzeuge normalerweise mit einem Satz von Sensoren oder Kameras ausgerüstet sein, die dazu eingerichtet sind, Fahrtrouteninformationen zu erfassen.
Wie in 3 dargestellt verbindet sich der OEM X Server 320 mit den nichtautonomen Fahrzeugen 351, 352 und 353 und der OEM Y Server 330 mit den nichtautonomen Fahrzeugen 354, 355 und 356 - die Fahrzeuge übertragen ihre Aktualisierungen an entsprechende Datenbanken auf dem OEM X Server 320 und dem OEM Y Server 330. Die Aktualisierungen werden anschließend zur Verifikation an Knoten der Blockchain übermittelt, die auf der Karten-Cloudplattform 310 implementiert ist. Wie bereits erwähnt können die Kartenaktualisierungen der Server 320 und 330 bereits in dem einheitlichen Format der Blockchain vorliegen oder müssen alternativ in dieses umgesetzt werden, bevor die Aktualisierungen zu einem Block in der Blockchain hinzugefügt werden können. Wie bereits erwähnt ist zu beachten, dass der Anbieter, der die Blockchain auf der Karten-Cloudplattform 310 verwaltet, jedem der für die Server 320 und 330 zuständigen Anbieter eine API zur Verfügung stellen kann, um ihre Kartenaktualisierungen an die Karten-Cloudplattform zu übermitteln.
Ähnlich wie die nichtautonomen Fahrzeuge übermitteln die in 3 dargestellten autonomen Fahrzeuge 357 und 358 ihre Aktualisierungen an einen Server 340, der beispielsweise von einem Entwickler einer autonomen Autoplattform (oder einem anderen Anbieter, der Teil des Ecosystems ist) betrieben wird. Server 340 kann beispielsweise bereits in einem Format übermitteln, das mit der auf Plattform 310 unterhaltenen Blockchain übereinstimmt. Dementsprechend kann der Server 340 die Kartenaktualisierungstransaktionen direkt an die Knoten der Blockchain übertragen, ohne eine Umsetzung zu erfordern. Es ist zu beachten, dass sowohl autonome als auch nichtautonome Fahrzeuge auch Kartenaktualisierungen von der Plattform 310 anfordern und beziehen können. In einer Ausführungsform können die Server 320, 330 und 340 Teil der Karten-Cloudplattform 310 sein und auch als Knoten der Blockchain ausgebildet sein.
In einer Ausführungsform kann die auf Plattform 310 ausgeführte Krypto-Engine eine blockchain-basierte Verifikation ermöglichen und Kartenaktualisierungen validieren, sobald ein Fahrzeug mit der Blockchain-Plattform verbunden ist. Dementsprechend kann die Blockchain-Plattform leicht hochskaliert werden, um den Fortschritt der Kartenaktualisierung in Echtzeit mit einem geeigneten Validierungsmechanismus und durch Alltagsfahrer, z.B. Fahrer von Fahrzeugen 351 bis 356, zu beschleunigen, anstatt dass eine Kartografiefirma, ein OEM oder ein anderer Anbieter im Kartografieecosystem ausschließlich auf Messwagen oder autonome Fahrzeuge angewiesen ist. Darüber hinaus ermöglicht es eine Verwendung der Blockchain-Plattform, die Kosten und Nutzen einer Aktualisierung von Karten auf mehrere Interessenträger, z.B. Endverbraucher, OEMs, Tier-1- bis Tier-3-Lieferanten usw. zu verteilen.
Darüber hinaus können Ausführungsformen der vorliegenden Erfindung bei Verwendung eines blockchain-basierten Kartografieecosystems vorteilhaft eine standardisierte Kartografieplattform mit einem einheitlichen Format bereitstellen, die das Problem der Kartenaktualisierung global löst und die Validierung von Kartenaktualisierungen demokratisiert. Weitere Herausforderungen im Zusammenhang mit herkömmlichen Kartografielösungen werden auch durch das Kartografieecosystem der vorliegenden Erfindung behandelt. Beispielsweise ermöglicht die Verwendung eines Blockchainmechanismus eine Rückverfolgbarkeit von Unregelmäßigkeiten, z.B. können alle bösartigen Aktualisierungen der Karte leicht erkannt, ihre Herkunft bestimmt und böswillige Updates entfernt werden, da Blockchains transparente und dezentral verteilte Datenbanken sind und jeder Block mit einem Zeitstempel versehen ist (und von einem vorhergehenden Block und einem nachfolgenden Block flankiert sein kann). Dadurch können Nutzer und Beitragende des MUT-basierten Systems für die Qualität der bereitgestellten Kartenaktualisierungen zur Verantwortung gezogen und ebenso für nützliche Aktualisierungen belohnt oder kompensiert werden. Darüber hinaus ermöglicht die Transparenz der Blockchain transparente Preise für einen Zugang zum Ecosystem, eine genaue Abrechnung und einen Mechanismus zur Belohnung von Fahrern und Anbietern für eine Bereitstellung genauer Kartenaktualisierungen, z.B. durch die Verwendung von MUTs.
Darüber hinaus ermöglichen es die Ausführungsformen der vorliegenden Erfindung durch die Einrichtung einer halböffentlichen Blockchain für das Kartografieecosystem vorteilhaft, einen Zugang zum Ecosystem zu steuern und die Privatsphäre seiner Mitglieder zu schützen.
In einer herkömmlichen Blockchain-Plattform erfolgt durch ein Netzwerk von kommunizierenden Knoten ein Unterhalt der Blockchain. Jeder Knoten validiert Transaktionen und fügt sie zu seiner eigenen lokalen Kopie der Blockchain hinzu, und sendet anschließend Blockadditionen an alle anderen Knoten. Alle diese Operationen werden so durchgeführt, dass zwischen den Netzwerkknoten ein verteilter Konsens über die in der Blockchain gespeicherten Informationen entsteht. Wenn ein Block gefälscht und der Kette hinzugefügt wird, werden andere Knoten die Daten als unwahr ermitteln. Beispielsweise wird in dem Kryptowährungssystem Bitcoin die Blockchain zur Speicherung von Finanztransaktionsdatensätzen verwendet. Bitcoin erreicht einen Konsens durch Verwendung eines Proof-of-Work-Algorithmus, der eingesetzt wird, um Transaktionen zu bestätigen und neue Blöcke in der Kette zu erzeugen. Bei Proof-of-Work liegt die Verantwortung für die Bestätigung von Transaktionen und die Anordnung von Blöcken (z.B. die Verwaltung von Blockzusätzen) bei speziellen Knoten, den sogenannten Minern, die darin miteinander konkurrieren, Transaktionen im Netzwerk abzuschließen und die belohnt werden.
Im Vergleich dazu und insbesondere erzielen Ausführungsformen der vorliegenden Erfindung einen Konsens für die Kartenaktualisierungen, die der Blockchain zur Verfügung gestellt werden, indem sie ein Tupel von mehreren Nachweisen verwenden, nämlich: a) einen Ortsnachweis (bei dem eine Lokalität einer Kartenaktualisierung durch andere Fahrzeuge verifiziert wird); b) ein Wiederholungsnachweis (bei dem eine bestimmte Aktualisierung erst nach Erhalt einer Reihe ähnlicher Aktualisierungen als wahr bestätigt wird); c) ein Sicherheitsnachweis (es wird eine Kombination aus verschiedenen Verfahren zur Risikovermeidung, Risikominderung, -vermeidung, - validierung und -genehmigung benutzt), der mindestens einen Nachweis aus der Menge der Sicherheitsnachweise umfasst, wie beispielsweise einen Nachweis einer funktionalen Sicherheit, einen Nachweis einer Sicherheit der vorgesehenen Funktion, einen Nachweis einer Systemsicherheit und dergleichen, und d) einen Nachweis einer physischen Lieferung (die Daten bestätigen Herkunft und Genauigkeit).
Es sollte beachtet werden, dass nicht alle Nachweise erforderlich sind, um einen Konsens zwischen den Knoten zu erzielen. Ein Konsens zwischen den Knoten kann mit weniger als allen vier hierin diskutierten Nachweisen erzielt werden. So können beispielsweise einige Ausführungsformen der vorliegenden Erfindung abhängig von der Wahl der Einrichtung und den Abhängigkeiten in einer solchen Einrichtung nur einen Ortsnachweis und einen Wiederholungsnachweis erfordern. Als weiteres Beispiel können einige Ausführungsformen zu einem bestimmten Zeitpunkt nur einen Nachweis erfordern, aber zu anderen Zeitpunkten kann ein Tupel von mindestens zwei Nachweisen verwendet werden. Ausführungsformen der vorliegenden Erfindung können dazu eingerichtet sein, dynamisch und austauschbar einen oder mehrere Nachweise aus dem Tupel der Nachweise auszuwählen, die auf mehreren Faktoren basieren, einschließlich aber nicht beschränkt auf verfügbare Sensorausführungen, externe Bedingungen und die Komplexität der Umgebung.
Ortsnachweis
Gemäß den Ausführungsformen der vorliegenden Erfindung führt die Blockchain 280 einen Ortsnachweis durch, um die Richtigkeit einer Lokalität zu überprüfen, die mit einer Kartenaktualisierungsübermittlung eines Anbieters oder Fahrzeugs verbunden ist. Um einen Konsens über den Ort eines eine Aktualisierung bereitstellenden Fahrzeugs zu erzielen ist eine zweite Kartenaktualisierungsübermittlung, die innerhalb einer Schwellenwertzeitdauer erfolgt und den Ort des Fahrzeugs bestätigt, das die erste Kartenaktualisierungsübermittlung bereitstellt, von mindestens einem anderen Fahrzeug in der Nähe des Fahrzeugs, das die Aktualisierung bereitstellt erforderlich, um den Ort des berichtenden Fahrzeugs zu validieren - dies bietet eine gewisse Bestätigung der Richtigkeit und Genauigkeit der berichteten Aktualisierung. Mit anderen Worten wären mindestens zwei autonome Fahrzeuge mit einer aktiven Verbindung zur Blockchain-Plattform erforderlich, um eine gültige Aktualisierung bereitzustellen, die auf dem Ort eines autonomen Fahrzeugs basiert. Oder alternativ müsste mindestens ein anderes Fahrzeug den Ort des berichtenden Fahrzeugs melden, damit die Kartenaktualisierung des berichtenden Fahrzeugs zumindest bezüglich seines berichteten Orts verifiziert werden kann.
4 ist ein Diagramm, das veranschaulicht, wie ein Ortsnachweis in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung erbracht werden kann. Wie bereits erwähnt ist ein autonomes Fahrzeug, das mit der autonomen Fahrzeugentwicklungsplattform 230 ausgebildet ist, normalerweise dazu in der Lage, sich präzise auf einer HD-Karte zu lokalisieren (auch bekannt als „Lokalisierung“). Wenn ein Auto 452 eine Aktualisierung mit Lokalisierungsinformationen an seinen jeweiligen Server berichtet, so muss die Aktualisierung normalerweise verifiziert werden, um sicherzustellen, dass das Auto 452 keine falschen Informationen meldet (entweder aufgrund von Fehlfunktion oder bösartigen Handelnden). Auf ähnliche Weise wird Auto 450 ebenso Lokalisierungsinformationen an seinen jeweiligen Server übertragen, die beglaubigt werden müssen. Da die Autos 450 und 452 in unmittelbarer Nähe zueinander stehen, können ihre jeweiligen Kameras und Sensoren die Position des jeweils anderen erfassen und bestätigen. So kann beispielsweise das Auto 450 die Lokalisierungsinformationen des Autos 452 bestätigen und umgekehrt. Jedes der Autos kann unabhängig seine Bestätigung des Ortes des jeweils anderen auch an seinen jeweiligen Server übermitteln. Tatsächlich können diese Lokalisierungsinformationen dem jeweiligen Server regelmäßig übermittelt werden.
In Blockchain-Netzwerken wird jede Transaktion, die an einen Server oder Knoten auf der Blockchain berichtet wird, normalerweise zu einem oder mehreren anderen Knoten übermittelt, um einen Konsens zu erzielen bevor die Transaktion in der Blockchain verzeichnet wird. Wenn die Autos 450 und 452 die Lokalisierungsinformationen und eine Bestätigung der jeweiligen Orte an ihre jeweiligen Server berichten, werden die Informationen an andere Knoten in der Blockchain verteilt. Danach können die Knoten einen Konsens darüber erzielen, dass die von jedem der Autos bereitgestellten Lokalisierungsinformationen tatsächlich genau sind. Mit den empfangenen Informationen kann der Server den Ort der Aktualisierung von Auto 452 mit dem berichteten Ort des Autos 450 abgleichen, das auch das Vorhandensein von Auto 452 in unmittelbarer Nähe berichtet. Dem Ortsnachweis wird entsprochen, wenn die orte übereinstimmen. Die Kartenaktualisierunginformationen können dann zu einem Block hinzugefügt und in der Blockchain verzeichnet werden (vorausgesetzt, die anderen Nachweise, die das Tupel von Nachweisen umfassen, sind ebenfalls gültig).
Wenn beispielsweise das Auto 452 Bestätigungsinformationen über den Standort des Autos 450 an seinen Server meldet, die von dem Auto 452 gemeldeten Informationen jedoch nicht mit den Lokalisierungsinformationen übereinstimmen, die von dem Auto 450 an seinen eigenen Server übermittelt werden, dann können beide Informationssätze als bösartig oder falsch gekennzeichnet und verworfen werden - es sei denn, es werden andere Bestätigungen empfangen, die entweder die von Auto 450 oder Auto 452 berichteten Informationen als genauer bestätigen.
Es sei darauf hingewiesen, dass eine Bereitstellung von Lokalisierungsinformationen nicht auf autonome Fahrzeuge beschränkt ist. Nichtautonome Fahrzeuge können auch mit der Intelligenz ihrer GPS-Systeme ausgebildet sein, um Lokalisierungsinformationen bereitzustellen, und sie können ferner mit Sensoren und Kameras ausgestattet sein, um Ortsbestätigungen für andere Fahrzeuge auf der Straße bereitzustellen.
Wiederholungsnachweis
In Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung verwendet die Blockchain Wiederholungsnachweise zur Verifikation einer Richtigkeit einer Kartenaktualisierung, was dazu beitragen kann, fehlerhafte Kartenaktualisierungen auszusortieren, die entweder durch Einrichtungen mit Fehlfunktion, mangelhafte und/oder fehlerhafte Softwarealgorithmen, mangelhafte und/oder fehlerhafte Klbasierte Wahrnehmungsalgorithmen und/oder böswillige Handelnde verursacht werden können. Mehrere Wiederholungen (z.B. mehrere Berichte) auf einer einzigen Fahrtroute sind erforderlich, um eine Kartenaktualisierung für eine bestimmte Fahrtroute zu validieren. Wenn beispielsweise zwei Fahrzeuge dieselbe Fahrtroute benutzen und einen ähnlichen Aktualisierungsbericht bezüglich der Fahrtroute bereitstellen, dann können ihre Aktualisierungen und ihre Fahrtrouten verglichen werden, und in Anschluss an eine Feststellung, dass beide Fahrzeuge dieselbe Fahrtroute genommen und dieselbe Aktualisierung bereitgestellt haben, kann die Fahrtroute als Kandidat für eine Kartenaktualisierung gekennzeichnet werden. Die Fahrtroute selbst kann eine neue Fahrtroute sein oder es kann eine neuerliche Aktualisierung einer bereits bestehenden Fahrtroute geben.
Anschließend ist für diese Fahrtroute eine vorgegebene Anzahl von konsistenten, bestätigenden Wiederholungen erforderlich, um die Blockchain zu aktualisieren. Wenn die Plattform beispielsweise prüft, ob eine neu entdeckte Fahrtroute hinzugefügt werden soll, falls die Anzahl der erforderlichen Iterationen 10 beträgt, dann müsste entweder ein Auto die gleiche Fahrtroute 10 mal nehmen oder 10 verschiedene Fahrzeuge würden jeweils die Fahrtroute einmal nehmen (oder jede andere Kombination von Autos und Malen, die insgesamt mindestens 10 Instanzen der gefahrenen Fahrtroute umfasst). Sobald die erforderliche Anzahl von Wiederholungen erzielt ist, werden die von den verschiedenen Fahrzeugen gesammelten Daten vereinheitlicht und der Blockchain hinzugefügt, um die neue Fahrtroute zu würdigen und der Karte hinzuzufügen. Ebenso muss eine vorgegebene Anzahl von Wiederholungen durchgeführt werden, falls die Plattform einer bereits bestehenden Fahrtroute eine neue Aktualisierung hinzufügen muss, z.B. infolge eines Unfalls oder von Bauarbeiten, damit diese Aktualisierung als gültige Aktualisierung in die Blockchain eingegliedert werden kann. Diese Aktualisierungen können von demselben Fahrzeug durchgeführt werden, das dieselbe Strecke mehrmals befährt, oder von mehreren Fahrzeugen, die dieselbe Strecke ebenfalls befahren. In einer Ausführungsform kann die Blockchain mindestens zwei verschiedene Fahrzeuge zur Durchführung der Wiederholungen vorschreiben, falls eines der Fahrzeuge ein bösartige Handelnder war oder aufgrund von Fehlfunktionen von Kameras, Sensoren und/oder Software gefährdende Daten bereitstellte.
5 veranschaulicht die Art und Weise, in welcher ein Wiederholungsnachweis in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung erbracht werden kann. Sowohl ein Auto 550 als auch ein Auto 552 fahren erstmals eine neue Fahrtroute, wobei das Auto 550 von West nach Ost fährt, während Auto 552 von Ost nach West fährt. Beide Fahrzeuge können durch den Vergleich der Fahrtrouten feststellen, dass sie auf der gleichen Strecke fahren. Zum Beispiel erfasst das Auto 550 das Gebäude 510 9,1m (zehn Yards) östlich und 27,4m (30 Yards) nördlich, während das Auto 552 das Gebäude 510 27,43m (30 Yards) westlich und 64m (70 Yards) nördlich erfasst. Ebenso können andere interessierende infrastrukturelle Punkte in der Peripherie, einschließlich des Appartementkomplexes 520, dazu genutzt werden, um mehrere andere Datenpunkte zu erzeugen, um die Positionen der Fahrzeuge zu triangulieren. Nachdem Daten über alle interessierenden Punkte an die Knoten übertragen und normiert wurden, verwenden die Knoten die normierten Daten, um zu versuchen, einen Konsens darüber zu erzielen, dass beide Autos auf derselben Strecke fahren. Mit anderen Worten verknüpfen die Knoten die Daten aus beiden Fahrzeugen über Kreuz und vergleichen diese, um zu sehen, ob sich die beiden Datensätze gegenseitig verstärken und unterstützen.
Es ist zu beachten, dass Autos nicht unbedingt aufeinander zu oder in entgegengesetzte Richtungen fahren müssen, um einen Kandidaten für eine Kartenaktualisierung zu erzeugen. In einigen Ausführungsformen können zwei Autos, die in die gleiche Richtung fahren (z.B. ein Mehrebenen-Straßennetz wie eine Überführung), auch einen Kandidaten für eine Kartenaktualisierung erzeugen, wenn die Knoten dazu in der Lage sind, die beiden Datensätze zu vergleichen und einen Konsens zu erzielen.
In Antwort auf eine Feststellung, dass beide Fahrzeuge die gleiche Strecke befahren haben und eine konsistente Aktualisierung geliefert haben, kann die Strecke als Kandidat für eine Kartenaktualisierung gekennzeichnet werden. Anschließend müssen möglicherweise mehrere Wiederholungen - entweder von den Fahrzeugen 550 oder 552 oder anderen Fahrzeugen - auf derselben Fahrtroute während eines vorbestimmten Zeitrahmens durchgeführt werden, um einen neuen Block auf der Blockchain zu erstellen, die die neue Fahrtroute umfasst. Wenn sich die beiden Datensätze nicht gegenseitig bestätigen, werden sie entweder verworfen oder zwischengespeichert, um zu sehen, ob weitere Aktualisierungen einen der Datensätze gegenüber dem anderen bestätigen können.
In einer Ausführungsform muss das Verfahren zum Bestimmen von Kartenaktualisierungen den Zeitpunkt der verschiedenen bereitgestellten Aktualisierungen berücksichtigen. Da die Blockchain die Zeitstempel der verschiedenen Transaktionen mitverfolgt, kann der zeitliche Ablauf für jede versuchte Aktualisierung leicht aus der Blockchain extrahiert werden. Beispielsweise muss für ein bestimmtes Kartensegment die erforderliche Anzahl von Wiederholungen innerhalb eines vorgegebenen Zeitrahmens erfolgen, um für eine gültige Kartenaktualisierung berücksichtigt zu werden. Wenn eine oder mehrere der Wiederholungen nicht die gleichen Informationen bestätigen wie die meisten der anderen Wiederholungen durch andere Fahrzeuge, können sie als von Fahrzeugen mit defekten Einrichtungen oder bösartigen Handelnden gemeldet zurückgewiesen werden. Wenn beispielsweise vierzig Durchgänge auf einer bestimmten Fahrtroute durchgeführt werden und alle bis auf zwei dieselben Daten bestätigen, können die beiden abweichenden Wiederholungen verworfen werden. Mehrere Durchgänge innerhalb eines vorgegebenen Zeitraums zu benötigen kann auch dabei helfen, zu vermeiden, dass kurzfristige Probleme auf einer bestimmten Fahrtroute in der Blockchain aktualisiert werden. Wenn beispielsweise ein Lieferwagen eine vorübergehende Blockade verursacht, kann es sein, dass nicht genügend Wiederholungen durchgeführt werden, um die vorübergehende Blockade als gültige Kartenaktualisierung auf der Blockchain zu akzeptieren, bevor die Blockade beseitigt wird.
Darüber hinaus werden Fahrzeuge, die zu späteren Zeitpunkten dieselbe Strecke befahren, in einer Ausführungsform die Kartenaktualisierung bestätigen. Die Kartenaktualisierung bleibt gültig, solange andere Fahrzeuge, die dieselbe Strecke befahren, die Aktualisierung weiterhin bestätigen. Wenn Änderungen an der Fahrtroute auftreten und die Kartenaktualisierung nicht mehr gültig ist, wird ein neuer Satz von Aktualisierungen von Fahrzeugen, die dieselbe Fahrtroute verwenden, geholt.
Beispielsweise kann eine Fahrtroute morgens durch Fahrzeuge, die die Fahrtroute befahren, aktualisiert werden, und es darf tagsüber keine wesentlichen Änderungen an der Fahrtroute geben. Danach bestätigen alle Fahrzeuge, die tagsüber auf derselben Strecke unterwegs sind, die morgens bereitgestellten Aktualisierungen und dementsprechend bleibt dieselbe Kartenaktualisierung den ganzen Tag über gültig. Wenn jedoch abends ein Teil der Strecke durch Bauarbeiten blockiert wird, müssen möglicherweise neue Updates von den Fahrzeugen geholt werden. Diese neuen Updates müssen das gleiche Validierungsverfahren durchlaufen, z.B. indem eine bestimmte Anzahl von Wiederholungen in einem vorgegebenen Zeitfenster erforderlich ist.
In einigen Ausführungsformen können bestimmte Arten von Aktualisierungen mit einer höheren Priorität gekennzeichnet werden, und es können weniger Wiederholungen erforderlich sein, um die Aktualisierungen mit hoher Priorität in die Blockchain zu bringen. Wenn beispielsweise ein Fahrzeug eine Aktualisierung für einen Krankenwagen oder ein Feuerwehrfahrzeug bereitstellt, können anstelle der erforderlichen 10 nur zwei Durchgänge erforderlich sein, um sie als gültige Kartenaktualisierung zu kennzeichnen.
Nachweis einer physischen Lieferung
Der Nachweis einer physischen Lieferung ist ein Konsens auf der Grundlage der Wertschöpfungskette der physischen Lieferung. Physischer Konsens wird durch eine Automatisierung des Datentransports von einem Fahrzeug zu einer digitalen Datenbank in einem Rechenzentrum für eine weitere KI-Verarbeitung erzielt. So kann beispielsweise ein Festkörperlaufwerk vom Eigentümer eines autonomen Fahrzeugs mit kartenbezogenen Daten ausgeliefert werden. In diesem Fall kann eine Nachverfolgungsnummer als Nachweis einer physischen Lieferung verwendet werden. Dadurch wird sowohl die Glaubwürdigkeit der Daten als auch deren Genauigkeit bestätigt. Als ein weiteres Beispiel kann ein von einem Anbieter betriebener Messwagen regelmäßig kartenbezogene Daten an die von einem Anbieter verwaltete digitale Datenbank senden müssen. In diesem Fall hilft ein physischer Liefernachweis, der in Form einer Nachverfolgungsnummer in die Blockchain aufgenommen werden kann, die Daten rückverfolgbar zu machen.
Ausführungsformen der vorliegenden Erfindung umfassen jedoch auch das Hochladen aller kartografierelevanten Informationen aus dem Auto direkt in das Anbieter-Rechenzentrum unter Verwendung von Hochgeschwindigkeits-Zellulär- oder -Wi-Fi-Verbindungen, falls Bandbreite verfügbar ist.
6 ist ein Datenflussdiagramm, das ein beispielhaftes rechnerimplementiertes Verfahren veranschaulicht, bei dem in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung ein Nachweis einer physischen Lieferung erbracht werden kann.
In Schritt 610 werden Daten von den an einem Fahrzeug angebrachten Sensoren erfasst.
Diese Daten können auf einem Festkörperlaufwerk im Fahrzeug gespeichert und in Schritt 620 an ein Rechenzentrum gesendet werden - eine Nachverfolgungsnummer wird als Nachweis einer physischen Lieferung gewonnen.
In Schritt 630 werden die Daten in der Karten-Cloudplattform 310 aufgenommen und kommentiert. Anschließend wird in Schritt 640 ein Training eines neuronalen Netzwerks mit den Daten durchgeführt. Mit anderen Worten werden die aus den Fahrzeugen gewonnenen Daten dazu verwendet, Lernprozesse eines mehrschichtigen neuronalen Netzwerks durchzuführen. Nachdem das neuronale Netzwerk in Schritt 650 trainiert wurde, wird es in Schritt 660 in autonomen Fahrzeuganwendungen und für eine Entwicklung autonomer Fahrzeugkartenanwendungen verwendet. Danach können in Schritt 670 die autonomen Fahrzeuge mit Echtzeitkarten probegefahren werden oder Simulationen mit Karten und Kartenaktualisierungen durchgeführt werden.
Sicherheitsnachweis
Der Kartenunterhaltserver kann einen Sicherheitsnachweis erbringen, um die Zuverlässigkeit mit genauen Kartenaktualisierungen zu gewährleisten. Beispielsweise kann Sicherheitsnachweis in einer Ausführungsform erfordern: a) Implementierungsredundanz und b) Implementierungsvielfalt. Eine Anforderung mehrerer verschiedener Nachweise (einer Vielzahl von Nachweisen) führt zu einer Implementierungsvielfalt. Ein Ortsnachweis, ein Wiederholungsnachweis und ein Nachweis einer physischen Lieferung, wie sie in den Ausführungsformen der vorliegenden Erfindung gefordert werden, bieten drei verschiedene oder verschiedenartige Mechanismen zur Validierung der Daten.
Eine Implementierungsredundanz wird dadurch erzielt, dass mehrere Quellen für dieselben Aktualisierungen oder eine ggf. mehrfache Wiederholung derselben Aktualisierung gefordert werden. Beispielsweise können innerhalb eines bestimmten Zeitraums mehrere Ortsnachweise erforderlich sein. Wenn sich zwei autonome Fahrzeuge in unmittelbarer Nähe befinden, können über einen Zeitraum mehrere Ortsnachweise erbracht werden, wobei jeder Ortsnachweis mit einem eindeutigen Zeitstempel versehen ist. Stimmen die mehreren Ortsnachweise innerhalb eines Zeitbereichs alle miteinander überein, so ist auch ein Sicherheitsnachweis erbracht.
Wie vorstehend erwähnt können Ausführungsformen der vorliegenden Erfindung dazu ausgebildet sein, dynamisch und austauschbar einen oder mehrere Nachweise aus dem Tupel der Nachweise auf Grundlage mehrerer Faktoren auszuwählen, einschließlich aber nicht beschränkt auf verfügbare Sensorausführungen, externe Bedingungen und die Komplexität der Umgebung. Jeder Knoten in dem Blockchain-Netzwerk kann mit der Intelligenz versehen sein, die Anzahl der Nachweise zu bestimmen, die für eine Validierung der Transaktion erforderlich sind. Wenn beispielsweise die Umgebung, für die die Kartenaktualisierung gilt, komplex ist oder die äußeren Witterungsbedingungen die Lokalisierung von Fahrzeugen herausfordernd gestalten, kann ein Knoten sowohl Ortsnachweise als auch Wiederholungen verlangen, um eine Kartenaktualisierungstransaktion zu validieren.
In einem anderen Szenario, wenn z.B. konsistente Informationen von mehreren Plattformen über Wiederholungen bezüglich einer bestimmten Fahrtroute empfangen werden, ist ein Ortsnachweis möglicherweise nicht erforderlich, damit ein Knoten eine Kartenaktualisierungstransaktion für die Fahrtroute validieren kann. In diesem Fall kann ein Knoten dynamisch wählen, ob er nur den Wiederholungsnachweis zur Validierung der Kartenaktualisierung heranziehen möchte. In einem anderen Szenario, in dem eine Aktualisierung eines hochempfindlichen, militärischen LiDAR in einem Umfeld ohne andere vorherrschende Komplexität empfangen wird, kann ein Ortsnachweis ausreichen, um die Transaktion zu validieren. Mit anderen Worten kann der Wiederholungsnachweis für eine Kartenaktualisierungstransaktion entfallen, die von zuverlässigen Sensorausführungen empfangen wird.
In einer oder mehreren Ausführungsformen werden die Informationen über das Tupel von Nachweisen in einer Datenstruktur innerhalb des mit einer Kartenaktualisierung verbundenen Datensatzes unterhalten. Die Datenstruktur ist dynamisch und kann Informationen über einen oder mehrere Nachweise umfassen, abhängig von der Anzahl der Nachweise, die zur Validierung der Transaktion erforderlich waren.
In einigen Ausführungsformen der vorliegenden Erfindung wird einem Block der Blockchain mit gültigem Zeitstempel erst dann eine Kartenaktualisierung hinzugefügt, wenn Sicherheitsnachweis erbracht ist.
7 zeigt ein Flussdiagramm eines beispielhaften rechnerimplementierten Verfahrens zur Validierung von Kartenaktualisierungen unter Verwendung einer Blockchain in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
In Schritt 702 wird eine Blockchain auf Server verteilt, die Teil der Karten-Cloudplattform 250 sind, und die Daten zum Unterhalt einer globalen Karte eines vorbestimmten geografischen Bereichs umfasst. Die Blockchain kann entweder auf dedizierten Knoten innerhalb der Karten-Cloudplattform unterhalten werden (z.B. Blockchain 260) oder könnte auch Server der verschiedenen Anbieter (z.B. Blockchain 280) umfassen. Zu den Anbietern können Kartografiefirmen, OEMs, Softwareanbieter, Kartenaktualisierungsfirmen, Halbleiterfirmen, Firmen, die Feldvergleichsdaten liefern, Tier-1-Lieferanten usw. gehören. Die Blöcke der Blockchain umfassen Datensätze, wobei sich die Datensätze auf Aktualisierungen der globalen Karte beziehen.
In Schritt 704 wird eine Nachricht empfangen, die im Zusammenhang mit einer Kartenaktualisierung der globalen Karte steht. Die Nachricht kann entweder von einem Fahrzeug oder einem der Anbieter in dem Kartografieecosystem übertragen werden. Die Nachricht kann sich auf eine Kartenaktualisierung für eine bestimmte Fahrtroute beziehen und mit einem Zeitstempel versehen sein.
In Schritt 706 wird die empfangene Kartenaktualisierung von einem oder mehreren Knoten in der Blockchain ausgewertet, um einen Konsens darüber zu erzielen, ob es sich um ein genaues Update handelt. Um einen Konsens zu erzielen umfasst die Auswertung eine Auswahl und Durchführung von mindestens einem aus einer Vielzahl von Nachweisen, einschließlich einem Ortsnachweis, einem Wiederholungsnachweis, einem physischen Liefernachweis und einem Sicherheitsnachweis. In einer Ausführungsform kann die Auswahl eines oder mehrerer Nachweise zum Teil auf einer Reihe von Faktoren beruhen, z.B. auf verfügbaren Sensorausführungen, externen Bedingungen und der Komplexität der Umgebung.
In Schritt 708 wird bestimmt, ob ein Konsens erzielt wurde und ob die Nachweise die Kartenaktualisierung validiert haben. Wenn die Kartenaktualisierung nicht validiert wurde, wird die Nachricht in Schritt 716 verworfen oder zwischengespeichert, bis eine weitere Auswertung erfolgen kann. So kann beispielsweise die Nachricht gespeichert werden, um auf zukünftige Aktualisierungen zu warten, die die mit der Nachricht im Zusammenhang stehende Kartenaktualisierung bestätigen oder verneinen können.
Wenn die Kartenaktualisierung validiert wurde, wird in Schritt 710 ein Datensatz erzeugt, wobei der Datensatz im Zusammenhang mit der empfangenen Kartenaktualisierung steht. Der Datensatz kann Teil anderer Datensätze sein, die zu einem neuen Block in der Blockchain hinzugefügt werden.
In Schritt 712 wird die Blockchain mit dem neuen Datensatz aktualisiert und die globale Karte wird auf Grundlage der Kartenaktualisierung in dem neuen Datensatz aktualisiert. In Schritt 714 kann die aktualisierte Blockchain an andere Knoten in der Blockchain übertragen werden. Die anderen Knoten können beispielsweise ihre lokalen Kopien der Blockchain aktualisieren und eine weitere Validierung durchführen.
8 zeigt ein Flussdiagramm eines beispielhaften rechnerimplementierten Verfahrens zum Unterhalt von Kartendaten unter Verwendung einer Blockchain in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung.
In Schritt 802 wird eine Blockchain auf einem Server (oder Knoten) gespeichert, der Teil einer Blockchain ist. Die Blockchain ist auf Server verteilt, die Teil der Karten-Cloudplattform 250 sind, und umfasst Daten zum Unterhalt einer globalen Karte eines vorgegebenen geografischen Bereichs. Die Blockchain kann entweder auf dedizierten Knoten innerhalb der Karten-Cloudplattform unterhalten werden (z.B. Blockchain 260) oder könnte auch Server der verschiedenen Anbieter (z.B. Blockchain 280) umfassen. Die Blöcke der Blockchain umfassen Datensätze, wobei sich die Datensätze auf Aktualisierungen der globalen Karte beziehen.
In Schritt 804 wird durch den Server eine erste Nachricht von einem ersten Client empfangen, wobei die erste Nachricht im Zusammenhang mit einer ersten Kartenaktualisierung auf der globalen Karte steht. Die Meldung kann sich auf eine Kartenaktualisierung für eine bestimmte Fahrtroute beziehen. Die Kartenaktualisierung kann bereits im einheitlichen Format der Blockchain erfolgen und muss möglicherweise nicht weiter formatiert werden.
In Schritt 806 wird eine zweite Nachricht auf dem Server von einem zweiten Client empfangen, wobei die zweite Nachricht im Zusammenhang mit einer zweiten Kartenaktualisierung auf der globalen Karte steht. Die Nachricht kann sich auf eine Kartenaktualisierung für eine bestimmte Fahrtroute beziehen, jedoch kann die zweite Nachricht im Gegensatz zur ersten Nachricht in einem herstellerspezifischen Format vorliegen und muss möglicherweise formatiert werden, um sie mit dem Blockchain-Format vereinbar zu machen.
In Schritt 808 werden der erste und der zweite Client vom Server als mit gültigen Abonnements oder Zugriffsrechten für den Zugriff auf die Blockchain beglaubigt.
In Schritt 810 wird die zweite Nachricht aus dem herstellerspezifischen Format in ein einheitliches Format umgewandelt, das von der Blockchain unterstützt wird.
In Schritt 812 werden die erste und zweite Kartenaktualisierung ausgewertet. Die Auswertung umfasst die Durchführung eines Nachweises, um die Aktualisierungen als genau zu validieren.
In Schritt 814 wird die Blockchain mit einem neuen Datensatz basierend auf den ersten und zweiten Kartenaktualisierungen aktualisiert und die globale Karte wird basierend auf den Kartenaktualisierungen im neuen Datensatz aktualisiert.
In Schritt 816 werden Token-Konten für den ersten und zweiten Client aktualisiert, wobei die Token-Konten Zugriffsrechte auf die Blockchain definieren. Wie bereits erwähnt können die MUTs in einer oder mehreren Ausführungsformen dazu verwendet werden, einen Zugriff auf die Kartografiedaten auf der Blockchain zu steuern. So kann die Karten-Cloudplattform 250 beispielsweise mittels verschlüsselten Schlüsseln und/oder intelligenten Verträgen nur solchen Mitgliedern des Ecosystems Kartenaktualisierungen zur Verfügung stellen, die über eine für den Erwerb der Updates erforderliche Anzahl von MUTs verfügen. Mit anderen Worten können die MUTs als Währung verwendet werden, um Kartenaktualisierungen zu kaufen oder zu verkaufen. Wie bereits erwähnt können die MUTs gemäß einer oder mehrerer Ausführungsformen an einen finanziellen Anreiz gebunden sein, den ein Fahrer oder Anbieter erhält, um eine bestimmte Anzahl genauer Kartenaktualisierungen bereitzustellen. Alternativ können die MUTs gegen Gutschriften eingetauscht werden, die einen Fahrer oder Anbieter dazu berechtigen, eine bestimmte Anzahl von Kartenaktualisierungen kostenlos aus dem Kartografiesystem zu beziehen.
9 ist ein Datenflussdiagramm, das ein beispielhaftes rechnerimplementiertes Verfahren zur Aktualisierung eines mit einem Client im Zusammenhang stehenden Token-Kontos in Übereinstimmung mit einer Ausführungsform der vorliegenden Erfindung veranschaulicht.
In Schritt 902 wird eine Nachricht von einem Client empfangen, z.B. einem autonomen Fahrzeug, einem Messwagen usw. Es ist zu beachten, dass Nachrichten auch von Anbietern empfangen werden können, z.B. von Kartografiefirmen, OEMs, Softwareanbieterfirmen, Halbleiterfirmen, Firmen, die Feldvergleichsdaten liefern, Tier-1-Lieferanten, usw. Die Nachricht kann entweder eine Aufforderung zum Bereitstellen einer Aktualisierung einer globalen Karte oder zum Herunterladen einer Kartenaktualisierung aus der auf der Cloudplattform unterhaltenen Blockchain umfassen.
Wenn die Nachricht eine Aufforderung zum Bereitstellen einer Kartenaktualisierung umfasst, wird in Schritt 904 ein dem Client zugeordnetes Abonnementkonto geprüft, um zu bestimmen, ob der Client über ein gültiges und aktives Abonnement für die Kartografieplattform verfügt.
Anschließend kann in Schritt 906 eine mit einem Client verbundene Reputation geprüft werden, um zu bestimmen, ob die Reputation über einem Schwellenwert liegt. Liegt die Reputation über dem geforderten Schwellenwert, so kann es dem Client gestattet werden, Aktualisierungen an der Blockchain vorzunehmen. In einer Ausführungsform können MUTs auch verwendet werden, um die Reputation und die Glaubwürdigkeit eines bestimmten Fahrers oder Anbieters zu ermitteln. Ein Fahrer kann sich einen Reputationswert aufbauen, indem er Aktualisierungen einbringt, die nicht korrigiert oder durch genauere Daten aus anderen Quellen ersetzt werden. Fahrer mit hohen Reputationswerten können mit MUTs belohnt und mit einem privaten Schlüssel für eine Bereitstellung ihrer Aktualisierungen für die Cloudplattform versehen werden.
In Schritt 908 wird die empfangene Kartenaktualisierung von einem oder mehreren Knoten in der Blockchain ausgewertet, um den Konsens darüber zu erzielen, ob es sich um ein genaues Update handelt. Wie bereits erwähnt umfasst die Auswertung, um einen Konsens zu erzielen, eine Auswahl und Durchführung von mindestens einem aus einer Vielzahl von Nachweisen, einschließlich einem Ortsnachweis, einem Wiederholungsnachweis, einem physischen Liefernachweis und einem Sicherheitsnachweis. In einer Ausführungsform kann die Auswahl eines oder mehrerer Nachweise zum Teil auf einer Reihe von Faktoren beruhen, z.B. auf verfügbaren Sensorausführungen, externen Bedingungen und der Komplexität der Umgebung.
Wenn die Kartenaktualisierung validiert wurde, wird in Schritt 910 ein Datensatz erzeugt, wobei der Datensatz im Zusammenhang mit der empfangenen Kartenaktualisierung steht. Der Datensatz kann Teil anderer Datensätze sein, die zu einem neuen Block in der Blockchain hinzugefügt werden.
In Schritt 912 wird das dem Client zugeordnete MUT-Konto angepasst. Wenn beispielsweise die Aktualisierung validiert und als korrekt anerkannt wurde, kann der Client mehr Token erhalten und der Saldo des MUT-Kontos entsprechend erhöht werden.
Wenn die empfangene Nachricht in Schritt 902 in Zusammenhang mit einer Anforderung zum Beziehen einer Kartenaktualisierung steht, wird in Schritt 914 ein dem Client zugeordnetes Abonnementkonto geprüft, um zu bestimmen, ob der Client über ein gültiges und aktives Abonnement für die Kartografieplattform verfügt. Ferner wird in Schritt 916 auch ein dem Client zugeordnetes MUT-Konto geprüft, um zu bestimmen, ob der Client über genügend Token verfügt, um Kartenaktualisierungen zu beziehen.
Wenn der Client über Zugriffsrechte und genügend MUTs im MUT-Konto verfügt, wird dem Client in Schritt 918 in Übereinstimmung mit der Anforderung eine Kartenaktualisierung zur Verfügung gestellt.
Schließlich wird in Schritt 920 das dem Client zugeordnete MUT-Konto angepasst. So kann beispielsweise der Saldo auf dem MUT-Konto vermindert werden, um den Bezug neuer Kartenaktualisierungen durch den Client widerzuspiegeln.
Beispielhaftes Rechensystem
Wie in 10 dargestellt weist ein beispielhaftes System zur Implementierung von Ausführungsformen eine allgemeine Rechnersystemumgebung auf, wie beispielsweise das Rechnersystem 1000. Beispielsweise kann das Rechnersystem 1000 verwendet werden, um einen der Server (oder Knoten) auf der Blockchain in der Karten-Cloudplattform, bei der die Updates empfangen werden, zu implementieren. In seiner grundlegendsten Ausführung weist das Rechnersystem 1000 normalerweise zumindest eine Verarbeitungseinheit 1001 und Speicher sowie einen Adress-/Datenbus 1009 (oder eine andere Schnittstelle) zur Übermittlung von Informationen auf. Je nach genauer Ausführung und Art der Rechnersystemumgebung kann der Speicher flüchtig (z.B. RAM 1002), nichtflüchtig (z.B. ROM 1003, Flash-Speicher, usw.) oder eine Kombination aus beidem sein. Das Rechnersystem 1000 kann auch ein oder mehrere Grafiksubsysteme 1005 umfassen, um dem Rechnerbenutzer Informationen darzustellen, z.B. durch eine Anzeige von Informationen auf einer angeschlossenen Anzeigevorrichtung 1010.
Darüber hinaus kann das Rechnersystem 1000 auch zusätzliche Merkmale und Funktionen aufweisen. Beispielsweise kann das Rechnersystem 1000 auch zusätzlichen Speicher (wechselbar und/oder nicht wechselbar) aufweisen, einschließlich, aber nicht beschränkt auf, magnetische oder optische Platten, oder Bänder. Ein solcher zusätzlicher Speicher ist in 10 durch die Datenspeichereinrichtung 1004 dargestellt. Da die Blockchain der vorliegenden Erfindung eine verteilte Datenbank ist, können Teile des Blockchain-Hauptbuches auf der Datenspeichervorrichtung 1004 implementiert werden. Computerspeichermedien umfassen flüchtige und nichtflüchtige, entfernbare und nicht entfernbare Medien, die in einem Verfahren oder einer Technologie zur Speicherung von Informationen wie computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen oder anderen Daten implementiert sind. RAM 1002, ROM 1003 und Datenspeichereinrichtung 1004 sind Beispiele für Computerspeichermedien.
Das Rechnersystem 1000 umfasst auch eine optionale alphanumerische Eingabeeinrichtung 1006, eine optionale Cursorsteuerungs- oder Leiteinrichtung 1007 und eine oder mehrere Signalübertragungsschnittstellen (Ein-/Ausgabeeinrichtungen, z.B. eine Netzwerkschnittstellenkarte) 1008. Die optionale alphanumerische Eingabeeinrichtung 1006 kann Informationen und Befehlsauswahlen an den Zentralprozessor 1001 übermitteln. Die optionale Cursorsteuerung oder Steuerungseinrichtung 1007 ist mit dem Bus 1009 gekoppelt, um Benutzereingaben und Befehlsauswahlen an den Zentralprozessor 1001 zu übermitteln. Die Signal-Kommunikationsschnittstelle (Ein-/Ausgabeeinrichtung) 1008, die ebenfalls an den Bus 1009 gekoppelt ist, kann eine serielle Schnittstelle sein. Die Kommunikationsschnittstelle 1009 kann auch drahtlose Kommunikationsmechanismen aufweisen. Mit der Kommunikationsschnittstelle 1009 kann das Rechnersystem 1000 über ein Kommunikationsnetzwerk wie das Internet oder ein Intranet (z.B. ein lokales Netzwerk) kommunikativ mit anderen Rechnersystemen gekoppelt werden oder Daten (z.B. ein digitales Fernsehsignal) empfangen.
In der vorstehenden Spezifikation wurden Ausführungsformen mit Bezug auf zahlreiche spezifische Details beschrieben, die von Implementierung zu Implementierung variieren können. Somit ist der einzige und ausschließliche Indikator dafür, was die Erfindung ist und was der Anmelder als Erfindung erachtet, der Satz von Ansprüchen, die sich aus dieser Anmeldung ergeben, in der spezifischen Form, in der diese Ansprüche geltend gemacht werden, einschließlich späterer Korrekturen. Daher sollte keine Einschränkung, Element, Eigenschaft, Merkmal, Vorteil oder Attribut, die nicht ausdrücklich in einem Anspruch erwähnt wird, den Schutz, den ein solcher Anspruchs verleiht, in irgendeiner Weise einschränken. Dementsprechend sind die Spezifikationen und Zeichnungen eher im illustrativen als im beschränkenden Sinne zu betrachten.

Claims

Verfahren zum Aktualisieren von Kartendaten unter Verwendung einer Blockchain, wobei das Verfahren umfasst: Speichern einer Blockchain, wobei die Blockchain eine verteilte Datenbank mit einer Vielzahl von Datensätzen ist, wobei jeder Datensatz in einem Zusammenhang mit einer Aktualisierung einer globalen Karte steht, und wobei die Blockchain ferner Daten zum Unterhalt der globalen Karte eines vorbestimmten geographischen Bereichs umfasst; Empfangen einer Nachricht, die in einem Zusammenhang mit einer Kartenaktualisierung für die globale Karte steht, wobei die Nachricht Informationen über eine Kartenaktualisierung für eine bestimmte Fahrtroute umfasst; Validieren der Kartenaktualisierung durch Auswerten eines Konsenses in Bezug auf die Kartenaktualisierung, wobei das Auswerten ein Auswählen und Durchführen von mindestens einem aus einer Vielzahl von Nachweisen für die Kartenaktualisierung umfasst; in Antwort auf eine erfolgreiche Validierung der Kartenaktualisierung über mindestens einen der Vielzahl von Nachweisen, Erzeugen eines der Kartenaktualisierung zugeordneten Datensatzes; Aktualisieren der Blockchain, um den erzeugten Datensatz aufzunehmen, um die globale Karte basierend auf der Kartenaktualisierung zu aktualisieren; und elektronisches Übertragen des erzeugten Datensatzes an eine Vielzahl von Knoten in der Blockchain.
Verfahren nach Anspruch 1, wobei die Blockchain eine halböffentliche verteilte Datenbank ist.
Verfahren nach Anspruch 1 oder 2, wobei das Empfangen der Nachricht das Empfangen der in einem proprietären Datenformatstandard eines Anbieters formatierten Nachricht umfasst, und ferner umfasst: vor dem Bestimmen, Konvertieren der Nachricht aus dem proprietären Datenformatstandard des Anbieters in den mit der Blockchain vereinbaren Datenformatstandard.
Verfahren wie in einem der vorhergehenden Ansprüche beschrieben, wobei die Vielzahl von Nachweisen einen oder mehrere Nachweise umfasst, die aus der Gruppe von Nachweisen ausgewählt ist/sind, die umfasst: einen Ortsnachweis; einen Wiederholungsnachweis; einen Nachweis einer physischen Lieferung; und einen Sicherheitsnachweis.
Verfahren wie in einem der vorhergehenden Ansprüche beschrieben, wobei die Vielzahl von Nachweisen einen oder mehrere Nachweise umfasst, die aus der Gruppe von Nachweisen ausgewählt ist/sind, die umfasst: einen Ortsnachweis, einen Wiederholungsnachweis, einen Nachweis einer physischen Lieferung und einen Sicherheitsnachweis, und wobei die Auswahl des mindestens einen aus der Vielzahl von Nachweisen auf mindestens einer aus den verfügbaren Sensorausführungen, den externen Bedingungen und der Komplexität der Umgebung basiert.
Verfahren wie in einem der vorhergehenden Ansprüche beschrieben, wobei die Vielzahl der Nachweise einen oder mehrere Nachweise umfasst, die aus der Gruppe von Nachweisen ausgewählt sind, die umfasst: einen Ortsnachweis, einen Wiederholungsnachweis, einen Nachweis einer physischen Lieferung und einen Sicherheitsnachweis, und wobei das Durchführen des Ortsnachweises ein Validieren einer Kartenaktualisierung umfasst, die von einer ersten mobilen Einheit empfangen wurde, nachdem ein Ort der ersten mobilen Einheit durch eine Kartenaktualisierung einer zweiten mobilen Einheit verifiziert wurde.
Verfahren wie in einem der vorhergehenden Ansprüche beschrieben, wobei die Vielzahl der Nachweise einen oder mehrere Nachweise umfasst, die aus der Gruppe von Nachweises ausgewählt sind, die umfasst: einen Ortsnachweis, einen Wiederholungsnachweis, einen Nachweis einer physischen Lieferung, und einen Sicherheitsnachweis, wobei das Durchführen der Wiederholungsnachweise ein Validieren einer von einer ersten mobilen Einheit empfangenen Kartenaktualisierung umfasst, nachdem die Kartenaktualisierung der ersten mobilen Einheit durch eine analoge Kartenaktualisierung einer zweiten mobilen Einheit verifiziert wurde, und nachdem eine mit der Kartenaktualisierung der ersten mobilen Einheit verbundene Fahrtroute mindestens einmal von einer oder mehreren mobilen Einheiten überprüft wurde.
Verfahren wie in einem der vorstehenden Ansprüche beschrieben, wobei die Vielzahl der Nachweise einen oder mehrere Nachweise umfasst, die aus der Gruppe von Nachweis ausgewählt sind, die umfasst: einen Ortsnachweis, einen Wiederholungsnachweis, einen Nachweis einer physischen Lieferung und einen Sicherheitsnachweis, wobei das Durchführen eines Nachweises einer physischen Lieferung umfasst: Automatisieren einer Lieferung von Daten, die in einem Zusammenhang mit der globalen Karte stehen, und entsprechender Kartenaktualisierungen an ein Rechenzentrum, in dem der Server unterhalten wird; und Hinzufügen einer in einem Zusammenhang mit der Lieferung stehenden Nachverfolgungsnummer zur Blockchain.
Verfahren wie in einem der vorstehenden Ansprüche beschrieben, wobei die Vielzahl der Nachweise einen oder mehrere Nachweise umfasst, die aus der Gruppe von Nachweisen ausgewählt sind, die umfasst: einen Ortsnachweis, einen Wiederholungsnachweis, einen Nachweis einer physischen Lieferung und einen Sicherheitsnachweis, wobei das Durchführen des Sicherheitsnachweises ein Durchführen mehrerer Durchgänge für den Ortsnachweis und den Wiederholungsnachweis umfasst.
Verfahren wie in einem der vorhergehenden Ansprüche beschrieben, ferner umfassend ein Verarbeiten der Blockchain zum Bestimmen eines bestimmten Ursprungs einer bestimmten Kartenaktualisierung.
Verfahren wie in einem der vorstehenden Ansprüche beschrieben, ferner umfassend: Verarbeiten der Blockchain, um einen bestimmten Ursprung einer Vielzahl von Kartenaktualisierungen zu bestimmen; und in Antwort auf eine Bestimmung, dass die Vielzahl von Kartenaktualisierungen genau ist und auf einer bestimmten Anzahl der Vielzahl von Kartenaktualisierungen basieren, Bereitstellen einer Schwellenwertkompensation für einen Anbieter, der in einem Zusammenhang mit dem bestimmten Ursprung steht.
Verfahren wie in einem der vorstehenden Ansprüche beschrieben, ferner umfassend: Verarbeiten der Blockchain, um einen bestimmten Ursprung einer Vielzahl von Kartenaktualisierungen zu bestimmen; und in Antwort auf eine Bestimmung, dass die Vielzahl von Kartenaktualisierungen genau ist und auf einer bestimmten Anzahl der Vielzahl von Kartenaktualisierungen basieren, Bereitstellen eines Schwellenwertgrades von globalem Kartenzugriff für einen Anbieter, der in einem Zusammenhang mit dem bestimmten Ursprung steht.
Verfahren wie in einem der vorstehenden Ansprüche beschrieben, ferner umfassend: Verarbeiten der Blockchain, um einen bestimmten Ursprung für eine Vielzahl von Kartenaktualisierungen zu bestimmen; und in Antwort auf eine Bestimmung, dass die Vielzahl von Kartenaktualisierungen genau ist und auf einer bestimmten Anzahl der Vielzahl von Kartenaktualisierungen basieren, Zuweisen eines Reputationswerts an einen Anbieter, der in einem Zusammenhang mit dem bestimmten Ursprung steht.
Verfahren wie in einem der vorhergehenden Ansprüche beschrieben, wobei die Nachricht von einem Anbieter empfangen wird, der in einem Zusammenhang mit einem Kartografieecosystem steht, das die globale Karte umfasst, wobei der Anbieter aus einer Gruppe ausgewählt ist, die umfasst: einen oder mehrere Erstausrüster (OEMs), einen oder mehrere Hersteller von GPS-Einrichtungen (Global Positioning System), einen oder mehrere Anbieter von Kartografiesoftware, einen oder mehrere Entwickler autonomer Fahrzeugentwicklungsplattformen, einen oder mehrere Tier-1-Lieferanten und eine oder mehrere Firmen, die Feldvergleichsdaten liefern.
Verfahren wie in einem der vorhergehenden Ansprüche beschrieben, wobei ein Server, der die Nachricht empfängt, in einer Cloudplattform unterhalten wird, wobei die Cloudplattform Server zum Speichern der Blockchain und Server zum Speichern von Daten, die in einem Zusammenhang mit jeweiligen Anbietern stehen, umfasst.
Verfahren nach Anspruch 15, wobei die Cloudplattform von einem Anbieter verwaltet wird, der in einem Zusammenhang mit dem Kartografieecosystem steht.
Verfahren wie in einem der vorhergehenden Ansprüche beschrieben, wobei die Nachricht von einem Fahrzeug empfangen wird, wobei das Fahrzeug ausgewählt ist aus einer Gruppe bestehend aus: autonomen Fahrzeugen und nichtautonomen Fahrzeugen.
Verfahren wie in einem der vorstehenden Ansprüche beschrieben, ferner umfassend: Empfangen einer Nachricht, die in einem Zusammenhang mit einer Anforderung für eine Kartenaktualisierung von einem Client steht; Überprüfen einer Anzahl von Token in einem dem Client zugeordneten Token-Konto, um zu bestimmen, ob der Client Zugriffsrechte auf die globale Karte hat; und in Antwort auf eine Bestimmung, dass der Client eine Schwellenwertanzahl von Token im Token-Konto hat, Bereitstellen einer Antwort auf die Anforderung.
Serverbasiertes Verfahren zum Verwalten von Kartendaten, wobei das Verfahren umfasst: Unterhalten einer elektronischen Karte eines geografischen Gebiets auf einem Server, wobei die elektronische Karte als eine Vielzahl von Datensätzen dargestellt ist, die in einer Blockchain gespeichert sind, wobei jeder Datensatz die in einem Zusammenhang mit einer Aktualisierung der elektronischen Karte steht, wobei die Blockchain eine halböffentliche verteilte Datenbank ist; Empfangen einer Vielzahl von Kartenaktualisierungskommunikation von einer Vielzahl von mobilen Einheiten, wobei jede Kartenaktualisierungskommunikation in einem einheitlichen Datenformatstandard formatiert ist, der mit der Blockchain vereinbar ist, und einen entsprechenden Kartenaktualisierungsdatensatz umfasst, wobei jede mobile Einheit einer Entität zugeordnet ist, die sich nicht in einem gemeinsamen Unternehmen mit der Server-Entität befindet; Akzeptieren und Validieren einer Teilmenge von Kartenaktualisierungsdatensätzen, die in einem Zusammenhang mit der Kartenaktualisierungskommunikation stehen, durch Auswählen und Anwenden zumindest eines aus einer Vielzahl von Nachweisen auf Kartenaktualisierungsdatensätzen der Kartenaktualisierungskommunikation; Aktualisieren der elektronischen Karte auf Grundlage der Teilmenge der Kartenaktualisierungsdatensätzen, um eine aktualisierte elektronische Karte zu erstellen; und elektronisches Übertragen der Teilmenge von Kartenaktualisierungsdatensätzen zum Empfang durch eine entfernte mobile Einheit.
Verfahren nach Anspruch 19, wobei die Vielzahl von Nachweisen einen oder mehrere Nachweise umfasst, die aus der Gruppe von Nachweisen ausgewählt sind, die umfasst: Ortsnachweise, Wiederholungsnachweise, Sicherheitsnachweise und Nachweise für physische Lieferprozesse.
Verfahren nach Anspruch 19 oder 20, wobei jede der Vielzahl von mobilen Einheiten dazu eingerichtet ist, Kartenaktualisierungskommunikation an den Server zu übertragen, vorausgesetzt, sie hat ein aktives Abonnement mit Zugriffsrechten auf die elektronische Karte.
Verfahren nach einem der Ansprüche 19 bis 21, wobei die Vielzahl der Nachweise einen oder mehrere Nachweise umfasst, die aus der Gruppe der Nachweise ausgewählt sind, die umfasst: Ortsnachweise, Wiederholungsnachweise, Sicherheitsnachweise und Nachweise für physische Lieferprozesse, und wobei das Durchführen des Ortsnachweises ein Validieren einer Kartenaktualisierung umfasst, die von einer ersten mobilen Einheit empfangen wurde, nachdem ein Ort der ersten mobilen Einheit durch eine Kartenaktualisierung einer zweiten mobilen Einheit verifiziert wurde.
Verfahren nach einem der Ansprüche 19 bis 22, wobei die Vielzahl der Nachweise einen oder mehrere Nachweise umfasst, die aus der Gruppe der Nachweise ausgewählt sind, die umfasst: Ortsnachweise, Wiederholungsnachweise, Sicherheitsnachweise und Nachweise physischer Lieferprozesse, und wobei das Durchführen des Wiederholungsnachweises ein Validieren einer von einer ersten mobilen Einheit empfangenen Kartenaktualisierung umfasst, nachdem die Kartenaktualisierung der ersten mobilen Einheit durch eine analoge Kartenaktualisierung einer zweiten mobilen Einheit verifiziert wurde, und nachdem eine mit der Kartenaktualisierung der ersten mobilen Einheit verbundene Fahrtroute mindestens einmal von einer oder mehreren mobilen Einheiten überprüft wurde.
Verfahren nach einem der Ansprüche 19 bis 23, wobei die Vielzahl der Nachweise einen oder mehrere Nachweise umfasst, die aus der Gruppe der Nachweise ausgewählt sind, die umfasst: Ortsnachweise, Wiederholungsnachweise, Sicherheitsnachweise und Nachweise für physische Lieferprozesse, und wobei das Durchführen eines Nachweises einer physischen Lieferung umfasst: Automatisieren einer Lieferung von Daten, die in einem Zusammenhang mit der globalen Karte stehen, und entsprechender Kartenaktualisierungen an ein Rechenzentrum, in dem der Server unterhalten wird; und Hinzufügen einer in einem Zusammenhang mit der Lieferung stehenden Nachverfolgungsnummer zur Blockchain.
Verfahren nach einem der Ansprüche 19 bis 24, wobei die Vielzahl der Nachweise einen oder mehrere Nachweise umfasst, die aus der Gruppe der Nachweise ausgewählt sind, die umfasst: Ortsnachweise, Wiederholungsnachweise , Sicherheitsnachweise und Nachweise für physische Lieferprozesse, und wobei das Durchführen des Sicherheitsnachweises ein Durchführen mehrerer Durchgänge für den Ortsnachweis und den Wiederholungsnachweis umfasst.
Verfahren zum Aktualisieren von Kartendaten unter Verwendung einer Blockchain, wobei das Verfahren umfasst: Speichern einer Blockchain, wobei die Blockchain eine verteilte Datenbank mit einer Vielzahl von Datensätzen ist, wobei jeder Datensatz in einem Zusammenhang mit einer Aktualisierung einer globalen Karte steht, und wobei die Blockchain ferner Daten zum Unterhalt der globalen Karte eines vorbestimmten geographischen Bereichs umfasst; Empfangen einer Nachricht, die in einem Zusammenhang mit einer Kartenaktualisierung für die globale Karte steht, wobei die Nachricht Informationen über eine Kartenaktualisierung für eine bestimmte Fahrtroute umfasst; Validieren der Kartenaktualisierung durch Auswerten eines Konsenses in Bezug auf die Kartenaktualisierung, wobei das Auswerten ein Durchführen einer Vielzahl von Nachweisen mit zumindest einem Wiederholungsnachweis umfasst; in Antwort auf eine erfolgreiche Validierung der Kartenaktualisierung über mindestens einen der Vielzahl von Nachweisen, Erzeugen eines der Kartenaktualisierung zugeordneten Datensatzes; Aktualisieren der Blockchain, um den erzeugten Datensatz aufzunehmen, um die globale Karte basierend auf der Kartenaktualisierung zu aktualisieren; und elektronisches Übertragen des erzeugten Datensatzes an eine Vielzahl von Knoten in der Blockchain.
Verfahren nach Anspruch 26, wobei die Blockchain halböffentlich ist.
Verfahren nach Anspruch 26 oder 27, wobei die Vielzahl von Nachweisen ferner einen oder mehrere Nachweise umfasst, die aus der Gruppe von Nachweisen ausgewählt sind, die umfasst: einen Ortsnachweis, einen Nachweis einer physischen Lieferung und einen Sicherheitsnachweis.