DE112020004587T5

DE112020004587T5 - Verteilter verkehrssicherheitskonsens

Info

Publication number: DE112020004587T5
Application number: DE112020004587.0T
Authority: DE
Inventors: Ignacio J. Alvarez; Rafael Misoczki; Andrea Miele
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-09-28
Filing date: 2020-08-28
Publication date: 2022-07-14
Also published as: WO2021061342A1; US20200026289A1

Abstract

Es wird auf Sensordaten zugegriffen, die durch Sensoren einer Vorrichtung in einer Umgebung erzeugt wurden. Eine Beobachtung eines Ereignisses wird aus den Sensordaten bestimmt, die eine Bewegung einer oder mehrerer Maschinen innerhalb der Umgebung in Verbindung mit dem Ereignis identifizieren, wobei mindestens eine der Maschinen dazu ausgelegt ist, sich autonom zu bewegen. Beobachtungsdaten werden erzeugt, um die Beobachtung zu beschreiben. Es wird veranlasst, dass die Beobachtungsdaten in einer verteilten verknüpften Datenstruktur gespeichert werden.

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNG
Diese Anmeldung beansprucht die Priorität der nichtvorläufigen (Non-Provisional-) US-Patentanmeldung Nr. 16/586,968 , eingereicht am 28. September 2019 mit dem Titel „DISTRIBUTED TRAFFIC SAFETY CONSENSUS“, die hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen wird.
TECHNISCHES GEBIET
Diese Offenbarung betrifft allgemein das Gebiet von Computersystemen und insbesondere Rechensysteme, die die Sicherheit autonomer Fahrzeuge beurteilen.
HINTERGRUND
Einige Fahrzeuge sind dazu konfiguriert, in einem autonomen Modus zu arbeiten, in dem das Fahrzeug mit wenig oder keiner Eingabe von einem Fahrer durch eine Umgebung navigiert. Ein solches Fahrzeug beinhaltet typischerweise einen oder mehrere Sensoren, die dazu konfiguriert sind, Informationen über die Umgebung zu erfassen. Das Fahrzeug kann die erfassten Informationen verwenden, um durch die Umgebung zu navigieren. Falls zum Beispiel die Sensoren erfassen, dass sich das Fahrzeug einem Hindernis nähert, kann das Fahrzeug um das Hindernis herum navigieren.
Figurenliste

1 ist ein vereinfachtes Blockdiagramm einer beispielhaften Fahrumgebung.
2 ist ein vereinfachtes Blockdiagramm eines beispielhaften fahrzeuginternen automatisierten Fahrsystems.
3 ist ein vereinfachtes Blockdiagramm, das Stufen automatisierten Fahrens veranschaulicht.
4 ist ein vereinfachtes Blockdiagramm, das Funktionsweisen eines automatisierten Fahrsystems veranschaulicht.
5 ist ein vereinfachtes Blockdiagramm, das grundlegende Funktionen automatisierter Fahrsysteme veranschaulicht.
6 ist ein vereinfachtes Blockdiagramm, das Komponenten eines beispielhaften automatisierten Fahrsystems veranschaulicht.
7 ist ein vereinfachtes Blockdiagramm einer beispielhaften verteilten verknüpften Datenstruktur.
8 ist ein vereinfachtes Blockdiagramm, das ein beispielhaftes Sicherheitsereignis veranschaulicht, an dem ein oder mehrere autonome Fahrzeuge beteiligt sind.
9 ist ein vereinfachtes Blockdiagramm, das beispielhafte Beobachtungen veranschaulicht, die für ein Sicherheitsereignis erzeugt werden.
10 ist ein vereinfachtes Blockdiagramm, das Hinzufügung von Blöcken zu einer beispielhaften verteilten verknüpften Datenstruktur veranschaulicht.
11 ist ein Flussdiagramm, das eine beispielhafte Methode zum Erzeugen von Beobachtungen von Sicherheitsereignissen veranschaulicht.
12 ist ein vereinfachtes Blockdiagramm, das einen Beobachtungskonsensus unter Verwendung einer beispielhaften verteilten verknüpften Datenstruktur veranschaulicht.
13 ist ein vereinfachtes Blockdiagramm, das eine beispielhafte Erzeugung einer Beurteilung zur Aufnahme in eine beispielhafte verteilte verknüpfte Datenstruktur veranschaulicht.
14 ist ein vereinfachtes Blockdiagramm, das eine beispielhafte Erzeugung einer überarbeiteten Beurteilung zur Aufnahme in eine beispielhafte verteilte verknüpfte Datenstruktur veranschaulicht.
15 ist ein vereinfachtes Blockdiagramm, das eine beispielhafte Konsenserzeugung einer Beurteilung zur Aufnahme in eine beispielhafte verteilte verknüpfte Datenstruktur veranschaulicht.
16 ist ein beispielhaftes Flussdiagramm, das einen beispielhaften verteilten Konsens für ein Sicherheitsereignis veranschaulicht.
17A-17B sind vereinfachte Flussdiagramme, die Methoden veranschaulichen, die beim Ermitteln sicherheitsbezogener Ereignisse genutzt werden, an denen autonome Maschinen beteiligt sind.
18 ist ein Blockdiagramm eines beispielhaften Prozessors gemäß einer Ausführungsform.
19 ist ein Blockdiagramm eines beispielhaften Rechensystems gemäß einer Ausführungsform.

Gleiche Bezugszeichen und Bezeichnungen in den verschiedenen Zeichnungen bezeichnen gleiche Elemente.
AUSFÜHRLICHE BESCHREIBUNG VON AUSFÜHRUNGBEISPIELEN
1 ist eine vereinfachte Darstellung 100, die eine beispielhafte autonome Fahrumgebung zeigt. Fahrzeuge (z.B. 105, 110, 115 usw.) können mit variierenden Stufen autonomer Fahrfähigkeiten versehen sein, die durch fahrzeuginterne Rechensysteme mit Logik ermöglicht werden, die in Hardware, Firmware und/oder Software implementiert ist, um jeweilige autonome Fahrstapel zu ermöglichen. Solche autonomen Fahrstapel können Fahrzeugen ermöglichen, sich selbst zu steuern oder Fahrerassistenz bereitzustellen, um Straßen zu erkennen, von einem Punkt zu einem anderen zu navigieren, andere Fahrzeuge und Verkehrsteilnehmer zu erkennen (z.B. Fußgänger (z.B. 135), Fahrradfahrer usw.), Hindernisse und Gefahren (z.B. 120) und Straßenbedingungen (z.B. Verkehr, Straßenbedingungen, Wetterbedingungen usw.) zu erkennen und Steuerung und Führung des Fahrzeugs entsprechend anzupassen.
In einigen Implementierungen können Fahrzeuge (z.B. 105, 110, 115) innerhalb der Umgebung insofern „verbunden“ sein, als die fahrzeuginternen Rechensysteme Kommunikationsmodule zum Unterstützen drahtloser Kommunikation unter Verwendung einer oder mehrerer Technologien (z.B. IEEE 802.11-Kommunikationen (z.B. WiFi), zellulare Datennetze (z.B. 3GPP- (3rd Generation Partnership Project) -Netze, Global System for Mobile Communication (GSM), Allgemeinpaketfunkdienst, Codemultiplex-Mehrfachzugriff (CDMA) usw.), Bluetooth™, Millimeterwelle (mmWave), ZigBee™, Z-Wave™ usw.) beinhalten, wodurch ermöglicht wird, dass sich die fahrzeuginternen Rechensysteme mit anderen Rechensystemen, wie etwa den fahrzeuginternen Rechensystemen anderer Fahrzeuge, Straßenrandeinheiten, Cloud-basierten Rechensystemen oder einer anderen unterstützenden Infrastruktur, verbinden und mit diesen kommunizieren. Beispielsweise können Fahrzeuge (z.B. 105, 110, 115) in einigen Implementierungen mit Rechensystemen kommunizieren, die Sensoren, Daten und Dienste zur Unterstützung der eigenen autonomen Fahrfähigkeiten der Fahrzeuge bereitstellen. Beispielsweise können, wie in dem veranschaulichenden Beispiel von 1 gezeigt, unterstützende Drohnen 180 (z.B. zu Land und/oder in der Luft), an der Straße befindliche Rechenvorrichtungen (z.B. 140), verschiedene externe (fahrzeugexterne oder „fremde“) Sensorvorrichtungen (z.B. 160, 165, 170, 175 usw.), und andere Vorrichtungen als Infrastruktur für autonomes Fahren separat von den Rechensystemen, Sensoren und Logik bereitgestellt sein, die in den Fahrzeugen (z.B. 105, 110, 115) implementiert sind, um unter anderen Beispielen Ergebnisse beim autonomen Fahren, die durch die Fahrzeuge bereitgestellt werden, zu unterstützen und zu verbessern. Fahrzeuge können unter anderen beispielhaften Kommunikationen auch mit anderen verbundenen Fahrzeugen über drahtlose Kommunikationskanäle kommunizieren, um Daten zu teilen und Bewegung innerhalb einer autonomen Fahrumgebung zu koordinieren.
Wie in dem Beispiel von 1 veranschaulicht, kann eine Infrastruktur für autonomes Fahren eine Vielfalt unterschiedlicher Systeme beinhalten. Solche Systeme können in Abhängigkeit vom Standort variieren, wobei entwickelte Straßen (z. B. Straßen, die durch spezifische Städte oder Mautbehörden gesteuert werden, Straßen in städtischen Gebieten, Straßenabschnitte, von denen bekannt ist, dass sie für autonome Fahrzeuge problematisch sind, usw.) eine größere Anzahl oder fortschrittlichere unterstützende Infrastrukturvorrichtungen als andere Straßenabschnitte usw. aufweisen. Beispielsweise können ergänzende Sensorvorrichtungen (z.B. 160, 165, 170, 175) bereitgestellt sein, die Sensoren zum Beobachten von Abschnitten von Straßen und Fahrzeugen, die sich innerhalb der Umgebung bewegen, und Erzeugen entsprechender Daten beinhalten, die Beobachtungen der Sensoren beschreiben oder umsetzen. Als Beispiele können Sensorvorrichtungen unter anderem in die Straße selbst eingebettet sein (z.B. der Sensor 160), an Straßenrändern oder an über Kopfniveau befindlichen Schildern angebracht sein (z.B. der Sensor 165 am Zeichen 125), oder Sensoren (z.B. 170, 175) können an elektronischen Geräten oder Einrichtungen am Straßenrand (z.B. Ampeln (z.B. 130), elektronischen Verkehrszeichen, elektronischen Werbetafeln usw.), oderdedizierten Straßenrandeinheiten (z.B. 140) angebracht sein. Sensorvorrichtungen können auch Kommunikationsfähigkeiten beinhalten, um ihre gesammelten Sensordaten direkt an in der Nähe befindliche verbundene Fahrzeuge oder an Fog- oder Cloud-basierte Rechensysteme (z.B. 140, 150) zu kommunizieren. Fahrzeuge können Sensordaten, die durch externe Sensorvorrichtungen (z.B. 160, 165, 170, 175, 180) gesammelt werden, oder Daten, die Beobachtungen oder Empfehlungen umsetzen, die durch andere Systeme (z.B. 140, 150) basierend auf Sensordaten von diesen Sensorvorrichtungen (z.B. 160, 165, 170, 175, 180) erzeugt werden, erhalten und verwenden diese Daten für Sensorfusion, Inferenz, Wegplanung und andere Aufgaben, die durch das fahrzeuginterne autonome Fahrsystem durchgeführt werden. In einigen Fällen können sich solche Fremdsensoren und Sensordaten in Wirklichkeit innerhalb des Fahrzeugs befinden, wie etwa in Form eines an dem Fahrzeug angebrachten Nachrüstsensors, einer persönlichen Rechenvorrichtung (z.B. Smartphone, Wearable-Vorrichtung usw.), die von Insassen des Fahrzeugs mitgeführt oder getragen wird, usw. Andere Verkehrsteilnehmer, darunter Fußgänger, Fahrräder, Drohnen, elektronische Roller usw., können ebenfalls mit Sensoren versehen sein oder diese tragen, um Sensordaten zu erzeugen, die eine autonome Fahrumgebung beschreiben, die unter anderem von autonomen Fahrzeugen, Cloud - oder Fog-basierten Unterstützungssystemen (z.B. 140, 150), anderen Sensorvorrichtungen (z.B. 160, 165, 170, 175, 180) verwendet und in Anspruch genommen werden können.
Da autonome Fahrzeugsysteme variierende Stufen an Funktionalität und Komplexität besitzen können, kann auf eine Unterstützungsinfrastruktur zurückgegriffen werden, um nicht nur die Erfassungsfähigkeiten einiger Fahrzeuge, sondern auch die Computer- und Maschinenlernfunktionalität zu ergänzen, die eine autonome Fahrfunktionalität einiger Fahrzeuge ermöglicht. Beispielsweise können Rechenressourcen und Logik für autonomes Fahren, die zum Ermöglichen von Maschinenlernmodell-Training und Verwendung solcher Maschinenlernmodelle verwendet werden, in den fahrzeuginternen Rechensystemen vollständig oder teilweise sowohl auf den fahrzeuginternen Systemen als auch einigen externen Systemen bereitgestellt werden (z.B. 140, 150). Beispielsweise kann ein verbundenes Fahrzeug mit Straßenrandeinheiten, Edge-Systemen oder Cloud-basierten Vorrichtungen (z.B. 140) kommunizieren, die lokal zu einem ermittelten Fahrbahnabschnitt sind, wobei solche Vorrichtungen (z.B. 140) in der Lage sind, Daten (z.B. Sensordaten, die von lokalen Sensoren (z.B. 160, 165, 170, 175, 180) aggregiert werden, oder Daten, die von Sensoren anderer Fahrzeuge gemeldet werden), bereitzustellen, Berechnungen (als Dienst) an Daten durchzuführen, die durch ein Fahrzeug bereitgestellt werden, um die fahrzeugeigenen Fähigkeiten zu ergänzen, und/oder Informationen an vorbeifahrende oder sich nähernde Fahrzeuge (z.B. basierend auf Sensordaten, die an der Vorrichtung 140 oder von nahegelegenen Sensorvorrichtungen gesammelt werden usw.) zu senden. Ein verbundenes Fahrzeug (z.B. 105, 110, 115) kann auch oder stattdessen mit Cloud-basierten Rechensystemen (z.B. 150) kommunizieren, die ähnliche Speicher-, Erfassungs- und Rechenressourcen bereitstellen können, um die an dem Fahrzeug verfügbaren zu verbessern. Unter anderen beispielhaften Implementierungen kann beispielsweise ein Cloud-basiertes System (z.B. 150) Sensordaten von einer Vielzahl von Vorrichtungen an einem oder mehreren Standorten sammeln und diese Daten nutzen, um Maschinenlernmodelle aufzubauen und/oder zu trainieren, die in dem Cloud-basierten System verwendet werden können, um verschiedenen Fahrzeugen (z.B. 105, 110, 115) in Kommunikation mit dem Cloud-basierten System 150 Ergebnisse bereitzustellen oder diese an Fahrzeuge zur Verwendung durch ihre fahrzeuginternen Systeme zu senden. Zugangspunkte (z.B. 145), wie etwa Mobilfunkmasten, Straßenrandeinheiten, Netzwerkzugangspunkte, die an verschiedenen Straßeninfrastrukturen montiert sind, Zugangspunkte, die von benachbarten Fahrzeugen oder Gebäuden bereitgestellt werden, und andere Zugangspunkte können innerhalb einer Umgebung bereitgestellt und verwendet werden, um Kommunikation über ein oder mehrere lokale oder Weitverkehrsnetze (z.B. 155) zwischen Cloud-basierten Systemen (z.B. 150) und verschiedenen Fahrzeugen (z.B. 105, 110, 115) zu ermöglichen. Bei solchen Infrastruktur- und Rechensystemen versteht es sich, dass die vorliegend besprochenen Beispiele, Merkmale und Lösungen vollständig durch solche fahrzeuginternen Rechensysteme und/oder Fog-basierte und/oder Edge-Rechenvorrichtungen und/oder Cloud-basierte Rechensysteme und/oder durch Kombinationen der Vorstehenden durch Kommunikation und Kooperation zwischen den Systemen durchgeführt werden können.
Grundsätzlich können vorliegend erörterte „Server“, „Clients“, „Rechenvorrichtungen“, „Netzwerkelemente“, „Hosts“, „Plattformen“, „Sensorvorrichtungen“, „Edge-Vorrichtung“, „autonome Fahrsysteme“, „autonome Fahrzeuge“, „Fog-basiertes System“, „Cloud-basiertes System“ und „Systeme“ usw. elektronische Rechenvorrichtungen beinhalten, die dazu betreibbar sind, Daten und Informationen im Zusammenhang mit einer autonomen Fahrumgebung zu empfangen, zu übertragen, zu verarbeiten, zu speichern oder zu verwalten. Die in diesem Dokument verwendeten Ausdrücke „Computer“, „Prozessor“, „Prozessorvorrichtung“ oder „Verarbeitungsvorrichtung“ sollen jede beliebige geeignete Verarbeitungseinrichtung umfassen, darunter unter anderem Zentralverarbeitungseinheiten (CPUs), Grafikverarbeitungseinheiten (GPUs), anwendungsspezifische integrierte Schaltungen (ASICs), frei programmierbare Gate-Arrays (FPGAs), Digitalsignalprozessoren (DSPs), Tensorprozessoren und andere arithmetische Matrixprozessoren. Beispielsweise können Elemente, die als einzelne Vorrichtungen innerhalb der Umgebung gezeigt sind, unter Verwendung einer Vielzahl von Rechenvorrichtungen und Prozessoren implementiert werden, wie etwa Server-Pools mit mehreren Server-Computern. Ferner können beliebige, alle oder einige der Rechenvorrichtungen dazu eingerichtet sein, ein beliebiges Betriebssystem auszuführen, darunter Linux™, UNIX™, Microsoft™ Windows™, Apple™ macOS™, Apple™ iOS™, Google™ Android™, WINDOWS-SERVER™ usw., sowie virtuelle Maschinen, die dazu eingerichtet sind, eine Ausführung eines jeweiligen Betriebssystems zu virtualisieren, einschließlich angepasster und proprietärer Betriebssysteme.
Beliebige der Abläufe, Verfahren, Prozesse (oder Teile davon) oder Funktionalität beliebiger der verschiedenen nachstehend beschriebenen oder in den Figuren veranschaulichten Komponenten können durch eine beliebige geeignete Rechenlogik durchgeführt werden, wie etwa ein oder mehrere Module, Engines, Blöcke, Einheiten, Modelle, Systeme oder eine andere geeignete Rechenlogik. Vorliegend können sich Bezugnahmen auf ein „Modul“, eine „Engine“, einen „Block“, eine „Einheit“, ein „Modell“, ein „System“ oder eine „Logik“ auf Hardware, Firmware, Software und/oder Kombinationen aus diesen beziehen, um eine oder mehrere Funktionen durchzuführen. Als ein Beispiel kann ein Modul, eine Engine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik eine oder mehrere Hardwarekomponenten, wie etwa einen Mikrocontroller oder Prozessor, beinhalten, die mit einem nichtflüchtigen Medium assoziiert sind, um Code zu speichern, der dazu ausgelegt ist, durch den Mikrocontroller oder Prozessor ausgeführt zu werden. Daher kann sich eine Bezugnahme auf ein Modul, eine Engine, einen Block, eine Einheit, ein Modell, ein System oder eine Logik in einer Ausführungsform auf Hardware beziehen, die speziell dafür konfiguriert ist, den Code, der auf einem nicht transienten Medium gehalten werden soll, zu erkennen und/oder auszuführen. Des Weiteren bezieht sich in einer anderen Ausführungsform die Verwendung eines Moduls, einer Engine, eines Blocks, einer Einheit, eines Modells, eines Systems oder einer Logik auf das nichtflüchtige Medium einschließlich des Codes, das speziell dazu eingerichtet ist, durch den Mikrocontroller oder Prozessor ausgeführt zu werden, um vorbestimmte Operationen durchzuführen. Und wie abgeleitet werden kann, kann sich in einer weiteren Ausführungsform ein Modul, eine Engine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik auf die Kombination aus der Hardware und dem nicht transienten Medium beziehen. In verschiedenen Ausführungsformen kann ein Modul, eine Engine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik einen Mikroprozessor oder ein anderes Verarbeitungselement, der/das betreibbar ist, um Softwareanweisungen auszuführen, diskrete Logik, wie etwa eine anwendungsspezifische integrierte Schaltung (ASIC), eine programmierte Logikvorrichtung, wie etwa ein frei programmierbares Gate-Array (FPGA), eine Speichervorrichtung, die Anweisungen enthält, Kombinationen von Logikvorrichtungen (wie sie z.B. auf einem Leiterplatte zu finden wären) oder eine andere geeignete Hardware und/oder Software beinhalten. Ein Modul, eine Engine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik können ein oder mehrere Gates oder andere Schaltungskomponenten beinhalten, die z.B. durch Transistoren implementiert werden können. In einigen Ausführungsformen kann ein Modul, eine Engine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik vollständig als Software umgesetzt sein. Software kann als Softwarepaket, Code, Anweisungen, Befehlssätze und/oder Daten umgesetzt sein, die auf einem nicht transienten computerlesbaren Speichermedium aufgezeichnet sind. Firmware kann als Code, Anweisungen oder Befehlssätze und/oder Daten umgesetzt sein, die in Speichervorrichtungen fest codiert (z.B. nicht flüchtig) sind. Des Weiteren variieren Logikgrenzen, die als separat veranschaulicht sind, üblicherweise und überlappen sich möglicherweise. Zum Beispiel können ein erstes und zweites Modul (oder mehrere Engines, Blöcke, Einheiten, Modelle, Systeme oder Logik) Hardware, Software, Firmware oder eine Kombination aus diesen gemeinsam verwenden, während möglicherweise Teile von unabhängiger Hardware, Software oder Firmware beibehalten werden.
Die nachstehend und in den begleitenden Figuren beschriebenen Abläufe, Verfahren und Prozesse sind lediglich repräsentativ für Funktionen, die in bestimmten Ausführungsformen durchgeführt werden können. In anderen Ausführungsformen können zusätzliche Funktionen in den Abläufen, Verfahren und Prozessen durchgeführt werden. Verschiedene Ausführungsformen der vorliegenden Offenbarung ziehen jegliche geeignete Signalisierungsmechanismen zum Ausführen der hier beschriebenen Funktionen in Betracht. Einige der vorliegend veranschaulichten Funktionen können gegebenenfalls innerhalb der Abläufe, Verfahren und Prozesse wiederholt, kombiniert, modifiziert oder gelöscht werden. Zudem können Funktionen innerhalb der Abläufe, Verfahren und Prozesse in einer beliebigen geeigneten Reihenfolge durchgeführt werden, ohne vom Schutzumfang bestimmter Ausführungsformen abzuweichen.
Gegenwärtig sind an Verkehrsunfällen üblicherweise ein oder mehrere Fahrzeuge beteiligt, die von menschlichen Fahrern gesteuert werden. Nachdem der Unfall stattgefunden hat, meldet jeder beteiligte Verkehrsteilnehmer die Beobachtung der Ereignisse, die zu dem Unfall führten, wobei optional weitere Zeugen des Ereignisses zugegen sind. Es kann dann zu einem Prozess der Geltendmachung von Ansprüchen unter Beteiligung von Versicherungen und/oder öffentlichen Sicherheitsverwaltungen kommen, was in einigen Fällen dazu führt, dass über die Anspruchsforderung gerichtlich entschieden wird. Das Aufkommen von Automatisierung bringt die Möglichkeit des Auftretens von Unfällen mit sich, bei denen einer, mehrere oder sogar alle Beteiligten und Zeugen (vorliegend auch als „Agenten“ bezeichnet) autonome Fahrzeuge sind. Unter solchen Umständen kann es unpraktikabel, unerwünscht oder unzureichend sein, aktuelle Anspruchsprozesse anzuwenden, die für menschliche Benutzer und Zeugen entwickelt wurden. Mit dem Einsatz autonomer Fahrzeuge könnten bald Umstände auftreten, unter denen keine menschlichen Bediener beteiligt sind und/oder bei denen kein menschlicher Zeuge anwesend war, der eine Beurteilung basierend auf Anwesenheitsbeobachtungen bereitstellen könnte. Dementsprechend können Rechensysteme, die zum Bereitstellen oder Unterstützen von Funktionalität für autonomes Fahren genutzt werden, verbessert werden, um eine angemessene Meldung und Beurteilung von sicherheitskritischem Betriebsverhalten automatisiert fahrender Fahrzeuge zu ermöglichen. In der modernen Praxis wird bei Unfällen größtenteils auf menschliche Akteure und Zeugen zurückgegriffen, um zu beurteilen, ob korrekte und gesetzeskonforme Fahrpraxen von den am Unfall Beteiligten eingehalten wurden. Ihre Beobachtungen können ergänzt und bestätigt/hinterfragt werden, indem Ereignisse unter Nutzung moderner wissenschaftlicher und forensischer Informationen rekonstruiert werden, wobei die kollektive Beweislage genutzt wird, um die Ursache des Unfalls rechtlich zu beurteilen.
Wenngleich von vielen Meinungsbildnern erwartet wird, dass die Häufigkeit und Schwere von Autounfällen wahrscheinlich abnimmt und autonome Fahrzeuge manuell betriebene Fahrzeuge auf Straßen und Autobahnen ersetzen, wird auch eingeräumt, dass manche Unfälle dennoch unvermeidbar und unvermeidbar sein werden. Das Sicherheitsproblem besteht nicht in der Frage „Können wir ein autonomes Fahrzeug bauen, das keine Unfälle hat?“, sondern in der Frage „Können wir eines bauen, das nicht durch seine eigene Entscheidungsfindung in Unfälle verwickelt wird?“. Modelle können innerhalb der Logik automatisierter Fahrsysteme bereitgestellt und übernommen werden, wobei die Modelle dazu dienen, Definitionen darüber zu formalisieren, welches Niveau an Sicherheit und automatisiertem Fahrverhalten akzeptabel ist. Solche Modelle können einen Industriestandard über sicheres Straßenverhalten (z.B. beginnend mit longitudinalen und lateralen Manövern) definieren und Definitionen wie etwa sicheren Abstand, Zeit bis zur Kollision, Vorfahrt und Verantwortung beinhalten, die allgemein vereinbart und für automatisiertes Fahren von Fahrzeugen definiert werden, um an einem bestimmten geopolitischen Standort zu arbeiten. Als ein Beispiel führt das Responsibility-Sensitive-Safety-Modell (RSS) (z.B. basierend auf Shai Shalev-Shwartz et al., On a Formal Model of Safe and Scalable Self-Drive Cars, (Überlegungen zu einem formalen Modell für sichere und skalierbare selbstfahrende Autos) (2017) die Konzepte Common Sense, vorsichtiges Fahren, Verantwortung und richtiges Reagieren ein und definiert die mathematischen Beweise für eine Anzahl von Straßenumgebungen. Theoretisch definiert ein solches Modell einen Satz universell anpassbarer Regeln für autonome Fahrsysteme, so dass, falls ein automatisiertes Fahrzeug diesen Common-Sense-Regeln folgt und vorsichtiges Fahren und richtiges Reagieren anwendet, das autonome Fahrzeug nicht die Ursache eines Unfalls sein sollte (z.B. Reduzieren von Unfällen auf solche aufgrund eines menschlichen Fehlers, unvorhersehbarer Katastrophe oder Fehlfunktion eines Rechensystems, das beim Treffen autonomer Fahrentscheidungen genutzt wird usw., anstatt eines korrekten Funktionierens autonomer Fahrsysteme autonomer Fahrzeuge auf der Straße). Solche Modelle können Regeln definieren, die ein optimales Fahrverhalten modellieren, um ein komfortables und zuverlässiges Fahren bereitzustellen, wobei Unfälle minimiert werden, und in einigen Fällen auf Einhaltung aktiver Vorschriften basieren oder diese erfordern (z.B. Einhalten der maximal zulässigen Geschwindigkeit auf dem Straßenabschnitt, Beachten von Verkehrszeichen und Fahrspurmarkierungen usw.). Kurz gesagt besteht ein Ziel autonomer Fahrsysteme darin, Fahrzeuge derart zu automatisieren, dass das Fahrzeug allen Vorschriften folgt, und falls ein Verkehrsvorfall auftritt, dieser kein Fehler der Logik des autonomen Fahrsystems sein sollte.
In einigen Implementierungen kann eine konsensbasierte Verifizierung einer Einhaltung von Vorschriften durch automatisierte Fahrzeuge unter Verwendung eines verbesserten Sicherheitssystems implementiert werden, um beispielsweise Informationen zu sammeln und zu melden, die mit sicherheitskritischen Straßenereignissen wie etwa Autounfällen zusammenhängen, und Verarbeitungslogik zu nutzen, die an mehreren Rechensystemen verfügbar ist, die die betreffende Szene beobachten, um die Eigenschaften und Ursachen des Ereignisses zu ermitteln. In einigen Implementierungen können Konsensbestimmungen in vertrauenswürdigen gemeinsam genutzten Datenspeichern gespeichert werden, wie etwa kryptografisch gesicherten verteilten Ledgers, wie etwa Aufzeichnungen, die Blockchain-Technologie nutzen. Beispielsweise kann eine Blockchain-basierte Liste von Aufzeichnungen genutzt werden, um Straßenereignisse zu speichern und Konsens zwischen einander nicht vertrauenden Parteien basierend auf den gespeicherten Beobachtungen des Ereignisses zu erreichen. In solchen Fällen können die Rechensysteme teilnehmender Straßenagenten (z.B. automatisierte Fahrzeuge, intelligente Kreuzungssensoren, Straßenrandstrukturen und -sensoren, Drohnen, die Straßen überwachen, nichtautonome Fahrzeuge, andere Verkehrsteilnehmer usw.) dafür konfiguriert sein, die Analyse eines an dem Agenten bestimmten Verkehrsereignisses aus ihrer jeweiligen Sicht vorzubringen, wobei die Analyse Schlussfolgerungen des Agenten dahingehend identifiziert, ob das Verhalten des oder der beteiligten Fahrzeuge bzw. der beteiligten Fahrzeuge Bestimmungen oder Sicherheitskonventionen einhielt. Dementsprechend kann eine konsensbasierte Analyse der Beobachtungen in der Blockchain gespeichert werden. Die Rohsensordaten, die von den Agenten beim Anstellen ihrer Beobachtungen und Schlussfolgerungen bezüglich eines Ereignisses genutzt werden, können ebenfalls mit den Beobachtungen als Beweise gespeichert werden, die die Gültigkeit und/oder Vertrauenswürdigkeit von Bestimmungen eines jeweiligen Agenten untermauern. Die Konsensbeobachtungen können unter anderen beispielhaften Verwendungen als transparenter und verifizierbarer Beweis zwischen einander nicht vertrauenden Parteien, wie etwa individuellen Anspruchsstellern, Versicherungsunternehmen, Regierungsorganisationen und anderen interessierten Parteien verwendet werden.
Systeme können entwickelt werden, um die vorstehend eingeführten beispielhaften Lösungen zu implementieren. Beispielsweise ist nun unter Bezugnahme auf 2 ein vereinfachtes Blockdiagramm 200 gezeigt, das eine beispielhafte Implementierung eines Fahrzeugs (und eines entsprechenden fahrzeuginternen Rechensystems) 105 veranschaulicht, das mit Funktionalität für autonomes Fahren ausgestattet ist. In einem Beispiel kann ein Fahrzeug 105 unter anderen Beispielen mit einem oder mehreren Prozessoren 202 ausgestattet sein, wie etwa Zentralverarbeitungseinheiten (CPUs), Grafikverarbeitungseinheiten (GPUs), anwendungsspezifischen integrierten Schaltungen (ASICs), frei programmierbaren Gate-Arrays (FPGAs), Digitalsignalprozessoren (DSPs), Tensorprozessoren und anderen arithmetischen Matrixprozessoren. Solche Prozessoren 202 können mit integrierten Hardware-Beschleunigervorrichtungen (z.B. 204) gekoppelt sein oder diese aufweisen, die mit Hardware zum Beschleunigen bestimmter Verarbeitungs- und Speicherzugriffsfunktionen versehen sein kann, wie etwa unter anderem Funktionen in Bezug auf Maschinenlerninferenz oder -training (einschließlich beliebiger der/des nachstehend beschriebenen Maschinenlerninferenz oder -trainings), Verarbeiten bestimmter Sensordaten (z.B. Kamerabilddaten, LIDAR (Light Detection and Ranging) -Punktwolken usw.), Durchführen bestimmter arithmetischer Funktionen, die autonomes Fahren betreffen (z.B. Matrixarithmetik, Faltungsarithmetik usw.). Ein oder mehrere Speicherelemente (z.B. 206) können bereitgestellt sein, um maschinenausführbare Anweisungen zu speichern, die alles oder einen Teil eines beliebigen der Module oder Untermodule eines autonomen Fahrstapels implementieren, der auf dem Fahrzeug implementiert ist, sowie Maschinenlernmodelle (z.B. 256), Sensordaten (z.B. 258) und anderen Daten zu speichern, die in Verbindung mit durch das Fahrzeug durchzuführender Funktionalität für autonomes Fahren empfangen, erzeugt oder verwendet werden (oder in Verbindung mit den vorliegend erörterten Beispielen und Lösungen verwendet werden). Zudem können verschiedene Kommunikationsmodule (z.B. 212) bereitgestellt sein, die in Hardwareschaltungsanordnungen und/oder Software implementiert sind, um Kommunikationsfähigkeiten zu implementieren, die vom System des Fahrzeugs verwendet werden, um mit anderen externen Rechensystemen über einen oder mehrere Netzwerkkanäle zu kommunizieren, die eine oder mehrere Netzwerkkommunikationstechnologien einsetzen. Diese verschiedenen Prozessoren 202, Beschleuniger 204, Speichervorrichtungen 206 und Netzwerkkommunikationsmodule 212 können in dem Fahrzeugsystem durch eine Vielzahl von Schnittstellen miteinander verbunden sein, die beispielsweise durch eine oder mehrere Verbindungsstrukturen oder -verknüpfungen implementiert sind, wie etwa Fabrics, die Technologien wie etwa unter anderem einen PCle-(Peripheral Component Interconnect Express), Ethernet-, USB- (Universal Serial Bus), UPI-(Ultra Path Interconnect) oder CAN (Controller Area Network) -Bus nutzen.
Unter weiterer Bezugnahme auf das Beispiel aus 2 kann ein beispielhaftes Fahrzeug (und ein entsprechendes fahrzeuginternes Rechensystem) 105 ein fahrzeuginternes automatisiertes Fahrsystem 210, Fahrsteuerungen (z.B. 220), Sensoren (z.B. 225) und Benutzer-/Fahrgastschnittstelle(n) (z.B. 230) beinhalten, neben anderen beispielhaften Modulen, die Funktionalität des autonomen Fahrzeugs in Hardware und/oder Software implementieren. Beispielsweise kann ein automatisiertes Fahrsystem 210 in einigen Implementierungen den gesamten oder einen Teil eines autonomen Fahrstapels und eines Prozessflusses implementieren. In einigen Implementierungen kann das automatisierte Fahrsystem 210 auf einem standardisierten Sicherheitsmodell, wie etwa einem RSS-basierten Modell, basieren und dazu ausgelegt sein, gemäß diesem zu arbeiten. Eine Maschinenlern-Engine 232 kann bereitgestellt sein, um verschiedene Maschinenlernmodelle (z.B. 256), die in dem Fahrzeug 105 bereitgestellt sind, in Verbindung mit einer oder mehreren autonomen Funktionen und Merkmalen zu nutzen, die in dem oder für das Fahrzeug bereitgestellt und implementiert werden, wie in den vorliegenden Beispielen erörtert. Solche Maschinenlernmodelle 256 können künstliche neuronale Netzmodelle, neuronale Faltungsnetze, entscheidungsbaumbasierte Modelle, Support Vector Machines (SVM), Bayes 'sche Modelle, Deep-Learning-Modelle und andere beispielhafte Modelle beinhalten. In einigen Implementierungen kann eine beispielhafte Maschinenlern-Engine 232 eine oder mehrere Modelltrainer-Engines 252 zur Beteiligung am Training (z.B. anfängliches Training, kontinuierliches Training usw.) eines oder mehrerer der Maschinenlernmodelle 256 beinhalten. Eine oder mehrere Inferenz-Engines 254 können zudem bereitgestellt sein, um die trainierten Maschinenlernmodelle 256 zu nutzen, um verschiedene Inferenzen, Vorhersagen, Klassifizierungen und andere Ergebnisse abzuleiten. In einigen Ausführungsformen kann das vorliegend beschriebene Maschinenlernmodell-Training oder die vorliegend beschriebene Inferenz außerhalb des Fahrzeugs, wie etwa durch das Rechensystem 140 oder 150, durchgeführt werden.
Die an dem Fahrzeug bereitgestellte(n) Maschinenlern-Engine(s) 232 kann (können) genutzt werden, um Ergebnisse zur Verwendung durch andere logische Komponenten und Module des automatisierten Fahrsystems 210, die einen autonomen Fahrstapel und andere auf autonomes Fahren bezogene Merkmale implementiert, zu unterstützen und bereitzustellen. Beispielsweise kann ein Datensammlungsmodul 234 mit Logik versehen sein, um Quellen zu ermitteln, von denen Daten gesammelt werden sollen (z. B. für Eingaben beim Training oder der Verwendung verschiedener Maschinenlernmodelle 256, die von dem Fahrzeug verwendet werden). Beispielsweise können die jeweilige Quelle (z.B. interne Sensoren (z.B. 225) oder fremde Quellen (z.B. 115, 140, 150 usw.)) ausgewählt werden, sowie die Frequenz und Genauigkeit, mit der die Daten entnommen werden können. In einigen Fällen können solche Auswahlen und Konfigurationen zumindest teilweise autonom durch das Datensammlungsmodul 234 unter Verwendung eines oder mehrerer entsprechender Maschinenlernmodelle getroffen werden (z.B. um Daten angesichts eines bestimmten detektierten Szenarios nach Bedarf zu sammeln).
Zudem kann ein Sensorfusionsmodul 236 verwendet werden, um die Verwendung und Verarbeitung der verschiedenen Sensoreingaben, die durch die Maschinenlern-Engine 232 und andere Module (z.B. 238, 240, 242, 244, 246 usw.) des fahrzeuginternen Verarbeitungssystems genutzt werden, zu regeln. Ein oder mehrere Sensorfusionsmodule (z.B. 236) können bereitgestellt sein, die eine Ausgabe aus mehreren Sensordatenquellen (z.B. am Fahrzeug oder außerhalb des Fahrzeugs) ableiten können. Die Quellen können homogene oder heterogene Arten von Quellen sein (z.B. mehrere Eingaben aus mehreren Instanzen einer gemeinsamen Art von Sensor oder von Instanzen mehrerer unterschiedlicher Arten von Sensoren). Ein beispielhaftes Sensorfusionsmodul 236 kann unter anderen beispielhaften Sensorfusionstechniken direkte Fusion oder indirekte Fusion anwenden. Die Ausgabe der Sensorfusion kann in manchen Fällen als Eingabe (zusammen mit möglicherweise zusätzlichen Eingaben) einem anderen Modul des fahrzeuginternen Verarbeitungssystems und/oder einem oder mehreren Maschinenlernmodellen in Verbindung mit dem Bereitstellen einer Funktionalität für autonomes Fahren oder einer anderen Funktionalität, wie etwa in den vorliegend erörterten beispielhaften Lösungen beschrieben, zugeführt werden.
Eine Wahrnehmungs-Engine 238 kann in manchen Beispielen bereitgestellt sein, die als Eingaben verschiedene Sensordaten (z.B. 258) nehmen kann, darunter in einigen Fällen solche aus Fremdquellen und/oder dem Sensorfusionsmodul 236, um Objekterkennung und/oder Verfolgung detektierter Objekte durchzuführen, neben anderen beispielhaften Funktionen, die einer autonomen Wahrnehmung der Umgebung entsprechen, auf die das Fahrzeug 105 trifft (oder treffen wird). Die Wahrnehmungs-Engine 238 kann Objekterkennung aus Sensordateneingaben unter Verwendung von Deep-Learning, wie etwa durch ein oder mehrere neuronale Faltungsnetze und andere Maschinenlernmodelle 256, durchführen. Eine Objektverfolgung kann ebenfalls durchgeführt werden, um aus Sensordateneingaben autonom zu schätzen, ob sich ein Objekt bewegt und, falls ja, entlang welcher Trajektorie. Nachdem beispielsweise ein gegebenes Objekt erkannt wurde, kann eine Wahrnehmungs-Engine 238 detektieren, wie sich das jeweilige Objekt in Bezug auf das Fahrzeug bewegt. Eine solche Funktionalität kann neben anderen beispielhaften Verwendungen beispielsweise verwendet werden, um Objekte wie etwa andere Fahrzeuge, Fußgänger, Wild, Radfahrer usw., die sich innerhalb einer Umgebung bewegen, zu detektieren, die den Weg des Fahrzeugs auf einer Straße beeinflussen können.
Eine Lokalisierungs-Engine 240 kann in einigen Implementierungen ebenfalls in einem automatisierten Fahrsystem 210 enthalten sein. In einigen Fällen kann die Lokalisierungs-Engine 240 als eine Unterkomponente einer Wahrnehmungs-Engine 238 implementiert sein. Die Lokalisierungs-Engine 240 kann auch ein oder mehrere Maschinenlernmodelle 256 und Sensorfusion (z.B. von LIDAR-und GPS-DATEN usw.) verwenden, um einen Standort mit hoher Konfidenz des Fahrzeugs und den Raum, den dieses innerhalb eines gegebenen physischen Raums (oder einer gegebenen „Umgebung“) einnimmt, zu ermitteln.
Ein Fahrzeug 105 kann ferner einen Wegplaner 242 beinhalten, der die Ergebnisse verschiedener anderer Module wie etwa Datensammlung 234, Sensorfusion 236, Wahrnehmungs-Engine 238 und Lokalisierungs-Engine (z.B. 240) (z.B. Empfehlungs-Engine 244) zum Ermitteln eines Wegplans und/oder Handlungsplans für das Fahrzeug nutzen kann, der von Fahrsteuerungen (z.B. 220) verwendet werden kann, um das Fahren des Fahrzeugs 105 innerhalb einer Umgebung zu steuern. Ein Wegplaner 242 kann zum Beispiel diese Eingaben und eine oder mehrere Maschinenlernmodelle einsetzen, um Wahrscheinlichkeiten verschiedener Ereignisse innerhalb einer Fahrumgebung zu ermitteln, um effektive Echtzeitpläne zu ermitteln, um innerhalb der Umgebung zu agieren.
In einigen Implementierungen kann das Fahrzeug 105 eine oder mehrere Empfehlungs-Engines 244 zum Erzeugen verschiedener Empfehlungen aus Sensordaten beinhalten, die durch die eigenen Sensoren des Fahrzeugs 105 (z.B. 225) sowie Sensordaten von Fremdsensoren (z.B. auf den Sensorvorrichtungen 115 usw.) erzeugt werden. Einige Empfehlungen können durch die Empfehlungs-Engine 244 bestimmt werden, die als Eingaben an andere Komponenten des autonomen Fahrstapels des Fahrzeugs geliefert werden können, um Bestimmungen zu beeinflussen, die durch diese Komponenten vorgenommen werden. Beispielsweise kann eine Empfehlung bestimmt werden, die, wenn sie von einem Wegplaner 242 berücksichtigt wird, bewirkt, dass der Wegplaner 242 von Entscheidungen oder Plänen abweicht, die er ohne die Empfehlung normalerweise anderweitig ermitteln würde. Empfehlungen können zudem durch Empfehlungs-Engines (z.B. 244) basierend auf Überlegungen zu Fahrgastkomfort und -erlebnis erzeugt werden. In einigen Fällen können Innenraummerkmale innerhalb des Fahrzeugs prädiktiv und autonom basierend auf diesen Empfehlungen manipuliert werden (die aus Sensordaten (z.B. 258) bestimmt werden, die durch die Sensoren des Fahrzeugs und/oder externe Sensoren usw. erfasst werden.
Wie vorstehend eingeführt, können einige Fahrzeugimplementierungen Benutzer-/Fahrgasterlebnis-Engines (z.B. 246) beinhalten, die Sensordaten und Ausgaben anderer Module innerhalb des autonomen Fahrstapels des Fahrzeugs nutzen können, um Fahrmanöver und Änderungen an der Innenraumumgebung des Fahrzeugs zu bewirken, um ein Fahrgasterlebnis innerhalb des Fahrzeugs basierend auf den Beobachtungen, die durch die Sensordaten erfasst werden, zu verbessern (z.B. 258). In einigen Fällen können Aspekte von Benutzerschnittstellen (z.B. 230), die an dem Fahrzeug bereitgestellt sind, um Benutzern zu ermöglichen, mit dem Fahrzeug und seinem autonomen Fahrsystem zu interagieren, verbessert werden. In einigen Fällen können neben anderen Verwendungsbeispielen Informationsdarstellungen durch Benutzeranzeigen (z.B. Audio-, visuelle und/oder taktile Darstellungen) erzeugt und bereitgestellt werden, um dabei zu helfen, Fahrgastererlebnisse innerhalb eines Fahrzeugs (z.B. 105) zu beeinflussen und zu verbessern.
In einigen Fällen kann auch ein Systemmanager 250 bereitgestellt sein, der Informationen überwacht, die durch verschiedene Sensoren am Fahrzeug gesammelt werden, um Probleme bezüglich der Performanz des autonomen Fahrsystems eines Fahrzeugs zu detektieren. Beispielsweise können Rechenfehler, Sensorausfälle und -probleme, Verfügbarkeit und Qualität von Kommunikationskanälen (die z.B. durch die Kommunikationsmodule 212 bereitgestellt werden), Fahrzeugsystemprüfungen (z.B. Probleme in Bezug auf den Motor, das Getriebe, die Batterie, das Kühlsystem, das elektrische System, die Reifen usw.) oder andere Betriebsereignisse durch den Systemmanager 250 detektiert werden. Solche Probleme können in Systemberichtdaten identifiziert werden, die durch den Systemmanager 250 erzeugt werden und die in manchen Fällen als Eingaben in die Maschinenlernmodelle 256 und zugehörige autonome Fahrmodule (z.B. 232, 234, 236, 238, 240, 242, 244, 246 usw.) genutzt werden, um zu ermöglichen, dass der Fahrzeugsystemzustand und Probleme auch zusammen mit anderen in den Sensordaten 258 gesammelten Informationen in der Funktionalität für autonomes Fahren des Fahrzeugs 105 berücksichtigt werden. In einigen Implementierungen kann der Sicherheitsmanager 250 unter anderen beispielhaften Merkmalen ein beispielhaftes Sicherheitsbegleitsubsystem implementieren oder umsetzen.
In einigen Implementierungen kann ein autonomer Fahrstapel eines Fahrzeugs 105 mit Fahrsteuerungen 220 gekoppelt sein, um zu beeinflussen, wie das Fahrzeug gefahren wird, darunter neben anderen Beispielen Lenksteuerungen, Gaspedal - /Drosselsteuerungen, Bremssteuerungen, Signalisierungssteuerungen. In einigen Fällen kann ein Fahrzeug auch vollständig oder teilweise basierend auf Benutzereingaben gesteuert werden. Beispielsweise können Benutzerschnittstellen (z.B. 230) Fahrsteuerungen (z.B. ein physisches oder virtuelles Lenkrad, Gaspedal, Bremsen, eine Kopplung usw.) beinhalten, um einem menschlichen Fahrer zu ermöglichen, von dem autonomen Fahrsystem (z.B. in einem Handover oder im Anschluss an eine Fahrerassistenzhandlung) die Steuerung zu übernehmen. Andere Sensoren können genutzt werden, um Benutzer-/Fahrgasteingaben entgegenzunehmen, wie etwa Sprachdetektion, Gestendetektionskameras und andere Beispiele. Benutzerschnittstellen (z.B. 230) können die Wünsche und Absichten der Fahrgäste/Benutzer erfassen und der autonome Fahrstapel des Fahrzeugs 105 kann diese als zusätzliche Eingaben beim Steuern des Fahrens des Fahrzeugs (z.B. Fahrsteuerungen 220) berücksichtigen. In einigen Implementierungen können Fahrsteuerungen durch externe Rechensysteme gesteuert werden, wie etwa in Fällen, in denen ein Fahrgast eine externe Vorrichtung (z.B. ein Smartphone oder Tablet) nutzt, um eine Fahrtrichtung oder Steuerung bereitzustellen, oder in Fällen eines entfernten Valet-Dienstes, in denen ein externer Fahrer oder ein externes System die Steuerung des Fahrzeugs übernimmt (z.B. basierend auf einem Notfallereignis), neben anderen Implementierungsbeispielen. Bereitgestellte Benutzerschnittstellen 230 können Fahrgästen/Benutzern eines Fahrzeugs auch Informationen präsentieren und können unter anderem Anzeigebildschirme, Lautsprecher und andere Schnittstellen beinhalten, um Benutzern optische oder akustische Statusinformationen anzuzeigen.
Wie vorstehend besprochen, kann der autonome Fahrstapel eines Fahrzeugs eine Vielfalt von Sensordaten (z.B. 258) nutzen, die durch verschiedene Sensoren erzeugt werden, die in dem und außerhalb des Fahrzeugs bereitgestellt sind. Als ein Beispiel kann ein Fahrzeug 105 eine Anordnung von Sensoren 225 besitzen, um verschiedene Informationen bezüglich der Außenseite des Fahrzeugs und der umliegenden Umgebung, des Fahrzeugsystemstatus, der Bedingungen innerhalb des Fahrzeugs und anderer Informationen, die durch die Module des Systems 210 für automatisiertes Fahren des Fahrzeugs verwendbar sind, zu sammeln. Beispielsweise können solche Sensoren 225 neben anderen beispielhaften Sensoren GPS- (Global Positioning) -Sensoren 268, LIDAR- (Light Detection and Ranging) Sensoren 270, zweidimensionale (2D-) Kameras 272, dreidimensionale (3D-) oder Stereokameras 274, akustische Sensoren 276, IMU- (Inertial Measurement Unit, Trägheitsmesseinheit) Sensoren 278, thermische Sensoren 280, Ultraschallsensoren 282, Biosensoren 284 (z.B. Gesichtserkennung, Spracherkennung, Pulsfrequenzsensoren, Körpertemperatursensoren, Emotionsdetektionssensoren usw.), Radarsensoren 286 und Wettersensoren (nicht gezeigt) umfassen. Die Sensordaten 258 können auch (oder stattdessen) durch Sensoren erzeugt werden, die nicht integral mit dem Fahrzeug verbunden sind, darunter Sensoren an anderen Fahrzeugen (z.B. 115) (die durch Fahrzeug-zu-Fahrzeug-Kommunikation oder andere Methoden an das Fahrzeug 105 kommuniziert werden können), Sensoren an Boden- oder Luftdrohnen, Sensoren von Benutzervorrichtungen (z.B. Smartphone oder Wearable), die von menschlichen Benutzern innerhalb oder außerhalb des Fahrzeugs 105 getragen werden, und Sensoren, die montiert oder an anderen Straßenrandelementen bereitgestellt sind, wie etwa einer Straßenrandeinheit (z.B. 140), einem Verkehrszeichen, einer Ampel, einer Straßenlaterne usw. Sensordaten von solchen externen Sensorvorrichtungen können unter anderem direkt von den Sensorvorrichtungen an das Fahrzeug geliefert werden oder können durch Datenaggregationsvorrichtungen oder als Ergebnisse bereitgestellt werden, die basierend auf diesen Sensoren durch andere Rechensysteme (z.B. 140, 150) erzeugt werden.
In einigen Implementierungen kann ein autonomes Fahrzeugsystem 105 mit Informationen und Diensten, die von anderen Rechensystemen bereitgestellt werden, eine Schnittstelle bilden und diese nutzen, um die Funktionalität für autonomes Fahren der Vorrichtung 105 zu verbessern, zu ermöglichen oder anderweitig zu unterstützen. In einigen Fällen können manche Merkmale autonomen Fahrens (einschließlich einiger der vorliegend erörterten beispielhaften Lösungen) durch Dienste, Rechenlogik, Maschinenlernmodelle, Daten oder andere Ressourcen von Rechensystemen außerhalb eines Fahrzeugs ermöglicht werden. Wenn solche externen Systeme für ein Fahrzeug nicht verfügbar sind, kann es sein, dass diese Merkmale zumindest temporär deaktiviert sind. Beispielsweise können externe Rechensysteme bereitgestellt und genutzt werden, die in Straßenrandeinheiten oder Fog-basierten Edge-Vorrichtungen (z.B. 140), anderen (z.B. höheren) Fahrzeugen (z.B. 115) und Cloud-basierten Systemen 150 (z.B. zugänglich durch verschiedene Netzwerkzugangspunkte (z.B. 145)) gehostet werden. Eine Straßenrandeinheit 140 oder ein Cloud-basiertes System 150 (oder ein anderes kooperierendes System, mit dem ein Fahrzeug (z.B. 105) interagiert, kann die gesamte oder einen Teil der Logik beinhalten, die als zu einem beispielhaften fahrzeuginternen automatisierten Fahrsystem (z.B. 210) gehörig veranschaulicht ist, zusammen mit möglicher zusätzlicher Funktionalität und Logik. Beispielsweise kann ein Cloud-basiertes Rechensystem, eine Straßenrandeinheit 140 oder ein anderes Rechensystem eine Maschinenlern-Engine beinhalten, die Modelltrainings- und/oder Inferenz-Engine-Logik unterstützt. Beispielsweise können solche externen Systeme bessere Datenverarbeitungsressourcen und entwickeltere oder aktuellere Maschinenlernmodelle besitzen, wodurch ermöglicht wird, dass diese Dienste überlegene Ergebnisse gegenüber dem liefern, was nativ auf dem automatisierten Fahrsystem 210 eines Fahrzeugs erzeugt würde. Beispielsweise kann ein automatisiertes Fahrsystem 210 auf dem Maschinenlerntraining, der Maschinenlerninferenz und/oder Maschinenlernmodellen beruhen, die durch einen Cloud-basierten Dienst für bestimmte Aufgaben und das Handhaben bestimmter Szenarien bereitgestellt werden. Tatsächlich versteht es sich, dass eines oder mehrere der als zu dem Fahrzeug 105 gehörig besprochenen und veranschaulichten Module in einigen Implementierungen alternativ oder redundant innerhalb eines Cloud-basierten, Fog-basierten oder anderen Rechensystems bereitgestellt sein können, das eine autonome Fahrumgebung unterstützt.
Wie erörtert, kann ein Fahrzeug, eine Straßenrandeinheit oder ein anderer Agent eine Vielfalt von Informationen unter Verwendung einer Vielfalt von Sensoren sammeln. Auf solche Daten kann in Verbindung mit einem kritischen Straßenereignis, an dem ein autonomes Fahrzeug beteiligt ist, zugegriffen werden oder diese gesammelt werden. Solche Rohdaten können jedoch umfangreich sein und eine mühsame Anforderung an das Telematiksystem eines Fahrzeugs stellen, das mit dem Bereitstellen dieser Informationen zu anderen Systemen zur Speicherung oder weiteren Analyse beauftragt ist. Während solche Rohsensordaten, die möglicherweise von mehreren unterschiedlichen Agenten in Verbindung mit einem Ereignis bereitgestellt werden, von einem einzigen zentralisierten System aggregiert und verarbeitet werden können, kann eine solche Implementierung Vertrauensschwierigkeiten bei dem zentralisierten Prozessor hervorrufen und komplizierte Filterungs- und Sensorfusionsanalytiken involvieren, um eine Bestimmung bezüglich der Ursachen und Faktoren vorzunehmen, die mit dem zugehörigen Sicherheitsereignis zusammenhängen. Zusätzlich kann Zentralisieren von Ereignisanalysen unter Verwendung von Rohsensordaten angesichts der beteiligten Datentransfers langsam und ineffektiv sein.
In einem verbesserten System, wie etwa in vorliegenden Beispielen besprochen, können kritische Beobachtungen unter Verwendung der Logik für autonomes Fahren vorgenommen werden, die sich auf den verschiedenen beteiligten oder einem Ereignis als Zeugen anwesenden Straßenagenten befindet, und die Beobachtungsergebnisse können von den Straßenagenten beinahe gleichzeitig mit dem Auftreten des Ereignisses gemeldet werden. Solche Beobachtungsergebnisdaten können beispielsweise gemeldet werden, indem jede der Beobachtungen in eine Blockchain-basierte Datenbank geschrieben wird (z.B. anstelle der den Beobachtungen zugrundeliegenden Sensordaten), was die Bandbreite reduzieren kann, die für solche Transaktionen verwendet wird, und eine vertrauenswürdige konsensbasierte Beurteilung des Ereignisses ermöglichen kann. Tatsächlich kann auf die Verwendung (und Übertragung) der zugrundeliegenden Rohdaten vollständig verzichtet werden. Ferner kann eine Blockchain-basierte verteilte Datenbank zusätzlich einen kryptografischen Nachweis kritischer Beobachtungen und eine Analyse der Sicherheitsperformanz durch alle beteiligten oder einem Unfall als Zeugen anwesenden Akteure enthalten. Diese Beobachtungen können dann als Teil einer öffentlichen (verteilten) Kette vorliegen, die nicht manipuliert werden kann. Konsens zur Einhaltung von Vorschriften durch jeden Akteur, der an dem Ereignis beteiligt ist, kann dann unter Verwendung der Blockchain-Aufzeichnungen des Ereignisses (z.B. durch vertrauenswürdige nachgeschaltete Akteure) erreicht werden. Ferner können Beurteilungen basierend auf den Beobachtungen aktualisiert werden, wenn zusätzliche Beobachtungen geliefert werden (z.B. durch andere Agenten). Schlussendlich kann die Analyse der Beobachtungen verwendet werden, um zu offenbaren, dass ein bestimmter Akteur (oder bestimmte Akteure) für ein gegebenes Ereignis (z.B. Unfall) verantwortlich ist/sind.
In einigen Implementierungen sind automatisiert fahrende Fahrzeuge und andere Straßenagenten dafür konfiguriert, vertrauenswürdige Sicherheitsbeobachtungen von Verkehrsereignissen durchzuführen, die sich selbst (Akteur oder Zeuge) in eine verifizierbare verteilte Datenbank in Form einer Blockchain involvieren könnten oder nicht. In einigen Fällen werden Beobachtungen, die durch die Agenten bestimmt werden, unter Verwendung von Logik basierend auf einem standardisierten Sicherheitsentscheidungsmodell (z.B. RSS) oder anderer regelbasierter Logik mit eingebetteten Verkehrsregeln und Fahrstandards durchgeführt werden. Diese Beobachtungen können in einer Blockchain zur Verwendung beim Beurteilen der Einhaltung von Sicherheitsvorschriften aller an einem Vorfall beteiligten Fahrzeuge gespeichert werden. Des Weiteren kann Konsens der Beobachtungen des Vorfalls durch mehrere Agenten bestimmt werden (manuell oder unter Nutzung von Rechenlogik (z.B. maschinelles Lernen) und der Konsens sicher (z.B. mit den zugrunde liegenden Beobachtungen) in der Blockchain gespeichert werden.
In Fortführung der Erörterung von 2 kann bei einigen Implementierungen ein beispielhafter Agent, wie etwa das Fahrzeug 105, Funktionalität beinhalten, um dem Agenten zu ermöglichen, seine Beobachtungen eines Straßenereignisses in eine öffentliche verteilte Datenbank beizutragen (z.B. basierend auf Blockchain), um sicherzustellen, dass Unfallbeobachtungen von den Agenten aufgezeichnet werden, die an dem kritischen Straßenereignis (z.B. Unfall, Verkehrsverstoß, Vergehen usw.) beteiligt sind und/oder mögliche Zeugen für die Ursache und Umstände des Ereignisses sind. Ein solches System kann die Erzeugung einer sicheren und manipulationssicheren Aufzeichnung der Ereignisse ermöglichen, bei denen möglicherweise keine menschlichen Augen vorhanden sind. Beispielsweise können ein oder mehrere Agenten, die an der Szene eines Unfalls anwesend sind, jeweils mit einem jeweiligen Sicherheitsbeobachtungssystem (z.B. 208) ausgestattet sein, das dafür konfiguriert ist, Sensordaten zu verarbeiten, die an dem Agenten erzeugt werden oder anderweitig für diesen zugänglich sind, und eine Bewertung der mit dem jeweiligen Ereignis verbundenen Regelkonformität zu ermitteln. Die Ergebnisse dieser Bewertung (z.B. ausgeführt als Beobachtungsdaten (z.B. 262), können in die verteilte Datenbank (z.B. eine öffentliche Blockchain) geladen werden, die auf einer Anzahl von Rechensystemen in einem Netzwerk (z.B. 150) gehostet wird. Die Beobachtungen, die der verteilten Datenbank bereitgestellt werden, können dann genutzt werden, um Konsens dieser Beobachtungen zu ermitteln, die genutzt werden können, um ein skalierbares, sicheres, öffentlich verifizierbares und manipulationssicheres Zeugnis bereitzustellen, das beispielsweise in Verbindung mit Rechts-, Wartungs- und/oder Versicherungsansprüchen, die sich aus dem Ereignis ergeben, verwendet werden kann.
Beispielsweise kann eine beispielhafte Sicherheitsbeobachtungs-Engine 208 Logik eines automatisierten Fahrsystems 210 nutzen, wie etwa Logik, die zum Implementieren eines standardisierten Fahrstandards (z.B. RSS) genutzt wird, sowie die Sensoren 225 des Fahrzeugs 105, um Beobachtungen in Verbindung mit durch das Fahrzeug 105 detektierten Sicherheitsereignissen zu ermitteln. Ein Sicherheitsereignis kann ein Ereignis sein, das direkt das Fahrzeug 105 involviert oder Fahrzeuge (z.B. 115), Eigentum, Personen, Tiere usw. außerhalb des Fahrzeugs 105 involvieren kann (das aber die Sensoren 225 des Fahrzeugs zumindest teilweise beobachtet haben können). Ein Ereignis kann automatisch detektiert werden, beispielsweise basierend auf Kollisions- oder anderen Sensoren oder Systemen, die an einem Fahrzeug vorhanden sind, das an dem Ereignis beteiligt ist, oder anderen Systemen (z.B. Drohnen, Straßenrandsensoren usw.), die bei dem Ereignis als Zeugen zugegen sind. Die Detektion eines Ereignisses kann dazu führen, dass ein Signal zum Empfang durch nahegelegene Systeme rundgesendet wird, um Sensordaten (z.B. 258) zu bewahren, die gleichzeitig mit dem Ereignis erzeugt werden. In anderen Fällen kann die Anwesenheit eines Agenten (z.B. 105, 115 usw.) in Reaktion auf eine Detektion eines Ereignisses dokumentiert werden und jeder Agent kann später aufgefordert werden, Informationen bezüglich des Ereignisses zu einem späteren Zeitpunkt (z.B. durch Heranziehen der Sensordaten (z.B. 258), die in Bezug auf das Ereignis aufgezeichnet und gespeichert sind) bereitzustellen. In einigen Implementierungen kann eine Beobachtungs-Engine (z.B. 260) eine oder mehrere Schlussfolgerungen oder Beobachtungen bezüglich Bedingungen und Verhalten von Entitäten, die an dem Ereignis beteiligt sind, aus den Sensordaten (z.B. 258) ermitteln, die durch die Sensoren des Agenten gleichzeitig mit dem Auftreten des Ereignisses erzeugt werden. In einigen Implementierungen können die Beobachtungen, die unter Verwendung der Beobachtungs-Engine (und der Logik der Beobachtungs-Engine selbst) bestimmt werden, auf einem automatisierten Fahrsicherheitsmodell (z.B. RSS) beruhen, so dass die Beobachtungen Eigenschaften des Verhaltens der beteiligten Entitäten identifizieren, die bis zu und nach dem Ereignis führen und definierte Verhaltensweisen und Praktiken in dem Sicherheitsmodell betreffen. Beispielsweise kann eine Beobachtungs-Engine 260 identifizieren, dass ein Ereignis aufgetreten ist (z.B. basierend auf einer internen Detektion des Ereignisses durch Systeme des Fahrzeugs 105 oder in Reaktion auf eine Benachrichtigung über das Auftreten des Ereignisses, die durch eine externe Quelle übertragen wird), und Sensordaten 258 identifizieren, die durch den Sensor 225 innerhalb eines Zeitfensters erzeugt werden, das mit dem Vorfeld und Auftreten des Ereignisses zusammenfällt. Aus dieser Auswahl von Sensordaten kann die Beobachtungs-Engine 260 neben anderen Beispielen Geschwindigkeiten anderer Fahrzeuge, laterale Bewegung anderer Fahrzeuge oder Akteure, Status von Ampeln, Bremslichtern und anderen Attributen ermitteln und ferner ermitteln, ob die Handlungen von Entitäten, die an dem Ereignis beteiligt sind, einer oder mehreren Sicherheitsregeln oder Standards entsprechen, die durch ein Sicherheitsmodell definiert sind. Beobachtungen, die durch die Beobachtungs-Engine 260 bestimmt werden, können in Beobachtungsdaten 262 umgesetzt sein und können zur Speicherung in einem sicheren Datenspeicher (z.B. unter Verwendung der Berichterstattungs-Engine 264), wie etwa einer Blockchain-basierten öffentlichen verteilten Datenbank, berichtet werden. Beobachtungsdaten 262 können ferner unter anderem unter Verwendung der Berichterstattungs-Engine 264 an die Systeme anderer interessierter Parteien gemeldet werden, wie etwa den Fahrzeughersteller, den bzw. die Anbieter, die für das automatisierte Fahrsystem verantwortlich sind, eine Versicherungsfirma usw.
In einigen Implementierungen kann, bevor ermöglicht wird, dass eine Beobachtung in einer verteilten Datenbank (z.B. implementiert in einem Netzwerk von Rechensystemen (z.B. 150)) aufgezeichnet wird, diese zuerst einem Validierungsscreening unterzogen werden, um beispielsweise die Vertrauenswürdigkeit der Beobachtung zu ermitteln, Geofencing von Quellen der Beobachtung durchzusetzen (z.B. Beschränken von Beobachtungen auf jene, die durch Systeme innerhalb des Orts des Ereignisses erzeugt wurden), Formatierungsregeln durchzusetzen und Sicherheitsrichtlinien durchzusetzen, neben anderen Regeln und Richtlinien. In einigen Implementierungen kann die Validierung auf zuvor autorisierte Systeme beschränkt sein. Validierte Beobachtungen können beispielsweise durch einen Schlüssel signiert werden, einen bestimmten Hash-Wert beinhalten oder andere kryptografische Sicherheitsdaten beinhalten, um zu identifizieren, dass die Beobachtung durch ein vertrauenswürdiges System validiert wurde (z.B. ausgestattet mit vertrauenswürdiger Hardware oder durch eine vertrauenswürdige Instanz mit dem/den erforderlichen kryptografischen Schlüssel(n) versehen). In einigen Implementierungen kann das Sicherheitsbeobachtungssystem 208 (oder separate Systeme des Fahrzeugs 105, die mit entsprechender Logik konfiguriert sind) Logik zum Durchführen einer Validierung von Beobachtungen beinhalten, die durch die Beobachtungs-Engine 260 bestimmt werden. Beispielsweise kann, wie in 2 gezeigt, ein Sicherheitsbeobachtungssystem 208 optional eine Validierungs-Engine 265 beinhalten. In anderen Fällen kann die Berichterstattungs-Engine 264 die durch die Beobachtungs-Engine 260 erzeugten Beobachtungsdaten 262 an ein separates System (z.B. außerhalb des Fahrzeugs 105) berichten, um die Validierung durchzuführen, und schlussendlich die validierte Beobachtung in der verteilten Datenbank aufzeichnen. Bei Implementierungen wie etwa der in dem Beispiel von 2 gezeigten kann, neben anderen Implementierungsbeispielen, das Fahrzeug 105 effektiv das Laden der Beobachtungsdaten in einen Block einer blockchainbasierten verteilten Datenbank (z.B. durch Erstellen eines neuen Blocks für die Datenbank einschließlich der Beobachtung) auch direkt am Fahrzeug (z.B. unter Verwendung der Blockchain-Engine 266) selbst validieren und durchführen.
Beobachtungen, die in eine verteilte Datenstruktur (z.B. eine verteilte verknüpfte Datenstruktur, wie etwa eine Blockchain-basierte Datenstruktur) geladen werden, können von anderen Akteuren genutzt werden, um die Ursachen, Umstände und Bedingungen eines zugehörigen Sicherheitsereignisses zu ermitteln. In einigen Implementierungen, wie etwa in den im Beispiel von 2 gezeigten, können ein oder mehrere Sicherheitsbeurteilungssysteme 215 genutzt werden, um die Aufzeichnungen der verteilten Datenstruktur zu lesen und Beobachtungsdaten zu finden, die Beobachtungen entsprechen, die durch Sicherheitsbeobachtungssysteme eines oder mehrerer Agenten erzeugt wurden und ein bestimmtes Ereignis beschreiben. In einem Beispiel beinhaltet ein Sicherheitsbeurteilungssystem 215 einen oder mehrere Prozessoren (z.B. 288), ein oder mehrere Speicherelemente (z.B. 289) und Logik, die durch den einen oder die mehreren Prozessoren (z.B. 288) ausführbar ist, die eine Beurteilungs-Engine (z.B. 290) enthalten, die dafür konfiguriert ist, einen Konsensalgorithmus unter Verwendung von Beobachtungen eines Ereignisses als Eingaben durchzuführen. Eine Beurteilung kann aus den Beobachtungen bestimmt werden, die aus der verteilten Datenstruktur erhalten werden, wobei die Beurteilung eine Konsensbeobachtung für die Umstände, Bedingungen und/oder Ursache des Ereignisses repräsentiert. Beurteilungsdaten können erzeugt und auch an die verteilte Datenstruktur angehängt werden, so dass neben anderen Implementierungsbeispielen sowohl die Beobachtungsdaten als auch die zugehörigen Beurteilungsdaten sicher und zuverlässig in derselben verteilten Datenstruktur enthalten sind.
Unter Bezugnahme auf 3 ist ein vereinfachtes Blockdiagramm 300 gezeigt, das beispielhafte Stufen von autonomem Fahren veranschaulicht, die in verschiedenen Fahrzeugen (e.g) durch deren entsprechende fahrzeuginterne Rechensysteme unterstützt werden können. Beispielsweise kann ein Stufenbereich definiert sein (z.B. L0-L5 (405-435)), wobei Stufe 5 (L5) Fahrzeugen mit der höchsten Stufe an autonomer Fahrfunktionalität (z.B. Vollautomatisierung) entspricht und Stufe 0 (L0) der niedrigsten Stufe an autonomer Fahrfunktionalität (z.B. keine Automatisierung) entspricht. Beispielsweise kann ein L5-Fahrzeug (z.B. 335) ein vollständig autonomes Rechensystem besitzen, das in der Lage ist, eine autonome Fahrleistung in jedem Fahrszenario bereitzustellen, die gleich oder besser ist, als wenn sie von einem menschlichen Fahrer bereitgestellt würde, einschließlich unter extremen Straßen- und Wetterbedingungen. Ein L4-Fahrzeug (z.B. 330) kann auch als vollständig autonom angesehen werden und in der Lage sein, autonom sicherheitskritische Fahrfunktionen durchzuführen und Fahrbahnbedingungen während einer gesamten Fahrt von einem Startort zu einem Zielort effektiv zu überwachen. L4-Fahrzeuge können sich von L5-Fahrzeugen darin unterscheiden, dass autonome Fähigkeiten eines L4 innerhalb der Grenzen der „Betriebsgestaltungsdomäne“ des Fahrzeugs definiert sind, die möglicherweise nicht alle Fahrszenarien beinhaltet. L3-Fahrzeuge (z.B. 320) stellen autonome Fahrfunktionalität bereit, um sicherheitskritische Funktionen in einem Satz spezifischer Verkehrs- und Umgebungsbedingungen vollständig zu dem Fahrzeug zu verschieben, die aber immer noch die Beteiligung und Verfügbarkeit menschlicher Fahrer erwarten, um das Fahren in allen anderen Szenarien zu handhaben. Dementsprechend können L3-Fahrzeuge Handover-Protokolle bereitstellen, um die Übertragung der Steuerung von einem menschlichen Fahrer auf den autonomen Fahrstapel und zurück zu orchestrieren. L2-Fahrzeuge (z.B. 315) stellen Fahrerassistenzfunktionalität bereit, die es dem Fahrer ermöglicht, sich gelegentlich aus dem physischen Betrieb des Fahrzeugs zu lösen, so dass sowohl die Hände als auch die Füße des Fahrers periodisch von den physischen Steuerungen des Fahrzeugs gelöst werden können. L1-Fahrzeuge (z.B. 310) stellen Fahrerassistenz einer oder mehrerer spezifischer Funktionen (z.B. Lenken, Bremsen usw.) bereit, erfordern aber immer noch eine konstante Fahrersteuerung der meisten Funktionen des Fahrzeugs. L0-Fahrzeuge können als nicht autonom betrachtet werden - der menschliche Fahrer steuert die gesamte Fahrfunktionalität des Fahrzeugs (obwohl solche Fahrzeuge dennoch passiv innerhalb autonomer Fahrumgebungen teilnehmen können, wie etwa durch Bereitstellen von Sensordaten an Fahrzeuge höherer Ebene, Verwenden von Sensordaten zum Verbessern von GPS- und Infotainmentdiensten innerhalb des Fahrzeugs usw.). In einigen Implementierungen kann ein einzelnes Fahrzeug einen Betrieb auf mehreren autonomen Fahrstufen unterstützen. Beispielsweise kann ein Fahrer steuern und auswählen, welche unterstützte Autonomiestufe während einer gegebenen Fahrt verwendet wird (z.B. L4 oder eine niedrigere Stufe). In anderen Fällen kann ein Fahrzeug autonom zwischen Stufen umschalten, beispielsweise basierend auf Bedingungen, die die Fahrbahn oder das autonome Fahrsystem des Fahrzeugs beeinflussen. In Reaktion auf Detektieren, dass ein oder mehrere Sensoren kompromittiert wurden, kann zum Beispiel ein L5- oder L4-Fahrzeug unter anderem in einen niedrigeren Modus (z.B. L2 oder niedriger) wechseln, um einen menschlichen Fahrgast angesichts des Sensorproblems einzubeziehen.
4 ist ein vereinfachtes Blockdiagramm 400, das einen beispielhaften autonomen Fahrablauf veranschaulicht, der in einigen autonomen Fahrsystemen implementiert werden kann. Beispielsweise kann ein autonomer Fahrablauf, der in einem autonomen (oder halbautonomen) Fahrzeug implementiert ist, eine Erfassungs- und Wahrnehmungsphase 405, eine Planungs- und Entscheidungsphase 410 und eine Steuer- und Handlungsphase 415 beinhalten. Während einer Erfassungs- und Wahrnehmungsphase 405 werden Daten durch verschiedene Sensoren erzeugt und zur Verwendung durch das autonome Fahrsystem gesammelt. Datensammlung kann in einigen Fällen Datenfiltern und Empfangen eines Sensors von externen Quellen beinhalten. Diese Phase kann auch Sensorfusionsoperationen und Objekterkennung und andere Wahrnehmungsaufgaben, wie etwa Lokalisierung, beinhalten, die unter Verwendung eines oder mehrerer Maschinenlernmodelle durchgeführt werden. Eine Planungs- und Entscheidungsphase 410 kann die Sensordaten und Ergebnisse verschiedener Wahrnehmungsoperationen nutzen, um probabilistische Vorhersagen der vorausliegenden Fahrbahn(en) zu treffen und einen Echtzeit-Wegplan basierend auf diesen Vorhersagen zu ermitteln. Eine Planungs- und Entscheidungsphase 410 kann zusätzlich ein Treffen von Entscheidungen bezüglich des Wegplans in Reaktion auf Detektion von Hindernissen und anderen Ereignissen beinhalten, um zu entscheiden, ob und welche Aktion angesichts dieser Ereignisse vorzunehmen ist, um sicher auf dem bestimmten Weg zu navigieren. Basierend auf dem Wegplan und Entscheidungen der Planungs- und Entscheidungsphase 410 kann eine Steuer- und Handlungsphase 415 diese Bestimmungen durch Aktuatoren in Handlungen umwandeln, um Fahrsteuerungen, einschließlich Lenken, Beschleunigen und Bremsen, sowie sekundäre Steuerungen, wie etwa Abbiegesignale, Sensorreiniger, Windschutzscheibenwischer, Ampeln usw., zu manipulieren. Entsprechend kann, wie in 5 veranschaulicht, die allgemeine Funktion eines automatisierten Fahrsystems 210 die Eingaben einer oder mehrerer Sensorvorrichtungen 225 (z.B. mehrere Sensoren mehrerer unterschiedlicher Typen) nutzen und diese Eingaben verarbeiten, um eine Bestimmung für das automatisierte Fahren eines Fahrzeugs vorzunehmen. Um die Performanz des automatisierten Fahrens (z.B. Beschleunigung, Lenken, Bremsen, Signalisierung usw.) zu realisieren, kann das automatisierte Fahrsystem 210 ein oder mehrere Ausgangssignale erzeugen, um die bestimmten automatisierten Fahrhandlungen zu implementieren, und diese Signale an eine oder mehrere Fahrsteuerungen senden, oder allgemeiner „Aktuatoren“ 220, die genutzt werden, um zu bewirken, dass das entsprechende Fahrzeug diese Fahrhandlungen durchführt.
6 ist ein vereinfachtes Blockdiagramm, das die beispielhafte Interaktion von Komponenten und Logik veranschaulicht, die gemäß einer beispielhaften Implementierung zum Implementieren eines fahrzeuginternen automatisierten Fahrsystems verwendet werden. Beispielsweise kann eine Vielfalt von Sensoren und Logik bereitgestellt sein, die Daten erzeugen kann, die durch das automatisierte Fahrsystem verwendet werden können, wie etwa, neben anderen beispielhaften Sensoren, Trägheitsmesseinheiten (IMUs) 605, Odometrielogik 610, Bordsensoren 615, GPS-Sensoren 268, Kartendaten 620, Wegpunktdaten und -Logik (z.B. 625), Kameras (z.B. 272), LIDAR-Sensoren 270, Nahbereichsradarsensoren 286a, Langbereichsradarsensoren 286b, einem nach vorne gerichteten Infrarot- (forward-looking infrared, FLIR-) Sensor 630. Zusätzliche Informationen können von Quellen außerhalb des Fahrzeugs (z.B. durch ein Netzwerk, das Fahrzeug-zu-Alles- (V2X-) Kommunikation (z.B. 635) ermöglicht) oder von dem Benutzer des Fahrzeugs (z.B. Fahrziele (z.B. 640) oder andere Eingaben, die von Fahrgästen innerhalb des Fahrzeugs bereitgestellt werden (z.B. durch Mensch-Maschine-Schnittstellen (z.B. 230)) bereitgestellt werden. Einige dieser Eingaben können einer Wahrnehmungs-Engine 238 bereitgestellt werden, die die Informationen beurteilen kann, die in Sensordaten enthalten sind, die durch einen oder eine Kombination der Sensoren des Fahrzeugs (oder sogar externe (z.B. Straßenrand-) Sensoren) erzeugt werden, und eine Objektdetektion durchführen (z.B. um mögliche Gefahren und Straßeneigenschaften zu identifizieren), die Objekte klassifizieren (z.B. um zu ermitteln, ob sie Gefahren sind oder nicht) und Objekte verfolgen (z.B. um eine Bewegung der Objekte zu ermitteln und vorherzusagen und festzustellen, ob oder wann die Objekte das Fahren des Fahrzeugs beeinflussen sollten).
Andere Sensoren und Logik (z.B. 268, 620, 625 usw.) können der Lokalisierungs- und Positionierungslogik (z.B. 240) des automatisierten Fahrsystems zugeführt werden, um eine genaue und präzise Lokalisierung des Fahrzeugs durch das automatisierte Fahrsystem zu ermöglichen (z.B. zum Verständnis der Geolokalisierung des Fahrzeugs sowie seiner Position relativ zu bestimmten tatsächlichen oder erwarteten Gefahren usw.). Ergebnisse der Wahrnehmungs-Engine 230 und der Lokalisierungs-Engine 240 können zusammen durch die Wegplanungslogik 242 des automatisierten Fahrsystems genutzt werden, so dass das Fahrzeug selbst zu einem gewünschten Ergebnis navigiert, was unmittelbarer und auf sichere Weise erfolgt. Fahrverhaltensplanungslogik (z.B. 650) kann bei einigen Implementierungen ebenfalls bereitgestellt werden, um Fahrziele (z.B. Systemebenen- oder benutzerangepasste Ziele) zu berücksichtigen, um bestimmte Fahr- oder Benutzerkomforterwartungen (z.B. Geschwindigkeit, Komfort, Verkehrsvermeidung, Mautstraßenvermeidung, Priorisierung landschaftliche reizvoller Routen oder Routen, die das Fahrzeug in der Nähe bestimmter Sehenswürdigkeiten oder Freizeiteinrichtungen halten usw.). Die Ausgabe des Fahrverhaltensplanungsmoduls 650 kann auch in eine Wegplanungs-Engine 242 eingespeist und durch diese beim Ermitteln des wünschenswertesten Weges für das Fahrzeug berücksichtigt werden.
Eine Wegplanungs-Engine 242 kann über den Pfad entscheiden, der von einem Fahrzeug genommen werden soll, wobei eine Bewegungsplanungs-Engine 655 mit dem Ermitteln beauftragt wird, „wie“ dieser Weg des Fahrzeugs zu realisieren ist (z.B. durch die Fahrsteuerlogik (z.B. 220). Die Fahrsteuerlogik 220 kann zudem den gegenwärtigen Zustand des Fahrzeugs, der unter Verwendung einer Fahrzeugzustandsschätzungs-Engine 660 bestimmt wird, berücksichtigen. Die Fahrzeugzustandsschätzungs-Engine 660 kann den gegenwärtigen Zustand des Fahrzeugs ermitteln (z.B. in welche Richtung(en) es sich gegenwärtig bewegt, die Geschwindigkeit, mit der es fährt, ob es beschleunigt oder langsamer wird (z.B. bremst) usw.), der beim Ermitteln berücksichtigt werden kann, welche Fahrfunktionen des Fahrzeugs betätigt werden sollen und wie dies durchzuführen ist (z.B. unter Verwendung der Fahrsteuerlogik 220). Beispielsweise können einige der Sensoren (z.B. 605, 610, 615 usw.) als Eingaben an die Fahrzeugzustandsschätzungs-Engine 660 geliefert werden und Zustandsinformationen können erzeugt und an die Fahrsteuerlogik 220 geliefert werden, die zusammen mit Bewegungsplanungsdaten (z.B. von der Bewegungsplanungs-Engine 655) berücksichtigt werden können, um unter anderem die verschiedenen Aktuatoren des Fahrzeugs anzuweisen, den gewünschten Fahrweg genau, sicher und komfortabel zu implementieren (z.B. indem Lenksteuerungen (z.B. 665), Drossel (z.B. 670), Bremsen (z.B. 675), Fahrzeugkarosseriesteuerungen (z.B. 680) usw. betätigt werden).
Um die Performanz des automatisierten Fahrsystems und seiner kollektiven Komponenten zu beurteilen, können in einigen Implementierungen auch ein oder mehrere Systemverwaltungswerkzeuge (z.B. 685) bereitgestellt sein. Beispielsweise können die Systemverwaltungswerkzeuge 685 unter anderem Logik zum Detektieren und Protokollieren von Ereignissen und verschiedenen Daten, die durch das automatisierte Fahrsystem gesammelt und/oder erzeugt werden, zum Beispiel zum Detektieren von Trends, Verbessern oder Trainieren von Maschinenlernmodellen, die durch das automatisierte Fahrsystem verwendet werden, und Identifizieren und Beheben möglicher Sicherheitsprobleme oder Fehler beinhalten. Tatsächlich können die Systemverwaltungswerkzeuge 685 in einigen Implementierungen Sicherheitsuntersysteme oder Begleitwerkzeuge beinhalten und können ferner Fehlerdetektions- und -behebungswerkzeuge beinhalten, neben anderen beispielhaften Werkzeugen und zugehöriger Funktionalität. In einigen Implementierungen kann Logik, die zum Implementieren des automatisierten Fahrsystems genutzt wird (z.B. Wahrnehmungs-Engine 238, Lokalisierungs-Engine 240, Fahrzeugzustandsschätzungs-Engine 660, Sensorfusionslogik, Maschinenlerninferenz-Engine und Maschinenlernmodelle, usw.) genutzt werden, um, neben anderen beispielhaften Verwendungen, eine Beobachtungs-Engine am Fahrzeug zu unterstützen oder zumindest teilweise zu implementieren, die Sensordaten verwenden kann, um beobachtete Eigenschaften eines identifizierten Ereignisses zu ermitteln und entsprechende Beobachtungsdaten zu erzeugen, die in Aufzeichnungen einer verteilten Datenbank zu laden sind.
Unter Bezugnahme auf 7 ist ein vereinfachtes Blockdiagramm gezeigt, das eine Darstellung einer beispielhaften verteilten Blockchain-Datenstruktur 700 veranschaulicht. Die verteilte Datenstruktur kann aus einer „Kette“ verknüpfter Blockstrukturen (z.B. 705a-c) bestehen. Jeder Block kann einen jeweiligen Block-Header (z.B. 710a-c) beinhalten, der einen Hash (z.B. 725a-c) des Headers des vorhergehenden Blocks beinhaltet, um als Verknüpfung mit dem vorhergehenden Block in der Kette zu dienen. Ein Blockheader (z.B. 710a-c) kann eine Vielfalt anderer Daten oder Felder basierend auf der jeweiligen Implementierung der Datenstruktur beinhalten, einschließlich Feldern, die unter anderem die Zeit der Erstellung des Blocks angeben, einen Nonce-Wert, der für den Hash verwendet wird, und einen Merkle-Wurzelwert (z.B. 730a-c). Jeder Block (z.B. 705a-c) beinhaltet zusätzlich jeweilige Transaktionsdaten 715a-c. In einigen Implementierungen kann die Blockchain-basierte verteilte Datenstruktur 700 zum Speichern von Beobachtungen dediziert sein, die durch Rechensysteme erzeugt werden, die autonome Fahrumgebungen implementieren und in Reaktion auf Sicherheitsereignisse gesammelt werden (z.B. innerhalb einer gegebenen geografischen Domäne oder weltweit). In anderen Implementierungen kann die verteilte Datenstruktur 700 gemischt verwendet werden, wobei Beobachtungen Fahrsicherheitsereignisse beinhalten, die als Transaktionen innerhalb der Blöcke (z.B. 705a-c) zusammen mit anderen Transaktionen enthalten sind. In solchen Beispielen können andere Transaktionen nicht-sicherheitsbezogene Ereignisse beinhalten und beschreiben oder können Beobachtungen anderer nicht-fahrbezogener Sicherheitsereignisse beinhalten. In einigen Fällen können die Transaktionsdaten 715a-c eine einzige Beobachtung oder Transaktion beinhalten. In anderen Fällen können mehrere Transaktionen, sogar mehrere unterschiedliche Beobachtungen (z.B. die mehrere unterschiedliche Ereignisse beinhalten) in einem einzigen Block gespeichert werden. Ein Merkle-Wurzelwert (z.B. 730a-c) kann basierend auf dem kombinierten Inhalt der Transaktionen/Beobachtungen, die in den Transaktionsdaten 715a-c enthalten sind, erzeugt werden. Beobachtungsdaten (z.B. 720a-c), die innerhalb eines Blocks (z.B. 705a-c) gespeichert sind, können Informationen zusätzlich zu den Beobachtungen beinhalten, die aus Sensordaten an einem System eines Straßenakteurs erzeugt werden, wie etwa eine Kennung, die dem in der Beobachtung beschriebenen Ereignis zugeordnet ist, Zeit- und/oder Standortinformationen, die der Beobachtung entsprechen, Identifikation des Systems und der Systemkomponenten, die bei der Erzeugung der Beobachtung genutzt werden (z.B. Modellnummer, Versionsnummer, Seriennummer usw.), neben anderen Beispielinformationen. Zusätzlich dazu können Beobachtungsdaten in einigen Fällen neben der bestimmten Beobachtung unter anderem auch eine Kopie der Rohsensordaten (und Unterentscheidungen, Inferenzen usw.) beinhalten, die an dem Straßenakteur erzeugt und zum Erzeugen der Beobachtung(en) genutzt werden.
Unter Bezugnahme auf 8 ist ein beispielhaftes Fahrsicherheitsereignis veranschaulicht, das durch die Rechensysteme und Sensoren verschiedener Agenten überwacht und beobachtet werden kann. Allgemein können, wenn ein Unfall auftritt, mehrere unterschiedliche Agenten vorhanden sein, einschließlich eines oder mehrerer aktiver Fahrzeuge (z.B. 105, 110) sowie passiver Agenten (Zeugen), die unter anderem entweder andere Fahrzeuge (z.B. 115) sein könnten, Infrastrukturelemente (z.B. am Straßenrand angebrachte Kameras oder andere Sensoren (z.B. 810)) oder Umstehende (wobei z.B. Daten von einer Personal-Computing-Vorrichtung gesammelt werden, die von dem Umstehenden gehalten oder getragen wird). Angesichts mehrerer unterschiedlicher Agenten können die Umstände, die zu einem bestimmten Ereignis (z.B. Unfall 830) führen, aus mehreren Perspektiven analysiert werden.
In dem Beispiel von 8 sind die Fahrzeuge 1 (105) und 2 (110) an einer Kollision an einer Kreuzung 805 beteiligt. Mindestens ein anderes Fahrzeug (Fahrzeug 3 (115)) ist an der Kreuzung 805 vorhanden und Sensoren des Fahrzeugs 115 „bezeugen“ den Unfall durch Aufzeichnen von Bedingungen an oder nahe dem Fahrzeug vor und während der Kollision. Zusätzlich können auch Zeugen-Systeme vorhanden sein, die entweder als zusätzliche Fahrzeuge oder Straßenrandsensoren implementiert sind. Beispielsweise kann im Beispiel von 8 eine Kamera 810, die an einer Ampel (z.B. 815 a) montiert ist, auch Bedingungen und Fahrzeugverhalten an der Kreuzung 805 beobachten. In diesem Beispiel (auf das als ein nicht einschränkendes Beispiel zum Bereitstellen eines Kontextes für nachfolgende Figuren und Erörterung zurückgegriffen werden wird) fährt das Fahrzeug 1 zum Zeitpunkt t-2 auf die Kreuzung 805 zu, tritt zum Zeitpunkt t-1 die Kollision auf, und werden zum Zeitpunkt t Sensordaten durch jedes der Zeugen-Systeme (z.B. 105, 110, 115, 810) zusammengeführt, und eine Beobachtung kann erzeugt und mit anderen Systemen (z.B. zur Aufnahme in eine verteilte Datenbankaufzeichnung) gemeinsam genutzt werden. Jedes der beobachtenden Agentensysteme (z.B. 105, 110, 115, 810) kann mit Logik zum Erkennen von Fahrzeugen und deren Verhalten, Straßengefahren (z.B. 820), Fahrspurmarkierungen (z.B. 825), Verkehrszeichen und -signalen (z.B. 125, 130a-b, 815a-b), neben anderen Bedingungen (z.B. menschliche oder tierische Akteure, Wetterbedingungen, Straßenbedingungen usw.), und Ermitteln von ordnungsgemäßem Betriebsverhalten aus diesen Bedingungen (z.B. basierend auf einem standardisierten Sicherheitsmodell) ausgestattet sein. Jedes beobachtende System kann eine oder mehrere Beobachtungen, die den Unfall beschreiben, unter Verwendung dieser Logik erzeugen, wobei die Beobachtungen eine Einhaltung eines oder mehrerer Fahrsicherheitsstandards durch eines oder mehrere der Fahrzeuge (z.B. 105, 110, 115) vor Ort beschreiben.
Wie durch 9 veranschaulicht, können die Beobachtungen (z.B. 905a-d), die durch die jeweiligen Agentensysteme (z.B. 105, 110, 115, 810) erzeugt werden, mehrere Blickpunkte eines Verkehrssicherheitsereignisses repräsentieren. Tatsächlich kann die Analyse aus der Sicht jedes Agenten als ein jeweiliges „Zeugnis“ jedes Agenten bezüglich des Ereignisses zur Verwendung in einer späteren Phase beim Feststellen von Rollen und Verantwortungen innerhalb eines Versicherungsanspruchs oder eines Gerichtsprozesses betrachtet werden. Tatsächlich können die Beobachtungen als Eingaben in eine Nachverarbeitung der Beobachtungen aller Agenten, die als Zeugen des Ereignisses identifiziert werden, bereitgestellt werden, um einen Konsens dessen zu erreichen, was geschehen ist.
Im Beispiel von 9 wird der Unfall aus 8 durch die spezifischen Beobachtungen 905a-d jedes der Agentensysteme (z.B. 105, 110, 115, 810) beschrieben. Beispielsweise kann das System des Fahrzeugs 1 aus seinen lokalen Sensordaten ermitteln, dass es in die Kreuzung 805 eingetreten ist, während seine Ampel (z.B. 130a) grün war (zum Zeitpunkt t-2), und ferner ermitteln, dass es mit 25 Meilen pro Stunde (mph) (in einer 30 mph-Zone) durch die Kreuzung gefahren ist, als das Fahrzeug 2 (110) mit dem Fahrzeug 1 (105) in der Kreuzung 805 kollidierte. Das Fahrzeug 2 (110) kann seine lokalen Sensordaten unter Verwendung von Logik für autonomes Fahren verarbeiten, um seine eigenen Beobachtungen anzustellen, wie etwa, dass das Fahrzeug 110, während seine Ampel (z.B. 815a) grün war, bei einer Geschwindigkeit von 25 mph in die Kreuzung 805 eingefahren ist. Das Fahrzeug 2 (110) kann ferner ermitteln, dass basierend auf der Identifikation des Fahrzeugs 1 und dem Standort und der Geschwindigkeit des Fahrzeugs 1 dieses Fahrzeug 1 unter anderen beispielhaften Beobachtungen bei oder unmittelbar vor dem Unfall nicht das erwartete Vorfahrtsrecht beachtet hat. Während die Beobachtungen 905 a,b widersprüchlich sein können, können zusätzliche Beobachtungen verfügbar sein, die zu einer Konsensbeobachtung des Ereignisses führen können. Beispielsweise kann die Beobachtung 905c eines dritten Fahrzeugs 115 durch das System des Fahrzeugs 115 basierend auf seinen lokalen Sensordaten erzeugt werden, um zu ermitteln, dass es an der Kreuzung stand (basierend auf der Erkennung, dass seine Ampel rot war), dass das Fahrzeug 2 mit einer Geschwindigkeit von 29 mph fuhr, als es mit dem Fahrzeug 1 (das mit 25 mph fuhr) kollidierte, und dass das Fahrzeug 1 in die Kreuzung 805 ein, während dessen Ampel 130a grün war. Ferner kann ein Straßenrandsensorsystem (z.B. 810) seine Daten verarbeiten, um zu ermitteln, dass die Ampeln (z.B. 130a-b, 815a-b) zum Zeitpunkt t-2 für das Fahrzeug 1 (105) Grün und für das Fahrzeug 2 (110) Rot signalisierten, dass zum Zeitpunkt des Unfalls (t-1) die Geschwindigkeit des Fahrzeugs 1 29 mph betrug und die Geschwindigkeit des Fahrzeugs 2 30 mph betrug und dass die Kollision zwischen den Fahrzeugen 1 und 2 aufgetreten ist. Jede dieser Beobachtungen (z.B. 905a-d) repräsentiert mehr als Rohsensordaten, ist aber das Produkt mehrerer möglicher Verarbeitungsrunden mehrerer möglicher Arten von Sensordaten, um die Beobachtung anzustellen (z.B. Sensorfusion, Objektdetektion/-erkennung, Bewegungserfassung, Wegplanung usw.). Aus diesen mehreren Beobachtungen kann eine Konsensanalyse (z.B. 910) durchgeführt werden, die in diesem Beispiel identifiziert, dass das Fahrzeug 2 (110) das Vorfahrtrecht und Rotlichtstandards/-regeln verletzt hat und als Verursacher des Unfalls gelten sollte.
Das Sammeln von Beobachtungen durch Straßenagentensysteme kann besonders kritisch bei teil- oder vollständig automatisierten Fahrbedingungen sein, bei denen Verantwortlichkeiten nicht durch menschliche Beobachtungen und Zeugnisse, sondern durch automatisierte Fahrzeuge oder intelligente Infrastruktursensoren festgestellt werden könnten. In einigen Implementierungen können Einschränkungen oder Annahmen in den Systemen vorgenommen werden, die solche Beobachtungen erzeugen, sodass Informationen vertrauenswürdig und sicher sind (z.B. um darauf zu vertrauen, dass Beobachtungen eines gegebenen Agenten gemäß seinen Wahrnehmungs- und Beobachtungsfähigkeiten wahr sind und nicht das Ergebnis von Betrug oder sogar eines physischen Angriffs, der seine Wahrnehmungs- oder Beobachtungsfähigkeiten geändert hat). In einigen Implementierungen kann Zensur von Systembeobachtungen beschränkt oder verboten sein, wodurch ermöglicht wird, dass potentiell jeder Agent, der (gemäß Bestimmung) bei dem Unfall zugegen war, aus einem jeweiligen Blickwinkel seine Bezeugung auf eine Weise zu dem Unfall beiträgt, die öffentlich, unzensiert und nicht manipuliert ist, sobald sie öffentlich gemacht wird. Das Ermitteln der Gesamtheit von Agenten, für die Beobachtungen erzeugt und berücksichtigt werden können, kann beispielsweise durch Geo- und Timefencing des Straßenereignisses bestimmt werden (z.B. Implementieren einer Regel, dass, um eine Beobachtung zu übermitteln, der Agent an dem Ort und zum Zeitpunkt des Ereignisses anwesend sein muss). Zusätzlich dazu können Beobachtungen definiert werden, um den beitragenden Agenten spezifisch zu identifizieren, wodurch ermöglicht wird, dass das Vertrauen in diesen Agenten beurteilt wird, sowie um zu identifizieren, wie die Logik und Sensordaten, die der bzw. den Beobachtung(en) eines gegebenen Agenten zugrunde liegen, zu prüfen oder weiter zu verarbeiten sind. In einigen Implementierungen können ein derartiges Vertrauen und eine derartige Sicherheit neben anderen beispielhaften Merkmalen zumindest teilweise unter Verwendung einer Kombination vertrauenswürdiger Ausführungsumgebungen und Blockchain-Technologie implementiert werden.
Angesichts des Obigen kann ein System ermöglichen, dass jeder beteiligte Straßenagent wertvolle Beobachtungen eines Straßenereignisses beiträgt, angesichts dessen, dass es in naher Zukunft möglicherweise keinen Menschen gibt, der an den Beobachtungen beteiligt ist, und somit automatisierte Systeme diese Beobachtungen vornehmen müssen. Ferner kann eine Konsensbestimmung bezüglich der Ursachen und Umstände eines Ereignisses auf einer konsolidierten Sicherheitsbeurteilung aus all diesen Beobachtungen basieren und als vertrauenswürdige gesetzliche Beweise zur Verwendung bei einer weiteren Handlung gespeichert werden (z.B. Zivil- oder Strafprozesse, Versicherungsansprüche, Rückmeldung an Anbieter autonomer Fahrzeuge usw.). Gemäß 10 ist eine Darstellung 1000 einer beispielhaften Verkehrssicherheits-Blockchain-Datenstruktur 700 zur Verwendung in Verbindung mit einem beobachtungsbasierten Konsenssystem veranschaulicht. Eine Verkehrssicherheits-Blockchain-Datenstruktur kann als verteilte Plattform implementiert sein, um Beobachtungen von Verkehrssicherheitsverstößen zu speichern, die durch authentifizierte Straßenagenten durchgeführt und durch andere Blockchain-Knoten validiert werden. Zusätzlich dazu kann eine Verkehrssicherheits-Blockchain-Datenstruktur Beurteilungen speichern, die aus den gesammelten Beobachtungen bestimmt werden, die eine Konsenszusammenfassung aller Beobachtungen repräsentieren, die ein Ereignis betreffen.
Verschiedene funktionale Rollen können innerhalb eines Systems definiert sein, die eine beispielhafte Verkehrssicherheits-Blockchain-Datenstruktur 700 implementieren und zu dieser beitragen, wie in dem Beispiel von 10 veranschaulicht ist. Beispielsweise führen Beobachter (z.B. 1005, 1010, 1015), wie etwa Straßenagenten, Beobachtungen durch, die durch Validierungsknoten (z.B. 1020, 1025, 1030, 1035, 1040) validiert werden. Sicherheitsbeurteilungsknoten (z.B. 215, 1045, 1050) führen Beurteilungen über die validierten Beobachtungen durch, die in der Verkehrssicherheits-Blockchain dargestellt werden. Es kann ein einziges System oder mehrere unterschiedliche Systeme genutzt werden, um alle Rollen für die Verkehrssicherheits-Blockchain 700 durchzuführen. In einigen Fällen kann eine höhere Sicherheit oder Autorisierung erforderlich sein, um einem System zu ermöglichen, manche der Funktionen innerhalb der Verkehrssicherheits-Blockchain durchzuführen, da die Beobachtungen und Beurteilungen, die auf diesen Beobachtungen basieren, gesetzlich bindende Folgen innerhalb des Verwaltungsorgans haben können, unter dem ein bestimmter Verkehrsverstoß stattgefunden hat.
In einer beispielhaften Implementierung können die funktionalen Rollen in einer Verkehrssicherheits-Blockchain Beobachter, Validierer und Sicherheitsbeurteiler beinhalten. Diese Funktionen können in separaten Softwarefunktionen definiert sein, die in separaten Systemen oder innerhalb eines einzigen Systems (z.B. Hardwareelement) ausgeführt werden können. In einem Beispiel können Funktionsanforderungen für einen Beobachter derart definiert sein, dass der Systemeigentümer als Rechtssubjekt innerhalb eines Verwaltungsorgans registriert ist, das mit der Verkehrssicherheits-Blockchain assoziiert ist (z.B. durch Registrierung eines Fahrzeugeigentümers durch einen gültigen Führerschein oder eine Fahrzeugregistrierung, Registrierung von Straßenrandüberwachungsgeräten (z.B. intelligenten Kreuzungen) durch eine Verkehrsverwaltungsbehörde, um zu bestätigen, dass das bzw. die Überwachungsgeräte gültige Software ausführen und mit einem gültigen privaten Schlüssel signiert sind, Registrierung eines autonomen Fahrzeugs bei der Verkehrsverwaltungsbehörde, die bestätigt, dass sie gültige standardkonforme Software ausführt und dass ihre Beobachtungen mit einem gültigen privaten Schlüssel signiert sind, Registrierung eines Verarbeitungsknotens bei der Verkehrsverwaltungsbehörde, die bestätigt, dass sie gültige Software ausführt und ihre Aktivitäten mit einem gültigen privaten Schlüssel signiert sind usw.). Ferner kann die Qualifizierung als gültiger Beobachter auf einem Beweis (z.B. gesammelte Daten, die zeigen) basieren, dass der Beobachter an dem Standort, an dem das Verkehrssicherheitsereignis gemeldet wird, innerhalb eines Zeitfensters zugegen war, das mit dem Auftreten des Verkehrssicherheitsereignisses assoziiert ist. Ein Validierer kann mit Durchführen von Konformitätsprüfungen an eingehenden Blöcken für die Verkehrssicherheits-Blockchain beauftragt werden. Diese Blöcke können Beobachtungen und/oder Sicherheitsbeurteilungen beinhalten. Der Validierer muss als Voraussetzung für die Aufnahme des Blocks in die Verkehrssicherheits-Blockchain bewerten, dass der Block legitim ist. Eine solche Validierung beinhaltet eine Bestimmung der Beobachter- und Sicherheitsbeurteilerregistrierung, Prüfungen bezüglich Mindestanforderungen an die Beobachtungen und Sicherheitsbeurteilungen, neben anderen beispielhaften Beurteilungen. Fehlschläge bei den Prüfungen können zur Zurückweisung des Blocks führen, was an die Quelle des Blocks zurückgemeldet werden kann, um eine Fehlerkorrektur oder Behebung von Datenbeschädigungsfehlern während Übertragungen zu ermöglichen. Ein Sicherheitsbeurteiler kann mit dem Durchführen einer Sicherheitsbeurteilung beauftragt werden, die einen Konsens eines Verkehrsereignisses darstellt, wobei alle Beobachtungen berücksichtigt werden, die in die Verkehrssicherheits-Blockchain aufgenommen wurden. Die Entitäten, die in der Lage sind, diese Beurteilungen durchzuführen, könnten denselben Einschränkungen unterliegen, die vorstehend für Beobachter beschrieben wurden. Beispielsweise muss, neben anderen beispielhaften Vorschriften, ein Sicherheitsbeurteilungsknoten möglicherweise bei den Verwaltungsorganbehörden unter Verwendung der Verkehrssicherheits-Blockchain registriert werden, eine Beurteilung für ein Ereignis basierend auf allen Beobachtungen desselben Verkehrssicherheitsvorfalls durchführen (wie z.B. durch Orts- und Zeitgrenzen definiert), alle aktiven und passiven Agenten, die an dem Verkehrssicherheitsvorfall beteiligt sind, eindeutig identifizieren und eine Sicherheitsanalyse gemäß den Regeln und Standards der entsprechenden Verwaltungsorganbehörde durchführen.
Unter weiterer Bezugnahme auf 10 können Straßenagenten (z.B. 1005, 1010, 1015) in einem Beispiel vorgeschlagene Blöcke erzeugen, die ihren jeweiligen Beobachtungen entsprechen, und können die vorgeschlagenen Blöcke (z.B. 1060, 1065, 1070) an verschiedene Validierungsknoten (z.B. 1020, 1025, 1030) rundsenden, um die Blöcke zu validierung und Hinzufügung der Blöcke zu einer Blockchain-basierten verteilten Datenstruktur (z.B. 700) zu initiieren. Wie vorliegend angemerkt, kann in einigen Implementierungen die Validierung an den Straßenagentensystemen selbst durchgeführt werden. Eine Gabelauswahl oder ein anderer Algorithmus kann definiert werden, um die Art und Weise zu regeln, auf die Versionen einer Blockchain-Datenstruktur übernommen werden, wobei jene Versionen der Datenstruktur (z.B. 1035, 1040) belohnt werden, die mehr Arbeit abgeschlossen haben (z.B. validierte Blöcke), so dass die Kopien der Blockchain-Datenstruktur, die an den verschiedenen Knoten verwaltet werden, um sich schlussendlich zu einer einzigen akzeptierten Version der Datenstruktur (z.B. einschließlich aller neu übermittelten Beobachtungsblöcke (z.B. 1060, 1065, 1070) zu vereinigen. Die neu hinzugefügten Blöcke können zusammen mit anderen Blöcken in der Datenstruktur durch Sicherheitsbeurteilungssysteme (z.B. 215, 1045, 1050) geparst werden, um eine Teilmenge von Blöcken zu detektieren, die Beobachtungen enthalten, die einem jeweiligen Ereignis von Interesse entsprechen (z.B. basierend auf den Beobachtungen, die eine jeweilige Zeit und Geografie identifizieren, die mit dem jeweiligen Ereignis zusammenhängen). Die Sicherheitsbeurteilungssysteme (z.B. 215, 1045, 1050) können die Beobachtungen lesen und einen Konsensalgorithmus oder eine andere Logik anwenden, um eine Beurteilung aus den Beobachtungen zu ermitteln und einen Beurteilungsblock (z.B. 1075a-c) zur Hinzufügung zu der Blockchain-basierten verteilten Datenstruktur 700 zu erzeugen. Der Beurteilungsblock kann unter anderem die Blöcke (z.B. 1060, 1065, 1070) identifizieren, die Beobachtungen enthalten, auf die zum Erzeugen der Beurteilung zurückgegriffen wird.
Wie vorstehend ausführlich beschrieben, können Beobachteragenten in einigen Implementierungen durch einen Satz vorbestimmter Urheberschafts- oder Inhaltsanforderungen eingeschränkt sein. Die Durchsetzung dieser Anforderungen kann in mehreren Formen erfolgen. Sie kann zum Beispiel Teil der Client-Software sein, die auf den Beobachterknoten läuft und die Verteilung von Beobachtungen auf eine Verkehrssicherheits-Blockchain-Struktur ermöglicht. Straßenagenten sind beispielsweise in der Lage, Beobachtungen von Verkehrsereignissen durchzuführen, sie im richtigen Verkehrssicherheits-Blockchain-Blockformat zu packen und sie an andere Systeme zur Verifizierung auf das Verkehrssicherheits-Blockchain-Netzwerk zu senden. Die Validierungsknoten in dem Verkehrssicherheits-Blockchain-Netzwerk können dann die Überprüfungen auf Gültigkeit der Beobachtung durchführen. Diese Überprüfungen können durchgeführt werden, um zu verhindern, dass nicht autorisierte Agenten mit falschen Beobachtungen bei einem Verkehrsereignis betrügen. Ähnliche Regeln können auf Sicherheitsbeurteilungsknoten angewendet werden, um neben anderen beispielhaften Richtlinien sicherzustellen, dass ihre Beurteilungsblöcke ebenfalls vertrauenswürdig und verifiziert sind.
Es versteht sich, dass Beobachtungen, die unter Verwendung von Logik automatisierter Fahrsysteme erzeugt werden, potentiell in jeder beliebigen sicheren Datenbank gespeichert werden können. Blockchain-basierte Datenspeicher können bei manchen Implementierungen aufgrund der durch Blockchain angebotenen Sicherheit, Datenintegrität und Dezentralisierung besonders nützlich sein. Beispielsweise stellt eine dezentrale, verteilte öffentliche Datenbank einen Mechanismus für einander nicht vertrauende Parteien bereit, um die Fairness des Sicherheitsbeobachtungsspeichers sicherzustellen. Zensur kann hierdurch ebenfalls verhindert werden, was eine reichhaltige Quelle durch Crowdsourcing erhaltener Beobachtungen in Bezug auf Sicherheit ermöglicht. Die Speicherung und Validierung sicherheitsverkehrsbezogener Beobachtungen können somit auf eine verteilte Weise durch mehrere Entitäten geschützt werden, einschließlich, ohne jedoch hierauf eingeschränkt zu sein, Regierungsentitäten, wie etwa Verkehrsministerien auf Bundes- und Staatsebene, National Highway Traffic Safety Administration (NHTSA), Kraftfahrzeugämter, Polizeibehörden, Gerichtssysteme usw.; Nichtstaatliche Parteien, wie etwa Versicherungsbehörden, Verbraucherschutzorganisationen, öffentliche Sicherheitsorganisationen usw.; und einzelne Bürger, die dafür bezahlt werden könnten, dass sie validieren, dass die in der Blockchain enthaltenen Beobachtungen berechtigt sind, neben anderen Beispielen. Sobald Beobachtungen in der Blockchain gespeichert sind, können kryptografische Elemente ferner garantieren, dass keine Zensur dieser Beobachtungen erfolgt. Dies erfolgt über öffentliche Verifizierbarkeit. In dem verteilten Ledger einer Blockchain-basierten Datenstruktur wird jeder Zustandsübergang durch Verifizierer bestätigt, Beobachter können jedoch dennoch prüfen, dass sich der Zustand des Ledgers gemäß dem Protokoll geändert hat (eine neue Beobachtung vorgenommen wurde). Dies ermöglicht Integrität, indem sichergestellt wird, dass die Informationen vor unbefugten Modifikationen geschützt sind. Konsensoperationen an Sicherheitsbeurteilungen können dann basierend auf den vollständigen Beobachtungen erfolgen, die in der Verkehrssicherheits-Blockchain-Struktur gespeichert sind, und das Ergebnis dieser Beobachtungen mit Zeigern auf die tatsächlichen Daten bei der Berechnung verwendet werden, und Metadaten, die den Beurteilungskriterien zugeordnet sind, können dann unter anderem als Beweis für Ansprüche oder juristische Schritte in die Blockchain angehängt werden. Solche Merkmale können unter anderem umständliche Prozesse des Datenabrufs, der Analyse und von Rechtsstreitigkeiten beschleunigen und automatisieren.
Gemäß 11 ist ein vereinfachtes Blockdiagramm 1100 bereitgestellt, um die beispielhafte Erzeugung eines Beobachtungsblocks 1105 durch ein Straßenagentensystem zur Aufnahme in eine beispielhafte Verkehrssicherheits-Blockchain-Struktur zu veranschaulichen. Beispielsweise kann eine Warnung angezeigt werden, um ein Verkehrssicherheitsereignis mit Flag 1110 zu versehen bzw. zu identifizieren. Das Verkehrssicherheitsereignis kann von einem Fahrzeug, das an dem Ereignis beteiligt ist, einem Straßenrandagenten, der eine Straße überwacht, von öffentlichen Sicherheitsbehörden, Helfern vor Ort oder anderen Systemen erkannt und ausgestrahlt werden, um zu identifizieren, dass ein Unfall aufgetreten ist oder dass ein Unfall erkannt wurde. Ereignisgrenzen können so definiert werden, dass sie dem identifizierten Ereignis entsprechen (z.B. basierend auf Daten, die durch Systeme an Fahrzeugen gesammelt werden, die an dem Ereignis beteiligt sind). Agentensysteme, die das gesendete Ereignis empfangen, können Rohsensordaten, Protokolle und andere Daten zwischenspeichern, die gesammelt oder erzeugt werden, während das Agentensystem innerhalb der Ereignisgrenzen zugegen war. Diese Daten können durch den Systemagenten zurückgesetzt und verarbeitet 1115 werden, um eine oder mehrere Beobachtungen zu ermitteln, die dem Ereignis entsprechen. Der Systemagent kann Zeit- und Standortgrenzen spezifizieren (bei 1120), die mit den Beobachtungen des Straßenagenten assoziiert werden sollen, die geparst werden sollen, um Ereignisgrenzen (Ort und Zeit) zu erstellen. Agentensystemen kann eine eindeutige ID zugewiesen werden und diese können (bei 1125) die ID in den Beobachtungsdaten (oder anderen Informationen zum Identifizieren des Agentensystems) beinhalten. Kartendaten, die für den Agenten genutzt werden oder verfügbar sind, um die Schauplatz des Ereignisses zu beschreiben, können ebenfalls erzeugt werden oder es kann auf diese zugegriffen werden (bei 1130) und diese können in die Beobachtungsdaten aufgenommen werden, wie etwa Straßengeometrie, Fahrspurtopologie, Kreuzungstopologie und andere Informationen. Die Beobachtungsinformationen können (bei 1135) in ein vordefiniertes Beobachtungsblockformat gepackt und (bei 1140) durch den Agenten signiert werden (z.B. unter Verwendung eines privaten Schlüssels, einer eindeutigen ID und Signatur oder einer anderen Technik), um den Straßenagenten, der den Beobachtungsblock erzeugt, zu identifizieren und zu zertifizieren. Der Block kann dann (bei 1145) an ein oder mehrere andere Systeme zur Validierung und Aufnahme in eine Verkehrssicherheits-Blockchain-Struktur übertragen werden.
In einigen Implementierungen können ein Format oder Felder von Beobachtungen für einen Eintrag in eine verteilte Datenbankstruktur definiert sein, um spezielle Informationen zu identifizieren, die in einer Beobachtung enthalten sein sollen. Wie beispielsweise in der in 11 gezeigten beispielhaften Beobachtung 1105 veranschaulicht, kann die Beobachtung Zeit- und Ortsgrenzeninformationen identifizieren, die in der Beobachtung beschriebenen Ereignisakteure identifizieren (die aufgrund dessen, dass ein Agent nicht in der Lage ist, die anderen Fahrzeuge konkret zu identifizieren und/oder um die Privatsphäre der Akteure zu bewahren usw., durch ein Pseudomonym identifiziert werden können) und den Agenten zu identifizieren, der für die Erzeugung der Beobachtung verantwortlich ist. Ferner kann die Beobachtung eine standardisierte Beschreibung der Kartendaten beinhalten, die den Ort betreffen, an dem das Ereignis stattgefunden hat. Implementierungen dieses Teils der Nachricht können Standardstrukturen unterstützen, wie etwa jene, die, neben anderen beispielhaften Standards, in SAE J2735-DSRC- (Dedicated Short Range Communications, dedizierte Nahbereichskommunikation) Nachricht oder SAE J2945/10 empfohlene Praktiken für SPAT-/MAP- (Signal Phase in Time and Map Data, Signalphasen in Zeit- und Kartendaten) Nachrichten beschrieben sind. Die Beobachtung kann dann die durch das Agentensystem bestimmten Umstände und Handlungen unter Verwendung von Sensordaten, die an dem Agenten erzeugt werden, identifizieren.
In einigen Implementierungen können die Handlungen und Umstände eines Ereignisses, das in einer Beobachtung beschrieben ist, durch eine sequenzielle Ereignisbeschreibung umgesetzt werden, die aus Messungen von den verschiedenen Sensoren abgeleitet wird, mit denen ein Akteur ausgestattet ist (z.B. Beschleunigungsmesser, Kameras, LIDAR, Radarsensoren, Näherungssensoren usw.). Diese Beschreibung identifiziert einen Akteur an einem bestimmten Ort in der beschriebenen Karte, der eine bestimmte Aktion durchführt, die unter Verwendung der Maschinenlern- und Computervisionsfähigkeiten des Agentensystems bestimmt wird. Die Ereignisbeschreibung kann so viele Einträge enthalten, wie Beobachtungsänderungen notwendig sind, um das vollständige Ereignis zu beschreiben (nur begrenzt durch die Qualität und Menge von Sensordaten, die dem Agentensystem des Ereignisses zur Verfügung stehen). Diese Beobachtungsänderungen können Aktionen von Agenten sein, die Längs-, Breitenänderungen oder Umgebungsänderungen oder -zustände umfassen (unter anderem z.B. Ampeländerungen oder Übertretungen signalisierter Befehle). Die Zeit- und Ortsgrenzen können verwendet werden, um ein spezifisches Verkehrsereignis eindeutig zu identifizieren. In einigen Fällen können Akteure unterschiedliche Zeiten und Orte melden, obwohl sie demselben Ereignis zugeordnet sind (z.B. Rundungseffekte oder aufgrund der Tatsache, dass sie unterschiedliche Perspektiven des Ereignisses widerspiegeln). In solchen Fällen können Beobachtungen desselben Ereignisses dennoch in Übereinstimmung gebracht werden, beispielsweise durch probabilistisches Ermitteln von Gemeinsamkeit basierend auf einer Überlappung von Ort und Zeit innerhalb eines tolerierbaren Spielraums. In Fällen, in denen ein standardisiertes Sicherheitsmodell beim Erzeugen und Artikulieren einer autonom erzeugten Beobachtung genutzt wird, können Zustandsprotokolle einer formalen Sicherheitsanalyse, wie sie laterale und longitudinale Sicherheitsabstände, Zeit bis zur Kollision, zulässige Manöver und Verhalten an Kreuzungen betreffen, wie etwa jene, die in RSS-(Responsibility-Sensitive-Safety-) Definitionen definiert sind, als Beobachtungen aufgenommen werden. Neben anderen beispielhaften Verbesserungen können Berechnungen, die in dem Modell enthalten sind, genutzt werden, um eine Verletzung von Regeln, die in dem Modell definiert sind (z.B. RSS), durch Fahrzeuge zu ermitteln.
Gemäß 12 ist ein Blockdiagramm 1200 gezeigt, das die Entwicklung einer Verkehrssicherheits-Blockchain veranschaulicht, die Beobachtungen eines bestimmten Sicherheitsereignisses enthält. Anfänglich kann ein Blockersteller (z.B. ein Straßenagent) seinen Block (oder seine Beobachtungsdaten) nur an eine Teilmenge der Rechensysteme in dem Netzwerk senden, die die Verkehrssicherheits-Blockchain-Struktur pflegen. Tatsächlich können unterschiedliche Rechensysteme in dem Netzwerk die verschiedenen Beobachtungen der möglicherweise mehreren Agenten empfangen, die an dem Ereignis beteiligt sind und/oder bei diesem als Zeugen zugegen waren. Dementsprechend enthält, wie in 12 veranschaulicht, anfänglich die Verkehrssicherheits-Blockchain-Struktur in jedem System in dem Netzwerk möglicherweise nicht alle Beobachtungen eines Verkehrsereignisses. Wie bei herkömmlichen Blockchain-Implementierungen werden Versionen der Blockchain (z.B. 1205, 1210), die mehr gültige Ereignisse enthalten, ausgezeichnet oder stärker gewichtet, was eine Übernahme jener Versionen der Blockchain mit der vollständigsten Liste von Beobachtungen und hochgeladenen Ereignissen (gegenüber weniger vollständigen Versionen (z.B. 1215, 1220, 1225)) bewirkt. Tatsächlich wird die Blockchain, die in jedem Netzwerksystem verwaltet wird, durch Peer-to-Peer-Aktualisierung letztendlich die Version der Blockchain sein, die alle Beobachtungsblöcke enthält, die durch möglicherweise mehrere Agenten erzeugt werden, die das Ereignis beobachten. Sobald eine Beobachtung hochgeladen und in der Verkehrssicherheits-Blockchain-Struktur akzeptiert ist, wird sie durch den sensitiven Hashing-Algorithmus, der sicherstellt, dass jeder Block mit dem vorherigen verknüpft ist, vor Modifikationen geschützt.
Gemäß 13 ist ein vereinfachtes Blockdiagramm 1300 gezeigt, das einen beispielhaften Prozess zum Übermitteln einer Beurteilung an die Verkehrssicherheits-Blockchain-Struktur 700 veranschaulicht. Tatsächlich können Beurteilungen (oder Beurteilungsblöcke) zu der Verkehrssicherheits-Blockchain-Struktur 700 auf eine Weise hinzugefügt werden, die der Übermittlung von Beobachtungen an die Verkehrssicherheits-Blockchain-Struktur 700 ähnlich ist. In einigen Implementierungen kann eine Beurteilung durch eine oder mehrere Sicherheitsbeurteilungsentitäten (z.B. 215) bestimmt werden. Die Beurteilung kann in einem Beurteilungsblock (z.B. 1075) beschrieben werden, der durch das Sicherheitsbeurteilungssystem 215 erzeugt und an ein Validierungsknotensystem (z.B. 1040) übermittelt wird. Der vorgeschlagene Beurteilungsblock (z.B. 1075) kann bei Validierung des Blocks durch das Validierungsknotensystem 1040 zu der Verkehrssicherheits-Blockchain-Struktur hinzugefügt werden. In einem Beispiel können Beurteilungsblöcke Zeiger auf alle Beobachtungsblöcke (z.B. 1320, 1325) enthalten, die in der Blockchain referenziert sind, die zu demselben Straßenereignis gehören und auf denen die Beurteilung basiert.
In einem Beispiel, das in 13 veranschaulicht ist, kann ein Sicherheitsbeurteilungssystem 1350 Beobachtungsblöcke 1320, 1325 (z.B. Blöcke, die eine oder mehrere von Staßenagenten erzeugte Beobachtungen enthalten) parsen, die in einer Verkehrssicherheits-Blockchain-Struktur 700 gespeichert sind, um eine Sammlung von Beobachtungsblöcken zu identifizieren 1355, die ein gemeinsames Ereignis beschreiben. In einigen Fällen kann das Identifizieren der Teilmenge von Beobachtungsblöcken, die einem bestimmten Ereignis entsprechen, durch Identifizieren eines Zeitfensters und/oder geografischen Fensters, das dem Ereignis entspricht, und Identifizieren jener Beobachtungsblöcke durchgeführt werden, die Beobachtungsdaten enthalten, die Zeit- und/oder Standortinformationen für Beobachtungen beinhalten, die angeben, dass diese Beobachtungen wahrscheinlich in Verbindung mit dem Ereignis erzeugt wurden. In weiteren Beispielen können Beobachtungsblöcke mit einer eindeutigen gemeinsamen Ereigniskennung markiert werden und ein Sicherheitsbeurteilungssystem kann Beobachtungen eines gemeinsamen Ereignisses basierend auf einer Aufnahme dieser Kennung in entsprechende Beobachtungsblöcke identifizieren. In einem Beispiel können Agenten, die bei einem Ereignis als Zeugen zugegen sind, mit anderen Agentensystemen (auf einer Peer-to-Peer-Basis) kommunizieren und eine Kennung für das Ereignis verhandeln, die jeder der Agenten in jeweiligen Beobachtungsdaten einfügen kann. In einem anderen Beispiel kann ein Validierungsknoten Beobachtungsblöcke identifizieren, die zu einem gemeinsamen Ereignis gehören (z.B. basierend auf Zeit- und/oder Standortinformationen), und die validierten Beobachtungsblöcke mit einer Kennung kennzeichnen, neben anderen Implementierungsbeispielen.
Das Sicherheitsbeurteilungssystem 215 kann verwendet werden, um Beurteilungen 1360 an der Sammlung von Beobachtungen durchzuführen. In einigen Implementierungen kann dies beinhalten, dass ein menschlicher Benutzer den Inhalt der Beobachtungen beurteilt, um die Beurteilung vorzunehmen oder zu unterstützen. In anderen Implementierungen kann das Sicherheitsbeurteilungssystem 215 selbst autonom eine Beurteilung basierend auf einem Satz von Beobachtungseingaben ermitteln. Beispielsweise kann ein definierter Satz von Beurteilungsregeln programmatisch angewendet werden (z.B. basierend auf einem definierten Sicherheitsmodell (z.B. RSS)), um die Informationen in den Beobachtungsdaten zu parsen und eine Beurteilung basierend auf diesen Regeln zu ermitteln. In einigen Implementierungen können maschinelles Lernen oder computerausgeführte heuristische Modelle durch das Sicherheitsbeurteilungssystem 215 eingesetzt werden, um unter anderen Implementierungsbeispielen autonom aus den Beobachtungsdaten ohne die Führung eines menschlichen Benutzers eine Konsensbeobachtung (z.B. basierend auf Erkennen bestätigender Beschreibungen in den Beobachtungen) zu ermitteln. Beim Ermitteln einer Beurteilung basierend auf einer Sammlung von Beobachtungsdaten von einer Verkehrssicherheits-Blockchain-Struktur kann ein Sicherheitsbeurteilungssystem Beurteilungsdaten erzeugen, die die Beurteilung beschreiben, und das Paket 1365 der Beurteilungsdaten in einem Block der Verkehrssicherheits-Blockchain-Struktur (z.B. einem Beurteilungsblock) verpacken. Das Sicherheitsbeurteilungssystem 215 kann dann die Block- und/oder Beurteilungsdaten signieren und den Block zur Validierung durch einen Validierungsknoten 1040 übermitteln (bei 1370). Sobald validiert, wird der Block (z.B. 1075) an die Verkehrssicherheits-Blockchain-Struktur angehängt.
13 beinhaltet eine Darstellung 1305 beispielhafter Beurteilungsdaten zur Aufnahme in einen Beurteilungsblock. Wie bei Beobachtungsdaten können Beurteilungsdaten gemäß einem definierten Format erzeugt werden, um gewisse standardisierte Informationen bezüglich des Ereignisses zu beinhalten, und eine entsprechende Beurteilung unter Verwendung eines Sicherheitsbeurteilungssystems 215 bestimmt werden. Beispielsweise kann der Inhalt des Beurteilungsblocks 1075 die Sicherheitsbeurteilungskennung, die Grenzen des Straßenereignisses (Ort und Zeit), eine ausführliche konsolidierte Karte, die aus den Beobachtungen extrahiert wird, in einem standardisierten Format enthalten, die Liste aller Beobachtungen (z.B. durch Beobachtung oder Blockkennung), die Liste aller Agenten, die an dem Ereignis beteiligt sind, eine chronologische Ereigniszusammenfassung sowie die Beurteilungskriterien, die auf die Beurteilung angewendet werden, neben anderen Beispielinformationen.
Gemäß 14 ist ein vereinfachtes Blockdiagramm 1400 gezeigt, das eine ergänzende Beurteilung (z.B. 1405) veranschaulicht, die basierend auf der Entdeckung zusätzlicher Beobachtungen (z.B. 1410) für ein Ereignis hinzugefügt werden kann, die möglicherweise in einem vorherigen Sicherheitsbeurteilungsblock (z.B. 1075) nicht berücksichtigt wurden. In einigen Implementierungen enthält ein Beurteilungsblock (z.B. 1075) Zeiger auf alle Beobachtungen (z.B. 1320, 1325), die in der Verkehrssicherheits-Blockchain-Struktur (z.B. 700) existieren und auf denen die Beurteilung basiert. Angesichts der Verteilung der Verkehrssicherheits-Blockchain-Struktur und Straßenagenten, die Blöcke zu der Verkehrssicherheits-Blockchain-Struktur beitragen, können jedoch zu einem bestimmten Zeitpunkt nur partielle Beobachtungen innerhalb der Verkehrssicherheits-Blockchain-Struktur verfügbar sein. Dies bedeutet, dass die erste Beurteilung (in einem ersten Beurteilungsblock 1075 für das Ereignis beschrieben) basierend auf einem nicht vollständigen Satz von Beobachtungen (z.B. 1320, 1325) abgeschlossen wurde. In diesem Fall ist, wenn eine neue Beobachtung gemeldet und an die Verkehrssicherheits-Blockchain-Struktur angehängt wird (z.B. wie Beobachtungsblock 1410), diese neue Beobachtung zweckmäßig nicht mit der bestehenden Beurteilung (in Beurteilungsblock 1315 beschrieben) verknüpft. Dementsprechend kann eine neue Beurteilung durch ein Sicherheitsbeurteilungssystem in Reaktion auf das Hinzufügen einer neuen Beobachtung für das Ereignis initiiert werden. Das Sicherheitsbeurteilungssystem kann die anderen zugehörigen Beobachtungen (z.B. 1320, 1325) identifizieren, die zu der Verkehrssicherheits-Blockchain-Struktur 700 hinzugefügt werden (z.B. durch Konsultieren des Beurteilungsblocks 1075), und einen neuen Beurteilungsprozess basierend auf dem abgeschlossenen (oder aktualisierten) Satz von Beobachtungsblöcken (z.B. 1320, 1325, 1410) durchführen. Ein neuer Beurteilungsblock (z.B. 1405) wird dann erzeugt, um die überarbeitete Beurteilung zu speichern, und an die Verkehrssicherheits-Blockchain-Struktur angehängt. Der revidierte Beurteilungsblock 1405 kann in einigen Implementierungen nicht nur mit den Beobachtungsblöcken (z.B. 1320, 1325, 1410) verknüpft sein, auf die in der revidierten Beurteilung zurückgegriffen wird, sondern kann neben anderen Beispielen auch mit dem vorherigen Beurteilungsblock 1315 verknüpft sein.
Sicherheitsbeurteilungsüberarbeitungen können nicht nur aus zusätzlichen Beobachtungen resultieren, sondern auch aus Überarbeitungen von Sicherheits- oder standardisierten Regeln, die entweder bei der zugrunde liegenden Beobachtung oder der Sicherheitsbeurteilung verwendet werden. Beispielsweise kann ein standardisiertes Sicherheitsmodell genutzt werden und als eine Grundlage der Straßenagentenbeobachtungslogik und/oder der Sicherheitsbeurteilungssystembeurteilungslogik dienen. Sollten Aktualisierungen oder Überarbeitungen an dem zugrunde liegenden Sicherheitsmodell vorgenommen werden, kann dementsprechend auch entsprechende Logik aktualisiert werden. Beispielsweise kann ein Konsensbeobachtungssystem ursprünglich auf Version 1.0 des Sicherheitsmodells (z.B. RSS) basieren, aber zu einem späteren Zeitpunkt kann es zwingend erforderlich sein, eine überarbeitete Version (z.B. Version 1.1) zu nutzen. Ferner werden frühere Beobachtungen und Beurteilungen möglicherweise nicht mehr in Übereinstimmung mit dem neu überarbeiteten Standard betrachtet. Somit kann in einigen Implementierungen eine Aktualisierung zugrunde liegender Sicherheitsstandards auslösen, dass aktualisierte Beobachtungen und/oder aktualisierte Beurteilungen durch ihre jeweiligen Systeme (z.B. Straßenagentensysteme und/oder Sicherheitsbeurteilungssysteme (z.B. 215)) berechnet werden, und entsprechende Ersatzbeobachtungsblöcke und -beurteilungsblöcke können an die Verkehrssicherheit-Bblockchain-Struktur angehängt werden. Solche aktualisierten Blöcke können Informationen beinhalten, um zu identifizieren, dass sie eine Überarbeitung vorheriger Versionen der Konsensbeobachtung darstellen, und können neben anderen beispielhaften Merkmalen mit den vorherigen Beobachtungsblöcken und Beurteilungsblöcken verknüpft sein, um die Beziehung und die Überarbeitung zu speichern.
In einigen Implementierungen kann der Prozess, der zu einer Sicherheitsbeurteilungsentscheidung über ein Ereignis basierend auf Beobachtungen führt, die auf der Verkehrssicherheits-Blockchain-Struktur gespeichert sind, auch verteilt werden. Beispielsweise können mehrere Beurteilungssysteme bereitgestellt und genutzt werden, um eine Konsensbeurteilung zu erreichen, anstatt auf ein einziges Beurteilungssystem zu vertrauen. Tatsächlich können mehrere Sicherheitsbeurteilungen in diesen Prozess involviert sein, um Fehlertoleranz und Zuverlässigkeit (z.B. wodurch ermöglicht wird, dass das System in der Lage ist, den Ausfall oder die Nichtverfügbarkeit einer oder mehrerer Sicherheitsbeurteilungen zu tolerieren) und Fairness (z.B. um die Beurteilungsentscheider derart zu diversifizieren, dass nicht nur auf einen einzigen Sicherheitsbeurteiler vertraut wird) zu gewährleisten. 15 ist ein vereinfachtes Blockdiagramm 1500, das eine Implementierung veranschaulicht, die mehrere Sicherheitsbeurteilungssysteme (z.B. 215, 1045, 1050) beinhaltet, die unter Verwendung eines gemeinsamen Satzes von Beobachtungen für ein Ereignis (z.B. beschrieben in Beobachtungsblöcken 1320, 1325 der Verkehrssicherheits-Blockchain-Struktur 700) zusammenarbeiten, um eine Konsensbeurteilung für das Ereignis zu erreichen. Dementsprechend kann jedes der Sicherheitsbeurteilungssysteme eine jeweilige Beurteilungslogik anwenden (oder alternativ dazu durch eine Beurteilung eines jeweiligen menschlichen Bedieners angesteuert oder durch diese ergänzt werden), um eine jeweilige Entscheidung (z.B. 1515a-c) basierend auf dem gemeinsamen Satz von Beobachtungen (z.B. 1320, 1325) zu erreichen. Ein Validierungsknotensystem (z.B. 1040) oder alternativ ein zusätzliches Sicherheitsbeurteilungssystem kann bereitgestellt sein, um die jeweiligen Beurteilungen zu sammeln und einen standardisierten Konsensalgorithmus anzuwenden, um eine Konsensbeurteilung aus den mehreren Beurteilungseingaben (z.B. 1515a-c) zu ermitteln. Beispielsweise kann der Validierungsknoten 1040 diese Konsensbeurteilung durch zuerst Authentifizieren (z.B. 1525) jedes der teilnehmenden Sicherheitsbeurteilungssysteme (z.B. 215, 1045, 1050) und ihrer Eingaben 1515a-c durch Validieren 1530 ihrer jeweiligen Formate durchführen. Der Konsensalgorithmus kann durch das Validierungsknotensystem 1040 auf die Eingaben angewendet werden 1535, um die Konsensbeurteilung abzuleiten. Die Konsensbeurteilung kann dann als ein Beurteilungsblock 1075 verpackt werden, der an die Verkehrssicherheits-Blockchain-Struktur 700 angehängt 1540 werden soll.
In einigen Implementierungen, bei denen mehrere unterschiedliche Sicherheitsregeln, Standards und entsprechende Modelle koexistieren, können mehrere teilnehmende Sicherheitsbeurteilungssysteme verwendet werden, um zu ermöglichen, dass jede dieser koexistierenden Regeln bei einer Konsensbeurteilung angewendet wird. In einigen Implementierungen kann jedes der mehreren Sicherheitsbeurteilungssysteme (z.B. 1305, 1505, 1510) seine jeweiligen Beurteilungen als Beurteilungsblöcke packen und laden, die an die Verkehrssicherheits-Blockchain-Struktur 700 angehängt sind. Als ein Nachprozess, bei dem mehrere unterschiedliche Beurteilungsblöcke (von mehreren Sicherheitsbeurteilungssystemen) als an die Verkehrssicherheits-Blockchain-Struktur 700 angehängt identifiziert werden, kann ein Validierungsknoten oder ein zusätzliches Sicherheitsbeurteilungssystem die Beurteilungen aus jedem der Blöcke extrahieren und den Konsensalgorithmus durchführen, um eine Konsensbeurteilung basierend auf diesen individuellen Beurteilungen (z.B. 1515a-c) abzuleiten. Ein neuer Beurteilungsblock kann dann an die Verkehrssicherheits-Blockchain-Struktur 700 angehängt werden, der die bestimmte Konsensbeurteilung speichert und der mit den individuellen Beurteilungen (z.B. 1515a-c) verknüpft ist, auf denen die Konsensbeurteilung basiert.
Ein Konsensalgorithmus, der zum Ableiten einer Konsensbeurteilung wie oben eingeführt genutzt wird, kann auf einem beliebigen geeigneten Konsensalgorithmus basieren oder diesen nutzen, um Bestätigungen zwischen den Beurteilungen, einer Mehrheit oder mehreren Konsensen usw. darzustellen. Als ein Beispiel kann ein Validierer unter der Annahme, dass es N Sicherheitsbeurteiler gibt, die Entscheidungen d1, d2,..., dN übermitteln, die endgültige Entscheidung als D = F(d1, d2,..., dN) berechnen, wobei die Funktion F das Histogramm der eingegebenen Entscheidungswerte berechnet und den Entscheidungswert zurückgibt, der die höchste Zählung aufweist. Falls keine Mehrheit festgestellt werden kann, kann der Validierer neben anderen Implementierungsbeispielen eine Warntransaktion speichern, die angibt, dass keine endgültige Entscheidung getroffen werden konnte.
Ein Risiko bei autonomen Beobachtungs- und Beurteilungsoperationen sind die möglichen Integritätsprobleme, die eingeführt werden, wenn eine vertrauenswürdige Operation an einem der Agenten (z.B. einem Straßenagenten, Validierungsknoten, Sicherheitsbeurteilungssystem usw.) kompromittiert wird. Als ein Beispiel kann ein kompromittierter oder bösartiger Agent „lügen“, wie etwa wenn ein Straßenagent bösartig (oder fehlerhaft) einen Beobachtungsbericht mit falschen Informationen eines Straßenereignisses erzeugt. In einigen Implementierungen muss, um als vertrauenswürdiger Agent validiert zu werden, ein Agentensystem möglicherweise gesicherte Hardware und gesicherte Kommunikationsfunktionalität beinhalten, beispielsweise durch eine Kombination einer TTE- (Trusted Execution Environment, vertrauenswürdige Ausführungsumgebung) Implementierung mit vertrauenswürdigen E/A-Blöcken in jedem Straßenagenten. Eine solche Sicherheit kann, neben anderen beispielhaften Lösungen und Implementierungen, garantieren, dass, sofern nicht ein Agent die tatsächlichen physischen Sensoren manipuliert (z.B. bei einem physischen Angriff), die von den Agenten aufgezeichneten Beobachtungen vertrauenswürdig und validiert sind.
Wenngleich die Möglichkeit besteht, dass ein individueller Beobachtungs - oder Beurteilungsbeitrag fehlerhaft oder kompromittiert ist, können konsensbasierte Bestimmungen, die mehrere Beobachtungs- und Beurteilungseingaben nutzen, ermöglichen, dass das Problem eines bösartigen Agenten abgeschwächt wird, indem Entscheidungen über einen Unfall basierend auf einer Mehrheit von Beobachtungsberichten und/oder Beurteilungen getroffen werden, die miteinander übereinstimmen. Das System geht davon aus, dass eine Mehrheit authentifizierter Agenten, die Beobachtungsberichte über einen Unfall melden, vertrauenswürdig und fehlerfrei ist. 16 ist ein vereinfachtes Flussdiagramm 1600, das einen beispielhaften Fluss in einem verteilten Verkehrssicherheitskonsens veranschaulicht, um dieses Prinzip zu veranschaulichen. In diesem Beispiel können ein oder mehrere Straßenagenten (z.B. eine Straßenrandsensorvorrichtung, computerausgestattete Fahrzeuge (z.B. einschließlich autonomer und nicht autonomer Fahrzeuge), eine Drohne usw.) ein Fahrzeug-Ad-hoc-Netzwerk (VANET) durch eine Anfrage initiieren (bei 1605). Dementsprechend kann ein Satz von Straßenagenten in Bereichen der Anforderung dem VANET beitreten (bei 1610) und Agentenidentifikationsinformationen teilen (bei 1615), wie etwa eine Kennung oder einen Namen, Sensorfähigkeiten, Hersteller- und/oder Modellinformationen, Agententypkennung, Standortinformationen, neben anderen beispielhaften Informationen.
In einigen Fällen können die Straßenagenten in Reaktion auf ein Sicherheitsereignis jeweilige Beobachtungsdaten teilen, rundsenden oder anderweitig erzeugen und senden (bei 1620), um Schlussfolgerungen zu beschreiben, die durch den jeweiligen Straßenagenten gezogen werden (aus Sensordaten an dem Agenten) und die bestimmte Sicherheitsattribute der Bewegung und/oder des Verhaltens eines oder mehrerer Fahrzeuge während oder bis zu dem Ereignis betreffen. Wie vorstehend angemerkt, kann dies in einigen Fällen Speichern und Teilen der Beobachtung durch eine verteilte verknüpfte Listendatenstruktur, wie etwa eine Blockchain-Datenstruktur, beinhalten. Ein Konsensalgorithmus (z.B. ein PBFT- (Practical Byzantine Fault Tolerance) Algorithmus) kann auf den Satz von Beobachtungen angewendet werden (bei 1625), die durch den Satz von Straßenagenten erzeugt werden, die in dem Fall zugegen sind oder an diesem beteiligt sind, um eine Konsensbeurteilung (bei 1630) bezüglich der Attribute und der möglichen Ursache des Ereignisses zu erreichen. Somit können Anreize für ein Beobachtersystem (Agent) oder einen bösartigen Benutzer existieren, der (zu Recht oder nicht) das System steuert, um im Kontext eines bestimmten Sicherheitsereignisses falsche oder übertriebene Beobachtungen zu erzeugen, die das Fahrzeug oder die Entität, das/die mit dem Agenten assoziiert ist, in einem vorteilhaften Licht darstellen. Dementsprechend können Situationen auftreten, bei denen eine unehrliche oder ungenaue Beobachtung zur Berücksichtigung unter rechtmäßigen Beobachtungen in einer Konsensbestimmung 1625 übermittelt wird (z.B. bei 1645). In Fällen, in denen jedoch mehrere Beobachtungen bereitgestellt werden (in einigen Fällen durch Parteien mit konkurrierenden Interessen), kann angenommen werden, dass eine unwahre oder fehlerhafte (z.B. erzeugt durch eine Fehlfunktion der Logik, die zum Ableiten der Beobachtung genutzt wird) gering gewichtet oder gänzlich vernachlässigt werden kann, basierend auf der Natur des angewendeten Konsensalgorithmus und den konkurrierenden Beobachtungen, die als Eingaben in den Algorithmus bereitgestellt werden (die wahrscheinlich einander zumindest teilweise bestätigen würden, falls sie durch vertrauenswürdige Systeme erzeugt werden, die dasselbe Ereignis bezeugen).
In einigen Implementierungen, wie etwa in dem Beispiel von 16 veranschaulicht, können Agentensysteme einen Vorbeurteilungskonsens ableiten oder sogar die Rolle des Sicherheitsbeurteilungssystems ersetzen, indem sie auf eine Peer-to-Peer-Weise eine einzige kombinierte Konsensbeobachtung für ein Ereignis ermitteln. Beispielsweise kann eine Sammlung von Straßenagentensystemen mit Logik konfiguriert sein, um einen Konsensalgorithmus basierend auf den individuellen Beobachtungen der Straßenagenten durchzuführen, die Details melden, die von Straßenagentensensoren am Schauplatz eines Ereignisses beobachtet werden. Während sie in einem VNET miteinander verbunden sind, können dementsprechend einer oder mehrere der Agenten mit dem Sammeln der individuellen Beobachtungen, die durch die Agenten erzeugt werden, und Durchführen eines Konsensalgorithmus (bei 1625) beauftragt werden, um eine Konsensbeobachtung (bei 1630) für die Gruppe von Agenten abzuleiten. Die Agenten können dann den Konsensalgorithmus signieren 1635 (obwohl bösartige Agenten das Signieren des Konsensalgorithmus unterlassen können, falls die bösartige oder fehlerhafte Beobachtung, die von dem bösartigen Agenten ausgegeben wird (z.B. bei 1645), herabgesetzt wird, was als Nachweis der Abweichung der Beobachtung 1645 dient) und die signierten Konsensbeobachtungsdaten an ein oder mehrere externe Systeme rundsenden 1640 (z.B. ist zur Validierung, Verifizierung das Speichern der signierten Konsensbeobachtungsdaten ein entsprechender Beobachtungsblock in einer Verkehrssicherheits-Blockchain-Datenstruktur).
In einigen Implementierungen können Konsensrollen derart konsolidiert werden, dass Validierung und Beurteilung während derselben Transaktion durch dasselbe System durchgeführt werden. In anderen Fällen, wie etwa in anderen vorliegend besprochenen Beispielen, können Validierung und Beurteilung separat ausgeführt werden. Beispielsweise kann in Abhängigkeit von der Geschwindigkeit, mit der mindestens eine anfängliche Beurteilung erreicht werden sollte, sowie der gewünschten Datenmenge, die auf einer Verkehrssicherheits-Blockchain-Struktur pro Unfall gespeichert werden soll, die Mehrheitsentscheidung entweder durch Validierer vor dem Speichern von Informationen über die Verkehrssicherheits-Blockchain-Struktur oder später durch die Sicherheitsbeurteilungen getroffen werden, falls es unter anderen Beispielen und Richtlinien zweckmäßig ist, die gesamte Liste von Beobachtungen bezüglich eines jeweiligen Unfalls auf der Verkehrssicherheits-Blockchain-Struktur zu speichern. Tatsächlich können Straßenagenten in einigen Implementierungen mit der kombinierten Logik zum Erzeugen von Beobachtungen, Validieren einer oder mehrerer der Beobachtungen, Zugreifen auf die Beobachtungsblöcke in Bezug auf das Ereignis und ermitteln einer Beurteilung basierend auf den Beobachtungen versehen werden. In solchen Fällen kann jeder Straßenagent als eine von mehreren Sicherheitsbeurteilungen dienen und seine Beurteilungen einem anderen vertrauenswürdigen System bereitstellen, um einen Konsensalgorithmus auf die einzelnen Beurteilungen anzuwenden. In solchen Beispielen können Agenten, die an einem Unfall beteiligt sind, bezüglich des Schauplatzes für einem einzigen Unfallbericht übereinstimmen (der die Konsensbeurteilung der Agenten beinhaltet), um zu minimieren, was auf der Verkehrssicherheits-Blockchain-Struktur gespeichert wird, und die Geschwindigkeit zu erhöhen, mit der eine anfängliche Beurteilung für ein Ereignis bestimmt wird, neben anderen beispielhaften Überlegungen und Merkmalen.
Auch wenn sich ein großer Teil der vorstehenden Erörterung auf fahrzeuginterne und straßenseitige Systeme konzentriert hat, die Straßensicherheitsereignisse überwachen und Fahrzeugsicherheitsstandards auf Ereignisse anwenden, die zumindest teilweise autonome Straßenfahrzeuge beinhalten, versteht es sich, dass die vorliegend erörterten Prinzipien gleichermaßen in anderen Umgebungen gelten können, in denen Maschinen, die dazu ausgelegt sind, sich autonom zu bewegen, an sicherheitsrelevanten Ereignissen beteiligt sein können. Beispielsweise können ähnliche Lösungen und Systeme basierend auf den obigen Prinzipien unter anderem für Maschinen wie Luftfahrzeuge, Wasserfahrzeuge, unbemannte Drohnen, Industrieroboter, Personalroboter abgeleitet werden. Beispielsweise sind 17A-17B vereinfachte Flussdiagramme 1700a-b, die beispielhafte Techniken veranschaulichen, die beim Ermitteln von Attributen sicherheitsbezogener Ereignisse genutzt werden, die Maschinen involvieren, die dafür konfiguriert sind, sich physisch autonom zu bewegen (z.B. gesteuert durch Rechensysteme, die maschinelles Lernen und künstliche Intelligenz nutzen).
Beispielsweise kann, wie in 17A gezeigt, auf Sensordaten bei einer Vorrichtung zugegriffen werden 1705, wobei die Vorrichtung einen Satz von Sensoren des gleichen oder unterschiedlicher Typen beinhaltet. Die Rohsensordaten können verarbeitet werden, indem Rechenlogik eingesetzt wird, die in der Vorrichtung implementiert ist, darunter zum Beispiel Maschinenlernlogik, um Beobachtungen eines bestimmten Ereignisses aus den Rohsensordaten zu ermitteln 1710. Solche Beobachtungen können bestimmte Akteure identifizieren, die an dem Ereignis beteiligt sind, und Bewegung der Akteure im Kontext bestimmter standardisierter Sicherheitsprinzipien oder -regeln (z.B. RSS-Standards) beschreiben. Die Beobachtung kann in Beobachtungsdaten beschrieben werden, die in der Vorrichtung zur Aufnahme in eine verteilte verknüpfte Datenstruktur (z.B. eine Blockchain-basierte Datenstruktur) erzeugt 1715 werden. In einigen Fällen können die Beobachtungsdaten mit anderen Daten (z.B. anderen Beobachtungen von anderen Agenten oder anderen nicht in Beziehung stehenden Transaktionen) in einem einzigen Block enthalten sein, der zu der verknüpften Datenstruktur hinzugefügt werden soll. In anderen Fällen kann, neben anderen Ausführungsbeispielen, ein neuer Block dafür dediziert sein, die Beobachtungsdaten zu enthalten, so dass die Beobachtung als ein entsprechender Beobachtungsblock in der verknüpften Datenstruktur hinzugefügt würde. Die Beobachtungsdaten können dann an ein anderes System gesendet werden, um zu bewirken, dass die Beobachtungsdaten zu der verteilten verknüpften Datenstruktur hinzugefügt werden (z.B. nachdem sie in der Vorrichtung oder durch das andere System validiert wurden).
Wie in 17B gezeigt, können Beobachtungen eines Ereignisses genutzt werden, um aus mehreren Beobachtungen eine Konsensbeobachtung oder Bestimmung der Attribute, Ursachen und Akteure innerhalb eines Ereignisses zu ermitteln, an dem eine Maschine beteiligt ist, die zu autonomer Bewegung in der Lage ist (z.B. ein Roboter, ein autonomes Fahrzeug usw.). Beispielsweise kann ein Sicherheitsbeurteilungssystem das Ereignis, ein Zeitfenster (z.B. Zeitgrenzen), das dem Ereignis entspricht (bei 1725), und geografische Grenzen für das Ereignis (bei 1730), das die Handlungen des Ereignisses und die wahrscheinlich naheliegenden Handlungen, die bis zu dem Ereignis führen, abdeckt, identifizieren. Unter Verwendung der Zeit und geografischen Grenzen als Kriterien kann das Sicherheitsbeurteilungssystem eine verteilte verknüpfte Datenstruktur (z.B. eine Blockchain-basierte Datenstruktur) parsen, um einen Satz von Blöcken in der Datenstruktur zu identifizieren, die Beobachtungen beschreiben, die durch Agenten bestimmt werden, die an dem Ereignis beteiligt oder zugegen waren. Ein Konsensalgorithmus kann unter Verwendung der Beobachtungen als Eingaben eingesetzt werden, um (bei 1740) eine Beurteilung aus den Beobachtungen zu ermitteln. Beurteilungsdaten können erzeugt werden, um die Beurteilung zu beschreiben, und es kann veranlasst 1745 werden, dass die Beurteilungsdaten zu einem Block der verteilten verknüpften Datenstruktur hinzugefügt werden.
18-19 sind Blockdiagramme beispielhafter Computerarchitekturen, die gemäß hier offenbarten Ausführungsformen verwendet werden können. Andere aus dem Stand der Technik bekannte Computerarchitekturkonstruktionen für Prozessoren und Computersysteme können ebenfalls verwendet werden. Allgemein können geeignete Computerarchitekturen für vorliegend offenbarte Ausführungsformen in 18-19 veranschaulichte Konfigurationen beinhalten, ohne jedoch hierauf eingeschränkt zu sein.
18 ist eine beispielhafte Darstellung eines Prozessors gemäß einer Ausführungsform. Der Prozessor 1800 ist ein Beispiel für einen Typ von Hardwarevorrichtung, die in Verbindung mit den vorstehenden Implementierungen verwendet werden kann. Der Prozessor 1800 kann ein beliebiger Typ von Prozessor sein, wie etwa ein Mikroprozessor, ein eingebetteter Prozessor, ein Digitalsignalprozessor (DSP), ein Netzwerkprozessor, ein Mehrfachkernprozessor, ein Einzelkernprozessor oder eine andere Einrichtung zum Ausführen von Code. Auch wenn nur ein Prozessor 1800 in 18 veranschaulicht ist, kann ein Verarbeitungselement alternativ mehr als einen des in 18 veranschaulichten Prozessors 1800 beinhalten. Der Prozessor 1800 kann ein Single-Thread-Kern sein oder für mindestens eine Ausführungsform kann der Prozessor 1800 in dem Sinne multithreaded sein, dass er mehr als einen Hardware-Thread-Kontext (oder „logischen Prozessor“) pro Kern beinhalten kann.
18 veranschaulicht zudem einen Speicher 1802, der mit dem Prozessor 1800 gekoppelt ist, gemäß einer Ausführungsform. Der Speicher 1802 kann ein beliebiger aus einer breiten Vielfalt von Speichern sein (einschließlich verschiedener Schichten einer Speicherhierarchie), die einem Fachmann bekannt sind oder anderweitig zur Verfügung stehen. Solche Speicherelemente können unter anderem Direktzugriffsspeicher (RAM), Nurlesespeicher (ROM), Logikblöcke eines feldprogrammierbaren Gate-Arrays (FPGA), einen löschbaren programmierbaren Nurlesespeicher (EPROM) und einen elektrisch löschbaren programmierbaren ROM (EEPROM) beinhalten.
Der Prozessor 1800 kann eine beliebige Art von Anweisungen ausführen, die mit Algorithmen, Prozessen oder Operationen zusammenhängen, die vorliegend ausführlich beschrieben sind. Allgemein kann der Prozessor 1800 ein Element oder einen Artikel (z.B. Daten) von einem Zustand oder Gegenstand in einen anderen Zustand oder Gegenstand umwandeln.
Code 1804, bei dem es sich um eine oder mehrere Anweisungen handeln kann, die durch den Prozessor 1800 auszuführen sind, kann in dem Speicher 1802 gespeichert sein oder kann in Software, Hardware, Firmware oder einer beliebigen geeigneten Kombination aus diesen oder in einer beliebigen anderen internen oder externen Komponente, Vorrichtung, einem Element oder Objekt gespeichert sein, je nach Bedarf und jeweiligen Anforderungen. Bei einem Beispiel kann der Prozessor 1800 einer Programmsequenz von Anweisungen, die durch den Code 1804 angegeben werden, folgen. Jede Anweisung tritt in eine Frontend-Logik 1806 ein und wird durch einen oder mehrere Decodierer 1808 verarbeitet. Der Decodierer kann als seine Ausgabe eine Mikrooperation erzeugen, wie etwa eine Mikrooperation mit fester Breite in einem vordefinierten Format, oder kann andere Anweisungen, Mikroanweisungen oder Steuersignale erzeugen, die ursprüngliche Codeanweisung widerspiegeln. Die Frontend-Logik 1806 beinhaltet auch eine Registerumbenennungslogik 1810 und eine Planungslogik 1812, die allgemein Ressourcen zuweisen und die Operation, die der Anweisung entspricht, zur Ausführung in eine Warteschlange einreihen.
Der Prozessor 1800 kann auch Ausführungslogik 1814 mit einem Satz von Ausführungseinheiten 1816a, 1816b, 1816n usw. beinhalten. Manche Ausführungsformen können eine Anzahl von Ausführungseinheiten beinhalten, die spezifischen Funktionen oder Sätzen von Funktionen dediziert sind. Andere Ausführungsformen können nur eine Ausführungseinheit oder eine Ausführungseinheit, die eine spezielle Funktion durchführen kann, beinhalten. Die Ausführungslogik 1814 führt die durch Codeanweisungen spezifizierten Operationen durch.
Nach Abschluss der Ausführung der durch die Codeanweisungen spezifizierten Operationen kann die Backend-Logik 1818 die Anweisungen des Codes 1804 zurückziehen. In einer Ausführungsform ermöglicht der Prozessor 1800 eine reihenfolgeveränderte Ausführung, erfordert aber ein reihenfolgetreues Zurückziehen von Anweisungen. Rückzugslogik 1820 kann eine Vielfalt bekannter Formen annehmen (z.B. Umordnungspuffer oder dergleichen). Auf diese Art und Weise wird der Prozessor 1800 während der Ausführung des Codes 1804 zumindest hinsichtlich der durch den Decodierer erzeugten Ausgabe, der Hardwareregister und Tabellen, die durch die Registerumbenennungslogik 1810 genutzt werden, und beliebiger durch die Ausführungslogik 1814 modifizierter Register (nicht dargestellt) transformiert.
Auch wenn dies in 18 nicht gezeigt ist, kann ein Verarbeitungselement weitere Elemente auf einem Chip mit dem Prozessor 1800 beinhalten. Ein Verarbeitungselement kann zum Beispiel eine Speichersteuerlogik zusammen mit dem Prozessor 1800 beinhalten. Das Verarbeitungselement kann eine E/A-Steuerlogik beinhalten und/oder kann eine E/A-Steuerlogik beinhalten, die mit der Speichersteuerlogik integriert ist. Das Verarbeitungselement kann zudem einen oder mehrere Caches beinhalten. In einigen Ausführungsformen kann nichtflüchtiger Speicher (wie etwa Flashspeicher oder Fuses) ebenfalls auf dem Chip mit dem Prozessor 1800 enthalten sein.
19 veranschaulicht ein Rechensystem 1900, das in einer Punkt-zu-Punkt-(PtP-) Konfiguration angeordnet ist, gemäß einer Ausführungsform. Insbesondere zeigt 19 ein System, bei dem Prozessoren, Speicher und Eingabe/Ausgabe-Vorrichtungen durch eine Anzahl von Punkt-zu-Punkt-Schnittstellen miteinander verbunden sind. Allgemein können eines oder mehrere der vorliegend beschriebenen Rechensysteme auf die gleiche oder eine ähnliche Weise wie das Rechensystem 1800 konfiguriert sein.
Die Prozessoren 1970 und 1980 können auch jeweils eine integrierte Speichersteuerungslogik (MC) 1972 und 1982 beinhalten, um mit den Speicherelementen 1932 und 1934 zu kommunizieren. Bei alternativen Ausführungsformen kann die Speichersteuerlogik 1972 und 1982 eine diskrete Logik sein, die von den Prozessoren 1970 und 1980 getrennt ist. Die Speicherelemente 1932 und/oder 1934 können verschiedene Daten speichern, die von den Prozessoren 1970 und 1980 beim Erreichen von hier dargelegten Operationen und Funktionalitäten verwendet werden sollen.
Die Prozessoren 1970 und 1980 können eine beliebige Art von Prozessor sein, wie etwa jene, die in Verbindung mit anderen Figuren vorliegend erörtert werden. Die Prozessoren 1970 und 1980 können Daten über eine Punkt-zu-Punkt(PtP)-Schnittstelle 1950 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 1978 bzw. 1988 austauschen. Die Prozessoren 1970 und 1980 können jeweils Daten über individuelle Punkt-zu-Punkt-Schnittstellen 1952 und 1954 mit einem Chipsatz 1990 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 1976, 1986, 1994 und 1998 austauschen. Der Chipsatz 1990 kann auch Daten mit einem Coprozessor 1938, wie etwa einer Grafikschaltung mit hoher Leistungsfähigkeit, einem Maschinenlernbeschleuniger oder einem anderen Coprozessor 1938, über eine Schnittstelle 1939 austauschen, die eine PtP-Schnittstellenschaltung sein könnte. In alternativen Ausführungsformen könnten beliebige oder alle der in 19 veranschaulichten PtP-Verbindungen als ein Multi-Drop-Bus anstelle einer PtP-Verbindung implementiert sein.
Der Chipsatz 1990 kann sich über eine Schnittstellenschaltung 1996 mit einem Bus 1920 in Kommunikation befinden. Der Bus 1920 kann eine oder mehrere Vorrichtungen aufweisen, die über ihn kommunizieren, wie etwa eine Busbrücke 1918 und E/A-Vorrichtungen 1916. Die Busbrücke 1918 kann sich über einen Bus 1910 in Kommunikation mit anderen Vorrichtungen befinden, wie etwa einer Benutzerschnittstelle 1912 (wie etwa einer Tastatur, einer Maus, einem Touchscreen oder anderen Eingabevorrichtungen), Kommunikationsvorrichtungen 1926 (wie etwa Modems, Netzwerkschnittstellenvorrichtungen oder anderen Arten von Kommunikationsvorrichtungen, die durch ein Computernetzwerk 1960 kommunizieren können), Audio-E/A-Vorrichtungen 1914 und/oder einer Datenspeicherungsvorrichtung 1928. Die Datenspeicherungsvorrichtung 1928 kann Code 1930 speichern, der durch die Prozessoren 1970 und/oder 1980 ausgeführt werden kann. In alternativen Ausführungsformen könnten beliebige Teile der Busarchitekturen mit einer oder mehreren PtP-Verbindungen implementiert werden.
Das in 19 dargestellte Computersystem ist eine schematische Veranschaulichung einer Ausführungsform eines Rechensystems, das genutzt werden kann, um verschiedene vorliegend behandelte Ausführungsformen zu implementieren. Es versteht sich, dass verschiedene Komponenten des in 19 dargestellten Systems in einer Ein-Chip-System-(SoC-) Architektur oder in einer beliebigen anderen geeigneten Konfiguration kombiniert werden können, die in der Lage ist, die Funktionalität und Merkmale von vorliegend bereitgestellten Beispielen und Implementierungen zu erreichen.
Obwohl manche der hier beschriebenen Systeme und Lösungen als mehrere Elemente enthaltend oder mit diesen assoziiert beschrieben sind, werden möglicherweise nicht alle Elemente, die explizit veranschaulicht oder beschrieben sind, in jeder alternativen Implementierung der vorliegenden Offenbarung genutzt. Zusätzlich können sich eines oder mehrere der Elemente, die hier beschrieben sind, außerhalb eines Systems befinden, während in anderen Fällen gewisse Elemente innerhalb oder als Teil eines oder mehrerer der anderen beschriebenen Elemente sowie anderer Elemente, die bei der veranschaulichten Implementierung nicht beschrieben sind, enthalten sein können. Ferner können gewisse Elemente mit anderen Komponenten kombiniert werden sowie für alternative oder zusätzliche Zwecke zusätzlich zu jenen hier beschriebenen Zwecken verwendet werden.
Ferner versteht es sich, dass die oben präsentierten Beispiele nicht beschränkende Beispiele sind, die lediglich zum Zweck der Veranschaulichung gewisser Prinzipien und Merkmale bereitgestellt sind und nicht notwendigerweise die möglichen Ausführungsformen der hier beschriebenen Konzepte beschränken oder eingrenzen. Beispielsweise kann eine Vielfalt verschiedener Ausführungsformen unter Verwendung verschiedener Kombinationen der vorliegend beschriebenen Merkmale und Komponenten realisiert werden, einschließlich Kombinationen, die durch die verschiedenen Implementierungen von vorliegend beschriebenen Komponenten realisiert werden. Andere Implementierungen, Merkmale und Einzelheiten verstehen sich aus dem Inhalt dieser Spezifikation.
Obwohl diese Offenbarung bezüglich gewisser Implementierungen und allgemein assoziierter Verfahren beschrieben wurde, werden einem Fachmann Abänderungen und Permutationen dieser Implementierungen und Verfahren ersichtlich sein. Zum Beispiel können die vorliegend beschriebenen Handlungen in einer anderen Reihenfolge als der beschriebenen durchgeführt werden und dennoch die gewünschten Ergebnisse erzielen. Als ein Beispiel erfordern die in den begleitenden Figuren dargestellten Prozesse nicht notwendigerweise die gezeigte spezielle Reihenfolge oder sequenzielle Reihenfolge, um die gewünschten Ergebnisse zu erzielen. Bei gewissen Implementierungen können Multitasking und Parallelverarbeitung vorteilhaft sein. Zudem können andere Benutzeroberflächenlayouts und -funktionalität unterstützt werden. Andere Variationen liegen innerhalb des Schutzumfangs der folgenden Ansprüche.
Auch wenn diese Spezifikation viele spezifische Implementierungsdetails enthält, sollten diese nicht als Beschränkungen des Schutzumfangs der Erfindungen oder des beanspruchten Gegenstandes, sondern als Beschreibungen von Merkmalen aufgefasst werden, die für bestimmte Ausführungsformen bestimmter Erfindungen spezifisch sind. Bestimmte Merkmale, die in dieser Beschreibung im Zusammenhang mit separaten Ausführungsformen beschrieben sind, können auch in Kombination in einer einzigen Ausführungsform realisiert werden. Im Gegensatz dazu können verschiedene Merkmale, die in dem Zusammenhang einer einzigen Ausführungsform beschrieben sind, auch in mehreren Ausführungsformen separat oder in einer beliebigen geeigneten Teilkombination implementiert werden. Obwohl Merkmale oben als in gewissen Kombinationen wirkend beschrieben und selbst anfänglich als solche beansprucht sein können, können zudem ein oder mehrere Merkmale aus einer beanspruchten Kombination in manchen Fällen aus der Kombination herausgelöst werden, und die beanspruchte Kombination kann auf eine Teilkombination oder Variation einer Teilkombination verweisen.
Auch wenn Operationen in den Zeichnungen in einer speziellen Reihenfolge dargestellt sind, sollte dies ebenfalls nicht so verstanden werden, dass dies erfordert, dass solche Operationen in der gezeigten speziellen Reihenfolge oder in sequentieller Reihenfolge durchgeführt werden oder dass alle dargestellten Operationen durchgeführt werden, um gewünschte Ergebnisse zu erzielen. Unter gewissen Umständen können Multitasking und Parallelverarbeitung vorteilhaft sein. Zudem sollte die Separation verschiedener Systemkomponenten bei den oben beschriebenen Ausführungsformen nicht so verstanden werden, dass eine solche Separation bei allen Ausführungsformen erforderlich ist, und es versteht sich, dass die beschriebenen Programmkomponenten und -systeme allgemein zusammen in einem einzigen Softwareprodukt integriert werden können oder in mehrere Softwareprodukte gepackt werden können.
Die folgenden Beispiele betreffen Ausführungsformen gemäß dieser Beschreibung. Beispiel 1 ist ein maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen durch einen Prozessor ausführbar sind, um den Prozessor zu Folgendem zu veranlassen: Zugreifen auf Sensordaten, die durch Sensoren einer Vorrichtung in einer Umgebung erzeugt werden; aus den Sensordaten erfolgendes Ermitteln einer Beobachtung eines Ereignisses, wobei die Beobachtung eine Bewegung einer oder mehrerer Maschinen innerhalb der Umgebung in Verbindung mit dem Ereignis identifiziert; Erzeugen von Beobachtungsdaten zur Aufnahme in eine verteilte verknüpfte Datenstruktur, wobei die Beobachtungsdaten die Beobachtung identifizieren; und Senden der Beobachtungsdaten an ein anderes System zur Speicherung in der verteilten verknüpften Datenstruktur.
Beispiel 2 beinhaltet den Gegenstand nach Beispiel 1, wobei die Erzeugung der Beobachtungsdaten Durchführen einer Inferenz unter Verwendung eines Maschinenlernmodell basierend auf zumindest einem Teil der Sensordaten beinhaltet.
Beispiel 3 beinhaltet den Gegenstand eines der Beispiele 1-2, wobei die Beobachtung auf einem standardisierten Sicherheitsmodell basiert und das standardisierte Sicherheitsmodell einen Satz von Berechnungen definiert, um einen Satz sicherer Betriebsstandards zu modellieren, und die Beobachtung zumindest teilweise unter Verwendung einer oder mehrerer des Satzes von Berechnungen erzeugt wird.
Beispiel 4 beinhaltet den Gegenstand nach Beispiel 3, wobei das standardisierte Sicherheitsmodell ein RRS- (Responsibility Sensitive Safety, verantwortungssensitive Sicherheit) basiertes Modell beinhaltet.
Beispiel 5 beinhaltet den Gegenstand nach einem der Beispiele 1-4, wobei zumindest eine bestimmte der einen oder der mehreren Maschinen dafür konfiguriert ist, sich autonom zu bewegen.
Beispiel 6 beinhaltet den Gegenstand nach Beispiel 5, wobei die jeweilige Maschine die Vorrichtung beinhaltet.
Beispiel 7 beinhaltet den Gegenstand nach Beispiel 6, wobei die jeweilige Maschine ein autonomes Fahrzeug beinhaltet.
Beispiel 8 beinhaltet den Gegenstand nach einem der Beispiele 6 und 7, wobei die Beobachtung zumindest teilweise unter Verwendung von Logik bestimmt wird, die durch die Maschine genutzt wird, um Entscheidungen in Verbindung mit einer Durchführung einer autonomen Bewegung zu treffen.
Beispiel 9 beinhaltet den Gegenstand nach einem der Beispiele 1 bis 8, wobei die verteilte verknüpfte Datenstruktur eine Blockchain-Datenstruktur beinhaltet und die Blockchain-Datenstruktur Beobachtungsdaten zum Beschreiben einer Vielzahl von Beobachtungen für das Ereignis beinhaltet.
Beispiel 10 beinhaltet den Gegenstand nach Beispiel 9, wobei die Anweisungen ferner ausführbar sind, um zu bewirken, dass der Prozessor einen neuen Block zur Aufnahme in die Blockchain-Datenstruktur erzeugt, wobei der neue Block die Beobachtungsdaten beinhaltet und jede der Vielzahl von Beobachtungen in einem jeweiligen einer Vielzahl von Blöcken enthalten ist, die in die Blockchain aufgenommen werden sollen.
Beispiel 11 beinhaltet den Gegenstand nach einem der Beispiele 1 bis 10, wobei die Beobachtungsdaten Zeitinformationen, die einem Auftreten des Ereignisses entsprechen, und Standortinformationen, die geografische Grenzen der Umgebung identifizieren, beinhalten.
Beispiel 12 beinhaltet den Gegenstand nach einem der Beispiele 1 bis 11, wobei die Sensordaten durch eine Vielzahl unterschiedlicher Typen von Sensoren in der Vorrichtung erzeugt werden.
Beispiel 13 beinhaltet den Gegenstand nach einem der Beispiele 1-12, wobei die Beobachtung jede einer Vielzahl von Maschinen identifiziert, die an dem Ereignis beteiligt sind.
Beispiel 14 ist ein Verfahren, das Folgendes beinhaltet: Zugreifen auf Sensordaten, die durch Sensoren einer Vorrichtung in einer Umgebung erzeugt werden; aus den Sensordaten erfolgendes Ermitteln einer Beobachtung eines Ereignisses, wobei die Beobachtung eine Bewegung einer oder mehrerer Maschinen innerhalb der Umgebung in Verbindung mit dem Ereignis identifiziert; Erzeugen von Beobachtungsdaten zur Aufnahme in eine verteilte verknüpfte Datenstruktur, wobei die Beobachtungsdaten die Beobachtung identifizieren; und Senden der Beobachtungsdaten an ein anderes System zur Speicherung in der verteilten verknüpften Datenstruktur.
Beispiel 15 beinhaltet den Gegenstand nach Beispiel 14, wobei die Erzeugung der Beobachtungsdaten Durchführen einer Inferenz unter Verwendung eines Maschinenlernmodell basierend auf zumindest einem Teil der Sensordaten beinhaltet.
Beispiel 16 beinhaltet den Gegenstand eines der Beispiele 14-15, wobei die Beobachtung auf einem standardisierten Sicherheitsmodell basiert und das standardisierte Sicherheitsmodell einen Satz von Berechnungen definiert, um einen Satz sicherer Betriebsstandards zu modellieren, und die Beobachtung zumindest teilweise unter Verwendung einer oder mehrerer des Satzes von Berechnungen erzeugt wird.
Beispiel 17 beinhaltet den Gegenstand nach Beispiel 16, wobei das standardisierte Sicherheitsmodell ein RRS- (Responsibility-Sensitive-Safety) basiertes Modell beinhaltet.
Beispiel 18 beinhaltet den Gegenstand nach einem der Beispiele 14-17, wobei zumindest eine bestimmte der einen oder der mehreren Maschinen dafür konfiguriert ist, sich autonom zu bewegen.
Beispiel 19 beinhaltet den Gegenstand nach Beispiel 18, wobei die jeweilige Maschine die Vorrichtung beinhaltet.
Beispiel 20 beinhaltet den Gegenstand nach Beispiel 19, wobei die jeweilige Maschine ein autonomes Fahrzeug beinhaltet.
Beispiel 21 beinhaltet den Gegenstand nach einem der Beispiele 18 und 19, wobei die Beobachtung zumindest teilweise unter Verwendung von Logik bestimmt wird, die durch die Maschine genutzt wird, um Entscheidungen in Verbindung mit einer Durchführung einer autonomen Bewegung zu treffen.
Beispiel 22 beinhaltet den Gegenstand nach einem der Beispiele 14 bis 21, wobei die verteilte verknüpfte Datenstruktur eine Blockchain-Datenstruktur beinhaltet und die Blockchain-Datenstruktur Beobachtungsdaten zum Beschreiben einer Vielzahl von Beobachtungen für das Ereignis beinhaltet.
Beispiel 23 beinhaltet den Gegenstand nach Beispiel 22 und ferner Erzeugen eines neuen Blocks zur Aufnahme in die Blockchain-Datenstruktur, wobei der neue Block die Beobachtungsdaten beinhaltet und jede der Vielzahl von Beobachtungen in einem jeweiligen einer Vielzahl von Blöcken enthalten ist, die in die Blockchain aufgenommen werden sollen.
Beispiel 24 beinhaltet den Gegenstand nach einem der Beispiele 14 bis 23, wobei die Beobachtungsdaten Zeitinformationen, die einem Auftreten des Ereignisses entsprechen, und Standortinformationen, die geografische Grenzen der Umgebung identifizieren, beinhalten.
Beispiel 25 beinhaltet den Gegenstand eines der Beispiele 14 bis 24, wobei die Sensordaten durch eine Vielzahl unterschiedlicher Typen von Sensoren in der Vorrichtung erzeugt werden.
Beispiel 26 beinhaltet den Gegenstand nach einem der Beispiele 14-25, wobei die Beobachtung jede einer Vielzahl von Maschinen identifiziert, die an dem Ereignis beteiligt sind.
Beispiel 27 ist ein System, das ein Mittel zum Durchführen des Verfahrens aus einem der Beispiele 14-26 beinhaltet.
Beispiel 28 ist ein maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen durch einen Prozessor ausführbar sind, um den Prozessor zu Folgendem zu veranlassen: Identifizieren von Zeitgrenzen eines Ereignisses, wobei das Ereignis einer unsicheren Aktion durch eine autonome Maschine innerhalb einer Umgebung entspricht; Identifizieren geografischer Grenzen des Ereignisses, die mit der Umgebung zusammenhängen; Ermitteln, dass ein Teilsatz von Blöcken in einer verteilten verknüpften Datenstruktur eine Vielzahl von Beobachtungen des Ereignisses beinhaltet, basierend auf den Zeitgrenzen und den geografischen Grenzen, wobei der Teilsatz von Blöcken Beobachtungsdaten beinhaltet, die die Vielzahl von Beobachtungen beschreiben, und jede der Vielzahl von Beobachtungen durch eine jeweilige einer Vielzahl von Vorrichtungen aus Sensordaten abgeleitet wird, die in der entsprechenden Vorrichtung erzeugt werden; Ausführen eines Konsensalgorithmus, um eine Beurteilung aus der Vielzahl von Beobachtungen zu ermitteln; und Veranlassen, dass Beurteilungsdaten zu einem Block der verteilten verknüpften Datenstruktur hinzugefügt werden, um die Beurteilung zu beschreiben.
Beispiel 29 beinhaltet den Gegenstand nach Beispiel 28, wobei die Beurteilungsdaten Verweise auf jede der Vielzahl von Beobachtungen in dem Teilsatz von Blöcken beinhalten.
Beispiel 30 beinhaltet den Gegenstand nach einem der Beispiele 28 bis 29, wobei mindestens eine der Vielzahl von Beobachtungen durch Logik erzeugt wird, die sich auf der autonomen Maschine befindet.
Beispiel 31 beinhaltet den Gegenstand nach einem der Beispiele 28 bis 30, wobei die autonome Maschine ein autonomes Fahrzeug oder einen Roboter beinhaltet.
Beispiel 32 beinhaltet den Gegenstand nach einem der Beispiele 28-31, wobei die Anweisungen ferner ausführbar sind, um den Prozessor zu Folgendem zu veranlassen: Identifizieren eines Hinzufügens einer weiteren Beobachtung des Ereignisses zu einem bestimmten Block der verteilten verknüpften Datenstruktur nach Hinzufügen des Beurteilungsblocks zu der verteilten verknüpften Datenstruktur; Ermitteln einer revidierten Beurteilung für das Ereignis basierend auf der anderen Beobachtung und der Vielzahl von Beobachtungen; und Veranlassen, dass zusätzliche Beurteilungsdaten zu einem anderen Block in der verteilten verknüpften Datenstruktur hinzugefügt werden, um die revidierte Beurteilung zu beschreiben.
Beispiel 33 beinhaltet den Gegenstand nach einem der Beispiele 28 bis 32, wobei jede der Vielzahl von Beobachtungen in einem jeweiligen des Teilsatzes von Blöcken enthalten ist und die Beurteilungsdaten durch Hinzufügen eines neuen Blocks, der die Beurteilungsdaten enthalten soll, zu der verteilten verknüpften Datenstruktur hinzugefügt werden.
Beispiel 34 beinhaltet den Gegenstand nach einem der Beispiele 28 bis 33, wobei die Anweisungen ferner ausführbar sind, um den Prozessor zu Folgendem zu veranlassen: Identifizieren einer Änderung an einem Satz von Regeln, der zum Ermitteln der Beurteilung verwendet wird; Ermitteln einer aktualisierten Beurteilung aus der Vielzahl von Beobachtungen basierend auf der Änderung an dem Satz von Regeln; und Veranlassen, dass aktualisierte Beurteilungsdaten einem weiteren Block in der verteilten verknüpften Datenstruktur hinzugefügt werden, um die aktualisierte Beurteilung zu beschreiben.
Beispiel 35 ist ein Verfahren, das Folgendes beinhaltet: Identifizieren von Zeitgrenzen eines Ereignisses, wobei das Ereignis einer unsicheren Aktion durch eine autonome Maschine innerhalb einer Umgebung entspricht; Identifizieren von geografischen Grenzen des Ereignisses, die mit der Umgebung zusammenhängen; Ermitteln, dass ein Teilsatz von Blöcken in einer verteilten verknüpften Datenstruktur eine Vielzahl von Beobachtungen des Ereignisses beinhaltet, basierend auf den Zeitgrenzen und den geografischen Grenzen, wobei der Teilsatz von Blöcken Beobachtungsdaten beinhaltet, die die Vielzahl von Beobachtungen beschreiben, und jede der Vielzahl von Beobachtungen durch eine jeweilige einer Vielzahl von Vorrichtungen aus Sensordaten abgeleitet wird, die an der entsprechenden Vorrichtung erzeugt werden; Ausführen eines Konsensalgorithmus, um eine Beurteilung aus der Vielzahl von Beobachtungen zu ermitteln; und Veranlassen, dass Beurteilungsdaten zu einem Block der verteilten verknüpften Datenstruktur hinzugefügt werden, um die Beurteilung zu beschreiben.
Beispiel 36 beinhaltet den Gegenstand nach Beispiel 35, wobei die Beurteilungsdaten Verweise auf jede der Vielzahl von Beobachtungen in dem Teilsatz von Blöcken beinhalten.
Beispiel 37 beinhaltet den Gegenstand nach einem der Beispiele 35 bis 36, wobei mindestens eine der Vielzahl von Beobachtungen durch Logik erzeugt wird, die sich auf der autonomen Maschine befindet.
Beispiel 38 beinhaltet den Gegenstand nach einem der Beispiele 35 bis 37, wobei die autonome Maschine ein autonomes Fahrzeug oder einen Roboter beinhaltet.
Beispiel 39 beinhaltet den Gegenstand nach einem der Beispiele 35-38, ferner beinhaltend: Identifizieren einer Hinzufügung einer weiteren Beobachtung des Ereignisses zu einem jeweiligen Block der verteilten verknüpften Datenstruktur nach dem Hinzufügen des Beurteilungsblocks zu der verteilten verknüpften Datenstruktur; Ermitteln einer überarbeiteten Beurteilung für das Ereignis basierend auf der weiteren Beobachtung und der Vielzahl von Beobachtungen; und Veranlassen, dass zusätzliche Beurteilungsdaten zu einem anderen Block in der verteilten verknüpften Datenstruktur hinzugefügt werden, um die überarbeitete Beurteilung zu beschreiben.
Beispiel 40 beinhaltet den Gegenstand nach einem der Beispiele 35 bis 39, wobei jede der Vielzahl von Beobachtungen in einem jeweiligen des Teilsatzes von Blöcken enthalten ist und die Beurteilungsdaten durch Hinzufügen eines neuen Blocks, der die Beurteilungsdaten enthalten soll, zu der verteilten verknüpften Datenstruktur hinzugefügt werden.
Beispiel 41 beinhaltet den Gegenstand nach einem der Beispiele 35-40, ferner beinhaltend: Identifizieren einer Änderung an einem Satz von Regeln, der zum Ermitteln der Beurteilung verwendet wird; Ermitteln einer aktualisierten Beurteilung aus der Vielzahl von Beobachtungen basierend auf der Änderung an dem Satz von Regeln; und Veranlassen, dass aktualisierte Beurteilungsdaten zu einem anderen Block in der verteilten verknüpften Datenstruktur hinzugefügt werden, um die aktualisierte Beurteilung zu beschreiben.
Beispiel 42 ist ein System, das ein Mittel zum Durchführen des Verfahrens aus einem der Beispiele 35-41 beinhaltet.
Beispiel 43 ist ein System, das Folgendes beinhaltet: einen Datenprozessor; einen Speicher; einen Satz von Sensoren; und eine Sicherheitsbeobachtungs-Engine, die von dem Datenprozessor ausführbar ist, um: einen Teilsatz von Sensordaten zu identifizieren, die von dem Satz von Sensoren erzeugt werden und die einer Zeit und Geografie eines Sicherheitsereignisses entsprechen, wobei das Sicherheitsereignis einer autonomen Bewegung durch eine Maschine entspricht; aus dem Teilsatz von Sensordaten erfolgendes Ermitteln einer Beobachtung des Sicherheitsereignisses, wobei die Beobachtung die Maschine identifiziert und Attribute der autonomen Bewegung beschreibt, wobei die Attribute mit Einhaltung eines Sicherheitsstandards assoziiert sind; Beobachtungsdaten zum Beschreiben der Beobachtung zu erzeugen; und zu veranlassen, dass die Beobachtungsdaten in einem Block einer Sicherheits-Blockchain zur Verwendung beim Ermitteln einer Ursache des Ereignisses zumindest teilweise auf Grundlage der Beobachtung gespeichert werden.
Beispiel 44 beinhaltet den Gegenstand nach Beispiel 43, ferner beinhaltend eine Maschinenlern-Engine zum Verwenden eines oder mehrerer Maschinenlernmodelle zum Durchführen von Inferenzen basierend auf den Sensordaten, wobei die Beobachtung zumindest teilweise basierend auf den Inferenzen bestimmt werden soll.
Beispiel 45 beinhaltet den Gegenstand nach einem der Beispiele 43 bis 44, wobei das System ein Fahrzeug, einen Straßenrandsensor, einen Roboter oder eine Drohne beinhaltet.
Beispiel 46 beinhaltet den Gegenstand nach einem der Beispiele 43 bis 45, wobei das System die Maschine beinhaltet.
Beispiel 47 beinhaltet den Gegenstand nach einem der Beispiele 43 bis 46, ferner beinhaltend einen Validierungsknoten zum: Validieren des Blocks; und Hinzufügen des Blocks zu der Sicherheits-Blockchain basierend auf einer Validierung des Blocks.
Beispiel 48 beinhaltet den Gegenstand eines der Beispiele 43 bis 47, wobei die Beobachtung auf einem standardisierten Sicherheitsmodell basiert und das standardisierte Sicherheitsmodell einen Satz von Berechnungen definiert, um einen Satz sicherer Betriebsstandards zu modellieren, und die Beobachtung zumindest teilweise unter Verwendung einer oder mehrerer des Satzes von Berechnungen erzeugt wird.
Beispiel 49 beinhaltet den Gegenstand nach Beispiel 48, wobei das standardisierte Sicherheitsmodell ein RRS- (Responsibility Sensitive Safety, verantwortungssensitive Sicherheit) basiertes Modell beinhaltet.
Beispiel 50 beinhaltet den Gegenstand nach einem der Beispiele 43 bis 49, ferner beinhaltend die Maschine, wobei die Maschine die Sicherheitsbeobachtungs-Engine beinhaltet.
Beispiel 51 beinhaltet den Gegenstand nach Beispiel 50, wobei die Maschine ein autonomes Fahrzeug beinhaltet.
Beispiel 52 beinhaltet den Gegenstand nach einem der Beispiele 50 und 51, wobei die Beobachtung zumindest teilweise unter Verwendung von Logik bestimmt wird, die durch die Maschine genutzt wird, um Entscheidungen in Verbindung mit einer Durchführung einer autonomen Bewegung zu treffen.
Beispiel 53 beinhaltet den Gegenstand nach einem der Beispiele 43 bis 52, wobei die Beobachtungsdaten Zeitinformationen, die einem Auftreten des Ereignisses entsprechen, und Standortinformationen, die geografische Grenzen der Umgebung identifizieren, beinhalten.
Beispiel 54 beinhaltet den Gegenstand nach einem der Beispiele 43 bis 53, wobei der Satz von Sensoren eine Vielzahl unterschiedlicher Typen von Sensoren beinhaltet.
Beispiel 55 beinhaltet den Gegenstand eines der Beispiele 43-54, wobei die Beobachtung jede von mehreren Maschinen identifiziert, die an dem Sicherheitsereignis beteiligt sind.
Somit wurden bestimmte Ausführungsformen des Gegenstands beschrieben. Andere Ausführungsformen liegen innerhalb des Schutzumfangs der folgenden Ansprüche. In einigen Fällen können die in den Ansprüchen aufgeführten Handlungen in einer anderen Reihenfolge durchgeführt werden und dennoch wünschenswerte Ergebnisse erzielen. Außerdem erfordern die in den begleitenden Figuren dargestellten Prozesse nicht notwendigerweise die gezeigte spezielle Reihenfolge oder sequenzielle Reihenfolge, um gewünschte Ergebnisse zu erzielen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 16/586968 [0001]

Claims

Verfahren, umfassend: Zugreifen auf Sensordaten, die durch Sensoren einer Vorrichtung in einer Umgebung erzeugt werden; aus den Sensordaten erfolgendes Ermitteln einer Beobachtung eines Ereignisses, wobei die Beobachtung eine Bewegung einer oder mehrerer Maschinen innerhalb der Umgebung in Verbindung mit dem Ereignis identifiziert; Erzeugen von Beobachtungsdaten zur Aufnahme in eine verteilte verknüpfte Datenstruktur, wobei die Beobachtungsdaten die Beobachtung identifizieren; und Senden der Beobachtungsdaten an ein anderes System zur Speicherung in der verteilten verknüpften Datenstruktur.
Verfahren nach Anspruch 1, wobei die Erzeugung der Beobachtungsdaten Durchführen einer Inferenz unter Verwendung eines Maschinenlernmodell basierend auf zumindest einem Teil der Sensordaten umfasst.
Verfahren nach einem der Ansprüche 1 und 2, wobei die Beobachtung auf einem standardisierten Sicherheitsmodell basiert und das standardisierte Sicherheitsmodell einen Satz von Berechnungen definiert, um einen Satz sicherer Betriebsstandards zu modellieren, und die Beobachtung zumindest teilweise unter Verwendung einer oder mehrerer des Satzes von Berechnungen erzeugt wird.
Verfahren nach einem der Ansprüche 1 bis 3, wobei zumindest eine bestimmte der einen oder der mehreren Maschinen dafür konfiguriert ist, sich autonom zu bewegen.
Verfahren nach Anspruch 4, wobei die bestimmte Maschine ein autonomes Fahrzeug umfasst.
Verfahren nach einem der Ansprüche 4 bis 5, wobei die Beobachtung zumindest teilweise unter Verwendung von Logik bestimmt wird, die durch die Maschine genutzt wird, um Entscheidungen in Verbindung mit einer Durchführung einer autonomen Bewegung zu treffen.
Verfahren nach einem der Ansprüche 1 bis 6, wobei die verteilte verknüpfte Datenstruktur eine Blockchain-Datenstruktur umfasst und die Blockchain-Datenstruktur Beobachtungsdaten zum Beschreiben einer Vielzahl von Beobachtungen für das Ereignis umfasst.
Verfahren nach Anspruch 7, ferner umfassend Erzeugen eines neuen Blocks zur Aufnahme in die Blockchain-Datenstruktur, wobei der neue Block die Beobachtungsdaten umfasst und jede der Vielzahl von Beobachtungen in einem jeweiligen einer Vielzahl von Blöcken enthalten ist, die in die Blockchain aufgenommen werden sollen.
Verfahren nach einem der Ansprüche 1 bis 8, wobei die Beobachtungsdaten Zeitinformationen, die einem Auftreten des Ereignisses entsprechen, und Standortinformationen, die geografische Grenzen der Umgebung identifizieren, umfassen.
Verfahren nach einem der Ansprüche 1 bis 9, wobei die Sensordaten durch eine Vielzahl unterschiedlicher Typen von Sensoren in der Vorrichtung erzeugt werden.
Verfahren nach einem der Ansprüche 1 bis 10, wobei die Beobachtung jede einer Vielzahl von Maschinen identifiziert, die an dem Ereignis beteiligt sind.
System, das Mittel umfasst, um das Verfahren nach einem der Ansprüche 1-11 auszuführen.
System nach Anspruch 12, wobei das Mittel ein maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen umfasst, wobei die Anweisungen durch einen Prozessor ausführbar sind, um zu bewirken, dass der Prozessor das Verfahren nach einem der Ansprüche 1 bis 11 durchführt.
Verfahren, umfassend: Identifizieren von Zeitgrenzen eines Ereignisses, wobei das Ereignis einer unsicheren Aktion durch eine autonome Maschine innerhalb einer Umgebung entspricht; Identifizieren von geografischen Grenzen des Ereignisses, die mit der Umgebung zusammenhängen; Ermitteln, dass ein Teilsatz von Blöcken in einer verteilten verknüpften Datenstruktur eine Vielzahl von Beobachtungen des Ereignisses beinhaltet, basierend auf den Zeitgrenzen und den geografischen Grenzen, wobei der Teilsatz von Blöcken Beobachtungsdaten umfasst, die die Vielzahl von Beobachtungen beschreiben, und jede der Vielzahl von Beobachtungen durch eine jeweilige einer Vielzahl von Vorrichtungen aus Sensordaten abgeleitet wird, die an der entsprechenden Vorrichtung erzeugt werden; Ausführen eines Konsensalgorithmus, um eine Beurteilung aus der Vielzahl von Beobachtungen zu ermitteln; und Veranlassen, dass Beurteilungsdaten zu einem Block der verteilten verknüpften Datenstruktur hinzugefügt werden, um die Beurteilung zu beschreiben.
Verfahren nach Anspruch 14, wobei die Beurteilungsdaten Verweise auf jede der Vielzahl von Beobachtungen in dem Teilsatz von Blöcken beinhalten.
Verfahren nach einem der Ansprüche 14 bis 15, wobei mindestens eine der Vielzahl von Beobachtungen durch Logik erzeugt wird, die sich auf der autonomen Maschine befindet.
Verfahren nach einem der Ansprüche 14-16, das ferner Folgendes umfasst: Identifizieren einer Hinzufügung einer weiteren Beobachtung des Ereignisses zu einem jeweiligen Block der verteilten verknüpften Datenstruktur nach dem Hinzufügen des Beurteilungsblocks zu der verteilten verknüpften Datenstruktur; Ermitteln einer überarbeiteten Beurteilung für das Ereignis basierend auf der weiteren Beobachtung und der Vielzahl von Beobachtungen; und Veranlassen, dass zusätzliche Beurteilungsdaten zu einem anderen Block in der verteilten verknüpften Datenstruktur hinzugefügt werden, um die überarbeitete Beurteilung zu beschreiben.
Verfahren nach einem der Ansprüche 14 bis 17, wobei jede der Vielzahl von Beobachtungen in einem jeweiligen des Teilsatzes von Blöcken enthalten ist und die Beurteilungsdaten durch Hinzufügen eines neuen Blocks, der die Beurteilungsdaten enthalten soll, zu der verteilten verknüpften Datenstruktur hinzugefügt werden.
Verfahren nach einem der Ansprüche 14-18, das ferner Folgendes umfasst: Identifizieren einer Änderung an einem Satz von Regeln, der zum Ermitteln der Beurteilung verwendet wird; Ermitteln einer aktualisierten Beurteilung aus der Vielzahl von Beobachtungen basierend auf der Änderung an dem Satz von Regeln; und Veranlassen, dass aktualisierte Beurteilungsdaten zu einem anderen Block in der verteilten verknüpften Datenstruktur hinzugefügt werden, um die aktualisierte Beurteilung zu beschreiben.
System, das Mittel umfasst, um das Verfahren nach einem der Ansprüche 14-19 auszuführen.
System nach Anspruch 20, wobei das Mittel ein maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen umfasst, wobei die Anweisungen durch einen Prozessor ausführbar sind, um zu bewirken, dass der Prozessor das Verfahren nach einem der Ansprüche 14 bis 19 durchführt.
System, umfassend: einen Datenprozessor; einen Speicher; einen Satz von Sensoren; und eine Sicherheitsbeobachtungs-Engine, die durch den Datenprozessor ausführbar ist, um: einen Teilsatz von Sensordaten zu identifizieren, die von dem Satz von Sensoren erzeugt werden und die einer Zeit und Geografie eines Sicherheitsereignisses entsprechen, wobei das Sicherheitsereignis einer autonomen Bewegung durch eine Maschine entspricht; aus dem Teilsatz von Sensordaten erfolgendes Ermitteln einer Beobachtung des Sicherheitsereignisses, wobei die Beobachtung die Maschine identifiziert und Attribute der autonomen Bewegung beschreibt, wobei die Attribute mit Einhaltung eines Sicherheitsstandards assoziiert sind; Beobachtungsdaten zum Beschreiben der Beobachtung zu erzeugen; und zu veranlassen, dass die Beobachtungsdaten in einem Block einer Sicherheits-Blockchain zur Verwendung beim Ermitteln einer Ursache des Ereignisses zumindest teilweise auf Grundlage der Beobachtung gespeichert werden.
System nach Anspruch 22, ferner umfassend eine Maschinenlern-Engine zum Verwenden eines oder mehrerer Maschinenlernmodelle zum Durchführen von Inferenzen basierend auf den Sensordaten, wobei die Beobachtung zumindest teilweise basierend auf den Inferenzen bestimmt werden soll.
System nach einem der Ansprüche 22 und 23, wobei das System ein Fahrzeug, einen Straßenrandsensor, einen Roboter oder eine Drohne umfasst.
System nach einem der Ansprüche 22-24, ferner umfassend einen Validierungsknoten zum: Validieren des Blocks; und Hinzufügen des Blocks zu der Sicherheits-Blockchain basierend auf der Validierung des Blocks.
System nach einem der Ansprüche 22 bis 25, wobei die Beobachtung auf einem standardisierten Sicherheitsmodell basiert und das standardisierte Sicherheitsmodell einen Satz von Berechnungen definiert, um einen Satz sicherer Betriebsstandards zu modellieren, und die Beobachtung zumindest teilweise unter Verwendung einer oder mehrerer des Satzes von Berechnungen erzeugt wird.
System nach einem der Ansprüche 22 bis 26, ferner umfassend die Maschine, wobei die Maschine die Sicherheitsbeobachtungs-Engine umfasst.
System nach Anspruch 27, wobei die Beobachtung zumindest teilweise unter Verwendung von Logik bestimmt wird, die durch die Maschine genutzt wird, um Entscheidungen in Verbindung mit einer Durchführung einer autonomen Bewegung zu treffen.
System nach einem der Ansprüche 22-28, wobei der Satz von Sensoren eine Vielzahl unterschiedlicher Typen von Sensoren umfasst.
System nach einem der Ansprüche 22 bis 29, wobei die Beobachtung jede einer Vielzahl von Maschinen identifiziert, die an dem Ereignis beteiligt sind.