DE102020102426A1 - Fehlverhaltensdetektion in autonomen Fahrkommunikationen - Google Patents

Fehlverhaltensdetektion in autonomen Fahrkommunikationen Download PDF

Info

Publication number
DE102020102426A1
DE102020102426A1 DE102020102426.6A DE102020102426A DE102020102426A1 DE 102020102426 A1 DE102020102426 A1 DE 102020102426A1 DE 102020102426 A DE102020102426 A DE 102020102426A DE 102020102426 A1 DE102020102426 A1 DE 102020102426A1
Authority
DE
Germany
Prior art keywords
road system
road
message
data
physical object
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102020102426.6A
Other languages
English (en)
Inventor
Liuyang Yang
Manoj Sastry
Xiruo Liu
Moreno Ambrosin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE102020102426A1 publication Critical patent/DE102020102426A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/16—Anti-collision systems
    • G08G1/164—Centralised systems, e.g. external to vehicles
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05D—SYSTEMS FOR CONTROLLING OR REGULATING NON-ELECTRIC VARIABLES
    • G05D1/00—Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots
    • G05D1/0088—Control of position, course, altitude or attitude of land, water, air or space vehicles, e.g. using automatic pilots characterized by the autonomous decision making process, e.g. artificial intelligence, predefined behaviours
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/16—Anti-collision systems
    • G08G1/166—Anti-collision systems for active traffic, e.g. moving vehicles, pedestrians, bikes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/009—Security arrangements; Authentication; Protecting privacy or anonymity specially adapted for networks, e.g. wireless sensor networks, ad-hoc networks, RFID networks or cloud networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
    • H04W12/122—Counter-measures against attacks; Protection against rogue devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/02—Access restriction performed under specific conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/005—Discovery of network devices, e.g. terminals

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Game Theory and Decision Science (AREA)
  • Evolutionary Computation (AREA)
  • Artificial Intelligence (AREA)
  • Medical Informatics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Health & Medical Sciences (AREA)
  • Business, Economics & Management (AREA)
  • Automation & Control Theory (AREA)
  • Databases & Information Systems (AREA)
  • Traffic Control Systems (AREA)

Abstract

Ein erstes Straßensystem empfängt eine Kommunikation von einem zweiten Straßensystem über einen drahtlosen Kanal, wobei die Kommunikation eine Beschreibung eines physischen Objekts innerhalb einer Fahrumgebung umfasst. Charakteristiken des physischen Objekts werden basierend auf Sensoren des ersten Straßensystems bestimmt. Die Kommunikation wird bestimmt, um eine Anomalie zu umfassen, basierend auf einem Vergleich der Beschreibung des physischen Objekts mit den basierend auf den Sensoren des ersten Straßensystems bestimmten Charakteristiken. Zur Beschreibung der Anomalie werden Fehlverhaltensdaten erzeugt. Basierend auf der Anomalie wird eine Abhilfehandlung initiiert.

Description

  • ZUGEHÖRIGE ANMELDUNGEN
  • Diese Anmeldung beansprucht die Priorität der Provisorischen US-Patentanmeldung mit dem Aktenzeichen 62/812,509 , eingereicht am 1. März 2019, die hierin durch Bezugnahme in ihrer Gesamtheit aufgenommen ist.
  • TECHNISCHES GEBIET
  • Diese Offenbarung bezieht sich im Allgemeinen auf den Bereich der Computersysteme und im Besonderen auf Rechensysteme, die eine Kommunikation zwischen autonomen Fahrzeugen erleichtern.
  • HINTERGRUND
  • Einige Fahrzeuge sind ausgebildet, um in einem autonomen Modus zu arbeiten, in dem das Fahrzeug mit wenig oder gar keiner Eingabe von einem Fahrer durch eine Umgebung navigiert. Ein solches Fahrzeug umfasst typischerweise einen oder mehrere Sensoren, die ausgebildet sind, um Informationen über die Umgebung zu erfassen. Das Fahrzeug kann die erfassten Informationen zur Navigation durch die Umgebung nutzen. Wenn die Sensoren beispielsweise 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 des automatisierten Fahrens darstellt.
    • 4 ist ein vereinfachtes Blockdiagramm, das Betriebsprinzipien eines automatisierten Fahrsystems darstellt.
    • 5 ist ein vereinfachtes Blockdiagramm, das die Grundfunktionen von automatisierten Fahrsystemen darstellt.
    • 6 ist ein vereinfachtes Blockdiagramm, das Komponenten eines beispielhaften automatisierten Fahrsystems darstellt.
    • 7 ist ein vereinfachtes Diagramm, das Fahrzeuge innerhalb einer Beispiel-Fahrumgebung darstellt.
    • 8 ist ein vereinfachtes Diagramm, das ein Beispiel für kommunikationsbasiertes Fehlverhalten innerhalb einer autonomen Fahrumgebung darstellt.
    • 9 stellt Diagramme dar, die die relativen angreifbaren Flächen zeigen, die bei unterschiedlichen beispielhaften autonomen Fahrsystemen ermöglicht werden.
    • 10 stellt Diagramme dar, die ein Beispiel für die sich im Laufe der Zeit ändernden Zustände von miteinander kommunizierenden Fahrzeugen zeigen.
    • 11 ist ein vereinfachtes Blockdiagramm, das einen beispielhaften Ablauf zum Detektieren von Anomalien durch ein Straßensystem darstellt.
    • 12 stellt Diagramme dar, die unterschiedliche Grade an Inkonsistenz zeigen, die durch ein Straßensystem beim Bewerten von kommunikationsbasiertem Fehlverhalten durch ein anderes Straßensystem innerhalb einer autonomen Fahrumgebung gemessen werden können.
    • 13 ist ein vereinfachtes Diagramm, das ein Beispiel für einen versuchten Geisterfahrzeugangriff darstellt.
    • 14A-14B stellen ein vereinfachtes Blockdiagramm dar, das ein beispielhaftes Detektieren von kommunikationsbasiertem Fehlverhalten innerhalb einer autonomen Fahrumgebung darstellt.
    • 15 stellt Diagramme dar, die unterschiedliche Sichtfelder eines gemeldeten Objekts durch unterschiedliche Straßensysteme innerhalb einer autonomen Fahrumgebung zeigen.
    • 16 ist ein vereinfachtes Diagramm, das eine Beispiel-Zertifikatsmanagementarchitektur darstellt.
    • 17 ist ein vereinfachtes Flussdiagramm, das eine Beispieltechnik zum Detektieren von kommunikationsbasiertem Fehlverhalten durch ein Straßensystem innerhalb einer autonomen Fahrumgebung darstellt.
    • 18 ist ein Blockdiagramm eines beispielhaften Prozessors gemäß einem Ausführungsbeispiel.
    • 19 ist ein Blockdiagramm eines beispielhaften Rechensystems gemäß einem Ausführungsbeispiel.
  • Gleiche Bezugszeichen und Bezeichnungen in den verschiedenen Zeichnungen zeigen gleiche Elemente an.
  • BESCHREIBUNG DER AUSFÜHRUNGSBEISPIELE
  • 1 ist eine vereinfachte Darstellung 100, die eine beispielhafte autonome Fahrumgebung zeigt. Fahrzeuge (z.B. 105, 110, 115 etc.) können variierende Stufen autonomer Fahrfähigkeiten bereitgestellt haben, die durch fahrzeuginterne Rechensysteme mit in Hardware, Firmware und/oder Software implementierter Logik ermöglicht werden, um jeweilige autonome Fahrstapel zu ermöglichen. Solche autonomen Fahrstapel können es Fahrzeugen erlauben, sich selbst zu steuern oder eine Fahrerassistenz bereitzustellen, um Straßen zu detektieren, von einem Punkt zu einem anderen zu navigieren, andere Fahrzeuge und Straßenakteure (z.B. Fußgänger (z.B. 135), Radfahrer etc.) zu detektieren, Hindernisse und Gefahren (z.B. 120) sowie Straßenverhältnisse (z.B. Verkehr, Straßenverhältnisse, Wetterbedingungen etc.) zu detektieren und die Steuerung und Führung des Fahrzeugs entsprechend anzupassen.
  • Bei einigen Implementierungen können Fahrzeuge (z.B. 105, 110, 115) innerhalb der Umgebung „verbunden“ sein, indem die fahrzeuginternen Rechensysteme Kommunikationsmodule zur Unterstützung von drahtloser Kommunikation unter Verwendung einer oder mehrerer Technologien (z.B. IEEE 802.11-Kommunikationen (z.B. WiFi), zellulare Datennetzwerke (z.B. 3rd Generation Partnership Project (3GPP)-Netzwerke, Global System for Mobile Communication (GSM), General Packet Radio Service, Codemultiplexzugriff (CDMA; code division multiple access) etc.), Bluetooth™, Millimeterwellen (mmWave), ZigBee™, Z-Wave™ etc.) umfassen, die es den fahrzeuginternen Rechensystemen erlauben, sich mit anderen Rechensystemen zu verbinden und mit diesen zu kommunizieren, wie beispielsweise den fahrzeuginternen Rechensystemen anderer Fahrzeuge, Straßenrandeinheiten, Cloud-basierten Rechensystemen oder anderer unterstützender Infrastruktur. Bei einigen Implementierungen können die Fahrzeuge (z.B. 105, 110, 115) beispielsweise mit Rechensystemen kommunizieren, die Sensoren, Daten und Dienste zur Unterstützung der eigenen autonomen Fahrfähigkeiten der Fahrzeuge bereitstellen. Beispielsweise, wie bei dem darstellenden Beispiel von 1 gezeigt, können unterstützende (z.B. bodenbasierte und/oder Luft-) Drohnen 180, Straßenrand-Rechenvorrichtungen (oder Straßenrandeinheiten (RSUs; road side units) (z.B. 140), verschiedene externe (zu dem Fahrzeug oder „fremde“) Sensorbauelemente (z.B. 160, 165, 170, 175 etc.) und andere Vorrichtungen können als autonome Fahrinfrastruktur getrennt von den Rechensystemen, Sensoren und Logik, die auf den Fahrzeugen (z.B. 105, 110, 115) implementiert sind, bereitgestellt sein, um die durch die Fahrzeuge bereitgestellten Ergebnisse zum autonomen Fahren zu unterstützen und zu verbessern, neben anderen Beispielen. Fahrzeuge können auch mit anderen verbundenen Fahrzeugen über drahtlose Kommunikationskanäle kommunizieren, um Daten gemeinsam zu nutzen und Bewegungen innerhalb einer autonomen Fahrumgebung zu koordinieren, neben anderen Beispiel-Kommunikationen.
  • Wie bei dem Beispiel von 1 dargestellt, kann eine autonome Fahrinfrastruktur eine Vielzahl an unterschiedlichen Systemen umfassen. Solche Systeme können abhängig von der Position variieren, wobei stärker ausgebaute Straßen (z.B. Straßen, die durch spezifische Gemeinden oder Mautbehörden kontrolliert werden, Straßen in städtischen Gebieten, Straßenabschnitte, die bekanntermaßen für autonome Fahrzeuge problematisch sind, etc.) eine größere Anzahl an oder fortschrittlichere unterstützende Infrastrukturvorrichtungen aufweisen als andere Straßenabschnitte etc. Beispielsweise können zusätzliche Sensorbauelemente (z.B. 160, 165, 170, 175) bereitgestellt sein, die Sensoren zur Beobachtung von Abschnitten von Straßen und Fahrzeugen, die sich innerhalb der Umgebung bewegen, umfassen und entsprechende Daten erzeugen, die die Beobachtungen der Sensoren beschreiben oder verkörpern. Als Beispiele können Sensorbauelemente innerhalb der Straße selbst (z.B. Sensor 160), auf Straßenrand- oder Überkopfbeschilderung (z.B. Sensor 165 auf dem Schild 125), Sensoren (z.B. 170, 175), die an elektronischen Straßenrandausrüstungen oder -halterungen angebracht sind (z.B. Ampeln (z.B. 130), elektronischen Straßenschildern, elektronischen Reklametafeln etc.), zweckgebundenen Straßenrandeinheiten (z.B. 140) eingebettet sein, neben anderen Beispielen. Sensorbauelemente können auch Kommunikationsfähigkeiten umfassen, um ihre gesammelten Sensordaten direkt an nahegelegene verbundene Fahrzeuge oder an Fog- oder Cloud-basierte Rechensysteme (z.B. 140, 150) zu kommunizieren. Fahrzeuge können Sensordaten erhalten, die durch externe Sensorbauelemente (z. B. 160, 165, 170, 175, 180) gesammelt wurden, oder Daten, die Beobachtungen oder Empfehlungen verkörpern, die durch andere Systeme (z. B. 140, 150) basierend auf Sensordaten von diesen Sensorbauelementen (z. B. 160, 165, 170, 175, 180) erzeugt wurden, und diese Daten bei einer Sensorfusion, Inferenz, Pfadplanung und anderen Aufgaben, die durch das fahrzeuginterne autonome Fahrsysteme durchgeführt werden, verwenden. In einigen Fällen können solche fremden Sensoren und Sensordaten tatsächlich innerhalb des Fahrzeugs sein, wie z.B. in Form eines am Fahrzeug angebrachten Nachrüstsensors, einer persönlichen Rechenvorrichtung (z.B. Smartphone, Wearable etc.), mitgeführt oder getragen durch Passagiere des Fahrzeugs, etc. Andere Straßenakteure, umfassend Fußgänger, Fahrräder, Drohnen, elektronische Roller etc., können ebenfalls Sensoren bereitgestellt haben oder diese mitführen, um Sensordaten zu erzeugen, die eine autonome Fahrumgebung beschreiben, die durch autonome Fahrzeuge, Cloud- oder Fog-basierte Unterstützungssysteme (z.B. 140, 150), andere Sensorbauelemente (z.B. 160, 165, 170, 175, 180) etc. genutzt und verbraucht werden können, neben anderen Beispielen.
  • Da autonome Fahrzeugsysteme variierende Stufen an Funktionalität und Ausgereiftheit aufweisen können, kann eine Unterstützungsinfrastruktur in Anspruch genommen werden, um nicht nur die Erfassungsfähigkeiten einiger Fahrzeuge, sondern auch die Computer- und Maschinenlernfunktionalität, die eine autonome Fahrfunktionalität einiger Fahrzeuge ermöglicht, zu ergänzen. Beispielsweise können Rechenressourcen und autonome Fahrlogik, verwendet zur Erleichterung eines Maschinenlernmodelltrainings und Verwendung solcher Maschinenlernmodelle, auf den fahrzeuginternen Rechensystemen ganz oder teilweise auf sowohl den fahrzeuginternen Systemen als auch einigen externen Systemen (z.B. 140, 150) bereitgestellt sein. Beispielsweise kann ein verbundenes Fahrzeug mit Straßenrandeinheiten, Randsystemen oder Cloud-basierten Vorrichtungen (z.B. 140), lokal im Hinblick auf ein bestimmtes Segment einer Straße, kommunizieren, 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 durchführen, die durch ein Fahrzeug bereitgestellt sind, um die im Hinblick auf das Fahrzeug nativen Fähigkeiten zu ergänzen und/oder Informationen an vorbeifahrende oder sich nähernde Fahrzeuge weiterzugeben (z.B. basierend auf Sensordaten, die an der Vorrichtung 140 oder von nahegelegenen Sensorbauelementen gesammelt werden, etc.). 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 Berechnungsressourcen bereitstellen können, um die beim Fahrzeug verfügbaren zu verbessern. Ein Cloud-basiertes System (z.B. 150) kann beispielsweise Sensordaten von einer Vielzahl von Vorrichtungen an einem oder mehreren Orten sammeln und diese Daten zum Aufbau und/oder Training von Maschinenlernmodellen nutzen, die an den Cloud-basierten Systemen verwendet werden können (um Ergebnisse an verschiedene Fahrzeuge (z.B. 105, 110, 115) in Kommunikation mit dem Cloud-basierten System 150 bereitzustellen oder um an Fahrzeuge zur Verwendung durch ihre fahrzeuginternen Systeme weiterzugeben, neben anderen Beispielimplementierungen. Zugriffspunkte (z.B. 145), wie z.B. Mobilfunkmasten, Straßenrandeinheiten, Netzwerkzugriffspunkte, die an verschiedenen Straßeninfrastrukturen angebracht sind, Zugriffspunkte, die durch benachbarte Fahrzeugen oder Gebäude bereitgestellt sind, und andere Zugriffspunkte können innerhalb einer Umgebung bereitgestellt sein und zur Erleichterung der Kommunikation über ein oder mehrere lokale oder weite Netzwerke (z.B. 155) zwischen Cloud-basierten Systemen (z.B. 150) und verschiedenen Fahrzeugen (z.B. 105, 110, 115) verwendet werden. Durch solche Infrastruktur- und Rechensysteme wird darauf hingewiesen, dass die hierin erörterten Beispiele, Merkmale und Lösungen vollständig durch ein oder mehrere solche fahrzeuginternen Rechensysteme, Fog-basierte oder Edge-Rechenvorrichtungen oder Cloud-basierte Rechensysteme oder durch Kombinationen des vorstehend Genannten durch Kommunikation und Kooperation zwischen den Systemen durchgeführt werden können.
  • Im Allgemeinen können „Server“, „Clients“, „Rechenvorrichtungen“, „Netzwerkelemente“, „Hosts“, „Plattformen“, „Sensorbauelemente“, „Edge-Vorrichtungen“, „autonome Fahrsysteme“, „autonome Fahrzeuge“, „Fog-basiertes System“, „Cloud-basiertes System“ und „Systeme“ im Allgemeinen etc., die hierin erörtert werden, elektronische Rechenvorrichtungen umfassen, die zum Empfang, Senden, Verarbeiten, Speichern oder Managen von Daten und Informationen, die einer autonomen Fahrumgebung zugeordnet sind, betrieben werden können. Wie in diesem Dokument verwendet, soll der Begriff „Computer“, „Prozessor“, „Prozessorbauelement“ oder „Verarbeitungsvorrichtung“ jegliche geeigneten Verarbeitungsgeräte umfassen, umfassend zentrale Verarbeitungseinheiten (CPUs; central processing units), graphische Verarbeitungseinheiten (GPUs; graphical processing units), anwendungsspezifische integrierte Schaltungen (ASICs; application specific integrated circuits), feld-programmierbare Gate-Arrays (FPGAs; field programmable gate arrays), digitale Signalprozessoren (DSPs; digital signal processors), Tensorprozessoren und andere Matrix-Arithmetik-Prozessoren, neben anderen Beispielen. Beispielsweise können Elemente, die als einzelne Vorrichtungen innerhalb der Umgebung gezeigt sind, unter Verwendung einer Mehrzahl von Rechenvorrichtungen und Prozessoren implementiert sein, wie z.B. Server-Pools, umfassend mehrere Server-Computer. Darüber hinaus können alle oder einige der Rechenvorrichtungen angepasst sein, um irgendein Betriebssystem auszuführen, umfassend Linux™, UNIX™, Microsoft™ Windows™, Apple™ macOS™, Apple™ iOS™, Google™ Android™, Windows Server™ etc., sowie virtuelle Maschinen, die zur Virtualisierung der Ausführung eines bestimmten Betriebssystems angepasst sind, umfassend spezifisch angepasste und proprietäre Betriebssysteme.
  • Irgendwelche von den Abläufen, Verfahren, Prozessen (oder Abschnitten davon) oder Funktionalität von irgendwelchen der verschiedenen Komponenten, die unten beschrieben oder in den Figuren dargestellt sind, können durch irgendeine geeignete Rechenlogik, wie z.B. ein oder mehrere Module, Maschinen (engines), Blöcke, Einheiten, Modelle, Systeme oder andere geeignete Rechenlogik, durchgeführt werden. Der Verweis hierin auf ein „Modul“, eine „Maschine“, einen „Block“, eine „Einheit“, ein „Modell“, ein „System“ oder eine „Logik“ kann sich auf Hardware, Firmware, Software und/oder Kombinationen von jedem beziehen, um eine oder mehrere Funktionen auszuführen. Als ein Beispiel kann ein Modul, eine Maschine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik eine oder mehrere Hardwarekomponenten umfassen, wie beispielsweise einen Mikrocontroller oder Prozessor, zugeordnet zu einem nichtflüchtigen Medium, um Code zu speichern, der angepasst ist, um durch den Mikrocontroller oder Prozessor ausgeführt zu werden. Daher kann sich der Bezug auf ein Modul, eine Maschine, einen Block, eine Einheit, ein Modell, ein System oder eine Logik bei einem Ausführungsbeispiel auf Hardware beziehen, die spezifisch ausgebildet ist, um den Code, der auf einem nichtflüchtigen Medium zu halten ist, zu erkennen und/oder auszuführen. Ferner bezieht sich bei einem anderen Ausführungsbeispiel die Verwendung von Modul, Maschine, Block, Einheit, Modell, System oder Logik auf das nichtflüchtige Medium, umfassend den Code, der spezifisch angepasst ist, um durch den Mikrocontroller oder Prozessor ausgeführt zu werden, um vorbestimmte Operationen durchzuführen. Und wie abgeleitet werden kann, kann sich bei einem wiederum anderen Ausführungsbeispiel ein Modul, eine Maschine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik auf die Kombination der Hardware und des nichtflüchtigen Mediums beziehen. Bei verschiedenen Ausführungsbeispielen kann ein Modul, eine Maschine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik einen Mikroprozessor oder ein anderes Verarbeitungselement, das zur Ausführung von Softwareanweisungen betrieben werden kann, diskrete Logik, wie beispielsweise eine anwendungsspezifische integrierte Schaltung (ASIC), eine programmierte Logikvorrichtung, wie beispielsweise ein feld-programmierbares Gate-Array (FPGA), ein Speicherbauelement, das Anweisungen umfasst, Kombinationen von Logikvorrichtungen (z.B. wie sie auf einer gedruckten Schaltungsplatine zu finden wären) oder andere geeignete Hardware und/oder Software umfassen. Ein Modul, eine Maschine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik kann ein oder mehrere Gates oder andere Schaltungskomponenten umfassen, die z.B. durch Transistoren implementiert sein können. Bei einigen Ausführungsbeispielen kann ein Modul, eine Maschine, ein Block, eine Einheit, ein Modell, ein System oder eine Logik vollständig als Software verkörpert sein. Software kann als ein Software-Package, Code, Anweisungen, Anweisungssätze und/oder Daten, aufgezeichnet auf einem nichtflüchtigen computerlesbaren Speichermedium, verkörpert sein. Firmware kann als Code, Anweisungen oder Anweisungssätze und/oder Daten, die in Speicherbauelementen hartcodiert (z. B. nichtflüchtig) sind, verkörpert sein. Ferner variieren Logikgrenzen, die als getrennt dargestellt sind, gewöhnlich und überlappen potenziell. Zum Beispiel können ein erstes und ein zweites Modul (oder mehrere Maschinen, Blöcke, Einheiten, Modelle, Systeme oder Logiken) Hardware, Software, Firmware oder eine Kombination davon gemeinschaftlich verwenden, während potenziell eine gewisse unabhängige Hardware, Software oder Firmware beibehalten wird.
  • Die im Folgenden und in den beiliegenden Figuren beschriebenen Abläufe, Verfahren und Prozesse sind lediglich repräsentativ für Funktionen, die bei bestimmten Ausführungsbeispielen durchgeführt werden können. Bei anderen Ausführungsbeispielen können zusätzliche Funktionen in den Abläufen, Verfahren und Prozessen ausgeführt werden. Verschiedene Ausführungsbeispiele der vorliegenden Offenbarung betrachten jegliche geeigneten Signalgebungsmechanismen zur Erfüllung der hierin beschriebenen Funktionen. Einige der hierin dargestellten Funktionen können gegebenenfalls innerhalb der Abläufe, Verfahren und Prozesse wiederholt, kombiniert, modifiziert oder gelöscht werden. Zusätzlich können Funktionen in irgendeiner geeigneten Reihenfolge innerhalb der Abläufe, Verfahren und Prozesse ausgeführt werden, ohne vom Schutzbereich bestimmter Ausführungsbeispiele abzuweichen.
  • Wie oben eingeführt, kann die Kommunikation zwischen Vorrichtungen genutzt werden, um mehrere Fahrzeuge sowie Straßenrandeinheiten- (RSU) Systeme zu befähigen, zu kooperieren und die Funktionalität des anderen zu nutzen, um zumindest teilautonome Fahrumgebungen zu verbessern und zu erleichtern. Beispielsweise ermöglicht V2X- (vehicles-to-everything) Kommunikation eine gemeinsame Nutzung von Informationen zwischen Fahrzeugen, Fußgängern und Straßenrandeinheiten in der Nähe durch V2X-Nachrichten. Als solches kann V2X als ein zentraler Wegbereiter für intelligente Transportsysteme dienen und seine Nutzung reicht von sicherheitskritischen Anwendungen bis hin zu Fahrzeug-Infotainment-Systemen, von lokalem kooperativem Fahren bis hin zu groß angelegtem Verkehrsmanagement. Während solche Kommunikationsschemata für die Erleichterung des autonomen Fahrens von Vorteil sein können, können solche Maschine-zu-Maschine-Kommunikationen (z.B. V2X) anfällig für Angriffe oder Bedrohungen sein. Beispielsweise können sich viele V2X-Anwendungen (z.B. Kollisionsvermeidungsanwendung, intelligente Verkehrssteuerungssignalsysteme) auf einen Austausch von Fahrinformationen (z.B. Geschwindigkeit, Position, Beschleunigung und Richtung) über grundlegende Sicherheitsnachrichten (BSMs; Basic Safety Messages) (z.B. in den Vereinigten Staaten) oder kooperative Bewusstseins-Nachrichten (CAMs; Cooperative Awareness Messages) (z.B. in Europa) (hierin zusammenfassend als grundlegende Sicherheitsnachrichten (BSMs) bezeichnet) verlassen. Dementsprechend können Sicherheitsverletzungen und Angriffe auf solche Nachrichten potenziell zu katastrophalen Sicherheitsereignissen führen und das öffentliche Vertrauen in solche Systeme bedrohen.
  • Als ein Beispiel können autonome Fahrsysteme eine gemeinsam genutzte Wahrnehmung unterstützen, mit Fahrzeugen oder Straßenrandeinheiten, die mit Sensoren und auf maschinellem Lernen basierenden Wahrnehmungs- (z.B. Computervision) Fähigkeiten ausgestattet sind, die ein maschinelles Detektieren von Objekten in einer Fahrumgebung ermöglichen. V2X- oder andere Nachrichten können zwischen Straßensystemen, die verschiedenen Straßenakteuren (z.B. Fahrzeugen, Straßenrandeinheiten, Fußgängern/Radfahrern, die Rechenvorrichtungen mit sich führen, etc.) zugeordnet sind, kommuniziert werden, was es erlaubt, eine Objekt-Detektion und Positionierung zwischen Straßensystemen gemeinsam zu nutzen, um zu ergänzen, welche (falls irgendeine) Wahrnehmungslogik auf dem empfangenden System implementiert ist. Ein Fahrzeug kann sich dann auf Darstellungen durch andere Straßensysteme verlassen, dass verschiedene Objekte vorhanden sind (oder nicht vorhanden sind), basierend auf Nachrichten, die von anderen Straßenakteursystemen empfangen werden.
  • Die Authentizität und Integrität von über V2X ausgetauschten Nachrichten wird durch digitale Signaturen garantiert. Beispielsweise kann ein Rechensystem eines Fahrzeugs oder einer Stra-ßenrandeinheit, das solche Nachrichten ausgibt, jede gesendete Nachricht unter Verwendung eines geheimen Schlüssels, der einem gegebenen Zertifikat zugeordnet ist, signieren. Das empfangende System kann die Authentizität und Integrität irgendeiner Nachricht verifizieren, indem es die Gültigkeit des Zertifikats und der Signatur verifiziert. Solche Zertifikate können durch eine vertrauenswürdige Zertifizierungsstelle gemanagt und ausgegeben werden. Beispielsweise können V2X-Zertifikate an die legitimen Benutzer durch eine Zugangsdatenmanagementinfrastruktur geliefert werden, wie beispielsweise das Secure Credentials Management System (SCMS) in den Vereinigten Staaten, neben anderen Beispiel-Entitäten.
  • Während gemeinsam genutzte Wahrnehmungsimplementierungen durch V2X das Potenzial aufweist, die Wahrnehmung von Fahrzeugen mit Sensoren und der Fähigkeit zur V2X-Kommunikation („verbundene autonome Fahrzeuge (CAVs; Connected Autonomous Vehicles)“) sowie von Fahrzeugen ohne Sensoren und der Fähigkeit zur V2X-Kommunikation („verbundene Fahrzeuge (CVs; Connected Vehicles)“) (Fahrzeuge ohne Sensoren, aber mit der Fähigkeit zur V2X-Kommunikation) zu erweitern. Unterschiedlich zu dem einfachen CV-Fall, wo Fahrzeuge ihre Stellung, Geschwindigkeit und andere Charakteristiken der sendenden Entität in grundlegenden V2X-Sicherheitsnachrichten gemeinsam nutzen, können Straßensysteme in einem gemeinsam genutzten Wahrnehmungssystem Wahrnehmungsinformationen austauschen (z.B. die Liste der Objekte, die sie detektiert und verfolgt haben). Eine gemeinsam genutzte Wahrnehmung kann die autonomen Fahrfähigkeiten, basierend auf Wahrnehmung, auf autonome Fahrzeuge niedrigerer Stufen ausdehnen. Trotz dieser Beispielvorteile können Nachrichten in einem V2X-System anfällig für böswillige Akteure sein, die Falschdatenangriffe starten können, um den korrekten Betrieb von Fahrzeugen auf einem Segment einer Straße zu stören. Während V2X (und andere Nachrichten) unter Verwendung von digitalen Signaturen im Hinblick auf Integrität und Authentizität geschützt sein können, kann ein ausgeklügelter Gegner, der über gültige V2X-Zugangsdaten verfügt, dennoch Falschdatenangriffe unter Verwendung kompromittierter V2X-Nachrichten starten. Beispielsweise kann ein Angreifer einen Geisterfahrzeugangriff (GVA; ghost vehicle attack) in einer gemeinsam genutzten Wahrnehmungsumgebung starten, bei dem ein böswilliger Sender ein nicht existierendes oder absichtlich falsch platziertes Objekt erstellt und dasselbe unter Verwendung von V2X kommuniziert, um die Wahrnehmung der Umgebung anderer Fahrzeuge zu beeinflussen. Die Auswirkungen dieses Angriffs können für die Sicherheit der Fahrzeuge erheblich sein. Dementsprechend werden in dieser Offenbarung verbesserte Straßensystem-Implementierungen beschrieben, umfassend Merkmale zum Detektieren und Abschwächen von Fehlverhalten, umfassend V2X und andere Zwischen-Straßen-System-Kommunikationen.
  • Nun bezugnehmend auf 2 ist ein vereinfachtes Blockdiagramm 200 gezeigt, das eine Beispielimplementierung eines Straßensystems 205, das mit einem Fahrwahrnehmungssystem 210 und einer Fehlverhaltensdetektionsmaschine 215 ausgestattet ist, zeigt. Ein solches System 205 kann in irgendeinem von einer Vielzahl von Straßenakteuren implementiert sein, wie z.B. Fahrzeugen (z.B. 110, 115), Straßenrandeinheiten (z.B. 160, 165), Drohnen, neben anderen Entitäten an oder in der Nähe einer Straße. Bei einem Beispiel kann ein Straßensystem 205 einen oder mehrere Prozessoren 202 umfassen, wie z.B. zentrale Verarbeitungseinheiten (CPUs), graphische Verarbeitungseinheiten (GPUs), anwendungsspezifische integrierte Schaltungen (ASICs), feld-programmierbare Gate-Arrays (FPGAs), digitale Signalprozessoren (DSPs), Tensorprozessoren und andere Matrix-Arithmetik-Prozessoren, neben anderen Beispielen. Solche Prozessoren 202 können ferner integrierte Hardware-Beschleuniger umfassen oder mit diesen gekoppelt sein, die weitere Hardware zur Beschleunigung bestimmter Verarbeitungs- und Speicherzugriffsfunktionen bereitstellen können, wie z.B. Funktionen im Zusammenhang mit Maschinenlern-Inferenz oder Training (umfassend irgendeines von Maschinenlern-Inferenz oder Training, die unten beschrieben sind), Verarbeitung bestimmter Sensordaten (z.B. Kamerabilddaten, Licht- und Abstandsmessungs- (LIDAR; Light Detecting and Ranging) Punktwolken etc.), Durchführung bestimmter arithmetischer Funktionen, die sich auf das autonome Fahren beziehen (z.B. Matrix-Arithmetik, Konvolutionsarithmetik etc.), neben anderen Beispielen. Ein oder mehrere Speicherelemente (z.B. 206) können zur Speicherung von maschinenausführbaren Anweisungen bereitgestellt sein, die alle oder einen Abschnitt von irgendeinem der Module oder Teilmodule eines autonomen Fahrstapels, implementiert auf dem Fahrzeug, implementieren, sowie zur Speicherung von Daten, die zur Durchführung einer Wahrnehmung von Objekten innerhalb einer Fahrumgebung verwendet werden. Solche Daten können z.B. Maschinenlernmodelle (z.B. 256), Sensordaten (z.B. 258), Objektdaten 262 (z.B. lokal an dem Straßensystem 205 bestimmt oder von anderen Straßensystemen über V2X-Nachrichtenübermittlung empfangen) und andere Daten umfassen, die in Verbindung mit der durch das Fahrzeug auszuführenden autonomen Fahrfunktionalität empfangen, erzeugt oder verwendet werden (oder in Verbindung mit den hierin erörterten Beispielen und Lösungen verwendet werden). Es können auch verschiedene Kommunikationsmodule (z.B. 212) bereitgestellt sein, die in Hardware-Schaltungsanordnung und/oder Software implementiert sind, um Kommunikationsfähigkeiten zu implementieren, die durch das System des Fahrzeugs zur Kommunikation mit anderen fremden Rechensystemen über einen oder mehrere Netzwerkkanäle unter Verwendung einer oder mehrerer Netzwerkkommunikationstechnologien (z.B. V2X) verwendet werden. Diese verschiedenen Prozessoren 202, Beschleuniger, Speicherbauelemente 206 und Netzwerkkommunikationsmodule 212 können auf dem Fahrzeugsystem durch eine Vielzahl von Schnittstellen verbunden sein, implementiert, z.B. durch ein oder mehrere Verbindungs-Strukturen oder Links, wie z.B. Strukturen, die Technologien wie einen Peripheral Component Interconnect Express (PCIe), Ethernet, Universal Serial Bus (USB), Ultra Path Interconnect (UPI), Controller Area Network (CAN; Steuerungsbereich-Netzwerk)-Bus, unter anderem, verwenden.
  • Im Falle eines Fahrzeugs kann ein Straßensystem 205 Beobachtungen und entsprechende Daten erzeugen, die als Eingabe für ein fahrzeuginternes Fahrsystem verwendet werden können, um die Art und Weise zu beeinflussen, in der das Fahren des Fahrzeugs gesteuert wird. In Straßenrandeinheiten kann das Straßensystem 205 auf ähnliche Weise ein Verhalten verschiedener Objekte innerhalb eines Abschnitts einer Fahrumgebung detektieren und bestimmen und diese Beobachtungen an Fahrzeuge innerhalb der Fahrumgebung für deren Nutzung sowie an Backend-Systeme für weitere Analysen, Berichterstattung, Sicherheit, Gesetzesvollzug, Einhaltung von Vorschriften und gesetzlichen Bestimmungen und andere Beispielanwendungen kommunizieren. Bei einer Implementierung kann ein Fahrwahrnehmungssystem 210 eine maschinenausführbare Logik (z.B. in Hardware und/oder Software implementiert) bereitgestellt haben, um umgebende Objekte und diesen Objekten zugeordnete Ereignisse innerhalb einer Fahrumgebung „wahrzunehmen“, z.B. unter Verwendung von maschinellem Lernen. Dementsprechend kann eine Maschine für maschinelles Lernen 232 bereitgestellt sein, um verschiedene an dem Straßensystem 205 bereitgestellte Maschinenlernmodelle (z.B. 256) zu nutzen, um als Eingaben Sensordaten (z.B. 258) zu nehmen, die durch lokale oder fremde Sensoren (z.B. 225) gesammelt wurden, und basierend auf den trainierten Maschinenlernmodellen (z.B. 256) Inferenzen zu erzeugen. Solche Inferenzen können die Basis für die Wahrnehmung eines bestimmten Objekts bilden (z.B. um zu erkennen, dass das Objekt existiert und um das Objekt als eine bestimmte Art von Objekt zu klassifizieren (z.B. ein Auto, ein Lastwagen, ein Fußgänger, ein Straßenschild, ein Fahrrad, ein Tier oder eine andere Straßengefahr etc.). Solche Maschinenlernmodelle 256 können Künstliches-neuronales-Netzwerk-Modelle, Konvolutions-neuronale-Netzwerke, Entscheidungsbaumbasierte Modelle, Support Vector Machines (SVMs), Bayes'sche Modelle, Deep-Learning- (tiefes Lernen) Modelle und andere Beispielmodelle umfassen. Bei einigen Implementierungen kann eine beispielhafte Maschine für maschinelles Lernen 232 ferner eine Logik umfassen, um an Training (z.B. Erst-Training, weiterführendes Training etc.) eines oder mehrerer der Maschinenlernmodelle 256 teilzunehmen. Bei einigen Ausführungsbeispielen kann das/die hierin beschriebene Maschinenlernmodell-Training oder Inferenz außerhalb des Fahrzeugs durchgeführt werden, neben anderen Beispielimplementierungen.
  • Die an dem Fahrzeug bereitgestellte(n) Maschine(n) für maschinelles Lernen 232 kann/können verwendet werden, um Ergebnisse zur Verwendung durch andere logische Komponenten und Module des Fahrwahrnehmungssystems 210, einen autonomen Fahrstapel und andere mit dem autonomen Fahren zusammenhängende Merkmale implementierend, zu unterstützen und bereitzustellen. So kann z.B. ein Datensammlungsmodul 234 eine Logik bereitgestellt haben, um Quellen zu bestimmen, aus denen Daten gesammelt werden sollen (z.B. für Eingaben im Training oder die Verwendung von verschiedenen Maschinenlernmodellen 256, die durch das Fahrzeug verwendet werden). Beispielsweise kann die bestimmte Quelle (z.B. interne Sensoren (z.B. 225) oder fremde Quellen (die über drahtlose Kanäle kommunizieren)) ausgewählt werden, so wie die Frequenz und die Genauigkeit, mit der die Daten abgetastet werden können, ausgewählt wird. In einigen Fällen können solche Selektionen und Konfigurationen zumindest teilweise autonom durch das Datensammlungsmodul 234 unter Verwendung eines oder mehrerer entsprechender Maschinenlernmodelle vorgenommen werden (z.B. um Daten je nach Eignung bei einem bestimmten detektierten Szenario zu sammeln).
  • Ein Sensorfusionsmodul 236 kann auch verwendet werden, um die Verwendung und Verarbeitung der verschiedenen Sensoreingaben zu regeln, die durch die Maschine für maschinelles Lernen 232 und andere Module (z.B. 238, 240, 242 etc.) des Fahrwahrnehmungssystems 205 verwendet werden. Es können ein oder mehrere Sensorfusionsmodule (z.B. 236) bereitgestellt sein, die eine Ausgabe von mehreren Sensordatenquellen (z.B. auf dem Fahrzeug oder fahrzeugextern) ableiten können. Die Quellen können homogene oder heterogene Typen von Quellen (z.B. mehrere Eingänge von mehreren Instanzen eines gemeinsamen Sensortyps oder von Instanzen mehrerer unterschiedlicher Sensortypen) sein. Ein Beispiel-Sensorfusionsmodul 236 kann eine direkte Fusion, indirekte Fusion anwenden, neben anderen Beispiel-Sensorfusionstechniken. Die Ausgabe der Sensorfusion kann in einigen Fällen als eine Eingabe (zusammen mit potenziell zusätzlichen Eingaben) einem anderen Modul des Fahrwahrnehmungssystems und/oder einem oder mehreren Maschinenlernmodellen in Verbindung mit der Bereitstellung autonomer Fahrfunktionalität oder anderer Funktionalität, wie in den hierin erörterten Beispiellösungen beschrieben, zugeführt werden.
  • Bei einigen Beispielen kann eine Wahrnehmungsmaschine 238 bereitgestellt sein, die als Eingaben die Ergebnisse von Inferenzen nehmen kann, die durch die Maschine für maschinelles Lernen 232 durchgeführt werden, und/oder verschiedene Sensordaten (z.B. 258), umfassend Daten, in einigen Fällen, von fremden Quellen und/oder dem Sensorfusionsmodul 236, zur Durchführung der Objekterkennung und/oder -verfolgung von detektierten Objekten, neben anderen Beispielfunktionen, die der autonomen Wahrnehmung der Umgebung entsprechen, auf die das Straßensystem 205 stößt (oder stoßen wird). Die Wahrnehmungsmaschine 238 kann die Objekterkennung aus Sensordateneingaben unter Verwendung von Deep Learning durchführen, wie z.B. durch ein oder mehrere Konvolutions-neuronale-Netzwerke und andere Maschinenlernmodelle 256. Die Objektverfolgung kann auch durchgeführt werden, um aus Sensordateneingaben autonom abzuschätzen, ob sich ein Objekt bewegt und wenn ja, entlang welcher Bahn. Beispielsweise kann, nachdem ein bestimmtes Objekt erkannt wurde, eine Wahrnehmungsmaschine 238 detektieren, wie sich das gegebene Objekt im Verhältnis zu dem Fahrzeug bewegt. Eine solche Funktionalität kann z.B. verwendet werden, um Objekte wie beispielsweise andere Fahrzeuge, Fußgänger, Wildtiere, Radfahrer etc. zu detektieren, die sich innerhalb einer Umgebung bewegen und die den Pfad des Fahrzeugs auf einer Straße beeinflussen können, neben anderen Beispielverwendungen.
  • Eine Lokalisierungsmaschine 240 kann bei einigen Implementierungen ebenfalls innerhalb des Fahrwahrnehmungssystems 210 umfasst sein. In einigen Fällen kann die Lokalisierungsmaschine 240 als eine Teilkomponente einer Wahrnehmungsmaschine 238 implementiert sein und Koordinaten oder andere Positionsinformationen (z.B. eine relative Distanz zwischen Objekten) für in der Umgebung detektierte Objekte identifizieren. Die Lokalisierungsmaschine 240 kann auch ein oder mehrere Maschinenlernmodelle 256 und die Sensorfusion (z.B. von LIDAR- und GPS-Daten etc.) nutzen, um eine Hohe-Konfidenz-Position des Fahrzeugs und den Raum, den es innerhalb eines gegebenen physischen Raums (oder Umgebung) einnimmt, zu bestimmen.
  • Ein Fahrwahrnehmungssystem (z.B. 210) kann ferner einen Pfadplaner 242 umfassen, der die Ergebnisse verschiedener anderer Module, wie z.B. der Datensammlung 234, der Sensorfusion 236, der Wahrnehmungsmaschine 238 und der Lokalisierungsmaschine (z.B. 240), unter anderem (z.B. Empfehlungsmaschine 244) nutzen kann, um einen Pfadplan und/oder Handlungsplan zu bestimmen, bei dem das Fahrwahrnehmungssystem 210 auf einem Fahrzeug implementiert ist, das durch Betätigungssteuerungen verwendet werden kann, um die Fahrfunktionalität des Fahrzeugs innerhalb einer Umgebung zu automatisieren. Im Falle einer Straßenrandeinheit kann ein Pfadplaner 242 Wahrnehmungen nutzen, die für verschiedene sich bewegende Objekte innerhalb einer Umgebung bestimmt wurden, und vorhersagen (z.B. basierend auf anderen innerhalb der Umgebung detektierten Objekten oder anderen bestimmten Straßenbedingungen (z.B. Wetter, Lichtverhältnisse etc.), wie sich ein bestimmtes Objekt (z.B. ein Fahrzeug, ein Fußgänger, ein Fahrrad etc.) in unmittelbarer Zukunft wahrscheinlich in der Umgebung verhalten und bewegen wird. So kann beispielsweise ein Pfadplaner 242 Sensordaten, andere Maschinenlernmodelle und Eingaben, die durch andere Module des Fahrwahrnehmungssystems 210 bereitgestellt sind, nutzen, um Wahrscheinlichkeiten verschiedener Ereignisse innerhalb einer Fahrumgebung zu bestimmen, um effektive Echtzeitpläne oder vorhergesagte Verhalten innerhalb der Umgebung zu bestimmen.
  • Wie oben erörtert, kann ein Straßensystem (z.B. 205) eine Vielzahl von Sensordaten (z.B. 258) nutzen, die durch verschiedene Sensoren, die auf dem und extern im Hinblick auf das Fahrzeug bereitgestellt sind, erzeugt werden. So kann ein Fahrzeug beispielsweise ein Array von Sensoren (z.B. 225) aufweisen, um verschiedene Informationen im Zusammenhang mit dem Äußeren des Fahrzeugs und der umgebenden Umgebung, dem Fahrzeugsystemstatus, Bedingungen innerhalb des Fahrzeugs und andere Informationen zu sammeln, die durch die Module des Fahrwahrnehmungssystems 210 des Fahrzeugs nutzbar sind. Solche Sensoren 225 können z.B. GPS- (global positioning) Sensoren, Licht- und Abstandsmessungs- (LIDAR-) Sensoren, zweidimensionale (2D-) Kameras, dreidimensionale (3D-) oder Stereokameras, akustische Sensoren, Inertiale-Messeinheit- (IMU-; inertial measurement unit) Sensoren, thermische Sensoren, Ultraschallsensoren, Biosensoren (z.B. Gesichtserkennung, Spracherkennung, Herzfrequenzsensoren, Körpertemperatursensoren, Emotionserkennungssensoren etc.), Radarsensoren, Wetter-Sensoren (nicht gezeigt), neben anderen Beispielsensoren, umfassen. Ähnliche Sensoren können in Stra-ßenrandeinheiten verwendet werden. Tatsächlich können Sensordaten 258 durch Sensoren erzeugt werden, die nicht integral mit dem Fahrzeug gekoppelt sind, umfassend Sensoren auf anderen Fahrzeugen (z.B. 115) (die durch Vehicle-to-Vehicle-Kommunikationen oder andere Techniken kommuniziert werden können), Sensoren an Boden-basierten oder Luftdrohnen, Sensoren von Benutzervorrichtungen (z.B. einem Smartphone oder Wearable), die durch menschliche Benutzer innerhalb oder außerhalb eines Fahrzeugs getragen werden, und Sensoren, die an anderen Straßenrandelementen befestigt oder mit diesen bereitgestellt sind, wie z.B. einer anderen Stra-ßenrandeinheit (z.B. 160), einem Straßenschild, einer Ampel, einer Straßenbeleuchtung etc. Sensordaten von solchen fremden Sensorbauelementen können direkt von den Sensorbauelementen an das Fahrzeug bereitgestellt sein oder durch Datenaggregationsvorrichtungen oder als Ergebnisse, die basierend auf diesen Sensoren durch andere Rechensysteme erzeugt werden, neben anderen Beispielimplementierungen, bereitgestellt sein.
  • Bei einigen Implementierungen kann ein autonomes Fahrzeug oder Straßenrandeinheit eine Schnittstelle zu anderen Rechensystemen bilden und die durch diese bereitgestellten Informationen und Dienste nutzen, um die Wahrnehmungsfunktionalität des Systems zu verbessern, zu ermöglichen oder anderweitig zu unterstützen. In einigen Fällen können einige autonome Fahrmerkmale (umfassend einige der hierin erörterten Beispiellösungen) durch Dienste, Rechenlogik, Maschinenlernmodelle, Daten oder andere Ressourcen von Rechensystemen außerhalb eines Fahrzeugs aktiviert werden. Wenn solche externen Systeme für ein Fahrzeug nicht verfügbar sind, kann es sein, dass diese Merkmale zumindest vorübergehend deaktiviert sind. Beispielsweise können externe Rechensysteme bereitgestellt und genutzt werden, die in Straßenrandeinheiten oder Fog-basierten Edge-Vorrichtungen, anderen (z.B. Höhere-Stufe-) Fahrzeugen (z.B. 115) und Cloud-basierten Systemen (z.B. durch verschiedene Netzwerke (z.B. 290) zugänglich) gehostet sind. Eine Straßenrandeinheit oder ein Cloud-basiertes System (oder ein anderes kooperierendes System, mit dem ein Fahrzeug (z.B. 115) interagiert, kann die gesamte oder einen Abschnitt der Logik umfassen, die typischerweise in einem beispielhaften fahrzeuginternen automatisierten Fahrsystem (z.B. umfassend das Fahrwahrnehmungssystem 210) implementiert ist, zusammen mit potenziell zusätzlicher Funktionalität und Logik. Beispielsweise kann ein Cloud-basiertes Rechensystem, die Straßenrandeinheit 140 oder ein anderes Rechensystem eine Maschine für maschinelles Lernen umfassen, die entweder eines oder beide von Modell-Training- und Inferenz-Maschine-Logik unterstützt. Beispielsweise können solche externen Systeme höherwertige Rechenressourcen und weiterentwickelte oder aktuelle Maschinenlernmodelle aufweisen, so dass diese Dienste bessere Ergebnisse bereitstellen können als das, was nativ auf dem automatisierten Fahrsystem eines Fahrzeugs erzeugt werden würde. Ein automatisiertes Fahrsystem kann sich beispielsweise auf das Maschinenlerntraining, die Maschinenlerninferenz und/oder Maschinenlernmodelle verlassen, die durch einen Cloud-basierten Dienst für bestimmte Aufgaben und die Handhabung bestimmter Szenarien bereitgestellt sind. In der Tat sollte darauf hingewiesen werden, dass eines oder mehrere der erörterten und als zu dem Fahrzeug gehörend dargestellten Module bei einigen Implementierungen alternativ oder redundant innerhalb eines Cloud-basierten, Fog-basierten oder anderen Rechensystems, das eine autonome Fahrumgebung unterstützt, bereitgestellt sein können.
  • Fortfahrend mit dem Beispiel von 2 kann ein Beispielsstraßensystem (z.B. 205) eine Fehlverhaltensdetektionsmaschine 215 umfassen, um Fälle zu detektieren, in denen Nachrichten, die durch andere Straßensysteme (z.B. von einem nahegelegenen Fahrzeug (z.B. 110, 115) oder einer Straßenrandeinheit (z.B. 160, 165) kommuniziert werden, möglicherweise kompromittiert wurden und denen durch das Straßensystem 205 nicht vertraut werden sollte und die dieses nicht verwenden sollte. Eine Beispiel-Fehlverhaltensdetektionsmaschine 215 kann verschiedene Komponenten umfassen, um verschiedene Modi der Fehlverhaltensdetektion zu ermöglichen. Beispielsweise kann eine Fehlverhaltensdetektionsmaschine 215 eine Nachrichtenanalysemaschine 220 mit einer Logik zum Abtasten von Nachrichten (z.B. V2x) umfassen, die von anderen Straßensystemen empfangen werden, um Inkonsistenzen mit entweder einem oder beiden von dem Format oder dem Inhalt der Nachrichten zu detektieren, die einen Fehler oder eine böswillige Absicht in den Nachrichten suggerieren. Die Nachrichtenanalysemaschine 220 kann beispielsweise Fälle detektieren, in denen derselbe Sender dasselbe Objekt zweimal sendet, Bereichs-Checks durchführen (z.B. zum Detektieren von Beschleunigung außerhalb vordefinierter Grenzen, plötzlichem Auftauchen/Teleportieren eines Objekts, wie in der grundlegenden Sicherheitsnachricht gemeldet, etc.). In diesem Sinne kann eine Nachrichtenanalysemaschine 220 potenzielles Fehlverhalten durch ein anderes Straßensystem allein aus dem Inhalt und/oder Format der empfangenen Nachricht detektieren. Dementsprechend können sogar Fahrzeuge ohne fahrzeuginterne Wahrnehmungssysteme eine Nachrichtenanalysemaschine umfassen und nutzen, um potenzielles Fehlverhalten unter Verwendung von V2X-Nachrichtenübermittlung zu detektieren.
  • Bei einigen Implementierungen kann eine Fehlverhaltensdetektionsmaschine 215 zusätzlich eine Nachrichtenvorhersagemaschine 222 umfassen, um potenzielles Fehlverhalten zu bestimmen, indem bestimmt wird, dass der Inhalt einer empfangenen Nachricht Informationen umfasst, die von in der Nachricht erwarteten Informationen abweichen (z.B. basierend auf Informationen, die in vorherigen Nachrichten von demselben (oder einem unterschiedlichen) Straßensystem umfasst sind). Beispielsweise kann die Nachrichtenvorhersagemaschine 222 ein oder mehrere Datenmodelle zur Modellierung des Verhaltens von Fahrzeugen und anderen Objekten, die sich innerhalb einer Fahrumgebung bewegen können, führen und nutzen. Die Nachrichtenvorhersagemaschine 222 kann zusätzlich Aufzeichnungen von zuvor empfangenen Nachrichten von verschiedenen anderen Straßensystemen speichern, die Objekte innerhalb einer Umgebung beschreiben. Basierend auf den zuvor empfangenen Nachrichten und dem Modell kann eine Beispiel-Nachrichtenvorhersagemaschine 222 Informationen vorhersagen (z.B. innerhalb eines Bereichs), die in einer nachfolgenden Nachricht von einem anderen oder demselben Straßensystem, die Position eines bestimmten Objekts beschreibend, umfasst sein sollen. Wenn eine nachfolgende Nachricht das bestimmte Objekt als eine Position oder Charakteristiken außerhalb des vorhergesagten Bereichs aufweisend beschreibt, kann die Nachrichtenvorhersagemaschine 222 bestimmen, dass ein Vorfall eines potenziellen Fehlverhaltens detektiert wurde, und kann Nachrichten von der Quelle der nachfolgenden Nachricht (und/oder der einen oder der mehreren vorhergehenden Nachrichten) weiterhin im Hinblick auf zusätzliche Anomalien überwachen. Beispielsweise kann ein bestimmtes Straßensystem, das einem entsprechenden Zertifikat oder Identifizierer zugeordnet ist, in einer Beobachtungsliste (watchlist) (z.B. 268) verfolgt werden, die die Straßensysteme identifiziert, von denen die detektierten anomalen Nachrichten stammten.
  • Eine Beispiel-Fehlverhaltensdetektionsmaschine 215 kann zusätzlich einen Überlappungsdetektor 224 umfassen, der die verschiedenen Objekte, die in empfangenen grundlegenden Sicherheitsnaschrichten (und anderen V2X-Nachrichten) detektiert und beschrieben werden, nachverfolgen kann. Genauer gesagt kann der Überlappungsdetektor 224 die Position eines Satzes von Objekten, wie in einer Umgebung gemeldet, verfolgen und eine Anomalie in einer empfangenen grundlegenden Sicherheitsnachricht bestimmen, die ein Objekt identifiziert, das Berichten zufolge mit einem anderen unterschiedlichen Objekt in demselben physischen Raum überlappt (z.B. identifiziert die Nachricht ein erstes Auto, das einen bestimmten Raum einnimmt, als einen Lastwagen, der in einer anderen Nachricht durch ein anderes Straßensystem gemeldet wird, neben anderen Beispielen). Solche Überlappungen können eine Fehlfunktion durch ein anderes Straßensystem anzeigen oder, böswilliger, einen versuchten Angriff, wie z.B. einen Host-Fahrzeug- Angriff.
  • An einem Straßensystem (z.B. 205) kann jedes Objekt, das durch das System (z.B. unter Verwendung des Fahrwahrnehmungssystems 210 und der Sensoren 225) detektiert wird und/oder als durch andere Straßensysteme detektiert gemeldet wird, unter Verwendung von entsprechenden Nachverfolgungsdaten 264 nachverfolgt werden. Solche Nachverfolgungsdaten können durch den Überlappungsdetektor 224 verwendet werden, um die verschiedenen Objekte zu verfolgen, die in grundlegenden Sicherheitsnachrichten, die an das Straßensystem 205 kommuniziert werden, gemeldet werden. Bei einigen Implementierungen können Nachverfolgungsdaten die Quelle der Informationen unterscheiden oder identifizieren, z.B. ob sie in einer Nachricht von einem anderen Straßensystem gemeldet wurden, unter Verwendung des Wahrnehmungssystems 210 des lokalen Systems detektiert wurden oder beides (wobei das lokale Fahrwahrnehmungssystem 210 die Gültigkeit einer grundlegenden Sicherheitsnachricht bestätigt, die Bedingungen entsprechend dem beschreibt, was unter Verwendung der lokalen Sensoren 225 beobachtet wird). In der Tat kann eine Fehlverhaltensdetektionsmaschine 215 in einem Straßensystem, umfassend Sensoren (z.B. 225) Wahrnehmungslogik (z.B. 210), auch eine Wahrnehmungsanalysemaschine 226 umfassen, die das Wahrnehmungssystem 210 des Straßensystems nutzt, um Objekte zu validieren, die durch andere Straßensysteme gemeldet werden (z.B. der Entitäten 110, 115, 160, 165 etc.). So kann beispielsweise eine grundlegende Sicherheitsnachricht von einem bestimmten externen Straßensystem die Anwesenheit oder Abwesenheit eines bestimmten Objekts innerhalb eines bestimmten Raums, beobachtbar unter Verwendung des lokalen Wahrnehmungssystems 210 eines Straßensystems 205, identifizieren. Die Wahrnehmungsanalysemaschine 226 kann detektieren, dass die Nachricht ein Objekt meldet, das mit einem anderen Objekt überlappt, das unter Verwendung des Fahrwahrnehmungssystems 210 detektiert wurde, oder ein Objekt, das einen Raum einnimmt, den das Fahrwahrnehmungssystem 210 als frei bestätigen kann, und die Nachricht basierend auf dieser Bestimmung als anomal kennzeichnen.
  • Wie oben eingeführt, wenn Nachrichten mit anomalem Inhalt detektiert werden, kann die Quelle der Nachrichten als potenziell kompromittiert oder böswillig gekennzeichnet werden. Eine Beobachtungsliste (verkörpert in den Beobachtungslistendaten 268) kann geführt werden, um andere Straßensysteme zu verfolgen, die das Straßensystem 205 (z.B. unter Verwendung lokaler Fehlverhaltensdetektionslogik (z.B. 220, 222, 224, 226)) als die Quelle einer verdächtigen Nachricht detektiert hat. Da möglicherweise nicht alle Anomalien böswillig sind und Anomalien stattdessen aus peripheren Fehlern in den Sensoren, der Wahrnehmungslogik und/oder den Kommunikationskanälen, die durch das Quellen-Straßensystem verwendet werden, resultieren können, in einigen Fällen das Senden einer einzelnen anomalen Sicherheitsnachricht nicht sofort eine Abhilfehandlung. Durch die Beobachtungsliste 268 können jedoch mehrere Instanzen von anomalen Daten, die von einem gegebenen Quellen-Straßensystem stammen, dazu führen, dass zukünftige Nachrichten von diesem Straßensystem nicht vertrauenswürdig sind. So können die Beobachtungslistendaten 268 beispielsweise schwarze Listen umfassen, die spezifische Straßensysteme identifizieren, die durch mehrere verdächtige Nachrichten als kompromittiert und nicht vertrauenswürdig befunden wurden. Dementsprechend kann ein Straßensystem 205 Informationen in Nachrichten ignorieren, die als von solchen auf einer schwarzen Liste stehenden Quellen stammend detektiert werden. Darüber hinaus kann eine Beispiel-Fehlverhaltensdetektionsmaschine 215 eine Fehlverhaltensberichterstattungsmaschine (z.B. 228) umfassen, um ein detektiertes Fehlverhalten an andere Straßensysteme zu melden (z.B. durch V2X-Nachrichten an benachbarte Straßenakteure (z.B. 110, 115, 160, 165) und/oder an Backend-Systeme (z.B. 250), wie z.B. Zertifikatsstellen, die für die Aufrechterhaltung von Zertifikaten verantwortlich sind, die Straßensystemen erteilt und durch Straßensysteme zur Authentifizierung ihrer Zuverlässigkeit verwendet werden.
  • Bei einigen Implementierungen kann eine Beispiel-Fehlverhaltensdetektionsmaschine 215 sowohl Berichte über detektierte anomale Nachrichten an andere Systeme senden als auch ähnliche Anomale-Nachrichten-Berichte (oder „Fehlverhaltensberichte“) von nahegelegenen Straßensystemen (z.B. auf 110, 115, 160, 165 etc.) unter Verwendung einer entsprechenden Fehlverhaltensdetektionslogik empfangen. Fälle von Fehlverhalten, die durch eine Sammlung von Straßensystemen detektiert werden, können an einzelnen Straßensystemen (z.B. in den Beobachtungslistendaten 268) und externen, administrativen Systemen (z.B. dem Fehlverhaltensstellensystem 250) verfolgt werden. Bei einigen Implementierungen kann eine Beispiel-Fehlverhaltensdetektionsmaschine 215 eine kollaborative Anomaliedetektionsmaschine 230 umfassen, die die gemeinsame Nutzung von Fehlverhaltensberichten zwischen Systemen erleichtern kann. Bei einigen Implementierungen, wenn die Anzahl der Fehlverhaltensberichte, die durch nahegelegene Systeme gemeldet werden, die anomales Verhalten durch ein bestimmtes Straßensystem identifizieren, eine Schwelle überschreitet (z.B. eine Anzahl oder Rate anomaler Identifizierungen eines bestimmten Objekts, eine Anzahl oder Rate von Sicherheitsnachrichten, die durch ein bestimmtes Straßensystem gesendet werden, die anomale Informationen umfassen, etc.). Tatsächlich kann die kollaborative Anomaliedetektionsmaschine 230 aus Nachrichten anderer Straßensysteme bestimmen, dass einer bestimmten von einem gegebenen Straßensystem empfangenen Nachricht nicht vertraut werden kann, selbst wenn die bestimmte Nachricht die erste ist, die von diesem System empfangen wurde und nicht durch das Fahrwahrnehmungssystem 210 des Straßensystems 205 verifiziert werden kann, neben anderen Beispielmerkmalen.
  • Während eine Fehlverhaltensdetektionsmaschine 215 eine lokale schwarze Liste von Straßensystemidentifizierem (z.B. Zertifikate) bestimmen kann, die nicht vertrauenswürdig sind (und ignoriert werden sollten), kann dies möglicherweise nicht verhindern, dass dieselben böswilligen Straßensysteme den Betrieb anderer Fahrzeuge und Straßenrandeinheiten durch die gemeinsame Nutzung verfälschter Sicherheitsnachrichten (z.B. V2X-BSMs) stören. Bei einigen Implementierungen können schwarze Listen auch zwischen Straßensystemen gemeinsam verwendet werden, um zu helfen, die Anwesenheit eines böswilligen Akteurs rundzusenden. So kann beispielsweise ein Straßensystem 205 mehrere schwarze Listen empfangen, die durch mehrere andere Straßensystemen gemeinsam genutzt werden, und sich wiederholende Straßensystemidentifizierer in den schwarzen Listen identifizieren. Bei einem Beispiel, wenn ein gegebener Straßensystemidentifizierer in einer Anzahl von gemeinsam verwendeten schwarzen Listen wiederholt wird, kann sich das Straßensystem 205 entscheiden, den Straßensystemidentifizierer zu einer lokalen Beobachtungsliste hinzuzufügen, die durch das Straßensystem geführt wird (selbst wenn dieses Straßensystem während des Betriebs nicht angetroffen wurde), neben anderen Beispielimplementierungen.
  • Bei einigen Implementierungen kann ein böswilliger Akteur durch die Berufung auf ein Fehlverhaltensstellensystem 250, wie z.B. ein System, das einer Regierungsbehörde, dem Gesetzesvollzug, dem Aussteller von Straßensystemzertifikaten etc. zugeordnet ist, dauerhafter unterdrückt werden. Wie in 2 dargestellt, kann ein Beispiel-Fehlverhaltensstellensystem 250 einen oder mehrere Datenprozessoren (z.B. 272), ein oder mehrere Speicherelemente (z.B. 274) und eine Logik, in Hardware und/oder Software implementiert, umfassen, um bei der Behebung eines Missbrauchs von V2X-Kommunikationssystemen und zugeordneten Zertifikaten zu helfen. Zum Beispiel kann ein Zertifikatsmanager 270 implementiert sein, um die Ausgabe und Informationen für Zertifikate zu managen, die durch verschiedene Straßensysteme verwendet werden sollen. Zertifikatsdaten 280 können geführt werden, die die Ausgabe von spezifischen Zertifikaten an spezifische Straßensysteme identifizieren. Die Zertifikatsdaten 280 können auch Informationen umfassen, die Probleme und gemeldetes Fehlverhalten, zugeordnet zu spezifischen Zertifikaten, beschreiben. Beispielsweise können Straßensysteme (z.B. 205), die mit einer Fehlverhaltensdetektionslogik (z.B. 215) ausgestattet sind, Fehlverhalten detektieren, umfassend Nachrichten, die einem bestimmten Zertifikat zugeordnet sind, und Fehlverhaltensberichte (z.B. 285) an entsprechende Stellen (z.B. eine Stelle, die das Fehlverhaltensstellensystem 250 regelt) senden, um diese Vorfälle an die Zertifikatsstellen zu melden. Bei einigen Implementierungen kann ein Zertifikatsmanager 270 eine Trust-Engine 275 umfassen, um die Einhaltung (durch Zertifikatsinhaber) verschiedener dem Zertifikat zugeordneter Regeln und Richtlinien zu bestimmen. Solche Richtlinien können die Basis von Algorithmen sein, die durch die Trust-Engine 275 angewendet werden, um zu bestimmen, ob das Vertrauen in ein bestimmtes Zertifikat widerrufen werden sollte, z.B. basierend auf wiederholtem Fehlverhalten, das durch verschiedene Straßensysteme durch entsprechende Fehlverhaltensberichte 285 gemeldet wird. Bei einigen Implementierungen kann eine Trust-Engine 275 verwendet werden, um zu bestimmen, dass ein bestimmtes Zertifikat durch einen böswilligen Akteur kompromittiert wurde (basierend auf wiederholten Fehlverhaltensberichten), und der Zertifikatsmanager kann das Zertifikat basierend auf dem bestimmten Fehlverhalten widerrufen oder annullieren. Bei einem Widerruf ist das Straßensystem, das das Zertifikat innehat, möglicherweise nicht in der Lage, mit anderen Straßensystemen in eine vertrauenswürdige Kommunikation zu treten (ohne ein gültiges Zertifikat zu besitzen), wodurch ein kompromittiertes Straßensystem isoliert und allgemein ignoriert wird (z.B. bis das Vertrauen wieder hergestellt und ein neues Zertifikat ausgegeben werden kann), neben anderen Beispielen.
  • Bezugnehmend auf 3 ist ein vereinfachtes Blockdiagramm 300 gezeigt, das Beispiel-Stufen des autonomen Fahrens darstellt, die in verschiedenen Fahrzeugen (z.B. durch ihre entsprechenden fahrzeuginternen Rechensysteme) unterstützt werden können. So kann z.B. ein Bereich von Stufen definiert werden (z.B. L0-L5 (405-435)), wobei Stufe 5 (L5) Fahrzeugen mit der höchsten Stufe der autonomen Fahrfunktionalität (z.B. volle Automatisierung) und Stufe 0 (L0) der niedrigsten Stufe der autonomen Fahrfunktionalität (z.B. keine Automatisierung) entspricht. Ein L5-Fahrzeug (z.B. 335) kann beispielsweise ein vollständig autonomes Rechensystem aufweisen, das in der Lage ist, in jedem Fahrszenario eine autonome Fahr-Performance bereitzustellen, die gleich zu der oder besser als die ist, die durch einen menschlichen Fahrer bereitgestellt werden würde, umfassend bei extremen Straßenbedingungen und extremem Wetter. Ein L4-Fahrzeug (z.B. 330) kann auch als vollständig autonom und in der Lage angesehen werden, sicherheitskritische Fahrfunktionen autonom auszuführen und Straßenbedingungen während einer gesamten Fahrt von einem Startort zu einem Zielort effektiv zu überwachen. L4-Fahrzeuge können sich von L5-Fahrzeugen dadurch unterscheiden, dass die autonomen Fähigkeiten eines L4 innerhalb der Grenzen des „operativen Entwurfsbereichs“ des Fahrzeugs definiert sind, der möglicherweise nicht alle Fahrszenarien umfasst. L3-Fahrzeuge (z.B. 320) stellen eine autonome Fahrfunktionalität bereit, um sicherheitskritische Funktionen in einem Satz von spezifischen Verkehrs- und Umgebungsbedingungen vollständig auf das Fahrzeug zu verlagern, erwarten aber dennoch das Engagement und die Verfügbarkeit von menschlichen Fahrern, um das Fahren in allen anderen Szenarien zu bewältigen. Dementsprechend können L3-Fahrzeuge Übergabeprotokolle 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 eine Fahrerassistenzfunktionalität bereit, die es dem Fahrer ermöglicht, sich gelegentlich von der physischen Bedienung 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 eine Fahrerassistenz von einer oder mehreren spezifischen Funktionen (z.B. Lenkung, Bremsen etc.) bereit, erfordern aber noch immer eine konstante Fahrersteuerung der meisten Funktionen des Fahrzeugs. L0-Fahrzeuge können als nicht autonom angesehen werden - der menschliche Fahrer steuert die gesamte Fahrfunktionalität des Fahrzeugs (obwohl solche Fahrzeuge dennoch passiv an autonomen Fahrumgebungen teilnehmen können, z.B. durch die Bereitstellung von Sensordaten an Fahrzeuge höherer Stufen, die Nutzung von Sensordaten zur Verbesserung von GPS- und Infotainment-Diensten innerhalb des Fahrzeugs etc.). Bei einigen Implementierungen kann ein einzelnes Fahrzeug den Betrieb auf mehreren autonomen Fahrstufen unterstützen. Ein Fahrer kann beispielsweise steuern und auswählen, welche unterstützte Stufe der Autonomie während einer gegebenen Fahrt verwendet wird (z.B. L4 oder eine niedrigere Stufe). In anderen Fällen kann ein Fahrzeug autonom zwischen Stufen toggeln, z.B. basierend auf Bedingungen, die die Straße oder das autonome Fahrsystem des Fahrzeugs beeinflussen. Zum Beispiel kann ein L5- oder L4-Fahrzeug als Antwort auf die Detektion, dass ein oder mehrere Sensoren kompromittiert wurden, zu einem niedrigeren Modus (z.B. L2 oder niedriger) wechseln, um einen menschlichen Passagier angesichts des Sensorproblems einzubeziehen, neben anderen Beispielen.
  • 4 ist ein vereinfachtes Blockdiagramm 400, das einen beispielhaften autonomen Fahrfluss darstellt, der in einigen autonomen Fahrsystemen implementiert werden kann. So kann beispielsweise ein autonomer Fahrfluss, der in einem autonomen (oder halbautonomen) Fahrzeug implementiert wird, eine Erfassungs- und Wahrnehmungsphase 405, eine Planungs- und Entscheidungsphase 410 und eine Steuerungs- und Handlungsphase 415 umfassen. Während einer Erfassungs- und Wahrnehmungsphase 405 werden Daten durch verschiedene Sensoren erzeugt und für die Nutzung durch das autonome Fahrsystem gesammelt. Die Datensammlung kann in einigen Fällen einen Datenfilterungs- und Empfangssensor aus externen Quellen umfassen. Diese Phase kann auch Sensorfusionsoperationen und Objekterkennung sowie andere Wahrnehmungsaufgaben, wie z.B. Lokalisierung, umfassen, 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 über die vorne liegende(n) Straßen(en) zu treffen und basierend auf diesen Vorhersagen einen Echtzeit-Pfadplan zu bestimmen. Eine Planungs- und Entscheidungsphase 410 kann zusätzlich ein Treffen von Entscheidungen in Bezug auf den Pfadplan als Antwort auf die Detektion von Hindernissen und anderen Ereignissen umfassen, um zu entscheiden, ob und welche Handlung zu ergreifen ist, um den bestimmten Pfad angesichts dieser Ereignisse sicher zu befahren. Basierend auf dem Pfadplan und Entscheidungen der Planungs- und Entscheidungsphase 410 kann eine Steuerungs- und Handlungsphase 415 diese Bestimmungen in Handlungen umsetzen, durch Aktuatoren zur Manipulation der Fahrsteuerungen, umfassend Lenkung, Beschleunigung und Bremsen, sowie sekundärer Steuerungen wie Blinker, Sensorreiniger, Scheibenwischer, Scheinwerfer etc. Dementsprechend, wie in 5 dargestellt, kann die allgemeine Funktion eines automatisierten Fahrsystems 505 die Eingaben eines oder mehrerer Sensorbauelemente 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 Performance des automatisierten Fahrens (z.B. Beschleunigung, Lenkung, Bremsen, Signalgebung etc.) zu realisieren, kann das automatisierte Fahrsystem 505 ein oder mehrere Ausgangssignale erzeugen, um die bestimmenden automatisierten Fahrhandlungen zu implementieren, und diese Signale an eine oder mehrere Fahrsteuerungen oder allgemeiner „Aktuatoren“ 510 senden, die dazu verwendet werden, das entsprechende Fahrzeug zur Durchführung dieser Fahrhandlungen zu veranlassen.
  • 6 ist ein vereinfachtes Blockdiagramm, das die Beispiel-Interaktion von Komponenten und Logik darstellt, die zur Implementierung eines fahrzeuginternen automatisierten Fahrsystems verwendet wird, gemäß einer Beispielimplementierung. Beispielsweise kann eine Vielzahl von Sensoren und Logik bereitgestellt werden, die Daten erzeugen können, die durch das automatisierte Fahrsystem verwendet werden können, wie z.B. inertiale Messeinheiten (IMUs) 605, O-dometrie-Logik 610, On-Board-Sensoren 615, GPS-Sensoren 616, Kartendaten 620, Wegpunktdaten und -logik (z.B. 625), Kameras (z.B. 630), LIDAR-Sensoren 631, Nahbereichs-Radarsensoren 633, Fernbereichs-Radarsensoren 634, Vorwärts-gerichtetes-Infrarot- (FLIR; forward-looking infrared) Sensor 632, neben anderen Beispielsensoren. Zusätzliche Informationen können aus fahrzeugexternen Quellen (z.B. durch ein Netzwerk, das Vehicle-to-Everything-(V2X) Kommunikationen (z.B. 635) erleichtert) oder von dem Benutzer des Fahrzeugs (z.B. Fahrziele (z.B. 640) oder andere Eingaben, bereitgestellt durch Passagiere innerhalb des Fahrzeugs (z.B. durch Mensch-Maschine-Schnittstellen (z.B. 652)) bereitgestellt werden. Einige dieser Eingaben können an eine Wahrnehmungsmaschine 238 bereitgestellt werden, die die Informationen, die in Sensordaten umfasst sind, die durch einen oder eine Kombination von Sensoren des Fahrzeugs (oder sogar externe (z.B. Straßenrand-) Sensoren) erzeugt werden, bewerten und eine Objektdetektion (z.B. um potenzielle Gefahren und Straßencharakteristiken zu identifizieren) durchführen, die Objekte klassifizieren (z.B. um zu bestimmen, ob sie Gefahren sind oder nicht) und Objekte verfolgen kann (z.B. um eine Bewegung der Objekte zu bestimmen und vorherzusagen und um festzustellen, ob oder wann die Objekte das Fahren des Fahrzeugs beeinflussen sollten).
  • Andere Sensoren und Logik (z.B. 616, 620, 625 etc.) 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. um die Geolokalisierung des Fahrzeugs sowie seine Position im Verhältnis zu bestimmten tatsächlichen oder erwarteten Gefahren zu verstehen etc.). Ergebnisse der Wahrnehmungsmaschine 230 und Lokalisierungsmaschine 240 können gemeinsam durch die Pfadplanungslogik 242 des automatisierten Fahrsystems genutzt werden, so dass das Fahrzeug selbsttätig auf ein gewünschtes Ergebnis hin navigiert, während es dies unmittelbarer in einer sicheren Weise tut. Bei einigen Implementierungen kann auch eine Fahrverhaltens-Planungslogik (z.B. 650) bereitgestellt werden, um Fahrziele (z.B. Ziele auf Systemebene oder benutzerdefinierte Ziele) zu berücksichtigen, um bestimmte Fahr- oder Benutzerkomforterwartungen (z.B. Geschwindigkeit, Komfort, Verkehrsvermeidung, Mautstraßenvermeidung, Priorisierung von landschaftlichen Routen oder Routen, die das Fahrzeug in der Nähe bestimmter Sehenswürdigkeiten oder Annehmlichkeiten halten, etc.) zu liefern. Die Ausgabe des Fahrverhaltens-Planungsmoduls 650 kann auch einer Pfadplanungsmaschine 242 zugeführt und durch diese bei der Bestimmung des für das Fahrzeug wünschenswertesten Pfades berücksichtigt werden.
  • Eine Pfadplanungsmaschine 242 kann über den Pfad entscheiden, den ein Fahrzeug nehmen soll, wobei eine Bewegungsplanungsmaschine 655 die Aufgabe hat, zu bestimmen, „wie“ dieser Pfad zu realisieren ist (z.B. durch die Fahrsteuerungslogik (z.B. 662) des Fahrzeugs. Die Fahrsteuerungslogik 662 kann auch den gegenwärtigen Zustand des Fahrzeugs berücksichtigen, wie unter Verwendung einer Fahrzeugzustandsschätzungsmaschine 660 bestimmt. Die Fahrzeugzustandsschätzungsmaschine 660 kann den gegenwärtigen Zustand des Fahrzeugs bestimmen (z.B. in welche Richtung(en) es sich aktuell bewegt, welche Geschwindigkeit es fährt, ob es beschleunigt oder langsamer wird (z.B. bremst) etc.), was bei der Bestimmung der zu betätigenden Fahrfunktionen des Fahrzeugs und der Art und Weise, wie dies zu tun ist (z.B. unter Verwendung der Fahrsteuerungslogik 662) berücksichtigt werden kann. Beispielsweise können einige der Sensoren (z.B. 605, 610, 615 etc.) als Eingaben für die Fahrzeugzustandsschätzungsmaschine 660 bereitgestellt werden und es können Zustandsinformationen erzeugt und an die Fahrsteuerungslogik 662 bereitgestellt werden, was berücksichtigt werden kann, zusammen mit Bewegungsplanungsdaten (z.B. von der Bewegungsplanungsmaschine 655), um die verschiedenen Aktuatoren des Fahrzeugs zu steuern, um den gewünschten Pfad der Reise genau, sicher und komfortabel (z.B. durch Betätigen der Lenkungssteuerungen (z.B. 665), der Drosselklappe (z.B. 670), der Bremse (z.B. 675), der Fahrzeugkörpersteuerungen (z.B. 680) etc.) zu implementieren, neben anderen Beispielen.
  • Um die Performance des automatisierten Fahrsystems und seiner kollektiven Komponenten zu bewerten, können bei einigen Implementierungen auch ein oder mehrere Systemmanagementwerkzeuge (z.B. 685) bereitgestellt werden. Die Systemmanagementwerkzeuge 685 können beispielsweise eine Logik zum Detektieren und Protokollieren von Ereignissen und verschiedenen Daten umfassen, die durch das automatisierte Fahrsystem gesammelt und/oder erzeugt werden, zum Beispiel, um Trends zu detektieren, durch das automatisierte Fahrsystem verwendete Maschinenlernmodelle zu verbessern oder zu trainieren und potenzielle Sicherheitsprobleme oder Fehler zu identifizieren und zu beheben, neben anderen Beispielen. In der Tat können die Systemmanagementwerkzeuge 685 bei einigen Implementierungen Sicherheits-Teilsysteme oder Begleitwerkzeuge umfassen und können darüber hinaus Fehlerdetektions- und - behebungswerkzeuge umfassen, neben anderen Beispielwerkzeugen und damit verbundener Funktionalität. Bei einigen Implementierungen können die Systemmanagementwerkzeuge 685 zusätzlich eine Fehlverhaltensdetektionslogik umfassen, wie sie hierin erörtert wird. In einigen Fällen kann die Logik, die zur Implementierung des automatisierten Fahrsystems (z.B. Wahrnehmungsmaschine 238, Lokalisierungsmaschine 240, Fahrzeugzustandsschätzungsmaschine 660, Sensorfusionslogik, Maschinenlerninferenzmaschinen und Maschinenlernmodelle etc.) verwendet wird, zur Unterstützung oder zumindest teilweisen Implementierung von Systemmanagementwerkzeugen des Fahrzeugs verwendet werden, neben anderen Beispielanwendungen.
  • Bezugnehmend auf 7 ist ein vereinfachtes Diagramm 700 gezeigt, das verschiedene Typen von Fahrzeugen (z.B. 705, 710, 715, 720, 730, 735 etc.) innerhalb einer Straßenumgebung darstellt. Eine Vehicle-to-Vehicle-Kommunikation kann in einer Teilmenge dieser Fahrzeuge aktiviert werden. Für Fahrzeuge mit V2X-Kommunikationsfähigkeiten kann es vorteilhaft sein, auch eine Fehlverhaltensdetektionslogik zu implementieren, als eine Schutzmaßnahme gegen Anfälligkeiten, die durch V2X- (und V2V-) Kommunikationen eingeführt werden. Beispielsweise können Fahrzeugtypen verbundene Fahrzeuge (CVs) (z.B. 705, 735) umfassen, die zur V2V-Kommunikation fähig sind, die Daten von nahegelegenen Fahrzeugen empfangen und darauf reagieren können (z.B. handeln, indem sie dem Fahrer eine Warnung zeigen; ihre Stellung, Geschwindigkeit etc. mit benachbarten Fahrzeugen gemeinsam verwenden etc.). Verbundene autonome Fahrzeuge (CAVs) (z.B. 710, 720) sind ein anderer Fahrzeugtyp, der durch einige Sensoren (z.B. LiDAR) gegebene Wahrnehmungsfähigkeiten umfasst. CAVs können das Ergebnis ihrer Wahrnehmung mit irgendeinem anderen CV oder CAV gemeinsam verwenden, d.h. solche Fahrzeuge können nicht nur ihre Stellung, Geschwindigkeit etc., sondern auch Informationen über die Umgebung, wie sie diese wahrnehmen, gemeinsam verwenden. Unverbundene Fahrzeuge (UVs) (z.B. 715, 725) sind Fahrzeuge, die nicht zur V2V-Kommunikation fähig sind. UVs sind keine aktiven Teilnehmer des gemeinsam genutzten Wahrnehmungssystems, aber ihre bloße Existenz ist für die Sicherheit der Straße entscheidend. Beispielsweise können CAVs die Existenz und Charakteristiken von UVs innerhalb der Umgebung wahrnehmen und andere CAVs und CVs über V2V-Kommunikation als Teil der Implementierung einer gemeinsam genutzten Wahrnehmung zwischen den Fahrzeugen in der Umgebung informieren.
  • Eine Nachrichtenübermittlung zwischen Fahrzeugen (z.B. 740, 745, 750, 755) kann eine Vielzahl von Formen annehmen und irgendeines von verschiedenen Protokollen und Technologien nutzen, die zur Verwendung in Fahrumgebungen entwickelt, standardisiert und eingesetzt werden können. Beispielsweise können Nachrichten zwischen Fahrzeugen (sowie zwischen Fahrzeugen und Straßenrandeinheiten) gemäß einer regelmäßigen Frequenz oder basierend auf bestimmten Ereignissen gesendet werden. Bei einem Beispiel können durch ein Straßensystem erzeugte Kommunikationen periodisch und rundgesendet sein (z.B. CV und CAV senden alle 100 ms eine Nachricht). Beispielsweise kann ein Straßensystem in festen Zeitintervallen Nachrichten an jedes andere verbundene Straßensystem (z.B. CVs, CAVs, RSUs) innerhalb des Bereichs der Kommunikation senden. Auf diese Weise können Straßensysteme Informationen (z.B. Sicherheitsnachrichten, Fehlverhaltensnachrichten etc.) mit jedem ihrer One-Hop-Nachbarn gemeinsam nutzen. Zum Beispiel können grundlegende Sicherheitsnachrichten oder kooperative Bewusstseins-Nachrichten (hierin zusammenfassend als „Sicherheitsnachrichten“ bezeichnet) durch jedes Fahrzeug periodisch rundgesendet werden, typischerweise mit einer Frequenz zwischen 10Hz und 3Hz. Sicherheitsnachrichten können durch das intelligente Wahrnehmungs-/Nachverfolgungsmodul der autonomen Fahr-Pipeline (z.B. der ADAS-Pipeline) verbraucht und verschmolzen werden. Darüber hinaus kann durch V2X-Kommunikationen ein gemeinsam genutztes Wahrnehmungssystem verkörpert werden, z.B. wo beide verbundenen Straßensysteme Listen von Objekten gemeinsam verwenden, d.h. Beobachtungen über sich selbst und über beobachtete Hindernisse (wo das Straßensystem in der Lage ist).
  • Bezugnehmend auf 8 ist ein vereinfachtes Diagramm 800 gezeigt, das ein Beispiel für eine böswillige Handlung darstellt, die V2X-Kommunikationen nutzen kann, um die Steuerung eines Opferfahrzeugs missbräuchlich zu beeinflussen. Beispielsweise kann ein Gegner das Straßensystem eines Fahrzeugs (z.B. On-Board-Einheit (OBU; on-board unit)) kompromittieren oder Zugangsdaten von einem legitimen Fahrzeug stehlen, um V2X-Nachrichten, die falsche Informationen umfassen, zu erstellen und zu verteilen. Folglich können diese Nachrichten durch empfangende Straßensysteme als die kryptografischen Verifizierungen an dem Opfer-Fahrzeug oder Infrastrukturknoten (z.B. RSU) bestehend akzeptiert werden und die falschen Informationen können in potenziell sicherheitskritischen Anwendungen verwendet werden. Diese Art eines Angriffs kann potenziell schwerwiegende Folgen verursachen, z.B. wenn ein kompromittiertes Straßensystem (z.B. eine durch eine Malware infizierte OBU) die Werte ausgehender V2X-Nachrichten verändert. Zum Beispiel, wie bei dem Beispiel von 8 gezeigt, verwendet ein kompromittiertes Fahrzeug 805 V2V- (oder V2X-) Nachrichten (z.B. 810), um zu versuchen, Fehler durch mit dem Opfer verbundene Fahrzeuge (z.B. 815) zu induzieren. Beispielsweise kann das Straßensystem des kompromittierten Fahrzeugs falsche Informationen an nahegelegene Fahrzeuge rundsenden, was in diesem Fall ein Fahrzeug (z.B. 815) mit eingeschränkter Sichtlinie (z.B. durch die Anwesenheit eines anderen Fahrzeugs, wie z.B. des Sattelschleppers 825) nachteilig beeinflussen kann. Solche falschen Informationen (z.B. eine verfälschte Sicherheitsnachricht) können beispielsweise eine Beschreibung der falschen Position, Orientierung und Geschwindigkeit umfassen, die das Straßensystem eines empfangenden Fahrzeugs 815 zu der inkorrekten Annahme führen, dass sich das kompromittierte Fahrzeug in einer Weise verhält, in der es dies nicht tut (wie durch 820 dargestellt). Dies kann dazu führen, dass das Opferfahrzeug 815 sicherheitskritische Reaktionen triggert (z.B. als Antwort auf ein gefährliches Durchschneidemanöver 820, wie bei dem Beispiel von 8 dargestellt).
  • Wie oben eingeführt, kann ein verbessertes Fehlverhaltensdetektionssystem bereitgestellt werden und eine kollaborative Fehlverhaltensdetektion und -berichterstattung ermöglichen, um Fälle zu identifizieren und zu beheben, in denen böswillige Akteure eine V2X-Sicherheitsnachrichtenübermittlung kompromittieren. Bei einigen Implementierungen kann ein ausgerüstetes Straßensystem handeln, um sich falsch verhaltende Akteure zu detektieren und Fälle von Fehlverhalten zu melden, was den Widerruf solcher sich falsch verhaltender Akteure in verbundenen Fahrzeugsystemen triggern kann. Bei einigen Implementierungen können eines oder mehrere der Straßensysteme (z.B. Fahrzeuge oder RSUs) lokale Onboard-Erfassungsfähigkeiten nutzen, um eine Inkonsistenz in den durch ein gegebenes Fahrzeug gemeldeten V2X-Informationen im Hinblick auf die gemessenen Eigenschaften des angeblich übereinstimmenden Fahrzeugs zu detektieren (z.B. unter Verwendung von Sichtlinienerfassung mittels Kamera, Radar und/oder LiDAR-Sensoren oder anderer Verifizierungswerkzeuge). Die Inkonsistenz oder Anomalie kann dann an andere nahegelegene Fahrzeuge und/oder an ein Backend-Fehlverhaltensstellensystem in der Infrastruktur, wie z.B. das eine, das durch das Security Credential Management System (SCMS) oder andere Entitäten bereitgestellt wird, unter Verwendung einer Fehlverhaltensbericht- (MBR; Misbehavior Report) Nachricht, die durch das detektierende Straßensystem erzeugt wird, gemeldet werden. Solche Nachrichten können die in der anomalen Nachricht gemeldeten Daten sowie die durch das meldende Fahrzeug erfassten Eigenschaften des Fahrzeugs als Beweis für eine Inkonsistenz umfassen. Ein Fehlverhaltensstellensystem kann solche Fehlverhaltensberichte sammeln und zusammenhängende Berichte verschmelzen, um eine Entscheidung über den Widerruf des Fahrzeugs zu treffen.
  • In traditionellen Systemen, wie in Diagramm 900a von 9 dargestellt, wird ein umfangreicher angreifbarer Raum für die Ausnutzung durch potenzielle böswillige Akteure zur Verfügung gestellt (z.B. um ein Geisterauto durch falsche V2X-Sicherheitsnachrichten in eine Sybil-Attacke einzuführen. Traditionelle Systeme konzentrieren sich möglicherweise vollständig darauf, ob die V2X-Nachricht Inkonsistenzen umfasst, wodurch die Fahrzeuge anfälliger für solche Angriffe werden können. Ein verbessertes On-Board-Sicherheitssystem, wie es hierin beschrieben wird, das eine Fehlverhaltensdetektionsmaschine implementiert, um unrechtmäßige V2X-Sicherheitsnachrichten zu detektieren, kann den Bereich, der dem Angreifer zur Verfügung steht, um potenziell ein Geisterfahrzeug zu injizieren, durch die Verwendung von Wahrnehmungssystemen, die zumindest in einigen der Fahrzeuge verfügbar sind, reduzieren, wie in Diagramm 900b gezeigt. Tatsächlich kann die Abwesenheit eines Geisterfahrzeugs durch irgendeines der verbundenen Fahrzeuge (oder RSUs), die ein Wahrnehmungslogik aufweisen, detektiert werden, sobald das angebliche Fahrzeug in den Erfassungsbereich (z.B. 905) eines der Fahrzeuge (z.B. 910) eintritt, wodurch die Inkonsistenz zwischen Realität und Informationen innerhalb der verdächtigen Nachricht detektiert und gemeldet werden kann.
  • Wie oben eingeführt, können bei einigen Implementierungen Fehlverhaltensdetektionssysteme die Objektnachverfolgung (z.B. verkörpert in Nachverfolgungsdaten) nutzen, um Inkonsistenzen in empfangenen V2X-Sicherheitsnachrichten zu identifizieren. Bei einem Beispiel können V2X-Sicherheitsnachrichten periodisch rundgesendet werden (z.B. mit einer Periodizität von z.B. 10 Hz) und zumindest die Position, die Richtung, die Geschwindigkeit und die Größe (z.B. Breite und Länge) des Senderfahrzeugs umfassen. Eine Nachricht zi kann eine V2X-Nachricht repräsentieren, die Informationen über ein Fahrzeug i (z.B. 1005) trägt, wie in den vereinfachten Diagrammen 1000a-c, die das Beispiel von 10 darstellen, dargestellt. Bei diesem Beispiel wird zur Veranschaulichung die Perspektive eines Fahrzeugs j (z.B. 1010), das das Fahrzeug i 1005 beobachtet, erörtert. Es sollte darauf hingewiesen werden, dass es ähnliche Beispiele gibt, z.B. mit Fahrzeug i, das Fahrzeug j beobachtet, einer Straßenrandeinheit, die eines (oder beide) der Fahrzeuge i und j beobachtet, neben anderen Fahrzeugen und Beispielen. Beispielsweise kann eine RSU Kamera- oder LIDAR-Feeds von mehreren Überwachungskameras oder LIDARs aggregieren, um eine Vogelperspektive auf den Bereich zu erhalten und dadurch eine Objektverfolgung und Inkonsistenzdetektion unter Verwendung ihres Straßensystems durchzuführen, wie bei den Beispielen hierin beschrieben. Eine Beispiel-RSU kann in der Tat die Fähigkeit aufweisen, viel mehr Sensoren (z.B. Kameras oder LIDARs) entlang eines Abschnitts einer Straße oder einer Kreuzung mit mehr Freiheitsgraden im Hinblick auf die Platzierungspositionen und damit potenziell einer besseren Reichweite und einem besseren Sichtfeld) zu aggregieren, was für ein einzelnes Fahrzeug schwierig zu bewerkstelligen ist. Eine Infrastruktureinheit, wie z.B. eine RSU, kann auch leistungsfähigere Rechenressourcen aufweisen als ein einzelnes Fahrzeug, neben anderen Beispielmerkmalen. In der Tat können Fahrzeuge und RSUs (oder andere Infrastruktureinheiten) miteinander kooperieren, um gleichzeitig eine Fehlverhaltensdetektion durchzuführen und die Qualität der Ergebnisse zu verbessern und eine bessere Redundanz und Systemrobustheit zu erreichen.
  • Innerhalb des Kontexts des darstellenden Beispiels von 10 ist ein erstes Fahrzeug (z.B. Fahrzeug i 1005) in der „Sichtlinie“ eines anderen, zweiten Fahrzeugs (z.B. Fahrzeug j 1010), wenn das zweite Fahrzeug das erste Fahrzeug unter Verwendung seiner eigenen lokalen Sensoren erfassen (und somit verfolgen) kann. Andererseits ist ein erstes Fahrzeug im Hinblick auf das zweite Fahrzeug „nur V2X“, wenn das zweite Fahrzeug keine Sichtlinie mit dem ersten Fahrzeug aufweist, aber V2X-Nachrichten von dem ersten Fahrzeug (oder einem anderen Fahrzeug, das Nachrichten sendet, die die Anwesenheit des ersten Fahrzeugs melden) empfangen kann. Anders ausgedrückt, ein Fahrzeug ist nur V2X im Hinblick auf ein anderes, wenn die einzige Informationsquelle zu diesem Fahrzeug durch eine V2X-Nachricht (z.B. Sicherheitsnachricht) ist, die Attribute des Fahrzeugs beschreibt. Die Konsequenz daraus ist, dass, wenn ein erstes Fahrzeug in der Sichtlinie eines zweiten Fahrzeugs ist, das erste Fahrzeug im Hinblick auf das zweite Fahrzeug nicht nur V2X ist.
  • In traditionellen Systemen können die Onboard-Sensoren ein Sichtfeld oder eine zuverlässige Sichtlinie realisieren, das/die eine kürzere Reichweite aufweist als V2X-Kommunikationen. In der Praxis kommen in der Tat volle oder teilweise Verdeckungen eines On-Board-Sensors aufgrund von Gebäuden, größeren Lastwagen und kurvenreichen Straßen, die in der realen Welt häufig vorkommen, zustande. Dementsprechend sind das Sichtfeld und der Bereich der Sensoren tendenziell eine Teilmenge des V2X-Kommunikationsbereichs. Ferner kann ein Fahrzeug i 1005 im Laufe der Zeit von einem Nur-V2X-Fahrzeug zu einem Fahrzeug in Sichtlinie und wieder zurück zu einem Nur-V2X-Fahrzeug im Hinblick auf ein anderes Fahrzeug j 1010 übergehen, wenn es auf das Fahrzeug j zufährt und dieses dann passiert, wie in 10 dargestellt. Zum Beispiel kann zu einer Zeit t = n, dargestellt in Diagramm 1000a, das Fahrzeug i 1005 aufgrund der Anwesenheit und Position des Lastwagens 1015 außerhalb der Sichtlinie des Fahrzeugs j 1010 sein. Zu der Zeit t = n+1, dargestellt im Diagramm 1000b, kann das Fahrzeug i 1005 beschleunigt und den Lastwagen 1015 überholt haben, wodurch das Fahrzeug i 1005 in die Sichtlinie der Sensoren des Fahrzeugs j 1010 gebracht wird. Die Positionen der Fahrzeuge 1005, 1010, 1015 können sich dynamisch ändern, da jedes Fahrzeug innerhalb der Umgebung fährt, was dazu führen kann, dass Fahrzeug i 1005 wieder aus der Sichtlinie von Fahrzeug j 1010 herausfällt, wie in Diagramm 1000c dargestellt, und so weiter.
  • Bei einigen Implementierungen können Fahrzeuge in der Lage sein, ein Detektieren und Nachverfolgen von sich bewegenden Objekten (DATMO; Detection and Tracking of Moving Objects) durchzuführen, um nahegelegene Fahrzeuge, die sie in ihrer LOS haben, zu verfolgen und ihre Position, Geschwindigkeit, Richtung und Größe abzuschätzen. V2X-Nachrichten (z.B. Sicherheitsnachrichten) können als zusätzliche Informationsquelle zur Verwendung zur Verfolgung anderer Fahrzeuge im Laufe der Zeit dienen. Tatsächlich können Informationen, die durch V2X für ein bestimmtes Objekt (z.B. ein anderes Fahrzeug) erhalten werden, mit den Informationen, die durch direkte Wahrnehmung (z.B. unter Verwendung von Kamera, LiDAR oder anderen Systemen zusammen mit On-Board-Wahrnehmungslogik) erhalten werden, verschmolzen werden. Informationen, die für ein Objekt aus V2X-Nachrichten und/oder Wahrnehmung ausfindig gemacht werden, können in Objektnachverfolgungen aufgezeichnet werden, die in den Nachverfolgungsdaten eines entsprechenden Straßensystems geführt werden. Die Nachverfolgungen (engl. tracks) können eine Liste von Objekten beschreiben, die durch das Straßensystem im Laufe der Zeit durch Wahrnehmung oder V2X-Berichterstattung identifiziert wurden. Bei einem Beispiel können Objektnachverfolgungen als drei Typen von Nachverfolgungen implementiert werden: Nur-V2X-Nachverfolgungen (VT; V2X-only Tracks), die Nur-V2X-Objektdaten (z.B. BSMs) führen, wenn die Nachricht ein Objekt außerhalb der Sichtlinie des Systems beschreibt; Nur-LOS-Nachverfolgungs- (LT; LOS-only Track) Daten, die Informationen verfolgen, die für ein Objekt unter Verwendung der Sensoren und Wahrnehmungslogik des Straßensystems erzeugt wurden (aber für die keine V2X-Nachrichten für das Objekt empfangen wurden (oder wenn das Straßensystem eine solche Nachrichtenübermittlung nicht unterstützt); und Gemischte-Nachverfolgung- (MT; Mixed Track) Daten für Objekte, für die beide Informationen aus einer Kombination von sowohl V2X-Nachrichten als auch Fahrzeugsensoren erhalten werden. In anderen Fällen können Nachverfolgungen für jedes Objekt, auf das ein Straßensystem trifft (z.B. innerhalb eines Zeitfensters), geführt werden, und die entsprechenden Nachverfolgungsdaten können Informationen, die durch Sensoren/Wahrnehmung gesammelt wurden, und Informationen, die aus empfangenen V2X-Nachrichten gesammelt wurden, identifizieren und zwischen diesen unterscheiden, neben anderen Beispielimplementierungen.
  • Objektnachverfolgungen können durch ein Fehlverhaltensdetektionssystem verwendet werden, um Inkonsistenzen in nachfolgenden V2X-Nachrichten zu detektieren, umfassend Informationen, die das verfolgte Objekt beschreiben. Beispielsweise kann ein Geisterfahrzeug unter Verwendung von Nachverfolgungsdaten detektiert werden. Zum Beispiel kann Fahrzeug i ein Geisterfahrzeug (GV; Ghost Vehicle) für ein Fahrzeug j, GVj (i,t), sein, wenn Fahrzeug j eine Inkonsistenz zwischen dem Wissen von Fahrzeug j über Fahrzeug i und der Umgebung von Fahrzeug j detektiert. Bei einem Beispiel können Informationen, die innerhalb einer Beispiel-V2X-Sicherheitsnachricht gemeldet werden, die Position des sendenden Fahrzeugs innerhalb eines Bereichs platzieren, der durch die Sensoren des empfangenden Fahrzeugs als frei detektiert (und in den entsprechenden Nachverfolgungsdaten aufgezeichnet) wird. Infolgedessen kann das Straßensystem des empfangenden Fahrzeugs eine Anomalie oder Inkonsistenz innerhalb des Inhalts der empfangenen Nachricht bestimmen. Die Inkonsistenz (und das für die Inkonsistenz verantwortliche Straßensystem) kann dann verfolgt werden (z.B. unter Verwendung einer Beobachtungsliste), um wiederholte Fälle derselben (oder unterschiedlicher) Inkonsistenzen in durch den Sender gesendeten Nachrichten zu bestimmen. Es können Abhilfehandlungen ergriffen werden, umfassend eine Nachrichtenübermittlung an ein Fehlverhaltensstellensystem, das potenziell die Kommunikationsprivilegien des Quellen-Systems basierend auf Fehlverhaltensberichtnachrichten, die die Inkonsistenzen melden, widerrufen kann, neben anderen Beispielimplementierungen.
  • Bezugnehmend auf das Flussdiagramm 1100 von 11, wird ein Mehrschicht-Fehlverhaltensdetektionsansatz skizziert. Wie in 2 eingeführt, können einige Implementierungen eines Straßensystems eine Fehlverhaltensdetektionsmaschine umfassen, die in der Lage ist, Anomalien oder Inkonsistenzen in V2X-Sicherheitsnachrichten zu detektieren. Darüber hinaus kann eine V2X-Nachrichtenübermittlung selbst genutzt werden, um eine kollaborative Fehlverhaltensdetektion, -verhinderung und -behebung zu ermöglichen. Ein Beispiel-Fehlverhaltensdetektionssystem kann beispielsweise sowohl eine lokale Anomalie-Detektionslogik umfassen, die es Fahrzeugen ermöglicht, Anomalien (und damit Fehlverhalten) in den V2X-Daten autonom zu detektieren, als auch eine kollaborative Detektionslogik, bei der Fahrzeuge lokal detektierte Anomalien innerhalb von Fehlverhaltensberichten (MRs; misbehavior reports) melden, die an ihre Nachbarn rundgesendet werden. Empfangene Fehlverhaltensberichte können dann verwendet werden, um lokal Entscheidungen über das potenzielle Fehlverhalten eines sendenden Fahrzeugs zu treffen.
  • Das Beispiel von 11 ist ein Diagramm 1100, das den Ablauf einer Beispiel-Fehlverhaltensdetektionsmaschine eines Straßensystems darstellt, der mehrere Stufen der Fehlverhaltensdetektion umfasst. Beispielsweise kann eine V2X-Nachricht 1105 (z.B. Sicherheitsnachricht) empfangen und zuerst durch eine Nachrichtenanalysemaschine 220 verarbeitet werden, was eine Anomaliedetektion auf Nachrichtenebene bereitstellt. Die Nachrichtenanalysemaschine 220 kann die Nachricht 1105 parsen, um Anomalien in den in der Nachricht 1105 gemeldeten Objekten auf einer Pro-Nachricht-Ebene zu detektieren, z.B. durch eine Durchführung von einfachen Bereichs-Checks (z.B. Beschleunigung außerhalb vordefinierter Grenzen, plötzliches Auftauchen/Teleportieren eines Objekts etc.) und Identifizierung von Fällen, in denen dasselbe Objekt redundant identifiziert wird etc. Die Nachricht 1105 kann geparst werden, um die einzelnen Objekte 1110 zu identifizieren, die durch den Sender der Nachricht 1105 identifiziert wurden. Die in von entfernten Sendern empfangenen Nachrichten identifizierten Objekte können akkumuliert 1115 und in einem Puffer (z.B. 1120) gehalten werden, der weiterhin die durch sendende Straßensysteme (z.B. verbundene Fahrzeuge und RSUs) in einer Umgebung gemeldeten Objekte (und Objektattribute) auf einer Sender-zu-Sender-Basis identifiziert. Bei einigen Implementierungen können Nachverfolgungsdaten (z.B. VT-, LT-, MT-Nachverfolgungen) zur Pufferung und Verfolgung von Objekten verwendet werden, die durch verschiedene Sender identifiziert wurden.
  • Fortfahrend mit dem Beispiel von 11 können Nachverfolgungsdaten (z.B. in 1120) durch zusätzliche Fehlverhaltensdetektionsstufen, wie z.B. Stufen, die durch eine Nachrichtenvorhersagemaschine 222 erleichtert werden, und Überlappungsdetektor 224 genutzt werden. Beispielsweise kann eine Nachrichtenvorhersagemaschine 222 eine Modellebene-Anomaliedetektion durch ein Detektieren von Anomalien in der Entwicklung der durch irgendeinen einzelnen Sender bereitgestellten Informationen im Laufe der Zeit bereitstellen. So kann ein Modell beispielsweise den vorhergesagten Zustand eines Objekts nach Ablauf einer Zeitspanne (die z.B. der Zeit zwischen Nachrichten entspricht) basierend auf Informationen, die in den unmittelbar vorhergehenden Nachrichten, die durch den Sender gesendet wurden und das Objekt beschreiben, identifizieren und Anomalien basierend auf dem Rest zwischen dem vorhergesagten Zustand und den neuen Informationen, die für das Objekt in der Nachricht gemeldet wurden (z.B. 1105), bestimmen. Ein Überlappungsdetektor 224 kann Anomalien an einer höheren Ebene zwischen Objekten betrachten und nach Überlappungen, die auftreten können, suchen, die das Vorhandensein einer sich falsch verhaltenden Entität anzeigen können, die ein Geisterfahrzeug herstellt (das mit einem anderen realen Fahrzeug „überlappt“). Solche Überlappungen können aus den Nachverfolgungsinformationen, die durch das empfangende Straßensystem geführt und akkumuliert werden, detektiert werden. Bei einigen Implementierungen kann ein Straßensystem Zugriff auf lokale Sensoren und Sensordaten haben, die als Eingaben an ein Wahrnehmungssystem bereitgestellt werden können, das ein Detektieren, Erkennen und Nachverfolgen spezifischer Objekte in einer Fahrumgebung ermöglicht. Die lokal detektierten Objekte können gleichermaßen gespeichert und nachverfolgt werden (z.B. in einem Datenspeicher 1125). Ein Überlappungsdetektor 224 kann bei einer solchen Implementierung Informationen verwenden, die sowohl entfernt detektierte Objekte als auch lokal wahrgenommene Objekte beschreiben, um eine Systemebene-Anomaliedetektion durchzuführen.
  • Entfernt detektierte und gemeldete Objekte können an dem empfangenden Straßensystem weiterverarbeitet werden, um die Objektberichte auf der Grundlage von Zeit (bei 1130) auszurichten, die Objektberichte 1135 zu clustern (z.B. um Informationen aus Nachrichten, die von verschiedenen Sendern stammen, die dasselbe Objekt beschreiben, abzugleichen) und zeitausgerichtete Objektdaten für jedes gemeldete Objekt durch Cluster-Zusammenführung 1140 zu erstellen. Die aus V2X-Nachrichten (z.B. 1105) identifizierten geclusterten Objektinformationen können mit entsprechenden Informationen, die lokal durch die Straßensystem-Wahrnehmungslogik (bei 1145) detektierte Objekte beschreiben, zeitausgerichtet werden.
  • Bei einigen Implementierungen kann die lokale Wahrnehmungslogik eines Straßensystems effektiv mit jener von anderen, benachbarten Straßensystemen kombiniert werden, um ein gemeinsam genutztes Wahrnehmungssystem zu implementieren, bei dem verbundene autonome Fahrzeuge und sogar verbundene nicht autonome Fahrzeuge eine Liste von N + 1 wahrgenommenen Objekten gemeinsam nutzen können, wobei N Objekte die durch das Fahrzeug wahrgenommenen Objekte sind (z.B., falls fähig - im Fall von nicht autonomen, nicht wahrnehmbaren Fahrzeugen N = 0), wobei 1 Objekt das Senderfahrzeug selbst beschreibt. Beispielsweise kann ein Straßensystem eine Liste von Objekten 5 führen, die mit eingehenden V2X-Informationen aktualisiert wird. Nachdem eine neue Nachricht (z.B. 1105) von einem sendenden Fahrzeug empfangen wurde, dekodiert 1108 ein empfangendes Fahrzeug vr die darin umfasste Liste von Objekten 1110 und akkumuliert 1115 die gemeldeten Objekte für die Nachverfolgung (z.B. unter Verwendung eines Kalman-Filters). Nachrichten können bei einer bestimmten Kadenz empfangen werden, wobei das empfangende Straßensystem jedes der letzten Objekte (oder Daten, die die detektierten Objekte in einer Fahrumgebung beschreiben) von allen benachbarten Sendern abruft (z.B. bei 1108) und sie an dem letzten Zeitstempel ausrichtet 1130 (z.B. unter Verwendung einer gleichen oder ähnlichen Zeitreferenz, wie z.B. GPS-Zeit). In einigen Fällen kann die Zeitausrichtung 1130 gemäß einem Modell (z.B. einem Konstantgeschwindigkeitsmodell (constant velocity model)) durchgeführt werden, das zur Vorhersage des Zustands von Objekten in der Umgebung verwendet werden kann, für die die Längsposition eines Objekts zu einer Zeit t + Δt gegeben ist durch xt+Δt = xt + ẋtΔt. Nach der Ausrichtung 1130 werden Objekte von mehreren Sendern basierend auf einer Distanzmetrik (z.B. der Mahalanobis-Distanz, die die Distanz zwischen Objekten anzeigte, wenn diese als multivariate Gauß-Variablen dargestellt werden) geclustert 1135. Cluster werden dann zusammengeführt 1140, um eine Liste von zusammengeführten entfernten Objekten zu erstellen. Eine solche Liste wird dann zeitausgerichtet 1145 mit den aktuellen Systemobjekten (z.B. bei 1125), die unter Verwendung von Sensoren und Wahrnehmungslogik des empfangenden Straßensystems detektiert werden, z.B. unter Verwendung eines Assoziationsalgorithmus (z.B. Global Nearest Neighbor), der, wenn möglich, entfernte Objekte (bei 1120) auf lokale Objekte (bei 1125) abbildet 1150 (z.B. passende Objekte aus den beiden Mengen, die wahrscheinlich dieselbe physische Entität beschreiben). Übereinstimmende Paare von Objekten können zusammengeführt oder verschmolzen 1155 werden, während nicht übereinstimmende entfernte Objekte als neue Systemobjekte zur Verfolgung hinzugefügt werden. Bei einigen Implementierungen können Objekte, die für die Verfolgung von Daten hinzugefügt wurden, die lange Zeit nicht aktualisiert werden, gemäß einer gewissen Managementrichtlinie entfernt werden, neben anderem Beispielmerkmalen. Auf diese Weise können entfernt identifizierte Objekte den lokal wahrgenommenen Objekten zugeordnet werden, um Objektaufzeichnungen (z.B. Nachverfolgungen) zu entwickeln, die sowohl die entfernt identifizierten Objektinformationen (von potenziell mehreren Straßensystemen) mit den lokal wahrgenommenen Objektinformationen umfassen. Solche kollektiven Objektinformationen können durch eine Wahrnehmungsanalysemaschine 226 zum Durchführen einer Wahrnehmungsebeneanomaliedetektion genutzt werden. Die Wahrnehmungsanalysemaschine 226 kann beispielsweise Inkonsistenzen zwischen dem Raum, wie er durch die Fahrzeugsensoren wahrgenommen wird, und jene, die in V2X-Nachrichten (z.B. 1105) beschrieben sind, detektieren. Beispielsweise kann ein Geisterfahrzeug in einem Bereich vorhanden sein, den Sensoren als frei detektiert haben, was eine offensichtliche Inkonsistenz darstellt.
  • In irgendeiner (und potenziell mehreren) der Stufen (entsprechend 220, 222, 224, 226) kann eine Anomalie eine Fehlverhaltensentscheidungsfindungsmaschine 1165 detektiert und gemeldet 1160 werden. In einigen Fällen kann, basierend auf der Schwere einer Anomalie oder basierend auf wiederholten Anomalien, die einen bestimmten Sender oder ein bestimmtes Objekt umfassen, das Straßensystem eine Fehlverhaltensberichtnachricht erzeugen, zum Senden an andere nahegelegene Straßensysteme (z.B. andere Fahrzeuge oder RSUs) und/oder ein Backend-Fehlverhaltensstellensystem, neben anderen Beispielen. Wie bei dem Beispiel von 11 gezeigt, können empfangene V2X-Nachrichten (z.B. 1105) eigene Fehlverhaltensberichte umfassen, die auch durch die Fehlverhaltensentscheidungsfindungsmaschine 1160 berücksichtigt werden können und nach denen diese handeln kann, um zu verursachen, dass Berichte oder eine Abhilfehandlung durch das Straßensystem initiiert werden. Fehlverhaltensberichte können die Basis für eine kollaborative Fehlverhaltensdetektion und -behebung bilden. Eine Fehlverhaltensentscheidungsfindungsmaschine (z.B. 1160) verwendet eine lokale Anomaliedetektion als primäre Eingabe. Wenn keine Alarme getriggert wurden, besteht immer noch eine Möglichkeit, dass ein Angreifer einen Angriff plant (z.B. einen Geisterfahrzeugangriff, bei dem sich das Geisterfahrzeug außerhalb des Sichtfeldes der Sensoren des empfangenden Straßensystems befindet). Dementsprechend kann eine Fehlverhaltensdetektionsmaschine des Straßensystems auch Fehlverhaltensberichte berücksichtigen, die durch Peers gesendet wurden, um Fehlverhalten zu detektieren und zu reagieren. Wenn z.B. die Anzahl von Fehlverhaltensberichten, die für einen potenziell böswilligen Sender gesendet wurden, größer ist als die Redundanz des Objekts (z.B. die Anzahl von unabhängigen Quellen, die die Existenz dieses Fahrzeugs bestätigen), kann das empfangende Straßensystem die Eingabe von dem bestimmten sendenden System als böswillig betrachten und alle Objektinformationen, die von diesem Sender stammen, verwerfen (z.B. eine Löschung zugeordneter Informationen aus an dem empfangenden System geführten Nachverfolgungsdaten. In einigen Fällen kann ein Beweis für Fehlverhalten empfangen werden (z.B. in einem empfangenen Fehlverhaltensbericht von einem entfernten Straßensystem), aber der Beweis reicht nicht aus, um definitiv zu bestimmen, dass einem bestimmten Sender nicht vertraut werden sollte, das empfangende Straßensystem kann die empfangenen V2X-Objektinformationen (z.B. um eine Vorwärtskollision zu detektieren und eine Warnung auszugeben) weiterhin verwenden. In einigen Fällen kann ein Bericht über ein Fehlverhalten, umfassend ein Peer-System, das empfangende Straßensystem veranlassen, dieses System auf eine Beobachtungsliste zu setzen (z.B. um zu bestimmen, ob ein wiederholtes Fehlverhalten detektiert/gemeldet wird) und kann sogar Informationen von „Beobachtungslisten“ Systemen mit größerer Vorsicht (z.B. auf einer reduzierten Vertrauensebene) behandeln als Informationen von einem Sender, der nicht auf der Beobachtungsliste des empfangenden Systems ist, neben anderen Beispielen.
  • Bei einigen Implementierungen kann ein Ende-zu-Ende-Fehlverhaltensdetektions- und - Managementsystem unter Verwendung von Straßensystemen (auf Fahrzeugen und RSUs) und einem oder mehreren Backend-Fehlverhaltensstellensystemen implementiert werden. Ein Ende-zu-Ende-Fehlverhaltensmanagement kann Phasen von (1) lokaler Inkonsistenzdetektion und - berichterstattung und (2) Berichtverarbeitung und Entscheidungsfindungsauslösung umfassen. In der lokalen Inkonsistenzdetektions- und -berichterstattungsphase detektiert ein Fahrzeug oder eine lokale Infrastrukturentität eine Inkonsistenz zwischen den geführten Objektnachverfolgungen und einer oder mehreren empfangenen V2X-Nachrichten. Solche Inkonsistenzen können durch auf Fahrzeugen, RSUs, Drohnen implementierte Straßensysteme bestimmt werden, neben anderen Beispielen.
  • Bei einigen Implementierungen kann das Straßensystem eines empfangenden Fahrzeugs eine eingehende BSM verarbeiten. Das Straßensystem kann eine schwarze Liste von detektierten, sich falsch verhaltenden Sendern führen, gegen die es vor der Signaturverifizierung jede eingehende BSM abgleicht. Wenn die Sender-ID nicht in der schwarzen Liste ist, prüft der Empfänger, ob die ID einer der durch das Straßensystem geführten Objektnachverfolgungen entspricht. Beispielsweise kann das empfangende Straßensystem prüfen, ob die Sicherheitsnachricht auf ein Objekt verweist, für das es eine bekannte MT gibt (z.B. eine bekannte V2X + LOS-Nachverfolgung). Wenn dies der Fall ist, berechnet das empfangende Straßensystem eine statistische Distanz d=D( ,) zwischen den BSM-Daten und der Nachverfolgung, die ein Maß für die „Divergenz“ der V2X-Daten im Hinblick auf den erwarteten und gemessenen Wert gibt (z.B. basierend auf einer Wahrnehmung desselben Objekts durch das Straßensystem (z.B. unter Verwendung der Sensoren des entsprechenden Fahrzeugs). Bei einigen Implementierungen vergleicht das empfangende Straßensystem die berechnete Divergenz oder den Wert d mit einer vordefinierten Schwelle T. Wenn z.B. d > T ist und dies das erste Mal ist, dass die BSM von dem MT abweicht, berechnet der Empfänger eine Zeittoleranz δt, die der Menge an Zeit (oder der Anzahl von nachfolgenden Nachrichten) entspricht, in der die BSMs eines gegebenen Senders „anomal“ bleiben können (z.B. außerhalb der akzeptablen statistischen Distanz von der Bodenwahrheit (ground truth), die unter Verwendung von Sensoren und der Wahrnehmungslogik des Straßensystems bestimmt wurde). Wenn ein Satz von BSMs von einem Sender über eine definierte Anzahl von Nachrichten oder eine bestimmte Zeitspanne hinweg konsistent anomal ist, kann das Straßensystem bestimmen, dass diese Anomalien ein Fehlverhalten auf Seiten des Senders darstellen. Dementsprechend kann das Straßensystem verursachen, dass eine Fehlverhaltensberichtnachricht an andere Straßensysteme gesendet wird, die anderen Fahrzeugen, RSUs etc. zugeordnet sind. Darüber hinaus können größere „Abweichungen“ der BSM-Daten von existierenden Nachverfolgungswerten zu unmittelbareren und/oder schwerwiegenderen Folgen für die Sicherheit anderer Fahrzeuge führen. Je größer bei einigen Implementierungen die Abweichung d, desto kleiner das δt, das verwendet wird, um Fehlverhalten zu bestimmen, neben anderen Beispielen.
  • Veranschaulichend stellt 12 zwei Szenarien (in den Diagrammen 1200a, 1200b) dar, um zum Vergleich Beispiele für einen Unterschied in der Abweichung der Beschreibung eines Objekts durch eine Nachricht von dem, was durch ein bestimmtes Fahrzeug (z.B. 110) unter Verwendung des Wahrnehmungssystems des Fahrzeugs 110 beobachtet wird zu zeigen. Bei diesem Beispiel kann die Nachricht über einen drahtlosen Kommunikationskanal (z.B. als V2X-BSM) von dem Straßensystem eines anderen Fahrzeugs (z.B. 115) empfangen werden. Das bestimmte Fahrzeug 110 kann die Nachricht (unter Verwendung seines Straßensystems) verarbeiten, um zu bestimmen, dass eines oder mehrere der in der Nachricht identifizierten und beschriebenen Objekte nicht zu dem passen, was das Fahrzeug 110 unter Verwendung seiner eigenen Sensoren beobachtet. Die Nachricht kann zum Beispiel das Fahrzeug 115 selbst beschreiben. Bei dem Beispiel von Diagramm 1200a kann eine Nachricht 1205 von dem Fahrzeug 115 anzeigen, dass sich das Fahrzeug 115 leicht außerhalb der Spur 1210 bewegt. Das Empfängerfahrzeug 110 kann jedoch wahrnehmen, dass das Fahrzeug 115 stattdessen seinen Kurs innerhalb der Spur 1210 beibehält. Dementsprechend kann das Straßensystem des Fahrzeugs 110 eine Inkonsistenz oder Anomalie anzeigen. Bei diesem Beispiel kann das Straßensystem des Fahrzeugs 110 die Inkonsistenz als relativ geringe Divergenz von dem, was beobachtet oder erwartet wird, ansehen, anstatt das Fahrzeug 115 auf eine schwarze Liste zu setzen oder eine Fehlverhaltensnachricht zu senden, das Straßensystem des Fahrzeugs 115 auf eine Beobachtungsliste zu setzen (z.B. Identifizierung des Fahrzeugs 115 durch ein entsprechendes Zertifikat, das in der V2X-Kommunikation verwendet wird). Beispielsweise kann das Empfängerstraßensystem die Zeit oder die Anzahl der Nachrichten verfolgen, die seit der ersten Klassifizierung einer von dem Fahrzeug 115 empfangenen BSM als anormal vergangen sind, und fügt den Sender zu einer Beobachtungsliste hinzu.
  • Sowohl beim ersten Mal als auch bei den nachfolgenden Malen, bei denen die berechnete statistische Divergenz der Anomalie d > T ist, wenn die verstrichene Zeit größer als δt ist, kann das Empfänger-Straßensystem die BSM (und die damit verbundenen Daten, die in zugeordneten Nachverfolgungsdaten verfolgt werden) verwerfen, eine MBR-Nachricht ausgeben und den Identifizierer des Sendersystems zu der schwarzen Liste hinzufügen. Bei einigen Beispielen, wenn eine empfangene Nachricht als eine Anomalie umfassend detektiert wird, aber mit einer Divergenz von d < T, dann kann das Empfängerstraßensystem die Nachricht einfach verwerfen/ignorieren, und gleichzeitig das verdächtige System im Hinblick auf nachfolgende anomale MBRs weiter verfolgen. Bei diesem Beispiel, wenn eine anomale Nachricht für ein bestimmtes Objekt empfangen wird, das durch ein bestimmtes Straßensystem gemeldet wurde, kann (gegebenenfalls) die zugehörige Nachverfolgung von gemischt (MT) zu Nur-Sichtlinie (LT) geändert werden (da die aktuellsten Nachverfolgungsinformationen nur von dem Wahrnehmungssystem des Empfängerstraßensystems stammen), neben anderen Beispielen. Wenn ein verdächtiges Straßensystem basierend auf einer vorherigen anomalen Nachricht zu einer Beobachtungsliste hinzugefügt wurde, nachfolgende Nachrichten jedoch keine Inkonsistenzen oder Anomalien umfassen (z.B. wenn die ursprüngliche Anomalie ein Ausreißer war (z.B. aufgrund einer vorübergehenden Ungenauigkeit seines Lokalisierungsalgorithmus), kann das verdächtige Straßensystem von der Beobachtungsliste entfernt werden, und seine BSM-Daten können u.a. mit zugehörigen MT-Nachverfolgungsdaten verschmolzen werden, neben anderen Beispielen.
  • Fortfahrend mit dem Beispiel von 12, bei dem Beispiel von Diagramm 1200b, kann die von dem Fahrzeug 115 empfangene Nachricht (z.B. 1215) eine Bewegung des Fahrzeugs 115 von einer unterschiedlichen Spur (z.B. 1220) anzeigen, was anzeigt, dass etwas nicht Charakteristisches von der Spur 1220 vorhanden ist. Das Wahrnehmungssystem des empfangenden Straßensystems (des Fahrzeugs 110) kann jedoch wieder anzeigen, dass das Gegenstands-Objekt (Fahrzeug 115) sich tatsächlich innerhalb der Spur 1210 vorwärtsbewegt. Basierend auf einem Vergleich der Wahrnehmung des Empfängerstraßensystems des Fahrzeuges 115 (und seiner Position und Bewegung) kann eine Inkonsistenz innerhalb der Inhalte der Nachricht 1215 bestimmt werden. Zusätzlich kann ein Divergenzwert basierend auf dem Grad der Divergenz zwischen den Informationen in der Nachricht 1215 und der beobachteten Bodenwahrheit bestimmt werden. Bei diesem Beispiel, statt eine Divergenz d < T (z.B. wie in dem in Diagramm 1200a dargestellten Szenario) zu sein, kann das Empfängerstraßensystem eine Divergenz d > T bestimmen und statt den Sender 115 auf eine Beobachtungsliste zu setzen, sofort einen Fehlverhaltensbericht erstellen und senden, den Sender auf eine lokale schwarze Liste setzen, neben anderen Abhilfehandlungen, basierend auf der Schwere der Divergenz, neben anderen Beispielen (wie das Beispiel von 13, wo eine Nachricht (z.B. 1305) an das Fahrzeug 110 von einem böswilligen Akteur 1310 die Anwesenheit eines Geisterfahrzeugs (z.B. 1315) innerhalb eines freien Raums 1320 darstellt (z.B. zwischen den Fahrzeugen 110, 115, 1325), detektiert durch das Straßensystem des Fahrzeugs 110 etc.).
  • 14A-14B zeigen ein Flussdiagramm 1400 (fortgesetzt von 14A bis 14B), das die Beispielverarbeitung einer beispielhaften grundlegenden Sicherheitsnachricht von einem sendenden Straßensystem bei Empfang 1402 der Nachricht an einem Empfängerstraßensystem darstellt. Bei einem Beispiel kann das Empfängerstraßensystem (oder der „Empfänger““ zur Einfachheit der Beschreibung dieses Beispiels) bestimmen 1404, ob ein Identifizierer (z.B. Zertifikats-ID, Fahrzeug-ID etc.) auf einer lokalen Kopie einer schwarzen Liste (z.B. einer lokalen schwarzen Liste oder globalen schwarzen Liste) vorhanden ist. Wenn der Identifizierer des sendenden Straßensystems (oder in diesem Beispiel einfach „Sender“) auf einer schwarzen Liste steht, kann der Empfänger die Nachricht ohne weitere Verarbeitung einfach verwerfen 1406. Wenn der Sender jedoch nicht auf einer schwarzen Liste ist, kann der Empfänger ferner bestimmen 1408, ob ein Identifizierer des Senders in den Gemischte-Nachverfolgung-Daten umfasst ist (z.B. eine entsprechende MT-ID aufweist). Falls nicht, kann der Empfänger ferner bestimmen 1410, ob die ID des Senders irgendwelchen V2X-Nachverfolgungen (z.B. VT-IDs) entspricht. Wenn die Sender-ID einer bekannten VT entspricht, können die Informationen innerhalb der BSM mit einer entsprechenden VT verschmolzen 1411 werden. Wenn die Sender-ID vorhandenen MTs (oder VTs) nicht entspricht, kann der Empfänger Bereichs-Checks durchführen 1412 (z.B. Vergleich der mit der Position der BSM berechneten Distanz mit dem maximalen drahtlosen Bereich oder Prüfung, ob die BSM das Fahrzeug in einem fahrbaren Raum platziert), um die Gültigkeit der Nachricht (auf der Nachrichtenebene) zu bestimmen 1414. Wenn die Nachricht beispielsweise den einen oder die mehreren Bereichs-Checks nicht besteht, kann die Nachricht verworfen 1416 werden (z.B. und die Sender-ID zu einer lokalen schwarzen Liste hinzugefügt 1418 werden).
  • Wenn ein Bereichs-Check 1414 bestanden wird, können die BSM-Daten auf dem aktuellen Satz von LTs in der Systemnachverfolgungsliste unter Verwendung eines statistischen Distanzmaßes (z.B. der Mahalanobis-Distanz oder eines anderen Maßes für die statistische Divergenz zwischen dem, was durch den Empfänger wahrgenommen wurde) abgeglichen 1420 werden. Wenn die BSM mit einer existierenden LT (z.B. eine Nachverfolgung für ein Objekt, das unter Verwendung von Sichtlinien- (LOS) Sensoren detektiert wird) übereinstimmt (bei 1422), wird die ID der Nachverfolgung mit der ID des Senders aktualisiert 1424, und die BSM-Daten werden mit der vorhandenen Nachverfolgung verschmolzen 1426 (z.B. werden die LT-Daten als MT gekennzeichnet). Wenn die BSM nicht mit einer vorhandenen LT übereinstimmt (bei 1422), wird eine Konsistenzprüfung durchgeführt, um zu sehen, ob die Informationen der BSM mit Wahrnehmungsergebnissen des Empfängers übereinstimmen 1428, basierend auf den Bereichssensordaten des Empfängers, um zu bestimmen 1430, ob der Inhalt der BSM mit den Bereichssensoren des Empfängers in Konflikt steht oder nicht (z.B. wo ein Konflikt ein Geisterfahrzeug (GV) anzeigen kann). Wenn eine solche Anomalie bei 1430 detektiert wird (z.B. platzieren BSM-Daten ein Fahrzeug auf einem freien Platz, wie bei dem Beispiel von 13), kann die Nachricht verworfen 1416 werden, die Sender-ID wird zu einer lokalen schwarzen Liste hinzugefügt 1418 und eine Fehlverhaltensberichtnachricht 1432 kann erzeugt und an andere Systeme (z.B. benachbarte Fahrzeuge, Drohnen, RSUs etc. oder entfernte Systeme, wie z.B. ein Fehlverhaltensstellensystem) gesendet werden. Wenn andererseits die Informationen innerhalb der BSM mit den durch die Sensoren und das Wahrnehmungssystem des Empfängers bestimmten Informationen übereinstimmen (bei 1434) (z.B. innerhalb einer Toleranz), kann eine neue MT-Aufzeichnung erzeugt 1436 werden, die der BSM entspricht, und Informationen der BSM können in der Aufzeichnung dokumentiert werden. Falls nicht, kann eine neue VT auf ähnliche Weise erzeugt 1438 und mit Informationen aus der BSM (z.B. basierend auf der BSM, die zu einem Nichtsichtlinienbereich für den Empfänger gehört) gefüllt werden. Bei einigen Implementierungen können VTs periodisch mit LTs abgeglichen und möglicherweise zu MTs verschmolzen werden.
  • Wird ein Sender einer BSM als eine bekannte MT-ID (und ein entsprechendes MT aufweisend) bestimmt, kann die BSM mit den übereinstimmenden MT-Daten zeitausgerichtet 1440 werden und eine Divergenz d kann für die Informationen innerhalb der BSM bestimmt werden (z.B. im Vergleich mit vorhergehenden Informationen für das eine oder die mehreren gleichen Objekte, das/die in der BSM beschrieben ist/sind) und mit einer Schwelle T verglichen 1442 werden. Bei diesem Beispiel kann, wenn d < T ist, bestimmt werden, dass die Divergenz ignoriert werden kann, was den Empfänger veranlasst, zu bestimmen 1444, ob die ID des Senders in einer Beobachtungsliste verfolgt wird (z.B. basierend auf einer zuvor detektierten Anomalie in einer vorhergehenden Nachricht von dem Sender). Wenn der Sender in einer Beobachtungsliste ist, kann er von der Beobachtungsliste entfernt 1446 werden, bevor die Informationen innerhalb der BSM innerhalb der entsprechenden MT verschmolzen 1426 werden.
  • Andererseits, wenn d nicht weniger als die Schwelle T (bei 1442) ist, kann der Sender beobachtet werden, was ein Bestimmen 1448 umfassen kann, ob dies die erste (z.B. innerhalb einer Zeitperiode) Divergenz in einer von dem Sender empfangenen Nachricht beim Empfänger ist. Wenn dies der Fall ist, kann eine Zeittoleranz basierend auf der Divergenz berechnet 1450 werden (z.B. mit längeren Zeittoleranzen, die für weniger gravierende Divergenzen berechnet werden), die ID des Senders kann zu einer Beobachtungsliste hinzugefügt 1452 werden und die Zeit des Auftretens der anomalen BSM kann in der Beobachtungsliste aufgezeichnet 1454 werden (z.B. mit der Zeittoleranz zur Bestimmung des Ablaufs des Zeittoleranzfensters). Wenn die anomale BSM nicht das erste Auftreten ist, kann eine Zeittoleranz und Zeit der anfänglichen anomalen Nachricht bereits bestimmt sein, was ein Berechnen 1456 einer Zeit seit der ersten Divergenz durch den Empfänger erlaubt. Wenn die verstrichene Zeit größer ist als die durch die Zeittoleranz (bei 1458) festgelegte Schwelle, dann kann die letzte BSM, da die empfangene BSM weiterhin Inkonsistenzen oder Anomalien umfasst (z.B. selbst wenn die Distanz/Divergenz der letzten BSM geringer ist als die einer der vorhergehenden abweichenden BSMs von dem Sender ist), verworfen 1416 werden, was zum Senden einer Fehlverhaltensberichtnachricht (z.B. 1432) und/oder Hinzufügen des Senders zu einer schwarzen Liste (z.B. 1418) führt. Wenn die berechnete Zeitschwelle nicht verstrichen ist, kann der Sender auf der Beobachtungsliste bleiben (z.B. wenn eine nachfolgende BSM von dem Sender potenziell zum Bestimmen eines Fehlverhaltens führen kann) und die dem Sender zugeordnete MT kann in eine LT-Aufzeichnung (basierend auf den Fehlern in dieser V2X-BSM) umgewandelt 1460 werden und die BSM kann ignoriert (z.B. 1406) werden, ohne eine weitere Abhilfehandlung 1462.
  • Bei einigen Implementierungen eines Fehlverhaltensdetektionssystems eines Straßensystems behält jedes Straßensystem als Ergebnis des DATMO-Prozesses im Laufe der Zeit den folgenden Zustand für jedes nachverfolgte Objekt (oder jede Nachverfolgung) zu der Zeit t, bei: o i ( t ) ∼ N ( μ i ( t ) = [ x ( t ) , y ( t ) , x ˙ ( t ) , y ˙ ( t ) , w ( t ) , l ( t ) ] P i ( t ) ) ,   i = 1,2, … M ,
    Figure DE102020102426A1_0001
    wobei N eine (multivariate) Normalverteilung mit Mittelwert µ und Kovarianzmatrix P anzeigt, x, y die Position des Zentrums des Fahrzeugs im 2D-Koordinatensystem ist, ẋ, ẏ die Geschwindigkeit des Fahrzeugs entlang der zwei Achsen darstellen und w, l die Breite und Länge des Fahrzeugs sind. Zusätzlich kann jede Nachverfolgung eine zugeordnete ID idi aufweisen und kann als eine VT, MT oder LT gekennzeichnet sein. Dementsprechend ist bei einem Beispiel eine (signierte) BSM-Nachricht mi(t'), die zu einer Zeit t' durch ein Fahrzeug i gesendet wird, wie folgt definiert: m i ( t ' ) = { i d i , t ' , z i ( t ' ) = [ x i ( t ' ) , y i ( t ' ) , x ˙ i ( t ' ) , y ˙ i ( t ' ) , w i ( t ' ) , l i ( t ' ) ] } .
    Figure DE102020102426A1_0002
  • Ein Fahrzeug j, das mi(t') zu einer Zeit t empfängt, kann, nachdem überprüft wurde, dass idi nicht in der schwarzen Liste von j erscheint, versuchen, zi(t') mit jedem ok(t'), k = 1, 2, ..., M, nach ID, abzugleichen. In einigen Fällen stimmt idi mit einer vorhandenen MT überein. ok(t') soll eine solche Nachverfolgung sein. Die Nachverfolgung wird zuerst mit den BSM-Daten zeitausgerichtet (z.B. unter Verwendung eines Konstantgeschwindigkeitsmodells, um den Zustand der Nachverfolgung vorwärts in der Zeit vorauszusagen). Dann schätzt der Empfänger die Distanz von zi(t') von ok(t') basierend z.B. auf der Mahalanobis-Distanz. Wenn die Distanz geringer als eine vordefinierte Schwelle T ist, wird zi(t') mit ok(t') (z.B. unter Verwendung eines Kalman-Filters (KF)) verschmolzen. Die Mahalanobis-Distanz kann gemäß einer X2 Verteilung verteilen, und somit kann die Schwelle in Abhängigkeit von den Freiheitsgraden und dem intendierten Konfidenzintervall abgeleitet werden. Wenn beispielsweise die Divergenz/Distanz d größer ist als T und wenn dies das erste Mal ist, dass dies geschieht, bestimmt j die Anzahl von Zeitschritten δt, die abzuwarten sind, bevor der Sender als sich falsch verhaltend gemeldet wird. δt wird später verwendet, um zu bestimmen, gegeben n nachfolgende Zeitperioden mit inkonsistenten V2X-Daten, ob die Inkonsistenz unter Verwendung eines Fehlverhaltensberichts an eine Fehlverhaltensstelle gemeldet werden soll (z.B., wenn n > δt).
  • In anderen Fällen, stimmt idi nicht mit einer vorhandenen MT überein. Dementsprechend, wenn, in diesem Fall, idi mit einer vorhandenen VT übereinstimmt, wird die Nachverfolgung verschmolzen und der Algorithmus endet, andernfalls wird geprüft, ob zi(t') innerhalb des Funkbereichs von j ist: wenn nicht, wird die Nachricht verworfen und der Sender gemeldet, andernfalls sucht j nach einer übereinstimmenden LT durch Berechnung der Distanz von zi(t') von jeder LT. Im Falle einer Übereinstimmung, kann zi(t') mit der übereinstimmenden LT verschmolzen werden, die dann als MT gekennzeichnet wird, und ihr Identifizierer wird mit idi aktualisiert. Andernfalls wird zi(t') mit der Ausgabe des Bereichssensors abgeglichen (z.B. mit einer verarbeiteten Punktwolke oder einer Belegungsgitterabbildung, berechnet durch j). Als ein Beispiel, wenn die Bounding Box, die durch zi(t') beschrieben ist, signifikant mit einem Bereich überlappt, der durch den Belegungsgitterabbildungalgorithmus als frei bestimmt wurde (z.B. wenn der Bericht den Sender in einem Raum platziert, der durch die Bereichssensoren des Empfängers als frei detektiert wurde), kann eine Anomalie-Kennzeichnung ausgelöst werden und j kann eine MBR ausstellen. Wenn es keinen Konflikt zwischen Bereichssensoren und V2X-Daten gibt, kann eine neue VT initiiert werden.
  • Bei einigen Implementierungen, stimmt idi nicht mit einer vorhandenen MT überein. Dementsprechend, in diesem Fall, wenn idi mit einer vorhandenen VT übereinstimmt, wird die Nachverfolgung verschmolzen und der Algorithmus endet, andernfalls wird geprüft, ob zi(t') innerhalb des Funkbereichs von j ist: Wenn nicht, wird die Nachricht verworfen und der Sender gemeldet, andernfalls sucht j nach einer übereinstimmenden LT durch Berechnung der Distanz von zi(t') von jeder LT. Im Falle einer Übereinstimmung kann zi(t') mit der übereinstimmenden LT verschmolzen werden, die dann als MT gekennzeichnet wird, und ihr Identifizierer wird mit idi aktualisiert. Andernfalls wird zi(t') mit der Ausgabe des Bereichssensors abgeglichen (z.B. mit einer verarbeiteten Punktwolke oder einer Belegungsgitterabbildung, berechnet durch j). Als ein Beispiel, wenn die Bounding Box, die durch zi(t') beschrieben ist, signifikant mit einem Bereich überlappt, der durch den Belegungsgitterabbildungalgorithmus als frei bestimmt wurde (z.B. wenn der Bericht den Sender in einem Raum platziert, der durch die Bereichssensoren des Empfängers als frei detektiert wurde), kann eine Anomalie-Kennzeichnung ausgelöst werden und j kann eine MBR ausstellen. Wenn es keinen Konflikt zwischen Bereichssensoren und V2X-Daten gibt, kann eine neue VT initiiert werden.
  • Bezugnehmend auf das obige Beispiel können bei Implementierungen andere Darstellungen in den durch Fahrzeuge ausgetauschten Daten verwendet werden. Beispielsweise kann ein Fahrzeug seine Position (x,y), Richtung (θ) und Vorwärtsgeschwindigkeit (s) senden. Der Unterschied zwischen einer „Messungs“-Darstellung und der „Zustands“-Darstellung kann durch Filter gehandhabt werden, wie beispielsweise das KF, das unter Verwendung einer Übergangsmatrix H (lineare Transformation) oder Funktion h (nichtlineare Transformation), die eine Zustands- in eine Messungsdarstellung umwandelt, arbeitet, neben anderen Beispielen. In einigen Fällen kann die Nichtlinearität die Verwendung von Filtern erfordern, die die Nichtlinearität handhaben können, wie z.B. das Erweiterte KF (EKF; Extended KF) oder das Unscented KF (UKF), neben anderen Beispielen.
  • Bei einigen Implementierungen kann ein anderes Straßensystem während einer Berichtsverarbeitungs-, Entscheidungsfindungs- und Auslösephase als Antwort auf das Detektieren einer Fehlverhaltenshandlung, umfassend V2V- oder V2X-Nachrichtenübermittlung durch ein bestimmtes Straßensystem (z.B. auf einem Fahrzeug, einer Straßenrandeinheit, einer Drohne etc.), eine entsprechende Fehlverhaltensberichtnachricht (MRM; misbehavior report message) senden. Bei einigen Implementierungen können solche Fehlverhaltensberichtnachrichten durch eine Fehlverhaltensstelle an eine Backend-Verarbeitung gesendet oder weitergeleitet werden, die in einigen Fällen das Ermessen oder die Befugnis aufweisen kann, die Kommunikationszugangsdaten eines angreifenden Systems für ungültig zu erklären, herabzustufen oder anderweitig zu ändern. Bei einigen Implementierungen können für die Meldung von unmittelbar detektiertem Fehlverhalten an benachbarte Systeme andere Fehlverhaltensberichtnachrichten verwendet werden als sie für die Meldung detaillierterer Berichte über das Fehlverhalten (und Daten, die durch das lokale Straßensystem bei der Bestimmung von Zuordnungs-Fehlverhalten verwendet werden) an eine Backend-Fehlverhaltensstelle verwendet werden, da die Informationen in diesen Kontexten unterschiedlich genutzt werden. Beispielsweise können lokale Fehlverhaltensberichtnachrichten, die an benachbarte Fahrzeug- und RSU-Straßensysteme gesendet wurden, verwendet werden, um diese Fahrzeuge zu veranlassen, eine entsprechende System-ID zur sofortigen Verwendung durch das empfangende Straßensystem zu einer Beobachtungsliste oder schwarzen Liste hinzuzufügen. Andererseits kann eine Fehlverhaltensstelle Fehlverhaltensberichtnachrichten über eine Zeitperiode kompilieren, die in verschiedenen Zeitfenstern von verschiedenen Straßensystemen empfangen wurden, und die Inhalte von Fehlverhaltensberichtnachrichten, die sich auf ein angebliches Fehlverhalten durch ein bestimmtes Straßensystem beziehen, sorgfältiger analysieren, um zu bestimmen, ob die Kommunikationszugangsdaten (z.B. SCMS-Zertifikat) eines autonomen Fahrzeugs widerrufen werden sollten.
  • Bei einem Beispiel können Fehlverhaltensberichtnachrichten, die durch Fahrzeug- und RSU-Straßensysteme an ein Backend-Fehlverhaltensstellensystem gesendet werden, Informationen umfassen, um es der Fehlverhaltensstelle zu ermöglichen, die Genauigkeit und den Hintergrund hinter angeblichem, detektiertem Fehlverhalten zu beurteilen. Solche Fehlverhaltensberichtnachrichten können beispielsweise die Position des Meldenden (z.B. in GNSS-Koordinaten), eine Kopie der Nachricht(en) (z.B. grundlegende Sicherheitsnachricht), die Handlung des Fehlverhaltens darstellend, Daten, die (z.B. durch lokale Sensoren des berichtenden Systems) als Nachweis der Inkonsistenz (z.B. in Form einer Objektliste oder einer Belegungsgitterabbildung etc.) gesammelt wurden, umfassen, neben anderen Beispielinformationen. Eine Fehlverhaltensberichtnachricht kann mit den Zugangsdaten des berichtenden Straßensystems unterzeichnet werden, um die Authentizität der Fehlverhaltensberichtnachricht sicherzustellen (z.B. und eine böswillige Nutzung des Fehlverhaltensberichterstattungssystems zu mindern), neben anderen Beispielmerkmalen.
  • Bei einem Beispiel, wenn das Backend-Fehlverhaltensstellensystem einen Satz von Fehlverhaltensberichtnachrichten empfängt, kann die Fehlverhaltensstelle bestimmen, ob und welche Abhilfehandlungen zu initiieren sind. Bei einigen Implementierungen kann ein Backend-Fehlverhaltensstellensystem unterschiedliche Berichtnachrichten unterschiedlich gewichten, wenn die Bewertung der Vertrauenswürdigkeit des Straßensystems in den Fehlverhaltensberichtnachrichten bemängelt wird. Beispielsweise kann das Vertrauen oder die Qualität der Sichtweise des berichtenden Straßensystems bewertet werden, neben anderen Charakteristiken. Bei einer Implementierung kann das Fehlverhaltensstellensystem nach dem Empfang und der Identifizierung eines zugehörigen Satzes von Fehlverhaltensberichtnachrichten (z.B. Identifizierung desselben Straßensystems (z.B. durch die Zertifikats-ID)) eine Darstellung des Sichtfeldes jedes der berichtenden Fahrzeuge im Hinblick auf das Zielfahrzeug (oder das Fahrzeug, das auf einen potenziellen Zertifikatswiderruf untersucht werden soll) berechnen. Beispielsweise ist 15 ein Satz von Diagrammen 1500a-c, die eine Fahrumgebung zu der Zeit von zwei (oder mehr) berichteten Fehlverhalten darstellen, die durch jeweilige Straßensysteme auf den Fahrzeuge 105 und 110 gemessen und gemeldet werden, umfassend Fehlverhalten durch ein bestimmtes Straßensystem auf einem anderen Fahrzeug 115. Das Diagramm 1500a stellt im Allgemeinen die Fahrumgebung dar, in der das Fahrzeug 115 die Straße mit anderen Straßenakteuren gemeinsam verwendet, umfassend die Fahrzeuge 105, 110, 1505, 1510 etc.
  • Wie bei dem Beispiel von 15 gezeigt, waren einige Fahrzeuge möglicherweise sowohl physisch als auch im Hinblick auf die auf dem Fahrzeug verfügbaren Sensoren in einer besseren Position, um eine Sichtfelddarstellung bereitzustellen, die die Verhalten des Zielsystems (z.B. von Fahrzeug 115) besser erfasst. Das Diagramm 1500b stellt das Sichtfeld dar, das durch das Fahrzeug 105 erfasst wurde, das möglicherweise einen ersten Fehlverhaltensbericht an das Fehlverhaltensstellensystem gesendet hat, während das Diagramm 1500c das Sichtfeld darstellt, das durch ein anderes Fahrzeug 110 erfasst wurde, das ebenfalls ein Fehlverhalten des Fahrzeugs 115 meldet, neben anderen darstellenden Beispielen. Darstellungen des jeweiligen Sichtfeldes der berichtenden Fahrzeuge können umfasst oder von der einen oder den mehreren von den berichtenden Fahrzeugen empfangenden Fehlverhaltensberichtnachrichten abgeleitet werden (z.B. durch das Fehlverhaltensstellensystem). Die Sichtfeld- (FOV; field of view) Modelle können durch die MA verwendet werden, um die Anzahl der potenziellen Zeugen zu schätzen und daraus eine Mindestanzahl von zu erhaltenden Berichten nrmin abzuleiten, um eine Entscheidung für das Zielstraßensystem 115 zu treffen. Ferner kann das Fehlverhaltensstellensystem unter Verwendung von Informationen in den Fehlverhaltensberichtnachrichten ein Gewicht w berechnen, das die Zuverlässigkeit des Berichts beschreibt, zum Beispiel basierend auf dem geschätzten FOV-Modell. Als ein Beispiel können Gewichte gemäß der Persistenzwahrscheinlichkeit pp in einer Mehrere-Objekte-Nachverfolgungsanwendung berechnet werden. Zum Beispiel können bei dem Beispiel von 15 unterschiedliche Gewichte den jeweiligen Berichten von den Fahrzeugen 105 und 110 zugeordnet werden. Bei einem Beispiel, vorausgesetzt, dass das Fahrzeug 110 eine klarere Sicht des Zielfahrzeugs 115 aufweist, kann die von dem Fahrzeug 110 stammende Fehlverhaltensberichtnachricht als zuverlässiger angesehen werden als die von dem Fahrzeug 105 und kann ein relativ höheres Gewicht erhalten. Bei einigen Implementierungen kann das Fehlverhaltensstellensystem die Summe aller Gewichte berechnen, die für ein bestimmtes Zielsystem empfangene Berichte bestimmt wurden. Diese Werte können verwendet werden, um das Gewicht zu bestimmen, das irgendeinem der Fehlverhaltensberichte beigemessen werden sollte, oder der kombinierten Schwere einer Sammlung von Berichten. Bei einigen Implementierungen kann ein einzelner Fehlverhaltensbericht eine Abhilfehandlung durch die Fehlverhaltensstelle triggern, wenn das bestimmte Gewicht des Fehlverhaltensberichts über einem Schwellenwert ist.
  • In einigen Fällen kann der Widerruf des Zertifikats des Zielsystems die durch das Fehlverhaltensstellensystem bestimmte Abhilfe sein. Es können auch weniger Handlungen getriggert werden, wie z.B. eine Reduzierung eines dem Zielsystem zugeordneten Vertrauensniveaus, die Platzierung des Zertifikats des Zielsystems in einer Beobachtungsliste zur weiteren Beurteilung, neben anderen Beispielabhilfen. Bei einem Ausführungsbeispiel kann der Widerruf unter Verwendung einer Certificate Revocation List (CRL) durchgeführt werden, umfassend die Zielfahrzeug-ID darin, neben anderen Beispiel-Widerrufstechniken.
  • 16 ist ein vereinfachtes Blockdiagramm 1600, das ein Beispiel für eine Zertifikatsmanagementarchitektur darstellt, in der ein Fehlverhaltensstellensystem (z.B. 250) ein Teil sein kann. Beispielsweise kann eine Vielzahl von Akteuren und Systemen an der Implementierung des Zertifikatsmanagementsystems 1605 beteiligt sein (umfassend Richtlinie 1610 und technische 1615 Akteure und Teilsysteme). Einige Akteure können intrinsisch zentral im Hinblick auf das Zertifikatsmanagement verschiedener Straßensysteme (z.B. 1620, umfassend derer von Fahrzeugen (On-Board-Ausrüstung- (OBEs; on-board equipment) Implementierungen), Straßenrandeinheiten (z.B. Straßenrandausrüstung (RSEs; roadside equipment)), mobilen Vorrichtungen (z.B. Nachrüstsicherheitsvorrichtungen (ASDs; aftermarket safety devices)) etc. sein. Ein Richtliniengenerator 1625 kann Richtlinien für die Verwendung und das Management von Kommunikationszertifikaten an alle Mitglieder der Architektur 1605 weitergeben, umfassend Zertifizierungsdienste 1622, Anmelde-Zertifikatsstellen (CA; certificate authorities) 1624, Registrierungsstellen 1626 etc. Bei einigen Implementierungen können Zertifikate hierarchisch sein, mit Root-Zertifikaten (gemanagt durch Root-CAs (z.B. 1630), Zwischenzertifikaten (gemanagt durch Zwischen-CAs (z.B. 1635) und so weiter. Verknüpfungsstellen (z.B. 1640) können zusammen mit Registrierungsstellenentitäten (z.B. 1626) und Fehlverhaltensstellensystemen, die Fehlverhaltensberichte managen (z.B. System 250), verwendet werden. Wie oben erwähnt, kann eine CRL zur Festsetzung und Durchsetzung von Widerrufen von Zertifikaten verwendet werden. Ein Beispiel-Fehlverhaltensstellensystem 250 kann beispielsweise einen CRL-Generator 1650 zur Erzeugung und Aktualisierung von CRL(s) umfassen, der an einen oder mehrere CRL-Speicher (z.B. 1655) weitergeleitet werden kann, für einen Zugriff durch Straßensysteme bei einer Bestimmung, ob einem anderen Straßensystem innerhalb einer Fahrumgebung vertraut und mit ihm in Kommunikation getreten werden soll, neben anderen Beispielkomponenten und -implementierungen.
  • Während sich ein Großteil der obigen Diskussion auf fahrzeuginterne und Straßenrand-Systeme konzentriert hat, die Straßensicherheitsereignisse überwachen und Fahrzeugsicherheitsstandards auf Vorfälle anwenden, die zumindest teilweise autonome Straßenfahrzeuge umfassen, sollte darauf hingewiesen werden, dass die hierin erörterten Prinzipien auch in anderen Umgebungen gelten können, in denen Maschinen, die entworfen sind, um sich autonom zu bewegen, potenziell für eine Nutzung unter Verwendung von kompromittierten Sicherheitsnachrichten ausgerichtet sein können. Beispielsweise können ähnliche Lösungen und Systeme basierend auf den obigen Prinzipien für Maschinen abgeleitet werden, umfassend Luftfahrzeuge, Wasserfahrzeuge, unbemannte Drohnen, Industrieroboter, persönliche Roboter, neben anderen Beispielen.
  • 17 ist ein vereinfachtes Flussdiagramm 1700, das eine Beispieltechnik zum Detektieren von Kommunikationsbasis-Fehlverhalten durch ein Straßensystems innerhalb einer autonomen Fahrumgebung darstellt. Beispielsweise kann eine Sicherheitsnachricht an einem ersten Straßensystem (z.B. autonomes Fahrzeugsystem, Drohne, Straßenrandeinheit etc.) von einem anderen Straßensystem (z.B. eines anderen autonomen Fahrzeugs, Straßenrandeinheit etc.) empfangen 1705 werden. Die Sicherheitsnachricht kann ein oder mehrere physische Objekte beschreiben, die (durch das zweite Straßensystem) als innerhalb der Fahrumgebung vorhanden gemeldet werden. Das erste Straßensystem kann Charakteristiken der Fahrumgebung bestimmen 1710, umfassend Charakteristiken des Objekts (umfassend, ob das Objekt innerhalb der Fahrumgebung vorhanden ist oder nicht, seine Position innerhalb der Umgebung, seine Größe, ob und wie sich das Objekt bewegt etc.). Die Charakteristiken können basierend auf Sensordaten bestimmt 1710 werden, die durch Sensoren erzeugt werden, die im Hinblick auf das erste Straßensystem lokal sind, sowie Maschinenwahrnehmungslogik des ersten Straßensystems. Zusätzliche Charakteristiken können auch für das physische Objekt basierend auf anderen Sicherheitsnachrichten von anderen Straßensystemen bestimmt werden, die das Objekt ebenfalls beschreiben. Die Charakteristiken können mit der Beschreibung des Objekts in der Sicherheitsnachricht von dem zweiten Straßensystem verglichen 1715 werden, um eine Anomalie in der Beschreibung der Sicherheitsnachricht von dem zweiten Straßensystems zu bestimmen 1720. Diese Anomalie kann auf einer Abweichung von der Beschreibung mit Charakteristiken basieren, die durch das erste Straßensystem unter Verwendung seiner Sensoren und Wahrnehmungslogik beobachtet werden. Das erste Straßensystem kann basierend auf der Anomalie eine oder mehrere Abhilfehandlungen initiieren, wie z.B. das zweite Straßensystem auf eine Beobachtungsliste oder eine schwarze Liste setzen, andere Straßensysteme über die Anomalie benachrichtigen, Fehlverhalten durch das zweite Straßensystem an ein Fehlverhaltensstellensystem melden etc. Tatsächlich können Fehlverhaltensdaten erzeugt (und in einigen Fällen durch das erste Straßensystem an andere Systeme gesendet) werden, die die Anomalie beschreiben, umfassend Nachverfolgungsdaten, Fehlverhaltensberichte an andere nahegelegene Straßensysteme, Fehlverhaltensberichte für den Verbrauch durch eine Zertifikatsstelle, neben anderen Beispielen.
  • 18-19 sind Blockdiagramme von beispielhaften Computerarchitekturen, die gemäß den hierin offenbarten Ausführungsbeispielen verwendet werden können. Andere im Stand der Technik bekannte Computerarchitekturentwürfe für Prozessoren und Rechensysteme können ebenfalls verwendet werden. Im Allgemeinen können geeignete Computerarchitekturen für hierin offenbarte Ausführungsbeispiele Konfigurationen umfassen, die in den 18-19 dargestellt sind, sind aber nicht darauf beschränkt.
  • 18 ist eine beispielhafte Darstellung eines Prozessors gemäß einem Ausführungsbeispiel. Der Prozessor 1800 ist ein Beispiel für einen Typ einer Hardwarevorrichtung, die in Verbindung mit den obigen Implementierungen verwendet werden kann. Der Prozessor 1800 kann irgendein Typ von Prozessor sein, wie z.B. ein Mikroprozessor, ein eingebetteter Prozessor, ein digitaler Signalprozessor (DSP), ein Netzwerkprozessor, ein Mehrkernprozessor, ein Einzelkernprozessor oder eine andere Vorrichtung zur Ausführung von Code. Obwohl nur ein Prozessor 1800 in 18 dargestellt ist, kann ein Verarbeitungselement alternativ mehr als einen von dem in 18 dargestellten Prozessor 1800 umfassen. Der Prozessor 1800 kann ein Single-Threaded-Kern sein oder, für zumindest ein Ausführungsbeispiel, der Prozessor 1800 kann multi-threaded sein, indem er mehr als einen Hardware-Thread-Kontext (oder „logischen Prozessor“) pro Kern umfassen kann.
  • 18 stellt auch einen Speicher 1802 dar, der gemäß einem Ausführungsbeispiel mit dem Prozessor 1800 gekoppelt ist. Der Memory 1802 kann irgendeiner von einer breiten Vielzahl von Speichern (umfassend verschiedene Schichten von Speicherhierarchie) sein, wie sie Fachleuten auf dem Gebiet bekannt sind oder diesen anderweitig zur Verfügung stehen. Solche Speicherelemente können Direktzugriffsspeicher (RAM; Random Access Memory), Nurlesespeicher (ROM; Read Only Memory), logische Blöcke eines feld-programmierbaren Gate-Arrays (FPGA), löschbare programmierbare Nurlesespeicher (EPROM; erasable programmable read only memory) und elektrisch löschbare programmierbare ROM (EEPROM; electrically erasable programmable ROM) umfassen, sind aber nicht darauf beschränkt.
  • Der Prozessor 1800 kann irgendeine Art von Anweisungen ausführen, die hierin detailliert beschriebenen Algorithmen, Prozessen oder Operationen zugeordnet sind. Im Allgemeinen kann der Prozessor 1800 ein Element oder einen Artikel (z.B. Daten) von einem Zustand oder einer Sache in einen anderen Zustand oder eine andere Sache transformieren.
  • Ein Code 1804, der eine oder mehrere durch den Prozessor 1800 auszuführende Anweisungen sein kann, kann in dem Speicher 1802 gespeichert sein, oder er kann in Software, Hardware, Firmware oder irgendeiner geeigneten Kombination davon oder in irgendeiner anderen internen oder externen Komponente, Vorrichtung, Element oder Objekt gespeichert sein, wo dies angemessen ist und basierend auf bestimmten Bedürfnissen. Bei einem Beispiel kann der Prozessor 1800 einer Programmsequenz von Anweisungen folgen, die durch den Code 1804 angezeigt ist. Jede Anweisung gelangt in eine Front-End-Logik 1806 und wird durch einen oder mehrere Decodierer 1808 verarbeitet. Der Decodierer kann als seine Ausgabe eine Mikrooperation wie eine Mikrooperation mit fester Breite in einem vordefinierten Format erzeugen oder kann andere Anweisungen, Microanweisungen oder Steuersignale erzeugen, die die ursprüngliche Codeanweisung widerspiegeln. Die Front-End-Logik 1806 umfasst auch eine Register-Umbenennungslogik 1810 und eine Zeitplanungslogik 1812, die im Allgemeinen Ressourcen zuweisen und die Operation in eine Warteschlange stellen, gemäß der Anweisung zur Ausführung.
  • Der Prozessor 1800 kann auch eine Ausführungslogik 1814 umfassen, die einen Satz von Ausführungseinheiten 1816a, 1816b, 1816n etc. aufweist. Einige Ausführungsbeispiele können eine Anzahl von Ausführungseinheiten umfassen, die für spezifische Funktionen oder Sätze von Funktionen zweckgebunden sind. Andere Ausführungsbeispiele umfassen möglicherweise nur eine Ausführungseinheit oder eine Ausführungseinheit, die eine bestimmte Funktion ausführen kann. Die Ausführungslogik 1814 führt die durch Codeanweisungen spezifizierten Operationen aus.
  • Nach Abschluss der Ausführung der durch die Codeanweisungen spezifizierten Operationen kann die Back-End-Logik 1818 die Anweisungen des Codes 1804 stilllegen. Bei einem Ausführungsbeispiel erlaubt der Prozessor 1800 eine Out-of-Order-Ausführung, erfordert aber eine In-Order-Rücknahme von Anweisungen. Eine Stilllegungslogik 1820 kann eine Vielzahl von bekannten Formen annehmen (z.B. Neuanordnungs- (re-order) Puffer oder dergleichen). Auf diese Weise wird der Prozessor 1800 während der Ausführung von Code 1804 transformiert, zumindest im Hinblick auf die Ausgabe, die durch den Decodierer, Hardwareregister und Tabellen, die durch die Registerumbenennungslogik 1820 genutzt werden und irgendwelche Register (nicht gezeigt), die durch die Ausführungslogik 1814 modifiziert werden, erzeugt wird.
  • Obwohl in 18 nicht gezeigt, kann ein Verarbeitungselement andere Elemente auf einem Chip mit dem Prozessor 1800 umfassen. Ein Verarbeitungselement kann beispielsweise eine Speichersteuerungslogik zusammen mit dem Prozessor 1800 umfassen. Das Verarbeitungselement kann eine I/O-Steuerungslogik und/oder eine mit der Speichersteuerungslogik integrierte I/O-Steuerungslogik umfassen. Das Verarbeitungselement kann auch einen oder mehrere Caches umfassen. Bei einigen Ausführungsbeispielen kann auch ein nichtflüchtiger Speicher (wie z.B. Flash-Speicher oder Sicherungen) auf dem Chip mit dem Prozessor 1800 umfasst sein.
  • 19 stellt ein Rechensystem 1900 dar, das in einer Punkt-zu-Punkt- (PtP; point-to-point) Konfiguration gemäß einem Ausführungsbeispiel angeordnet ist. Insbesondere zeigt 19 ein System, bei dem Prozessoren, Speicher und Eingabe-/Ausgabevorrichtungen durch eine Anzahl von Punkt-zu-Punkt-Schnittstellen verbunden sind. Im Allgemeinen können eines oder mehrere der hierin beschriebenen Rechensysteme auf die gleiche oder eine ähnliche Weise wie das Rechensystem 1800 ausgebildet sein.
  • Prozessoren 1970 und 1980 können auch jeweils eine integrierte Speichersteuerungslogik (MC; memory controller) 1972 und 1982 umfassen, um mit den Speicherelementen 1932 und 1934 zu kommunizieren. Bei alternativen Ausführungsbeispielen kann die Speichersteuerungslogik 1972 und 1982 eine von den Prozessoren 1970 und 1980 getrennte diskrete Logik sein. Die Speicherelemente 1932 und/oder 1934 können verschiedene Daten zur Verwendung durch die Prozessoren 1970 und 1980 bei der Erreichung der hierin beschriebenen Operationen und Funktionalität speichern.
  • Die Prozessoren 1970 und 1980 können irgendein Typ von Prozessor sein, wie jene, die im Zusammenhang mit anderen Figuren hierin erörtert sind. 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 mit einem Chipsatz 1990 über individuelle Punkt-zu-Punkt-Schnittstellen 1952 und 1954 unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 1976, 1986, 1994 und 1998 Daten austauschen. Der Chipsatz 1990 kann auch Daten mit einem Co-Prozessor 1938, wie z.B. einer Hochperformance-Graphikschaltung, einem Maschinenlernbeschleuniger oder einem anderen Co-Prozessor 1938, über eine Schnittstelle 1939 austauschen, die eine PtP-Schnittstellenschaltung sein könnte. Bei alternativen Ausführungsbeispielen könnten irgendwelche oder alle der in 19 dargestellten PtP-Links als ein Multi-Drop Bus statt als ein PtP-Link implementiert sein.
  • Der Chipsatz 1990 kommuniziert möglicherweise über eine Schnittstellenschaltung 1996 mit einem Bus 1920. Der Bus 1920 kann ein oder mehrere Vorrichtungen aufweisen, die über ihn kommunizieren, wie z.B. eine Bus-Brücke 1918 und I/O-Vorrichtungen 1916. Über einen Bus 1910 kann die Bus-Brücke 1918 mit anderen Vorrichtungen kommunizieren, wie z.B. einer Benutzerschnittstelle 1912 (wie beispielsweise einer Tastatur, Maus, Touchscreen oder anderen Eingabevorrichtungen), Kommunikationsvorrichtungen 1926 (wie beispielsweise Modems, Netzwerkschnittstellenvorrichtungen oder anderen Arten von Kommunikationsvorrichtungen, die durch ein Computernetzwerk 1960 kommunizieren können), Audio-I/O-Vorrichtungen 1914 und/oder einer Datenspeichervorrichtung 1928. Die Datenspeichervorrichtung 1928 kann den Code 1930 speichern, der durch die Prozessoren 1970 und/oder 1980 ausgeführt werden kann. Bei alternativen Ausführungsbeispielen könnten irgendwelche Abschnitte der Busarchitekturen mit einem oder mehreren PtP-Links implementiert sein.
  • Das in 19 abgebildete Computersystem ist eine schematische Darstellung eines Ausführungsbeispiels eines Rechensystems, das zur Implementierung verschiedener hierin erörterter Ausführungsbeispiele verwendet werden kann. Es wird darauf hingewiesen, dass verschiedene Komponenten des in 19 abgebildeten Systems in einer System-auf-einem-Chip- (SoC; system-on-a-chip) Architektur oder in irgendeiner anderen geeigneten Konfiguration kombiniert werden können, die in der Lage ist, die Funktionalität und die Merkmale von hierin bereitgestellten Beispielen und Implementierungen zu erreichen.
  • Während einige der hierin beschriebenen und dargestellten Systeme und Lösungen als eine Mehrzahl von Elementen umfassend oder dieser zugeordnet beschrieben wurden, werden möglicherweise nicht alle explizit dargestellten oder beschriebenen Elemente bei jeder alternativen Implementierung der vorliegenden Offenbarung verwendet. Zusätzlich können eines oder mehrere der hierin beschriebenen Elemente extern im Hinblick auf ein System positioniert sein, während in anderen Fällen bestimmte Elemente innerhalb oder als ein Abschnitt eines oder mehrerer der anderen beschriebenen Elemente sowie anderer Elemente, die nicht in der dargestellten Implementierung beschrieben sind, umfasst sein können. Ferner können bestimmte Elemente mit anderen Komponenten kombiniert sowie für alternative oder zusätzliche Zwecke zusätzlich zu den hierin beschriebenen Zwecken verwendet werden.
  • Ferner sollte darauf hingewiesen werden, dass die oben vorgestellten Beispiele nicht einschränkende Beispiele sind, die lediglich zur Veranschaulichung bestimmter Prinzipien und Merkmale bereitgestellt sind und die die potenziellen Ausführungsbeispiele der hierin beschriebenen Konzepte nicht unbedingt begrenzen oder einschränken. Beispielsweise kann eine Vielzahl unterschiedlicher Ausführungsbeispiele unter Verwendung verschiedener Kombinationen der hierin beschriebenen Merkmale und Komponenten realisiert werden, umfassend Kombinationen, die durch die verschiedenen Implementierungen von hierin beschriebenen Komponenten realisiert werden. Andere Implementierungen, Merkmale und Details sollten aus den Inhalten dieser Beschreibung erkannt werden.
  • Obwohl diese Offenbarung im Hinblick auf bestimmte Implementierungen und allgemein zugeordnete Verfahren beschrieben wurde, werden Änderungen und Permutationen dieser Implementierungen und Verfahren für Fachleute auf dem Gebiet offensichtlich sein. Die hierin beschriebenen Handlungen können z.B. in einer unterschiedlichen Reihenfolge als beschrieben durchgeführt werden und dennoch die gewünschten Ergebnisse erzielen. Als ein Beispiel erfordern die in den beiliegenden Figuren abgebildeten Prozesse nicht unbedingt die bestimmte gezeigte Reihenfolge oder sequenzielle Reihenfolge, um die gewünschten Ergebnisse zu erzielen. Bei bestimmten Implementierungen können Multitasking und Parallelverarbeitung vorteilhaft sein. Zusätzlich können andere Benutzerschnittstellenlayouts- und Funktionalität unterstützt werden. Andere Variationen sind im Rahmen der folgenden Ansprüche.
  • Während diese Beschreibung viele spezifische Implementierungsdetails umfasst, sollten diese nicht als Einschränkungen im Hinblick auf den Schutzbereich von irgendwelchen Erfindungen oder dessen, was beansprucht werden kann, ausgelegt werden, sondern vielmehr als Beschreibungen von Merkmalen, die für bestimmte Ausführungsbeispiele bestimmter Erfindungen spezifisch sind. Bestimmte Merkmale, die in dieser Beschreibung im Kontext von separaten Ausführungsbeispielen beschrieben werden, können auch in Kombination in einem einzelnen Ausführungsbeispiel implementiert werden. Umgekehrt können verschiedene Merkmale, die im Kontext eines einzelnen Ausführungsbeispiels beschrieben werden, auch in mehreren Ausführungsbeispielen getrennt oder in irgendeiner geeigneten Teilkombination implementiert werden. Darüber hinaus, obwohl Merkmale oben als in bestimmten Kombinationen wirkend beschrieben und sogar anfänglich als solche beansprucht werden können, können in einigen Fällen ein oder mehrere Merkmale aus einer beanspruchten Kombination herausgeschnitten werden, und die beanspruchte Kombination kann auf eine Teilkombination oder eine Variation einer Teilkombination gerichtet sein.
  • Ähnlich, wenn Operationen in den Zeichnungen in einer bestimmten Reihenfolge dargestellt werden, sollte dies nicht so verstanden werden, dass es erforderlich ist, dass solche Operationen in der bestimmten gezeigten Reihenfolge oder in einer sequenziellen Reihenfolge durchgeführt werden oder dass alle dargestellten Operationen ausgeführt werden, um die gewünschten Ergebnisse zu erzielen. Unter bestimmten Umständen können Multitasking und Parallelverarbeitung vorteilhaft sein. Darüber hinaus sollte die Trennung der verschiedenen Systemkomponenten in den oben beschriebenen Ausführungsbeispielen nicht so verstanden werden, dass bei allen Ausführungsbeispielen eine solche Trennung erforderlich ist, und es versteht sich, dass die beschriebenen Programm-Komponenten und Systeme im Allgemeinen zusammen in ein einzelnes Softwareprodukt integriert oder in mehrere Softwareprodukte gepackagt werden können.
  • Die folgenden Beispiele beziehen sich auf Ausführungsbeispiele gemäß dieser Beschreibung. Beispiel 1 ist ein maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen durch eine Maschine ausführbar sind, um die Maschine zu veranlassen zum: Empfangen, an einem ersten Straßensystem, einer Kommunikation von einem zweiten Straßensystem über einen drahtlosen Kanal, wobei die Kommunikation eine Identifizierung des zweiten Straßensystems und Beschreibung eines physischen Objekts innerhalb einer Fahrumgebung umfasst; Bestimmen von Charakteristiken des physischen Objekts basierend auf Sensoren des ersten Straßensystems; Bestimmen, dass die Beschreibung des physischen Objekts in der Kommunikation eine Anomalie umfasst, basierend auf einem Vergleich mit den Charakteristiken des physischen Objekts basierend auf Sensoren des ersten Straßensystems; Erzeugen von Fehlverhaltensdaten zur Beschreibung der Anomalie; und Bestimmen, ob eine Abhilfehandlung initiiert werden soll, basierend auf der Anomalie.
  • Beispiel 2 umfasst den Gegenstand von Beispiel 1, wobei die Fehlverhaltensdaten eine Fehlverhaltensberichtnachricht umfassen und die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Fehlverhaltensberichtnachricht an ein anderes System zu senden, um zumindest einen Abschnitt der Abhilfehandlung an dem anderen System zu initiieren.
  • Beispiel 3 umfasst den Gegenstand von Beispiel 2, wobei die Identifizierung des zweiten Straßensystems umfasst, dass Zugangsdaten des zweiten Straßensystems in eine drahtlose Kommunikation mit anderen Straßensystemen in der Fahrumgebung treten, die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Zugangsdaten des zweiten Straßensystems in Verbindung mit dem Empfang der Kommunikation zu prüfen, und das andere System ein Fehlverhaltensstellensystem umfasst, um zu bestimmen, ob die Zugangsdaten des zweiten Straßensystems basierend auf der Anomalie zugeordnetem Fehlverhalten zu widerrufen sind.
  • Beispiel 4 umfasst den Gegenstand von Beispiel 2, wobei das andere System ein anderes Straßensystem in der Fahrumgebung umfasst und die Fehlverhaltensdaten an das andere Straßensystem identifizieren, dass die Anomalie in der Kommunikation von dem zweiten Straßensystem detektiert wurde.
  • Beispiel 5 umfasst den Gegenstand von Beispiel 2, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, eine weitere Fehlverhaltensberichtnachricht von einem anderen Straßensystem zu empfangen, der andere Fehlverhaltensbericht eine durch das andere Straßensystem detektierte Anomalie identifiziert, umfassend eine Kommunikation von dem zweiten Straßensystem, an dem anderen Straßensystem, und die Abhilfehandlung ferner basierend auf dem anderen Fehlverhaltensbericht bestimmt wird.
  • Beispiel 6 umfasst den Gegenstand von Beispiel 5, wobei die Anweisungen ferner ausführbar sind, um zu bestimmen, ob eine Schwelle von Fehlverhaltensberichten erreicht wurde, und die Abhilfehandlung zumindest teilweise darauf basiert, ob die Schwelle erreicht wurde.
  • Beispiel 7 umfasst den Gegenstand von irgendeinem der Beispiele 1-6, wobei die Abhilfehandlung ein Hinzufügen des zweiten Straßensystems zu einer Beobachtungsliste umfasst, eine zusätzliche Abhilfehandlung initiiert werden soll, wenn Anomalien durch das erste Straßensystem in nachfolgenden Kommunikationen von dem zweiten Straßensystem basierend auf dem Umfassen des zweiten Straßensystems in der Beobachtungsliste detektiert werden.
  • Beispiel 8 umfasst den Gegenstand von irgendeinem der Beispiele 1-7, wobei die Abhilfehandlung das Hinzufügen des Identifizierers des zweiten Straßensystems zu einer lokalen schwarzen Liste umfasst, die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen zum: Abtasten von durch das erste Straßensystem empfangenen Kommunikationen, um zu bestimmen, ob Senderidentifizierer in der lokalen schwarzen Liste umfasst sind; Nichtberücksichtigen von Kommunikationen von Sendern mit Senderidentifizierer, die in der lokalen schwarzen Liste umfasst sind.
  • Beispiel 9 umfasst den Gegenstand von irgendeinem der Beispiele 1-8, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, einen Grad der Divergenz in der Beschreibung des physischen Objekts in der Kommunikation von den Charakteristiken des physischen Objekts basierend auf Sensoren des ersten Straßensystems zu bestimmen, wobei das Initiieren der Abhilfehandlung auf dem Grad der Divergenz basiert.
  • Beispiel 10 umfasst den Gegenstand von Beispiel 9, wobei die Anweisungen ferner ausführbar sind, um eine Menge von Anomalien in Kommunikationen von dem zweiten Straßensystem während eines Zeitfensters zu bestimmen, die Bestimmung, ob die Abhilfehandlung initiiert werden soll, darauf basiert, ob die Menge der Anomalien eine Schwelle überschreitet, und die Dauer des Zeitfensters auf dem Grad der Divergenz basiert.
  • Beispiel 11 umfasst den Gegenstand von irgendeinem der Beispiele 1-10, wobei die Kommunikation eine Sicherheitsnachricht umfasst, das erste Straßensystem das autonome Fahren eines Fahrzeugs steuern soll und das erste Straßensystem das autonome Fahren basierend zumindest teilweise auf Sicherheitsnachrichten steuern soll, die von anderen Straßensystemen in der Fahrumgebung empfangen werden.
  • Beispiel 12 umfasst den Gegenstand von Beispiel 11, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Sicherheitsnachricht zu überprüfen, um zu bestimmen, ob eine Position des physischen Objekts innerhalb eines angenommenen Bereichs ist. Nachricht überprüft im Hinblick auf Annahmen
  • Beispiel 13 umfasst den Gegenstand von irgendeinem der Beispiele 11-12, wobei zumindest eine andere Sicherheitsnachricht von einem anderen Straßensystem empfangen wird und das physische Objekt beschreibt, und die Anomalie ferner auf einem Vergleich von Inhalten der Sicherheitsnachricht mit Informationen in der anderen Sicherheitsnachricht basiert.
  • Beispiel 14 umfasst den Gegenstand von irgendeinem der Beispiele 11-13, wobei die Sicherheitsnachricht eine zweite Sicherheitsnachricht ist, die von dem zweiten Straßensystem nach dem Empfang einer ersten Sicherheitsnachricht von dem zweiten Straßensystem empfangen wurde, die erste Sicherheitsnachricht auch das physische Objekt beschreibt und die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen zum: Bestimmen, anhand eines Modells, eines erwarteten Zustands des physischen Objekts basierend auf der ersten Sicherheitsnachricht; und Bestimmen, ob die Beschreibung des physischen Objekts in der zweiten Sicherheitsnachricht von dem erwarteten Zustand abweicht, wobei die Anomalie ferner auf der Bestimmung einer Divergenz zwischen der Beschreibung des physischen Objekts und dem erwarteten Zustand basiert.
  • Beispiel 15 umfasst den Gegenstand von irgendeinem der Beispiele 1-14, wobei die Anweisungen ferner ausführbar sind, um Nachverfolgungsdaten zur Verfolgung des physischen Objekts zu erzeugen.
  • Beispiel 16 umfasst den Gegenstand von Beispiel 15, wobei die jeweiligen Nachverfolgungsdaten für jedes eine einer Mehrzahl von physischen Objekten, die innerhalb der Fahrumgebung detektiert oder gemeldet werden, geführt werden.
  • Beispiel 17 umfasst den Gegenstand von irgendeinem der Beispiele 15-16, wobei die Nachverfolgungsdaten als eine gemeldete Objektnachverfolgung (VT; reported object track), eine wahrgenommene Objektnachverfolgung (LT; perceived object track) oder eine gemischte Nachverfolgung (MT; mixed track), umfassend sowohl gemeldete als auch wahrgenommene Informationen, gekennzeichnet sind.
  • Beispiel 18 umfasst den Gegenstand von Beispiel 17, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen zum: Identifizieren von vorhandenen Nachverfolgungsdaten für das physische Objekt, wobei die vorhandenen Nachverfolgungsdaten eine gemischte Nachverfolgung umfassen, basierend zumindest teilweise auf einer zuvor empfangenen Kommunikation zur Beschreibung des physischen Objekts; und Ändern der Bezeichnung des vorhandenen Nachverfolgungsdatums von MT zu LT basierend auf der Anomalie.
  • Beispiel 19 umfasst den Gegenstand von irgendeinem der Beispiele 15-17, wobei die Nachverfolgungsdaten Informationen für physische Objekte zusammenführen sollen, die entweder intern durch das erste Straßensystem oder von anderen Straßensystemen empfangen wurden oder beides.
  • Beispiel 20 umfasst den Gegenstand von irgendeinem der Beispiele 1-19, wobei jedes von dem ersten und zweiten Straßensystem jeweils ein autonomes Fahrzeug oder eine Straßenrandeinheit umfasst.
  • Beispiel 21 ist ein Verfahren, umfassend: Empfangen, an einem ersten Straßensystem, einer Kommunikation von einem zweiten Straßensystem über einen drahtlosen Kanal, wobei die Kommunikation eine Identifizierung des zweiten Straßensystems und Beschreibung eines physischen Objekts innerhalb einer Fahrumgebung umfasst; Bestimmen von Charakteristiken des physischen Objekts basierend auf Sensoren des ersten Straßensystems; Bestimmen, dass die Beschreibung des physischen Objekts in der Kommunikation eine Anomalie umfasst, basierend auf einem Vergleich mit den Charakteristiken des physischen Objekts basierend auf Sensoren des ersten Straßensystems; Erzeugen von Fehlverhaltensdaten zur Beschreibung der Anomalie; und Bestimmen, ob eine Abhilfehandlung initiiert werden soll, basierend auf der Anomalie, wobei die Abhilfehandlung das erste Straßensystem daran hindern soll, nachfolgende anomale Kommunikationen zu berücksichtigen.
  • Beispiel 22 umfasst den Gegenstand von Beispiel 21, ferner umfassend ein Senden der Fehlverhaltensdaten an ein anderes System als eine Fehlverhaltensberichtnachricht, wobei die Fehlverhaltensberichtnachricht ein potenzielles Fehlverhalten durch das zweite Straßensystem basierend auf der Anomalie meldet.
  • Beispiel 23 umfasst den Gegenstand von irgendeinem der Beispiele 21-22, wobei die Fehlverhaltensdaten eine Fehlverhaltensberichtnachricht umfassen und das Verfahren ferner das Senden der Fehlverhaltensberichtnachricht an ein anderes System umfasst, um zumindest einen Abschnitt der Abhilfehandlung an dem anderen System zu initiieren.
  • Beispiel 24 umfasst den Gegenstand von Beispiel 23, wobei die Identifizierung des zweiten Straßensystems umfasst, dass Zugangsdaten des zweiten Straßensystems in eine drahtlose Kommunikation mit anderen Straßensystemen in der Fahrumgebung treten, das Verfahren ferner die Überprüfung der Zugangsdaten des zweiten Straßensystems in Verbindung mit dem Empfang der Kommunikation umfasst, und das andere System ein Fehlverhaltensstellensystem umfasst, um zu bestimmen, ob die Zugangsdaten des zweiten Straßensystems basierend auf der Anomalie zugeordnetem Fehlverhalten zu widerrufen sind.
  • Beispiel 25 umfasst den Gegenstand von irgendeinem der Beispiele 23-24, wobei das andere System ein anderes Straßensystem in der Fahrumgebung umfasst und die Fehlverhaltensdaten an das andere Straßensystem identifizieren, dass die Anomalie in der Kommunikation von dem zweiten Straßensystem detektiert wurde.
  • Beispiel 26 umfasst den Gegenstand von irgendeinem der Beispiele 23-25, ferner umfassend den Empfang einer anderen Fehlverhaltensberichtnachricht von einem anderen Straßensystem, der andere Fehlverhaltensbericht identifiziert eine Anomalie, die durch ein anderes Straßensystem detektiert wurde, umfassend eine Kommunikation von dem zweiten Straßensystem an dem anderen Straßensystem, und die Abhilfehandlung ferner basierend auf dem anderen Fehlverhaltensbericht bestimmt wird.
  • Beispiel 27 umfasst den Gegenstand von Beispiel 26, ferner umfassend ein Bestimmen, ob eine Schwelle von Fehlverhaltensberichten erreicht wurde, und die Abhilfehandlung zumindest teilweise darauf basiert, ob die Schwelle erreicht wird.
  • Beispiel 28 umfasst den Gegenstand von irgendeinem der Beispiele 21-27, wobei die Abhilfehandlung ein Hinzufügen des zweiten Straßensystems zu einer Beobachtungsliste umfasst, eine zusätzliche Abhilfehandlung initiiert werden soll, wenn Anomalien durch das erste Straßensystem in nachfolgenden Kommunikationen von dem zweiten Straßensystem basierend auf dem Umfassen des zweiten Straßensystems in der Beobachtungsliste detektiert werden.
  • Beispiel 29 umfasst den Gegenstand von irgendeinem der Beispiele 21-28, wobei die Abhilfehandlung das Hinzufügen des Identifizierers des zweiten Straßensystems zu einer lokalen schwarzen Liste umfasst und das Verfahren ferner umfasst: Abtasten von Kommunikationen, die durch das erste Straßensystem empfangen werden, um zu bestimmen, ob Senderidentifizierer in der lokalen schwarzen Liste umfasst sind; und Nichtberücksichtigen von Kommunikationen von Sendern, deren Senderidentifizierer in der lokalen schwarzen Liste umfasst ist.
  • Beispiel 30 umfasst den Gegenstand von irgendeinem der Beispiele 21-29, ferner umfassend ein Bestimmen eines Grades an Divergenz in der Beschreibung des physischen Objekts in der Kommunikation von den Charakteristiken des physischen Objekts basierend auf Sensoren des ersten Straßensystems, wobei die Initiierung der Abhilfehandlung auf dem Grad der Divergenz basiert.
    Beispiel 31 umfasst den Gegenstand von Beispiel 30, ferner umfassend ein Bestimmen einer Menge von Anomalien in Kommunikationen von dem zweiten Straßensystem während eines Zeitfensters, ein Bestimmen, ob die Abhilfehandlung zu initiieren ist, basiert darauf, ob die Menge der Anomalien eine Schwelle überschreitet, und die Dauer des Zeitfensters basiert auf dem Grad der Divergenz.
  • Beispiel 32 umfasst den Gegenstand von irgendeinem der Beispiele 21-31, wobei die Kommunikation eine Sicherheitsnachricht umfasst, das erste Straßensystem das autonome Fahren eines Fahrzeugs steuern soll und das erste Straßensystem das autonome Fahren basierend zumindest teilweise auf Sicherheitsnachrichten steuern soll, die von anderen Straßensystemen in der Fahrumgebung empfangen werden.
  • Beispiel 33 umfasst den Gegenstand von Beispiel 32, ferner umfassend ein Überprüfen der Sicherheitsnachricht, um zu bestimmen, ob eine Position des physischen Objekts innerhalb eines angenommenen Bereichs ist. Nachricht überprüft im Hinblick auf Annahmen
  • Beispiel 34 umfasst den Gegenstand von irgendeinem der Beispiele 32-33, wobei zumindest eine weitere Sicherheitsnachricht von einem anderen Straßensystem empfangen wird und das physische Objekt beschreibt, und die Anomalie ferner auf einem Vergleich von Inhalten der Sicherheitsnachricht mit Informationen in der anderen Sicherheitsnachricht basiert.
  • Beispiel 35 umfasst den Gegenstand von irgendeinem der Beispiele 32-34, wobei die Sicherheitsnachricht eine zweite Sicherheitsnachricht ist, die von dem zweiten Straßensystem nach dem Empfang einer ersten Sicherheitsnachricht von dem zweiten Straßensystem empfangen wird, die erste Sicherheitsnachricht auch das physische Objekt beschreibt und das Verfahren ferner umfasst: Bestimmen, anhand eines Modells, eines erwarteten Zustands des physischen Objekts basierend auf der ersten Sicherheitsnachricht; und Bestimmen, ob die Beschreibung des physischen Objekts in der zweiten Sicherheitsnachricht von dem erwarteten Zustand abweicht, wobei die Anomalie ferner auf einer Bestimmung einer Divergenz zwischen der Beschreibung des physischen Objekts und dem erwarteten Zustand basiert.
  • Beispiel 36 umfasst den Gegenstand von irgendeinem der Beispiele 21-35, ferner umfassend ein Erzeugen von Nachverfolgungsdaten zum Verfolgen des physischen Objekts.
  • Beispiel 37 umfasst den Gegenstand von Beispiel 36, wobei die jeweiligen Nachverfolgungsdaten für jedes eine einer Mehrzahl von physischen Objekten, die innerhalb der Fahrumgebung detektiert oder gemeldet werden, geführt werden.
  • Beispiel 38 umfasst den Gegenstand von irgendeinem der Beispiele 36-37, wobei die Nachverfolgungsdaten als eine gemeldete Objektnachverfolgung (VT), eine wahrgenommene Objektnachverfolgung (LT) oder eine gemischte Nachverfolgung (MT), umfassend sowohl gemeldete als auch wahrgenommene Informationen, gekennzeichnet sind.
  • Beispiel 39 umfasst den Gegenstand von Beispiel 38, ferner umfassend: Identifizieren vorhandener Nachverfolgungsdaten für das physische Objekt, wobei die vorhandenen Nachverfolgungsdaten eine gemischte Nachverfolgung umfassen, basierend zumindest teilweise auf einer zuvor empfangenen Kommunikation zur Beschreibung des physischen Objekts; und Ändern der Bezeichnung des vorhandenen Nachverfolgungsdatums von MT zu LT basierend auf der Anomalie.
  • Beispiel 40 umfasst den Gegenstand von irgendeinem der Beispiele 37-39, wobei die Nachverfolgungsdaten Informationen für physische Objekte zusammenführen sollen, die entweder intern durch das erste Straßensystem oder von anderen Straßensystemen empfangen wurden oder beides.
  • Beispiel 41 umfasst den Gegenstand von irgendeinem der Beispiele 21-40, wobei jedes von dem ersten und zweiten Straßensystem jeweils ein autonomes Fahrzeug oder eine Straßenrandeinheit umfasst.
  • Beispiel 42 ist ein System, umfassend Mittel zum Durchführen des Verfahrens von irgendeinem der Beispiele 21-41.
  • Beispiel 43 ist ein System, umfassend: einen oder mehrere Datenprozessoren; einen Speicher; einen Satz von Sensoren; eine Wahrnehmungsmaschine, ausführbar durch zumindest einen des einen oder der mehreren Datenprozessoren zur Verwendung von Sensordaten, die durch den Satz von Sensoren erzeugt werden, um Charakteristiken von physischen Objekten innerhalb einer Fahrumgebung zu bestimmen; und eine Fehlverhaltensdetektionsmaschine, ausführbar durch zumindest einen von dem einen oder den mehreren Datenprozessoren zum: Identifizieren einer Beschreibung eines bestimmten physischen Objekts in einer von einem bestimmten Straßensystem empfangenen Sicherheitsnachricht; Vergleichen von Charakteristiken des bestimmten physischen Objekts, die durch die Wahrnehmungsmaschine basierend auf den Sensordaten bestimmt wurden, zum Bestimmen einer Anomalie in der Beschreibung; Bestimmen, ob die Sicherheitsnachricht ein Fehlverhalten durch das bestimmte Straßensystem umfasst, basierend zumindest teilweise auf der Anomalie; und Initiieren einer Abhilfehandlung basierend auf der Anomalie.
  • Beispiel 44 umfasst den Gegenstand von Beispiel 43, wobei die Fehlverhaltensdetektionsmaschine ferner Fehlverhaltensdaten basierend auf der Anomalie erzeugen soll.
  • Beispiel 45 umfasst den Gegenstand von Beispiel 44, wobei die Fehlverhaltensdaten eine Fehlverhaltensberichtnachricht umfassen und die Fehlverhaltensdetektionsmaschine die Fehlverhaltensberichtnachricht an ein anderes System senden soll, um zumindest einen Abschnitt der Abhilfehandlung an dem anderen System zu initiieren.
  • Beispiel 46 umfasst den Gegenstand von Beispiel 45, wobei die Sicherheitsnachricht Zugangsdaten des bestimmten Straßensystems umfasst, um in eine Sicherheitsnachrichtkommunikation mit anderen Straßensystemen in der Fahrumgebung zu treten, die Fehlverhaltensdetektionsmaschine die Zugangsdaten des bestimmten Straßensystems in Verbindung mit dem Empfang der Sicherheitsnachricht zu überprüfen hat und das andere System ein Fehlverhaltensstellensystem umfasst, um zu bestimmen, ob die Zugangsdaten des bestimmten Straßensystems basierend auf der Anomalie zugeordnetem Fehlverhalten widerrufen werden sollen.
  • Beispiel 47 umfasst den Gegenstand von Beispiel 45, wobei das andere System ein anderes Straßensystem in der Fahrumgebung umfasst und die Fehlverhaltensdaten an das andere Straßensystem identifizieren, dass die Anomalie in der Kommunikation von dem bestimmten Straßensystem detektiert wurde.
  • Beispiel 48 umfasst den Gegenstand von Beispiel 45, wobei die Fehlverhaltensdetektionsmaschine ferner eine andere Fehlverhaltensberichtnachricht von einem anderen Straßensystem empfangen soll, der andere Fehlverhaltensbericht eine durch das andere Straßensystem detektierte Anomalie identifiziert, umfassend eine andere Sicherheitsnachricht von dem bestimmten Straßensystem an dem anderen Straßensystem, und die Abhilfehandlung ferner basierend auf dem anderen Fehlverhaltensbericht bestimmt wird.
  • Beispiel 49 umfasst den Gegenstand von Beispiel 48, wobei die Anweisungen ferner ausführbar sind, um zu bestimmen, ob eine Schwelle von Fehlverhaltensberichten erreicht wurde, und die Abhilfehandlung zumindest teilweise darauf basiert, ob die Schwelle erreicht wird.
  • Beispiel 50 umfasst den Gegenstand von irgendeinem der Beispiele 43-49, wobei die Abhilfehandlung ein Hinzufügen des bestimmten Straßensystems zu einer Beobachtungsliste umfasst, eine zusätzliche Abhilfehandlung zu initiieren ist, wenn Anomalien durch das erste Straßensystem in nachfolgenden Sicherheitsnachrichten von dem bestimmten Straßensystem basierend auf einer Aufnahme des bestimmten Straßensystems in die Beobachtungsliste detektiert werden.
  • Beispiel 51 umfasst den Gegenstand von irgendeinem der Beispiele 43-50, wobei die Abhilfehandlung das Hinzufügen des Identifizierers des bestimmten Straßensystems zu einer lokalen schwarzen Liste umfasst, die Fehlverhaltensdetektionsmaschine ferner ausgebildet ist zum: Abtasten von empfangenen Sicherheitsnachrichten, um zu bestimmen, ob Senderidentifizierer in der lokalen schwarzen Liste umfasst sind; und Nichtberücksichtigen von Kommunikationen von Sendern mit einem in der lokalen schwarzen Liste umfassten Senderidentifizierer.
  • Beispiel 52 umfasst den Gegenstand von irgendeinem der Beispiele 43-51, wobei die Fehlverhaltensdetektionsmaschine ferner einen Grad an Divergenz in der Beschreibung des physischen Objekts in der Kommunikation von den Charakteristiken des physischen Objekts basierend auf Sensoren des ersten Straßensystems bestimmen soll, wobei die Initiierung der Abhilfehandlung auf dem Grad der Divergenz basiert.
  • Beispiel 53 umfasst den Gegenstand von Beispiel 52, wobei die Anweisungen ferner ausführbar sind, um eine Menge von Anomalien in Kommunikationen von dem bestimmten Straßensystem während eines Zeitfensters zu bestimmen, die Bestimmung, ob die Abhilfehandlung initiiert werden soll, darauf basiert, ob die Menge der Anomalien eine Schwelle überschreitet, und die Dauer des Zeitfensters auf dem Grad der Divergenz basiert.
  • Beispiel 54 umfasst den Gegenstand von irgendeinem der Beispiele 43-53, ferner umfassend autonome Fahrsteuerungen, um das autonome Fahren eines Fahrzeugs zu steuern, und die autonomen Fahrsteuerungen sollen das autonome Fahren basierend zumindest teilweise auf Sicherheitsnachrichten, die von anderen Straßensystemen in der Fahrumgebung empfangen werden, steuern.
  • Beispiel 55 umfasst den Gegenstand von Beispiel 54, wobei die Fehlverhaltensdetektionsmaschine die Sicherheitsnachricht ferner überprüfen soll, um zu bestimmen, ob eine Position des physischen Objekts innerhalb eines angenommenen Bereichs ist. Nachricht überprüft im Hinblick auf Annahmen
  • Beispiel 56 umfasst den Gegenstand von irgendeinem der Beispiele 54-55, wobei zumindest eine andere Sicherheitsnachricht von einem anderen Straßensystem empfangen wird und das physische Objekt beschreibt, und die Anomalie ferner auf einem Vergleich von Inhalten der Sicherheitsnachricht mit Informationen in der anderen Sicherheitsnachricht basiert.
  • Beispiel 57 umfasst den Gegenstand von irgendeinem der Beispiele 54-56, wobei die Sicherheitsnachricht eine zweite Sicherheitsnachricht ist, die von dem bestimmten Straßensystem nach dem Empfang einer ersten Sicherheitsnachricht von dem bestimmten Straßensystem empfangen wird, die erste Sicherheitsnachricht auch das physische Objekt beschreibt und die Fehlverhaltensdetektionsmaschine ferner ausgebildet ist zum: Bestimmen, anhand eines Modells, eines erwarteten Zustands des physischen Objekts basierend auf der ersten Sicherheitsnachricht; und Bestimmen, ob die Beschreibung des physischen Objekts in der zweiten Sicherheitsnachricht von dem erwarteten Zustand abweicht, wobei die Anomalie ferner auf der Bestimmung einer Divergenz zwischen der Beschreibung des physischen Objekts und dem erwarteten Zustand basiert.
  • Beispiel 58 umfasst den Gegenstand von irgendeinem der Beispiele 43-57, wobei die Anweisungen ferner ausführbar sind, um Nachverfolgungsdaten zur Verfolgung des physischen Objekts zu erzeugen.
  • Beispiel 59 umfasst den Gegenstand von Beispiel 58, wobei die jeweiligen Nachverfolgungsdaten für jedes eine einer Mehrzahl von physischen Objekten, die innerhalb der Fahrumgebung detektiert oder gemeldet werden, geführt werden.
    Beispiel 60 umfasst den Gegenstand von irgendeinem der Beispiele 58-59, wobei die Nachverfolgungsdaten als eine gemeldete Objektnachverfolgung (VT), eine wahrgenommene Objektnachverfolgung (LT) oder eine gemischte Nachverfolgung (MT), umfassend sowohl gemeldete als auch wahrgenommene Informationen, gekennzeichnet sind.
  • Beispiel 61 umfasst den Gegenstand von Beispiel 60, wobei die Fehlverhaltensdetektionsmaschine ferner ausgebildet ist zum: Identifizieren von vorhandenen Nachverfolgungsdaten für das physische Objekt, wobei die vorhandenen Nachverfolgungsdaten eine gemischte Nachverfolgung umfassen, basierend zumindest teilweise auf einer zuvor empfangenen Kommunikation zur Beschreibung des physischen Objekts; und Ändern der Bezeichnung des vorhandenen Nachverfolgungsdatums von MT zu LT basierend auf der Anomalie.
  • Beispiel 62 umfasst den Gegenstand von irgendeinem der Beispiele 59-61, wobei die Nachverfolgungsdaten Informationen für physische Objekte zusammenführen sollen, die von einem oder beiden von der Wahrnehmungsmaschine oder von anderen Straßensystemen erhalten wurden.
  • Beispiel 63 umfasst den Gegenstand von irgendeinem der Beispiele 43-61, wobei die Wahrnehmungsmaschine ein Maschinenlernmodell verwendet und die Sensordaten als Eingaben an das Maschinenlernmodell bereitstellt, um die physischen Objekte zu detektieren, und die Wahrnehmungsmaschine ferner ausgebildet ist, um die Bewegung der physischen Objekte innerhalb der Fahrumgebung zu verfolgen.
  • Beispiel 64 umfasst den Gegenstand von irgendeinem der Beispiele 43-63, wobei das System ein zumindest teilweise autonomes Fahrzeug umfasst, das sich innerhalb der Fahrumgebung bewegt, und das Fahrzeug eine Steuerung zur Steuerung der Bewegung des Fahrzeugs umfasst, basierend zumindest teilweise auf Sicherheitsnachrichten, die von anderen Systemen innerhalb der Fahrumgebung empfangen werden.
  • Beispiel 65 umfasst den Gegenstand von irgendeinem der Beispiele 43-64, wobei das System eine Straßenrandausrüstung zum Überwachen der Fahrumgebung umfasst.
  • Somit wurden bestimmte Ausführungsbeispiele des Gegenstands beschrieben. Andere Ausführungsbeispiele sind im Rahmen der folgenden Ansprüche. In einigen Fällen können die in den Ansprüchen genannten Handlungen in einer unterschiedlichen Reihenfolge durchgeführt werden und dennoch wünschenswerte Ergebnisse erzielen. Darüber hinaus erfordern die in den beiliegenden Figuren abgebildeten Prozesse nicht unbedingt die bestimmte gezeigte 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 62/812509 [0001]

Claims (65)

  1. Zumindest ein maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen durch eine Maschine ausführbar sind, um die Maschine zu veranlassen zum: Empfangen, an einem ersten Straßensystem, einer Kommunikation von einem zweiten Straßensystem über einen drahtlosen Kanal, wobei die Kommunikation eine Identifizierung des zweiten Straßensystems und Beschreibung eines physischen Objekts innerhalb einer Fahrumgebung umfasst, Bestimmen von Charakteristiken des physischen Objekts basierend auf Sensoren des ersten Straßensystems; Bestimmen, dass die Beschreibung des physischen Objekts in der Kommunikation eine Anomalie umfasst, basierend auf einem Vergleich mit den Charakteristiken; Erzeugen von Fehlverhaltensdaten, um die Anomalie zu beschreiben; und Bestimmen, ob basierend auf der Anomalie eine Abhilfehandlung initiiert werden soll.
  2. Das Speichermedium gemäß Anspruch 1, wobei die Fehlverhaltensdaten eine Fehlverhaltensberichtnachricht umfassen und die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Fehlverhaltensberichtnachricht an ein anderes System zu senden, um zumindest einen Abschnitt der Abhilfehandlung an dem anderen System zu initiieren.
  3. Das Speichermedium gemäß Anspruch 2, wobei die Identifizierung des zweiten Straßensystems Zugangsdaten des zweiten Straßensystems umfasst, um in eine drahtlose Kommunikation mit anderen Straßensystemen in der Fahrumgebung zu treten, die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Zugangsdaten des zweiten Straßensystems in Verbindung mit einem Empfang der Kommunikation zu überprüfen, und das andere System ein Sicherheitsstellensystem umfasst, um zu bestimmen, ob die Zugangsdaten des zweiten Straßensystems basierend auf einem der Anomalie zugeordneten Fehlverhalten zu widerrufen sind.
  4. Das Speichermedium gemäß Anspruch 2 oder 3, wobei das andere System ein anderes Straßensystem in der Fahrumgebung umfasst und die Fehlverhaltensdaten an das andere Straßensystem identifizieren, dass die Anomalie in der Kommunikation von dem zweiten Straßensystem detektiert wurde.
  5. Das Speichermedium gemäß Anspruch 2, 3 oder 4, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, eine andere Fehlverhaltensberichtnachricht von einem anderen Straßensystem zu empfangen, der andere Fehlverhaltensbericht eine durch das andere Straßensystem detektierte Anomalie identifiziert, umfassend eine Kommunikation von dem zweiten Straßensystem an dem anderen Straßensystem, und die Abhilfehandlung ferner basierend auf dem anderen Fehlverhaltensbericht bestimmt ist.
  6. Das Speichermedium gemäß Anspruch 5, wobei die Anweisungen ferner ausführbar sind, um zu bestimmen, ob eine Schwelle von Fehlverhaltensberichten erreicht wurde, und die Abhilfehandlung zumindest teilweise darauf basiert, ob die Schwelle erreicht wird.
  7. Das Speichermedium gemäß einem der Ansprüche 1-6, wobei die Abhilfehandlung ein Hinzufügen des zweiten Straßensystems zu einer Beobachtungsliste umfasst, eine zusätzliche Abhilfehandlung initiiert werden soll, wenn Anomalien durch das erste Straßensystem in nachfolgenden Kommunikationen von dem zweiten Straßensystem basierend auf einer Aufnahme des zweiten Straßensystems in der Beobachtungsliste detektiert werden.
  8. Das Speichermedium gemäß einem der Ansprüche 1-7, wobei die Abhilfehandlung ein Hinzufügen des Identifizierers des zweiten Straßensystems zu einer lokalen schwarzen Liste umfasst, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen zum: Abtasten von durch das erste Straßensystem empfangenen Kommunikationen, um zu bestimmen, ob Senderidentifizierer in der lokalen schwarzen Liste umfasst sind, und Nichtberücksichtigen von Kommunikationen von Sendern mit einem in der lokalen schwarzen Liste umfassten Senderidentifizierer.
  9. Das Speichermedium gemäß einem der Ansprüche 1-8, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, einen Grad der Divergenz in der Beschreibung des physischen Objekts in der Kommunikation von den Charakteristiken des physischen Objekts basierend auf Sensoren des ersten Straßensystems zu bestimmen, wobei das Initiieren der Abhilfehandlung auf dem Grad der Divergenz basiert.
  10. Das Speichermedium gemäß Anspruch 9, wobei die Anweisungen ferner ausführbar sind, um eine Menge von Anomalien in Kommunikationen von dem zweiten Straßensystem während eines Zeitfensters zu bestimmen, die Bestimmung, ob die Abhilfehandlung initiiert werden soll, darauf basiert, ob die Menge der Anomalien eine Schwelle überschreitet, und die Dauer des Zeitfensters auf dem Grad der Divergenz basiert.
  11. Das Speichermedium gemäß einem der Ansprüche 1-10, wobei die Kommunikation eine Sicherheitsnachricht umfasst, das erste Straßensystem ausgebildet ist, um das autonome Fahren eines Fahrzeugs zu steuern, und das erste Straßensystem ausgebildet ist, um das autonome Fahren basierend zumindest teilweise auf Sicherheitsnachrichten zu steuern, die von anderen Straßensystemen in der Fahrumgebung empfangen werden.
  12. Das Speichermedium gemäß Anspruch 11, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Sicherheitsnachricht zu überprüfen, um zu bestimmen, ob eine Position des physischen Objekts innerhalb eines angenommenen Bereichs ist. Nachricht überprüft im Hinblick auf Annahmen
  13. Das Speichermedium gemäß einem der Ansprüche 11-12, wobei zumindest eine andere Sicherheitsnachricht von einem anderen Straßensystem empfangen wird und das physische Objekt beschreibt, und die Anomalie ferner auf einem Vergleich von Inhalten der Sicherheitsnachricht mit Informationen in der anderen Sicherheitsnachricht basiert.
  14. Das Speichermedium gemäß einem der Ansprüche 11-13, wobei die Sicherheitsnachricht eine zweite Sicherheitsnachricht ist, die von dem zweiten Straßensystem nach dem Empfang einer ersten Sicherheitsnachricht von dem zweiten Straßensystem empfangen wird, die erste Sicherheitsnachricht auch das physische Objekt beschreibt und die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen zum: Bestimmen, anhand eines Modells, eines erwarteten Zustands des physischen Objekts basierend auf der ersten Sicherheitsnachricht; Bestimmen, ob die Beschreibung des physischen Objekts in der zweiten Sicherheitsnachricht von dem erwarteten Zustand divergiert, wobei die Anomalie ferner auf der Bestimmung einer Divergenz zwischen der Beschreibung des physischen Objekts und dem erwarteten Zustand basiert.
  15. Das Speichermedium gemäß einem der Ansprüche 1-14, wobei die Anweisungen ferner ausführbar sind, um Nachverfolgungsdaten zur Verfolgung des physischen Objekts zu erzeugen.
  16. Das Speichermedium gemäß Anspruch 15, wobei die jeweiligen Nachverfolgungsdaten für jedes eine von einer Mehrzahl von physischen Objekten, die innerhalb der Fahrumgebung detektiert oder gemeldet werden, geführt werden.
  17. Das Speichermedium gemäß einem der Ansprüche 15-16, wobei die Nachverfolgungsdaten als eine gemeldete Objektnachverfolgung (VT), eine wahrgenommene Objektnachverfolgung (LT) oder eine gemischte Nachverfolgung (MT), umfassend sowohl gemeldete als auch wahrgenommene Informationen, gekennzeichnet sind.
  18. Das Speichermedium gemäß Anspruch 17, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen zum: Identifizieren vorhandener Nachverfolgungsdaten für das physische Objekt, wobei die vorhandenen Nachverfolgungsdaten eine gemischte Nachverfolgung umfassen, basierend zumindest teilweise auf einer zuvor empfangenen Kommunikation zur Beschreibung des physischen Objekts; und Ändern der Bezeichnung des vorhandenen Nachverfolgungsdatums von MT zu LT basierend auf der Anomalie.
  19. Das Speichermedium gemäß einem der Ansprüche 15-17, wobei die Nachverfolgungsdaten ausgebildet sind, um Informationen für physische Objekte zusammenzuführen, die entweder intern durch das erste Straßensystem oder von anderen Straßensystemen empfangen wurden oder beides.
  20. Das Speichermedium gemäß einem der Ansprüche 1-19, wobei jedes von dem ersten und zweiten Straßensystem jeweils ein autonomes Fahrzeug oder eine Straßenrandeinheit umfasst.
  21. Ein Verfahren, umfassend: Empfangen, an einem ersten Straßensystem, einer Kommunikation von einem zweiten Straßensystem über einen drahtlosen Kanal, wobei die Kommunikation eine Identifizierung des zweiten Straßensystems und Beschreibung eines physischen Objekts innerhalb einer Fahrumgebung umfasst, Bestimmen von Charakteristiken des physischen Objekts basierend auf Sensoren des ersten Straßensystems; Bestimmen, dass die Beschreibung des physischen Objekts in der Kommunikation eine Anomalie umfasst, basierend auf einem Vergleich mit den Charakteristiken; Erzeugen von Fehlverhaltensdaten, um die Anomalie zu beschreiben; und Bestimmen, ob basierend auf der Anomalie eine Abhilfehandlung initiiert werden soll, wobei die Abhilfehandlung ausgebildet ist, um das erste Straßensystem daran zu hindern, nachfolgende anomale Kommunikationen zu berücksichtigen.
  22. Das Verfahren gemäß Anspruch 21, ferner umfassend ein Senden der Fehlverhaltensdaten an ein anderes System als eine Fehlverhaltensberichtnachricht, wobei die Fehlverhaltensberichtnachricht ein potenzielles Fehlverhalten durch das zweite Straßensystem basierend auf der Anomalie meldet.
  23. Das Verfahren gemäß einem der Ansprüche 21-22, wobei die Fehlverhaltensdaten eine Fehlverhaltensberichtnachricht umfassen und das Verfahren ferner ein Senden der Fehlverhaltensberichtnachricht an ein anderes System umfasst, um zumindest einen Abschnitt der Abhilfehandlung an dem anderen System zu initiieren.
  24. Das Verfahren gemäß Anspruch 23, wobei die Identifizierung des zweiten Straßensystems Zugangsdaten des zweiten Straßensystems umfasst, um in eine drahtlose Kommunikation mit anderen Straßensystemen in der Fahrumgebung zu treten, das Verfahren ferner die Überprüfung der Zugangsdaten des zweiten Straßensystems in Verbindung mit einem Empfang der Kommunikation umfasst, und das andere System ein Sicherheitsstellensystem umfasst, um zu bestimmen, ob die Zugangsdaten des zweiten Straßensystems basierend auf einem der Anomalie zugeordneten Fehlverhalten zu widerrufen sind.
  25. Das Verfahren gemäß einem der Ansprüche 23-24, wobei das andere System ein anderes Straßensystem in der Fahrumgebung umfasst und die Fehlverhaltensdaten an das andere Straßensystem identifizieren, dass die Anomalie in der Kommunikation von dem zweiten Straßensystem detektiert wurde.
  26. Das Verfahren gemäß einem der Ansprüche 23-25, ferner umfassend ein Empfangen einer anderen Fehlverhaltensberichtnachricht von einem anderen Straßensystem, der andere Fehlverhaltensbericht eine Anomalie identifiziert, die durch das andere Straßensystem detektiert wurde, umfassend eine Kommunikation von dem zweiten Straßensystem an dem anderen Straßensystem, und die Abhilfehandlung ferner basierend auf dem anderen Fehlverhaltensbericht bestimmt wird.
  27. Das Verfahren gemäß Anspruch 26, ferner umfassend ein Bestimmen, ob eine Schwelle von Fehlverhaltensberichten erreicht wurde, und die Abhilfehandlung basiert zumindest teilweise darauf, ob die Schwelle erreicht wird.
  28. Das Verfahren gemäß einem der Ansprüche 21-27, wobei die Abhilfehandlung ein Hinzufügen des zweiten Straßensystems zu einer Beobachtungsliste umfasst, eine zusätzliche Abhilfehandlung initiiert werden soll, wenn Anomalien durch das erste Straßensystem in nachfolgenden Kommunikationen von dem zweiten Straßensystem basierend auf dem Umfassen des zweiten Straßensystems in der Beobachtungsliste detektiert werden.
  29. Das Verfahren gemäß einem der Ansprüche 21-28, wobei die Abhilfehandlung ein Hinzufügen des Identifizierers des zweiten Straßensystems zu einer lokalen schwarzen Liste umfasst, und das Verfahren ferner umfassend: Abtasten von durch das erste Straßensystem empfangenen Kommunikationen, um zu bestimmen, ob Senderidentifizierer in der lokalen schwarzen Liste umfasst sind, und Nichtberücksichtigen von Kommunikationen von Sendern mit einem in der lokalen schwarzen Liste umfassten Senderidentifizierer.
  30. Das Verfahren gemäß einem der Ansprüche 21-29, ferner umfassend ein Bestimmen eines Grades an Divergenz in der Beschreibung des physischen Objekts in der Kommunikation von den Charakteristiken des physischen Objekts basierend auf Sensoren des ersten Straßensystems, wobei die Initiierung der Abhilfehandlung auf dem Grad der Divergenz basiert.
  31. Das Verfahren gemäß Anspruch 30, ferner umfassend ein Bestimmen einer Menge von Anomalien in Kommunikationen von dem zweiten Straßensystem während eines Zeitfensters, ein Bestimmen, ob die Abhilfehandlung zu initiieren ist, basiert darauf, ob die Menge der Anomalien eine Schwelle überschreitet, und die Dauer des Zeitfensters basiert auf dem Grad der Divergenz.
  32. Das Verfahren gemäß einem der Ansprüche 21-31, wobei die Kommunikation eine Sicherheitsnachricht umfasst, das erste Straßensystem ausgebildet ist, um das autonome Fahren eines Fahrzeugs zu steuern, und das erste Straßensystem ausgebildet ist, um das autonome Fahren basierend zumindest teilweise auf Sicherheitsnachrichten zu steuern, die von anderen Straßensystemen in der Fahrumgebung empfangen werden.
  33. Das Verfahren gemäß Anspruch 32, ferner umfassend ein Überprüfen der Sicherheitsnachricht, um zu bestimmen, ob eine Position des physischen Objekts innerhalb eines angenommenen Bereichs ist. Nachricht überprüft im Hinblick auf Annahmen
  34. Das Verfahren gemäß einem der Ansprüche 32-33, wobei zumindest eine andere Sicherheitsnachricht von einem anderen Straßensystem empfangen wird und das physische Objekt beschreibt, und die Anomalie ferner auf einem Vergleich von Inhalten der Sicherheitsnachricht mit Informationen in der anderen Sicherheitsnachricht basiert.
  35. Das Verfahren gemäß einem der Ansprüche 32-34, wobei die Sicherheitsnachricht eine zweite Sicherheitsnachricht ist, die von dem zweiten Straßensystem nach dem Empfang einer ersten Sicherheitsnachricht von dem zweiten Straßensystem empfangen wird, die erste Sicherheitsnachricht auch das physische Objekt beschreibt und das Verfahren ferner umfassend: Bestimmen, anhand eines Modells, eines erwarteten Zustands des physischen Objekts basierend auf der ersten Sicherheitsnachricht: und Bestimmen, ob die Beschreibung des physischen Objekts in der zweiten Sicherheitsnachricht von dem erwarteten Zustand divergiert, wobei die Anomalie ferner auf der Bestimmung einer Divergenz zwischen der Beschreibung des physischen Objekts und dem erwarteten Zustand basiert.
  36. Das Verfahren gemäß einem der Ansprüche 21-35, ferner umfassend ein Erzeugen von Nachverfolgungsdaten zum Verfolgen des physischen Objekts.
  37. Das Verfahren gemäß Anspruch 36, wobei die jeweiligen Nachverfolgungsdaten für jedes eine einer Mehrzahl von physischen Objekten, die innerhalb der Fahrumgebung detektiert oder gemeldet werden, geführt werden.
  38. Das Verfahren gemäß einem der Ansprüche 36-37, wobei die Nachverfolgungsdaten als eine gemeldete Objektnachverfolgung (VT), eine wahrgenommene Objektnachverfolgung (LT) oder eine gemischte Nachverfolgung (MT), umfassend sowohl gemeldete als auch wahrgenommene Informationen, gekennzeichnet sind.
  39. Das Verfahren gemäß Anspruch 38, ferner umfassend: Identifizieren vorhandener Nachverfolgungsdaten für das physische Objekt, wobei die vorhandenen Nachverfolgungsdaten eine gemischte Nachverfolgung umfassen, basierend zumindest teilweise auf einer zuvor empfangenen Kommunikation zur Beschreibung des physischen Objekts; und Ändern der Bezeichnung des vorhandenen Nachverfolgungsdatums von MT zu LT basierend auf der Anomalie.
  40. Das Verfahren gemäß einem der Ansprüche 37-39, wobei die Nachverfolgungsdaten ausgebildet sind, um Informationen für physische Objekte zusammenzuführen, die entweder intern durch das erste Straßensystem oder von anderen Straßensystemen empfangen wurden oder beides.
  41. Das Verfahren gemäß einem der Ansprüche 21-40, wobei jedes von dem ersten und zweiten Straßensystem jeweils ein autonomes Fahrzeug oder eine Straßenrandeinheit umfasst.
  42. Ein System, umfassend Mittel zum Durchführen des Verfahrens gemäß einem der Ansprüche 21-41.
  43. Ein System, umfassend: einen oder mehrere Datenprozessoren; einen Speicher; einen Satz von Sensoren; eine Wahrnehmungsmaschine, ausführbar durch zumindest einen von dem einen oder den mehreren Datenprozessoren zur Verwendung von Sensordaten, die durch den Satz von Sensoren erzeugt werden, um Charakteristiken von physischen Objekten innerhalb einer Fahrumgebung zu bestimmen; und eine Fehlverhaltensdetektionsmaschine, ausführbar durch zumindest einen von dem einen oder den mehreren Datenprozessoren zum: Identifizieren einer Beschreibung eines bestimmten physischen Objekts in einer von einem bestimmten Straßensystem empfangenen Sicherheitsnachricht; Vergleichen von Charakteristiken des bestimmten physischen Objekts, die durch die Wahrnehmungsmaschine basierend auf den Sensordaten bestimmt sind, um eine Anomalie in der Beschreibung zu bestimmen; Bestimmen, ob die Sicherheitsnachricht ein Fehlverhalten durch das bestimmte Straßensystem umfasst, basierend zumindest teilweise auf der Anomalie; und Initiieren einer Abhilfehandlung basierend auf der Anomalie.
  44. Das System gemäß Anspruch 43, wobei die Fehlverhaltensdetektionsmaschine ferner ausgebildet ist, um Fehlverhaltensdaten basierend auf der Anomalie zu erzeugen.
  45. Das System gemäß Anspruch 44, wobei die Fehlverhaltensdaten eine Fehlverhaltensberichtnachricht umfassen und die Fehlverhaltensdetektionsmaschine ausgebildet ist, um die Fehlverhaltensberichtnachricht an ein anderes System zu senden, um zumindest einen Abschnitt der Abhilfehandlung an dem anderen System zu initiieren.
  46. Das System gemäß Anspruch 45, wobei die Sicherheitsnachricht Zugangsdaten des bestimmten Straßensystems umfasst, um in eine Sicherheitsnachrichtkommunikation mit anderen Straßensystemen in der Fahrumgebung zu treten, die Fehlverhaltensdetektionsmaschine ausgebildet ist, um die Zugangsdaten des bestimmten Straßensystems in Verbindung mit einem Empfang der Sicherheitsnachricht zu überprüfen, und das andere System ein Sicherheitsstellensystem umfasst, um zu bestimmen, ob die Zugangsdaten des bestimmten Straßensystems basierend auf der Anomalie zugeordnetem Fehlverhalten widerrufen werden sollen.
  47. Das System gemäß Anspruch 45 oder 46, wobei das andere System ein anderes Straßensystem in der Fahrumgebung umfasst und die Fehlverhaltensdaten an das andere Straßensystem identifizieren, dass die Anomalie in der Kommunikation von dem bestimmten Straßensystem detektiert wurde.
  48. Das System gemäß Anspruch 45, 46 oder 47, wobei die Fehlverhaltensdetektionsmaschine ferner ausgebildet ist, um eine andere Fehlverhaltensberichtnachricht von einem anderen Straßensystem zu empfangen, der andere Fehlverhaltensbericht eine durch das andere Straßensystem detektierte Anomalie identifiziert, umfassend eine andere Sicherheitsnachricht von dem bestimmten Straßensystem an dem anderen Straßensystem, und die Abhilfehandlung ferner basierend auf dem anderen Fehlverhaltensbericht bestimmt wird.
  49. Das System gemäß Anspruch 48, wobei die Anweisungen ferner ausführbar sind, um zu bestimmen, ob eine Schwelle von Fehlverhaltensberichten erreicht wurde, und die Abhilfehandlung zumindest teilweise darauf basiert, ob die Schwelle erreicht wird.
  50. Das System gemäß einem der Ansprüche 43-49, wobei die Abhilfehandlung ein Hinzufügen des bestimmten Straßensystems zu einer Beobachtungsliste umfasst, eine zusätzliche Abhilfehandlung zu initiieren ist, wenn Anomalien durch das erste Straßensystem in nachfolgenden Sicherheitsnachrichten von dem bestimmten Straßensystem basierend auf einer Aufnahme des bestimmten Straßensystems in die Beobachtungsliste detektiert werden.
  51. Das System gemäß einem der Ansprüche 43-50, wobei die Abhilfehandlung ein Hinzufügen des Identifizierers des bestimmten Straßensystems zu einer lokalen schwarzen Liste umfasst, wobei die Fehlverhaltensdetektionsmaschine ferner ausgebildet ist zum: Abtasten von empfangenen Sicherheitsnachrichten, um zu bestimmen, ob Senderidentifizierer in der lokalen schwarzen Liste umfasst sind; und Nichtberücksichtigen von Kommunikationen von Sendern mit einem in der lokalen schwarzen Liste umfassten Senderidentifizierer.
  52. Das System gemäß einem der Ansprüche 43-51, wobei die Fehlverhaltensdetektionsmaschine ferner ausgebildet ist, um einen Grad an Divergenz in der Beschreibung des physischen Objekts in der Kommunikation von den Charakteristiken des physischen Objekts basierend auf Sensoren des ersten Straßensystems zu bestimmen, wobei die Initiierung der Abhilfehandlung auf dem Grad der Divergenz basiert.
  53. Das System gemäß Anspruch 52, wobei die Anweisungen ferner ausführbar sind, um eine Menge von Anomalien in Kommunikationen von dem bestimmten Straßensystem während eines Zeitfensters zu bestimmen, die Bestimmung, ob die Abhilfehandlung initiiert werden soll, darauf basiert, ob die Menge der Anomalien eine Schwelle überschreitet, und die Dauer des Zeitfensters auf dem Grad der Divergenz basiert.
  54. Das System gemäß einem der Ansprüche 43-53, ferner umfassend autonome Fahrsteuerungen, um das autonome Fahren eines Fahrzeugs zu steuern, und die autonomen Fahrsteuerungen sind ausgebildet, um das autonome Fahren basierend zumindest teilweise auf Sicherheitsnachrichten, die von anderen Straßensystemen in der Fahrumgebung empfangen werden, zu steuern.
  55. Das System gemäß Anspruch 54, wobei die Fehlverhaltensdetektionsmaschine ferner ausgebildet ist, um die Sicherheitsnachricht zu überprüfen, um zu bestimmen, ob eine Position des physischen Objekts innerhalb eines angenommenen Bereichs ist. Nachricht überprüft im Hinblick auf Annahmen
  56. Das System gemäß einem der Ansprüche 54-55, wobei zumindest eine andere Sicherheitsnachricht von einem anderen Straßensystem empfangen wird und das physische Objekt beschreibt, und die Anomalie ferner auf einem Vergleich von Inhalten der Sicherheitsnachricht mit Informationen in der anderen Sicherheitsnachricht basiert.
  57. Das System gemäß einem der Ansprüche 54-56, wobei die Sicherheitsnachricht eine zweite Sicherheitsnachricht ist, die von dem bestimmten Straßensystem nach dem Empfang einer ersten Sicherheitsnachricht von dem bestimmten Straßensystem empfangen wird, die erste Sicherheitsnachricht auch das physische Objekt beschreibt und die Fehlverhaltensdetektionsmaschine ferner ausgebildet ist zum: Bestimmen, anhand eines Modells, eines erwarteten Zustands des physischen Objekts basierend auf der ersten Sicherheitsnachricht; Bestimmen, ob die Beschreibung des physischen Objekts in der zweiten Sicherheitsnachricht von dem erwarteten Zustand divergiert, wobei die Anomalie ferner auf der Bestimmung einer Divergenz zwischen der Beschreibung des physischen Objekts und dem erwarteten Zustand basiert.
  58. Das System gemäß einem der Ansprüche 43-57, wobei die Anweisungen ferner ausführbar sind, um Nachverfolgungsdaten zur Verfolgung des physischen Objekts zu erzeugen.
  59. Das System gemäß Anspruch 58, wobei die jeweiligen Nachverfolgungsdaten für jedes eine von einer Mehrzahl von physischen Objekten, die innerhalb der Fahrumgebung detektiert oder gemeldet werden, geführt werden.
  60. Das System gemäß einem der Ansprüche 58-59, wobei die Nachverfolgungsdaten als eine gemeldete Objektnachverfolgung (VT), eine wahrgenommene Objektnachverfolgung (LT) oder eine gemischte Nachverfolgung (MT), umfassend sowohl gemeldete als auch wahrgenommene Informationen, gekennzeichnet sind.
  61. Das System gemäß Anspruch 60, wobei die Fehlverhaltensdetektionsmaschine ferner ausgebildet ist zum: Identifizieren vorhandener Nachverfolgungsdaten für das physische Objekt, wobei die vorhandenen Nachverfolgungsdaten eine gemischte Nachverfolgung umfassen, basierend zumindest teilweise auf einer zuvor empfangenen Kommunikation zur Beschreibung des physischen Objekts; und Ändern der Bezeichnung des vorhandenen Nachverfolgungsdatums von MT zu LT basierend auf der Anomalie.
  62. Das System gemäß einem der Ansprüche 59-61, wobei die Nachverfolgungsdaten ausgebildet sind, um Informationen für physische Objekte zusammenzuführen, die von einem oder beiden von der Wahrnehmungsmaschine oder von anderen Straßensystemen erhalten wurden.
  63. Das System gemäß einem der Ansprüche 43-61, wobei die Wahrnehmungsmaschine ein Maschinenlernmodell verwendet und die Sensordaten als Eingaben an das Maschinenlernmodell bereitstellt, um die physischen Objekte zu detektieren, und die Wahrnehmungsmaschine ferner ausgebildet ist, um die Bewegung der physischen Objekte innerhalb der Fahrumgebung zu verfolgen.
  64. Das System gemäß einem der Ansprüche 43-63, wobei das System ein zumindest teilweise autonomes Fahrzeug zum Bewegen innerhalb der Fahrumgebung umfasst.
  65. Das System gemäß einem der Ansprüche 43-64, wobei das System eine Straßenrandausrüstung zum Überwachen der Fahrumgebung umfasst.
DE102020102426.6A 2019-03-01 2020-01-31 Fehlverhaltensdetektion in autonomen Fahrkommunikationen Pending DE102020102426A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201962812509P 2019-03-01 2019-03-01
US62/812,509 2019-03-01
US16/729,250 US11553346B2 (en) 2019-03-01 2019-12-27 Misbehavior detection in autonomous driving communications
US16/729,250 2019-12-27

Publications (1)

Publication Number Publication Date
DE102020102426A1 true DE102020102426A1 (de) 2020-09-03

Family

ID=70326213

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020102426.6A Pending DE102020102426A1 (de) 2019-03-01 2020-01-31 Fehlverhaltensdetektion in autonomen Fahrkommunikationen

Country Status (2)

Country Link
US (2) US11553346B2 (de)
DE (1) DE102020102426A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220067020A1 (en) * 2020-08-26 2022-03-03 Ford Global Technologies, Llc Anomaly detection in multidimensional sensor data
DE102020214347A1 (de) 2020-11-16 2022-05-19 Volkswagen Aktiengesellschaft Bahnplanung eines Fahrzeugs
DE102022106028A1 (de) 2022-01-29 2023-08-03 GM Global Technology Operations LLC Systeme und verfahren zum erkennen von fehlverhalten bei einem autonomen fahrsystem
DE102022106030A1 (de) 2022-01-29 2023-08-03 GM Global Technology Operations LLC Systeme und verfahren zur erkennung von fehlverhalten auf der grundlage von fusionsdaten bei einem autonomen fahrsystem

Families Citing this family (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3076045A1 (fr) * 2017-12-22 2019-06-28 Orange Procede de surveillance d'un environnement d'un premier element positionne au niveau d'une voie de circulation, et systeme associe
US11520297B2 (en) * 2019-03-29 2022-12-06 Intel Corporation Enhancing diagnostic capabilities of computing systems by combining variable patrolling API and comparison mechanism of variables
US11170640B2 (en) * 2019-05-14 2021-11-09 Ford Global Technologies, Llc Method and apparatus for bridging and optimizing V2X networks
US20190318257A1 (en) * 2019-06-28 2019-10-17 Helen Adrienne Frances Gould Assessment and response mechanism for autonomous systems
US11456890B2 (en) * 2019-07-16 2022-09-27 Baidu Usa Llc Open and safe monitoring system for autonomous driving platform
US11350239B2 (en) * 2019-07-17 2022-05-31 Ford Global Technologies, Llc Smart mmWave c-V2X antenna
US11787407B2 (en) * 2019-07-24 2023-10-17 Pony Ai Inc. System and method for sensing vehicles and street
US11574538B2 (en) * 2019-08-16 2023-02-07 GM Global Technology Operations LLC Method and apparatus for perception-sharing between vehicles
JP7382791B2 (ja) * 2019-10-30 2023-11-17 株式会社日立製作所 異常判定装置、車両支援システム
US11468716B2 (en) * 2019-12-11 2022-10-11 Volvo Car Corporation Vehicle resource management systems
CN113055846A (zh) * 2019-12-26 2021-06-29 索尼公司 电子设备、无线通信方法和计算机可读存储介质
US11368826B2 (en) * 2020-01-27 2022-06-21 Ford Global Technologies, Llc Method and apparatus for bridging and optimizing V2X networks in vehicles
US11792014B2 (en) * 2020-03-16 2023-10-17 Uatc, Llc Systems and methods for vehicle message signing
WO2021184313A1 (zh) * 2020-03-19 2021-09-23 华为技术有限公司 证书列表更新方法及装置
IT202000006340A1 (it) * 2020-03-25 2021-09-25 Cleafy Spa Metodo per monitorare e proteggere l’accesso ad un servizio online
US11008018B1 (en) * 2020-03-25 2021-05-18 Toyota Research Institute, Inc. Risk prediction on a peer-to-peer network
IT202000006265A1 (it) 2020-03-25 2021-09-25 Cleafy Spa Metodo per monitorare e proteggere l’accesso ad un servizio online
IT202000006343A1 (it) 2020-03-25 2021-09-25 Cleafy Spa Metodo per monitorare e proteggere l’accesso ad un servizio online
WO2021198789A1 (en) * 2020-04-01 2021-10-07 Mobileye Vision Technologies Ltd. Evaluating a floating-point accuracy of a compiler
CN113496602B (zh) * 2020-04-03 2023-01-31 上海丰豹商务咨询有限公司 智能路侧工具箱
US11794762B2 (en) * 2020-04-10 2023-10-24 Toyota Research Institute, Inc. Peer-to-peer occupancy estimation
CN111824307B (zh) * 2020-06-18 2021-08-24 北京骑胜科技有限公司 交通工具控制方法、装置、设备、交通工具和介质
US11659372B2 (en) * 2020-07-30 2023-05-23 Toyota Motor Engineering & Manufacturing North America, Inc. Adaptive sensor data sharing for a connected vehicle
US20220068122A1 (en) * 2020-08-27 2022-03-03 Toyota Motor Engineering & Manufacturing North America, Inc. Systems and methods to group and move vehicles cooperatively to mitigate anomalous driving behavior
US11516669B2 (en) * 2020-09-22 2022-11-29 Toyota Motor Engineering & Manufacturing North America, Inc. Misbehavior detection for vehicle-to-everything messages
KR102329889B1 (ko) * 2020-09-23 2021-11-23 펜타시큐리티시스템 주식회사 로드 사이드 유닛의 이상 감지 방법 및 장치
DE102020212565A1 (de) * 2020-10-06 2022-04-07 Volkswagen Aktiengesellschaft Fahrzeug, Vorrichtung, Computerprogramm und Verfahren zur Durchführung in einem Fahrzeug
US11003919B1 (en) 2020-10-16 2021-05-11 Hayden Al Technologies, Inc. Systems and methods for detecting traffic violations using mobile detection devices
US11868137B2 (en) * 2020-11-12 2024-01-09 Honda Motor Co., Ltd. Systems and methods for path planning with latent state inference and graphical relationships
US12063511B2 (en) * 2020-12-22 2024-08-13 Intel Corporation Pathloss drop trusted agent misbehavior detection
US11663908B2 (en) * 2021-01-14 2023-05-30 Qualcomm Incorporated Method and system for misbehavior detection report management routing
TW202231088A (zh) * 2021-01-14 2022-08-01 美商高通公司 用於異常行為偵測報告管理路由的方法和系統
US20220219731A1 (en) * 2021-01-14 2022-07-14 Cavh Llc Intelligent information conversion for automatic driving
BR112023013691A2 (pt) * 2021-01-19 2023-12-12 Qualcomm Inc Sistema local de prevenção de comportamento incorreto para sistemas cooperativos de transporte inteligente
US12003966B2 (en) * 2021-01-19 2024-06-04 Qualcomm Incorporated Local misbehavior prevention system for cooperative intelligent transportation systems
US12008895B2 (en) * 2021-01-19 2024-06-11 Qualcomm Incorporated Vehicle-to-everything (V2X) misbehavior detection using a local dynamic map data model
US20220258739A1 (en) * 2021-02-17 2022-08-18 Qualcomm Incorporated Method and System for Generating a Confidence Value in a Position Overlap Check Using Vehicle Threshold Models
IT202100006383A1 (it) * 2021-03-17 2022-09-17 Cleafy Spa Metodo per monitorare e proteggere l’accesso ad un servizio online
US11405786B1 (en) * 2021-03-25 2022-08-02 Qualcomm Incorporated Detecting misbehavior conditions in vehicle-to-everything (V2X) messages
CN113420805B (zh) * 2021-06-21 2022-11-29 车路通科技(成都)有限公司 视频和雷达的动态轨迹图像融合方法、装置、设备及介质
US20230095194A1 (en) * 2021-09-30 2023-03-30 AyDeeKay LLC dba Indie Semiconductor Dynamic and Selective Pairing Between Proximate Vehicles
US11722865B2 (en) * 2021-10-11 2023-08-08 Qualcomm Incorporated Vehicle-to-everything (V2X) information verification for misbehavior detection
CN114040406B (zh) * 2021-10-27 2024-04-26 海信集团控股股份有限公司 一种车载设备的异常信息检测方法及装置
US20230230421A1 (en) * 2022-01-19 2023-07-20 Toyota Motor Engineering & Manufacturing North America, Inc. Knowledge transfer for early unsafe driving behavior recognition
CN114613130B (zh) * 2022-02-18 2023-05-12 北京理工大学 交通与运载系统中驾驶可信性分析方法
US20230300640A1 (en) * 2022-03-16 2023-09-21 Qualcomm Incorporated Notifying local vehicle-to-everything misbehavior to receive-side local misbehavior detection system
WO2023209409A1 (en) * 2022-04-26 2023-11-02 Commsignia Kft. Data processing method and system for iterative sensor fusion, computer program product and computer readable medium for implementing the method
US20240013655A1 (en) * 2022-07-05 2024-01-11 Qualcomm Incorporated Misbehavior detection in a vehicle-to-everything (v2x) maneuver coordination message
US20240022909A1 (en) * 2022-07-12 2024-01-18 Qualcomm Incorporated Network response against malicious nodes
CN117528451A (zh) * 2022-07-26 2024-02-06 通用汽车环球科技运作有限责任公司 基于雷达和摄像头融合的无线通信不当行为检测
WO2024119401A1 (zh) * 2022-12-07 2024-06-13 华为技术有限公司 异常检测的方法、装置和车辆
CN116954201A (zh) * 2023-01-18 2023-10-27 腾讯科技（深圳）有限公司 车辆控制方法、装置、设备、存储介质及程序产品
US20240321103A1 (en) * 2023-03-21 2024-09-26 Sonamore, Inc. dba P3Mobility Method, system, and computer program for high confidence object-actor run-time detection, classification, and tracking
CN118354228B (zh) * 2024-04-25 2024-10-18 北京茵沃汽车科技有限公司 基于传感器系统的通信方法、电子设备

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8708820B2 (en) * 2009-11-16 2014-04-29 Igt Movable mechanical display devices and methods
JP2015141209A (ja) * 2014-01-27 2015-08-03 セイコーエプソン株式会社 アクチュエーター制御装置、光学モジュール、及び電子機器
EP3259731A4 (de) * 2015-02-16 2018-09-05 Synergy Blue, LLC In kasinospielnetzwerken implementierte, verbesserte on-demand-dienstfunktionalität
GB201504695D0 (en) * 2015-03-19 2015-05-06 Biotechflow Ltd Chromatography columns and processes
US10556600B2 (en) * 2015-12-09 2020-02-11 Toyota Motor Engineering & Manufacturing North America, Inc. Assessment of human driving performance using autonomous vehicles
US10308246B1 (en) * 2016-01-22 2019-06-04 State Farm Mutual Automobile Insurance Company Autonomous vehicle signal control
US11507064B2 (en) * 2016-05-09 2022-11-22 Strong Force Iot Portfolio 2016, Llc Methods and systems for industrial internet of things data collection in downstream oil and gas environment
US11074220B2 (en) * 2017-01-06 2021-07-27 Oracle International Corporation Consistent file system semantics with cloud object storage
US20190206258A1 (en) * 2018-01-04 2019-07-04 nuTonomy Inc. Augmented reality vehicle interfacing
US10757815B2 (en) 2018-01-09 2020-08-25 Carnegie Mellon University Method for fabrication of a soft-matter printed circuit board
US20190039612A1 (en) 2018-09-28 2019-02-07 Intel Corporation Technologies To Facilitate Automated Driving Assistance Based On Objects Sensed And Reported By Remote Senders
US11024180B2 (en) 2018-12-27 2021-06-01 Intel Corporation Methods and apparatus to validate data communicated by a vehicle
US11445362B2 (en) * 2019-03-01 2022-09-13 Intel Corporation Security certificate management and misbehavior vehicle reporting in vehicle-to-everything (V2X) communication
US20200017114A1 (en) * 2019-09-23 2020-01-16 Intel Corporation Independent safety monitoring of an automated driving system
US20200026289A1 (en) * 2019-09-28 2020-01-23 Ignacio J. Alvarez Distributed traffic safety consensus

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220067020A1 (en) * 2020-08-26 2022-03-03 Ford Global Technologies, Llc Anomaly detection in multidimensional sensor data
US11893004B2 (en) * 2020-08-26 2024-02-06 Ford Global Technologies, Llc Anomaly detection in multidimensional sensor data
DE102020214347A1 (de) 2020-11-16 2022-05-19 Volkswagen Aktiengesellschaft Bahnplanung eines Fahrzeugs
DE102022106028A1 (de) 2022-01-29 2023-08-03 GM Global Technology Operations LLC Systeme und verfahren zum erkennen von fehlverhalten bei einem autonomen fahrsystem
DE102022106030A1 (de) 2022-01-29 2023-08-03 GM Global Technology Operations LLC Systeme und verfahren zur erkennung von fehlverhalten auf der grundlage von fusionsdaten bei einem autonomen fahrsystem
US11981351B2 (en) 2022-01-29 2024-05-14 GM Global Technology Operations LLC Systems and methods for detecting misbehavior behavior based on fusion data at an autonomous driving system
US12017665B2 (en) 2022-01-29 2024-06-25 GM Global Technology Operations LLC Systems and methods for detecting misbehavior behavior at an autonomous driving system

Also Published As

Publication number Publication date
US11553346B2 (en) 2023-01-10
US11863991B2 (en) 2024-01-02
US20230284029A1 (en) 2023-09-07
US20200137580A1 (en) 2020-04-30

Similar Documents

Publication Publication Date Title
DE102020102426A1 (de) Fehlverhaltensdetektion in autonomen Fahrkommunikationen
DE112020004587T5 (de) Verteilter verkehrssicherheitskonsens
DE112020001649T5 (de) Autonomes fahrzeugsystem
DE112019005425T5 (de) Redundanz in autonomen fahrzeugen
EP3614223A1 (de) Verfahren, system und notsteuerungsvorrichtung zur verkehrsverwaltung von autonomen fahrzeugen in notsituationen
DE102020122757A1 (de) Systeme und verfahren für mitfahrgelegenheiten unter verwendung von blockchain
DE102020128433A1 (de) Simulation eines autonomen Fahrzeugs zur Verbesserung der Sicherheit und Zuverlässigkeit eines autonomen Fahrzeugs
DE102016217645A1 (de) Verfahren zum Bereitstellen von Information über eine voraussichtliche Fahrintention eines Fahrzeugs
US20220068122A1 (en) Systems and methods to group and move vehicles cooperatively to mitigate anomalous driving behavior
DE102021131848A1 (de) Sicherheits-gateway
DE102018221740A1 (de) Verfahren, Vorrichtung und Computerprogramm für ein Fahrzeug
US20230211805A1 (en) Concept For Supporting a Motor Vehicle Being Guided in at Least Partially Automated Manner
DE102021124931A1 (de) Vorrichtungsbereitstellung und -autentifizierung
DE102020211478A1 (de) Konzept zum Unterstützen eines zumindest teilautomatisiert geführten Kraftfahrzeugs
Alshdadi Cyber-physical system with IoT-based smart vehicles
DE102021123721A1 (de) Fahrzeugbetrieb unter verwendung eines verhaltensregelmodells
DE102021133346A1 (de) Sitzungsschlüsselerzeugung für einen betrieb autonomer fahrzeuge
Sabaliauskaite et al. Integrated safety and cybersecurity risk analysis of cooperative intelligent transport systems
DE102021209134A1 (de) Verfahren und Vorrichtung zur Validierung von Fahrzeug-zu-X Nachrichten zur Regelung des Verkehrsflusses
DE112022003364T5 (de) Komplementäres steuersystem für ein autonomes fahrzeug
DE102021133367A1 (de) Sitzungsschlüsselerzeugung für einen betrieb autonomer fahrzeuge
DE102021110247A1 (de) Steuerung der Stromversorgung elektronischer Vorrichtungen in einem Fahrzeug
WO2023103459A1 (zh) 车辆控制方法、决策服务器及存储介质
DE102023108976A1 (de) Systeme und verfahren zur erleichterung eines sicheren schulbusbetriebes
DE102022100078A1 (de) SYSTEM ZUR ERKLÄRUNG NACH EINER MAßNAHME EINES AUTONOMEN FAHRZEUGS