DE112020001643T5 - Autonomes Fahrzeugsystem - Google Patents

Abstract

Sensordaten werden von einer Mehrzahl von Sensoren empfangen, wobei die Mehrzahl von Sensoren einen ersten Satz von Sensoren und einen zweiten Satz von Sensoren umfasst, und zumindest ein Teil der Mehrzahl von Sensoren mit einem Fahrzeug gekoppelt ist. Die Steuerung des Fahrzeugs wird basierend auf zumindest einem Abschnitt der Sensordaten automatisiert, die von dem ersten Satz von Sensoren erzeugt werden. Die Insassenattribute eines oder mehrerer Insassen in den autonomen Fahrzeugen werden anhand von Sensordaten bestimmt, die von dem zweiten Satz von Sensoren erzeugt werden. Die Attribute des Fahrzeugs werden basierend auf den Insassenattributen und den von dem ersten Satz von Sensoren erzeugten Sensordaten geändert.

Description

• QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
• Diese Anmeldung beansprucht den Nutzen und die Priorität der vorläufigen US-Patentanmeldung Nr. 62/826,955 mit dem Titel „Autonomous Vehicle System“, die am 29. März 2019 eingereicht wurde und deren gesamte Offenbarung hier durch Bezugnahme umfassen ist.
• TECHNISCHES GEBIET
• Diese Offenbarung bezieht sich im Allgemeinen auf den Bereich der Computersysteme und insbesondere auf Rechensysteme, die autonome Fahrzeuge ermöglichen.
• HINTERGRUND
• Einige Fahrzeuge sind so ausgebildet, dass sie in einem autonomen Modus betrieben werden können, in dem das Fahrzeug mit wenigen oder gar keinen Eingaben des Fahrers durch eine Umgebung navigiert. Ein solches Fahrzeug verfügt in der Regel über einen oder mehrere Sensoren, die so ausgebildet sind, dass sie Informationen über die Umgebung 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 eine vereinfachte Darstellung eines Beispiels für eine autonome Fahrumgebung.
• 2 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung einer Beispielimplementierung eines Fahrzeugs (und eines entsprechenden bordeigenen Rechensystems) mit autonomer Fahrfunktion.
• 3 zeigt ein Beispiel für ein neuronales Netz in Übereinstimmung mit bestimmten Ausführungsformen.
• 4 ist ein vereinfachtes Blockdiagramm, das beispielhafte Stufen des autonomen Fahrens veranschaulicht, die in verschiedenen Fahrzeugen (z. B. durch ihre entsprechenden bordeigenen Rechensysteme) unterstützt werden können.
• 5 ist ein vereinfachtes Blockdiagramm, das einen beispielhaften Ablauf des autonomen Fahrens veranschaulicht, der in einigen autonomen Fahrsystemen implementiert werden kann.
• 6 ist ein vereinfachtes Blockdiagramm, das Beispielmodule zeigt, die in der Hardware und/oder Software eines autonomen Fahrzeugs vorhanden sind, um eine Pipeline für autonomes Fahren zu implementieren.
• 7 ist ein vereinfachtes Blockdiagramm, das die logische Darstellung eines beispielhaften Empfehlungssystems zeigt.
• 8 ist ein vereinfachtes Blockdiagramm, das ein Beispiel für ein untergeordnetes autonomes Fahrzeug mit verschiedenen Erweiterungsmodi zeigt.
• 9 ist ein vereinfachtes Blockdiagramm, das ein Beispiel für eine Fahrumgebung zeigt.
• 10 ist ein vereinfachtes Blockdiagramm, das ein Beispiel für ein verbessertes autonomes Fahrsystem zeigt.
• 11 ist ein vereinfachtes Blockdiagramm, das ein Beispiel für einen Frame-Transcoder zeigt.
• 12 zeigt die Darstellung eines Beispiels für ein maschinelles Lernmodell zur Ereigniserkennung.
• 13 zeigt die Darstellung eines Maschinelles-Lernen-Modells zur Szenen klassifizierung.
• 14 veranschaulicht Aspekte eines Beispiels für ein autonomes Fahrsystem mit einem Empfehlungssystem.
• 15 ist ein vereinfachtes Blockdiagramm, das ein autonomes Fahrzeug und eine Vielzahl von Sensoren in Übereinstimmung mit bestimmten Ausführungsformen zeigt.
• 16 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung der Kommunikation zwischen Systemen während der Erbringung eines beispielhaften Remote-Valet-Service (ferngesteuerten Valet-Service) in Übereinstimmung mit bestimmten Ausführungsformen.
• 17 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung der kooperativen Meldung von Informationen in Bezug auf das Risiko des Umkippens und Warnungen über den Straßenzustand, die gemäß bestimmten Ausführungsformen für die Einrichtung von Remote-Valet-Services genutzt werden können.
• 18 ist ein vereinfachtes Blockdiagramm, das beispielhafte autonome Fahrzeugfunktionen einschließlich Fahrzeugsensoren, einen auf künstlicher Intelligenz/Maschinenlernen basierenden Autonomes-Fahren-Stack und eine Logik zur Unterstützung der Auslösung und Erzeugung von Übergabeanforderungen an Systeme zeigt, die in der Lage sind, einen Remote-Valet in Übereinstimmung mit bestimmten Ausführungsformen bereitzustellen.
• 19 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung eines beispielhaften „Sense, Plan, Act“-Modells zur Steuerung autonomer Fahrzeuge in zumindest einigen Ausführungsformen.
• 20 veranschaulicht ein vereinfachtes Modell zum Verständnis sozialer Normen in Übereinstimmung mit mindestens einer Ausführungsform.
• 21 zeigt Diagramme, die Aspekte der Koordination zwischen Fahrzeugen in einer Umgebung veranschaulichen.
• 22 ist ein Blockdiagramm, das einen beispielhaften Informationsaustausch zwischen zwei Fahrzeugen zeigt.
• 23 ist ein vereinfachtes Blockdiagramm, das ein Beispiel für eine Straßenkreuzung zeigt.
• 24 veranschaulicht ein Beispiel für einen Konsens über ein lokales Verhaltensmodell.
• 25 ist ein vereinfachtes Diagramm, das einen beispielhaften Prozess der Bewertung und Validierung von Sensordaten autonomer Fahrzeuge aus der Crowd gemäß mindestens einer Ausführungsform zeigt.
• 26 ist ein Flussdiagramm eines Beispielprozesses zur Bewertung von Sensordaten eines autonomen Fahrzeugs gemäß mindestens einer Ausführungsform.
• 27 ist ein Flussdiagramm eines Beispielprozesses zur Bewertung von Sensordaten eines autonomen Fahrzeugs gemäß mindestens einer Ausführungsform.
• 28 ist ein vereinfachtes Diagramm einer Beispielumgebung für die Datenerfassung in autonomen Fahrzeugen gemäß mindestens einer Ausführungsform.
• 29 ist ein vereinfachtes Blockdiagramm eines Beispiels für eine Crowdsourced-Datenerfassungsumgebung für autonome Fahrzeuge gemäß mindestens einer Ausführungsform.
• 30 ist ein vereinfachtes Diagramm eines Beispiels für eine Heatmap zur Berechnung einer Sensordatengütebewertung gemäß mindestens einer Ausführungsform.
• 31 ist ein Flussdiagramm eines Beispielprozesses zur Berechnung einer Gütebewertung für Sensordaten von autonomen Fahrzeugen in Übereinstimmung mit mindestens einer Ausführungsform.
• 32 veranschaulicht ein Beispielszenario „Pittsburgh Left“.
• 33 veranschaulicht ein Beispielszenario für „Verkehrsrowdy“.
• 34 ist ein vereinfachtes Blockdiagramm, das ein Modell zur Verfolgung von unregelmäßigem/anormalem Verhalten für ein autonomes Fahrzeug gemäß mindestens einer Ausführungsform zeigt.
• 35 zeigt ein Beispiel für ein kontextbezogenes Diagramm, das aufzeigt, wie oft ein Fahrmuster in einem bestimmten Kontext auftritt.
• 36 ist ein Flussdiagramm eines Beispielprozesses zur Verfolgung von unregelmäßigen Verhaltensweisen, die von Fahrzeugen gemäß mindestens einer Ausführungsform beobachtet werden.
• 37 ist ein Flussdiagramm eines Beispielprozesses zur Identifizierung kontextbezogener Verhaltensmuster in Übereinstimmung mit mindestens einer Ausführungsform.
• 38 ist ein vereinfachtes Blockdiagramm, das eine Beispielimplementierung eines Angriffserkennungssystem in einer autonomen Fahrumgebung zeigt.
• 39 veranschaulicht ein Beispiel für die Bearbeitung einer Computer-Vision-Analyse.
• 40 ist ein Blockdiagramm einer vereinfachten zentralisierten Fahrzeugsteuerungsarchitektur für ein Fahrzeug gemäß mindestens einer Ausführungsform.
• 41 ist ein vereinfachtes Blockdiagramm einer autonomen Erfassungs- und Steuerungspipeline.
• 42 ist ein vereinfachtes Blockdiagramm, das ein Beispiel für eine x-by-wire-Architektur eines hochautomatisierten oder autonomen Fahrzeugs zeigt.
• 43 ist ein vereinfachtes Blockdiagramm, das eine beispielhafte Sicherheitsrücksetzarchitektur eines hochautomatisierten oder autonomen Fahrzeugs gemäß mindestens einer Ausführungsform zeigt.
• 44 ist ein vereinfachtes Blockdiagramm, das ein Beispiel für eine allgemeine Sicherheitsarchitektur eines hochautomatisierten oder autonomen Fahrzeugs gemäß mindestens einer Ausführungsform zeigt.
• 45 ist ein vereinfachtes Blockdiagramm, das einen beispielhaften Betriebsablauf eines Fehler- und Angriffserkennungssystems für hochautomatisierte und autonome Fahrzeuge gemäß mindestens einer Ausführungsform zeigt.
• 46 ist ein vereinfachtes Flussdiagramm, das den Ablauf von Beispielvorgängen im Zusammenhang mit einem Fehler- und Angriffserkennungssystem veranschaulicht.
• 47 ist ein weiteres vereinfachtes Flussdiagramm, das den detaillierten Ablauf von Beispielvorgängen im Zusammenhang mit einem Fehler- und Angriffserkennungssystem veranschaulicht.
• 48A-48B sind vereinfachte Flussdiagramme, die Beispielvorgänge im Zusammenhang mit einem Fehler- und Angriffserkennungssystem in einer automatisierten Fahrumgebung zeigen.
• 49 zeigt einen Ablauf der Datenkategorisierung, -bewertung und - verarbeitung gemäß bestimmten Ausführungsformen.
• 50 zeigt einen beispielhaften Ablauf für die Verarbeitung von Daten auf der Grundlage von Kategorisierungen gemäß bestimmten Ausführungsformen.
• 51 zeigt ein System zur intelligenten Erzeugung synthetischer Daten in Übereinstimmung mit bestimmten Ausführungsformen.
• 52 zeigt einen Ablauf zur Erzeugung synthetischer Daten in Übereinstimmung mit bestimmten Ausführungsformen.
• 53 zeigt einen Ablauf für die Erzeugung gegnerischer Abtastwerte (Samples) und das Training eines Maschinelles-Lernen-Modells auf der Grundlage der gegnerischen Abtastwerte.
• 54 zeigt einen Ablauf zum Erzeugen eines simulierten Angriffsdatensatzes und zum Trainieren eines Klassifikationsmodells unter Verwendung des simulierten Angriffsdatensatzes in Übereinstimmung mit bestimmten Ausführungsformen.
• 55 veranschaulicht die Funktionsweise eines nichtlinearen Klassifizierers in Übereinstimmung mit bestimmten Ausführungsformen.
• 56 veranschaulicht die Funktionsweise eines linearen Klassifizierers in Übereinstimmung mit bestimmten Ausführungsformen.
• 57 zeigt einen Ablauf zur Auslösung einer Aktion auf der Grundlage der Genauigkeit eines linearen Klassifikators.
• 58 veranschaulicht beispielhaft verantwortungsbewusste Sicherheitsphasen (RSS) in Übereinstimmung mit bestimmten Ausführungsformen.
• 59 ist ein Diagramm eines Systems zur Änderung der Fahrereingaben, um RSS-konforme Beschleunigungen gemäß bestimmten Ausführungsformen zu gewährleisten.
• 60 zeigt eine Trainingsphase für den Regel-Beschleunigungs-Wandler in Übereinstimmung mit bestimmten Ausführungsformen.
• 61 zeigt die Inferenzphase eines Konverters zur Umwandlung von Steuerung in Beschleunigung in Übereinstimmung mit bestimmten Ausführungsformen.
• 62 zeigt einen Ablauf für die Bereitstellung akzeptabler Steuersignale für ein Fahrzeugbetätigungssystem in Übereinstimmung mit bestimmten Ausführungsformen.
• 63 zeigt eine Trainingsphase zur Erstellung eines Kontextmodells 1508 in Übereinstimmung mit bestimmten Ausführungsformen.
• 64 zeigt eine Trainingsphase zum Aufbau eines Signalqualitätsmetrikmodells in Übereinstimmung mit bestimmten Ausführungsformen.
• 65 zeigt eine Trainingsphase zur Erstellung eines Übergabebereitschaftsmodells in Übereinstimmung mit bestimmten Ausführungsformen.
• 66 zeigt eine Inferenzphase zur Bestimmung einer Übergabeentscheidung auf der Grundlage von Sensordaten in Übereinstimmung mit bestimmten Ausführungsformen.
• 67 zeigt einen Ablauf, mit dem bestimmt wird, ob die Kontrolle über ein Fahrzeug in Übereinstimmung mit bestimmten Ausführungsformen weitergegeben werden soll.
• 68 zeigt eine Trainingsphase für ein Fahrerzustandsmodell in Übereinstimmung mit bestimmten Ausführungsformen.
• 69 zeigt eine Trainingsphase für ein Übergabeentscheidungsmodell in Übereinstimmung mit bestimmten Ausführungsformen.
• 70 zeigt eine Inferenzphase zur Bestimmung einer Übergabeentscheidung in Übereinstimmung mit bestimmten Ausführungsformen.
• 71 zeigt einen Ablauf zur Generierung einer Übergabeentscheidung in Übereinstimmung mit bestimmten Ausführungsformen.
• 72 zeigt ein übergeordnetes Blockdiagramm eines Rahmens für die Steuerung eines autonomen Fahrzeugs in Übereinstimmung mit bestimmten Ausführungsformen.
• 73 ist ein Diagramm eines Beispiels für einen Prozess zur Kontrolle von Übernahmen eines autonomen Fahrzeugs gemäß bestimmten Ausführungsformen.
• 74 ist ein Diagramm eines weiteren Beispiels für die Kontrolle von Übernahmen eines autonomen Fahrzeugs in Übereinstimmung mit bestimmten Ausführungsformen.
• 75 ist ein Diagramm einer beispielhaften Pipeline 2800 zur Wahrnehmung, Planung und Durchführung des autonomen Fahrens für ein autonomes Fahrzeug in Übereinstimmung mit bestimmten Ausführungsformen.
• 76 ist ein Diagramm eines Beispielprozesses zur Kontrolle von Übernahmeanfragen durch menschliche Fahrer eines autonomen Fahrzeugs in Übereinstimmung mit bestimmten Ausführungsformen.
• 77 zeigt verschiedene Automatisierungsgrade und den damit verbundenen Aufwand für den menschlichen Fahrer in Übereinstimmung mit bestimmten Ausführungsformen.
• 78 veranschaulicht ein umfassendes kognitives Überwachungssystem in Übereinstimmung mit bestimmten Ausführungsformen.
• 79 veranschaulicht beispielhafte autonome Ebenenübergänge in Übereinstimmung mit bestimmten Ausführungsformen.
• 80 veranschaulicht ein Beispiel für einen architektonischen Datenfluss eines autonomen Fahrzeugs, das auf einem Autonomiegrad L4 in Übereinstimmung mit bestimmten Ausführungsformen betrieben wird.
• 81 veranschaulicht ein Beispiel für ein Videosignal an den Treiber in Übereinstimmung mit bestimmten Ausführungsformen.
• 82 veranschaulicht den Ablauf einer beispielhaften Übergabesituation eines autonomen Fahrzeugs in Übereinstimmung mit bestimmten Ausführungsformen.
• 83 veranschaulicht ein Beispiel für einen Ablauf zur Übergabe der Kontrolle eines autonomen Fahrzeugs an einen menschlichen Fahrer gemäß bestimmten Ausführungsformen.
• 84 ist ein Diagramm, das Beispiele für Gated Recurrent Unit (GRU) und Long Short Term Memory (LSTM) Architekturen zeigt.
• 85 zeigt ein System zur Erkennung von Anomalien in Übereinstimmung mit bestimmten Ausführungsformen.
• 86 zeigt einen Ablauf zur Erkennung von Anomalien in Übereinstimmung mit bestimmten Ausführungsformen.
• 87 veranschaulicht ein Beispiel für ein Verfahren zur Einschränkung des Autonomiegrades eines Fahrzeugs auf einem Straßenabschnitt gemäß einer Ausführungsform.
• 88 veranschaulicht ein Beispiel für eine Karte, in der jeder Bereich der aufgelisteten Straßen einen Sicherheitswert für diesen Straßenabschnitt angibt.
• 89 veranschaulicht ein Kommunikationssystem zur Wahrung der Privatsphäre in Computer-Vision-Systemen von Fahrzeugen gemäß mindestens einer hier beschriebenen Ausführungsform.
• 90A-90B zeigen ein Beispiel für einen Diskriminator.
• 91 veranschaulicht weitere mögliche Komponenten und Betriebsdetails des GAN-Konfigurationssystems gemäß mindestens einer Ausführungsform.
• 92 zeigt ein Beispiel für unkenntlich gemachte Bilder, die mit Hilfe eines StarGAN-basierten Modells erzeugt wurden, um verschiedene Gesichtsattribute eines Eingangsbildes zu verändern.
• 93 zeigt ein Beispiel für unkenntlich gemachte Bilder, die von einem StarGAN-basierten Modell aus einem Eingabebild eines echten Gesichts erzeugt wurden, sowie die Ergebnisse einer Gesichtserkennungsmaschine, die die echten und unkenntlich gemachten Bilder auswertet.
• 94A zeigt ein Beispiel für unkenntlich gemachte Bilder, die von einem StarGAN-basierten Modell aus einem Eingabebild eines realen Gesichts erzeugt wurden, sowie die Ergebnisse einer Emotionserkennungsmaschine, die das reale und das unkenntlich gemachte Bild auswertet.
• 94B ist eine Auflistung von Eingabeparametern und Ausgabeergebnissen, die der Beispielverarbeitung der Emotionserkennungsmaschine für das Eingabebild und die in 94A gezeigten unkenntlich gemachten Bilder entsprechen.
• 95 zeigt ein Beispiel für die Umwandlung eines Eingabebildes eines echten Gesichts in ein unkenntlich gemachtes Bild, wie es von einem IcGAN-basierten Modell durchgeführt wird.
• 96 veranschaulicht weitere mögliche Betriebsdetails eines ausgebildeten GAN-Modells, das in einem Fahrzeug implementiert ist.
• 97 veranschaulicht ein Beispiel für den Betrieb eines ausgebildeten GAN-Modells in einem Fahrzeug zur Erzeugung eines unkenntlich gemachten Bildes und die Verwendung des unkenntlich gemachten Bildes bei Aufgaben des maschinellen Lernens gemäß mindestens einer Ausführungsform.
• 98 ist ein vereinfachtes Flussdiagramm, das detailliert einen möglichen Ablauf von Operationen veranschaulicht, die mit der Konfiguration eines Generative Adversarial Network (GAN) verbunden sind, das darauf trainiert ist, Attributübertragungen auf Bilder von Gesichtern durchzuführen.
• 99 ist ein vereinfachtes Flussdiagramm, das detailliert einen möglichen Ablauf von Operationen veranschaulicht, die mit dem Betrieb eines datenschutzfreundlichen Computer-Vision-Systems eines Fahrzeugs verbunden sind, wenn ein ausgebildetes GAN-Modell in dem System implementiert ist.
• 100 ist ein vereinfachtes Flussdiagramm, das detailliert einen möglichen Ablauf von Operationen veranschaulicht, die bei der Anwendung eines ausgebildeten GAN-Modells auf ein Eingangsbild auftreten können.
• 101 veranschaulicht ein System zur Einhaltung des Datenschutzes bei autonomen Fahrzeugen auf Anfrage.
• 102 zeigt eine Darstellung der von einem Fahrzeug gesammelten Daten und der Objekte, die definiert wurden, um die Einhaltung des Datenschutzes für die Daten zu gewährleisten.
• 103 zeigt ein Beispiel einer Richtlinienvorlage für ein System zur Einhaltung des Datenschutzes auf Abruf gemäß mindestens einer Ausführungsform.
• 104 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung möglicher Komponenten und eines allgemeinen Betriebsablaufs eines Fahrzeugdatensystems.
• 105 veranschaulicht Merkmale und Aktivitäten eines Edge- oder Cloud-Fahrzeugdatensystems aus der Perspektive verschiedener möglicher menschlicher Akteure und Hardware- und/oder Softwareakteure.
• 106 ist ein Beispiel für die Anzeige eines Portalbildschirms eines On-Demand-Systems zur Einhaltung des Datenschutzes für die Erstellung von Richtlinien für von autonomen Fahrzeugen erfasste Daten.
• 107 zeigt ein Beispielbild, das von einem Fahrzeug aufgenommen wurde, bevor und nachdem ein Verfahren zum Verwischen von Nummernschildern auf das Bild angewendet wurde.
• 108 zeigt ein Beispielbild, das von einem Fahrzeug aufgenommen wurde, bevor und nachdem eine Gesichtsverwischungsstrategie auf das Bild angewendet wurde.
• 109 ist ein vereinfachtes Flussdiagramm, das einen detaillierten möglichen Ablauf von Vorgängen veranschaulicht, die mit der Kennzeichnung von Daten verbunden sind, die an einem Fahrzeug in einem System zur Einhaltung des Datenschutzes auf Abruf gesammelt werden.
• 110 ist ein vereinfachtes Flussdiagramm, das einen detaillierten möglichen Ablauf von Vorgängen im Zusammenhang mit der Durchsetzung von Richtlinien in einem System zur Einhaltung des Datenschutzes auf Abruf veranschaulicht.
• 111 ist ein vereinfachtes Flussdiagramm, das einen detaillierten möglichen Ablauf von Vorgängen im Zusammenhang mit der Durchsetzung von Richtlinien in einem System zur Einhaltung des Datenschutzes auf Abruf veranschaulicht.
• 112 ist ein vereinfachtes Diagramm eines Regelkreises für die Automatisierung eines autonomen Fahrzeugs in Übereinstimmung mit mindestens einer Ausführungsform.
• 113 ist ein vereinfachtes Diagramm eines Generalized Data Input (GDI) für die Automatisierung eines autonomen Fahrzeugs in Übereinstimmung mit mindestens einer Ausführungsform
• 114 ist ein Diagramm einer beispielhaften GDI-Freigabeumgebung in Übereinstimmung mit mindestens einer Ausführungsform.
• 115 ist ein Diagramm einer beispielhaften Blockchain-Topologie in Übereinstimmung mit mindestens einer Ausführungsform.
• 116 ist ein Diagramm eines beispielhaften „kettenlosen“ Blocks, der eine Topologie eines gerichteten azyklischen Graphen (DAG) in Übereinstimmung mit mindestens einer Ausführungsform verwendet.
• 117 ist ein vereinfachtes Blockdiagramm eines Beispiels für ein sicheres fahrzeuginternes Kommunikationsprotokoll für ein autonomes Fahrzeug in Übereinstimmung mit mindestens einer Ausführungsform.
• 118 ist ein vereinfachtes Blockdiagramm eines Beispiels für ein sicheres Kommunikationsprotokoll zwischen Fahrzeugen für ein autonomes Fahrzeug in Übereinstimmung mit mindestens einer Ausführungsform.
• 119 ist ein vereinfachtes Blockdiagramm eines Beispiels für ein sicheres fahrzeuginternes Kommunikationsprotokoll für ein autonomes Fahrzeug in Übereinstimmung mit mindestens einer Ausführungsform.
• 120A zeigt ein System zur Bestimmung von Abtastraten für eine Mehrzahl von Sensoren in Übereinstimmung mit bestimmten Ausführungsformen.
• 120B zeigt einen Algorithmus für maschinelles Lernen zur Erstellung eines Kontextmodells in Übereinstimmung mit bestimmten Ausführungsformen.
• 121 zeigt einen Fusionsalgorithmus zur Erzeugung eines Fusionskontext-Wörterbuchs in Übereinstimmung mit bestimmten Ausführungsformen.
• 122 zeigt eine Inferenzphase zur Bestimmung der selektiven Abtastung und der fusionierten Sensorgewichte in Übereinstimmung mit bestimmten Ausführungsformen.
• 123 veranschaulicht die unterschiedliche Gewichtung der Sensoren für verschiedene Kontexte.
• 124A veranschaulicht einen Ansatz zum Erlernen von Gewichten für Sensoren in verschiedenen Kontexten in Übereinstimmung mit bestimmten Ausführungsformen.
• 124B veranschaulicht einen detaillierteren Ansatz für das Lernen von Gewichten für Sensoren unter verschiedenen Bedingungen in Übereinstimmung mit bestimmten Ausführungsformen.
• 125 zeigt einen Ablauf zur Bestimmung einer Abtastpolitik in Übereinstimmung mit bestimmten Ausführungsformen.
• 126 ist ein vereinfachtes Diagramm einer beispielhaften VLC- oder Li-Fi-Kommunikation zwischen autonomen Fahrzeugen gemäß mindestens einer Ausführungsform.
• 127A-127B sind vereinfachte Diagramme von beispielhaften VLC- oder Li-Fi-Sensorpositionen an einem autonomen Fahrzeug gemäß mindestens einer Ausführungsform
• 128 ist ein vereinfachtes Diagramm einer beispielhaften VLC- oder Li-Fi-Kommunikation zwischen einem betroffenen Fahrzeug und einem Verkehrsfahrzeug gemäß mindestens einer Ausführungsform.
• 129 ist ein vereinfachtes Diagramm eines Beispiels für die Verwendung von VLC- oder Li-Fi-Informationen in einem Sensorfusionsprozess eines autonomen Fahrzeugs in Übereinstimmung mit mindestens einer Ausführungsform.
• 130A veranschaulicht eine Verarbeitungspipeline für einen einzelnen Strom von Sensordaten, die von einem einzelnen Sensor stammen.
• 130B zeigt ein Beispielbild, das direkt aus LIDAR-Daten gewonnen wurde.
• 131 zeigt Beispiele für parallele Verarbeitungspipelines zur Verarbeitung mehrerer Sensordatenströme.
• 132 zeigt eine Verarbeitungspipeline, in der die Daten von mehreren Sensoren durch die Filterung kombiniert werden.
• 133 zeigt eine Verarbeitungspipeline, in der Daten von mehreren Sensoren durch eine Fusionsaktion nach allen oben beschriebenen Aktionen der Sensorabstraktion kombiniert werden.
• 134 zeigt einen Ablauf zur Erzeugung von Trainingsdaten mit hochauflösenden und entsprechenden niedrigauflösenden Bildern in Übereinstimmung mit bestimmten Ausführungsformen.
• 135 zeigt eine Trainingsphase für ein Modell zur Erzeugung hochauflösender Bilder aus niedrig aufgelösten Bildern gemäß bestimmten Ausführungsformen.
• 136 zeigt eine Inferenzphase für ein Modell zur Erzeugung hochauflösender Bilder aus niedrigauflösenden Bildern gemäß bestimmten Ausführungsformen.
• 137 zeigt eine Trainingsphase für das Training eines Schülermodells unter Verwendung von Wissensdestillation in Übereinstimmung mit bestimmten Ausführungsformen.
• 138 zeigt eine Inferenzphase für ein Schülermodell, das mit Hilfe der Wissensdestillation gemäß bestimmten Ausführungsformen trainiert wurde.
• 139 zeigt einen Ablauf zur Erhöhung der Auflösung von aufgenommenen Bildern zur Verwendung bei der Objekterkennung gemäß bestimmten Ausführungsformen.
• 140 zeigt einen Ablauf für das Training eines Maschinelles-Lernen-Modells auf der Grundlage eines Ensembles von Methoden in Übereinstimmung mit bestimmten Ausführungsformen.
• 141 zeigt ein Beispiel für eine Situation, in der ein autonomes Fahrzeug die Sensoren verdeckt hat und dadurch eine Fahrsituation potenziell gefährlich wird.
• 142 zeigt ein Beispiel für ein High-Level-Architekturdiagramm eines Systems, das die Fahrzeugkooperation nutzt.
• 143 zeigt ein Beispiel für eine Situation, in der mehrere Aktionen von mehreren Fahrzeugen in Erwägung gezogen werden.
• 144 zeigt ein Fahrzeug mit dynamisch einstellbaren Bildsensoren und Kalibrierungsmarkern.
• 145 zeigt das Fahrzeug von 144 mit einem gedrehten Bildsensor.
• 146 zeigt einen Ablauf zur Einstellung eines Bildsensors eines Fahrzeugs in Übereinstimmung mit bestimmten Ausführungsformen.
• 147 zeigt ein Beispielsystem für die Übergabe eines autonomen Fahrzeugs an einen menschlichen Fahrer in Übereinstimmung mit bestimmten Ausführungsformen.
• 148 veranschaulicht eine Beispielroute, die ein Fahrzeug in Übereinstimmung mit bestimmten Ausführungsformen nehmen kann, um von Punkt A zu Punkt B zu gelangen.
• 149 veranschaulicht einen Ablauf, der zumindest teilweise von einem Abgabehandhabungsmodul in Übereinstimmung mit bestimmten Ausführungsformen durchgeführt werden kann.
• 150 zeigt ein Beispiel für eine Sensoranordnung an einem autonomen Fahrzeug.
• 151 zeigt ein Beispiel für ein dynamisches System zur Erkennung von Autonomiegraden.
• 152 zeigt ein Beispiel für das Manövrieren eines autonomen Fahrzeugs.
• 153 veranschaulicht ein Ackermann-Modell.
• 154 zeigt ein Beispiel für ein Fahrzeug mit einem Anbaugerät.
• 155 veranschaulicht ein Beispiel für die Verfolgung neuer Abmessungen eines Beispielfahrzeugs, um die durch eine an das Fahrzeug gekoppelte Verlängerung hinzugefügten Abmessungen zu berücksichtigen.
• 156 veranschaulicht ein Beispiel für einen Fluss zur Kompensation von Fahrzeugmodellverdeckungen gemäß mindestens einer Ausführungsform.
• 157 ist ein Beispiel für die Darstellung eines Prozessors gemäß einer Ausführungsform.
• 158 veranschaulicht ein Beispiel für ein Rechensystem gemäß einer Ausführungsform.
• BESCHREIBUNG DER BEISPIELHAFTEN AUSFÜHRUNGSBEISPIELE
• 1 ist eine vereinfachte Darstellung 100, die eine beispielhafte autonome Fahrumgebung zeigt. Fahrzeugen (z. B. 105, 110, 115 etc.) können unterschiedliche Grade von Autonomes-Fahren-Fähigkeiten bereitgestellt sein, die durch bordeigene Rechensysteme mit in Hardware, Firmware und/oder Software implementierter Logik ermöglicht werden, um jeweilige Autonomes-Fahren-Stacks zu ermöglichen. Solche Autonomes-Fahren-Stacks können es Fahrzeugen ermöglichen, sich selbst zu steuern oder eine Fahrerassistenz bereitzustellen, um Fahrbahnen zu detektieren, von einem Punkt zum anderen zu navigieren, andere Fahrzeuge und Verkehrsteilnehmer (z. B. Fußgänger (z. B. 135), Radfahrer etc.) zu detektieren, Hindernisse und Gefahren (z. B. 120) und Straßenzustände (z. B. Verkehr, Straßenzustände, Wetterbedingungen etc.) zu detektieren und die Steuerung und Führung des Fahrzeugs entsprechend anzupassen. Im Rahmen der vorliegenden Offenbarung kann ein „Fahrzeug“ ein bemanntes Fahrzeug sein, das für die Beförderung eines oder mehrerer menschlicher Fahrgäste ausgelegt ist (z. B. Pkw, Lkw, Transporter, Busse, Motorräder, Züge, Lufttransportfahrzeuge, Krankenwagen usw.), ein unbemanntes Fahrzeug, das mit oder ohne menschliche Fahrgäste fährt (z. B. Frachtfahrzeuge (z. B. Lkw, schienengestützte Fahrzeuge usw.), Fahrzeuge zur Beförderung nicht menschlicher Fahrgäste (z. B. Viehtransporte usw.) und/oder Drohnen (z. B. land- oder luftgestützte Drohnen oder Roboter, die sich in einer Fahrumgebung bewegen sollen (z. B. um Informationen über die Fahrumgebung zu sammeln, Unterstützung bei der Automatisierung anderer Fahrzeuge zu leisten, Aufgaben der Straßeninstandhaltung zu übernehmen, industrielle Aufgaben zu erfüllen, Aufgaben der öffentlichen Sicherheit und der Gefahrenabwehr zu erfüllen usw.). In einigen Implementierungen kann ein Fahrzeug ein System sein, das so ausgebildet ist, dass es alternativ in mehreren verschiedenen Modi betrieben werden kann (z. B. Insassenfahrzeug, unbemanntes Fahrzeug oder Drohnenfahrzeug), neben anderen Beispielen. Ein Fahrzeug kann in einer Umgebung „fahren“, um sich auf dem Boden (z. B. auf einer befestigten oder unbefestigten Straße, einem Weg oder einer Landschaft), durch Wasser oder in der Luft zu bewegen. In diesem Sinne kann eine „Straße“ oder „Fahrbahn“ je nach Ausführung einen Weg im Freien oder in Gebäuden am Boden, einen Wasserkanal oder eine bestimmte Grenze in der Luft darstellen. Dementsprechend sollte man sich bewusst sein, dass die folgende Offenbarung und die damit verbundenen Ausführungsformen gleichermaßen für verschiedene Kontexte und Fahrzeugimplementierungsbeispiele gelten können.
• In einigen Implementierungen können Fahrzeuge (z. B. 105, 110, 115) in der Umgebung „verbunden“ sein, indem die fahrzeuginternen Rechensysteme Kommunikationsmodule zur Unterstützung der drahtlosen Kommunikation mit einer oder mehreren Technologien (z. B. IEEE 802.11-Kommunikation (z. B. WiFi), zellulare Datennetze (z. B.,3rd Generation Partnership Project (3GPP) -Netzwerke, Global System for Mobile Communication (GSM), General Packet Radio Service, Code Division Multiple Access (CDMA), 4G, 5G, 6G usw.), Bluetooth, Millimeterwellen (mmWave), ZigBee, Z-Wave usw.), die es den bordeigenen Rechensystemen ermöglichen, eine Verbindung zu anderen Rechensystemen herzustellen und mit diesen zu kommunizieren, wie z. B. den bordeigenen Rechensystemen anderer Fahrzeuge, Straßenrandeinheiten, Cloud-basierten Rechensystemen oder einer anderen unterstützenden 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. Zum Beispiel, wie im illustrativen Beispiel von 1 gezeigt, können unterstützende Drohnen 180 (z. B. boden- und/oder luftgestützt), straßenseitige Rechenvorrichtungen (z. B. 140), verschiedene externe (zu dem Fahrzeug oder „fremde“) Sensorvorrichtungen (z. B. 160, 165, 170, 175 etc.) und andere Vorrichtungen als autonome Fahrinfrastruktur bereitgestellt werden, getrennt von den auf den Fahrzeugen (z. B. 105, 110, 115) implementierten Rechensystemen, Sensoren und Logiken, um u.a. die durch die Fahrzeuge bereitgestellten autonomen Fahrergebnisse zu unterstützen und zu verbessern. Fahrzeuge können auch mit anderen verbundenen Fahrzeugen über drahtlose Kommunikationskanäle kommunizieren, um Daten gemeinschaftlich zu verwenden und Bewegungen innerhalb einer Autonomes-Fahren-Umgebung zu koordinieren, neben anderen beispielhaften Kommunikationen.
• Wie bei dem Beispiel von 1 gezeigt, kann die Infrastruktur für das autonome Fahren eine Vielzahl unterschiedlicher Systeme umfassen. Solche Systeme können abhängig von der Position variieren, wobei besser 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 zum Beobachten 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 Sensorvorrichtungen innerhalb der Fahrbahn selbst (z. B. Sensor 160), auf straßenseitiger oder Überkopf-Beschilderung (z. B. Sensor 165 auf dem Schild 125), in Sensoren (z. B. 170, 175), die an elektronischen Vorrichtungen oder Einrichtungen am Straßenrand (z. B. Ampeln (z. B. 130), elektronischen Verkehrsschildern, elektronischen Reklametafeln etc.) angebracht sind, in dedizierte Straßenrandeinheiten (z. B. 140) eingebettet sein, unter anderen Beispielen. Sensorvorrichtungen können auch Kommunikationsfähigkeiten aufweisen, um ihre gesammelten Sensordaten direkt an verbundene Fahrzeuge in der Nähe oder an Fog- oder Cloud-basierte Rechensysteme (z. B. 140, 150) zu kommunizieren. Fahrzeuge können Sensordaten erhalten, die durch externe Sensorvorrichtungen (z. B. 160, 165, 170, 175, 180) gesammelt wurden, oder Daten, die Beobachtungen oder Empfehlungen umfassen, die von anderen Systemen (z. B. 140, 150) basierend auf Sensordaten von diesen Sensorvorrichtungen (z. B. 160, 165, 170, 175, 180) erzeugt wurden, und diese Daten bei der Sensorfusion, Inferenz, Pfadplanung und anderen Aufgaben, die von dem bordeigenen Autonomes-Fahren-System ausgeführt werden, verwenden. In einigen Fällen können sich solche externen Sensoren und Sensordaten tatsächlich im Fahrzeug befinden, z. B. in Form eines am Fahrzeug angebrachten Nachrüstsensors, eines persönlichen Computergeräts (z. B. Smartphone, Wearable usw.), das von den Fahrzeuginsassen mitgeführt oder getragen wird, usw. Andere Verkehrsteilnehmer, einschließlich Fußgänger, Fahrräder, Drohnen, unbemannte Luftfahrzeuge, Roboter, Elektroroller usw., können ebenfalls mit Sensoren ausgestattet sein oder Sensoren tragen, um Sensordaten zu erzeugen, die eine autonome Fahrumgebung beschreiben und von autonomen Fahrzeugen, cloud- oder nebelbasierten Unterstützungssystemen (z. B. 140, 150), anderen Sensorgeräten (z. B. 160, 165, 170, 175, 180) und anderen Beispielen verwendet und genutzt werden können.
• Da autonome Fahrzeugsysteme verschiedene Grade an Funktionalität und Ausgereiftheit aufweisen können, kann eine unterstützende Infrastruktur herangezogen werden, um nicht nur die Erfassungsfähigkeiten einiger Fahrzeuge, sondern auch die Computer- und Maschinelles-Lernen-Funktionalität, die die autonome Fahrfunktionalität einiger Fahrzeuge ermöglicht, zu ergänzen. Beispielsweise können Rechenressourcen und Autonomes-Fahren-Logik, die verwendet werden, um Maschinelles-Lernen-Modelle-Training und die Verwendung solcher Maschinelles-Lernen-Modelle zu ermöglichen, ganz auf den bordeigenen Rechensystemen oder teilweise auf sowohl den bordeigenen Systemen als auch einigen externen Systemen (z. B. 140, 150) bereitgestellt werden. Beispielsweise kann ein verbundenes Fahrzeug mit Straßenrandeinheiten, Randsystemen oder Cloud-basierten Vorrichtungen (z. B. 140) kommunizieren, die sich lokal auf einem bestimmten Fahrbahnsegment befinden, wobei solche Vorrichtungen (z. B. 140) in der Lage sind, Daten bereitzustellen (z. B. von lokalen Sensoren aggregierte Sensordaten (z. B. 160, 165, 170, 175, 180) oder Daten, die von Sensoren anderer Fahrzeuge gemeldet werden), Berechnungen (als Dienst) zu Daten auszuführen, die von einem Fahrzeug bereitgestellt werden, um die fahrzeugeigenen Fähigkeiten zu ergänzen und/oder Informationen an vorbeifahrende oder sich nähernde Fahrzeuge zu senden (z. B. basierend auf Sensordaten, die an der Vorrichtung 140 oder von Sensorvorrichtungen in der Nähe gesammelt wurden 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 Rechen-Ressourcen bereitstellen können, um die an dem Fahrzeug verfügbaren zu verbessern. Beispielsweise kann ein Cloud-basiertes System (z. B. 150) Sensordaten von einer Vielzahl von Vorrichtungen an einem oder mehreren Orten sammeln und diese Daten nutzen, um Maschinelles-Lernen-Modelle zu erstellen und/oder zu trainieren, die an dem Cloud-basierten System 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 sie an Fahrzeuge zur Verwendung durch ihre bordeigenen Systeme weiterzugeben, neben anderen beispielhaften Implementierungen. Zugangspunkte (z. B. 145), wie z. B. Mobilfunkmasten, straßenseitige Einheiten, Netzzugangspunkte, die an verschiedenen Fahrbahninfrastrukturen angebracht sind, Zugangspunkte, die durch benachbarte Fahrzeuge oder Gebäude bereitgestellt werden, und andere Zugangspunkte können innerhalb einer Umgebung bereitgestellt werden und verwendet werden, um die Kommunikation über ein oder mehrere lokale oder Weitbereich-Netzwerke (z. B. 155) zwischen Cloud-basierten Systemen (z. B. 150) und verschiedenen Fahrzeugen (z. B. 105, 110, 115) zu ermöglichen. Durch solche Infrastruktur- und Rechensysteme wird darauf hingewiesen, dass die hierin erörterten Beispiele, Merkmale und Lösungen vollständig von einem oder mehreren solcher bordeigenen Rechensysteme, Fog-basierten oder Edge-Rechenvorrichtungen oder Cloud-basierten Rechensysteme oder von Kombinationen des vorangehend Genannten durch Kommunikation und Kooperation zwischen den Systemen ausgeführt werden können.
• Im Allgemeinen können „Server“, „Clients“, „Rechenvorrichtungen“, „Netzwerkelemente“, „Hosts“, „Plattformen“, „Sensorvorrichtungen“, „Edge-Vorrichtung“, „Autonomes-Fahren-Systeme“, „autonome Fahrzeuge“, „Fog-basiertes System“, „Cloudbasiertes System“ und „Systeme“ im Allgemeinen etc., die hierin erörtert werden, elektronische Rechenvorrichtungen umfassen, die wirksam sind, um einer Autonomes-Fahren-Umgebung zugeordnete Daten und Informationen zu empfangen, zu senden, zu verarbeiten, zu speichern oder zu verwalten. Gemäß Verwendung in diesem Dokument soll der Begriff „Computer“, „Prozessor“, „Prozessorvorrichtung“ oder „Verarbeitungsvorrichtung“ irgendeine geeignete Verarbeitungsvorrichtung umfassen, umfassend u. a. zentrale Verarbeitungseinheiten (CPUs), graphische Verarbeitungseinheiten (GPUs), anwendungsspezifische integrierte Schaltungen (ASICs; application specific integrated circuits), feldprogrammierbare Gate-Arrays (FPGAs; field programmable gate arrays), digitale Signalprozessoren (DSPs; digital signal processors), Tensor-Prozessoren und andere Matrix-Arithmetikprozessoren. Beispielsweise können Elemente, die als einzelne Vorrichtungen innerhalb der Umgebung gezeigt werden, unter Verwendung einer Mehrzahl von Rechenvorrichtungen und Prozessoren implementiert werden, wie z. B. Server-Pools, die mehrere Server-Computer umfassen. Ferner können irgendwelche, alle oder einige der Rechenvorrichtungen angepasst werden, um irgendein Betriebssystem ausführen zu können, umfassend Linux, UNIX, Microsoft Windows, Apple OS, Apple iOS, Google Android, Windows Server etc., sowie virtuelle Maschinen, die angepasst sind, um die Ausführung eines bestimmten Betriebssystems zu virtualisieren, umfassend 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 auszufü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 wirksam ist, diskrete Logik, wie beispielsweise eine anwendungsspezifische integrierte Schaltung (ASIC), eine programmierte Logikvorrichtung, wie beispielsweise ein feldprogrammierbares 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 Speichervorrichtungen 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 irgendwelche 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.
• Bezug nehmend auf 2 wird ein vereinfachtes Blockdiagramm 200 gezeigt, das eine Beispielimplementierung eines Fahrzeugs (und eines entsprechenden bordeigenen Rechensystems) 105 mit autonomer Fahrfunktionalität veranschaulicht. Bei einem Beispiel kann ein Fahrzeug 105 mit einem oder mehreren Prozessoren 202 ausgestattet sein, wie beispielsweise zentrale Verarbeitungseinheiten (CPUs), graphische Verarbeitungseinheiten (GPUs), anwendungsspezifische integrierte Schaltungen (ASICs), feldprogrammierbare Gate-Arrays (FPGAs), digitale Signalprozessoren (DSPs), Tensor-Prozessoren und andere Matrix-Arithmetikprozessoren, unter anderen Beispielen. Solche Prozessoren 202 können mit Hardware-Beschleunigungsvorrichtungen (z. B. 204) gekoppelt sein oder diese integriert haben, die mit Hardware zur Beschleunigung bestimmter Verarbeitungs- und Speicherzugriffsfunktionen ausgestattet sein können, wie etwa Funktionen im Zusammenhang mit maschinellem Lernen, Inferenz oder Training (einschließlich der unten beschriebenen maschinellen Lerninferenz oder des Trainings), Verarbeitung bestimmter Sensordaten (z. B. Kamerabilddaten, LIDAR-Punktwolken usw.), Durchführung bestimmter arithmetischer Funktionen im Zusammenhang mit dem autonomen Fahren (z. B. Matrixarithmetik usw.), Kamerabilddaten, LIDAR-Punktwolken usw.), Durchführung bestimmter arithmetischer Funktionen im Zusammenhang mit dem autonomen Fahren (z. B. Matrixarithmetik, Faltungsarithmetik usw.) und andere Beispiele. Ein oder mehrere Speicherelemente (z. B. 206) können bereitgestellt sein, um maschinenausführbare Anweisungen zu speichern, die alle oder einen Abschnitt von irgendeinem der Module oder Teilmodule eines auf dem Fahrzeug implementierten Autonomes-Fahren-Stacks implementieren, sowie um Maschinelles-Lernen-Modelle (z. B. 256), Sensordaten (z. B. 258) und andere Daten zu speichern, 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 werden, die in einer Hardware-Schaltungsanordnung und/oder Software implementiert sind, um Kommunikationsfähigkeiten zu implementieren, die durch das Fahrzeugsystem verwendet werden, um mit anderen fremden Rechensystemen über einen oder mehrere Netzwerkkanäle, die eine oder mehrere Netzwerkkommunikationstechnologien einsetzen, zu kommunizieren. Diese verschiedenen Prozessoren 202, Beschleuniger 204, Speichervorrichtungen 206 und Netzwerkkommunikationsmodule 212 können auf dem Fahrzeugsystem durch eine oder mehrere Verbindungsstrukturen oder -verknüpfungen (z. B. 208) verbunden werden, wie z. B. Strukturen, die Technologien wie z. B. u. a. Peripheral Component Interconnect Express (PCle), Ethernet, OpenCAPI™, Gen-Z™, UPI, Universal Serial Bus, (USB), Cache Coherent Interconnect for Accelerators (CCIX™), Advanced Micro Device™'s (AMD™) Infinity™, Common Communication Interface (CCI), oder Qualcomm™'s Centriq™ Verbindung nutzen.
• Um bei dem Beispiel von 2 fortzufahren, kann ein beispielhaftes Fahrzeug (und ein entsprechendes bordeigenes Rechensystem) 105 ein bordeigenes Verarbeitungssystem 210, Fahrsteuerungen (z. B. 220), Sensoren (z. B. 225) und Benutzer-/Beifahrer-Schnittstelle(n) (z. B. 230) umfassen, neben anderen beispielhaften Modulen, die die Funktionalität des autonomen Fahrzeugs in Hardware und/oder Software implementieren. Beispielsweise kann ein bordeigenes Verarbeitungssystem 210 bei einigen Implementierungen den gesamten oder einen Abschnitt eines Autonomes-Fahren-Stacks und Prozessablaufs implementieren (z. B. wie bei dem Beispiel von 5 gezeigt und erörtert). Der Autonomes-Fahren-Stack kann in Hardware, Firmware oder Software implementiert sein. Eine Maschinelles-Lernen-Maschine 232 kann bereitgestellt werden, um verschiedene an dem Fahrzeug 105 bereitgestellte Maschinelles-Lernen-Modelle (z. B. 256) in Verbindung mit einer oder mehreren autonomen Funktionen und Merkmalen zu nutzen, die an dem oder für das Fahrzeug bereitgestellt und implementiert werden, wie in den Beispielen hierin erörtert wird. Solche Maschinelles-Lernen-Modelle 256 können Modelle für künstliche neuronale Netze, faltende neuronale Netze, auf Entscheidungsbäumen basierende Modelle, Unterstützungsvektor-Maschinen (SVMs; support vector machines), Bayessche Modelle, Deep-Learning-Modelle und andere beispielhafte Modelle umfassen. Bei einigen Implementierungen kann eine beispielhafte Maschinelles-Lernen-Maschine 232 eine oder mehrere Modell-Trainer-Maschinen 252 umfassen, um an dem Training (z. B. ursprüngliches Training, kontinuierliches Training etc.) eines oder mehrerer der Maschinelles-Lernen-Modelle 256 teilzunehmen. Eine oder mehrere Inferenz-Maschinen 254 können auch bereitgestellt sein, um die trainierten Maschinelles-Lernen-Modelle 256 zu nutzen, um verschiedene Rückschlüsse, Vorhersagen, Klassifizierungen und andere Ergebnisse herzuleiten. In einigen Ausführungsformen kann das hier beschriebene Training des Maschinelles-Lernen-Modells oder die Inferenz außerhalb des Fahrzeugs durchgeführt werden, z. B. durch das Rechensystem 140 oder 150.
• Die an dem Fahrzeug bereitgestellte(n) Maschinelles-Lernen-Maschine(n) 232 kann/können verwendet werden, um Ergebnisse für die Verwendung durch andere logische Komponenten und Module des bordeigenen Verarbeitungssystems 210 zu unterstützen und bereitzustellen, die einen Autonomes-Fahren-Stack und andere mit dem autonomen Fahren zusammenhängende Merkmale implementieren. So kann z. B. ein Datensammlungsmodul 234 mit einer Logik bereitgestellt sein, um Quellen zu bestimmen, aus denen Daten gesammelt werden sollen (z. B. für Eingaben in das Training oder die Nutzung von verschiedenen durch das Fahrzeug verwendeten Maschinelles-Lernen-Modellen 256). So kann z. B. die jeweilige Quelle (z. B. interne Sensoren (z. B. 225) oder externe Quellen (z. B. 115, 140, 150, 180, 215 usw.)) ausgewählt werden, ebenso wie die Frequenz und die Genauigkeit, mit der die Daten abgetastet (gesampelt) werden können. In einigen Fällen können solche Selektionen und Konfigurationen zumindest teilweise autonom durch das Datensammlungsmodul 234 unter Verwendung eines oder mehrerer entsprechender Maschinelles-Lernen-Modelle 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 Maschinelles-Lernen-Maschine 232 und andere Module (z. B. 238, 240, 242, 244, 246 etc.) des bordeigenen Verarbeitungssystems genutzt werden. Es können ein oder mehrere Sensorfusionsmodule (z. B. 236) bereitgestellt werden, die eine Ausgabe von mehreren Sensordatenquellen (z. B. am Fahrzeug oder fahrzeugextern) herleiten können. Die Quellen können homogene oder heterogene Arten von Quellen sein (z. B. mehrere Eingaben von mehreren Instanzen eines gemeinsamen Sensortyps oder von Instanzen mehrerer unterschiedlicher Sensortypen). Ein beispielhaftes Sensorfusionsmodul 236 kann direkte Fusion, indirekte Fusion, neben anderen beispielhaften Sensorfusionstechniken, anwenden. Die Ausgabe der Sensorfusion kann in einigen Fällen als Eingabe (zusammen mit potenziell zusätzlichen Eingaben) einem anderen Modul des bordeigenen Verarbeitungssystems und/oder einem oder mehreren Maschinelles-Lernen-Modellen in Verbindung mit der Bereitstellung einer autonomen Fahrfunktionalität oder einer anderen Funktionalität, wie beispielsweise bei den hierin erörterten beispielhaften Lösungen beschrieben, zugeführt werden.
• Bei einigen Beispielen kann eine Wahrnehmungsmaschine 238 bereitgestellt sein, die als Eingaben verschiedene Sensordaten (z. B. 258) nimmt, umfassend Daten, in einigen Fällen, von Fremdquellen und/oder Sensorfusionsmodul 236, um eine Objektdetektion und/oder eine Verfolgung von detektierten Objekten auszuführen, unter anderen Beispielfunktionen, die der autonomen Wahrnehmung der von dem Fahrzeug 105 angetroffenen (oder anzutreffenden) Umgebung entsprechen. Die Wahrnehmungsmaschine 238 kann Objekterkennung von Sensordateneingaben unter Verwendung von Deep Learning ausführen, z. B. durch ein oder mehrere faltende neuronale Netze und andere Maschinelles-Lernen-Modelle 256. Die Objektverfolgung kann auch ausgeführt werden, um anhand von Sensordateneingaben autonom zu schätzen, ob sich ein Objekt bewegt und, wenn ja, entlang welcher Trajektorie. Zum Beispiel kann eine Wahrnehmungsmaschine 238, nachdem ein gegebenes Objekt erkannt wurde, 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 in einer Umgebung bewegen, die neben anderen beispielhaften Verwendungen den Pfad des Fahrzeugs auf einer Fahrbahn beeinflussen können.
• Eine Lokalisierungsmaschine 240 kann bei einigen Implementierungen auch in einem bordeigenen Verarbeitungssystem 210 umfasst sein. In einigen Fällen kann die Lokalisierungsmaschine 240 als eine Teilkomponente einer Wahrnehmungsmaschine 238 implementiert sein. Die Lokalisierungsmaschine 240 kann auch ein oder mehrere Maschinelles-Lernen-Modelle 256 und die Sensorfusion (z. B. von LIDAR- und GPS-Daten etc.) nutzen, um einen hochzuverlässigen Standort des Fahrzeugs und den Raum, den es in einem gegebenen physischen Raum (oder „Umgebung“) einnimmt, zu bestimmen.
• Ein Fahrzeug 105 kann ferner einen Pfadplaner 242 umfassen, der die Ergebnisse verschiedener anderer Module, wie z. B. der Datenerfassung 234, der Sensorfusion 236, der Wahrnehmungsmaschine 238 und der Lokalisierungsmaschine (z. B. 240) unter anderem (z. B. der Empfehlungsmaschine 244) nutzen kann, um einen Pfadplan und/oder einen Aktionsplan für das Fahrzeug zu bestimmen, der von Antriebssteuerungen (z. B. 220) verwendet werden kann, um das Fahren des Fahrzeugs 105 innerhalb einer Umgebung zu steuern. Zum Beispiel kann ein Pfadplaner 242 diese Eingaben und ein oder mehrere Maschinelles-Lernen-Modelle nutzen, um Wahrscheinlichkeiten verschiedener Ereignisse innerhalb einer Fahrumgebung zu bestimmen, um effektive Echtzeitpläne für das Handeln innerhalb der Umgebung zu bestimmen.
• Bei einigen Implementierungen kann das Fahrzeug 105 eine oder mehrere Empfehlungsmaschinen 244 umfassen, um verschiedene Empfehlungen aus Sensordaten zu erzeugen, die von den eigenen Sensoren des Fahrzeugs 105 (z. B. 225) sowie aus Sensordaten von Fremdsensoren (z. B. Sensorvorrichtungen 115, 180, 215 etc.) erzeugt werden. Einige Empfehlungen können durch die Empfehlungsmaschine 244 bestimmt werden, die als Eingaben an andere Komponenten des Autonomes-Fahren-Stacks des Fahrzeugs bereitgestellt werden können, um von diesen Komponenten vorgenommene Bestimmungen zu beeinflussen. Zum Beispiel kann eine Empfehlung bestimmt werden, die, wenn sie von einem Pfadplaner 242 berücksichtigt wird, den Pfadplaner 242 dazu veranlasst, von Entscheidungen oder Plänen abzuweichen, die er ansonsten normalerweise bestimmen würde, wäre nicht die Empfehlung. Empfehlungen können auch durch Empfehlungsmaschinen (z. B. 244) basierend auf Überlegungen zu Insassenkomfort und -erfahrung erzeugt werden. In einigen Fällen können Innenraummerkmale innerhalb des Fahrzeugs basierend auf diesen Empfehlungen (die aus Sensordaten (z. B. 258) bestimmt werden, die durch die Sensoren des Fahrzeugs und/oder Fremdsensoren etc. erfasst werden) vorausschauend und autonom manipuliert werden.
• Wie oben eingeführt, können einige Fahrzeugimplementierungen Benutzer-/Insassen-Erlebnis-Engines (z. B. 246) umfassen, die Sensordaten und Ausgaben anderer Module innerhalb des autonomen Fahrstapels des Fahrzeugs nutzen können, um eine Steuereinheit des Fahrzeugs zu steuern, um Fahrmanöver zu ändern und Änderungen an der Fahrzeugkabinenumgebung zu bewirken, um das Erlebnis der Fahrgäste innerhalb des Fahrzeugs auf der Grundlage der von den Sensordaten erfassten Beobachtungen zu verbessern (z. B. 258). In einigen Fällen können Aspekte der Benutzerschnittstellen (z. B. 230), die auf dem Fahrzeug bereitgestellt werden, um den Benutzern die Interaktion mit dem Fahrzeug und seinem Autonomes-Fahren-System zu ermöglichen, verbessert sein. In einigen Fällen können Informationspräsentationen erzeugt und durch Benutzeranzeigen (z. B. Audio-, visuelle und/oder taktile Präsentationen) bereitgestellt werden, um zu helfen, die Insassenerfahrungen innerhalb eines Fahrzeugs (z. B. 105) neben anderen beispielhaften Verwendungen zu beeinflussen und zu verbessern.
• In einigen Fällen kann auch ein Systemmanager 250 bereitgestellt sein, der die von verschiedenen Sensoren an dem Fahrzeug gesammelten Informationen überwacht, um Probleme betreffend die Performance des Autonomes-Fahren-Systems eines Fahrzeugs zu detektieren. So können z. B. Rechenfehler, Sensorausfälle und -probleme, Verfügbarkeit und Qualität der Kommunikationskanäle (die z. B. durch die Kommunikationsmodule 212 bereitgestellt werden), Fahrzeugsystemüberprüfungen (z. B. Probleme betreffend den Motor, das Getriebe, die Batterie, das Kühlsystem, das elektrische System, die Reifen etc.) oder andere Betriebsereignisse von dem Systemmanager 250 detektiert werden. Solche Probleme können in den von dem Systemmanager 250 erzeugten Systemberichtdaten identifiziert werden, die in einigen Fällen als Eingaben für die Maschinelles-Lernen-Modelle 256 und zugehörige Autonomes-Fahren-Module (z. B. 232, 234, 236, 238, 240, 242, 244, 246 etc.) verwendet werden können, um zu ermöglichen, dass die Fahrzeugsystem-Gesundheit und -Probleme zusammen mit anderen Informationen, die in den Sensordaten 258 in der Autonomes-Fahren-Funktionalität des Fahrzeugs 105 gesammelt werden, ebenfalls berücksichtigt werden können.
• Bei einigen Implementierungen kann ein Autonomes-Fahren-Stack eines Fahrzeugs 105 mit den Fahrsteuerungen 220 gekoppelt sein, um die Fahrweise des Fahrzeugs zu beeinflussen, umfassend u. a. Lenkungssteuerungen (z. B. 260), Gaspedal-/Drosselklappen-Steuerungen (z. B. 262), Bremssteuerungen (z. B. 264), Signalisierungssteuerungen (z. B. 266). In einigen Fällen kann ein Fahrzeug auch ganz oder teilweise basierend auf Benutzereingaben gesteuert werden. Benutzerschnittstellen (z. B. 230) können beispielsweise Fahrsteuerungen umfassen (z. B. ein physisches oder virtuelles Lenkrad, Gaspedal, Bremsen, Kupplung etc.), die es einem menschlichen Fahrer ermöglichen, die Kontrolle über das autonome Fahrsystem zu übernehmen (z. B. bei einer Übergabe oder nach einer Fahrerassistenz-Aktion). Andere Sensoren können verwendet werden, um Benutzer/Insassen-Eingaben zu akzeptieren, wie beispielsweise Sprachdetektion 292, Gestendetektionskameras 294 und andere Beispiele. Benutzerschnittstellen (z. B. 230) können die Wünsche und Absichten der Insassen-Benutzer erfassen, und der Autonomes-Fahren-Stack des Fahrzeugs 105 kann diese als zusätzliche Eingaben bei der Steuerung des Fahrens des Fahrzeugs (z. B. Fahrsteuerungen 220) berücksichtigen. Bei einigen Implementierungen können die Fahrsteuerungen durch externe Rechensysteme gesteuert werden, z. B. in Fällen, in denen ein Insasse eine externe Vorrichtung (z. B. ein Smartphone oder Tablet) verwendet, um die Fahrtrichtung oder die Steuerung bereitzustellen, oder in Fällen eines Remote-Valet-Service, in denen ein externer Fahrer oder ein externes System die Steuerung des Fahrzeugs übernimmt (z. B. basierend auf einem Notfallereignis), neben anderen beispielhaften Implementierungen.
• Wie vorstehend erörtert, kann der Autonomes-Fahren-Stack eines Fahrzeugs eine Vielzahl von Sensordaten (z. B. 258) nutzen, die durch verschiedene, an dem und außerhalb des Fahrzeugs bereitgestellte Sensoren erzeugt werden. Beispielsweise kann ein Fahrzeug 105 über ein Array von Sensoren 225 verfügen, um verschiedene Informationen über das Äußere des Fahrzeugs und die umgebende Umgebung, den Fahrzeugsystemzustand, die Bedingungen innerhalb des Fahrzeugs und andere Informationen zu sammeln, die durch die Module des Verarbeitungssystems 210 des Fahrzeugs verwendet werden können. Solche Sensoren 225 können neben anderen Beispielsensoren z. B. GPS- (global positioning) Sensoren 268, Licht- und Abstandsmessungs- (LiDAR-; Light Detection and Ranging) Sensoren 270, zweidimensionale (2D-) Kameras 272, dreidimensionale (3D-) oder Stereo-Kameras 274, akustische Sensoren 276, Inertiale-Messeinheiten- (IMU-; Inertial Measurement Unit) Sensoren 278, thermische Sensoren 280, Ultraschall-Sensoren 282, Bio-Sensoren 284 (z. B. Gesichtserkennung, Spracherkennung, Herzfrequenzsensoren, Körpertemperatursensoren, Emotionsdetektionssensoren etc.), Radarsensoren 286, Wettersensoren (nicht gezeigt) umfassen. Solche Sensoren können in Kombination verwendet werden, um verschiedene Attribute und Bedingungen der Umgebung, in der das Fahrzeug betrieben wird (z. B. Wetter, Hindernisse, Verkehr, Straßenzustand usw.), die Fahrgäste im Fahrzeug (z. B. Aufmerksamkeit oder Wachsamkeit der Fahrgäste oder des Fahrers, Komfort oder Stimmung der Fahrgäste, Gesundheit oder physiologischer Zustand der Fahrgäste usw.), andere Inhalte des Fahrzeugs (z. B. Pakete, Vieh, Fracht, Gepäck usw.), Teilsysteme des Fahrzeugs und andere Beispiele zu bestimmen. Die Sensordaten 258 können auch (oder stattdessen) von Sensoren erzeugt werden, die nicht integral mit dem Fahrzeug gekoppelt sind, umfassend Sensoren an anderen Fahrzeugen (z. B. 115) (die über Vehicle-to-Vehicle-Kommunikationen oder andere Techniken an das Fahrzeug 105 kommuniziert werden können), Sensoren an bodengestützten oder Flug-Drohnen 180, Sensoren von Benutzervorrichtungen 215 (z. B. ein Smartphone oder eine tragbare Vorrichtung), die von menschlichen Benutzern innerhalb oder außerhalb des Fahrzeugs 105 getragen werden, und Sensoren, die an anderen Straßenrandelementen befestigt oder mit diesen bereitgestellt sind, wie beispielsweise einer Straßenrandeinheit (z. B. 140), einem Straßenschild, einer Ampel, einer Straßenbeleuchtung etc. Sensordaten von solchen fremden Sensorvorrichtungen können direkt von den Sensorvorrichtungen an das Fahrzeug bereitgestellt werden, oder sie können durch Datenaggregationsvorrichtungen oder als Ergebnisse, die basierend auf diesen Sensoren durch andere Rechensysteme (z. B. 140, 150) erzeugt werden, bereitgestellt werden, neben anderen beispielhaften Implementierungen.
• Bei einigen Implementierungen kann ein autonomes Fahrzeugsystem 105 mit Informationen und Diensten, die von anderen Rechensystemen bereitgestellt werden, eine Schnittstelle bilden und diese nutzen, um die Autonomes-Fahren-Funktionalität der Vorrichtung 105 zu verbessern, zu ermöglichen oder anderweitig zu unterstützen. In einigen Fällen können einige Autonomes-Fahren-Merkmale (umfassend einige der hierin erörterten beispielhaften Lösungen) durch Dienste, Rechenlogik, Maschinelles-Lernen-Modelle, Daten oder andere Ressourcen von Rechensystemen außerhalb eines Fahrzeugs ermöglicht werden. Wenn solche externen Systeme für ein Fahrzeug nicht verfügbar sind, kann es sein, dass diese Merkmale zumindest vorübergehend deaktiviert sind. Beispielsweise können externe Rechensysteme bereitgestellt und genutzt werden, die in Straßenrandeinheiten oder Fog-basierten Edge-Vorrichtungen (z. B. 140), anderen (z. B. übergeordneten) Fahrzeugen (z. B. 115) und Cloud-basierten Systemen 150 (z. B. über verschiedene Netzwerkzugangspunkte (z. B. 145) zugänglich) untergebracht sind. Eine Straßenrandeinheit 140 oder ein Cloud-basiertes System 150 (oder ein anderes kooperierendes System, mit dem ein Fahrzeug (z. B. 105) interagiert, kann die gesamte oder einen Abschnitt der Logik umfassen, die als zu einem beispielhaften bordeigenen Verarbeitungssystem (z. B. 210) gehörend dargestellt ist, zusammen mit potenzieller zusätzlicher Funktionalität und Logik. Zum Beispiel kann ein Cloud-basiertes Rechensystem, eine Straßenrandeinheit 140 oder ein anderes Rechensystem eine Maschinelles-Lernen-Maschine umfassen, die entweder die Modell-Training- oder die Inferenz-Maschine-Logik, oder beides, unterstützt. Beispielsweise können solche externen Systeme über höherwertige Rechenressourcen und weiterentwickelte oder aktuelle Maschinelles-Lernen-Modelle verfügen, sodass diese Dienste bessere Ergebnisse bereitstellen können als das, was nativ auf dem Verarbeitungssystem 210 eines Fahrzeugs erzeugt würde. Beispielsweise kann sich ein bordeigenes Verarbeitungssystem 210 für bestimmte Aufgaben und die Handhabung bestimmter Szenarien auf das Maschinelles-Lernen-Training, die Maschinelles-Lernen-Inferenz und/oder die Maschinelles-Lernen-Modelle verlassen, die über einen Cloud-basierten Dienst bereitgestellt sind. Es sollte tatsächlich darauf hingewiesen werden, dass eines oder mehrere der erörterten und als zum Fahrzeug 105 gehörend dargestellten Module bei einigen Implementierungen alternativ oder redundant innerhalb eines Cloud-basierten, Fog-basierten oder eines anderen Rechensystems, das eine Autonomes-Fahren-Umgebung unterstützt, bereitgestellt sein können.
• Verschiedene Ausführungsformen hierin können ein oder mehrere maschinelle Lernmodelle verwenden, um Funktionen des autonomen Fahrzeugstapels (oder andere hierin beschriebene Funktionen) auszuführen. Ein Maschinelles-Lernen-Modell kann von einem Rechensystem ausgeführt werden, um die Performance einer bestimmten Aufgabe schrittweise zu verbessern. Bei einigen Ausführungsbeispielen können die Parameter eines Maschinelles-Lernen-Modells während einer Trainingsphase basierend auf Trainingsdaten angepasst werden. Ein trainiertes Maschinelles-Lernen-Modell kann dann während einer Inferenzphase verwendet werden, um Vorhersagen oder Entscheidungen basierend auf Eingabedaten zu treffen.
• Die hierin beschriebenen Maschinelles-Lernen-Modelle können irgendeine geeignete Form annehmen oder irgendwelche geeigneten Techniken nutzen. Beispielsweise kann irgendeines der Maschinelles-Lernen-Modelle Techniken des Überwachten Lernens (supervised learning), des Teilüberwachten Lernens (semi-supervised learning), des Unüberwachten Lernens (unsupervised learning) oder des Bestärkenden Lernens (reinforcement learning) verwenden.
• Bei Überwachtem Lernen kann das Modell unter Verwendung eines Trainingsdatensatzes aufgebaut werden, der sowohl die Eingaben als auch die entsprechenden erwünschten Ausgaben umfasst. Jeder Trainingsfall kann eine oder mehrere Eingaben und eine erwünschte Ausgabe umfassen. Das Training kann eine Iteration durch Trainingsfälle und eine Verwendung einer objektiven Funktion umfassen, um dem Modell beizubringen, die Ausgabe für neue Eingaben vorherzusagen. Bei Teilüberwachtem Lernen fehlen möglicherweise einem Abschnitt der Eingaben in dem Trainingssatz die erwünschten Ausgaben.
• Bei Unüberwachtem Lernen kann das Modell aus einem Satz von Daten aufgebaut werden, der nur Eingaben und keine erwünschten Ausgaben umfasst. Das Unüberwachte Modell kann verwendet werden, um Struktur in den Daten zu finden (z. B. Gruppieren oder Clustern von Datenpunkten), indem Muster in den Daten entdeckt werden. Techniken, die in einem Unüberwachtes-Lernen-Modell implementiert sein können, umfassen z. B. selbstorganisierende Karten (self-organizing maps), Nächste-Nachbarn- (nearest-neighbor-) Karte, k-Means-Clustering und Singulärwertzerlegung.
• Bestärkendes-Lernen-Modelle können positive oder negative Rückmeldung erhalten, um die Genauigkeit zu verbessern. Ein Bestärkendes-Lernen-Modell kann versuchen, ein oder mehrere Ziele/Belohnungen (rewards) zu maximieren. Techniken, die in einem Bestärkendes-Lernen-Modell implementiert werden können, umfassen z. B. Q-Learning, Temporal Difference (TD) und Deep Adversarial Networks (tiefe gegnerische Netzwerke).
• Verschiedene hierin beschriebene Ausführungsbeispiele können ein oder mehrere Klassifizierungsmodelle verwenden. In einem Klassifizierungsmodell können die Ausgaben auf einen begrenzten Satz von Werten beschränkt werden. Das Klassifizierungsmodell kann eine Klasse für einen Eingabesatz von einem oder mehreren Eingabewerten ausgeben. Hiesige Verweise auf Klassifizierungsmodelle können ein Modell betrachten, das z. B. irgendeine oder mehrere der folgenden Techniken implementiert: lineare Klassifizierer (z. B. logistische Regression oder naiver Bayes-Klassifizierer), Unterstützungs-Vektormaschinen, Entscheidungsbäume, geboostete Bäume (boosted trees), Random Forest, neuronale Netzwerke oder Nächster-Nachbar.
• Verschiedene hierin beschriebene Ausführungsbeispiele können ein oder mehrere Regressionsmodelle verwenden. Ein Regressionsmodell kann einen numerischen Wert aus einem durchgehenden Bereich basierend auf einem Eingabesatz von einem oder mehreren Werten ausgeben. Hiesige Verweise auf Regressionsmodelle können ein Modell betrachten, das z. B. irgendeine oder mehrere der folgenden Techniken (oder andere geeignete Techniken) implementiert: lineare Regression, Entscheidungsbäume, Random Forest oder neuronale Netzwerke.
• In verschiedenen Ausführungsformen kann jedes der hier erörterten maschinellen Lernmodelle ein oder mehrere neuronale Netze verwenden. Ein neuronales Netz kann eine Gruppe von neuronalen Einheiten umfassen, die lose der Struktur eines biologischen Gehirns nachempfunden sind, das große Gruppen von Neuronen umfasst, die durch Synapsen verbunden sind. In einem neuronalen Netz sind neuronale Einheiten mit anderen neuronalen Einheiten über Verbindungen verbunden, die sich erregend oder hemmend auf den Aktivierungszustand der verbundenen neuronalen Einheiten auswirken können. Eine neuronale Einheit kann eine Funktion ausführen, die die Werte ihrer Eingänge nutzt, um ein Membranpotenzial der neuronalen Einheit zu aktualisieren. Eine neuronale Einheit kann ein Spike-Signal an angeschlossene neuronale Einheiten weitergeben, wenn ein der neuronalen Einheit zugeordneter Schwellenwert überschritten wird. Ein neuronales Netz kann trainiert oder anderweitig angepasst werden, um verschiedene Datenverarbeitungsaufgaben (einschließlich der vom autonomen Fahrzeugstapel durchgeführten Aufgaben) auszuführen, wie z. B. Computer-Vision-Aufgaben, Spracherkennungsaufgaben oder andere geeignete Datenverarbeitungsaufgaben.
• 3 zeigt einen Beispielteil eines neuronalen Netzwerkes 300 in Übereinstimmung mit bestimmten Ausführungsformen. Das neuronale Netz 300 umfasst die neuronalen Einheiten X1-X9. Die neuronalen Einheiten X1-X4 sind neuronale Eingangseinheiten, die jeweils primäre Eingaben 11-14 erhalten (die konstant gehalten werden können, während das neuronale Netz 300 eine Ausgabe verarbeitet). Es können alle geeigneten Primäreingänge verwendet werden. Ein Beispiel: Wenn das neuronale Netzwerk 300 eine Bildverarbeitung durchführt, kann ein primärer Eingabewert der Wert eines Pixels aus einem Bild sein (und der Wert der primären Eingabe kann konstant bleiben, während das Bild verarbeitet wird). Ein weiteres Beispiel: Wenn das neuronale Netz 300 eine Sprachverarbeitung durchführt, kann sich der primäre Eingabewert, der auf eine bestimmte neuronale Eingabeeinheit angewendet wird, im Laufe der Zeit auf der Grundlage von Änderungen der eingegebenen Sprache ändern.
• Ein spezielles Topologie- und Konnektivitätsschema ist in BILD dargestellt. 3, können die Lehren der vorliegenden Offenbarung in neuronalen Netzen mit jeder geeigneten Topologie und/oder Konnektivität verwendet werden. Bei einem neuronalen Netz kann es sich beispielsweise um ein neuronales Feedforward-Netz, ein rekurrentes Netz oder ein anderes neuronales Netz mit irgendeiner geeigneten Konnektivität zwischen den neuronalen Einheiten handeln. Ein weiteres Beispiel: Obwohl das neuronale Netz mit einer Eingabeschicht, einer verborgenen Schicht und einer Ausgabeschicht dargestellt ist, kann ein neuronales Netz beliebige geeignete Schichten aufweisen, die in beliebiger Weise angeordnet sind. In der dargestellten Ausführungsform hat jede Verbindung zwischen zwei neuronalen Einheiten ein Synapsengewicht, das die Stärke der Beziehung zwischen den beiden neuronalen Einheiten angibt. Die Synapsengewichte werden als WXY dargestellt, wobei X für die präsynaptische neuronale Einheit und Y für die postsynaptische neuronale Einheit steht. Die Verbindungen zwischen den neuronalen Einheiten können sich erregend oder hemmend auf den Aktivierungszustand der verbundenen neuronalen Einheiten auswirken. So kann beispielsweise ein Spike, der sich von X1 nach X5 ausbreitet, das Membranpotenzial von X5 je nach dem Wert von W15 erhöhen oder verringern. In verschiedenen Ausführungsformen können die Verbindungen gerichtet oder ungerichtet sein.
• In verschiedenen Ausführungsformen kann eine neuronale Einheit während jedes Zeitschritts eines neuronalen Netzwerkes alle geeigneten Eingaben empfangen, z. B. einen Vorspannungswert oder eine oder mehrere Eingabespitzen von einer oder mehreren neuronalen Einheiten, die über entsprechende Synapsen mit der neuronalen Einheit verbunden sind (diese Gruppe von neuronalen Einheiten wird als neuronale Fan-in-Einheiten der neuronalen Einheit bezeichnet). Der auf eine neuronale Einheit angewendete Bias-Wert kann eine Funktion einer primären Eingabe sein, die auf eine neuronale Eingangseinheit angewendet wird, und/oder ein anderer Wert, der auf eine neuronale Einheit angewendet wird (z. B. ein konstanter Wert, der während des Trainings oder eines anderen Betriebs des neuronalen Netzwerkes angepasst werden kann). In verschiedenen Ausführungsformen kann jeder neuronalen Einheit ein eigener Bias-Wert zugeordnet werden oder ein Bias-Wert kann auf mehrere neuronale Einheiten angewendet werden.
• Die neuronale Einheit kann eine Funktion unter Verwendung der Werte ihrer Eingänge und ihres aktuellen Membranpotenzials ausführen. Beispielsweise können die Eingaben zum aktuellen Membranpotenzial der neuronalen Einheit addiert werden, um ein aktualisiertes Membranpotenzial zu erzeugen. Als weiteres Beispiel kann eine nichtlineare Funktion, wie z. B. eine Sigmoid-Transferfunktion, auf die Eingänge und das aktuelle Membranpotenzial angewendet werden. Jede andere geeignete Funktion kann verwendet werden. Die neuronale Einheit aktualisiert dann ihr Membranpotenzial auf der Grundlage der Ausgabe der Funktion.
• Bezug nehmend nun auf 4 ist ein vereinfachtes Blockdiagramm 400 dargestellt, das beispielhafte Grade des autonomen Fahrens veranschaulicht, die in verschiedenen Fahrzeugen (z. B. durch ihre entsprechenden bordeigenen Rechensysteme) unterstützt werden können. Beispielsweise kann ein Bereich von Graden definiert sein (z. B. L0-L5 (405-435)), wobei Grad 5 (L5) den Fahrzeugen mit dem höchsten Grad autonomer Fahrfunktionalität (z. B. Vollautomatisierung) entspricht und Grad 0 (L0) dem niedrigsten Grad autonomer Fahrfunktionalität (z. B. keine Automatisierung) entspricht. Beispielsweise kann ein L5-Fahrzeug (z. B. 435) über ein vollständig autonomes Rechensystem verfügen, das in der Lage ist, in jedem Fahrszenario eine Autonomes-Fahren-Performance bereitzustellen, die gleich oder besser ist als die eines menschlichen Fahrers, umfassend bei extremen Straßenbedingungen und Wetter. Ein L4-Fahrzeug (z. B. 430) kann auch als vollautonom betrachtet werden und ist in der Lage, sicherheitskritische Fahrfunktionen autonom auszuführen und den Straßenzustand während der gesamten Fahrt von einem Start- 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 „operationellen Entwurfsbereichs“ des Fahrzeugs definiert sind, der möglicherweise nicht alle Fahrszenarien umfasst. L3-Fahrzeuge (z. B. 420) stellen eine autonome Fahrfunktionalität bereit, um sicherheitskritische Funktionen in einem Satz von spezifischen Verkehrs- und Umgebungsbedingungen vollständig auf das Fahrzeug zu verlagern, die aber dennoch die Beteiligung und Verfügbarkeit menschlicher Fahrer erwarten, um das Fahren in allen anderen Szenarien zu handhaben. Dementsprechend können L3-Fahrzeuge Übergabeprotokolle bereitstellen, um die Übertragung der Steuerung von einem menschlichen Fahrer auf den Autonomes-Fahren-Stack und zurück zu orchestrieren. L2-Fahrzeuge (z. B. 415) stellen eine Fahrerassistenzfunktionalität bereit, die es dem Fahrer erlaubt, sich gelegentlich von der physischen Bedienung des Fahrzeugs zu lösen, derart, dass sowohl die Hände als auch die Füße des Fahrers periodisch von den physischen Steuerungselementen des Fahrzeugs gelöst werden können. L1-Fahrzeuge (z. B. 410) stellen eine Fahrerassistenz einer oder mehrerer spezifischer Funktionen (z. B. Lenkung, Bremsen etc.) bereit, erfordern aber dennoch eine ständige Steuerung seitens des Fahrers 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 innerhalb autonomer Fahrumgebungen teilnehmen können, z. B. durch die Bereitstellung von Sensordaten an Fahrzeuge höherer Ebenen, unter Verwendung von Sensordaten zur Verbesserung von GPS- und Infotainment-Diensten innerhalb des Fahrzeugs etc.). Bei einigen Implementierungen kann ein einzelnes Fahrzeug den Betrieb auf mehreren Autonomes-Fahren-Ebenen unterstützen. Beispielsweise kann ein Fahrer steuern und auswählen, welche unterstützte Autonomieebene während einer bestimmten Fahrt verwendet wird (z. B. L4 oder eine niedrigere Ebene). In anderen Fällen kann ein Fahrzeug autonom zwischen den Ebenen umschalten, z. B. basierend auf Bedingungen, die die Fahrbahn oder das autonome Fahrsystem des Fahrzeugs beeinflussen. Zum Beispiel kann ein L5- oder L4-Fahrzeug ansprechend auf das Detektieren, dass ein oder mehrere Sensoren beeinträchtigt wurden, in einen niedrigeren Modus (z. B. L2 oder niedriger) schalten, um angesichts des Sensorproblems einen menschlichen Insassen einzubeziehen, neben anderen Beispielen.
• 5 ist ein vereinfachtes Blockdiagramm 500, das einen beispielhaften Ablauf des autonomen Fahrens veranschaulicht, der in einigen autonomen Fahrsystemen implementiert werden kann. So kann beispielsweise ein Autonomes-Fahren-Ablauf, der in einem autonomen (oder halbautonomen) Fahrzeug implementiert wird, eine Erfassungs- und Wahrnehmungsstufe 505, eine Planungs- und Entscheidungsstufe 510 und eine Steuerungs- und Handlungsphase 515 umfassen. Während einer Erfassungs- und Wahrnehmungsstufe 505 werden Daten durch verschiedene Sensoren erzeugt und zur Verwendung durch das autonome Fahrsystem gesammelt. Die Datensammlung kann in einigen Fällen einen Datenfilterungs- und Empfangssensor aus externen Quellen umfassen. Diese Stufe kann auch Sensorfusionsoperationen und Objekterkennung und andere Wahrnehmungsaufgaben, wie beispielsweise Lokalisierung, umfassen, die unter Verwendung eines oder mehrerer Maschinelles-Lernen-Modelle ausgeführt werden. Eine Planungs- und Entscheidungsstufe 510 kann die Sensordaten und Ergebnisse verschiedener Wahrnehmungsoperationen nutzen, um probabilistische Vorhersagen über die vorausliegende(n) Fahrbahn(en) zu treffen und basierend auf diesen Vorhersagen einen Echtzeit-Pfadplan zu bestimmen. Eine Planungs- und Entscheidungsstufe 510 kann zusätzlich das Treffen von Entscheidungen in Bezug auf den Pfadplan ansprechend auf die Detektion von Hindernissen und anderen Ereignissen umfassen, um zu entscheiden, ob und welche Maßnahmen zu ergreifen sind, um den festgelegten Pfad angesichts dieser Ereignisse sicher zu überqueren. Basierend auf dem Pfadplan und den Entscheidungen der Planungs- und Entscheidungsstufe 510 kann eine Steuerungs- und Handlungsstufe 515 diese Bestimmungen in Handlungen umwandeln, durch Aktuatoren zur Manipulation der Fahrsteuerungen, umfassend Lenkung, Beschleunigung und Bremsen sowie sekundärer Steuerungen wie beispielsweise Blinker, Sensorreiniger, Scheibenwischer, Scheinwerfer etc.
• In höherwertigen autonomen Fahrzeugen ermöglicht das bordeigene Verarbeitungssystem, das einen Autonomes-Fahren-Stack implementiert, Fahrentscheidungen ohne direkte Eingaben der Fahrzeuginsassen zu treffen und zu steuern, wobei sich das Fahrzeugsystem stattdessen auf die Anwendung von Modellen, einschließlich Modellen des maschinellen Lernens, stützt, die als Eingaben Daten, die automatisch von Sensoren im Fahrzeug erfasst werden, Daten von anderen Fahrzeugen oder der nahegelegenen Infrastruktur (z. B. straßenseitige Sensoren und Kameras usw.) sowie Daten (z. B. Kartendaten), die die Geografie und die Karten der vom Fahrzeug möglicherweise befahrenen Strecken beschreiben, verwenden können. Die Modelle, auf die sich die Systeme des autonomen Fahrzeugs stützen, können auch durch Training auf Datensätzen entwickelt werden, die andere vorangegangene Fahrten (des Fahrzeugs oder anderer Fahrzeuge) beschreiben, deren Grundwahrheit auch auf der Perspektive des Fahrzeugs und den Ergebnissen beruhen kann, die es durch seine Sensoren beobachtet oder wahrnimmt. In einigen Fällen kann der „Erfolg“ eines autonomen Fahrzeugs maschinenzentriert oder übermäßig pragmatisch sein - mit dem Ziel, einen sicheren und zuverlässigen Transport von Punkt A nach Punkt B zu gewährleisten, während die einzigartigen Präferenzen und variablen menschlichen Kontexte der Fahrgäste möglicherweise keine Rolle spielen. So sind autonome Fahrzeuge zwar mit verschiedenen Sensoren ausgestattet, doch konzentrieren sich diese Sensoren in erster Linie auf die Sicherheit des Fahrzeugs, z. B. auf die Erkennung von Fahrzeugen und Hindernissen in der Umgebung sowie von Verkehrsereignissen, um sichere und verlässliche Routenpläne und Entscheidungen im Rahmen der traditionellen „Sense-Plan-Act“-Pipeline des autonomen Fahrens zu treffen. Die Erfahrungen der Fahrgäste und Empfehlungen zur Beeinflussung des autonomen Fahrmodus zur Verbesserung der Erfahrungen der Fahrgäste fehlen in den bestehenden Systemen. In diesem Sinne können von Menschen gesteuerte Fahrzeuge ein insassen- und menschenfreundlicheres Reiseerlebnis bieten, da der menschliche Fahrer wahrscheinlich besser über menschliche Zusammenhänge Bescheid weiß, die sich auf den Fahrer und seine Fahrgäste auswirken, so dass der menschliche Fahrer in der Lage ist, seinen Fahrstil anzupassen, um den Fahrgästen ein besseres Erlebnis zu bieten (z. B. Anpassung der Beschleunigung, der Lenkung und des Bremsverhaltens; Vermeidung von Straßen, die die Fahrgäste krank oder nervös machen (z. B. je nachdem, welche Fahrgäste sich im Fahrzeug befinden, wo sie sitzen, wie das Wetter draußen ist usw.); neben anderen Anpassungen. Diese verbleibenden Vorteile des menschlichen Fahrens könnten ein weiteres Hindernis für die breite Einführung autonomer Fahrzeuge darstellen.
• In einigen Implementierungen kann ein autonomes Fahrzeug mit einem Empfehlungssystem ausgestattet sein, das unter Verwendung von Computerhardware, Firmware oder Software im Fahrzeug implementiert ist (z. B. implementiert auf oder unter Verwendung des fahrzeuginternen Rechensystems des Fahrzeugs), was die Funktionalität eines autonomen Fahrzeugs verbessern kann, um Sensoren am und im Fahrzeug zu nutzen, um Insassenkontexte und -präferenzen zu erkennen und die Leistung, die gewählte Route und die internen Umgebungseinstellungen des Fahrzeugs anzupassen, um diese Insassenereignisse und -attribute zu berücksichtigen. So können z. B. Sensoren, die ursprünglich zur Unterstützung der wichtigsten autonomen Fahrfunktionen eines Fahrzeugs vorgesehen waren, zur Erfassung von Umgebungsmerkmalen innerhalb und außerhalb des Fahrzeugs sowie von Merkmalen der Fahrzeuginsassen genutzt werden. Darüber hinaus können zusätzliche Sensoren zur Verfügung gestellt werden, um die Anzahl der Eingaben zu erhöhen, die nicht nur bei der zentralen autonomen Pfadplanung und Entscheidungsfindung berücksichtigt werden können, sondern auch bei der Bereitstellung eines verbesserten und individuellen Benutzererlebnisses für die Fahrgäste. Das Empfehlungssystem kann daher mit der Pipeline des autonomen Fahrens verknüpft werden, um mit ähnlichen Eingaben zu versuchen, Unannehmlichkeiten für die Fahrgäste zu vermeiden und ein positives Insassen-Erlebnis zu gewährleisten. Neben der Beeinflussung des Fahrverhaltens des Fahrzeugs kann das Empfehlungssystem auch Funktionen innerhalb der Fahrzeugkabine aktivieren, um den Insassenkomfort zu erhöhen (z. B. Öffnen von Fenstern, Belüftung, Luftfilterung, Anpassung der Beleuchtung, dynamische Anpassung der Position von Bildschirmen, dynamische Anpassung der Sitzposition, Anpassung der Lautstärke usw.). Solche Anpassungen können auf Attribute und Ereignisse reagieren, die in der Umgebung des Fahrzeugs oder in der Insassenkabine erkannt werden.
• Bezug nehmend nun auf das vereinfachte Blockdiagramm, gezeigt in 6, implementieren Module, die in der Hardware und/oder Software eines autonomen Fahrzeugs vorgesehen sind, eine autonome Fahrpipeline, die das Erfassen 605 (wobei Daten von einer Reihe von Sensoren abgetastet werden, die am Fahrzeug und/oder in einer das Fahrzeug umgebenden Umgebung vorgesehen sind) einer Umgebung, das Planen 610 eines Pfadplans oder Manövers innerhalb der Umgebung auf der Grundlage der Sensordaten und das Handeln 615 umfasst, um die Instrumentierung am Fahrzeug zu veranlassen, den geplanten Weg oder das Manöver auszuführen. In einigen Implementierungen kann ein Empfehlungssystem 620 mit der Pipeline für autonomes Fahren (605, 610, 615) gekoppelt sein. In einigen Implementierungen kann das Empfehlungssystem 620 Informationen nutzen, die von Sensoren gesammelt werden, die in erster Linie in der Kernpipeline des autonomen Fahrens verwendet werden, sowie von zusätzlichen Sensoren außerhalb und/oder innerhalb des Fahrzeugs, um Informationen über Bedingungen zu sammeln, die sich auf das Insassen-Erlebnis auswirken können. Die Erfassungsphase 605 der Pipeline kann beispielsweise um Informationen von den externen Sensoren des Fahrzeugs über äußere Umgebungsbedingungen erweitert werden, die sich auf die Erfahrungen der Fahrgäste auswirken können, wie z. B. Wetterbedingungen, Allergengehalt, Außentemperaturen, Zustand der Straßenoberfläche (z. B. nass, staubig, klar, gesalzen usw.), Straßeneigenschaften (z. B. Kurven, Böschungen, Gefälle usw.), Höhenlage, Feuchtigkeit, Dunkelheit, Sonneneinstrahlung, Lichtverhältnisse und andere Beispiele. Darüber hinaus können Sensoren, die im Fahrzeug positioniert sind, auch zur Erfassungsphase 605 der Pipeline beitragen und Informationen wie biometrische Daten der Fahrgäste (z. B. Augenerkennung, Körpertemperatur, Herzfrequenz, Körpertemperatur, Körperhaltung, Emotionen usw.), Identitätserkennung der Fahrgäste, Erkennung der Position von Instrumenten, Bildschirmen, Sitzen und anderen physischen Komponenten des Fahrzeugs, mit denen die Fahrgäste interagieren, sowie Erkennung der atmosphärischen Bedingungen in der Fahrzeugkabine und andere Beispiele liefern.
• In der geänderten Pipeline, die in dem Beispiel von 6 dargestellt ist, führt die Empfehlungssystemphase 620 eine Sensorinformationsfusion für die erweiterten Erfassungsphaseninformationen durch und sendet eine Empfehlung an die Planungsphase 610, die verschiedene Formen annehmen kann, um das Insassenerlebnis zu verbessern und die Unannehmlichkeiten für die Insassen zu mindern. Die Planungsphase 610 kann die vom Empfehlungssystem 620 bereitgestellte Empfehlung berücksichtigen, um den von der Planungsphase 610 ermittelten Plan zu ergänzen.
• Das Empfehlungssystem 620 kann auch verwendet werden, um den Betrieb von Geräten innerhalb des Fahrzeugs zu unterstützen oder zu steuern, die von den Nutzern während der Fahrt durch eine Phase der Anpassung der Fahrzeugumgebung 625 verwendet werden können. Ein anschauliches Beispiel: Auf einer kurvenreichen Straße kann erkannt werden, dass ein Insasse ein VR/AR-Headset benutzt, und das autonome Fahrzeug kann dem Headset signalisieren, den Bildschirm im Headset zu neigen, um das Sichtfeld anzupassen, damit die Fahrt und das Seherlebnis reibungsloser verlaufen. Bei Fahrgästen, die im Fahrzeug als anfällig für Reisekrankheit erkannt werden, können rollende oder kurvige Straßen das Fahrzeug dazu veranlassen, die Luftzufuhr zu automatisieren, ein Warnsignal auszusenden, damit der Insasse seinen Blick nach vorne richtet, und andere Maßnahmen zu ergreifen. Ein weiteres Beispiel ist ein Bio-Monitor (z. B. ein Herzfrequenz- oder Atemmonitor), der vom Insassen mitgeführt wird oder im Fahrzeug vorhanden ist, um Atembeschwerden des Insassen zu erkennen, und der aus zusätzlichen Sensoren oder Daten, die Allergene identifizieren, schließen kann, dass die Atembeschwerden mit den Allergenkonzentrationen zusammenhängen, wodurch automatisch Asthmaanfälle aufgrund der Allergenkonzentrationen ausgelöst werden. Sobald dies erkannt wird, kann unter anderem die Luftreinigung durch HEPA-Filter im Fahrzeuginneren ausgelöst werden.
• Wie aus den vorangegangenen Beispielen ersichtlich ist, können die vom Empfehlungssystem des Fahrzeugs verwendeten Sensoren einige Sensoren umfassen, die nicht in das Fahrzeug integriert sind oder ursprünglich mit dem Fahrzeug geliefert wurden. Beispielsweise können tragbare Geräte, Smartphones, Media-Player und andere Geräte, die der Benutzer mit sich führt oder die nachträglich im Fahrzeug angebracht werden, Sensoren umfassen und mit dem fahrzeuginternen Rechensystem kommunizieren, das die Pipeline für das autonome Fahren implementiert, um die von diesen Geräten gesammelten Daten in der Erfassungsphase 605 bereitzustellen. In ähnlicher Weise können die Ausgaben des Empfehlungssystems 620 nicht nur Aktionen der im Fahrzeug integrierten Komponenten auslösen, sondern auch fremde Geräte (z. B. Smartphones, AR/VR-Headsets, tragbare Geräte, Nachrüstkomponenten usw.).
• Bezug nehmend nun auf 7 ist ein vereinfachtes Blockdiagramm 700 dargestellt, das eine logische Darstellung eines Empfehlungssystems zeigt. Im Allgemeinen können verschiedene Sensoren 705 bereitgestellt werden, wie oben beschrieben, und die von diesen Sensoren erzeugten Daten können an einen Sensor-Fusions-/Entscheidungsfindungsblock 735 übermittelt werden. Es können auch Insassenüberwachungssensoren 710 vorgesehen werden. Ein solcher Sensor kann verwendet werden, um bestimmte Fahrgäste im Fahrzeug biometrisch zu identifizieren. Die Erkennung einzelner Fahrgäste kann es dem Empfehlungssystem in einigen Fällen ermöglichen, auf entsprechende Präferenz- und Attributdaten der Fahrgäste zuzugreifen, die vom Empfehlungssystem ebenfalls berücksichtigt werden können. Wie bei den Fahrzeug- und Umgebungssensoren (z. B. 705) können mehrere verschiedene biometrische und Insassenüberwachungssensoren (z. B. 710) vorgesehen werden, und die von diesen Sensoren erzeugten Daten können gemeinsam mit der Sensorfusions-/Entscheidungslogik 735 verarbeitet werden. Diese Informationen können verwendet werden, um das autonome Fahren und die Pfadplanung des autonomen Fahrzeugs zu verbessern, um den Insassenkomfort zu erhöhen. Die Sensorfusionslogik (z. B. 753) kann auch dazu verwendet werden, Dienste in der Kabine bereitzustellen und Anpassungen an den Instrumenten (z. B. 720) in der Kabine vorzunehmen, die nicht direkt mit dem autonomen Fahrsystem zusammenhängen, die aber dennoch dazu beitragen können, das Benutzererlebnis und den Komfort zu verbessern.
• In diesem speziellen Beispiel, das in 7 dargestellt ist, kann das Empfehlungssystem dazu verwendet werden, bestimmte Nutzer zu unterstützen, die unter Allergien gegen Luftallergene leiden. Zu den Sensoren 705 kann beispielsweise ein Allergensensor 725 gehören, der das Vorhandensein und die Konzentration von Allergenen in der Luft innerhalb des Fahrzeuginnenraums oder in der Atmosphäre außerhalb des Fahrzeugs erkennen kann. Biometrische Monitore (z. B. 710) können bereitgestellt werden, um einen bestimmten Benutzer im Fahrzeug zu identifizieren, von dem persönliche Attributinformationen erhalten werden können, einschließlich Warnungen bezüglich der Anfälligkeit für Allergien, Asthma oder andere Empfindlichkeiten gegenüber bestimmten Allergenen. In diesem Beispiel können die Insassenmonitore/-sensoren 710 einen Herzfrequenzmonitor 730 umfassen, der einen Anstieg der Herzfrequenz von Fahrgästen im Fahrzeug erkennen kann (was in einigen Fällen darauf zurückzuführen sein kann, dass der Insasse aufgrund einer Allergie oder eines Asthmaanfalls nach Luft ringt). Der Sensorfusionsblock 735 kann in diesem Beispiel diese Sensordaten (von 725 und 730) als Eingaben verwenden und veranlassen, dass ein HEPA-Filtergerät 740 aktiviert wird, um zu versuchen, das Problem mit den Allergien zu lindern. Es ist zu verstehen, dass das Beispiel von 7 mit der Filterung von Allergenen nur ein anschauliches Beispiel für eine von vielen verschiedenen Verbesserungen des Insassenerlebnisses ist, die unter anderem durch den Einsatz eines Empfehlungssystems implementiert werden können, das in die in einem Fahrzeug vorhandene Pipeline für autonomes Fahren integriert ist.
• Ein Empfehlungssystem kann nicht nur Eingaben an die Fahrzeugsysteme liefern, damit die Fahrzeugfunktionen angepasst werden können, um den Komfort und die Erfahrung der Fahrgäste zu verbessern, sondern auch Informationen nutzen, die von den Sensoren eines autonomen Fahrzeugs gesammelt werden, um Empfehlungen zu geben, die für die Fahrgäste angesichts ihrer aktuellen Route oder ihrer Eigenschaften, Emotionen oder Ereignisse, die als für die Fahrgäste relevant erkannt wurden, relevant sind. Beispielsweise kann das Fahrzeug die Identität der Fahrgäste im Fahrzeug erkennen (z. B. durch Biomarker, wie durch Gesichts- oder Stimmerkennung) und aus den Präferenzdaten der Gruppe von Fahrgästen eine Empfehlung für ein bestimmtes Hotel oder Restaurant ermitteln, das das Empfehlungssystem als wahrscheinlich für die Gruppe von Fahrgästen im Fahrzeug geeignet erachtet und das sich auf oder in der Nähe des vom Fahrzeug befahrenen Weges befindet, neben einer Vielzahl anderer potenzieller Concierge-artiger Dienste und anderer Dienste. In dem Maße, wie die Kluft zwischen Menschen und Maschinen kleiner wird, begrüßen, akzeptieren und vertrauen die Menschen zunehmend den Maschinen und ihren Fähigkeiten. Ein Beispiel für ein Empfehlungssystem (z. B. unter Verwendung der Profil- und Präferenzinformationen der Fahrgäste) ist der Rückgriff auf eine Computerlogik, die in der Lage ist, Abfragen zu bearbeiten und Informationen zu empfehlen, z. B. zur kürzesten/schnellsten Navigation zu einem Ziel, zum nächstgelegenen „Cafe“, zu Filmempfehlungen oder dazu, wohin man zur bevorstehenden Jubiläumsfeier gehen sollte, usw.
• Es ist davon auszugehen, dass mit der Verbesserung der Systeme und Dienste und der zunehmenden Gewöhnung der Nutzer an das Zusammenspiel und die Nutzung dieser Systeme auch die Erwartungen der Nutzer immer höher werden. In dem Maße, in dem sich autonome Fahrzeuge verbreiten und durchsetzen, ist es wahrscheinlich, dass die Fahrgäste ähnlich hohe Erwartungen an ein System haben, dem sie buchstäblich ihr Leben und ihre Sicherheit anvertrauen. Die Umsetzung solcher autonomen Fahrzeuge, auf die ein Nutzer vertrauen kann, kann von hochentwickelten fahrzeuginternen Computerressourcen abhängen, die mit einer Mehrzahl von High-End-Sensoren wie Kameras, Radargeräten, LIDAR-Sensoren, 5G-Kommunikation, Hi-Def-GPS sowie Sensoren und Monitoren (und zugehöriger Logik) verbunden sind, die in der Lage sind, die Umgebung des Fahrzeugs (und seiner Insassen), das Wetter, das Gelände, die Straßenbedingungen sowie die Identität der Insassen im Fahrzeug zu erkennen (z. B. Alleinfahrt, Fahrt mit der Familie oder mit Kollegen usw.). Es ist davon auszugehen, dass solche hochentwickelten autonomen Fahrzeuge hohe Herstellungs- und Programmierkosten (und Gesamtkosten) sowie eine kostspielige und hochtechnologische Wartung und eine fein abgestimmte Sammlung für maximale, zuverlässige und genaue Leistung und Dienstgüte (QoS; Quality of Service) erfordern werden. Autonome Fahrzeuge höherer Klassen (zumindest in den ersten Generationen, bevor sie auf breiter Front eingesetzt werden) könnten daher für den Durchschnittshaushalt unerschwinglich und für die Versicherungsbranche angesichts der entstehenden Wartungs- und Ersatzteilkosten zu riskant sein. Dementsprechend ist es möglich, dass sich Lösungen für autonome Fahrzeuge auf niedriger Ebene (z. B. L1-L2) durchsetzen, bevor sich Lösungen für autonome Fahrzeuge auf höherer Ebene (z. B. L3-L5) auf dem Markt durchsetzen. So können beispielsweise teilautonome (oder sogar nichtautonome) Fahrzeuge mit integrierten oder auf dem Nachrüstungsmarkt erhältlichen, kostengünstigeren Lösungen mit vergleichbarer Dienstgüte ausgestattet werden.
• In einigen Implementierungen können übergeordnete autonome Fahrzeuge über Kommunikationsfunktionen verfügen, um über drahtlose Kommunikationskanäle mit benachbarten Fahrzeugen und Rechensystemen in diesen benachbarten Fahrzeugen zu kommunizieren, um vom autonomen Fahrzeug gesammelte und analysierte Informationen sowie Pläne, Ereignisse und andere vom autonomen Fahrzeug ermittelte Umweltinformationen auszutauschen. In einigen Fällen kann das Vorhandensein von autonomen High-End-Fahrzeugen in einer heterogenen autonomen/nicht autonomen Fahrumgebung genutzt werden, um mit den Computern von Fahrzeugen der unteren Klasse zusammenzuarbeiten und ihnen „Wissen“ über autonomes Fahren zu vermitteln. Darüber hinaus können in einigen Fällen straßenseitige Rechensysteme oder Cloud-basierte Rechensysteme verwendet werden, um mit den Rechensystemen von Fahrzeugen der unteren Klasse zu kommunizieren und die Intelligenz und Funktionalität dieser Fahrzeuge zu erweitern. Solche Lösungen und Systeme können dazu beitragen, die Abhängigkeit untergeordneter Fahrzeuge von High-End-Sensorsuiten zu minimieren und eine definierte Mindestmenge an Fähigkeiten und Diensten zu unterstützen, um Lücken bei der Bereitstellung von Kernfunktionen des autonomen Fahrens für andere benachbarte Fahrzeuge zu schließen. Ein übergeordnetes autonomes Fahrzeug, das über ein Empfehlungssystem wie das hier beschriebene verfügt, kann nicht nur bei der Bereitstellung von Informationen und Daten für die Bereitstellung autonomer Fahrfunktionen für benachbarte Fahrzeuge behilflich sein, sondern auch Ergebnisse und Dienste, die durch sein Empfehlungssystem ermöglicht werden, an benachbarte Fahrzeugsysteme weitergeben.
• Mit dem Aufkommen von Smartphones, künstlicher Intelligenz, sozialen Medien und einer wachsenden Zahl von Websites und Softwarediensten besteht in einer Vielzahl von Branchen ein Bedarf an Empfehlungssystemen. Im Bereich des Fahrens und Reisens (z. B. in autonomen Fahrzeugen) kann eine Reihe von häufigen und erwarteten reisebezogenen Abfragen und Diensten definiert werden, die mit Informationen verknüpft werden können, die über verschiedene Sensoren in einem mit autonomer Fahrlogik ausgestatteten Fahrzeug zugänglich sind. Zurück zu 6 kann eine Sammlung von Sensoren in einer Erfassungsphase 605 in erster Linie dazu dienen, die Kernfunktionen von autonomen Fahrzeugsystemen wie Pfadplanung, Fehlplanung und Entscheidungsfindung zu unterstützen. Dementsprechend kann die Planungsphase 610 neben anderen Funktionen die Pfadplanung und die Warnung vor potenziellen Herausforderungen auf der Ebene des autonomen Fahrzeugs unterstützen. Darüber hinaus können die Sensoren in der Erfassungsphase 605 auch Informationen sammeln, die den Status, die Identität und den Zustand der Fahrzeuginsassen, die Umgebungsbedingungen in Bezug auf den Komfort der Insassen (z. B. Hitze, Kälte, Feuchtigkeit usw.), die Sicherheit (z. B. den Status der Fahrzeugrückhaltevorrichtung, die Fahrt durch ein unfallgefährdetes Gebiet, die Gefahr einer Sturzflut, die Fahrt durch Gebiete mit hoher Kriminalität) und andere Informationen wiedergeben. Sensoren zur Identifizierung von Nutzern (z. B. zur Identifizierung bestimmter Nutzer, Emotionen von Nutzern und/oder demografischer Informationen der Nutzer usw.) können auch die Identifizierung von Präferenzen der Nutzer ermöglichen (z. B. durch Zugriff auf entsprechende Präferenzeinstellungen oder -modelle für die bestimmten Nutzer oder auf der Grundlage der ein- oder multimodalen Attribute der Nutzer) und bei der Erstellung von Empfehlungen (z. B. Restaurantempfehlungen, Aktivitätsempfehlungen, Änderungen der Pfadplanung, Empfehlungen für den Einzelhandel usw.) unter Verwendung des Empfehlungssystems 620 verwendet werden.
• In einigen Implementierungen kann das autonome Fahrzeugsystem im Fahrzeug durch ein Beispiel-Empfehlungssystem 620 zusätzlich die Identifizierung von Wetterproblemen entlang einer Route (z. B. Regen, Nebel, Schnee, extreme Temperaturen), Empfehlungen für Restaurants, Übernachtungsmöglichkeiten, Sehenswürdigkeiten, Tankstellen, Einzelhandelsgeschäfte usw. entlang einer Strecke, Anpassungen der Fahrzeugumgebung an die identifizierten Fahrgäste und andere Beispieldienste bieten. Die Eingaben, die zur Ableitung solcher Dienste verwendet werden, können mit denen geteilt werden, die im Rahmen der Kernfunktionalität des autonomen Fahrens des Systems verwendet werden, wie z. B. bei der Navigation und der Planung von Ausweichrouten. In einigen Implementierungen kann das Empfehlungssystem verwendet werden, um Warnungen zu generieren, die auf den Audio- und/oder Grafikdisplays des Fahrzeugs angezeigt werden, z. B. um den Fahrer vor potenziellen Problembereichen zu warnen, einen oder mehrere Fahrgäste auf ein Übergabe- oder Überholereignis vorzubereiten, die Fahrgäste vor der Wahrscheinlichkeit solcher Ereignisse zu warnen, die Fahrgäste vor potenziellen Herabstufungen der autonomen Fahrstufe zu warnen (z. B. von L5 auf L4, L4 auf L3 usw.) auf der Grundlage der vor dem Fahrzeug festgestellten Fahrbedingungen (und in einigen Implementierungen auch auf der Grundlage von Informationen über die Benutzerpräferenzen (Ermittlung der Risiko- und manuellen Fahrtoleranzen des Benutzers)), um nur einige Beispiele zu nennen. In einigen Fällen kann das Empfehlungssystem Ergebnisse und Empfehlungen für den Verbrauch durch das autonome Fahrzeug (z. B. entweder durch die Logik der Planungsphase (z. B. 610) oder durch den Block zur Anpassung der Fahrzeugumgebung (z. B. 625)) in unterschiedlichen Intervallen oder Häufigkeiten erzeugen. Auch bei der gemeinsamen Nutzung solcher Empfehlungen mit benachbarten Fahrzeugen können einige gemeinsam genutzte Empfehlungsinformationen mit einer geringeren Aktualisierungsrate zufrieden gestellt werden, während andere, wie z. B. Wetter- und Verkehrsbedingungen, eine häufigere, minutengenaue Aktualisierungsrate mit Unterstützung einer hohen Kommunikationsbandbreite und einer präzisen Positionsmeldung des Fahrzeugs erfordern, die von Fahrzeugen mit Sensoren niedrigerer Bauart kaum nativ unterstützt werden können. In einigen Fällen kann die Rate der Übermittlung von Empfehlungsinformationen von einem übergeordneten autonomen Fahrzeug an ein untergeordnetes autonomes Fahrzeug auf einer Identifizierung (durch das übergeordnete Fahrzeug) der besonderen Fähigkeiten des benachbarten Fahrzeugs beruhen. So kann beispielsweise ein benachbartes Fahrzeug mit einigen Verarbeitungsfunktionen und Sensoren ausgestattet sein, die es dem übergeordneten Fahrzeug ermöglichen, bei Erkennung dieser Fähigkeiten andere Empfehlungstypen und/oder Empfehlungen mit einer anderen Häufigkeit zu senden, als dies bei einer Schnittstelle mit einem anderen autonomen Fahrzeugmodell der unteren Ebene der Fall wäre.
• Bezug nehmend nun auf 8 wird ein vereinfachtes Blockdiagramm 800 gezeigt, das die Erweiterung eines autonomen Fahrzeugs der unteren Ebene mit verschiedenen Erweiterungsmodi veranschaulicht, von denen jeder in der Lage ist, verschiedene Modi der Umgebungsbeschreibung bereitzustellen, die, wenn sie kombiniert werden, die Low-Level-Fähigkeiten eines autonomen Fahrzeugs der unteren Ebene für einen spezifischen Satz von Bedingungen ergänzen/ergänzen, der die Kriterien der Insassen personalisiert, wodurch seine allgemeine Empfehlungsreaktion, die auf eine bestimmte Region oder ein bestimmtes Gebiet oder einen anderen Satz von Bedingungen angewendet werden kann, effektiv verbessert oder künstlich erweitert wird. Wie in diesem Beispiel gezeigt, können die Sensoren 805, die in einem bestimmten autonomen (oder nicht-autonomen) Fahrzeug der unteren Klasse eingebaut sind, durch verschiedene externe Sensoren mit höherer Leistungsfähigkeit (z. B. 810-830) ergänzt werden. Solche Sensoren, einschließlich einiger mit spezifischen Funktionen, können die Sensoren (z. B. 805) von autonomen Fahrzeugen der unteren Klasse ergänzen und sogar Daten für Empfehlungssysteme auf dem Nachrüstungsmarkt liefern, die für weniger leistungsfähige oder nicht autonome Altfahrzeuge bereitgestellt werden.
• In einigen Implementierungen können Daten, die von diesen verschiedenen Sensoren erzeugt werden, für den Verbrauch und/oder das Hosting durch eine oder mehrere Cloud- oder Fog-basierte Computerumgebungen (z. B. 835) bereitgestellt werden. In einigen Fällen kann eine solche Lösung dazu dienen, Daten, die in Umgebungen gesammelt werden, in denen sich autonome Fahrzeuge befinden, zu demokratisieren und/oder zu verallgemeinern. Die Aggregation der Sammlung von mindestens einem Teil dieser Daten kann außerdem die Durchführung zusätzlicher Verarbeitungen und die Maximierung der Datenerfassung und - auslagerung ermöglichen, um z. B. spezifische Bedürfnisse verschiedener „Client“-Fahrzeuge zu erfüllen, die mit diesen Diensten (z. B. 835) verbunden sind, um z. B. Arten von sensorinduzierten Daten für den fehlenden Typ, demografische Daten, Kontext, Lieferung von aggregierten Ergebnissen, Ergebnisse, die für eine bestimmte Region oder ein bestimmtes Gebiet einzigartig sind, und andere Beispiele zu erhalten. Solche Komponenten oder eine Teilmenge davon können die Cloud (z. B. 835) mit verschiedenen Ebenen von sensorischen Informationen versorgen, um zu helfen, die in der Umgebung gesammelten Informationen miteinander zu korrelieren und die verschiedenen Daten und Sensoren als Dienst für autonome Kundenfahrzeuge mit geringeren Sensorfähigkeiten, dauerhaft oder vorübergehend beschädigten/deaktivierten Sensoren (auch bei autonomen High-End-Fahrzeugen) oder Fahrzeugen, die weniger als eine vollständige Suite von High-Level-Sensor- oder Rechenfähigkeiten besitzen, effektiv zu integrieren, neben anderen Beispielen.
• Wie bereits erwähnt, können verschiedene Fremdsensoren verwendet werden, um eine robustere Sammlung von Sensoreingaben zu erstellen, die aggregiert, kreuzkorreliert und/oder als Daten- oder autonome Fahrunterstützung-as-a-Service gebündelt werden können. In einigen Beispielen können die Sensoren Luftdrohnen (z. B. 815), Luftschiffdrohnen (z. B. 810) oder andere fliegende Geräte mit Sensoren umfassen, die den Luftverkehr und/oder die Umwelt unterstützen. Drohnen können Verkehrsanalysen aus der Luft durchführen, einschließlich Kommunikationsfähigkeiten, um schnelle Warnungen an einen cloud- oder nebelbasierten Dienst oder direkt an autonome Fahrzeuge in Reichweite zu senden. Solche Verkehrsinformationen können beispielsweise Verkehrsberichte, Sicherheitsberichte, Unfallberichte, Notfallwarnungen, Warnungen vor Geisterfahrern, Warnungen vor Verkehrsrowdys usw. umfassen. Zeppelin-Drohnen (z. B. 810) können ähnliche Informationen und Dienste wie Flugdrohnen liefern, können aber auch bei unruhigerem Wetter eingesetzt werden. Es können auch autopilotgesteuerte, bodengestützte Drohnen und andere Fahrzeuge (z. B. 820) bereitgestellt werden (z. B. ein unbemanntes Drohnenfahrzeug, ein intelligenter Schneepflug, eine intelligente Straßenkehrmaschine, ein Fahrzeug des öffentlichen Verkehrs, ein Fahrzeug der öffentlichen Sicherheit usw.), die Systematisch oder routinemäßig verschiedene Straßenabschnitte befahren und mit Sensoren ausgestattet sein können, um den Zustand dieser Straßenabschnitte zu erfassen, um bei der Erfassung von Informationen über den Verkehrsfluss, den Zustand der Straßen (z. B. Erkennung von Schlaglöchern, Brückenzuständen, Straßenschutt, Eis oder Schnee, Smogwerten, Straßenneigung, Allergenwerten usw.). Wie bereits erwähnt, können auch Sensoren anderer autonomer Personenkraftwagen, wie z. B. hochgradig autonome Fahrzeuge (z. B. 825), sowie Beacon--, straßenseitige und in der Straße eingebettete Sensoren (z. B. 830) genutzt werden. Beacon--, straßenbegleitende und in die Straße eingebettete Sensoren (z. B. 830) können als stationäre oder bewegliche Sensoren in städtischen Gebieten und wichtigen ländlichen Gebieten (z. B. in der Nähe von Gebieten, die anfällig für Sturzfluten, Wild- und Viehübergänge, Lawinen usw. sind) positioniert werden, um Informationen zu erfassen und Daten zu liefern, die den Verkehrsfluss, das Wetter, Sicherheitsinformationen, Werbe- und Einzelhandelsinformationen, Tourismusinformationen und andere Informationen beschreiben. In einigen Fällen können diese Sensoren in andere Straßenelemente wie Verkehrsschilder, Ampeln, Werbetafeln, Bushaltestellen usw. integriert oder mit ihnen verbunden sein. Darüber hinaus können verschiedene externe Geräte (z. B. 810-830) auch als Zugangspunkt für ein untergeordnetes Fahrzeug dienen, um auf Daten von einem Cloud-Dienst (z. B. 835) zuzugreifen und diese zu empfangen, der Daten aggregiert und auf der Grundlage dieser Daten Empfehlungsdienste bereitstellt (z. B. auf der Grundlage, dass sich das Fahrzeug in der Nähe eines dieser anderen Geräte (z. B. 810-830) befindet, wenn es Empfehlungsdaten abfragt oder erhält, neben anderen Beispielimplementierungen.
• In einigen Implementierungen können Daten, die einem bordeigenen Rechensystem eines Fahrzeugs (z. B. 805) zur Verfügung gestellt werden, auf der Grundlage der spezifischen Merkmale und Fähigkeiten dieses Fahrzeugs zeitgesteuert, gefiltert und kuratiert werden. Darüber hinaus können Insasseninformationen im Fahrzeug gesammelt und (z. B. in einer gesicherten, anonymisierten Weise) mit externen Systemen (z. B. 810-830) geteilt werden, und die mit dem Fahrzeug geteilten Daten können auf der Grundlage der für die Fahrzeuginsassen bestimmten Präferenzinformationen weiter gefiltert und/oder kuratiert werden. Zusätzlich zu den insassenspezifischen Faktoren (z. B. Anzahl der Fahrgäste, demografische Merkmale der Fahrgäste, Verhältnis der Fahrgäste zueinander usw.) können weitere Faktoren, die den Umfang und die Art der Unterstützung für ein untergeordnetes Fahrzeug beeinflussen, die Tageszeit (z. B. Hauptverkehrszeit, Essenszeiten, Zeiten, die einem Arbeits- oder Schulweg entsprechen usw.), die Länge der Fahrt (z. B. Langstrecke oder Kurzstrecke) und Informationen über den Sensor- und Autonomiegrad des jeweiligen Fahrzeugmodells usw. sein. Wie in 8 gezeigt, wenn die von den Sensoren eines untergeordneten Fahrzeugs gesammelten Informationen und die Rechenkapazitäten des Fahrzeugs mit den Informationen und Diensten gekoppelt werden (bei 845), die von anderen Sensoren (z. B. bei 810-830) und den Rechenressourcen anderer Systeme (z. B. 810-835) bereitgestellt werden, um die Fähigkeiten, die Dienstgüte, die Sicherheit und den Komfort solcher untergeordneter Fahrzeuge (bei 850) zu niedrigeren, zugriffsfreundlicheren Kosten zu verbessern. In einigen Fällen können diese robusten Empfehlungsfähigkeiten auf untergeordnete Fahrzeuge ausgedehnt werden, die, wie bei einigen übergeordneten autonomen Fahrzeugen, auch insassenspezifische Präferenzen und Einstellungen (bei 840) erkennen und berücksichtigen können, wenn sie diese Empfehlungen aussprechen. In einigen Implementierungen können Empfehlungsdienste, die von solchen fahrzeugexternen Systemen bereitgestellt oder unterstützt werden, als Teil einer kommunalen, regionalen oder nationalen Infrastruktur, in Verbindung mit Werbeplattformen (z. B. Plakatwänden) oder als cloudbasiertes Sensor- oder Empfehlungssystem als Service bereitgestellt werden. Empfehlungsdienste und zusätzliche Sensordaten und -ausgaben können in einigen Implementierungen für den Verbrauch durch ein leichteres Empfehlungssystem, ein fahrzeuginternes GPS-System oder ein anderes System bereitgestellt werden, so dass die Informationen und die Funktionalität dieses bestehenden Systems durch die außerhalb des Fahrzeugs (z. B. durch 810-835) bereitgestellten Informationen und die Rechenlogik verbessert und erweitert werden, neben anderen Beispielen.
• Während im vorangegangenen Beispiel Empfehlungssysteme beschrieben werden, die es einem Fahrzeug ermöglichen, mehrere Sensoren, die von mehreren anderen Geräten bereitgestellt werden, zu nutzen, um robustere Empfehlungen für niedrigere autonome Fahrzeuge zu erstellen, kann in einigen Implementierungen eine ähnliche Infrastruktur weiter genutzt werden, um auch Empfehlungssysteme für hoch entwickelte autonome Fahrzeuge zu unterstützen. In einigen Fällen kann ein hochgradig autonomes Fahrzeug nicht nur den autonomen Betrieb auf seiner höchsten Ebene (z. B. L4 oder L5) unterstützen, sondern auch autonome Fahrfunktionen auf relativ niedrigeren Ebenen (z. B. L3). Abhängig von den Straßenverhältnissen, der Integrität der Sensoren, den Präferenzen des Fahrers und anderen Faktoren kann der Autonomes-Fahren-Stack, der über das fahrzeugeigene Rechensystem implementiert wird, so programmiert werden, dass er den Betrieb in mehreren verschiedenen Graden des autonomen Fahrens unterstützt, und er kann manuell oder automatisch (z. B. ansprechend auf ein erkanntes Ereignis oder eine Bedingung) zwischen den Graden umgeschaltet werden. Obwohl ein Benutzer im Allgemeinen in dem höchsten unterstützten Grad des Fahrzeugs verbleiben möchte (z. B. immer L4 verwenden), können die realen Sensorbedingungen des Fahrzeugs und die äußere Fahrumgebung den Benutzer während einiger Zeiträume und unter bestimmten Umständen auf niedrigere, von Menschenhand unterstützte Autonomiegrade beschränken. Wenn beispielsweise die Sensoren eines autonomen L4-Fahrzeugs auf eisigen Straßen mit Schlamm bespritzt oder mit Salz beschmiert werden, können kritische Sensoren, die den L4-Modus unterstützen, (vorübergehend) beeinträchtigt werden, so dass das Fahrzeug gezwungen ist, auf einer niedrigeren Stufe des autonomen Fahrens zu fahren, neben anderen Beispielen.
• In einigen Implementierungen können ein Empfehlungssystem oder andere Komponenten eines Bordcomputers des Fahrzeugs genutzt werden, um Fälle zu erkennen und sogar vorherzusagen, in denen das Fahrzeug möglicherweise seine autonome Fahrstufe herabstufen müsste. In einigen Beispielen kann das Empfehlungssystem ansprechend auf die Erkennung eines solchen Zustands eine Schnittstelle zu anderen Geräten oder einem Dienst bilden, der Sensordaten sammelt, die von Sensoren anderer Geräte erfasst werden, um dem autonomen Fahrzeug zusätzliche Informationen zu liefern und fehlende Informationen zu ergänzen, die typischerweise von einem seiner beeinträchtigten Sensoren erfasst und vom autonomen Fahrzeug zur Unterstützung eines höheren Autonomiemodus verwendet werden. In einem Beispiel kann zur Unterstützung solcher Funktionen ein Empfehlungssystem bereitgestellt werden, das das Auto über seine Fähigkeiten informiert. In einigen Fällen kann sich dieses Empfehlungssystem von einem Empfehlungssystem unterscheiden, das in demselben Fahrzeug vorhanden ist, um Empfehlungen für den Verbrauch durch die Benutzer und/oder zur Verbesserung des Insassenkomforts zu geben, wie in einigen der hier beschriebenen Beispiele. Wie bei anderen Empfehlungssystemen ist auch hier die zentrale „Sense, Plan, Act“-Pipeline (z. B. wie in 6) können von dem Empfehlungssystem genutzt werden. Der Sensorstatus kann in einigen Fällen durch ein Systemdiagnosetool ermittelt werden. In anderen Fällen kann die Planungslogik oder eine andere maschinelle Lernlogik des autonomen Fahrzeugs erkennen, dass die von verschiedenen Sensoren empfangenen Daten darauf hindeuten, dass die spezifischen Sensoren in irgendeiner Weise beeinträchtigt sind (z. B. blockiert, defekt, deaktiviert usw.). Auf der Grundlage des von den Sensoren erfassten Zustands kann das Fahrzeugsystem in Echtzeit den Status des Fahrzeugs und seiner autonomen Fahrfunktionen bestimmen. Auf der Grundlage dieser Statusinformationen kann das System den aktuell maximal nutzbaren Autonomiegrad bestimmen. Auf der Grundlage des ermittelten Status der Fahrzeugsensoren und der autonomen Fahrfähigkeiten des Fahrzeugs können dann Empfehlungen ausgesprochen werden. Da sich die Erfassungsmöglichkeiten im Laufe der Lebensdauer des Fahrzeugs und sogar während einer einzelnen Fahrt ändern können, können sich der Status und die entsprechenden Empfehlungen, die von einem Empfehlungssystem generiert werden, von Fahrt zu Fahrt ändern. In einigen Fällen kann das Empfehlungssystem auf der Grundlage des erkannten Szenarios und des Systemstatus Empfehlungen zur Verwendung einer bestimmten von mehreren unterstützten Autonomiegrade aussprechen. Da der Grad des autonomen Fahrens sinkt, wenn Sensordaten nicht verfügbar oder von geringerer Qualität sind, kann das Empfehlungssystem versuchen, Sensordaten zu erhalten und zu nutzen, die von anderen Geräten oder Diensten außerhalb des Fahrzeugs erzeugt und übermittelt werden (z. B. Crowdsourcing-Daten, Aktualisierungen aus der Cloud), und diese Informationen nutzen, um die Lücken in der eigenen Funktionalität des Fahrzeugs zu schließen und dadurch den Autonomiegrad des Fahrzeugs wiederherzustellen oder zu erhöhen.
• Bezug nehmend nun auf 9 wird ein vereinfachtes Blockdiagramm 900 gezeigt, das eine beispielhafte Fahrumgebung an einem bestimmten Ort veranschaulicht, die ein oder mehrere Fahrzeuge (z. B. 105, 110, 115, 905 usw.) sowie andere Geräte (z. B. 130, 180 usw.) und Strukturen (z. B. 125, 910 usw.) umfasst, die mit Sensoren (z. B. 160, 165, 170, 915 usw.) ausgestattet sind, die Informationen sammeln, die relevant und als Eingaben (oder zur Erzeugung von Eingaben) für die autonome Fahrlogik eines Fahrzeugs verwendbar sein können. In diesem Beispiel wird ein autonomes Fahrzeug 105 bereitgestellt, das autonomes Fahren bis zu einer bestimmten Stufe (z. B. L4) unterstützen kann. Am Fahrzeug 105 können verschiedene Sensoren (z. B. 920, 925, 930 usw.) vorhanden sein, um die Daten zu liefern, die von der in einem Rechensystem des Fahrzeugs 105 implementierten Pipeline für autonomes Fahren verwendet werden, um die vom Fahrzeug 105 auszuführenden Pfade und Entscheidungen zu bestimmen.
• In einer Implementierung kann das bordeigene System feststellen, dass einer oder mehrere der Sensoren (z. B. 920, 925, 930) des Fahrzeugs 105 beeinträchtigt sind, so dass die von ihnen erzeugten Daten weniger zuverlässig sind. In einigen Fällen kann die Feststellung, dass ein oder mehrere Sensoren beeinträchtigt sind, dazu führen, dass das Empfehlungssystem des Fahrzeugs den Grad der Fahrautonomie herabsetzt, weil die zuverlässigen Sensordaten zur Unterstützung der autonomen Fahrfunktion des Fahrzeugs 105 abnehmen. In anderen Fällen kann das Fahrzeug, um den Grad der Verschlechterung des autonomen Fahrgrades des Fahrzeugs 105 zu vermeiden oder zu minimieren, auf Sensordaten, Objekterkennungsergebnisse, Verkehrserkennungsergebnisse, Straßenzustandserkennungsergebnisse und andere Daten zugreifen, die von anderen Geräten (z. B. 110, 115, 125, 130, 180, 910 usw.) erzeugt werden, die für den aktuellen Standort des Fahrzeugs 105 oder für Standorte, die einem geplanten Weg oder einer geplanten Route des Fahrzeugs 105 entsprechen, relevant sind. So kann beispielsweise festgestellt werden, dass ein Sensor 925 nicht ordnungsgemäß funktioniert, und das System 105 des Fahrzeugs kann auf Daten zugreifen, die von anderen Geräten (z. B. 110, 115, 125, 130, 180, 910 usw.) erzeugt werden, um die durch den beeinträchtigten Sensor 925 verursachte verringerte Genauigkeit zu ersetzen oder zu ergänzen. In einigen Fällen kann das Fahrzeug 105 verfügbare Daten aus anderen Quellen (z. B. 110, 115, 125, 130, 155, 180, 910 usw.) auf der Grundlage des Standorts des kompromittierten Sensors filtern (z. B. um Daten von Sensoren (z. B. 160, 165, 175, am Fahrzeug 115, an der Antenne 180 usw.) zu erhalten, die am wahrscheinlichsten Informationen liefern, die normalerweise vom kompromittierten Sensor 925 (z. B. auf der linken Seite des Fahrzeugs 105) geliefert werden würden, neben anderen Beispielen. Anstatt das Fahrzeug 105 ansprechend auf einen fehlerhaften Sensor mit einem konstanten Datenstrom zu überschwemmen, können in einigen Implementierungen gezielte Anleitungen an das Fahrzeug gesendet und ähnlich gezielte Empfehlungen ausgesprochen werden, die potenziell problematischen oder herausfordernden Orten oder Ereignissen entsprechen, mit denen das Fahrzeug 105 in Anbetracht seines/ihres beeinträchtigten Sensors konfrontiert ist.
• Wie in anderen hier besprochenen Beispielen können in einigen Fällen Sensordaten und Beobachtungen, die von der Sammlung von Sensoren und ihren Geräten erzeugt wurden, an Backend-Dienste (z. B. im Netzwerk 155) weitergeleitet und von diesen aggregiert werden. In einigen Fällen können verschiedene Netzzugangspunkte (z. B. 145) Netzkommunikationskanäle mit niedriger Latenz bereitstellen, über die Fahrzeuge (z. B. 105) auf die vom Dienst gesammelten Informationen zugreifen können. In einigen Fällen kann der Dienst die Art des Fahrzeugs (z. B. 105) identifizieren und einen Bericht vom Fahrzeug 105 erhalten, der angibt, welche Sensoren (z. B. 925) beeinträchtigt sind, und diese Informationen nutzen, um die Kommunikation mit dem Fahrzeug 105 entsprechend zu filtern und zeitlich zu staffeln, je nachdem, was der Dienst als die spezifischen Bedürfnisse oder Anforderungen des Fahrzeugs 105 (im Hinblick auf das gemeldete Sensorproblem) bestimmt. Unabhängig von der Quelle der zusätzlichen Daten kann das Empfehlungssystem diese zusätzlichen Informationen nutzen, um den Betrieb des autonomen Fahrzeugs 105 zu steuern.
• In manchen Fällen kann es nur wenige Augenblicke dauern, bis der Status eines oder mehrerer Sensoren von betriebsbereit auf gefährdet abfällt. So kann zum Beispiel ein Schlammspritzer, eine unerwartete Fehlfunktion, ein schlecht eingestellter Scheinwerfer oder Sonnenlicht usw. die Integrität eines Sensors in kürzester Zeit beeinträchtigen. Die Umstellung auf einen weniger autonomen Fahrmodus mit Empfehlungserkennung in diesem Moment könnte aus betrieblicher und praktischer Sicht eine zu große Herausforderung darstellen. Dementsprechend kann ein Empfehlungssystem eines Fahrzeugs (z. B. 105) in einigen Implementierungen über prädiktive Analytik und maschinelle Lernlogik verfügen, um Fälle vorherzusagen, in denen die Verwendung des Empfehlungssystems (und zusätzlicher Sensor- und Objekterkennungsdaten) oder eine Änderung des Autonomiegrades wahrscheinlicher ist. So können beispielsweise ein oder mehrere maschinelle Lernmodelle bereitgestellt werden, die Eingaben von Systemen des Fahrzeugs (z. B. 105) entgegennehmen, um vorherzusagen, wann eine Fahrt mit größerer Wahrscheinlichkeit auf solche Änderungen des Betriebs der übergeordneten autonomen Fahrfunktionen des Fahrzeugs angewiesen ist. Zu den Eingaben können beispielsweise Informationen über den Sensorstatus, Systemdiagnoseinformationen, Statistiken über das Alter oder die Verwendung der Sensoren, Wetterinformationen (z. B. über schlammige Straßen, mit Salz behandelte Straßen, eingeschränkte Sicht usw.), Informationen über den Straßenzustand (z. B. über Straßen, die das Funktionieren der Sensoren eher behindern (z. B. unbefestigte Straßen, Straßen mit stehendem Wasser usw.) und andere Eingaben gehören. Wenn eine solche Wahrscheinlichkeit vorhergesagt wird, kann das Fahrzeug Systeme vorbereiten (z. B. im Voraus damit beginnen, Daten von anderen Geräten zu akzeptieren, die den aktuellen oder kommenden Straßenabschnitt entlang einer geplanten Route beschreiben), falls ein Problem mit einem oder mehreren der Sensoren auftritt, so dass das Fahrzeug sofort auf ein Sensorproblem reagieren und den Betrieb seiner autonomen Fahrlogik anpassen kann, neben anderen Beispielimplementierungen.
• Wie in einigen der Beispiele hierin erwähnt, können einige Implementierungen des autonomen Fahrens ein System von Sensoren verwenden, einschließlich Sensoren, die in das Fahrzeug integriert oder anderweitig mit ihm verbunden sind (einschließlich Sensoren, die Bedingungen innerhalb und außerhalb des Fahrzeugs erfassen), und Sensoren, die sich außerhalb eines bestimmten autonomen Fahrzeugs befinden und diesem fremd sind. Zumindest Teile dieser Daten können mit anderen Akteuren ausgetauscht und gemeinsam genutzt werden, z. B. durch die Kommunikation von Fahrzeug zu Fahrzeug, die Kommunikation zwischen Fahrzeugen und straßenseitigen oder an Verkehrsschildern/Signalen angebrachten Sensoren, die Kommunikation mit Backend-Sensordatenaggregatoren und -diensten, die Kommunikation zwischen Drohnen und autonomen Fahrzeugen und/oderSensordatenaggregationsdiensten, um nur einige Beispiele zu nennen. Bei übergeordneten autonomen Systemen, die High-End-Sensoren verwenden, sind viele dieser Daten sehr umfangreich und hochauflösend. Dementsprechend können solche Systeme riesige Datenmengen für die Erfassung und die Kommunikation zwischen den Geräten erzeugen, was die Skalierung und Auslagerung solcher Datenmengen (z. B. an Datenzentren, Cloud- oder Fog-basierte Dienste und andere Geräte) zu einem teuren Unterfangen macht. In einigen Implementierungen können Systemprotokolle und -logik bereitgestellt werden, um die Datenerfassung zu optimieren und effizient zu steuern, indem dynamisch die besten Ansätze innerhalb des Systems für das Auslagern von Daten (z. B. in Bezug auf Kosten und Zeit) ermittelt werden.
• Tabelle 1 zeigt eine Zusammenfassung der geschätzten Sensordaten, die am Beispiel eines einzelnen autonomen Fahrzeugs erzeugt wurden. In diesem Beispiel kann die Gesamtbandbreite bis zu 40 Gbits pro Sekunde erreichen (z. B. ~20TB/Std.). Wenn man dies mit den theoretisch Millionen von autonomen Fahrzeugen multipliziert, die eines Tages auf den Straßen unterwegs sein könnten, kann die Übertragung aller gesammelten Daten und die Speicherung einer solch riesigen Datenmenge (z. B. für Deep-Learning-Modelle zum Trainieren) unerschwinglich teuer werden. Darüber hinaus kann die bestehende Netzinfrastruktur mit der kontinuierlichen Übermittlung solch großer Datenmengen überfordert sein, so dass die Nutzung derselben Infrastruktur zum Abrufen der analysierten Daten und zur Reaktion auf Szenarien in Echtzeit gefährdet ist. Tabelle 1

  Sensoren im autonomen Kraftfahrzeug
  Sensor-Typ	Anzahl der Sensoren	Erstellte Daten pro Sensor
  Radar	6	15 Mbits/s
  LIDAR	5	100 Mbits/s
  Kamera	12	3500 Mbits/s

• In einem Beispiel kann ein autonomes Fahrsystem bereitgestellt werden, bei dem die am System teilnehmenden Geräte (z. B. einzelne autonome Fahrzeuge, Drohnen, straßenseitige Sensorgeräte, Systeme, die eine Cloud-basierte Unterstützung des autonomen Fahrens bereitstellen, usw.) mit einer Logik ausgestattet sind, die dazu beiträgt, die Gesamtmenge der gesammelten und ausgelagerten Sensordaten auf intelligente Weise zu reduzieren (z. B. indem nicht benötigte Daten entweder nicht gesammelt und/oder lokal im Fahrzeug gespeichert werden), indem maschinelle Lernmodelle und Logik zum intelligenten Hochladen und Übertragen von Daten genutzt werden. So kann beispielsweise die Sammlung von Sensordaten durch die Anwendung verteilter Trainings- und Transfermodelltechniken des maschinellen Lernens reduziert werden, um diese Kosten bzw. diesen Aufwand zu verringern. Bei einem solchen Ansatz können die „Bedingungen“, für die zusätzliche Daten von einem Gerät „benötigt“ werden, spezifiziert und mit einer maschinellen Lernmaschine auf dem Gerät (z. B. einer maschinellen Lernmaschine im angeschlossenen autonomen Fahrzeug) kommuniziert werden. Infolgedessen sammelt und überträgt das angeschlossene Gerät nur die Sensordaten, die die festgelegten Bedingungen erfüllen, die (z. B. dynamisch) aktualisiert werden können, wenn sich das Modell weiterentwickelt und trainiert wird. Darüber hinaus kann in einigen Implementierungen ein auf maschinellem Lernen basierender intelligenter Sensordaten-Upload implementiert werden, um die Übertragung von Sensordaten von einem Gerät zu einem anderen und/oder von einem Gerät zur Cloud intelligent zu filtern und zeitlich zu steuern. Herkömmliche Systeme können entweder alle Daten sammeln und offline hochladen (z. B. Hochladen der Daten am Ende des Tages oder während des Aufladens des Fahrzeugs, beim Parken usw.) oder online hochladen (z. B. ständiges Hochladen der Daten während der Fahrzeit, wenn Netzverbindungen verfügbar sind). Auch wenn einige Daten sofort oder (fast) in Echtzeit an die Cloud oder ein anderes Gerät übertragen werden müssen, ist die Übertragung aller Daten in Echtzeit nicht effizient, kostspielig und eine Verschwendung knapper drahtloser Ressourcen, wodurch die Skalierbarkeit eines solchen Systems gefährdet wird. Dementsprechend können in einem verbesserten Beispiel für ein autonomes System die teilnehmenden Sensorgeräte (z. B. vernetzte Fahrzeuge) zusätzliche maschinelle Lerntechniken verwenden, um aus Attributen wie der Zeitempfindlichkeit der Daten, der Verfügbarkeit von Datentransportoptionen (z. B. Mobilfunk, WLAN, der verfügbaren Transporttechnologie (z. B. 4G, 5G) und den Kosten und dem verfügbaren Durchsatz der Kanäle) an verschiedenen Orten und zu verschiedenen Tageszeiten sowie aus anderen Nutzungen und Präferenzen der Fahrzeugnutzer (und der entsprechenden Netzwerk- und Rechennutzung auf der Grundlage dieser Nutzungen (z. B. Medien-Streaming und Spiele im Fahrzeug usw.) lernen, um eine optimierte Option dafür zu bestimmen, wann und wie welche Daten an die Cloud oder ein anderes angeschlossenes Gerät übertragen werden sollen.
• Bezug nehmend nun auf 10 ist ein vereinfachtes Blockdiagramm 1000 dargestellt, das ein verbessertes autonomes Fahrsystem mit Blöcken (z. B. 1005, 1035, 1040, 244 usw.) zeigt, die Funktionen zur intelligenten Verwaltung der Erstellung, Speicherung und Entladung von Sensordaten bereitstellen, die von einer Sensoranordnung 1005 in einem entsprechenden autonomen Fahrzeug erzeugt werden. Beispielsweise kann das Sensorarray 1005 aus mehreren verschiedenen Sensortypen bestehen (wie hier beschrieben) und mit einer Vorverarbeitungssoftware und/oder -hardware ausgestattet sein, um eine gewisse Objekterkennung durchzuführen und Objektlistenergebnisse sowie Rohdaten zu liefern. In einigen Implementierungen kann die Vorverarbeitungslogik auch bei der Optimierung der Datenlieferung und -produktion helfen. Daten von der Sensoranordnung 1005 können an einen fahrzeuginternen Datenspeicher 1010 (oder Speicher) übermittelt werden, auf den andere Funktionsblöcke des autonomen Fahrsystems zugreifen und ihn nutzen können. Zum Beispiel kann ein Autonomes-Fahren-Stack 1015, der verschiedene Logiken der künstlichen Intelligenz und Modelle des maschinellen Lernens verwendet, die Sensordaten empfangen oder abrufen, um Ausgaben für den Betätigungs- und Steuerblock 1020 zu erzeugen, um das Fahrzeug 105 autonom zu lenken, zu beschleunigen und zu bremsen. In einigen Fällen können die vom Autonomes-Fahren-Stack 1015 erzeugten Ergebnisse mit anderen Vorrichtungen (z. B. 1025) außerhalb des Fahrzeugs 105 geteilt werden.
• Um mit dem Beispiel von 10 fortzufahren, Sensordaten, die im Datenspeicher 1010 abgelegt sind, können auch verarbeitet werden, um die Daten zu reduzieren und sie an Prozesse und Dienste zu liefern, die die Daten nicht in ihrer ursprünglichen Auflösung benötigen. So kann beispielsweise eine verlustfreie Transcodierung (bei 1030) durchgeführt werden. In einigen Implementierungen kann eine auf maschinellem Lernen basierende verlustbehaftete Intra-Frame-Transcodierung (mit Block 1035) sowie eine auf maschinellem Lernen basierende Erkennung von Ereignissen/Szenen und Szenarien (bei 1040) durchgeführt werden. Die von diesen Blöcken (z. B. 1030, 1035, 1040) erzeugten übersetzten Daten können einem Empfehlungssystem 244 des autonomen Fahrzeugs zur Verfügung gestellt werden, das zur Erkennung und Vorhersage von Eigenschaften von Kommunikationskanälen und Empfängern der aufbereiteten Daten verwendet werden kann. In einigen Fällen kann eine dynamische Datenleitung 1045 vom Empfehlungssystem 244 unterstützt werden, die Cloud- und/oder Fogbasierten Diensten und Repositorien (z. B. 1055, 1060) zur weiteren Verarbeitung zur Verfügung gestellt werden kann. Zusätzlich kann das Empfehlungssystem 244 (wie auch andere Komponenten des autonomen Fahrsystems) Ergebnisdaten (z. B. 1050) von anderen Sensorgeräten und cloudbasierten Diensten (z. B. 1055, 1060) nutzen, wie z. B. Ergebnisse von anderen Maschinelles-Lernen-Modellen, die als Eingaben Sensordaten von einer Mehrzahl von autonomen Fahrzeugen und anderen Sensorgeräten verwenden, neben anderen Beispielen.
• In einer beispielhaften Ausführungsform kann ein autonomes Fahrsystem mindestens die von zwei Sensoren (z. B. Front- und Heckkameras mit einer Auflösung von 2 Megapixeln (MP), die mit 30 Bildern pro Sekunde (fps) arbeiten) gesammelten Daten verarbeiten und analysieren, wobei ein oder mehrere maschinelle Lernmodelle verwendet werden, die vom fahrzeuginternen autonomen Fahrsystem ausgeführt werden, um den Weg zu planen und auf verschiedene Szenarien zu reagieren. In manchen Fällen verfügen autonome Fahrzeuge nicht über Modelle oder eine Logik, die „erfahren“ genug sind, um in komplexen und dynamischen Umgebungen ohne ständige Datenerfassung (von den eigenen Sensoren und externen Quellen) und kontinuierliches oder inkrementelles Training der Modelle voll zu funktionieren. Die Durchführung einer solchen Wartung anhand der gesammelten Daten kann in der Tat eine kritische Aufgabe sein, zumal der Einsatz autonomer Fahrzeuge noch in den Kinderschuhen steckt. In einem solchen Szenario kann die Menge der zu erfassenden, zu verarbeitenden und zu speichernden Daten jedoch sehr teuer sein. Bei zehn autonomen Fahrzeugen, die täglich vier Stunden lang fahren und jeweils mit zwei Kamerasensoren mit einer Auflösung von 2 MP (24 Bit pro Pixel) bei 30 Bildern pro Sekunde arbeiten, werden beispielsweise 2880 MBit pro Sekunde (360 MByte pro Sekunde) an Daten generiert. In nur vier Stunden werden insgesamt 51,48 TB an Daten erzeugt. In einem Jahr, wenn man von einer durchschnittlichen Arbeitszeit von 261 Tagen ausgeht, wird die Gesamtdatenmenge, die von diesen zehn Autos erzeugt wird, fast 14 Peta Bytes an Daten betragen.
• In einigen Implementierungen kann ein Empfehlungssystem (z. B. 244) Bedingungen erkennen, denen ein verbundenes Fahrzeug derzeit ausgesetzt ist oder voraussichtlich ausgesetzt sein wird, und Datenverarbeitungsverfahren für andere Komponenten des autonomen Fahrsystems empfehlen und anweisen, einschließlich der Auslagerung von Daten an externe Systeme, der Anwendung von Transcodierung und Komprimierung auf Sensordaten und sogar der Erzeugung der Sensordaten selbst durch die Sensoranordnung 1005. Beispielsweise kann das Empfehlungssystem 244 empfehlen, dass der Betrieb eines oder mehrerer Sensoren in der Sensoranordnung 1005 auf der Grundlage der ermittelten Bedingungen, unter denen sich das Fahrzeug befindet, angepasst wird (z. B. Bedingungen, die sich auf die Netzwerkressourcen und die Möglichkeiten der gemeinsamen Datennutzung für das Fahrzeug auswirken, Bedingungen, die sich auf die Komplexität der autonomen Fahraufgaben und Klassifizierungen auswirken, denen sich das Fahrzeug auf einem geplanten Weg gegenübersieht, usw.). Beispielsweise kann das Empfehlungssystem 244 einen oder mehrere Sensoren in der Sensoranordnung anweisen, die von den Sensoren erzeugte Qualität, Auflösung oder Wiedergabetreue auf der Grundlage dieser Bedingungen anzupassen, z. B. durch Angabe einer minimal akzeptablen Qualität der Daten auf der Grundlage der Bedingungen (z. B. auf der Grundlage der Sensorrate, der Bilder pro Sekunde, des Schnittfensters, der maximalen Bitrate usw.).
• In einigen Implementierungen können Daten-Resampling und Pruning angewandt werden, um die Menge der von den Sensorgeräten eines autonomen Fahrzeugs ausgegebenen Daten zu reduzieren. Aufgrund der hohen Korrelation zwischen den von den Kamerasensoren eines autonomen Fahrzeugs erzeugten Videobildern kann die Größe der von diesen Kameras erzeugten Daten durch Resampling um mehrere Faktoren reduziert werden (z. B. reduziert das Resampling der Daten von 30 Bildern pro Sekunde auf 1 Bild pro Sekunde die Datengröße um einen Faktor 30). In einigen Fällen kann auch eine verlustfreie Komprimierung angewendet werden (z. B. mit einer 50-fachen Komprimierungsrate), so dass die Nettoreduzierung der Daten, wenn sowohl die Neuabtastung als auch die Komprimierung angewendet werden, zu komprimierten Daten führt, die etwa 0,05 % der ursprünglichen Datengröße betragen. Dementsprechend kann die Datenmenge des vorangegangenen Beispiels durch Downsampling und umfangreiche Vorverarbeitung der gesammelten Daten (bei einer Auflösung, bei der ein genaues Training möglich bleibt) auf etwa 6 Tera Bytes Daten von den zehn Beispielfahrzeugen mit zwei 30fps mit 2MP-Kamerasensoren reduziert werden, neben anderen Beispielen.
• Das obige Beispiel verdeutlicht die Schwierigkeiten bei der Verarbeitung von Daten, die von zehn autonomen Fahrzeugen mit jeweils nur zwei Kamerasensoren erzeugt werden. In komplexeren Szenarien können sich jedoch Tausende von autonomen Fahrzeugen die Fahrbahn teilen und mit viel mehr Sensoren unterschiedlicher Art ausgestattet sein. Dementsprechend können in solch komplexen Szenarien Tausende von Peta-Bytes an Daten erzeugt und über drahtlose Kommunikationskanäle innerhalb einer autonomen Fahrumgebung übermittelt werden. Die Übertragung all dieser Daten und ihre Speicherung in Cloud-Systemen zu Schulungszwecken ist eine sehr teure und zeitaufwändige Aufgabe. Tabelle 2 zeigt die Trainingsdauer für einige Beispielmodelle des maschinellen Lernens, die in einem autonomen Fahrsystem (z. B. mit einem Grafikprozessor mit 332 GFLOPS Leistung) eingesetzt werden können und die generierten Sensordaten von mehreren Fahrzeugen oder Sensorgeräten verwenden. Tabelle 2

  Modell	Anzahl der Parameter (in Millionen)	GFLOPS	Zugzeit (für 100 Epochen)
  AlexNet	60,97	1,34	6.3 Std.
  VGG-16	138,36	14,7	69.59 Std.
  GoogleNet V1	7	1,6	7.54 Std.
  ResNet-50	25,56	3,9	18.39 Std.
  ResNet-152	60,19	11,4	53.76 Std.
  Einführung V4	42,71	12,35	58.24 Std.

• In einigen Implementierungen, wie im vereinfachten Blockdiagramm 1100 von 11 gezeigt, kann ein auf maschinellem Lernen basierender verlustbehafteter Inter-Intra-Frame-Transcoder 1035 eine gleichzeitige Datenkompression mit Standard-Codecs (JPEG2000, m-jpeg, mpeg4 und verlustfreiem mpeg4s) sowie eine fortgeschrittene, auf maschinellem Lernen basierende Superkompression durchführen. Diese Art der Datenkomprimierung kann dazu beitragen, aufgenommene Bilder in verschiedene Profile umzuwandeln (z. B. Bitrate, Bildrate und Übertragungsfehlerbeschränkungen), neben anderen Anwendungsbeispielen und Beispielen für mögliche Vorteile. So kann z. B. ein hochkarätiger, wenig komprimierter Datenstrom verschoben werden, um die Effizienz des aktuellen Netzes zu verbessern, wenn ein Fahrzeug durch Gebiete mit geringer Bandbreite fährt, neben anderen Anwendungsbeispielen.
• Wie durch die vereinfachten Blockdiagramme 1200, 1300 von 12 und 13 gezeigt, kann ein auf maschinellem Lernen basierendes System zur Erkennung von Ereignissen oder Szenarien (z. B. 1040) verwendet werden, um die Datenübertragung und -speicherung in einem autonomen Fahrsystem zu verbessern. Wie bereits erwähnt, kann eine passive, unkontrollierte Datenerfassung und -übertragung sehr teuer sein. In einigen Implementierungen kann die Filterung der Datenerfassung und -übertragung im Wesentlichen auf der Grundlage von internen und/oder externen Ereignissen erfolgen, die auf maschinell erlernten Ereignis- und/oder Szenenklassifizierungen basieren (was eine Empfehlung bei der Datenerfassung darstellt). So kann die Erkennung eines Ereignisses, wie z. B. eines oder mehrerer defekter Sensoren in einem angeschlossenen Fahrzeug, eine Zunahme der Kommunikation mit fremden Datenquellen (z. B. anderen angeschlossenen Fahrzeugen oder anderen Sensorgeräten) verursachen. Als weiteres Beispielszenario oder -ereignis kann die Erkennung einer bestimmten Art von schlechtem Wetter (z. B. Nebel, Schnee, Regen usw.) das Fahrzeug dazu zwingen, keine mehrdeutigen Daten zu verwenden, hochauflösende Daten zu erhalten und zu verwenden, seine eigenen Sensordaten mit zusätzlichen Daten aus anderen externen Quellen zu ergänzen, um nur einige Beispiele zu nennen. Solche Ereignisse können durch die Bereitstellung von Daten von einem oder mehreren Sensoren des angeschlossenen autonomen Fahrzeugs an ein oder mehrere maschinelle Lernmodelle (z. B. 1205) erkannt werden. Zum Beispiel, wie bei dem Beispiel von 12 gezeigt, können interne Systemzustandsinformationen 1210 (z. B. von einem oder mehreren internen Sensoren und/oder einem Systemdiagnosemodul) zusammen mit Daten 1215 (von integrierten oder externen Sensoren) bereitgestellt werden, die die Bedingungen der äußeren Umgebung des Fahrzeugs beschreiben (z. B. Wetterinformationen, Straßenzustand, Verkehrsbedingungen usw.) oder die Umgebungsbedingungen entlang bevorstehender Abschnitte eines festgelegten Streckenplans beschreiben, neben anderen Beispieleingaben. Das Maschinelles-Lernen-Modell 1205 kann eine oder mehrere Arten von Ereignissen aus diesen Eingaben bestimmen, wie z. B. defekte oder anderweitig beeinträchtigte Sensoren (z. B. 1220) und Wetterereignisse (z. B. 1225), wie oben beschrieben, sowie Kommunikationskanalmerkmale (1230) (z. B. (z. B. Bereiche ohne Netzabdeckung, unzuverlässige Signale oder drahtlose Kanäle mit geringer Bandbreite, die das Fahrzeug zwingen können, umfangreiche Daten oder Daten mit höherer Genauigkeit für die künftige Verwendung unter Verwendung von Ereignis- und Klassifizierungsmodellen zu sammeln) sowie Straßenzustands- und Verkehrsereignisse (z. B. 1235) (die das Fahrzeug zwingen können, die Klassifizierung und Datenübertragung in Echtzeit zu priorisieren), um nur einige Beispiele zu nennen.
• Das Beispiel aus 13 veranschaulicht ein vereinfachtes Blockdiagramm 1300 einen auf maschinellem Lernen basierenden Szenenklassifizierungsblock 1305, der in das autonome Fahrsystem eines verbundenen Fahrzeugs integriert werden kann. Verschiedene Sensordaten 1310, wie z. B. Kameradaten, Radardaten, LIDAR-Daten, IMU-Daten und andere Sensordaten, können als Eingaben (z. B. multimodale Eingaben) für das Klassifizierungsmodell (z. B. ein trainiertes neuronales Faltungsnetzwerk) bereitgestellt werden, aus dem Szenenklassifizierungen ausgegeben werden können. Beispielsweise kann das Modell anhand der bereitgestellten Sensordaten erkennen, dass sich das Fahrzeug gerade in einem Ort mit bestimmten Umgebungsmerkmalen befindet (oder sich in Kürze dort befinden wird, basierend auf einem Routenplan). Diese Umgebungsmerkmale können ein Empfehlungssystem auf dem autonomen Fahrzeug beeinflussen, das für die Datenerfassung und -abgabe durch das autonome Fahrsystem des Fahrzeugs verantwortlich ist. Beispielsweise kann das Modell 1305 anhand der Eingaben 1310 feststellen, dass die Fahrzeugumgebung eine städtische Umgebung ist, die durch ein hohes Verkehrsaufkommen und dynamische Bedingungen gekennzeichnet ist (z. B. 1315), eine gut ausgebaute Autobahn, die durch weitgehend statische Fahrbedingungen gekennzeichnet ist (z. B. 1320), ein offenes Land oder Wälder, die durch weitgehend ungeübte Straßen und eine wahrscheinlich unterentwickelte Infrastruktur zur Unterstützung des autonomen Fahrens gekennzeichnet sind (z. B. 1325), sowie andere Beispiele. Tatsächlich können aus den Sensordaten 1310 auch ortsbezogene oder -spezifische Szenen oder Warnungen (z. B. 1330) erkannt werden, wie z. B. Zonen mit schwachen Signalen, Unfälle, anormale Hindernisse oder Straßenhindernisse usw. Die maschinellen Lernmodelle eines beispielhaften Empfehlungssystems können als Eingaben sowohl die Ereignisklassifizierungen (z. B. vom Modell 1205) als auch die Szenenklassifizierungen (z. B. vom Modell 1305) akzeptieren, um zu bestimmen, ob und wie Sensordaten gesammelt und ausgelagert werden sollen und mit welcher Genauigkeit, Häufigkeit usw. Beispielsweise können Szenen und Ereignisse, bei denen die Entscheidungsfindung des autonomen Fahrsystems wahrscheinlich aktiver ist (z. B. eine städtische Umgebung bei schlechtem Wetter), dazu führen, dass das Empfehlungssystem eine Datenerfassung mit hoher Genauigkeit, eine Echtzeit-Klassifizierung der Sensordaten und eine Kommunikation mit hoher Bandbreite und geringer Latenz mit verschiedenen externen Sensorgeräten und Diensten anordnet, neben anderen Beispielen. Im umgekehrten Fall, auf einer Autobahn bei klarem Wetter, wo die Sensoren des Fahrzeugs als voll funktionsfähig erkannt werden, kann das Empfehlungssystem eine andere Handhabung der Erfassung, Verarbeitung und Entladung von Sensordaten anordnen, neben einer Mehrzahl anderer Beispiele, die letztendlich durch das Zusammenwirken von Faktoren bestimmt werden, die für die Szene und die Ereignisse, mit denen ein autonomes Fahrzeug konfrontiert ist, erkannt werden.
• Bezug nehmend nun auf das vereinfachte Blockdiagramm 1400 in 14 kann ein Empfehlungssystem zusätzlich zur Berücksichtigung der Umstände des autonomen Fahrzeugs und der unmittelbaren Anforderungen, die diese Umstände an die Pfadplanungs- und Entscheidungsfindungslogik des autonomen Fahrsystems des Fahrzeugs stellen, auch die Beschaffenheit der Kommunikationsinfrastruktur berücksichtigen, die für das Senden und Empfangen von Daten mit anderen Geräten, Fahrzeugen oder Diensten zur Verfügung steht, um zu bestimmen, wie die in diesem Moment auf das Fahrzeug angewendeten Richtlinien für das Abladen und Sammeln von Daten zu steuern sind. Beispielsweise kann das System eine Empfehlung aussprechen, wie ein anstehender Daten-Upload in Übereinstimmung mit einer dynamischen Daten-Upload-Pipeline erfolgen soll, die ebenfalls ein oder mehrere maschinelle Lernmodelle nutzen kann, um auf intelligente Weise eine optimierte Art und Weise der Durchführung des Uploads zu bestimmen (z. B. anstelle der passiven Durchführung des Uploads in einer vordefinierten Art und Weise (z. B. nachts, beim Parken usw.). Ein solcher dynamischer, auf maschinellem Lernen basierender Ansatz kann zu erheblichen Kosten- und Bandbreiteneinsparungen sowohl für das Fahrzeug als auch für die für diese Uploads genutzte Netzinfrastruktur führen.
• Wie bei dem Beispiel von 14 gezeigt, in einigen Fällen kann ein Empfehlungssystem die Art und Weise des Hochladens von Daten durch ein autonomes Fahrzeug anpassen, z. B. durch Hochladen mindestens eines ausgewählten Teils der Sensor- oder Ergebnisdaten, die im Fahrzeug erzeugt werden, zu Nebel-, Cloud- oder Edge-Cloud-Systemen (z. B. Edge-Computing-Server, Nebelgerät oder straßenseitige Einheit). Solche Uploads können sowohl auf der Menge der hochzuladenden Daten als auch auf den Eigenschaften der verfügbaren Verbindungen basieren. Ein autonomes Fahrzeugsystem kann die Kommunikation mit einer Vielzahl verschiedener Geräte und Dienste über eine Vielzahl verschiedener Kommunikationstechnologien unterstützen (z. B. Bluetooth, Millimeterwellen, WiFi, zellulare Daten usw.) und kann ferner Entlastungsentscheidungen auf der Grundlage der erkannten Kommunikationskanaltechnologien, die in einer Umgebung verfügbar sind, und der potenziellen Datenentlastungs- oder -freigabe-Partner treffen (z. B. Verbindung mit einer Straßenrandeinheit über Bluetooth oder WiFi, einem Nebelelement über mmWave, einem Edge-Computer-Server oder Cloud-Dienst über 5G usw.). Die Zeit und die Netzwerkbandbreite, die bei der Datenübertragung verbraucht werden, können ebenfalls berechnet und von einem maschinellen Lernmodell eines Empfehlungssystems bei der Bestimmung des Entladeverhaltens des Fahrzeugs berücksichtigt werden. Wenn beispielsweise mehrere potenzielle Entladeziele verfügbar sind, kann das Empfehlungssystem auf der Grundlage der in einer Umgebung festgestellten Konnektivitätsmerkmale aus den mehreren potenziellen Alternativen auswählen. So kann der Empfehlungsgeber beispielsweise ein bestimmtes Ziel für den Offload und den zu verwendenden Kommunikationskanal oder die zu verwendende Technologie auswählen. Das Empfehlungssystem kann auch die Art und Sensibilität der zu übertragenden Daten berücksichtigen (z. B. werden missionskritische Daten (z. B. nach oder während eines Unfalls) anders behandelt als Daten, die in erster Linie für die Erstellung von Karten verwendet werden), um nur einige Beispiele zu nennen.
• 14 zeigt verschiedene Beispiele für Empfehlungen, die ein Empfehlungssystem für das Auslagern von Daten geben kann. Wenn beispielsweise bei 1405 wichtige, zeitkritische Daten ausgelagert werden sollen (z. B. an eine Edge-Vorrichtung oder ein anderes Fahrzeug (z. B. 110)), aber kein Datenpfad mit hoher Bandbreite erkannt wird, können die vom Empfehlungssystem angewendeten Maschinelles-Lernen-Modelle zu einer Empfehlung führen, die Daten in einem Format mit geringer Auflösung zu senden (z. B. 1425), das lediglich die Koordinaten von abstrakten Hindernissen beschreibt, die vom Fahrzeug 105 erkannt wurden. In einem anderen Beispiel, in dem das Fahrzeug 105 Daten auszulagern hat, aber nur eine partielle Bandbreitenbedingung erkannt wird (bei 1410), kann das Empfehlungssystem bestimmen, dass die Daten in einem vorverarbeiteten Format mit geringerer Bandbreite (z. B. 1430) an lokale Nebelsysteme (z. B. 1420) ausgelagert werden. Die Nebelressourcen 1420 können diese Daten dann anderen Geräten (z. B. dem Kraftfahrzeug 110) oder sogar dem bereitstellenden Fahrzeug 105 (z. B. zu einem späteren Zeitpunkt) zur Verfügung stellen. In einem weiteren Beispiel kann ein Kanal mit niedriger Latenz und hoher Bandbreite erkannt werden (z. B. zu einem Zeitpunkt, zu dem das Fahrzeug auch als fahrend erkannt wird, unter Bedingungen, bei denen die Netzwerkkommunikation und die Rechenressourcen Kapazität haben (z. B. während der Fahrt auf der Autobahn, im geparkten Zustand usw.), und der Offload kann mit Daten in voller Auflösung (z. B. 1435) direkt an Cloud-basierte Backend-Systeme (z. B. 150) durchgeführt werden, neben anderen Beispielen.
• Während alle Funktionen, die für das autonome Funktionieren eines Fahrzeugs erforderlich sind, nativ durch fahrzeuginterne Rechensysteme bereitgestellt werden können (und bei Bedarf durch regelmäßige Kommunikation über drahtgebundene oder drahtlose Heim- oder Garagennetzwerke aktualisiert werden), können sich einige autonome Fahrzeugimplementierungen mit dem Fortschritt der drahtlosen Kommunikationstechnologien und -geschwindigkeiten stärker auf die Kommunikation von externen Daten- und Rechenressourcen (z. B. außerhalb des Fahrzeugs oder nicht nativ in das Fahrzeug integriert) verlassen. Mit dem Aufkommen von 5G-Trägernetzen und der Ausweitung der 4G-LTE-Abdeckung werden beispielsweise Implementierungen von vernetzten autonomen Fahrzeugen und Vehicle-to-Everything-Systemen (V2X) sofort realisierbar. Angesichts des hohen Stellenwerts der Sicherheit kann die Sicherheit, die autonome Fahrsysteme in Fahrzeugen bieten, durch fahrzeugexterne Systeme ergänzt, erweitert und verbessert werden, um sowohl erweiterte und von der Masse bereitgestellte Intelligenz als auch Redundanz zu bieten, z. B. durch hoch zuverlässige Echtzeitanwendungen.
• Ein autonomes Fahrzeug kann mit externen Rechnersystemen kommunizieren und von diesen gesteuert werden. Eine solche Steuerung kann eine niedrige Steuerungsebene umfassen, wie z. B. das Einspielen von Over-the-Air-Updates (OTA), bei denen das Fahrzeug von einer Fernsteuerungs-/Wartungszentrale (z. B. des Originalgeräteherstellers (OEM) oder Anbieters des Fahrzeugs oder des autonomen Fahrsystems) Software- und/oder Firmware-Updates erhält (z. B. im Gegensatz zur manuellen Durchführung durch einen Techniker, der das Fahrzeug zur Wartungszentrale bringt). Bei anderen Anwendungen mit höherer Kontrolldichte kann die vollständige Kontrolle über ein autonomes Fahrzeug an ein externes Rechensystem oder einen entfernten Benutzer/virtuellen Fahrer auf einem entfernten Computerterminal übergeben werden. Eine solche Fernsteuerung kann z. B. als „Remote-Valet“-Service auf Abruf angeboten werden, wenn eine Übergabe der Kontrolle von einem autonomen Fahrzeug an einen Fahrzeuginsassen nicht möglich oder unerwünscht ist, um ein Fahrzeug zu unterstützen, dessen autonomes Fahrsystem Schwierigkeiten hat, einen bestimmten Streckenabschnitt genau, effizient oder sicher zu navigieren, oder um bei einem Überschlag oder einem anderweitig stillstehenden autonomen Fahrzeug zu helfen.
• Wenn ein autonomes Fahrzeug auf eine Situation oder ein Ereignis stößt, das das autonome Fahrzeug nicht zuverlässig und sicher bewältigen kann, kann das Fahrzeug so programmiert werden, dass es einen Überholvorgang einleitet, bei dem das autonome Fahrsystem das Fahrzeug von der Fahrbahn ablenkt (z. B. auf den Seitenstreifen einer Straße, in eine Parklücke usw.). In Zukunft, wenn autonome Fahrzeuge in größerer Zahl auf den Straßen anzutreffen sind, kann ein Ereignis, das ein autonomes Fahrzeug dazu veranlasst, ein Überholmanöver einzuleiten, auch andere benachbarte autonome Fahrzeuge betreffen, was zu der Möglichkeit führt, dass mehrere Überholmanöver zusätzliche Staus und Verkehrsbehinderungen verursachen, wodurch die Fahrbahn und das autonome Fahren auf diesen Straßen möglicherweise lahmgelegt werden. Während in einigen Fällen ein Übergabeereignis vom autonomen Fahrsystem an einen menschlichen Beifahrer möglich ist, um die Situation, die zum Anhalten führt, zu steuern, kann in anderen Fällen ein Remote-Valet-Service ausgelöst werden (z. B. wenn das Fahrzeug ohne Beifahrer ist (z. B. ein Drohnenfahrzeug, ein Fahrzeug, das zu seinen Fahrgästen unterwegs ist, indem es eine ferngesteuerte Ruffunktion verwendet, usw.)), neben anderen Beispielsituationen und -implementierungen.
• In Übereinstimmung mit den obigen Ausführungen können einige Implementierungen eines autonomen Fahrzeugs einen Remote-Valet-Modus unterstützen, der es ermöglicht, das Fahren des Fahrzeugs (vom autonomen Fahrsystem des Fahrzeugs) an ein entferntes Rechensystem zu übergeben und von diesem über ein Netzwerk zu steuern. Die Fernsteuerung des autonomen Fahrzeugs kann beispielsweise auf Anforderung durch das autonome Fahrzeug ausgelöst werden, wenn es mit einer Situation konfrontiert ist, die es nicht bewältigen kann (z. B. wenn die Sensoren nicht funktionieren, eine neue, für das Fahrzeug unbekannte Straßensituation vorliegt, das bordeigene System nicht in der Lage ist, eine Entscheidung zu treffen, usw.). Eine solche Fernsteuerung kann dem Fahrzeug auch in Notsituationen zur Verfügung gestellt werden, in denen das Fahrzeug die Fernsteuerung verlangt. Bei einem Remote-Valet-Service kann ein Mensch in einem Steuer- und Wartungszentrum sitzen, das mit Endpunktsystemen ausgestattet ist, mit denen das Fahrzeug ferngesteuert werden kann. Ein solches System kann eingesetzt werden, um Fälle zu entschärfen, in denen das autonome Fahrzeug umkippt oder unbeweglich bleibt, weil es nicht in der Lage ist, ein Manöver durchzuführen, weil es keine verwertbaren Informationen über sich selbst oder seine Umgebung hat. Remote-Valet-Systeme können auch mit Funktionen ausgestattet sein, um Informationen vom autonomen System zu empfangen (z. B. um einen Überblick über die vom Fahrzeug befahrene Fahrbahn zu erhalten, Informationen über den Systemstatus des Fahrzeugs, den Insassenstatus des Fahrzeugs usw.), können aber dennoch unabhängig vom autonomen Fahrsystem des Fahrzeugs funktionieren. Eine solche Unabhängigkeit kann es dem Remote-Valet-Service ermöglichen, selbst bei vollständigem oder erheblichem Sensorausfall am autonomen Fahrzeug zu funktionieren, neben anderen Anwendungsbeispielen, Vorteilen und Implementierungen.
• Wie beispielsweise im vereinfachten Blockdiagramm 1500 von 15 kann ein autonomes Fahrzeug 105 eine Vielzahl von Sensoren (z. B. 920, 925, 930, etc.) und eine autonome Fahrlogik umfassen, die es dem autonomen Fahrzeug ermöglicht, in verschiedenen Umgebungen selbständig zu fahren. Wie oben eingeführt, kann in einigen Fällen durch das autonome Fahrzeug (oder auf Anfrage eines Insassen im autonomen Fahrzeug) festgestellt werden, dass das autonome Fahrsystem des Fahrzeugs 105 nicht in der Lage ist, einen Teil einer Route in einem Pfadplan zuverlässig, wünschenswert oder sicher zu navigieren. Das autonome Fahrzeug 105 kann über Kommunikationsfähigkeiten verfügen, um mit einem oder mehreren Netzwerken (z. B. 155) zu kommunizieren und den Datenaustausch zwischen dem Fahrzeug 105 und einem oder mehreren Rechensystemen zu ermöglichen, die einen Remote-Valet-Service 1505 implementieren. Der Remote-Valet-Service 1505 kann mehrere Benutzerendgeräte bereitstellen, die es den Benutzern des virtuellen Fahrers ermöglichen, die Bedingungen rund um das Fahrzeug 105 zu beobachten, und zwar auf der Grundlage von Sensordaten (z. B. Kameraansichten oder andere Sensorinformationen), die von Sensoren (z. B. 920, 925, 930 usw.) am Fahrzeug oder von Sensoren (z. B. 175) an anderen Geräten (z. B. straßenseitige Systeme (z. B. 130), luft- oder bodengestützte Drohnen (z. B. 180) und sogar Sensoren von anderen benachbarten Fahrzeugen) bereitgestellt werden. Der virtuelle Fahrer kann dann Eingaben am Remote-Valet-Terminal machen, um zu bewirken, dass entsprechende Daten mit niedriger Latenz und hoher Priorität (über das Netzwerk 155) an das Fahrzeug 105 übermittelt werden, um die Lenkung, die Beschleunigung und das Bremsen des Fahrzeugs 105 zu steuern.
• In einigen Fällen kann das Fahrzeug 105 automatisch den Eingriff und die Übergabe der Kontrolle an einen Remote-Valet-Service 1505 anfordern. In einigen Fällen kann diese Anforderung reaktiv sein (z. B. ansprechend auf ein Überziehereignis, einen Sensorausfall oder einen Notfall), während in anderen Fällen die Anforderung gesendet werden kann, um den Remote-Valet-Service 1505 präventiv zu veranlassen, die Kontrolle über das Fahrzeug zu übernehmen (basierend auf einer Vorhersage, dass ein Überziehereignis oder eine andere Schwierigkeit angesichts der vorausliegenden Bedingungen auf einer Route wahrscheinlich ist. Das Fahrzeug 105 kann Sensordaten von seinen eigenen Sensoren (z. B. 920, 925, 930 usw.) sowie Daten von anderen Sensoren und Geräten (z. B. 130, 180 usw.) sowie Backend-Dienste zur Unterstützung des autonomen Fahrens (z. B. Cloud-basierte Dienste 150) nutzen, um unter Verwendung eines oder mehrerer maschineller Lernmodelle zu bestimmen, dass die Bedingungen so sind, dass die Kontrolle an einen Remote-Valet-Service 1505 übergeben werden sollte.
• In manchen Fällen gibt es mehrere Remote-Valet-Services, die von mehreren verschiedenen autonomen Fahrzeugen genutzt werden können. Tatsächlich können mehrere autonome Fahrzeuge gleichzeitig mit einem einzigen Remote-Valet-Service verbunden sein und von diesem gesteuert werden (z. B. mit verschiedenen ferngesteuerten Fahrern, die jedes einzelne Fahrzeug steuern). In einigen Fällen kann es vorkommen, dass ein Remote-Valet-Service eine höhere Verfügbarkeit als ein anderer anbietet. In einigen Fällen können die Remote-Valet-Service-Qualitätsbewertungen beibehalten werden. In anderen Fällen können Informationen über die Verbindungsqualität und -geschwindigkeit aufrechterhalten werden, um die Konnektivitätsbedingungen jedes einzelnen von mehreren verschiedenen Remote-Valet-Services in Echtzeit zu ermitteln. Dementsprechend kann ein autonomes Fahrzeug (z. B. 105) nicht nur erkennen, dass eine Fernübergabe erforderlich oder wahrscheinlich ist, sondern auch derartige Eingaben berücksichtigen, um zu bestimmen, welche der potenziell vielen verfügbaren alternativen Remote-Valet-Services genutzt und angefordert werden können. In einigen Fällen ist die Auswahl einfach, z. B. wenn das Fahrzeug mit einem bestimmten Remote-Valet-Service verbunden ist (z. B. durch ein aktives Abonnement für Remote-Valet-Services eines bestimmten Anbieters, wobei der Remote-Valet-Service u. a. mit dem Hersteller des Fahrzeugs oder seinem autonomen Fahrsystem verbunden ist).
• Darüber hinaus können Remote-Valet-Services ihre Dienste auch auf einzelne autonome Fahrzeuge (z. B. 105) und deren Besitzer und Insassen zuschneiden, und zwar auf der Grundlage verschiedener Attribute, die vom Remote-Valet-Service erkannt werden (z. B. anhand von Informationen, die in der Anfrage zur Übergabe umfassen sind, Informationen, die aus Sensordaten gewonnen werden, die in Verbindung mit der Übergabe oder Fernsteuerung empfangen werden, usw.). So können z. B. maßgeschneiderte Benutzerschnittstellen für die Fahrunterstützung und die Steuerung bereitgestellt und einem virtuellen Fahrer des Remote-Valet-Service auf der Grundlage der Marke und des Modells des zu steuernden Fahrzeugs, der Version und der Implementierung des autonomen Fahrsystems des Fahrzeugs, der nach wie vor funktionsfähigen und zuverlässigen Sensoren des Fahrzeugs, der spezifischen Bedingungen, die die Übergabe ausgelöst haben (z. B. mit spezialisierten Fernfahrern, die zur Unterstützung bei der Fehlersuche und der Navigation des Fahrzeugs aus schwierigen Kurven angefordert werden), und anderen Beispielen präsentiert werden.
• In einigen Implementierungen können Remote-Valet-Services durch eine Regierungsbehörde als öffentlicher Dienst bereitgestellt werden. In anderen Fällen können Remote-Valet-Services als privatwirtschaftliche Unternehmungen angeboten werden. Dementsprechend können in Verbindung mit einem Remote-Valet-Service, der in Verbindung mit der Fahrt eines bestimmten Fahrzeugs (z. B. 105) erbracht wird, automatisch Metriken gesammelt und entsprechende Daten erzeugt werden (z. B. durch Sensoren oder Monitore am Fahrzeug (z. B. 105) oder am Remote-Valet-System 1505), um den erbrachten Remote-Valet-Service zu beschreiben. Solche Metriken und Daten können Merkmale des Remote-Valet-Service beschreiben wie die Schwere der Bedingungen, die den Remote-Valet-Service ausgelöst haben (z. B. höhere Gebühren für den Remote-Valet-Service bei schwierigeren Problemen), die unter der Kontrolle des Remote-Valet-Service zurückgelegte Kilometerzahl, die Zeit unter der Kontrolle des Remote-Valet-Service, die besonderen virtuellen Fahrer und Werkzeuge, die zur Erleichterung des Remote-Valet-Service verwendet werden, die Quelle und Menge der vom Remote-Valet-Service verwendeten Fremddaten (z. B. die Menge der Daten, die von Quellen (z. B. 175, 180) außerhalb der Sensoren (z. B. 920, 935, 930) angefordert und gesammelt werden), neben anderen Messgrößen, die berücksichtigt und verwendet werden können, um die Gebühren zu bestimmen, die der ferngesteuerte virtuelle Service für seine Dienste berechnet. In einigen Fällen können die Gebühren vom Eigentümer des Fahrzeugs, dem Fahrzeughersteller, einem Anbieter von Fahrzeuggarantien, dem Anbieter des autonomen Fahrsystems des Fahrzeugs usw. gezahlt oder zwischen diesen aufgeteilt werden. In einigen Fällen kann die Zuständigkeit für die Gebühren für den Remote-Valet-Service automatisch anhand von Daten bestimmt werden, die in Verbindung mit der Übergabeanforderung generiert werden, um zu ermitteln, welche Partei(en) für welche Beträge der Gebühren für den Remote-Valet-Service verantwortlich ist/sind, neben anderen beispielhaften Implementierungen.
• Daten, die in Verbindung mit einer Übergabeanforderung an einen Remote-Valet-Service generiert werden, sowie Daten, die zur Aufzeichnung eines Remote-Valet-Service generiert werden, der einem Fahrzeug während einer bestimmten Fahrt zur Verfügung gestellt wird, können auf Systemen (z. B. 1510) des Remote-Valet-Service (z. B. 1505) oder in Cloud-basierten Diensten (z. B. 150) gesammelt und verwaltet werden, die die Ergebnisse von Remote-Valet-Services zusammenfassen und auswerten können, um sowohl die Bereitstellung künftiger Remote-Valet-Services als auch die Autonomes-Fahren zu verbessern, auf die sich die Fahrzeuge verlassen, um selbst zu fahren und Remote-Valet-Services anzufordern, neben anderen Anwendungsbeispielen.
• Bezug nehmend nun auf 16 ist ein vereinfachtes Blockdiagramm 1600 dargestellt, das die Kommunikation zwischen den Systemen bei der Erbringung eines beispielhaften Remote-Valet-Service veranschaulicht. So kann beispielsweise eine Übergabeanforderung 1610 von einem Fahrzeug (105) (z. B. einem Remote-Valet-Support-Block (z. B. 1605) seines autonomen Fahrsystems) über ein Netzwerk an ein Rechensystem gesendet werden, das Remote-Valet-Services (die über ein oder mehrere Remote-Valet-Service-Systeme (z. B. 1505) bereitgestellt werden) anbietet oder vermittelt. In anderen Fällen kann ein System eines vertrauenswürdigen Dritten (z. B. außerhalb des autonomen Fahrzeugs 105) feststellen (z. B. durch ein Ensemble von Sensordaten verschiedener Geräte, die den Verkehr mit dem Fahrzeug überwachen), dass das Fahrzeug 105 Hilfe benötigt. In einigen Fällen kann ein Insasse im Fahrzeug veranlassen, dass der Remote-Valet-Service (z. B. über eine Smartphone-App) über einen Drittanbieterdienst (z. B. einen cloudbasierten Dienst 150) ausgelöst wird, der die Übergabeanforderung (z. B. 1605') im Namen des Fahrzeugs 105 senden kann, neben anderen Beispielimplementierungen. Zwischen dem Fahrzeug 105 und dem Remote-Valet-System 1505 kann ein sicherer Kommunikationskanal 1615 mit hoher Priorität eingerichtet werden, um die Bereitstellung des Remote-Valet-Service zu ermöglichen. So können beispielsweise Sensordaten (z. B. Kameradaten, LIDAR-Daten usw.), die von den Sensoren des Fahrzeugs 105 erfasst werden, gesendet werden, um einen nahezu in Echtzeit erfolgenden Überblick über die Position und den Status des Fahrzeugs sowie über die Umgebung zu erhalten. In einigen Fällen können die Daten auch Daten von internen Sensoren des Fahrzeugs 105 umfassen (z. B. um einen Blick auf die Insassen des Fahrzeugs zu ermöglichen und/oder um die Live-Kommunikation zwischen den Fahrgästen und dem virtuellen Fahrer des Remote-Valets zu erleichtern, neben anderen Anwendungsbeispielen). Der virtuelle Fahrer des Remote-Valets kann auf die empfangenen Informationen reagieren, die den Live-Zustand des Fahrzeugs 105 beschreiben, und mithilfe von Steuerelementen an seinem Terminal Fahranweisungsdaten erzeugen, die über den Kanal 1615 an das Fahrzeug gesendet werden, um den Fahrbetrieb des Fahrzeugs 105 fernzusteuern. Der Remote-Valet-Service kann auch zusätzliche Daten (z. B. zusätzlich zu den vom Fahrzeug 105 empfangenen) von externen Quellen erhalten, z. B. von Straßenrandeinheiten, anderen Fahrzeugen, Drohnen und anderen Sensorgeräten. Diese Informationen können über Kanäle mit hoher Priorität (z. B. 1620) bereitgestellt werden, die durch ein oder mehrere Backend-Systeme (z. B. 150) unterstützt werden. In einigen Implementierungen kann das Remote-Valet-Service-System 1505 anhand des Standorts des Fahrzeugs 105 Sätze von Sensoren bestimmen (die sich dynamisch ändern können, wenn sich das Fahrzeug unter der Kontrolle des Fahrers des Remote-Valet-Systems entlang eines Weges bewegt), mit denen das entfernte Parkservice-System einen weiteren sicheren Kanal (z. B. 1620) einrichten und Live-Daten erhalten kann, die die Szene um das vom Remote-Valet-System gesteuerte Fahrzeug beschreiben. Dementsprechend kann der Remote-Valet-Service in einigen Implementierungen entweder Sensordaten von Sensoren am oder außerhalb des zu kontrollierenden Fahrzeugs 105 oder beide verwenden.
• Wie bereits erwähnt, kann ein autonomes Fahrzeug in einigen Fällen erkennen, wann es einen Remote-Valet-Service um Hilfe bitten sollte. In einigen Fällen kann diese Bestimmung durch einen oder mehrere Backend-Dienste (z. B. 150) unterstützt werden. In einigen Implementierungen kann das Fahrzeug solchen Diensten 150 (oder anderen Cloud-basierten Systemen, Repositorien und Diensten) Daten zur Verfügung stellen, die die Bedingungen beschreiben, die die Übergabeanforderung (z. B. 1610) ausgelöst haben. Das Fahrzeug kann darüber hinaus (nach oder während des Dienstes) einen Bericht erstellen, in dem die Leistung des Remote-Valet-Systems beschrieben wird (z. B. Beschreibung der vom Remote-Valet durchgeführten Manöver oder Wege, Beschreibung der Zufriedenheit der Fahrgäste mit dem Dienst usw.). Solche Berichtsdaten (z. B. 1630) können später verwendet werden, um Modelle für maschinelles Lernen zu trainieren und die vom Backend- oder Cloud-basierten System (z. B. 150) bereitgestellten Dienste anderweitig zu verbessern. Erkenntnisse und verbesserte Modelle können vom System 150 abgeleitet und dann mit dem autonomen Fahrsystem des Fahrzeugs (sowie seiner Remote-Valet-Unterstützungslogik 1605) ausgetauscht werden. In einigen Fällen kann das autonome Fahrzeug Informationen aufzeichnen, die die Manöver und Reaktionen des Remote-Valets beschreiben, und diese zum weiteren Trainieren und Verbessern von Modellen verwenden, die in seinen eigenen Maschinelles-Lernen-Modellen für autonomes Fahren verwendet werden. In ähnlicher Weise können Berichtsdaten (z. B. über 1620) vom Remote-Valet-System 1505 an Cloud-basierte Dienste oder an das Fahrzeug zur Verwendung bei der Verbesserung der autonomen Fahrlogik des Fahrzeugs (und anderer Fahrzeuge) und bei Übergabeanfragen, neben anderen Beispielen, wie hier beschrieben, bereitgestellt werden.
• Zur Veranschaulichung: Ein autonomes Fahrzeug (z. B. 105) kann autonom feststellen (oder auf der Grundlage von Rückmeldungen von Fahrgästen oder von einem Sicherheitsbeauftragten empfangenen oder gemeldeten Rückmeldungen usw.), dass das autonome Fahrsystem des Fahrzeugs nicht in der Lage ist, eine bestimmte Situation zu bewältigen, während es eine bestimmte Strecke entlangfährt. Dementsprechend kann ein Remote-Valet-Service ausgelöst werden. In einigen Fällen kann der remote-Valet-Service bereits vor einem bevorstehenden Straßenabschnitt kontaktiert werden, wenn dieser als problematisch eingestuft wird. In einigen Implementierungen kann eine Übergabeanforderung von einem Logikblock ausgeführt werden, der die Logik des autonomen Fahrsystems ergänzt, das eine Pfadplanungsphase in einer Pipeline für autonomes Fahren implementiert (wie im Beispiel von 5 erörtert). In einigen Fällen kann ein Kommunikationsmodul des autonomen Fahrzeugs, wie z. B. eine Telematik-Steuereinheit (TCU), zur Verbindung mit dem Remote-Valet-Service verwendet werden, sobald eine Übergabeanforderung an ein Remote-Valet-System erfolgt ist. In einigen Implementierungen kann die Kommunikation mit dem Remote-Valet-Service als Kommunikation mit einem Notdienst (ähnlich einem Notruf) eingerichtet werden, der während der Herstellungsphase der TCU festgelegt wird. In dieser Übergabeanforderung kann der Standort des Fahrzeugs angegeben werden. In einigen Implementierungen können die Übergabeanforderung und der Remote-Valet-Service in einem vom OEM bereitgestellten Call-/Control-Center implementiert werden, in dem der virtuelle Fahrer, der den „Remote-Valet“ (ferngesteuerter Valet-Service) bedient, tätig wird. In einigen Implementierungen kann der Remote-Valet ansprechend auf die Herstellung einer Verbindung zwischen dem Fahrzeug und dem Remote-Valet eine Aufforderung an das Fahrzeug senden, Videos von all seinen Kameras zu streamen, um die Umgebung in Echtzeit zu betrachten. Andere Sensoren (z. B. Straßenkameras und straßenseitige Sensoren), die sich am selben Ort befinden, können ebenfalls identifiziert werden, um Daten (z. B. zusätzliche Videostreams) zur Ergänzung der vom Fahrzeug empfangenen Informationen zu liefern. Auf der Grundlage der Ansicht der Fahrzeugumgebung und der Straßenbedingungen, die dem Remote-Valet durch die gestreamten Videos von Fahrzeugen (und möglicherweise auch von zusätzlichen Quellen (z. B. Straßenkameras)) nahezu in Echtzeit angezeigt werden, steuert der Remote-Valet das Fahrzeug (ähnlich wie bei immersiven Videospielen, bei denen der Spieler die Ansicht des Fahrzeugs sieht und es mit einem Lenkrad, einem Handheld-Controller usw. steuert), um das Fahrzeug zu einem Ziel zu fahren. In einigen Fällen kann das Ziel einem nächsten Abschnitt einer Route entsprechen, der als weniger problematisch eingestuft wird. An diesem Punkt kann die Kontrolle an das autonome Fahrsystem zurückgegeben werden, um das Fahren des Fahrzeugs in einem standardmäßigen autonomen Fahrmodus zu steuern. In anderen Fällen kann der Remote-Valet-Service das Fahrzeug auf der Grundlage der Umstände und der erkannten Merkmale der ursprünglichen Übergabeanforderung an ein bestimmtes Ziel leiten, das für die Behebung der am Fahrzeug erkannten Probleme geeignet ist, wie z. B. das Fahren eines Fahrzeugs mit defekten Sensoren oder autonomem Fahrsystem zum nächsten Servicecenter oder das Fahren eines Fahrzeugs mit kranken oder verletzten Insassen zu einem Krankenhaus, neben anderen Beispielen und Anwendungsfällen.
• Wie bereits erwähnt, kann das autonome Fahrsystem eines Fahrzeugs in einigen Fällen auf Daten zugreifen, die von anderen Fernsensorgeräten (z. B. anderen autonomen Fahrzeugen, Drohnen, Straßenrandeinheiten, Wetterwächtern usw.) gesammelt wurden, um vorausschauend die wahrscheinlichen Bedingungen auf bevorstehenden Straßenabschnitten zu ermitteln. In einigen Fällen kann eine Vielzahl von Sensoren Daten an Cloud-basierte Systeme liefern, die diese Datensammlung zusammenfassen und verarbeiten, um mehreren autonomen Fahrzeugen Informationen über Straßenabschnitte und die Bedingungen auf diesen Strecken zu liefern. Wie bereits erwähnt, können Cloud-basierte Systeme und andere Systeme in einigen Fällen Eingaben empfangen, die mit früheren Anhalte- (pullover) und Remote-Valet-Übergabe-(handover) Ereignissen in Verbindung stehen, und können gemeinsame Merkmale dieser Ereignisse erkennen. In einigen Implementierungen können maschinelle Lernmodelle aus diesen Informationen erstellt und trainiert werden, und solche maschinellen Lernmodelle können auf Straßenrandeinheiten, Cloud-basierten Unterstützungssystemen, Remote-Valet-Rechensystemen oder den bordeigenen Systemen der autonomen Fahrzeuge selbst eingesetzt und ausgeführt werden, um eine Logik für die vorausschauende Bestimmung potenzieller Remote-Valet-Übergaben bereitzustellen. So kann ein autonomes Fahrzeug anhand von Sensordaten, auf die es zugreift, im Voraus die Bereiche entlang jeder Straße ermitteln, in denen häufig angehalten wird und/oder in denen Remote-Valet-Übergaben üblich sind. In einigen Fällen kann das autonome Fahrzeug (z. B. anhand eines entsprechenden Maschinelles-Lernen-Modells) feststellen, dass die für einen bevorstehenden Straßenabschnitt gemeldeten Bedingungen die Wahrscheinlichkeit eines Anhaltens und/oder einer Remote-Valet-Übergabe nahelegen (selbst wenn an diesem bestimmten Straßenabschnitt zuvor kein Anhalten und keine Übergabe stattgefunden hat). Anhand dieser Informationen kann ein autonomes Fahrzeug präventiv Maßnahmen ergreifen, um sich auf die Übergabe an einen Fahrer im Fahrzeug oder an einen Remote-Valet vorzubereiten. In einigen Fällen kann das autonome Fahrzeug beschließen, den Routenplan zu ändern, um den problematischen Straßenabschnitt zu vermeiden (z. B. auf der Grundlage der Erkennung der Nichtverfügbarkeit von Kommunikationsressourcen, die das Remote-Valet unterstützen können, der gemeldeten mangelnden Verfügbarkeit eines bevorzugten Valet-Service, einer Benutzerpräferenz, die verlangt, dass der Remote-Valet nach Möglichkeit vermieden wird, usw.). In einigen Ausführungen können die Anzeigen des autonomen Fahrzeugs den Fahrzeuginsassen Warnungen oder Anweisungen zu einem bevorstehenden, vorhergesagten Problem und der Möglichkeit eines Anhaltens und/oder einer Remote-Valet-Übergabe anzeigen. In einigen Fällen können diese Informationen auf einem interaktiven Display angezeigt werden, über das ein Insasse seine Präferenz für die Abwicklung des bevorstehenden Fahrtabschnitts entweder durch eine Übergabe an den Insassen, eine Übergabe an einen Remote-Valet, die Auswahl einer alternativen Route oder ein Anhalte-Ereignis angeben kann. In noch anderen Implementierungen kann cloudbasiertes Wissen über problematische Straßenabschnitte an Straßenschilder oder fahrzeuginterne Straßenkarten übermittelt werden, um Fahrer und andere autonome Fahrzeuge auf die problematischen Abschnitte hinzuweisen, um nur einige Beispiele zu nennen.
• Bezug nehmend nun auf 17 wird ein vereinfachtes Blockdiagramm 1700 gezeigt, das die kooperative Übermittlung von Informationen über das Risiko eines Überschlags und Warnungen über den Straßenzustand veranschaulicht, die weiter genutzt werden können, um Remote-Valet-Services einzurichten, die autonome Fahrzeuge in solchen gefährlichen und schwierigen Szenarien unterstützen. So können beispielsweise Informationen über eine Anhalteaufforderung und/oder ein Remote-Valet-Ereignis von den betroffenen Fahrzeugen und/oder umliegenden Sensorgeräten gesammelt werden, und diese Informationen können gemeinsam genutzt werden, um autonome Fahrsysteme zu verbessern. Bei dem Beispiel von 17 kann das betroffene Fahrzeug (z. B. 105) bei einem Überholvorgang oder einer Übergabe die im Zusammenhang mit diesem Ereignis erzeugten und gesammelten Daten zusammenstellen und diese Informationen mit Cloud-basierten Unterstützungssystemen (z. B. 150) und/oder Edge-Vorrichtungen, wie z. B. einer Straßenrandeinheit oder einem Edge-Computer (oder Edge-Cloud)-Server (z. B. 140), austauschen.
• 18 zeigt ein vereinfachtes Blockdiagramm 1800, das die Merkmale eines beispielhaften autonomen Fahrzeugs 105 veranschaulicht, das verschiedene Fahrzeugsensoren (z. B. 920, 925), einen auf künstlicher Intelligenz/Maschinenlernen basierenden Autonomes-Fahren-Stack 515 und eine Logik (z. B. 1805) zur Unterstützung des Auslösens und Erstellens von Übergabeanforderungen an Systeme, die in der Lage sind, einen Remote-Valet bereitzustellen, umfassen kann. Es kann eine Telematik-Steuereinheit (TCU) 1810 vorgesehen werden, über die die Übergabeanforderung gesendet und die Kommunikation zwischen dem Fahrzeug 105 und einem virtuellen Fahrerterminal, das den Remote-Valet-Service anbietet, hergestellt werden kann.
• Wenn die Autonomes-Fahren-Maschine (z. B. 515) ein Anhalte-Ereignis feststellt oder die Logik zur Unterstützung des Remote-Valet (z. B. 1805) feststellt, dass eine Übergabeanforderung gesendet werden sollte, kann ein Signal an die TCU (1810) gesendet werden, um den Fahrzeugstandort und den Pull-Over-Standort an verschiedene Cloud-basierte Einheiten zu senden (oder an eine einzelne Einheit oder ein Gateway, das diese Informationen an mehrere Einheiten oder Dienste verteilt. In der Tat können viele verschiedene Dienste diese Informationen nutzen. So kann beispielsweise eine Cloud-basierte Anwendung 1715 (z. B. in Verbindung mit dem Fahrzeug-OEM) in einem Beispiel das primäre Ziel oder der primäre Empfänger dieser Informationen sein und Teile dieser Informationen an andere Empfänger weitergeben. In anderen Fällen kann das Fahrzeug 105 selbst Daten bereitstellen und an mehrere verschiedene cloudbasierte Anwendungen verteilen (z. B. eine Anwendung pro Empfänger). So kann beispielsweise eine OEM-Wartungsanwendung (z. B. 1720) Pull-Over- oder Hand-Off-Informationen nutzen und sie für Diagnosen und die Identifizierung von Eckfällen verwenden, in denen das Fahrzeug (und seine Modelle) das autonome Fahren nicht bewältigen kann. In einigen Beispielen können zu den Empfängern von Anhalte- oder ÜbergabeInformationen auch Anbieter von Kartenanwendungen (z. B. 1725, 1726) gehören, darunter Anbieter von herkömmlichen Navigationskarten, 3D-Karten, HD-Karten usw., die diese Informationen über spezielle Cloud-Apps entweder direkt vom Fahrzeug oder über den OEM erhalten können, der die Informationen direkt vom Fahrzeug empfängt. Die Kartenanbieter können die Informationen über Überholvorgänge und Übergabevorgänge für Statistiken nutzen, die dazu beitragen können, die Karten mit Informationen über Gebiete zu füllen, die für Überholvorgänge und schwierige autonome Fahrbedingungen anfällig sind, so dass diese Informationen ständig aktualisiert werden können. Darüber hinaus können HD-Karten solche Informationen als Teil der hochpräzisen Informationen pro Straßenabschnitt umfassen, die die HD-Karten liefern, neben anderen Beispielen. Gemeinden, Regierungsbehörden, Mautstraßenanbieter und andere Infrastrukturunternehmen und Behörden (z. B. 1730) können ebenfalls Empfänger von Anhalte- und Übergabeinformationen sein (z. B. direkt vom Fahrzeug 105, indirekt über eine andere Anwendung oder Einrichtung oder durch Erfassung solcher Informationen durch zugehörige straßenseitige Sensoren und straßenseitige Unterstützungseinheiten, neben anderen Beispielen). Diese Behörden können diese Informationen nutzen, um die Straßeninstandhaltung zu veranlassen, als Beweismittel für neue Straßen- und Infrastrukturprojekte, für polizeiliche Maßnahmen, für Mautgebühren, für die Aufstellung von Schildern oder Warnhinweisen und für andere Zwecke.
• Ein Anhalte- oder Übergabeereignis kann auch dazu führen, dass ein Fahrzeug 105 Informationen mit nahe gelegenen Straßenrandeinheiten, Fahrzeugen und anderen Sensorgeräten austauscht. Eine straßenseitige Einheit (z. B. 140) kann diese Informationen beispielsweise nutzen, um diese Daten mit anderen empfangenen Daten zu verarbeiten und diese Informationen oder die Ergebnisse ihrer Analyse mit anderen Fahrzeugen (z. B. 110) oder Systemen in ihrer Nähe zu teilen (z. B. über eine Straßenabschnittsanwendung 1735). So kann die straßenseitige Einheit z. B. andere Fahrzeuge vor einem drohenden Überholmanöver warnen, die Infrastruktur für die Kommunikation mit Remote-Valet-Services vorbereiten und vieles mehr. Die Straßenrandeinheiten können diese Informationen auch speichern oder übermitteln, so dass die angeschlossenen Gemeinden, Wartungsunternehmen und Behörden auf diese Informationen zugreifen können (z. B. zur dynamischen Anpassung der Zeitsteuerung von Verkehrssignalen, zur Aktualisierung der digitalen Beschilderung, zur Freigabe zusätzlicher Verkehrsspuren usw.).
• Wie oben beschrieben, können verschiedene Cloud- und Edge-basierte Rechensysteme die von verschiedenen Fahrzeugen im Laufe der Zeit gesammelten Informationen über das Anhalten und die Übergabe nutzen, um Modelle zu verbessern, die gemeinsam genutzt werden können, um Empfehlungssysteme zu verbessern (z. B. um ein Anhalten oder eine Remote-Valet-Übergabe zu empfehlen), um prädiktive oder präventive Remote-Valet-Übergaben zu ermöglichen, um Modelle für autonomes Fahren zu verbessern, um Remote-Valet-Übergaben zu verbessern, neben anderen Beispielen für Anwendungen und Vorteile.
• In einigen Implementierungen kann ein autonomer Fahrstapel ein „Erkennen, Planen, Handeln“-Modell verwenden. Beispielsweise zeigt 19 zeigt ein Beispiel für ein „sense, plan, act“- (Erfassen, Planen, Handeln) Modell 1900 zur Steuerung autonomer Fahrzeuge gemäß mindestens einer Ausführungsform. Das Modell 1900 kann in einigen Fällen auch als autonome Fahrzeugsteuerungspipeline bezeichnet werden. Im gezeigten Beispiel besteht das Erfassungs-/Wahrnehmungssystem 1902 entweder aus einem einzelnen Typ oder einer multimodalen Kombination von Sensoren (z. B. LIDAR, Radar, Kamera(s), HD-Karte, wie gezeigt, oder anderen Sensortypen), die eine digitale Konstruktion (über Sensorfusion) der Umgebung ermöglichen, einschließlich sich bewegender und sich nicht bewegender Agenten und ihrer aktuellen Position in Bezug auf das Erfassungselement. Auf diese Weise kann ein autonomes Fahrzeug eine interne Darstellung seiner Umgebung erstellen und sich selbst in diese Darstellung einordnen (was als Umgebungsmodell bezeichnet werden kann). Das Umgebungsmodell kann in einigen Fällen drei Arten von Komponenten umfassen: statische Informationen über die Umgebung (die mit einer HD-Karte korreliert sein können), dynamische Informationen über die Umgebung (z. B. sich bewegende Objekte auf der Straße, die durch aktuelle Positionsinformationen und Geschwindigkeitsvektoren dargestellt werden können) und Ego-Lokalisierungsinformationen, die angeben, wo das autonome Fahrzeug in das Modell passt.
• Das Umgebungsmodell kann dann in ein Planungssystem 1904 eines autonomen Fahrsystems im Fahrzeug eingespeist werden, das die aktiv aktualisierten Umgebungsinformationen verwendet und ansprechend auf das vorhergesagte Verhalten dieser Umgebungsbedingungen einen Aktionsplan erstellt (der z. B. Routeninformationen, Verhaltensinformationen, Vorhersageinformationen und Trajektorieninformationen umfassen kann). Der Plan wird dann einem Betätigungssystem 1906 zur Verfügung gestellt, das das Fahrzeug dazu bringen kann, nach diesem Plan zu handeln (z. B. durch Betätigung des Gas-, Brems- und Lenksystems des autonomen Fahrzeugs).
• In einem oder mehreren Aspekten existiert ein System zur Modellierung sozialer Normen (1908) zwischen dem Erfassungs- und dem Planungssystem und fungiert als paralleler Input für das Planungssystem. Das vorgeschlagene System zur Modellierung sozialer Normen würde dazu dienen, ein adaptives semantisches Verständnis der Fahrzeugumgebung zu schaffen, mit dem Ziel, das Verhalten des Fahrzeugs an die an einem bestimmten Ort beobachtete soziale Norm anzupassen. Im gezeigten Beispiel empfängt das System 1908 zur Modellierung sozialer Normen beispielsweise das vom Wahrnehmungssystem 1902 erzeugte Umgebungsmodell zusammen mit einem vom Planungssystem 1904 verwendeten Verhaltensmodell und verwendet diese Informationen als Eingaben zur Bestimmung eines Modells sozialer Normen, das dem Planungssystem 1904 zur Berücksichtigung vorgelegt werden kann.
• Das System 1908 zur Modellierung sozialer Normen kann in der Lage sein, sensorische Informationen von den Erfassungskomponenten des Fahrzeugs aufzunehmen und ortsbezogene Verhaltensmodelle sozialer Fahrnormen zu formulieren. Diese Informationen können nützlich sein, um zaghaftes autonomes Fahrzeugverhalten anzugehen, da sie dazu genutzt werden können, menschliches Fahrerverhalten zu quantifizieren und so zu interpretieren, dass autonome Fahrzeuge weniger risikoscheu gegenüber dem sind, was menschliche Fahrer als normale Straßenverkehrsteilnahme ansehen würden. Aktuelle Modelle können zum Beispiel einen kalkulierten Ansatz verfolgen und so das Risiko einer Kollision messen, wenn eine bestimmte Aktion durchgeführt wird; dieser Ansatz allein kann jedoch ein autonomes Fahrzeug hilflos machen, wenn es auf eine Autobahn auffährt, wo aggressives Fahren die soziale Norm ist.
• 20 zeigt ein vereinfachtes Modell des Verständnisses sozialer Normen 2000 in Übereinstimmung mit mindestens einer Ausführungsform. Das Modell zum Verstehen sozialer Normen kann von einem System zur Modellierung sozialer Normen in einer autonomen Fahrzeugsteuerungspipeline implementiert werden, wie z. B. dem System zur Modellierung sozialer Normen 1908 der autonomen Fahrzeugsteuerungspipeline 1900.
• In dem gezeigten Beispiel lädt das System zur Modellierung sozialer Normen zunächst ein Umgebungsmodell und ein Verhaltensmodell für das autonome Fahrzeug im Jahr 2002. Das Umgebungsmodell kann ein Umgebungsmodell sein, das von einem Wahrnehmungssystem einer autonomen Fahrzeugsteuerungspipeline an das System zur Modellierung sozialer Normen weitergeleitet wird (z. B. wie in 19) umfassen. Die Verhaltensrichtlinie kann aus einer Planungsphase einer autonomen Fahrzeugsteuerungspipeline empfangen werden (z. B. wie in 19) umfassen. In einigen Fällen kann eine Standard-Verhaltensrichtlinie, die in der Planungsphase verwendet wurde, gesendet werden. In anderen Fällen kann die Verhaltenspolitik auf dem Umgebungsmodell basieren, das das Wahrnehmungssystem an das Planungssystem weitergibt.
• Im Jahr 2004 stellt das System zur Modellierung sozialer Normen fest, ob das vom Umgebungsmodell dargestellte Szenario auf ein bestehendes Profil sozialer Normen abgebildet wird. Ist dies der Fall, wird das vorhandene Profil der sozialen Norm als Referenz geladen. Wenn nicht, wird ein neues Profil der sozialen Norm erstellt. Das neu erstellte Profil einer sozialen Norm kann Standardbedingungen oder andere Informationen zur Beschreibung einer sozialen Norm umfassen. Jedes Profil der sozialen Norm kann mit einem bestimmten Szenario/einer bestimmten Umgebung verknüpft sein (z. B. Anzahl der Fahrzeuge in der Umgebung des autonomen Fahrzeugs, Tageszeit, Geschwindigkeit der Fahrzeuge in der Umgebung, Wetterbedingungen usw.) und kann Einschränkungen (die weiter unten beschrieben werden) oder andere Informationen zur Beschreibung der sozialen Norm in Bezug auf eine Verhaltenspolitik umfassen. Jedes soziale Normprofil kann auch mit einem bestimmten geografischen Ort verbunden sein. So kann beispielsweise dasselbe Szenario an verschiedenen geografischen Orten präsentiert werden, aber jedes Szenario kann ein anderes entsprechendes soziales Normprofil aufweisen, weil die beobachteten Verhaltensweisen an den verschiedenen Orten sehr unterschiedlich sein können.
• Als nächstes, im Jahr 2010, beobachtet das System zur Modellierung sozialer Normen dynamische Informationen im Umweltmodell. Die dynamischen Informationen können Verhaltensinformationen über dynamische Hindernisse (z. B. andere Fahrzeuge oder Personen auf der Straße) umfassen. Das System zur Modellierung sozialer Normen ist dann parallel dazu: (1) eine Variation des beobachteten Verhaltens der dynamischen Hindernisse im Jahr 2012 bestimmt oder schätzt, und (2) eine Abweichung des beobachteten Verhaltens der dynamischen Hindernisse vom Verhalten des autonomen Fahrzeugs selbst im Jahr 2014 bestimmt oder schätzt. So kann das Modell beispielsweise 2012 feststellen, ob das beobachtete Verhalten der anderen Fahrzeuge innerhalb der aktuellen Parameter des 2002 geladenen Verhaltensmodells liegt, und kann 2014 feststellen, ob die Abweichung zwischen dem Verhalten der Fahrzeuge innerhalb der aktuellen Parameter des Verhaltensmodells liegt.
• Auf der Grundlage der ermittelten Variation und Abweichung kann das Modell zum Verständnis der sozialen Norm feststellen, ob sich die beobachtete soziale Norm gegenüber dem Profil der sozialen Norm im Jahr 2016 verändert hat. Ist dies der Fall, können die neuen Informationen (z. B. Einschränkungen wie unten beschrieben) im Profil der sozialen Norm gespeichert werden. Wenn nicht, kann das Modell feststellen, ob sich das Szenario bis 2020 geändert hat. Ist dies nicht der Fall, beobachtet das Modell weiterhin die dynamischen Informationen und trifft, wie oben beschrieben, Feststellungen zur Varianz und Abweichung des beobachteten Verhaltens. Wenn sich das Szenario ändert, führt das Modell den Prozess von Anfang an durch, beginnend mit dem Jahr 2002.
• In einigen Ausführungsformen kann das Modell zum Verständnis sozialer Normen (2000) dafür verantwortlich sein, soziale Normen als beobachtungsbasierte Einschränkungen für die Verhaltenspolitik des Ego-Fahrzeugs zu generieren. Die Generierung dieser Randbedingungen kann aus dem zeitlichen Verfolgungsverhalten im Szenario der umgebenden Fahrzeuge abgeleitet werden. Insbesondere können zwei Prozesse parallel ausgeführt werden:
• • Schätzung einer Verhaltensänderung, die einen euklidischen Abstand zur aktuellen Verhaltenspolitik/zum aktuellen Verhaltensmodell aus den Beobachtungen jedes umgebenden Fahrzeugs analysiert; und
• • Schätzung einer Abweichung, die die Reaktionen der umliegenden Fahrzeuge auf die beobachtete Fahrweise analysiert und negative Rückmeldungen (Überschreitungen) ermittelt, die als Grenzen für das Verhalten dienen.
• Das Ergebnis dieser beiden parallelen Prozesse kann verwendet werden, um die Grenzen des Verhaltens zu bestimmen, die eine soziale Norm bilden. Diese soziale Norm (z. B. die Grenzwerte) kann dann an das Planungsmodul zurückgegeben werden, um als Einschränkungen für das jeweilige Fahrszenario zu dienen. Je nach Verhaltensvariation und Abweichung, die in den parallelen Prozessen beobachtet werden, kann die daraus resultierende soziale Norm den Verhaltensplaner stärker oder schwächer einschränken und so ein natürlicheres Fahrverhalten ermöglichen. In einigen Fällen kann die Konstruktion sozialer Normen von Szenario-Merkmalen wie Straßengeometrie und Signalisierung sowie von den beobachteten Fahrzeugen in der Umgebung abhängen. Aus der Kombination von Straßenumgebung und Anzahl der Fahrzeugteilnehmer, die mit dem Ego-Fahrzeug interagieren, könnten sich unterschiedliche soziale Normen ergeben. In einigen Fällen kann das Modell Veränderungen in der sozialen Norm berücksichtigen, die mit der Zeit auftreten.
• In einer Beispielimplementierung könnte ein Szenario aus einer Straßenkartengeometrie bestehen, die Fahrspuren als Teil einer HD-Karte festlegt, und aus Fahrzeugen, die auf diesen Fahrspuren platziert sind, mit Zuständen, die durch X_i = [x_i,y_i,θ_i, ϑ_i] gekennzeichnet sind, wobei (x_i,y_i) eine Position, θ_i eine Richtung und ϑ_i eine Geschwindigkeit für jedes Fahrzeug iangeben. So kann eine Anzahl m von Fahrzeugzuständen als Menge angegeben werden (X₁...X_m). Die Trajektorien für jedes der Fahrzeuge könnten in Zeitintervallen unter Verwendung der folgenden Kostenfunktion berechnet werden: $$J_i={\displaystyle \sum _{t=1}^{N-1}\left({\Vert X_{i,t}\Vert }^2+{\Vert \mathrm{\Delta }{u}_{i,t}\Vert }^2\right)}$$

  
• Dabei ist Δu_i die beobachtete Differenz zwischen der Fahrzeugkontrolle und dem Verhaltensmodell. Die Anwendung der Kostenfunktion über ein definiertes Beobachtungsfenster N erzeugt die Trajektorie try_i . Einschränkungen für diese Flugbahnplanung können aus statischen Hindernissen wie y_i,kmin < y_i,k < y_i,kmax, dynamischen Hindernissen (Sicherheitseinschränkungen) (x_i,k,) ∈ S_i (x, y) oder der Machbarkeit eines bestimmten Ausgangs u_i,kabgeleitet werden. Die Interaktion zwischen den einzelnen Fahrzeugen kann als ${\displaystyle {\sum }_{i=1}^m{J}_i}$

  

  beobachtet werden, und aus den beobachteten Interaktionen lassen sich Änderungen der Randbedingungen ableiten (z. B. durch Minimierung der Kostenfunktion J_i). Die abgeleiteten Randbedingungen können als „soziale Norm“ für das Szenario betrachtet werden und können in einigen Ausführungsformen an das Planungssystem weitergegeben werden, damit sie direkt auf die Ego-Kostenfunktion für die Flugbahnplanung angewendet werden. Andere Implementierungen könnten andere Kostenfunktionen zur Ableitung von Beschränkungen verwenden. In einigen Fällen können beispielsweise neuronale Netze zum Erlernen der sozialen Normen oder ein teilweise beobachtbarer Markov-Entscheidungsprozess eingesetzt werden.
• Wenn die Fahrkultur/Sozialnorm bekannt ist (z. B. für aggressives Fahren), können die Planungssysteme so angepasst werden, dass sie ihre Verhandlungstaktik ändern, um aggressiver/weniger aggressiv und risikofreudig zu sein, da die Risikominderung aus dem Wissen um das von anderen Verkehrsteilnehmern erwartete Risiko resultiert. Durch die Beobachtung sozialer Normen kann außerdem das Problem gelöst werden, dass autonome Fahrsysteme für bestimmte geografische Kontexte konzipiert werden, da Verhaltensmodelle für mehrere geografische Standorte entworfen und im Laufe der Zeit verbessert werden können. Dieser Ansatz bildet auch die Grundlage für die Schaffung und Verbreitung sozialer Antriebsnormen. Wenn autonome Fahrzeuge die Mehrheit der Verkehrsteilnehmer ausmachen, kann dieses adaptive semantische System zum Verständnis von Verhaltensmustern gemeinsame Verhaltensmodelle ermöglichen, die allen Verkehrsteilnehmern die Verhandlung auf der Straße vorschreiben können.
• Die Vorgänge, gezeigt in den Beispielprozessen in 19, 20, können von verschiedenen Aspekten oder Komponenten des bordeigenen Rechnersystems eines autonomen Fahrzeugs durchgeführt werden. Die Beispielprozesse können zusätzliche oder andere Vorgänge umfassen, und die Vorgänge können in der gezeigten oder in einer anderen Reihenfolge durchgeführt werden. In manchen Fällen können eine oder mehrere der in 19, 20 gezeigten Operationen als Prozesse implementiert werden, die mehrere Operationen, Unterprozesse oder andere Arten von Routinen umfassen. In einigen Fällen können Vorgänge kombiniert, in anderer Reihenfolge, parallel, iterativ oder auf andere Weise wiederholt oder durchgeführt werden.
• Fahrzeug-zu-Fahrzeug-Kommunikation (V2V) kann von autonomen Fahrzeugen zur Risikominderung genutzt werden. Diese Kommunikation kann zum Beispiel dazu verwendet werden, Ereignisse wie Unfälle oder die Position von Hindernissen auf der Straße zu melden. In anderen Anwendungsfällen kann die Fernerkundung für kollaborative Aufgaben wie die Kartierung oder die Zusammenarbeit bei Manövern eingesetzt werden. Bei der zweiten Art von kollaborativen Aufgaben sind die meisten Konzepte auf sehr spezifische Verkehrssituationen oder Anwendungen wie die kooperative adaptive Geschwindigkeitsregelung (C-ACC; Cooperative Adaptive Cruise Control) zur Koordinierung von Platooning beschränkt. C-ACC beispielsweise nutzt die Koordination in Längsrichtung, um einen minimalen Zeitabstand zum vorausfahrenden Fahrzeug einzuhalten und den Verkehrsfluss und die Kraftstoffeffizienz zu verbessern. Andere koordinierte Manöver können in einigen Systemen unterstützt werden, z. B. Spurwechsel und Zusammenführung durch eine Kombination aus Längs- und Querkoordination, um sichere Lücken in Fahrzeugkorridoren und angrenzenden Fahrspuren zu schaffen. Die koordinierte Kontrolle in Längs- und Querrichtung kann jedoch an Kreuzungen, an denen die Koordination mehrerer Fahrzeuge und die Anwendung von Vorfahrtsregeln erforderlich ist, um eine Zusammenarbeit zu erreichen, nicht ausreichend sein. Bestehende Lösungen sind für bestimmte Fahrszenarien nützlich, aber es fehlen Mechanismen für die Interoperabilität. Außerdem wird bei den meisten dieser Lösungen davon ausgegangen, dass alle Fahrzeuge miteinander verbunden und automatisiert sind und dass sie nach derselben Strategie gesteuert werden. In diesem Sinne gehen maschinelle Lernmodelle, die in einigen autonomen Fahrsystemen verwendet werden, von einem generischen Fahrzeugverhalten aus und passen die autonomen Fahrentscheidungen auf der Grundlage dieser Annahmen an. Standardansätze für autonome Fahrsysteme können auch Modelle verwenden, die von einem Ideal ausgehen (z. B. dass andere Autos autonom sind, dass menschliche Fahrer sich an die Gesetze halten usw.), aber solche Lösungen sind in gemischten Verkehrsszenarien nicht anwendbar, in denen menschliche Fahrer und ihr Verhalten nicht kontrolliert werden können und sich möglicherweise nicht an Regeln oder Ziele der Verkehrskooperation halten.
• In einigen Implementierungen kann ein fahrzeuginternes autonomes Fahrsystem eines bestimmten Fahrzeugs so ausgebildet sein, dass es eine Manöverkoordination in vollautomatischen oder gemischten Verkehrsszenarien durchführt und gemeinsame Verhaltensmodelle nutzt, die über V2X-Kommunikationstechnologien (einschließlich Fahrzeug-zu-Fahrzeug (V2V) oder Infrastruktur-zu-Fahrzeug (I2V) usw.) zur Unterstützung der autonomen Fahrentscheidungs- und Pfadplanungsfunktionen des jeweiligen Fahrzeugs übermittelt werden. Beispielsweise, wie in 21 gezeigt, werden Diagramme 2100a-c gezeigt, die Aspekte der Koordination zwischen Fahrzeugen in einer Umgebung veranschaulichen, in der zumindest ein Teil der Fahrzeuge teil- oder vollautonom ist. Verhaltensmodelle können zum Beispiel mit Hilfe von Fahrregeln bei automatisierten Fahrzeugen oder über Datenlernprozesse, die naturalistisches Fahrverhalten ableiten, erstellt werden. Wie bereits erwähnt, können beispielsweise Verhaltensmodelle bereitgestellt werden, die sich kontinuierlich weiterentwickeln und verbessern lassen, indem sie auf der Grundlage von Beobachtungen aus der Umwelt angepasst werden, um die im Modell definierten erlernten Einschränkungen zu ändern. Bei von Menschen gesteuerten Fahrzeugen, für die es möglicherweise keine Modelle gibt, können im Laufe der Zeit mithilfe künstlicher neuronaler Netze ungefähre Verhaltensmodelle erstellt werden. Solche neuronalen Netzmodelle können auf der Grundlage der Eingaben, die dem Modell zugeführt werden, kontinuierlich lernen und verfeinert werden. Zu den Eingabeparametern solcher Modelle können beispielsweise Informationen über die Straßenumgebung (z. B. Kartendaten), Positions- und Geschwindigkeitsvektoren der umgebenden Fahrzeuge, die Ausgangsposition und der Geschwindigkeitsvektor des Ego-Fahrzeugs, Informationen zur Fahreridentifikation (z. B. demografische Daten menschlicher Fahrer) und andere Beispiele gehören. Wenn ein Fahrzeug sein Verhaltensmodell mit anderen Fahrzeugen teilt, kann die Version des Verhaltensmodells dementsprechend eine Version sein, die auf der Grundlage von Beobachtungen und weiteren Lernvorgängen des Fahrzeugs während des Betriebs auf der Straße verfeinert und weiter abgestimmt wurde.
• Wie in 21 gezeigt, zeigt Diagramm 2100a zwei Fahrzeuge A und B in einer Fahrumgebung. Die V2V-Kommunikation kann aktiviert werden, damit ein Fahrzeug oder beide Fahrzeuge Beobachtungen und Sensordaten mit dem anderen austauschen können. Beispielsweise kann Fahrzeug A ein Hindernis (z. B. 2105) erkennen, das auf einen Fahrbahnabschnitt auftrifft, und außerdem die Anwesenheit eines anderen Fahrzeugs (z. B. Fahrzeug B) erkennen, das sich auf demselben Fahrbahnabschnitt befindet oder in diesen einfährt. Als Reaktion darauf kann Fahrzeug A Informationen über das Hindernis 2105 übermitteln (z. B. seine Koordinaten, die Art des Hindernisses oder der Gefahr (z. B. ein Objekt, ein Unfall, ein Wetterereignis, ein Schild oder eine ausgefallene Ampel usw.), eine computergesteuerte Klassifizierung, die für das Hindernis ermittelt wurde (z. B. dass es sich bei dem Hindernis um ein Fahrrad handelt), sowie andere Informationen. Zusätzlich können die Fahrzeuge A und B, wie oben beschrieben, auch V2V- oder V2X-Kommunikation nutzen, um Verhaltensmodelle mit den anderen Fahrzeugen auszutauschen. Diese Modelle können von einem empfangenden Fahrzeug verwendet werden, um Wahrscheinlichkeiten zu bestimmen, dass benachbarte Fahrzeuge in bestimmten Situationen bestimmte Aktionen durchführen werden. Diese ermittelten Wahrscheinlichkeiten können dann als Eingaben für das fahrzeugeigene maschinelle Lernen oder andere (z. B. logikbasierte wie regelbasierte) Modelle und die autonome Fahrlogik verwendet werden, um die Entscheidungsfindung und die Pfadplanung in Gegenwart dieser benachbarten Fahrzeuge zu beeinflussen.
• 21 veranschaulicht einen Ablauf für den Austausch und die Verwendung von Verhaltensmodellen in autonomen Fahrumgebungen. Wie in Diagramm 2100a dargestellt, können beispielsweise zwei Fahrzeuge die Anwesenheit des jeweils anderen innerhalb eines Straßenabschnitts erkennen und dem anderen Fahrzeug Informationen über die aktuelle Position, Lage, Geschwindigkeit usw. des sendenden Fahrzeugs übermitteln. Soweit Verhaltensmodelle nicht bereits gemeinsam genutzt oder von dem anderen Fahrzeug erhalten wurden, können ein oder mehrere Verhaltensmodelle zwischen den Fahrzeugen oder mit Infrastrukturvermittlern ausgetauscht werden. Wie in Diagramm 2100c dargestellt, dienen den Verhaltensmodellen als Eingaben Karten- und andere geografische Daten (z. B. die Identifizierung potenziell befahrbarer Pfade), erkannte Hindernisse innerhalb dieser Pfade und der Zustand des Fahrzeugs (z. B. seine Position, Ausrichtung, Geschwindigkeit, Beschleunigung, Bremsen usw.). Die von den Verhaltensmodellen erzeugten Ergebnisse können die Wahrscheinlichkeit angeben, dass das entsprechende Fahrzeug eine bestimmte Aktion ausführen wird (z. B. lenken, bremsen, beschleunigen usw.). Verhaltensmodelle können generisch oder szenariospezifisch sein (z. B. Modelle für das Halten der Fahrspur, das Wechseln der Fahrspur, das Zusammenführen von Rampen oder Kreuzungen usw.). Das Verhaltensmodell kann zum Beispiel ein „universelles“ Modell in dem Sinne sein, dass es für ein bestimmtes Fahrszenario die Wahrscheinlichkeiten der entsprechenden Fahrzeugaktionen in diesem Szenario klassifiziert. In anderen Fällen können mehrere szenario- oder ortsspezifische Verhaltensmodelle für ein einzelnes Fahrzeug (oder eine Fahrzeugmarke/ein Fahrzeugmodell) entwickelt werden, und die Sammlung von Modellen kann ausgetauscht werden (z. B. alles auf einmal als Paket, situationsabhängig auf der Grundlage des/der Orte(s) oder des/der Szenarios(s), in denen das Fahrzeug auf andere Fahrzeuge trifft, usw.). In solchen Fällen kann ein Fahrzeug zunächst das Szenario erkennen, um das herum es plant (z. B. auf der Grundlage von Feststellungen, die in der eigenen Pfadplanungsphase des Fahrzeugs getroffen wurden), und die Ergebnisse verwenden, um ein bestimmtes der gemeinsam genutzten Modelle des anderen Fahrzeugs zu identifizieren, um das Verhaltensmodell zu ermitteln, das am besten zu dem vorliegenden Szenario „passt“, und dieses Verhaltensmodell zu verwenden, neben anderen Beispielimplementierungen.
• Um mit dem Beispiel von 21 fortzufahren, Fahrzeug B kann beim Empfang des Verhaltensmodells für Fahrzeug A erkennen, dass sich Fahrzeug A in seiner Nähe befindet, und ferner aktuelle Eingaben für das Verhaltensmodell erfassen, etwa von der eigenen Sensoranordnung des Fahrzeugs B, von externen Datenquellen (z. B. Straßenrandeinheiten) oder von Daten, die V2V von Fahrzeug A (z. B. durch ein Beacon-Signal) geteilt werden und die Umgebung, Hindernisse, die Geschwindigkeit von Fahrzeug A usw. beschreiben. Diese Eingaben (z. B. 2110) können als Eingaben für das Modell des gemeinsamen Verhaltens (z. B. 2115) bereitgestellt werden, um einen Wahrscheinlichkeitswert P (z. B. 2120) abzuleiten. Dieser Wahrscheinlichkeitswert 2120 kann die Wahrscheinlichkeit angeben, dass Fahrzeug A eine bestimmte Aktion durchführen wird (angesichts der aktuellen Umgebung und des beobachteten Status von Fahrzeug A), wie z. B. Lenken in eine bestimmte Richtung, Beschleunigen, Bremsen, Beibehalten der Geschwindigkeit, usw. Dieser Wahrscheinlichkeitswert 2120 kann dann vom autonomen Fahrstapel (z. B. 2125) von Fahrzeug B verwendet werden, wenn es seinen eigenen Weg plant und Entscheidungen in Bezug auf das Vorhandensein von Fahrzeug A trifft. Dementsprechend kann Fahrzeug B durch die Verwendung des gemeinsamen Verhaltensmodells die Art und Weise ändern, in der es die in der Fahrumgebung auszuführenden Aktionen bestimmt, und zwar abweichend von einem Standardansatz oder einer Programmierung, die der autonome Fahrstapel 2125 verwendet, wenn er in Gegenwart von Fahrzeugen fährt, für die kein Verhaltensmodell verfügbar ist, neben anderen Beispielimplementierungen.
• Um ein Fahrzeug in die Lage zu versetzen, die Aktionen und Manöver anderer Fahrzeuge (mit Hilfe seiner eigenen maschinellen Lernfähigkeiten) zu antizipieren und zu planen, insbesondere von Fahrzeugen mit unterschiedlichen Autonomiegrade, kann das Fahrzeug Verhaltensmodelle für diese anderen Fahrzeuge erhalten oder anderweitig darauf zugreifen. Auf der Grundlage der Modelle dieser benachbarten Fahrzeuge kann ein Fahrzeug, das die Straße mit diesen Fahrzeugen teilt, vorhersagen, wie diese Fahrzeuge aufgrund der in der Umgebung beobachteten Bedingungen, die jedes der Fahrzeuge beeinflussen, reagieren werden. Indem einem Fahrzeug die Verhaltensmodelle der umliegenden Fahrzeuge zur Verfügung gestellt werden, kann das Fahrzeug durch Projektion der Umgebungsbedingungen zukünftige Szenarien abschätzen. Auf diese Weise können Fahrzeuge, die mit diesen zusätzlichen Verhaltensmodellen ausgestattet sind, eine risikooptimierte Entscheidung auf der Grundlage aktueller Beobachtungen und modellgestützter Vorhersagen, die eine geringere Unsicherheit aufweisen, planen. Eine solche Lösung erhöht nicht nur die Sicherheit in der autonomen Fahrumgebung, sondern kann auch rechnerisch effizienter sein, da das Fahrzeug, das diese anderen Modelle verwendet, keine individuellen Verhaltensmodelle auf der Grundlage probabilistischer Projektionen für die umliegenden Fahrzeuge berechnen muss, sondern lediglich überprüft, ob die Projektionen glaubwürdig sind, und sein Verhalten entsprechend ändert.
• Bezug nehmend nun auf 22 ist ein Blockdiagramm 2200 dargestellt, das einen beispielhaften Informationsaustausch zwischen zwei Fahrzeugen 105, 110 illustriert. In einem Beispiel können vernetzte Fahrzeuge mehrere verschiedene Modi für den Informationsaustausch haben, darunter den Austausch von Beacon- und Modellen. In einem Beispiel umfasst der Beacon-Austausch die Aussendung eines Beacon 2208, um die Identität des entsprechenden Fahrzeugs (z. B. eine Kennung für ein angeschlossenes autonomes Fahrzeug (CAVid; connected autonomous vehicle identifier)) zusammen mit einem Zustandsvektor zu signalisieren, der die Position, die Ausrichtung und den Kurs desselben Fahrzeugs darstellt.) Der Modellaustausch kann die Übertragung des Verhaltensmodells des sendenden Fahrzeugs an andere Fahrzeuge (und straßenseitige Systeme) umfassen.
• Da ein Verhaltensmodell von einem anderen Fahrzeug genutzt werden kann, um künftiges Fahrzeugverhalten vorherzusagen und entsprechende Maßnahmen zu ergreifen, werden Verhaltensmodelle in einigen Fällen nur akzeptiert und genutzt, wenn sie von vertrauenswürdigen Fahrzeugen stammen. Dementsprechend kann der Austausch von Modellen zwischen Fahrzeugen ein Vertrauensprotokoll umfassen, das es den Geräten ermöglicht, die anfängliche Vertrauenswürdigkeit der von diesem Fahrzeug empfangenen Verhaltensmodelle festzustellen. In einigen Implementierungen kann sich dieser Vertrauenswürdigkeitswert im Laufe der Zeit ändern, wenn das ausgegebene Verhalten erheblich vom beobachteten Fahrzeugverhalten abweicht. Fällt der Vertrauenswürdigkeitswert unter einen bestimmten Schwellenwert, kann das Modell als ungeeignet eingestuft werden. Wie in 22 gezeigt, , wenn zwei Fahrzeuge 105, 110 einander in einer Umgebung begegnen, identifizieren sich in einigen Implementierungen die beiden Fahrzeuge (z. B. 105, 110) gegenseitig durch die jeweiligen CAVids, die mittels Beacon-Austausch gesendet werden. Ein Fahrzeug (z. B. 105) kann anhand des CAVid (z. B. bei 2210) feststellen, ob das andere Fahrzeug (z. B. 110) ein bekanntes Fahrzeug ist (oder sein Verhaltensmodell ein bekanntes Modell ist), so dass das Fahrzeug 105 das entsprechende Verhaltensmodell identifizieren und darauf zugreifen kann (z. B. in einem lokalen Cache oder in einer vertrauenswürdigen (z. B. Cloud- oder Fogbasierten) Datenbank (z. B. 2215)). Dementsprechend kann in einigen Implementierungen bei der Begegnung mit einem anderen Fahrzeug eine Abfrage durchgeführt werden, um festzustellen, ob die erforderlichen Verhaltensmodelle in der Datenbank 2215 vorhanden sind, die einer im Beacon-Signal umfassten angekündigten CAVid entsprechen. Wenn festgestellt wird, dass das Fahrzeug 105 nicht im Besitz des Verhaltensmodells für das identifizierte Fahrzeug 110 ist, können die Fahrzeuge einen Modellaustausch beginnen, indem sie eine Sitzung durch den Austausch von Token aufbauen (bei 2220). In einem Beispiel kann jedes Token (z. B. 2225) die CAVid, den öffentlichen Schlüssel und einen geheimen Wert sowie eine Sitzungs-ID umfassen. Jedes Fahrzeug (z. B. 105, 110) kann den Token des anderen empfangen und eine Überprüfung 2230 des Tokens durchführen, um sicherzustellen, dass der Token gültig ist. Nach Überprüfung der Token-Signatur kann dem anderen Fahrzeug eine Bestätigung übermittelt werden, die anzeigt, dass das Fahrzeug dem anderen Fahrzeug vertraut und mit dem Modellaustausch fortfahren möchte. In einigen Implementierungen kann der Modellaustausch die Kommunikation eines Verhaltensmodells (z. B. 2235) umfassen, das über mehrere Pakete aufgeteilt und kommuniziert wird, bis der Modellaustausch 2240 im letzten Paket abgeschlossen ist (was z. B. durch eine Bestätigung angezeigt werden kann). Die Sitzungs-ID der Sitzung kann bei Bedarf verwendet werden, um die Wiederherstellung von Daten zu ermöglichen, falls die Verbindung zwischen den beiden Fahrzeugen unterbrochen wird. Für die Kommunikation zwischen den beiden Fahrzeugen kann V2V- oder V2X-Kommunikation verwendet werden. In einigen Fällen kann es sich bei dem Kommunikationskanal um einen Kanal mit geringer Latenz und hohem Durchsatz handeln, wie z. B. einen 5G-Drahtloskanal.
• Nach Erhalt des Verhaltensmodells eines anderen Fahrzeugs kann das Fahrzeug eine Modellprüfung 2245 für das Modell durchführen. Die Modellüberprüfung 2245 kann die Überprüfung des Modells auf Normkonformität und Kompatibilität mit dem Autonomes-Fahren-Stack oder dem maschinellen Lernsystem des empfangenden Fahrzeugs umfassen. In einigen Fällen können frühere Eingaben und aufgezeichnete Ausgaben des Verhaltensmodells des empfangenden Fahrzeugs im empfangenden Fahrzeug zwischengespeichert werden, und das empfangende Fahrzeug kann die Gültigkeit des empfangenen Verhaltensmodells überprüfen, indem es diese zwischengespeicherten Eingaben auf das empfangene Verhaltensmodell anwendet und die Ausgabe mit der zwischengespeicherten Ausgabe vergleicht (z. B. Validierung des empfangenen Verhaltensmodells, wenn die Ausgabe vergleichbar ist). In anderen Implementierungen kann die Überprüfung des Verhaltensmodells 2245 durch die Beobachtung des Verhaltens des entsprechenden Fahrzeugs (z. B. 110) und die Feststellung erfolgen, ob das beobachtete Verhalten einem erwarteten Verhalten entspricht, das durch das Verhaltensmodell bestimmt wurde (z. B. durch Bereitstellung von Eingaben, die der aktuellen Umgebung entsprechen, für das Modell und die Feststellung, ob die Ausgabe mit dem beobachteten Verhalten des Fahrzeugs übereinstimmt). Bei dem Beispiel von 22 kann nach Überprüfung eines empfangenen Verhaltensmodells eine Bestätigung (z. B. 2250) an das Ausgangsfahrzeug gesendet und die Sitzung geschlossen werden. Von da an können die Fahrzeuge weiterhin Beacon- austauschen (um 2255), um ihre weitere Nähe festzustellen und andere Informationen auszutauschen (z. B. Sensordaten, Ergebnisse ihrer Modelle usw.).
• Während das Beispiel von 22 einen Fall veranschaulicht, in dem ein unbekanntes Fahrzeug angetroffen wird und neue Verhaltensmodelle ausgetauscht werden. Wenn zwei Fahrzeuge (z. B. 105, 110) in der Vergangenheit bereits Verhaltensmodelle miteinander ausgetauscht haben, wird die Suche in einem Cache oder einer Verhaltensmodelldatenbank 2215 ein positives Ergebnis liefern, und eine Bestätigungsnachricht der Modellüberprüfung kann zwischen den beiden Fahrzeugen ausgetauscht werden. In einigen Fällen können Verhaltensmodelle aktualisiert werden oder auslaufen. In diesem Fall können die Fahrzeuge die Aktualisierung einem anderen bekannten Fahrzeug (oder Fahrzeugmodell) mitteilen, und es kann ein Austausch der Modellaktualisierung durchgeführt werden (z. B. in ähnlicher Weise wie bei einem vollständigen Modellaustausch in einer neuen Sitzung), neben anderen Beispielen. In einigen Fällen kann ein Fahrzeug (z. B. 105) einseitig feststellen, dass ein zuvor gespeichertes Verhaltensmodell für ein bestimmtes anderes Fahrzeug (z. B. 110) veraltet, falsch oder fehlerhaft ist, wenn es (bei einer nachfolgenden Begegnung mit dem bestimmten Fahrzeug) feststellt, dass das beobachtete Verhalten des bestimmten Fahrzeugs nicht mit dem vorhergesagten Verhalten übereinstimmt, das bei Anwendung der früher gespeicherten Version des Verhaltensmodells ermittelt wurde. Eine solche Feststellung kann das Fahrzeug (z. B. 105) veranlassen, eine aktualisierte Version des Verhaltensmodells anzufordern (z. B. und einen Modellaustausch auszulösen, der dem in 22 Gezeigten ähnlich ist).
• Durch den Austausch und die Sammlung von verifizierten, genauen und vertrauenswürdigen Verhaltensmodellen kann ein Fahrzeug in Zukunft den Austausch von Beacon- nutzen, um Fahrzeuge zu identifizieren, die ein vertrauenswürdiges, genaues Verhaltensmodell bei der Navigation in einer Umgebung verwenden, und kann dadurch zukünftige Vorhersagen über das Verhalten des umgebenden Fahrzeugs auf effiziente Weise erstellen. In einigen Fällen können Verhaltensmodelle und CAVids auf der Basis eines einzelnen Fahrzeugs erfolgen. In anderen Beispielen kann davon ausgegangen werden, dass jede Instanz eines bestimmten autonomen Fahrzeugmodells (z. B. Marke, Modell und Jahr) dasselbe Verhaltensmodell verwendet, so dass ein Fahrzeug bei Begegnungen mit irgendeiner Instanz dieses Fahrzeugmodells u. a. die Verifizierung eines einzigen, diesem Fahrzeugmodell zugeordneten Verhaltensmodells verwenden kann.
• Die Verhaltensmodelle können auf den Modellen des maschinellen Lernens basieren, die für das autonome Fahren des entsprechenden Fahrzeugs verwendet werden. In einigen Fällen können Verhaltensmodelle stattdessen auf Regelmaschinen oder Heuristiken beruhen (und somit regelbasiert sein). In einigen Fällen können sich die Verhaltensmodelle, die mit anderen Fahrzeugen geteilt und ausgetauscht werden sollen, von den tatsächlich vom Fahrzeug verwendeten Maschinelles-Lernen-Modellen unterscheiden. Wie bereits erwähnt, können Verhaltensmodelle kleinere, einfachere „Teile“ eines Gesamtmodells sein, die bestimmten Umgebungen, Szenarien, Straßenabschnitten usw. entsprechen. Zu den szenariospezifischen Verhaltensmodellen können beispielsweise neuronale Netzwerkmodelle gehören, die die Wahrscheinlichkeit verschiedener Aktionen eines entsprechenden Fahrzeugs im Kontext des jeweiligen Szenarios darstellen (z. B. Manövrieren an einer Kreuzung, Manövrieren in einem Kreisverkehr, Umgang mit Überholvorgängen, Fahren auf der Autobahn, Fahren bei schlechtem Wetter, Fahren durch Höhenunterschiede verschiedener Steigungen, Fahrspurwechsel usw.). Dementsprechend können mehrere Verhaltensmodelle für ein einzelnes Fahrzeug bereitgestellt und im Speicher eines bestimmten Fahrzeugs unter Verwendung dieser Modelle gespeichert werden. Darüber hinaus kann die Verwendung dieser verschiedenen Modelle im Vergleich zur Verwendung eines universellen Verhaltensmodells, das alle potenziellen Verhaltensweisen eines bestimmten Fahrzeugs modelliert, eine schnellere und effizientere (und genauere) Vorhersage für das jeweilige Fahrzeug ermöglichen, neben anderen Beispielen.
• Der Austausch und die Sammlung von Verhaltensmodellen kann in einigen Fällen auf von Menschen gesteuerte Fahrzeuge, einschließlich autonomer Fahrzeuge der unteren Klasse, ausgeweitet werden. In einigen Fällen können Verhaltensmodelle für einzelne Fahrer, Gruppen von Fahrern (Fahrer in einer bestimmten Gegend oder an einem bestimmten Ort, Fahrer mit bestimmten demografischen Merkmalen usw.), gemischte Modelle (abhängig davon, ob das Fahrzeug in einem autonomen Modus oder einem Modus mit menschlichem Fahrer betrieben wird) und andere Beispiele erstellt werden. Beispielsweise kann ein Fahrzeug (als OEM-Komponente oder Nachrüstkomponente) einen Monitor umfassen, der die Leistung eines menschlichen Fahrers beobachtet und ein Verhaltensmodell für diesen Fahrer oder eine Gruppe von Fahrern erstellt (z. B. durch gemeinsame Nutzung der Überwachungsdaten mit einer Cloud-basierten Aggregator-Anwendung). In anderen Fällen können straßenseitige Sensoren und/oder Sensordaten aus der Bevölkerung verwendet werden, die das Fahrverhalten einzelner Fahrer oder Fahrergruppen beschreiben, und auf der Grundlage dieser Informationen kann ein Verhaltensmodell erstellt werden. Verhaltensmodelle für menschliche Fahrer können in einem zugehörigen Fahrzeug gespeichert und mit anderen Fahrzeugen in Übereinstimmung mit anderen Austauschen von Verhaltensmodellen, wie in den obigen Beispielen beschrieben, geteilt werden. In anderen Fällen, z. B. wenn das von Menschen gesteuerte Fahrzeug nicht angeschlossen ist oder den Austausch von Modellen nicht unterstützt, können andere Systeme verwendet werden, um Verhaltensmodelle für menschliche Fahrer auszutauschen und zu verbreiten, z. B. straßenseitige Einheiten, Peer-to-Peer-Verteilung (z. B. V2V) durch andere Fahrzeuge und andere Beispiele.
• Da immer mehr Akteure im Straßenverkehr selbstfahrend unterwegs sind und die städtische Infrastruktur modernisiert wird, kann es zu Konflikten zwischen den verschiedenen Systemen für autonomes Fahren und den auf maschinellem Lernen basierenden Verhaltensmodellen kommen, auf die sich diese Akteure verlassen. Da verschiedene Anbieter von Fahrzeugen und autonomen Systemen mit unabhängigen Lösungen konkurrieren, kann es wünschenswert sein, die Koordinierung und Konsensbildung zwischen den verschiedenen Modellen zu erleichtern, die von diesen vielen Fahrzeugen und anderen Akteuren genutzt werden. Staatliche Gesetze und Vorschriften sowie Industrienormen können entwickelt werden, um die Sicherheit und Kompatibilität zwischen verschiedenen Technologien zu fördern. Da jedoch mehrere wichtige Akteure ihre eigenen Lösungen entwickeln, bleibt die Frage nach der Verbesserung der allgemeinen Sicherheit im Straßenverkehr unbeantwortet. Die Sicherheitsstandards stecken noch in den Kinderschuhen, da es für die politischen Entscheidungsträger und die Öffentlichkeit keine klare Möglichkeit gibt, die von diesen Fahrzeugen getroffenen Entscheidungen zu überprüfen. Da autonome Fahrzeuge ihre Modelle und die entsprechende Entscheidungsfindung verbessern, können veraltete Modelle und Lösungen (z. B. in Fahrzeugen aus der Anfangszeit des autonomen Fahrens) eine zunehmende Gefahr im Straßenverkehr darstellen. Dies führt zu einem Problem bei der Verhaltensübereinstimmung, da ältere oder schlecht funktionierende autonome Fahrzeugakteure auf der Straße möglicherweise widersprüchliche Modelle verwenden und nicht in den Genuss der Vorteile verbesserter Funktionen kommen, die durch neuere, weiterentwickelte Modelle bereitgestellt werden.
• Angesichts der jungen und sich entwickelnden Branche der autonomen Fahrzeuge und der noch in den Kinderschuhen steckenden 5G-Netze und -Infrastrukturen sind die V2X-Kommunikation und -Lösungen ähnlich begrenzt. So sind die heute angebotenen V2X-Lösungen vor allem im Bereich der Lokalisierung und Kartierung angesiedelt. In dem Maße, in dem autonome Fahrzeuge und die sie unterstützende Infrastruktur zur Regel werden, bietet sich die Gelegenheit, neue Lösungen zu entwickeln und auszubauen, die die Zusammenarbeit und Kommunikation zwischen vernetzten Fahrzeugen und ihrer Umgebung fördern. In einigen Implementierungen können beispielsweise ein Konsens und unterstützende Protokolle implementiert werden, um die Erstellung von Konsens-Verhaltensmodellen zu ermöglichen, die gemeinsam genutzt werden können, um die „besten“ Modelle an die Fahrzeuge weiterzugeben, so dass sich die maschinellen Lernmodelle der Fahrzeuge kontinuierlich weiterentwickeln, um die sichersten, effizientesten und insassenfreundlichsten Innovationen und „Erkenntnisse“ zu übernehmen. So können beispielsweise drahtlose Hochgeschwindigkeitsnetzwerke (z. B. 5G-Netzwerke) und eine verbesserte Straßeninfrastruktur zur Unterstützung solcher Konsenssysteme genutzt werden.
• In einem Beispiel kann ein byzantinischer Konsensalgorithmus definiert und zwischen den Akteuren in einem autonomen Fahrsystem implementiert werden, um einen fehlertoleranten Konsens zu erreichen. Ein solcher Konsens kann davon abhängen, dass die Mehrheit der Teilnehmer (z. B. die Teilnehmer eines gemeinsamen Verhaltensmodells) genaue Informationen in das Konsenssystem einspeist. Die Genauigkeit der Beiträge kann im Zusammenhang mit autonomen Fahrzeugen problematisch sein, da die Gesamtzahl der Verkehrsteilnehmer an einer bestimmten Kreuzung zu einem bestimmten Zeitpunkt möglicherweise gering ist, was die Wahrscheinlichkeit eines schlechten Konsenses erhöht (z. B. durch die gemeinsame Nutzung von Modellen durch die wenigen Akteure). In einigen Implementierungen können Rechenknoten an Straßenabschnitten und Straßenkreuzungen (z. B. Kreuzungen, Kreisverkehre usw.) vorgesehen werden, z. B. in Straßenrandeinheiten (z. B. 140), die an Straßenlaternen, nahe gelegenen Gebäuden, Verkehrssignalen usw. montiert sind, neben anderen Beispielen. In einigen Fällen können die Rechenknoten in zusätzliche Sensorgeräte integriert oder mit diesen verbunden sein, die in der Lage sein können, den Verkehr auf dem entsprechenden Straßenabschnitt zu beobachten. Solche straßenseitigen Rechengeräte (der Einfachheit halber hier zusammenfassend als „straßenseitige Einheiten“ oder „RSU“ bezeichnet) können als zentraler Punkt für die Sammlung von Modellbeiträgen, die Verteilung der Modelle zwischen den Fahrzeugen, die Validierung der Modelle durch die ankommenden angeschlossenen autonomen Fahrzeuge und die Ermittlung des Konsenses aus diesen Modellen (und, sofern möglich, auf der Grundlage von Beobachtungen der Sensoren der RSU) an den entsprechenden Straßenabschnittsstandorten bestimmt und ausgebildet werden.
• In einigen Implementierungen kann eine straßenseitige Einheit, die einen Konsensknoten für einen bestimmten Straßenabschnitt implementiert, modellbasierte Verhaltensinformationen aus dem einzigartigen Sensor- und Wahrnehmungsstapel jedes Fahrzeugs akzeptieren und im Laufe der Zeit verfeinern, was das ideale Verhaltensmodell für diesen Straßenabschnitt ist. Auf diese Weise kann dieser zentrale Punkt die Genauigkeit der Modelle im Vergleich zu anderen Verkehrsteilnehmern, die sich zu diesem Zeitpunkt auf der Straße befinden, sowie zu anderen Verkehrsteilnehmern, die in der Vergangenheit denselben Straßenabschnitt befahren haben, überprüfen. Auf diese Weise kann der Konsensknoten Modelle auf historische Weise betrachten. Dieser zentrale Knotenpunkt kann dann als Anführer in einer byzantinischen Konsenskommunikation zur Standardisierung der Straßenverkehrssicherheit zwischen verschiedenen Akteuren dienen, trotz der unterschiedlichen Anzahl und Verteilung der genauen Konsensbeiträge.
• Bezug nehmend nun auf 23 wird ein vereinfachtes Blockdiagramm 2300 gezeigt, das ein Beispiel für eine Straßenkreuzung 2305 darstellt. Eine oder mehrere straßenseitige Einheiten (z. B. 140) können als Konsensknoten für den Straßenabschnitt 2305 dienen. In diesem Beispiel kann das Gerät des Konsensknotens (z. B. 140) einen oder mehrere Sensoren, wie die Kamera 2310, umfassen. In einigen Implementierungen kann der Konsensknoten als zwei oder mehr verschiedene, gemeinsam genutzte Computergeräte implementiert werden, die miteinander kommunizieren und als ein einziges Gerät zusammenarbeiten, wenn sie Konsensdienste für das entsprechende Straßensegment 2305 durchführen. Die Vertrauenswürdigkeit der Straßenrandeinheit(en) (z. B. 140), die den Konsensknoten implementiert (implementieren), kann von grundlegender Bedeutung sein, und die RSU 140 kann mit einem vertrauenswürdigen Akteur, wie z. B. einer Regierungsbehörde, verbunden sein. In einigen Implementierungen kann eine RSU 140 mit Hardware, Firmware und/oder Software ausgebildet sein, um Bestätigungstransaktionen durchzuführen, um ihre Identität und Vertrauenswürdigkeit gegenüber anderen Rechensystemen zu bestätigen, die mit anderen in der Nähe befindlichen Straßenakteuren (z. B. Fahrzeugen 105, 110, 115 usw.) verbunden sind, neben anderen Beispielen. Ein Beispiel für eine RSU kann Rechen- und Speicherressourcen mit hardware- und/oder softwarebasierter Logik umfassen, um drahtlos mit anderen Systemen von Straßenakteuren zu kommunizieren, den Austausch von Verhaltensmodellen zwischen Fahrzeugen zu beobachten und zu erfassen (wie oben im Beispiel von 21 und 22 beschrieben), erhalten Verhaltensmodelle direkt von anderen Straßenakteuren, bestimmen (aus den empfangenen Modelleingaben) ein Konsensmodell (z. B. auf der Grundlage eines byzantinischen Konsensschemas oder -algorithmus) und verteilen das Konsensmodell an Straßenakteure (z. B. 105, 110, 115), damit diese ihre internen Modelle aktualisieren (oder ersetzen), um die Navigation des Straßenakteurs auf dem entsprechenden Straßenabschnitt zu optimieren (z. B. 2305).
• Es sei darauf hingewiesen, dass eine RSU, die einen Konsensknoten einrichtet, dies ohne zusätzliche Sensorgeräte tun kann. In einigen Implementierungen kann ein RSE-Sensorsystem (z. B. 2310) jedoch nützliche Eingaben liefern, die vom RSE beim Aufbau eines Konsens-Verhaltensmodells verwendet werden können. Beispielsweise kann eine RSU einen oder mehrere Sensoren (z. B. 2310) verwenden, um nicht-autonome Straßenakteure zu beobachten (z. B. nicht-autonome Fahrzeuge, Elektroroller und andere kleine motorisierte Transportmittel, Radfahrer, Fußgänger, Tiere usw.), um lokalisierte Modelle (z. B. für einen Straßenabschnitt (z. B. 2305)) zu erstellen und diese Beobachtungen in das Konsensmodell aufzunehmen. So kann beispielsweise davon ausgegangen werden, dass nicht-autonome Fahrzeuge nicht in der Lage sind, ein Verhaltensmodell zu übermitteln, und ein Sensorsystem der RSU kann Verhaltensmodelle für nicht-autonome Fahrzeuge, menschliche Fahrer und andere Verkehrsteilnehmer auf der Grundlage von Beobachtungen seiner Sensoren erstellen (z. B. 2310). Beispielsweise können ein Sensorsystem und die Logik einer beispielhaften RSU (z. B. 140) die Erkennung bestimmter nicht autonomer Fahrzeuge oder sogar die Erkennung bestimmter menschlicher Fahrer ermöglichen, und auf der Grundlage des Vorhandenseins (und der Häufigkeit des Vorhandenseins dieser Akteure) in der Straßenumgebung können entsprechende Verhaltensmodelle entwickelt werden. Für dieses Straßensegment 2305 können Konsensmodelle erstellt werden, um das Wissen darüber einzubeziehen, wie man am besten den Weg plant und Entscheidungen trifft, wenn solche nicht-autonomen Akteure von einem autonomen Fahrzeug (z. B. 105), das das Konsensmodell anwendet, entdeckt werden. In weiteren Beispielen können nicht-autonome Fahrzeuge dennoch mit Sensoren (z. B. OEM- oder Nachrüstsensoren) ausgestattet sein, die Aktionen des Fahrzeugs oder seines Fahrers und die diesen aufgezeichneten Aktionen entsprechenden Umgebungsbedingungen aufzeichnen (z. B. um die Erkennung von Fahrreaktionen auf diese Bedingungen zu ermöglichen) und diese Informationen an straßenseitige Einheiten weitergeben, um bei der Bereitstellung von Daten zu helfen, die in Konsensmodellen verwendet und integriert werden können, die von jeder dieser RSUs für ihre jeweiligen Orte oder Straßenabschnitte erstellt werden. Erstausrüster- und Nachrüstsysteme können auch bereitgestellt werden, um einige autonome Fahrfunktionen in nicht autonomen Fahrzeugen zu ermöglichen und/oder Fahrerassistenz zu bieten, und solche Systeme können mit Funktionen ausgestattet sein, um mit RSUs zu kommunizieren und Konsensmodelle zur Verwendung bei der Erweiterung der Dienste und Informationen zu erhalten, die durch solche Fahrerassistenzsysteme bereitgestellt werden, neben anderen Beispielimplementierungen.
• Die am Konsens beteiligten Akteure können entweder autonome Fahrzeuge oder nicht-autonome Fahrzeuge sein. Wenn sich beispielsweise Fahrzeuge (z. B. 105, 110, 115) in Reichweite zueinander und zu einer Straßenrandeinheit 140 befinden, die den Straßenabschnitt (z. B. 2305) regelt, können die Fahrzeuge miteinander kommunizieren, um ihre jeweiligen Verhaltensmodelle auszutauschen und an einer Konsensverhandlung teilzunehmen. Die RSU 140 kann in die Verhandlung eingreifen, um veraltete, böswillig falsche oder fehlerhafte Modelle auf der Grundlage des von der RSU 140 im Laufe der Zeit entwickelten Konsensmodells zu ermitteln. Das Konsensmodell ist vergleichbar mit einer Arbeitserklärung, die verhindert, dass eine Minderheit von Akteuren in einer Verhandlung die Qualität des kumulativen Wissens, das im Konsensmodell umfassen ist, dramatisch verschlechtert und außer Kraft setzt. Bezug nehmend nun auf 24 werden Diagramme 2405, 2410 gezeigt, die veranschaulichen, dass im Laufe der Zeit (t) für ein bestimmtes Straßensegment ein lokalisierter Verhaltensmodellkonsens unter Berücksichtigung der Beteiligung einer entsprechenden RSU (z. B. 140) an jeder Konsensverhandlung für das Straßensegment gesammelt und bestimmt werden kann. Dieser historische Konsensansatz ermöglicht eine höhere Verkehrssicherheit, da autonome Fahrzeuge verschiedener Marken und Hersteller mit unterschiedlichen autonomen Fahrsystemen sowohl in der Gegenwart als auch in der Vergangenheit voneinander profitieren können. Ein solches konsensbasiertes System wendet einen ganzheitlichen und bewährten Ansatz für die Straßenverkehrssicherheit durch die gemeinsame Nutzung von Verhaltensmodellen an. Von jedem Akteur auf der Straße (z. B. 105, 110, 115), ob autonomes Fahrzeug oder nicht-autonomes Fahrzeug, wird erwartet, dass er die Umgebung beobachtet und eine Entscheidung darübertrifft, wie er sich unabhängig davon verhalten soll. Alle Konsensbeteiligten (z. B. 105, 110, 115, 140 usw.) werden auch versuchen, die Aktionen anderer Verkehrsteilnehmer über ihre jeweiligen sensorischen Systeme vorherzusagen. Autonome Fahrzeuge (z. B. 105, 110, 115) teilen dann ihre Verhaltensmodelle mit der RSU (z. B. 140) und untereinander, wie in den Darstellungen in den Diagrammen 2405, 2410 zu sehen ist.
• Durch die gemeinsame Nutzung von Modellen im Rahmen einer Konsensbildung (z. B. auf der Grundlage eines byzantinischen Konsensmodells) können autonome Fahrzeuge dann ihre eigene Wahrnehmung der Umgebung anhand des/der Konsens-Verhaltensmodells/Verhaltensmodelle nutzen und die genauen Handlungen der anderen Verkehrsteilnehmer bestimmen, so dass sie und ihre Kollegen überprüfen können, ob ihre anfänglichen Vorhersagen übereinander zutreffend waren. Diese Information und Validierung ist auch für die RSU sichtbar, die ebenfalls an dieser Konsensverhandlung beteiligt ist. Mit dem Wissen um risikoreichere Verhaltensweisen, die zu Kollisionen führen würden, kann die Abstimmung beginnen, bei der ein Verhaltensmodell verbreitet wird, das nicht zu Kollisionen oder Missverständnissen über die Umgebung einschließlich anderer Verkehrsteilnehmer führt. Hashes oder Seeds, die auf dem ausgewählten Modell basieren, können verwendet werden, um den Vergleich zu vereinfachen und die Wiederholung lokaler Verhaltensmodellvorhersagen während des Prozesses zu vermeiden. In einigen Implementierungen kann die RSU als Konsensknotenpunkt ihren Beitrag zum Konsens auf der Grundlage früherer erfolgreicher Konsensverhandlungen, an denen sie beteiligt war, gewichten, was von den anderen Akteuren auf der Straße berücksichtigt werden sollte. Die Validierung des Konsenses kann dann anhand der Aktionen der Straßenakteure überprüft werden.
• Wie bereits erwähnt, können hochauflösende Karten in verschiedenen Anwendungen des autonomen Fahrens verwendet werden, unter anderem durch das bordeigene System selbst sowie durch externe Systeme, die einem autonomen Fahrzeug Fahrunterstützung bieten (z. B. Cloud- oder straßenseitige Systeme, Remote-Valet-Systeme usw.). Dementsprechend ist die Genauigkeit der beim autonomen Fahren/bei der autonomen Fahrzeugsteuerung verwendeten HD-Karte von entscheidender Bedeutung. Um die HD-Karte zu erstellen und zu pflegen, ist es wichtig, dynamische und aktuelle Daten zu erhalten. Wenn sich die Umgebung ändert (z. B. Straßenarbeiten, Unfälle usw.), sollte die HD-Karte aktualisiert werden, um diese Änderung zu berücksichtigen. In einigen Fällen können Daten von mehreren autonomen Fahrzeugen per Crowdsourcing gesammelt und zur Aktualisierung der HD-Karte verwendet werden. In einigen Fällen kann das Vertrauen in die erhaltenen Daten jedoch fragwürdig sein. Eine Herausforderung könnte darin bestehen, die Vertrauenswürdigkeit der von den einzelnen Fahrzeugen empfangenen Daten zu verstehen und zu codieren. So können die von einem autonomen Fahrzeug stammenden Daten von geringerer Qualität sein (z. B. von weniger leistungsfähigen Sensoren), unbeabsichtigt verfälscht (z. B. durch zufällige Bitumkehr) oder böswillig verändert werden. Solche Daten von geringer (oder gar keiner) Qualität könnten wiederum die auf den Servern vorhandenen HD-Karten beschädigen.
• Dementsprechend können in bestimmten Ausführungsformen die von den verschiedenen Sensoren eines autonomen Fahrzeugs gesammelten Daten mit Daten verglichen werden, die in einer entsprechenden Kachel der auf das autonome Fahrzeug heruntergeladenen HD-Karte umfassen sind. Wenn es einen Unterschied zwischen den gesammelten Daten und den HD-Kartendaten gibt, kann das Delta (Differenz zwischen der HD-Kartenkachel und den neu gesammelten Daten) an den Server übertragen werden, der die HD-Karte hostet, so dass die HD-Kartenkachel an diesem bestimmten Ort aktualisiert werden kann. Vor der Übertragung an den Server können die Daten lokal in jedem autonomen Fahrzeug bewertet und erneut auf dem Server überprüft werden, bevor die HD-Karte aktualisiert wird. Obwohl hier beschrieben wird, dass der Server die Sensordaten des autonomen Fahrzeugs validiert, bevor eine HD-Karte aktualisiert wird, können die Delta-Informationen in einigen Fällen auch an andere autonome Fahrzeuge in der Nähe des autonomen Fahrzeugs, das die Daten gesammelt hat, gesendet werden, um ihre HD-Karten schnell zu aktualisieren. Die anderen autonomen Fahrzeuge können die Daten auf die gleiche Weise wie der Server analysieren, bevor sie ihre HD-Karte aktualisieren.
• 25 ist ein vereinfachtes Diagramm, das einen beispielhaften Prozess der Bewertung und Validierung von Sensordaten autonomer Fahrzeuge aus der Crowd gemäß mindestens einer Ausführungsform zeigt. Im gezeigten Beispiel sammelt jedes autonome Fahrzeug 2502 Daten von einem oder mehreren damit verbundenen Sensoren (z. B. Kamera(s), LIDAR, Radar usw.). Die autonomen Fahrzeuge 2502 können die Sensordaten verwenden, um einen oder mehrere Aspekte des autonomen Fahrzeugs zu steuern. Während jedes autonome Fahrzeug Daten von einem oder mehreren Sensoren sammelt, kann das autonome Fahrzeug bestimmen, wie viel Vertrauen in die gesammelten Daten gesetzt wird. Beispielsweise kann die Vertrauensbewertung auf Informationen basieren, die sich auf die Erfassung der Sensordaten beziehen, wie z. B. Wetterdaten zum Zeitpunkt der Datenerfassung (z. B. können Kameradaten an einem sonnigen Tag eine höhere Vertrauensbewertung erhalten als Kameras an einem nebligen Tag), Informationen zur Konfiguration des Sensorgeräts (z. B. eine Bitrate oder Auflösung des Kamerastroms), Informationen zum Betrieb des Sensorgeräts (z. B. bitfehlerrate für einen Kamerastrom), Informationen über den Authentifizierungsstatus des Sensorgeräts (z. B. ob das Sensorgerät zuvor vom autonomen Fahrzeug authentifiziert wurde, wie weiter unten beschrieben) oder Informationen über die Bestätigung lokaler Sensoren (z. B. Informationen, die anzeigen, dass jede von zwei oder mehr Kameras des autonomen Fahrzeugs ein Objekt im selben Videobild oder zur selben Zeit erkannt hat).
• Das autonome Fahrzeug kann einen Vertrauenswert berechnen, der in den mit den Daten verbundenen Metadaten gespeichert werden kann. Der Vertrauenswert kann in einigen Implementierungen eine kontinuierliche Skala zwischen Null und Eins sein (statt einer binären Entscheidung, ob man allem oder nichts vertraut) oder zwischen Null und einer anderen Zahl (z. B. 10). Darüber hinaus kann in Fällen, in denen das Erfassungsgerät zur Authentifizierung oder Bescheinigung in der Lage ist (z. B. wenn das Gerät durch das autonome Fahrzeug authentifiziert wird, bevor das autonome Fahrzeug die Daten vom Gerät akzeptiert), der Authentifizierungs-/Bescheinigungsstatus des Geräts in den Metadaten der vom Sensorgerät erfassten Daten angegeben werden (z. B. als Flagge, digitale Signatur oder eine andere Art von Information, die den Authentifizierungsstatus des Sensorgeräts angibt), so dass der Server 2504 oder ein anderes autonomes Fahrzeug die Daten umfassender verifizieren/validieren/vertrauen kann, bevor die Daten zur Aktualisierung der HD-Karte verwendet werden. In einigen Fällen kann das autonome Fahrzeug selbst durch den Server authentifiziert werden (z. B. mit Hilfe digitaler Signaturverfahren). In solchen Fällen können die von verschiedenen Sensoren des autonomen Fahrzeugs gesammelten Daten vom Hauptprozessor oder der Verarbeitungseinheit im autonomen Fahrzeug aggregiert und in einigen Fällen authentifiziert werden, bevor sie an den Server oder an nahe gelegene autonome Fahrzeuge übertragen oder anderweitig übermittelt werden.
• Die Werte für die Bewertung der verschiedenen Geräte können durch eine Richtlinie für die Sammlung und Zusammenfassung der Daten festgelegt werden. Die Richtlinie kann auch angeben, wann das autonome Fahrzeug die neu gesammelten Daten hochladen soll, z. B. zur Aktualisierung der HD-Karte. Die Richtlinie kann beispielsweise festlegen, dass das Delta zwischen der HD-Kartenkachel und den neu erfassten Daten über einem bestimmten Schwellenwert liegen muss, damit die Daten zur Aktualisierung der HD-Karte an den Server zurückgesendet werden. Beispielsweise können Baustellenmaterialien (Fässer, Geräte usw.) ein großes Delta zwischen den HD-Kartendaten und den erfassten Daten verursachen, während ein Kieselstein auf der Straße ein kleineres Delta verursachen kann. Die Richtlinie kann auch vorsehen, dass der mit den Daten verbundene Konfidenzwert über einem bestimmten Schwellenwert liegen muss, bevor die Daten hochgeladen werden. So kann z. B. verlangt werden, dass der Konfidenzwert über 0,8 liegt, damit alle Daten an den Server zurückgesendet/veröffentlicht werden.
• Nach dem Empfang vom autonomen Fahrzeug kann der Server zusätzliche Überprüfungsmaßnahmen durchführen, bevor er die HD-Karte mit den Delta-Informationen aktualisiert. So kann der Server beispielsweise den Konfidenzwert/die Metrik überprüfen, der/die mit den Daten geteilt wurde (z. B. in den Metadaten). Solange der/die Konfidenzwert(e) einer Serverrichtlinie entsprechen (z. B. müssen alle zur Aktualisierung der Karte verwendeten Deltadaten einen Konfidenzwert aufweisen, der größer als ein Schwellenwert, z. B. 0,9, ist), kann der Server die Daten zur Aktualisierung der HD-Karte berücksichtigen. In einigen Fällen kann der Server eine Liste der kürzlich gesehenen autonomen Fahrzeuge führen und einen Vertrauenswert für jedes der autonomen Fahrzeuge zusammen mit dem Vertrauenswert der Daten zur Aktualisierung der Karte verfolgen. In einigen Ausführungsformen kann die Vertrauensbewertung als zusätzlicher Filter dafür verwendet werden, ob der Server die Daten zur Aktualisierung der HD-Karte verwendet. In einigen Fällen kann der Vertrauenswert auf dem Vertrauenswert der empfangenen Daten basieren. Wenn der Vertrauenswert beispielsweise über einem ersten Schwellenwert liegt, kann der Vertrauenswert für das autonome Fahrzeug erhöht werden (z. B. erhöht (+1)), und wenn der Vertrauenswert unter einem zweiten Schwellenwert liegt (der niedriger ist als der erste Schwellenwert), kann der Vertrauenswert für das autonome Fahrzeug verringert werden (z. B. verringert (-1)). Liegt der Vertrauenswert zwischen dem ersten und dem zweiten Schwellenwert, so kann der Vertrauenswert für das autonome Fahrzeug gleich bleiben. In einigen Implementierungen kann ein IoT-basiertes Reputationssystem (z. B. EigenTrust oder PeerTrust) für diese Nachverfolgung verwendet werden. In einigen Fällen können die Sensordaten mit Sensordaten anderer autonomer Fahrzeuge in der Umgebung korreliert werden, um festzustellen, ob den Sensordaten zu trauen ist.
• In einigen Ausführungsformen kann das autonome Fahrzeug bei der Veröffentlichung der Daten auf dem Server die Daten mit pseudo-anonymen Zertifikaten signieren. Das autonome Fahrzeug kann z. B. eines der für die V2X-Kommunikation entwickelten Systeme verwenden. In einigen Fällen können die signierten Daten, wenn sie vom Server empfangen werden, an das HD-Kartenmodul weitergeleitet werden, um die HD-Karte zu aktualisieren, sofern sie nicht von einem autonomen Fahrzeug stammen, das auf der schwarzen Liste steht. In anderen Fällen kann bei der Ermittlung der Vertrauenswürdigkeit des autonomen Fahrzeugs berücksichtigt werden, ob die Daten signiert sind oder nicht.
• Wenn die Authentifizierung und/oder Vertrauensüberprüfung beim Server nicht erfolgreich ist, kann der Vertrauenswert für das autonome Fahrzeug, von dem die Daten empfangen wurden, niedrig eingestuft oder herabgesetzt werden, und die Daten können ignoriert oder nicht zur Aktualisierung der HD-Karte verwendet werden. In einigen Fällen kann das autonome Fahrzeug auf eine schwarze Liste gesetzt werden, wenn sein Vertrauenswert unter einen bestimmten Schwellenwert fällt. Wenn die Authentifizierung und/oder Vertrauensüberprüfung beim Server erfolgreich ist, kann der Vertrauenswert für das autonome Fahrzeug erhöht werden und die vom autonomen Fahrzeug empfangenen Daten können zur Aktualisierung der HD-Karte verwendet werden. Die hier beschriebenen Mechanismen können auch die Transitivität des Vertrauens ermöglichen, so dass autonome Fahrzeuge Daten aus weiter entfernten Quellen (z. B. anderen autonomen Fahrzeugen) nutzen können, und sie können für die Einstufung von Crowdsourced-Daten verwendet werden, die für andere Zwecke benötigt werden (z. B. für das Training von Maschinelles-Lernen-Modellen).
• 26 ist ein Flussdiagramm eines Beispielprozesses zur Bewertung von Sensordaten eines autonomen Fahrzeugs gemäß mindestens einer Ausführungsform. Die Vorgänge in den Beispielprozessen in 26 können von verschiedenen Aspekten oder Komponenten eines autonomen Fahrzeugs durchgeführt werden. Die Beispielprozesse können zusätzliche oder andere Vorgänge umfassen, und die Vorgänge können in der gezeigten oder in einer anderen Reihenfolge durchgeführt werden. In manchen Fällen können eine oder mehrere der in 26 gezeigten Operationen als Prozesse implementiert werden, die mehrere Operationen, Unterprozesse oder andere Arten von Routinen umfassen. In einigen Fällen können Vorgänge kombiniert, in anderer Reihenfolge, parallel, iterativ oder auf andere Weise wiederholt oder durchgeführt werden.
• Bei 2602 werden Sensordaten von einem Sensor eines autonomen Fahrzeugs empfangen. Die Sensordaten können Daten von einem Kameragerät, einem LIDAR-Sensorgerät, einem Radargerät oder einer anderen Art von Sensorgerät für autonome Fahrzeuge umfassen.
• Bei 2604 wird ein Konfidenzwert für die Sensordaten ermittelt. Die Vertrauensbewertung kann auf Informationen beruhen, die aus den bei 2602 empfangenen Sensordaten oder anderen Sensordaten (z. B. Wetter- oder anderen Umgebungsinformationen), Informationen über den Authentifizierungsstatus des Sensorgeräts (z. B. ob das Sensorgerät vom autonomen Fahrzeug authentifiziert wurde, bevor seine Daten akzeptiert wurden), lokalen Sensorbestätigungsdaten oder anderen Informationen, die für die Entscheidung, ob den erhaltenen Sensordaten zu trauen ist, nützlich sein können (z. B. Sensorsensorfähigkeiten odereinstellungen des Geräts (z. B. Videobitrate der Kamera), Bitfehlerrate für empfangene Sensordaten usw.), gewonnen oder ermittelt wurden.
• Bei 2606 wird festgestellt, ob der Konfidenzwert über einem Schwellenwert liegt. Wenn dies der Fall ist, wird bei 2608 ein Delta-Wert zwischen den bei 2602 empfangenen Sensordaten und den HD-Kartendaten bestimmt, und wenn bei 2610 festgestellt wird, dass der Delta-Wert über einem Schwellenwert liegt, signiert das autonome Fahrzeug die Daten und veröffentlicht die Daten bei 2612 an den Server zur Aktualisierung der HD-Karte. Liegt der Konfidenzwert unter dem entsprechenden Schwellenwert oder der Deltawert unter dem entsprechenden Schwellenwert, werden die Daten nicht auf dem Server veröffentlicht, um die HD-Karte zu aktualisieren.
• 27 ist ein Flussdiagramm eines Beispielprozesses zur Bewertung von Sensordaten eines autonomen Fahrzeugs gemäß mindestens einer Ausführungsform. Die Vorgänge in den Beispielprozessen in 27 können von verschiedenen Aspekten oder Komponenten eines Servergeräts durchgeführt werden, beispielsweise von einem Server, der eine HD-Karte für autonome Fahrzeuge verwaltet, oder von einer oder mehreren Komponenten eines autonomen Fahrzeugs. Die Beispielprozesse können zusätzliche oder andere Vorgänge umfassen, und die Vorgänge können in der gezeigten oder in einer anderen Reihenfolge durchgeführt werden. In manchen Fällen können eine oder mehrere der in 27 gezeigten Operationen als Prozesse implementiert werden, die mehrere Operationen, Unterprozesse oder andere Arten von Routinen umfassen. In einigen Fällen können Vorgänge kombiniert, in anderer Reihenfolge, parallel, iterativ oder auf andere Weise wiederholt oder durchgeführt werden.
• Um 2702 werden Sensordaten von einem autonomen Fahrzeug empfangen. Die Sensordaten können einen mit den Sensordaten verknüpften Vertrauenswert umfassen, der den Grad des Vertrauens in die von der Sensorvorrichtung erfassten Daten angibt. Der Konfidenzwert kann nach dem oben beschriebenen Verfahren 2600 berechnet werden. In einigen Fällen kann der Konfidenzwert in die Metadaten aufgenommen werden.
• Bei 2704 wird der Konfidenzwert mit einem Schwellenwert verglichen. Wenn der Vertrauenswert größer als der Schwellenwert ist, wird ein Vertrauenswert für das autonome Fahrzeug auf der Grundlage des Vertrauenswertes bei 2706 aktualisiert. Wenn nicht, werden die Sensordaten bei 2712 ignoriert.
• Bei 2708 wird bestimmt, ob das autonome Fahrzeug zumindest teilweise auf der Grundlage der Vertrauensbewertung vertrauenswürdig ist. In einigen Fällen kann die Feststellung, ob das autonome Fahrzeug vertrauenswürdig ist, darauf basieren, ob das autonome Fahrzeug auf eine schwarze Liste gesetzt wurde (z. B. wie oben beschrieben). In einigen Fällen kann die Feststellung, ob das autonome Fahrzeug vertrauenswürdig ist, auf einer Korrelation der Sensordaten des autonomen Fahrzeugs mit Sensordaten von anderen autonomen Fahrzeugen in der Nähe basieren (z. B. um zu überprüfen, ob die Sensordaten genau sind). Wenn das autonome Fahrzeug vertrauenswürdig ist, können die Sensordaten zur Aktualisierung der HD-Karte bei 2710 verwendet werden. Wenn nicht, werden die Sensordaten bei 2712 ignoriert. Alternativ kann der auf der Vertrauensbewertung basierende Vertrauensgrad verwendet werden, um den Vertrauensgrad des autonomen Fahrzeugs in die Sensordaten zu bestimmen und somit die HD-Karte auf der Grundlage eines Bereichs oder einer Skala entsprechend zu aktualisieren.
• Wie hier erörtert, können Crowdsourcing-Datensammlungen darin bestehen, Datensätze mit Hilfe einer großen Gruppe autonomer Fahrzeuge zu erstellen. Es gibt Quellen und Datenlieferanten, die bereit sind, die Daten mit relevanten, fehlenden oder neuen Informationen anzureichern.
• Die Erfassung von Daten aus einer großen Gruppe autonomer Fahrzeuge kann die Datenerfassung beschleunigen, was wiederum zu einer schnelleren Modellbildung für autonome Fahrzeuge führt. Beim Crowdsourcing von Daten kann ein Teil der Daten unvollständig oder ungenau sein, und selbst wenn die Daten vollständig und genau sind, kann es schwierig sein, eine so große Menge an Daten zu verwalten. Darüber hinaus stellen Crowdsourced-Daten in der Praxis eine Herausforderung dar, da es keine ausgewogenen positiven und negativen Kategorien gibt und die verschiedenen Sensoren der verschiedenen autonomen Fahrzeuge unterschiedliche Lärmpegel verursachen. Daher kann es von Vorteil sein, die durch Crowdsourcing gesammelten Daten zu bewerten und in eine Rangfolge zu bringen, um ihre Güte zu ermitteln.
• Dementsprechend können in einigen Aspekten Crowdsourced-Daten auf der Grundlage von Geolokalisierungsinformationen für das autonome Fahrzeug bewertet und eingestuft werden. In einigen Aspekten können die Crowdsourced-Daten bewertet und eingestuft werden, indem zusätzlich zu den Fahrzeug-Metadaten auch Standort-Metadaten berücksichtigt werden. Durch die Verwendung von Geolokalisierungsinformationen zur Bewertung und Einstufung von Daten können standortspezifische Modelle im Gegensatz zu fahrzeugspezifischen Modellen erstellt werden.
• 28 ist ein vereinfachtes Diagramm einer Beispielumgebung 2800 für autonome Fahrzeugdatenerfassung in Übereinstimmung mit mindestens einer Ausführungsform. Die Beispielumgebung 2800 umfasst einen Server 2802 für die Datenbewertung autonomer Fahrzeuge, einen Crowdsourced-Datenspeicher 2806 und mehrere autonome Fahrzeuge 2810, die jeweils über das Netzwerk 2808 miteinander verbunden sind. Obwohl nicht dargestellt, umfasst jedes der autonomen Fahrzeuge 2810 einen oder mehrere Sensoren, die von dem autonomen Fahrzeug verwendet werden, um das autonome Fahrzeug zu steuern und Fahrten des autonomen Fahrzeugs zwischen Orten zu vermitteln. Wie weiter beschrieben, kann die Beispielumgebung 2800 zur Crowdsourcing-Datenerfassung von jedem der autonomen Fahrzeuge 2810 verwendet werden. Insbesondere sammelt jedes der autonomen Fahrzeuge 2810 während der Fahrt Sensordaten von jedem einer Mehrzahl von Sensoren, die mit dem autonomen Fahrzeug gekoppelt sind, wie z. B. Kameradaten, LIDAR-Daten, Geolokalisierungsdaten, Temperatur- oder andere Wetterdaten. In einigen Fällen kann das autonome Fahrzeug seine Sensordaten über das Netzwerk 2808 an den Server 2802 für die Datenauswertung des autonomen Fahrzeugs übertragen. Der Server 2802 für die Bewertung der Daten des autonomen Fahrzeugs kann seinerseits die Daten wie hier beschrieben bewerten oder einstufen und auf der Grundlage der Bewertung/Einstufung entscheiden, ob die Daten im Crowdsourced Data Store 2806 gespeichert werden sollen.
• In einigen Fällen umfassen die von den autonomen Fahrzeugen gesendeten Daten Bilddaten und Sensordaten und können auch einige zugehörige Metadaten umfassen. Beide Datenquellen können zusammen oder einzeln verwendet werden, um ortsbezogene Metadaten/Tags zu extrahieren und zu erzeugen. Bei den kumulativen ortsspezifischen Metadaten kann es sich zum Beispiel um Informationen wie geografische Koordinaten handeln: „45° 31' 22,4256“ N und 122° 59' 23,3880" W". Es kann sich auch um zusätzliche Umgebungsinformationen handeln, die Umgebungskontexte angeben, wie z. B. Geländeinformationen (z. B. „hügelig“ oder „flach“), Höheninformationen (z. B. „59,1 m“), Temperaturinformationen (z. B. „20° C“) oder Wetterinformationen, die mit diesem Ort verbunden sind (z. B. „sonnig“, „neblig“ oder „Schnee“). Alle ortsspezifischen und zugehörigen Metadaten (z. B. Wetterdaten) können zur Bewertung der vom autonomen Fahrzeug gesendeten Daten verwendet werden, um zu entscheiden, ob die Daten in einem Crowdsourced Data Store gespeichert werden sollen. In einigen Fällen kann der Algorithmus für die Datenauswertung eine Sättigung für die Geografie in Bezug auf die Datenerfassung erreichen, indem er eine Kaskade von standortkontextbasierten Heatmaps oder Dichtekarten für die Auswertung der Daten verwendet, wie weiter unten beschrieben.
• Gibt es beispielsweise eine Reihe von Standort-Metadatenkategorien wie geografische Koordinaten, Höhenlage, Wetter usw., so kann eine Gesamtbewertung der Sensordaten des autonomen Fahrzeugs anhand einer Standortbewertung vorgenommen werden. Die Standortbewertung kann eine gewichtete Summierung aller Kategorien sein und kann durch beschrieben werden: $$Bewertun{g}_{Standort}={\displaystyle \sum \left(\alpha .GeoKoordinaten+\beta .H\ddot{o}he+\gamma .Wetter+\cdots \right)}$$

  

  wobei jede der Variablen GeoKoordinaten, Höhe und Wetter Werte sind, die aus einer Heatmap, irgendeiner Art von Dichteplot oder irgendeiner Art von Dichteverteilungskarte (z. B. der Heatmap 3000 von 30) bestimmt werden und α, β, γ sind Gewichte (die jeweils auf der Grundlage einer separaten Dichtekurve berechnet werden können), die mit jeder Kategorie von Standortmetadaten verbunden sind. In einigen Fällen liegt jede der Variablen der Standortbewertung zwischen 0 und 1, und die Standortbewertung liegt ebenfalls zwischen 0 und 1.
• Nach der Berechnung der Standortbewertung können zusätzliche Qualitäten, die mit den Sensordaten verbunden sind (z. B. Rauschpegel, interessante Objekte in den Bilddaten usw.), verwendet werden, um eine Gesamtgütebewertung für die Sensordaten zu ermitteln. In einigen Fällen ist die Gesamtgüte der Sensordaten eine kumulative gewichtete Summe aller Datenqualitäten und kann durch beschrieben werden: $$\begin{array}{l}Bewertun{g}_{G\ddot{u}te}\\ ={\displaystyle \sum (a.Bewertun{g}_{Standort}+b.Bewertun{g}_{Rauschen}}\\ +c.Bewertun{g}_{ObjektDiversit\ddot{a}t}+\cdots )\end{array}$$

  

  wobei a, b, c die mit den Datenqualitätskategorien verbundenen Gewichte sind. In einigen Fällen liegen die einzelnen Variablen der Gesamtgütebewertung zwischen 0 und 1, und die Gesamtgütebewertung liegt ebenfalls zwischen 0 und 1. Die vom Algorithmus zur Bewertung der Daten des autonomen Fahrzeugs ausgegebene Gesamtbewertung der Güte (z. B. durch ein externes Datenspeichersystem oder ein anderes Rechensystem, das ein Datenbewertungssystem implementiert) kann mit den Sensordaten des autonomen Fahrzeugs verknüpft und verwendet werden, um zu bestimmen, ob die Daten des autonomen Fahrzeugs an den Crowdsourcing-Datenspeicher weitergeleitet werden sollen.
• In einigen Implementierungen umfasst ein Beispiel für einen Server 2802 zur Bewertung von Daten autonomer Fahrzeuge einen Prozessor 2803 und einen Speicher 2804. Der Beispielprozessor 2803 führt beispielsweise Anweisungen aus, um eine oder mehrere der hier beschriebenen Funktionen auszuführen. Die Anweisungen können Programme, Codes, Skripte oder andere Arten von im Speicher abgelegten Daten umfassen. Zusätzlich oder alternativ können die Anweisungen als vorprogrammierte oder umprogrammierbare Logikschaltungen, Logikgatter oder andere Arten von Hardware- oder Firmware-Komponenten codiert werden. Der Prozessor 2803 kann ein Allzweck-Mikroprozessor, ein spezialisierter Koprozessor oder eine andere Art von Datenverarbeitungsgerät sein oder umfassen. In einigen Fällen kann der Prozessor 2803 so ausgebildet sein, dass er Software, Skripte, Programme, Funktionen, ausführbare Dateien oder andere im Speicher 2804 gespeicherte Anweisungen ausführt oder interpretiert. In einigen Fällen umfasst der Prozessor 2803 mehrere Prozessoren oder Datenverarbeitungsgeräte. Der Beispielspeicher 2804 umfasst ein oder mehrere computerlesbare Medien. Der Speicher 2804 kann beispielsweise ein flüchtiges oder ein nichtflüchtiges Speichermedium oder eine Kombination davon sein. Der Speicher 2804 kann einen oder mehrere Festwertspeicher, Direktzugriffsspeicher, Pufferspeicher oder eine Kombination aus diesen und anderen Speicherarten umfassen. Der Speicher 2804 kann Anweisungen (z. B. Programme, Codes, Skripte oder andere Arten von ausführbaren Anweisungen) speichern, die vom Prozessor 2803 ausgeführt werden können. Obwohl nicht dargestellt, kann jedes der autonomen Fahrzeuge 2810 einen Prozessor und einen Speicher ähnlich dem Prozessor 2803 und dem Speicher 2804 umfassen.
• 29 ist ein vereinfachtes Blockdiagramm einer beispielhaften Crowdsourced-Datenerfassungsumgebung 2900 für autonome Fahrzeuge gemäß mindestens einer Ausführungsform. Die Beispielumgebung 2900 umfasst ein autonomes Fahrzeug 2902, einen Server 2904 für die Bewertung der Daten des autonomen Fahrzeugs in der Cloud und einen Crowdsourced-Datenspeicher 2906. Im gezeigten Beispiel verfügt das autonome Fahrzeug über einen eigenen Speicher für seine Sensordaten und ein KI-System, das zur Navigation des autonomen Fahrzeugs auf der Grundlage der Sensordaten verwendet wird. Das autonome Fahrzeug sendet alle oder einige seiner Sensordaten an den Server für die Bewertung und Einstufung der Daten des autonomen Fahrzeugs, der die mit den Daten verbundenen Metadaten extrahiert und speichert. Der Server analysiert auch die Bild- und Sensordaten des autonomen Fahrzeugs, um zusätzliche Informationen/Metadaten zu extrahieren, und speichert diese Informationen. Die gespeicherten Metadaten werden dann von einem Bewertungsmodul des Servers verwendet, um eine standortbezogene Bewertung (z. B. die oben beschriebene Standortbewertung) und eine Datenqualitätsbewertung (z. B. die oben beschriebene Gesamtbewertung der Güte) zu berechnen. Anhand dieser Bewertungen entscheidet der Server, ob die Sensordaten des autonomen Fahrzeugs an den Crowdsourced Data Storage weitergeleitet werden sollen.
• In einigen Fällen kann der Server auch einen Vehicle Dependability Score (Fahrzeugzuverlässigkeitsbewertung) berechnen, der dem autonomen Fahrzeug zugeordnet werden soll. Diese Bewertung kann auf historischen Standortbewertungen, Gütebewertungen oder anderen Informationen basieren und kann eine Metrik sein, die vom Crowdsource-Governance-System als Kontext für die Bereitstellung der Identität des autonomen Fahrzeugs für zukünftige Datenbewertungen/Ranglisten verwendet wird. Der Vehicle Dependability Score kann auch als Anreiz für die Beteiligung des autonomen Fahrzeugs an der Bereitstellung seiner Daten in der Zukunft verwendet werden.
• 30 ist ein vereinfachtes Diagramm einer beispielhaften Heatmap 3000 zur Verwendung bei der Berechnung einer Sensordatengütebewertung gemäß mindestens einer Ausführungsform. Im gezeigten Beispiel zeigt die Heatmap die Verfügbarkeit von Crowdsourced-Daten anhand von Metadaten mit geografischen Koordinaten an. Jede Position in der Heatmap zeigt einen Wert an, der mit der Datenverfügbarkeit verbunden ist. In dem gezeigten Beispiel reichen die Werte von 0-1. Die helleren Bereiche auf der Karte weisen auf die geringste verfügbare Datenmenge an diesen Orten hin, während die dunkleren Bereiche ein Gebiet mit einer hohen Dichte an gesammelten Daten anzeigen. Der Grund für die unterschiedliche Dichte der erfassten Daten könnte einer oder mehrere der folgenden Faktoren sein: Bevölkerungsdichte, industrielle Entwicklung, geografische Bedingungen usw. Das Ziel des Algorithmus zur Datenauswertung kann also darin bestehen, die Daten so auszuwerten, dass in den geografischen Koordinaten der helleren Bereiche der Heatmap genügend Daten gesammelt werden. Da die gesammelten Daten in den leichteren Regionen spärlich sind, werden sie nachsichtig bewertet. Werden hingegen Daten aus dem dunkleren Bereich der Karte gesammelt, der eine hohe Datendichte aufweist, haben Faktoren wie das Rauschen in den Daten einen größeren Einfluss auf die Datenbewertung.
• Für jede Variable/jeden Faktor der Standortbewertung kann eine eigene Heatmap erstellt werden. Bezogen auf die obige Standortbewertung würde beispielsweise der Variablen GeoKoordinaten eine erste Heatmap zugeordnet, der Variablen Höhe eine zweite Heatmap und der Variablen Wetter eine dritte Heatmap. Jede der Heatmaps kann unterschiedliche Werte umfassen, da die Menge der für jede der Variablen gesammelten Daten je nach Standort variieren kann. Die Werte der verschiedenen Heatmaps können in die Berechnung der Standortbewertung einfließen, z. B. durch eine gewichtete Summierung wie oben beschrieben.
• 31 ist ein Flussdiagramm eines Beispielprozesses 3100 zur Berechnung einer Gütebewertung für Sensordaten autonomer Fahrzeuge in Übereinstimmung mit mindestens einer Ausführungsform. Die Vorgänge im Beispielprozess 3100 können von Komponenten eines Servers 2802 für die Datenauswertung von autonomen Fahrzeugen (z. B. dem Server von 28), oder mitdemselben Verbundenen, ausgeführt werden. Der Beispielprozess 3100 kann zusätzliche oder andere Vorgänge umfassen, und die Vorgänge können in der gezeigten oder einer anderen Reihenfolge durchgeführt werden. In manchen Fällen können eine oder mehrere der in 3100 gezeigten Operationen als Prozesse implementiert werden, die mehrere Operationen, Unterprozesse oder andere Arten von Routinen umfassen. In einigen Fällen können Vorgänge kombiniert, in anderer Reihenfolge, parallel, iterativ oder auf andere Weise wiederholt oder durchgeführt werden.
• Um 3102 werden Sensordaten von einem oder mehreren autonomen Fahrzeugen empfangen. Die Sensordaten können eine oder mehrere Video- oder Bilddaten (z. B. von Kameras) und Punktdatenwerte (z. B. Temperatur, Luftdruck usw.) umfassen.
• Bei 3104 werden Geolokalisierungs- und andere Umgebungsinformationen aus den Sensordaten gewonnen.
• Bei 3106 wird eine Bewertung für die Sensordaten berechnet, die ihre Gesamtgüte oder Qualität angibt. Die Bewertung basiert auf den bei 3104 erhaltenen Geolokalisierungs- und Umweltinformationen. Die Bewertung kann beispielsweise auf einer Standortbewertung basieren, die wie oben beschrieben aus den Geolokalisierungs- und Umgebungsinformationen berechnet wird. In einigen Fällen kann die Bewertung auch auf zusätzlichen Informationen beruhen, die mit den Sensordaten verknüpft sind. Die Bewertung kann z. B. auf einer Rauschbewertung, einer Bewertung der Objektvielfalt oder anderen für die Sensordaten berechneten Bewertungen basieren.
• Bei 3108 wird bestimmt, ob die bei 3106 berechnete Bewertung über einem Schwellenwert oder innerhalb eines Wertebereichs liegt. Ist dies der Fall, werden die Sensordaten bei 3110 in einer Datenbank gespeichert, die für die Sammlung von Sensordaten autonomer Fahrzeuge aus der Bevölkerung verwendet wird. Bei der Speicherung können die Sensordaten mit dem berechneten Gütewert verknüpft werden. Liegt der Wert unter dem Schwellenwert oder außerhalb eines Wertebereichs, werden die Sensordaten verworfen oder nicht gespeichert (3109).
• Es ist davon auszugehen, dass autonome Fahrzeuge auch weiterhin die Straße mit von Menschen gesteuerten Fahrzeugen teilen werden, die möglicherweise ein unregelmäßiges Verhalten an den Tag legen, das nicht den dokumentierten Fahrpraktiken entspricht. Menschliche Fahrer können sich aggressiv verhalten (z. B. dicht auffahren oder sich durch den Verkehr schlängeln) oder ängstlich (z. B. deutlich langsamer fahren als die vorgeschriebene Höchstgeschwindigkeit, was ebenfalls zu Unfällen führen kann). Unregelmäßiges menschliches Fahrverhalten kann in manchen Fällen auch aus den Fahrgewohnheiten in bestimmten Regionen resultieren. Ein in West-Pennsylvania beobachtetes Manöver, das manchmal als „Pittsburgh Left“ bezeichnet wird, verstößt beispielsweise gegen die Standardvorrangregeln für Fahrzeuge an einer Kreuzung, indem es dem ersten links abbiegenden Fahrzeug den Vorrang vor Fahrzeugen einräumt, die geradeaus durch eine Kreuzung fahren (z. B. nachdem eine Ampel für beide Richtungen auf Grün umschaltet). Ein weiteres Beispiel ist, dass Fahrer in bestimmten Regionen des Landes mehr oder weniger aggressiv fahren können als Fahrer in anderen Regionen des Landes.
• Das autonome Fahrsystem, das durch das bordeigene Rechensystem eines autonomen Fahrzeugs implementiert wird, kann so verbessert werden, dass es das unregelmäßige Verhalten von HVs erlernt und erkennt und sicher darauf reagiert. In einigen Aspekten kann ein autonomes Fahrzeugsystem beispielsweise die Häufigkeit von unregelmäßigen Verhaltensweisen (z. B. die in der nachstehenden Tabelle aufgeführten) beobachten und verfolgen und lernen, vorherzusagen, dass ein einzelner HV in naher Zukunft wahrscheinlich ein unregelmäßiges Verhalten an den Tag legen wird oder dass eine bestimmte Art von unregelmäßigem Verhalten in einer bestimmten Region des Landes eher auftreten wird.

  Häufigkeit von unregelmäßigem Verhalten	Beispiele
  Einmaliger Vorfall durch einen einzelnen Fahrer	Ein menschlicher Fahrer versucht, die Spur zu wechseln, wenn sich das autonome Fahrzeug im toten Winkel befindet.
  Wiederholte Vorfälle durch denselben Fahrer	Betrunkene, übermüdete oder rasende Fahrer, die wiederholt ein unsicheres Fahrverhalten an den Tag legen.
  Gemeinsames standortspezifisches Verhalten	In bestimmten Städten neigen Autofahrer dazu, aggressiv zu fahren und bei kleinen seitlichen Lücken zwischen den Fahrzeugen zuzuschneiden.

• In einigen Ausführungsformen können unregelmäßige Fahrmuster als eine Abfolge von Fahraktionen modelliert werden, die von dem normalen, vom autonomen Fahrzeug erwarteten Verhalten abweichen. 32 und 33 zeigen zwei Beispiele für unregelmäßige Fahrmuster und wie ein autonomes Fahrzeug lernen kann, sein Verhalten anzupassen, wenn es solche Verhaltensweisen beobachtet.
• 32 veranschaulicht ein Beispielszenario „Pittsburgh Left“ wie oben beschrieben. Im gezeigten Beispiel halten ein HV 3202 und ein autonomes Fahrzeug 3204 beide an der Kreuzung 3206, wenn die Ampel 3208 auf Grün schaltet. In einem typischen Szenario hätte das autonome Fahrzeug Vorrang, um vor dem HV über die Kreuzung zu fahren. Im gezeigten Pittsburgh-Links-Szenario biegt der HV jedoch zuerst nach links ab, anstatt dem autonomen Fahrzeug, das gerade über die Kreuzung fährt, den Vortritt zu lassen. Durch die mehrfache Beobachtung dieses Verhaltens in einer geografischen Region kann das autonome Fahrzeug lernen, ein solches Verhalten zu antizipieren (wobei das erste links abbiegende Fahrzeug Vorrang hat), so dass es vorsichtiger in die Kreuzung einfährt, wenn es sich in der geografischen Region befindet.
• 33 veranschaulicht ein Beispielszenario für „Verkehrsrowdytum“ durch einen HV. Im gezeigten Beispiel könnte der Fahrer des Lkw wütend auf das autonome Fahrzeug sein und dementsprechend vor dem autonomen Fahrzeug fahren und abrupt abbremsen. Daraufhin kann das autonome Fahrzeug langsamer werden und die Spur wechseln, um dem HV auszuweichen. Der HV kann dann weiter beschleunigen und wieder vor dem autonomen Fahrzeug schneiden, um dann wieder abrupt abzubremsen. Da der HV dieses Manöver schon mehrfach gesehen hat, kann das autonome Fahrzeug erkennen, dass es sich bei dem HV um einen verärgerten Fahrer handelt, der wiederholt vor dem autonomen Fahrzeug fährt. Das autonome Fahrzeug kann dementsprechend eine Korrekturmaßnahme ergreifen, wie z. B. die Rückgabe der Kontrolle an den menschlichen Fahrer, wenn es das nächste Mal auf den betreffenden HV trifft.
• 34 ist ein vereinfachtes Blockdiagramm, das ein Modell zur Verfolgung von unregelmäßigem/anormalem Verhalten 3400 für ein autonomes Fahrzeug gemäß mindestens einer Ausführungsform zeigt. Im gezeigten Beispiel empfängt die Erfassungsphase 3410 des Software-Stacks für autonome Fahrzeuge Sensordaten von den Sensoren 3402 des autonomen Fahrzeugs und verwendet die Sensordaten, um anomales Verhalten, das von einem bestimmten HV beobachtet wird, zu erkennen/identifizieren (z. B. in einem Softwaremodul 3404 zur Erkennung anomalen Verhaltens, wie gezeigt). ansprechend auf die Erkennung anomalen Verhaltens oder parallel zur Erkennung wird eine anonyme Identität für den HV erstellt (z. B. in einem Softwaremodul 3406 zur Erstellung einer anonymen Identität, wie gezeigt). Das beobachtete Verhalten und die zugehörige Identität des HV werden dann verwendet, um die Häufigkeit des beobachteten Verhaltens durch das HV und andere HVs in der Umgebung des autonomen Fahrzeugs zu verfolgen (z. B. in einem Softwaremodul 3408 zur Verfolgung unsicheren Verhaltens, wie gezeigt). In einigen Fällen kann das verfolgte Verhalten von einer Planungsphase 3420 des Software-Stacks für autonome Fahrzeuge verwendet werden, um dynamische Verhaltensrichtlinien für das autonome Fahrzeug auszulösen, wenn anormale Verhaltensmuster in den HVs erkannt werden. Einige Aspekte des Modells 3400 werden weiter unten beschrieben.
• In einigen Ausführungsformen kann das autonome Fahrzeug ein anormales oder unregelmäßiges Verhalten eines bestimmten HV erkennen, indem es Sequenzen von Fahraktionen verfolgt, die zum Beispiel:
• ◯ Das Sicherheitsmodell des autonomen Fahrzeugs verletzen (z. B. Fahrer, die keinen sicheren Seitenabstand gemäß einem verantwortungsbewussten Sicherheitsregelwerk einhalten).
• ◯ Fahrer, deren Fahrverhalten deutlich von dem anderer Fahrer in der Umgebung abweicht (z. B. Fahrer, die deutlich langsamer oder schneller fahren als andere Fahrer, oder Fahrer, die durch den Verkehr schlängeln). Studien haben gezeigt, dass Fahrer, deren Geschwindigkeit deutlich von der des umgebenden Verkehrs abweicht, die Wahrscheinlichkeit von Unfällen erhöhen können.
• ◯ Fahrer, deren Verhalten andere Fahrer zu einer negativen Reaktion veranlasst (z. B. ein Fahrer, der von mehreren Fahrern gemieden wird, oder ein Fahrer, der von mehreren Fahrern angehupt wird).
• Zusätzlich zur Verfolgung von Sequenzen von Fahraktionen kann das autonome Fahrzeug in einigen Ausführungsformen auch Audio- und visuelle Kontextinformationen verwenden, um Fahrertypen (z. B. einen abgelenkten Fahrer im Vergleich zu einem sicheren Fahrer, der einen sicheren Abstand zu anderen Fahrzeugen einhält), Fahrereigenschaften (z. B. Aufmerksamkeit auf die Straße richten vs. auf das Telefon schauen) oder Fahrzeugattribute (z. B. fehlende Spiegel, kaputte Windschutzscheiben oder andere Merkmale, die das Fahrzeug verkehrsuntauglich machen würden), die in naher Zukunft eher zu unsicherem Verhalten führen könnten. So können beispielsweise Videobilder von nach außen gerichteten Kameras des autonomen Fahrzeugs verwendet werden, um Computer-Vision-Modelle zu trainieren, die Fahrzeug- oder Fahrereigenschaften erkennen, die das Unfallrisiko erhöhen, wie z. B. ein menschlicher Fahrer, der mit seinem Handy telefoniert, oder eingeschränkte Sicht aufgrund schneebedeckter Fenster. Die Computer-Vision-Modelle können in bestimmten Fällen durch akustische Modelle ergänzt werden, die aggressives Verhalten wie aggressives Hupen, Schreien oder unsichere Situationen wie quietschende Bremsen erkennen können. In der nachstehenden Tabelle sind einige Beispiele für akustische und visuelle Kontextinformationen aufgeführt, die auf eine erhöhte Wahrscheinlichkeit für künftiges unsicheres Verhalten hinweisen können.

  Art des unsicheren Verhaltens	Audiovisueller Kontext
  Verärgerter Fahrer	- Aggressiv blinkende Scheinwerfer
  	- Erhobene Fäuste
  	- Aggressives Hupen
  	- Fahrer schreit
  	- Wütender Fahrer (z. B. wütender Gesichtsausdruck, erhobene Fäuste)
  Abgelenkter Fahrer	- Fahrer am Mobiltelefon
  	- Fahrer, der wiederholt den Blick von der Straße nimmt
  	- Fahrer nimmt die Hände vom Steuer
  Verdunkelte Sicht	- Fahrzeug mit eingeschränkter Sicht durch schneebedeckte Scheiben
  	- Fehlende Seitenspiegel oder Rückspiegel
  	- Nicht funktionierende Scheinwerfer
  Probleme beim Bremsen	- Übermäßige Bremsgeräusche
  	- Abblätternde Reifen

• In einigen Ausführungsformen kann das autonome Fahrzeug die Häufigkeit des beobachteten irregulären Verhaltens bestimmter Fahrzeuge (z. B. HVs) verfolgen, um festzustellen, ob es sich um einen einzelnen Fahrer handelt, der dasselbe Verhalten in einem bestimmten Zeitfenster an den Tag legt (was auf einen unsicheren Fahrer hindeuten kann), oder ob es mehrere Fahrer an einem bestimmten Ort gibt, die dasselbe Verhalten an den Tag legen (was auf eine soziale Norm für den Ort hindeuten kann).
• Um die Privatsphäre der menschlichen Fahrer zu schützen, kann das autonome Fahrzeug eine anonyme Identität für das unsichere HV erstellen und diese Identität mit dem unsicheren Verhalten verknüpfen, um eine Wiederholung durch das HV oder andere HVs zu verfolgen. Die anonyme Identität kann erstellt werden, ohne sich auf die Nummernschilderkennung zu verlassen, die nicht immer verfügbar oder zuverlässig ist. Die anonyme Signatur kann in einigen Ausführungsformen durch Extraktion repräsentativer Merkmale aus dem Deep-Learning-Modell erstellt werden, das für die Erkennung von Autos verwendet wird. Beispielsweise können bestimmte Schichten des Deep-Learning-Netzwerks des autonomen Fahrzeugs Merkmale des Fahrzeugs wie seine Form und Farbe erfassen. Diese Merkmale können auch durch zusätzliche Attribute ergänzt werden, die wir über das Fahrzeug erkennen, wie z. B. die Marke, das Modell oder ungewöhnliche Merkmale wie Beulen, Kratzer, kaputte Windschutzscheibe, fehlende Seitenspiegel usw. Auf die kombinierten Merkmale kann dann ein kryptografischer Hash angewandt werden, der während der aktuellen Fahrt des autonomen Fahrzeugs als Kennung für den HV verwendet werden kann. In manchen Fällen ist diese Signatur nicht völlig eindeutig für das Fahrzeug (z. B. wenn es ähnlich aussehende Fahrzeuge in der Umgebung des autonomen Fahrzeugs gibt); sie kann jedoch für das autonome Fahrzeug ausreichend sein, um das unsichere Fahrzeug für die Dauer einer Fahrt zu identifizieren. Die Nummernschilderkennung kann in bestimmten Fällen eingesetzt werden, etwa wenn das autonome Fahrzeug die Behörden vor einem gefährlichen Fahrzeug warnen muss.
• Das autonome Fahrzeug kann feststellen, dass das unsichere Verhalten eskaliert, indem es z. B. überwacht, ob die Dauer zwischen unsicheren Ereignissen abnimmt oder ob der Schweregrad der unsicheren Aktion zunimmt. Diese Informationen können dann in die Planungsphase der AD-Pipeline eingespeist werden, um eine dynamische Strategie auszulösen, z. B. das unsichere Fahrzeug zu meiden, wenn das autonome Fahrzeug ihm wieder begegnet, oder die Behörden zu alarmieren, wenn das unsichere Verhalten andere Autofahrer auf der Straße gefährdet. Das autonome Fahrzeug kann auch eine Aufbewahrungsrichtlinie für die Verfolgung des unsicheren Verhaltens für ein bestimmtes Fahrzeug festlegen. Eine Aufbewahrungsrichtlinie kann beispielsweise vorsehen, dass ein autonomes Fahrzeug Informationen über einen unsicheren Fahrer nur für die Dauer der Fahrt, für eine bestimmte Anzahl von Fahrten, für eine bestimmte Zeitspanne usw. speichert.
• In einigen Ausführungsformen kann das autonome Fahrzeug Daten über das von ihm festgestellte anormale Verhalten an die Cloud übermitteln, und zwar auf der Basis des einzelnen Fahrzeugs. Diese Daten können genutzt werden, um Muster für menschlich bedingtes irreguläres Verhalten zu erkennen und festzustellen, ob solche Verhaltensweisen in einem bestimmten Kontext wahrscheinlicher sind. So kann man z. B. lernen, dass Fahrer in einer bestimmten Stadt eher in den Verkehr einfahren, wenn der seitliche Abstand zwischen den Fahrzeugen größer als ein bestimmter Abstand ist, dass Fahrer an bestimmten Kreuzungen eher zu Rollstopps neigen oder dass Fahrer, die mit dem Handy telefonieren, eher von ihrer Fahrspur abweichen. Die vom autonomen Fahrzeug an die Cloud übertragenen Daten können z. B. umfassen:
• ◯ Flugbahnen des unsicheren Fahrzeugs, der benachbarten Fahrzeuge und des autonomen Fahrzeugs
• ◯ fahrer- und Fahrzeugmerkmale bei unsicherem Fahrzeug, z. B. Fahrer telefoniert, Sichtbehinderung durch schneebedeckte Scheiben
• ◯ geografischer Standort, Wetterbedingungen, Verkehrszeichen und Ampeldaten
• ◯ Art der unsicheren Aktion - kann entweder als bekannte Aktion, wie z. B. abruptes Anhalten, das gegen das Sicherheitsmodell des autonomen Fahrzeugs verstößt, oder als unbekanntes anormales Verhalten, das vom System erkannt wird, gekennzeichnet werden
• In einigen Ausführungsformen kann das Lernen der kontextbasierten Muster des von Menschen gesteuerten irregulären Verhaltens das Clustern der zeitlichen Sequenzen von Fahraktionen umfassen, die mit unsicherem Verhalten assoziiert sind, unter Verwendung von Techniken wie beispielsweise Longest Common Subsequences (LCS; längste gemeinsame Teilsequenzen). Durch Clustering kann die Dimensionalität der Art reduziert und eine repräsentative Abfolge von Fahraktionen für jedes unsichere Verhalten ermittelt werden. Die nachstehende Tabelle umfasst Beispiele für bestimmte zeitliche Abfolgen, die geclustert werden können.

  ID	Sequenz
  1	Ampel schaltet auf Rot -> Autonomes Fahrzeug (AV) kommt an der Kreuzung an -> Von Menschen gesteuertes Fahrzeug (HV) kommt an der Kreuzung an -> Ampel schaltet auf Grün -> HV biegt nach links ab, anstatt dem AV auszuweichen, das geradeaus fährt.
  2	Die Ampel schaltet auf Rot -> der HV kommt an der Kreuzung an -> der AV kommt an der Kreuzung an -> die Ampel schaltet auf Grün -> der HV biegt nach links ab, anstatt dem AV, der geradeaus fährt, Vorfahrt zu gewähren.

• Außerdem können in einigen Ausführungsformen Fahrmuster gelernt werden, die in einem bestimmten Kontext mit größerer Wahrscheinlichkeit auftreten. Anhand der aufgezeichneten Sequenzen lässt sich beispielsweise feststellen, ob ein bestimmtes unregelmäßiges Fahrverhalten in einer bestimmten Stadt bei Schneefall häufiger auftritt oder ob bestimmte Fahrmanöver eher bei verärgerten Fahrern vorkommen. Diese Informationen können zur Modellierung der bedingten Wahrscheinlichkeitsverteilungen von Fahrmustern in einem bestimmten Kontext verwendet werden. Diese kontextbasierten Modelle ermöglichen es dem autonomen Fahrzeug, die wahrscheinliche Abfolge von Aktionen zu antizipieren, die ein unsicheres Fahrzeug in einem bestimmten Szenario ausführen könnte. Ein kontextbezogenes Diagramm, das aufzeigt, wie oft ein Fahrmuster in einem bestimmten Kontext auftritt, ist beispielsweise in 35 dargestellt. Wie gezeigt, kann der kontextbezogene Graph die identifizierten Sequenzen („Fahrmuster“-Knoten in 35) zusammen mit Kontextinformationen („Kontext“-Knoten in 35) und die damit verbundene Häufigkeit der Beobachtung der Sequenzen und des Kontexts (die Gewichte der Kanten in 35) nachverfolgen, um festzustellen, ob es bestimmte Verhaltensmuster gibt, die in bestimmten Kontexten häufiger vorkommen als in anderen (z. B. Muster, die in bestimmten geografischen Kontexten, zeitlichen Kontexten usw. übermäßig häufig auftreten). Die identifizierten Muster können auch zum Trainieren von Verstärkungslernmodellen verwendet werden, die die Maßnahmen identifizieren, die das autonome Fahrzeug ergreifen sollte, um das unsichere Verhalten zu vermeiden. Beispielsweise können die erlernten kontextbezogenen Verhaltensmuster dazu verwendet werden, ein Verhaltensmodell eines autonomen Fahrzeugs zu modifizieren, z. B. dynamisch, wenn das autonome Fahrzeug den bestimmten Kontext, der mit dem kontextbezogenen Verhaltensmuster verbunden ist, betritt oder beobachtet.
• 36 ist ein Flussdiagramm eines Beispielprozesses 3600 der Verfolgung von unregelmäßigen Verhaltensweisen, die von Fahrzeugen gemäß mindestens einer Ausführungsform beobachtet werden. Die Vorgänge im Beispielprozess 3600 können von einer oder mehreren Komponenten eines autonomen Fahrzeugs oder eines cloudbasierten Lernmoduls durchgeführt werden. Der Beispielprozess 3600 kann zusätzliche oder andere Vorgänge umfassen, und die Vorgänge können in der gezeigten oder einer anderen Reihenfolge durchgeführt werden. In manchen Fällen können eine oder mehrere der in 3600 gezeigten Operationen als Prozesse implementiert werden, die mehrere Operationen, Unterprozesse oder andere Arten von Routinen umfassen. In einigen Fällen können Vorgänge kombiniert, in anderer Reihenfolge, parallel, iterativ oder auf andere Weise wiederholt oder durchgeführt werden.
• Bei 3602 werden Sensordaten von einer Mehrzahl von Sensoren empfangen, die mit dem autonomen Fahrzeug gekoppelt sind, einschließlich Kameras, LIDAR oder anderen Sensoren, die vom autonomen Fahrzeug verwendet werden, um Fahrzeuge und Umgebung zu identifizieren.
• Bei 3604 werden unregelmäßige oder anomale Verhaltensweisen von einem oder mehreren Fahrzeugen erkannt. In einigen Fällen kann die Erkennung durch den Vergleich eines beobachteten Verhaltens des betreffenden Fahrzeugs mit einem Sicherheitsmodell des autonomen Fahrzeugs erfolgen; und auf der Grundlage des Vergleichs wird festgestellt, dass das beobachtete Verhalten gegen das Sicherheitsmodell des autonomen Fahrzeugs verstößt. In einigen Fällen kann die Erkennung durch den Vergleich eines beobachteten Verhaltens des betreffenden Fahrzeugs mit dem beobachteten Verhalten anderer Fahrzeuge erfolgen und auf der Grundlage des Vergleichs festgestellt werden, dass das beobachtete Verhalten des betreffenden Fahrzeugs von dem beobachteten Verhalten der anderen Fahrzeuge abweicht. In einigen Fällen kann die Erkennung durch den Vergleich eines beobachteten Verhaltens des betreffenden Fahrzeugs mit dem beobachteten Verhalten anderer Fahrzeuge erfolgen und auf der Grundlage des Vergleichs festgestellt werden, dass das beobachtete Verhalten des betreffenden Fahrzeugs von dem beobachteten Verhalten der anderen Fahrzeuge abweicht. Die Erkennung kann auch auf andere Weise erfolgen. Die Erkennung kann sich auf akustische und visuelle Kontextinformationen in den Sensordaten stützen.
• Bei 3606 wird für jedes Fahrzeug, bei dem ein unregelmäßiges Verhalten beobachtet wurde, eine Kennung erzeugt. Die Kennung kann erzeugt werden, indem Werte für die jeweiligen Merkmale des jeweiligen Fahrzeugs ermittelt werden und eine kryptografische Funktion auf eine Kombination der Werte angewendet wird, um die Kennung zu erhalten. Die Werte können durch Extraktion repräsentativer Merkmale aus einem Deep-Learning-Modell ermittelt werden, das vom autonomen Fahrzeug zur Erkennung anderer Fahrzeuge verwendet wird. Der Identifikator kann auch auf andere Weise erzeugt werden.
• Bei 3608 werden die bei 3604 festgestellten unregelmäßigen Verhaltensweisen mit den bei 3606 erzeugten Identifikatoren für die Fahrzeuge, die die jeweiligen unregelmäßigen Verhaltensweisen gezeigt haben, verknüpft.
• Bei 3610 wird die Häufigkeit des Auftretens der unregelmäßigen Verhaltensweisen für die identifizierten Fahrzeuge verfolgt.
• Bei 3612 wird festgestellt, ob ein beobachtetes unregelmäßiges Verhalten von einem bestimmten Fahrzeug mehr als eine bestimmte Anzahl von Malen beobachtet wurde. Wenn dies der Fall ist, wird bei 3614 eine dynamische Verhaltenspolitik eingeleitet (z. B. um dem Fahrzeug weiter auszuweichen). Ist dies nicht der Fall, setzt das autonome Fahrzeug seinen Betrieb mit dem Standardverhalten fort.
• 37 ist ein Flussdiagramm eines Beispielprozesses 3700 zur Identifizierung kontextbezogener Verhaltensmuster in Übereinstimmung mit mindestens einer Ausführungsform. Die Vorgänge im Beispielprozess 3700 können von einem Lernmodul eines autonomen Fahrzeugs oder einem cloudbasierten Lernmodul durchgeführt werden. Der Beispielprozess 3700 kann zusätzliche oder andere Vorgänge umfassen, und die Vorgänge können in der gezeigten oder einer anderen Reihenfolge durchgeführt werden. In manchen Fällen können eine oder mehrere der in 37 gezeigten Operationen als Prozesse implementiert werden, die mehrere Operationen, Unterprozesse oder andere Arten von Routinen umfassen. In einigen Fällen können Vorgänge kombiniert, in anderer Reihenfolge, parallel, iterativ oder auf andere Weise wiederholt oder durchgeführt werden.
• Bei 3702 werden Daten zur Verfolgung von unregelmäßigem Verhalten von einer Mehrzahl autonomer Fahrzeuge empfangen. Die Daten zur Verfolgung irregulären Verhaltens können Einträge umfassen, die eine Fahrzeugkennung, ein zugehöriges irreguläres Verhalten, das von einem mit der Fahrzeugkennung verbundenen Fahrzeug beobachtet wurde, und Kontextdaten, die einen Kontext angeben, in dem das irreguläre Verhalten von den autonomen Fahrzeugen erkannt wurde, umfassen. In einigen Fällen können die Kontextdaten eine oder mehrere Trajektorieninformationen für die Fahrzeuge, die die unregelmäßigen Verhaltensweisen ausführen, Fahrzeugattribute für die Fahrzeuge, die die unregelmäßigen Verhaltensweisen ausführen, Fahrerattribute für die Fahrzeuge, die die unregelmäßigen Verhaltensweisen ausführen, einen geografischen Standort der Fahrzeuge, die die unregelmäßigen Verhaltensweisen ausführen, Wetterbedingungen in der Umgebung der Fahrzeuge, die die unregelmäßigen Verhaltensweisen ausführen, und Verkehrsinformationen, die die Verkehrsbedingungen in der Umgebung der Fahrzeuge, die die unregelmäßigen Verhaltensweisen ausführen, anzeigen, umfassen.
• Bei 3704 werden eine oder mehrere Sequenzen von unregelmäßigen Verhaltensweisen identifiziert. Dies kann durch Clustering der Verhaltensweisen geschehen, z. B. durch die Verwendung von Longest Common Subsequences- (LCS-) Techniken.
• In 3706 wird auf der Grundlage der in 3704 identifizierten Sequenzen und der in 3702 empfangenen Daten ein kontextbezogener Graph erstellt. Der kontextuelle Graph kann einen ersten Satz von Knoten umfassen, die identifizierte Sequenzen anzeigen, und einen zweiten Satz von Knoten, die kontextuelle Daten anzeigen, wobei die Kanten des kontextuellen Graphen eine Häufigkeit von Assoziationen zwischen den Knoten anzeigen.
• Bei 3708 wird ein kontextbezogenes Verhaltensmuster unter Verwendung des kontextbezogenen Graphen identifiziert, und bei 3710 wird eine Verhaltensrichtlinie für ein oder mehrere autonome Fahrzeuge basierend auf dem identifizierten kontextbezogenen Verhaltensmuster geändert. Beispielsweise können Verhaltensrichtlinien für ein oder mehrere autonome Fahrzeuge geändert werden, wenn festgestellt wird, dass sich das eine oder die mehreren autonomen Fahrzeuge in einem bestimmten Kontext befinden, der mit dem identifizierten kontextbezogenen Verhaltensmuster verbunden ist.
• Wie hier erörtert, können Prinzipien und Merkmale der modernen Computer Vision (CV) und der künstlichen Intelligenz (AI) in fahrzeuginternen Rechensystemen genutzt werden, um beispielsweise autonome Fahrsysteme für hochautomatisierte und autonome Fahrzeuge zu implementieren. Allerdings sind Lebenslauf- und Kl-Modelle und -Logiken manchmal anfällig für Fehlklassifizierungen und Manipulationen. Ein typisches Intrusion Detection System (IDS) ist langsam und komplex und kann eine erhebliche Menge an Rauschen und Fehlalarmen erzeugen. Ein einziger Bitwechsel in einem Deep Neural Network (DNN)-Algorithmus kann zu einer völlig falschen Klassifizierung eines Bildes führen. Dementsprechend können verbesserte autonome Fahrsysteme eingesetzt werden, um Fehler und Angriffe auf hochautomatisierte und autonome Fahrzeuge genauer zu erkennen.
• Die folgende Offenbarung bietet verschiedene mögliche Ausführungsformen oder Beispiele für die Implementierung eines Fehler- und Angriffserkennungssystem 3800 für hochautomatisierte und autonome Fahrzeuge, wie sie in 38 gezeigt. In einer oder mehreren Ausführungsformen werden Ereignisse zur Vorhersage der Fahrzeugbewegung und Steuerbefehle, die beide eine höhere Abstraktionsebene darstellen, überwacht. Basierend auf dem aktuellen Zustand der Bewegungsparameter des Fahrzeugs und der Straßenparameter bleibt das Fahrzeug innerhalb eines bestimmten Bewegungsrahmens. A zeitliches Normalverhaltensmodell 3841 wird konstruiert, um die Einhaltung der Bewegungshüllkurve zu gewährleisten. In mindestens einer Ausführungsform werden mindestens zwei Algorithmen verwendet, um das zeitliche Normalverhaltensmodell zu erstellen. Die Algorithmen umfassen ein Fahrzeugverhaltensmodell 3842 (z. B. basierend auf einem Hidden Markov Model (HMM)) zum Erlernen des normalen Fahrzeugverhaltens und ein Regressionsmodell 3844 um die Abweichung vom Fahrzeugverhaltensmodell zu ermitteln. Insbesondere wird das Regressionsmodell verwendet, um festzustellen, ob das Fahrzeugverhaltensmodell einen Fehler korrekt erkennt, wobei der Fehler ein Fehler des Fahrzeugsystems oder ein bösartiger Angriff auf das Fahrzeugsystem sein könnte.
• Zur Veranschaulichung der verschiedenen Ausführungsformen eines Fehler- und Angriffserkennungssystems für hochautomatisierte und autonome Fahrzeuge ist es zunächst wichtig, die möglichen Aktivitäten im Zusammenhang mit hochautomatisierten und autonomen Fahrzeugen zu verstehen. Dementsprechend können die folgenden grundlegenden Informationen als Basis angesehen werden, von der aus die vorliegende Offenbarung richtig erklärt werden kann.
• Moderne Computer Vision (CV) und künstliche Intelligenz (AI), die für autonome Fahrzeuge verwendet werden, sind anfällig für Fehlklassifizierungen und Manipulationen. So kann ein Angreifer beispielsweise Aufkleber generieren, die einem Fahrzeug vorgaukeln, dass ein Schild in Wirklichkeit etwas anderes bedeutet. 39 veranschaulicht eine solche Manipulation, wie sie in der „Hass-Liebe“-Grafik 3900 zu sehen ist, in der „LOVE“ über „STOP“ auf einem Stoppschild und „HATE“ unter „STOP“ auf dem Stoppschild gedruckt ist. Obwohl das mit Graffiti beschriftete Schild für englischsprachige Autofahrer eindeutig als Stoppschild zu erkennen ist, kann dieses Graffiti zumindest einige Computer-Vision-Algorithmen dazu veranlassen, das Stoppschild in Wirklichkeit für eine Geschwindigkeitsbegrenzung oder einen Vorfahrtshinweis zu halten. Darüber hinaus kann ein einziger Bitfehler in einem Algorithmus eines tiefen neuronalen Netzwerkes (DNN), der Bilder klassifiziert, zu einer Fehlklassifizierung eines Bildes führen. Zum Beispiel könnte ein einziger Bit-Sprung dazu führen, dass der Klassifikator statt eines riesigen Lastwagens ein kleines Tier oder einen Vogel sieht.
• Aktuelle (regelbasierte) Angriffserkennungssysteme (IDS) erzeugen aufgrund der nicht-deterministischen Natur von Kfz-Netzwerken zu viel Rauschen und zu viele falschpositive Ergebnisse, so dass sie nicht in der Lage sind, das gesamte Spektrum an abnormalem Verhalten abzudecken. Fehlerkorrekturcode-Algorithmen (ECC) haben ihre Grenzen und sind im Allgemeinen nicht hilfreich für künstliche Intelligenz. Generative Adversarial Networks (GANs) sind wertvoll, hängen aber stark von der Auswahl der gegnerischen Daten in einem Trainingssatz ab. Aktuelle, auf maschinellem Lernen basierende Angriffserkennungssysteme sind aufgrund der hohen Komplexität und der vielen internen Netzwerke und externen Verbindungen, die überwacht werden, nicht für den Einsatz in Automobilsystemen geeignet.
• Fehler- und Angriffserkennungssystem 3800, wie in 38 gezeigt, löst viele der vorgenannten Probleme (und mehr). System 3800 umfasst ein Modell des zeitlichen Normalverhaltens 3841 mit zwei Algorithmen: Fahrzeugverhaltensmodell 3842 zum Erlernen des Normalverhaltens eines Fahrzeugs und Regressionsmodell 3844 zur Vorhersage der Wahrscheinlichkeit eines Fahrzeugverhaltens für ein Zeitintervall t. Das Fahrzeugverhaltensmodell kann ein probabilistisches Modell für normales Fahrzeugverhalten sein. Das Fahrzeugverhaltensmodell lernt ein stationäres Basismodell mit niedrigem Rang und modelliert dann die Abweichung des zeitlichen Modells vom stationären Modell. Da der Ereignissatz im Allgemeinen im Laufe der Zeit statisch ist, kann das Fahrzeugverhaltensmodell durch gelegentliche Neugewichtung der Parameter anhand früherer und neuer, überprüfter Trainings- Abtastwerte, die das Fehler- und Angriffserkennungssystem durchlaufen haben und beibehalten wurden, aktualisiert werden. Ein Regressionsalgorithmus vergleicht die Wahrscheinlichkeit einer Bewegungsänderung auf der Grundlage neuer empfangener Steuerereignisse, die anhand des Fahrzeugverhaltensmodells berechnet werden, mit dem vom Regressionsalgorithmus vorhergesagten Modell (z. B. der Bewegungshüllkurve).
• Ein Fehler- und Angriffserkennungssystem 3800 bietet mehrere potenzielle Vorteile. Zum Beispiel überwacht das System 3800 Ereignisse und Steuerbefehle zur Vorhersage von Fahrzeugbewegungen, die auf einer höheren Abstraktionsebene angesiedelt sind als diejenigen, die von typischen Angrifferkennungssystemen überwacht werden. Die hier vorgestellten Modelle ermöglichen eine Erkennung auf einer höheren Ebene, auf der böswillige Angriffe und Absichten erkannt werden können, anstatt Änderungen auf niedriger Ebene zu erkennen, die von einem typischen Angriffserkennungssystem möglicherweise nicht erfasst werden. Entsprechend, System 3800 die Erkennung anspruchsvoller und komplexer Angriffe und Systemausfälle.
• Bezug nehmend nun auf 38 umfasst das Fehler- und Angriffserkennungssystem 3800 ein Cloud-Verarbeitungssystem 3810, ein Fahrzeug 3850, andere Edge-Vorrichtungen 3830 und ein oder mehrere Netzwerke (z. B. Netzwerk 3805), die die Kommunikation zwischen Fahrzeug 3850 und Cloud-Verarbeitungssystem 3810 und zwischen Fahrzeug 3850 und anderen Edge-Vorrichtungen 3830 ermöglichen. Cloud-Verarbeitungssystem 3810 umfasst ein Cloud-Fahrzeugdatensystem 3820. Fahrzeug 3850 umfasst eine CCU 3840 und zahlreiche Sensoren, wie zum Beispiel Sensoren 3855A-3855E. Elemente von 38 umfassen auch geeignete Hardwarekomponenten, einschließlich, aber nicht notwendigerweise beschränkt auf Prozessoren (z. B. 3817, 3857) und Speicher (z. B. 3819, 3859), die in zahlreichen verschiedenen Ausführungsformen implementiert werden können.
• Im Fahrzeug 3850 kann die CCU 3840 nahezu kontinuierliche Datenspeisungen von Sensoren 3855A-3855E empfangen. Zu den Sensoren kann jede hier beschriebene Art von Sensor gehören, einschließlich Lenk-, Drosselklappen- und Bremssensoren. Zahlreiche andere Arten von Sensoren (z. B. Bilderfassungsvorrichtungen, Reifendrucksensoren, Straßenzustandssensoren usw.) können ebenfalls Daten an die CCU 3840 bereitstellen. CCU 3840 umfasst ein zeitliches Normalverhaltensmodell 3841, das ein Fahrzeugverhaltensmodell 3842, ein Regressionsmodell 3844 und einen Komparator 3846 umfasst.
• Fahrzeugverhaltensmodell 3842 kann mit Rohdaten von Sensoren trainiert werden, z. B. mit den Daten eines Lenksensors, eines Drosselklappensensors und eines Bremssensors, um das Fahrzeugverhalten auf einer niedrigen Ebene zu lernen. Die im Fahrzeug auftretenden Ereignisse sind im Allgemeinen im Laufe der Zeit statisch, so dass das Fahrzeugverhaltensmodell durch eine gelegentliche Neugewichtung der Parameter anhand früherer und neuer, überprüfter Trainings- Abtastwerte, die das Fehler- und Angriffserkennungssystem durchlaufen haben und beibehalten wurden, aktualisiert werden kann.
• In mindestens einem Beispiel ist das Fahrzeugverhaltensmodell 3842 ein probabilistisches Modell. Ein probabilistisches Modell ist ein statistisches Modell, das dazu dient, Beziehungen zwischen Variablen zu definieren. Zumindest in einigen Ausführungsformen umfassen diese Variablen Daten von Lenkungssensoren, Drosselklappensensoren und Bremssensoren. In einem probabilistischen Modell kann es bei der Vorhersage einer Variablen aus den anderen Variablen zu Fehlern kommen. Andere Faktoren können für die Variabilität der Daten verantwortlich sein, und das probabilistische Modell umfasst eine oder mehrere Wahrscheinlichkeitsverteilungen, um diesen anderen Faktoren Rechnung zu tragen. In mindestens einer Ausführungsform kann das probabilistische Modell ein Hidden-Markov-Modell (HMM) sein. Beim HMM wird davon ausgegangen, dass das zu modellierende System ein Markov-Prozess mit unbeobachteten (z. B. verborgenen) Zuständen ist.
• In mindestens einer Ausführungsform befindet sich das Fahrzeugverhaltensmodell in der Pipeline zur physischen Fahrzeugbetätigung. Betätigungsereignisse (hier auch als „Steuerereignisse“ bezeichnet) können von einer vorhergehenden Softwareschicht als Betätigungsereignisse gekennzeichnet werden. Vektorstrukturen können von Fahrzeugverhaltensmodell 3842 für verschiedene Arten von Eingabedaten verwendet werden (z. B. Vektor für Wetter, Vektor für Geschwindigkeit, Vektor für Richtung usw.). Für jeden Parameter in einer Vektorstruktur wird Fahrzeugverhaltensmodell 3842 eine Wahrscheinlichkeit zugewiesen. Fahrzeugverhaltensmodell 3842 kann kontinuierlich mit den Daten arbeiten, die an die Aktoren des Fahrzeugs gehen. Dementsprechend kann jeder Befehl (z. B. zur Änderung der Bewegung des Fahrzeugs) das Fahrzeugverhaltensmodell durchlaufen und ein Verhaltenszustand des Fahrzeugs kann aufrechterhalten werden.
• Normalerweise werden Steuerereignisse durch Befehle des Fahrers (z. B. Drehen des Lenkrads, Betätigung der Bremsen, Gas geben) oder durch Sensoren eines autonomen Fahrzeugs ausgelöst, die die nächste Aktion des Fahrzeugs anzeigen. Steuerereignisse können auch aus einer Rückkopplungsschleife von den Sensoren und Aktoren selbst stammen. Im Allgemeinen ist ein Kontrollereignis ein Hinweis auf eine Bewegungsänderung des Fahrzeugs. Fahrzeugverhaltensmodell 3842 kann feststellen, ob es sich bei der Bewegungsänderung um eine potenzielle Anomalie oder um ein erwartetes Verhalten handelt. Insbesondere kann eine Ausgabe des Fahrzeugverhaltensmodells eine Klassifizierung der Bewegungsänderung sein. In einem Beispiel kann eine Klassifizierung die Wahrscheinlichkeit anzeigen, dass es sich bei der Bewegungsänderung um einen Fehler handelt (z. B. einen böswilligen Angriff oder eine Störung im Computersystem des Fahrzeugs).
• Regressionsmodell 3844 sagt die Wahrscheinlichkeit voraus, dass eine Bewegungsänderung des Fahrzeugs, die durch ein Steuerereignis angezeigt wird, in einem bestimmten Zeitintervall t eintritt. Ein Regressionsalgorithmus ist eine statistische Methode zur Untersuchung der Beziehung zwischen zwei oder mehr Variablen. Im Allgemeinen wird mit Regressionsalgorithmen der Einfluss einer oder mehrerer unabhängiger Variablen auf eine abhängige Variable untersucht.
• Eingaben für Regressionsmodell 3844 können auch Ereignisse auf höherer Ebene umfassen, z. B. Eingaben von anderen Weg- und/oder Geschwindigkeitsgebern als dem Weg- und/oder Geschwindigkeitsgeber, der dem Steuerungsereignis zugeordnet ist. Wenn beispielsweise eine Steuerung auch mit einem Bremssensor verbunden ist, kann die Eingabe für das Regressionsmodell auch Eingaben des Drosselklappensensors und des Lenksensors umfassen. Eingaben können von anderen relevanten Fahrzeugsensoren, wie z. B. Gyroskopen, die die Trägheit des Fahrzeugs anzeigen, empfangen werden. Regressionsmodell 3844 kann auch Eingaben von anderen Modellen im Fahrzeug erhalten, z. B. von einem Bildklassifikator, der ein Bild klassifizieren kann, das von einer mit dem Fahrzeug verbundenen Bilderfassungsvorrichtung (z. B. einer Kamera) aufgenommen wurde. Darüber hinaus kann das Regressionsmodell 3944 Eingaben aus entfernten Quellen umfassen, einschließlich, aber nicht notwendigerweise beschränkt auf, andere Edge-Vorrichtungen wie Mobilfunkmasten, Mautstellen, Infrastrukturgeräte, Satelliten, andere Fahrzeuge, Radiosender (z. B. für Wettervorhersage, Verkehrsbedingungen usw.) usw. Zu den Eingaben von anderen Edge-Vorrichtungen können Umgebungsdaten gehören, die zusätzliche Informationen liefern (z. B. Umgebungsbedingungen, Wettervorhersage, Straßenzustand, Tageszeit, Standort des Fahrzeugs, Verkehrsbedingungen usw.), die vom Regressionsmodell untersucht werden können, um festzustellen, wie die zusätzlichen Informationen das Steuerereignis beeinflussen.
• In mindestens einer Ausführungsform führt Regressionsmodell 3844 im Hintergrund und erstellt auf der Grundlage der Prüfung der Eingaben von Sensoren, anderen Modellen, entfernten Quellen wie anderen Edge-Vorrichtungen usw. einen Speicher dessen, was das Fahrzeug getan hat, und sagt voraus, was das Fahrzeug unter normalen (fehlerfreien) Bedingungen tun sollte. Es kann eine Bewegungshüllkurve erstellt werden, um Grenzen für das Fahrzeugverhaltensmodell festzulegen. Eine Bewegungshüllkurve ist eine berechnete Vorhersage auf der Grundlage der Eingaben des Weges des Fahrzeugs und eines Ziels des Fahrzeugs während eines bestimmten Zeitintervalls t unter der Annahme, dass nichts schief geht. Das Regressionsmodell 3844 kann bestimmen, ob ein Steuerereignis eine Bewegungsänderung des Fahrzeugs anzeigt, die außerhalb einer Bewegungshüllkurve liegt. Handelt es sich bei einem Steuerereignis beispielsweise um eine Vollbremsung, kann das Fahrzeugverhaltensmodell feststellen, dass das Bremsereignis außerhalb eines normalen Schwellenwerts für das Bremsen liegt und eine hohe Wahrscheinlichkeit für einen Fehler im Fahrzeugsystem anzeigt. Das Regressionsmodell kann jedoch auch Eingaben von straßenseitigen Infrastruktureinrichtungen prüfen, die ein hohes Verkehrsaufkommen (z. B. aufgrund eines Unfalls) anzeigen. Auf diese Weise kann das Regressionsmodell feststellen, dass das Vollbremsungsereignis wahrscheinlich innerhalb einer vorhergesagten Bewegungshüllkurve auftreten wird, die zumindest teilweise auf der Grundlage der besonderen Verkehrsbedingungen während des Zeitintervalls t berechnet wird.
• Fehler- und Angriffserkennungssystem 3800 ist agonistisch gegenüber der Art des verwendeten Regressionsalgorithmus. So kann beispielsweise ein Erwartungsmaximierungsalgorithmus (EM) verwendet werden, eine iterative Methode zur Ermittlung der maximalen Wahrscheinlichkeit von Parametern in einem statistischen Modell wie dem HMM, das von verborgenen Variablen abhängt. In mindestens einer Ausführungsform kann der Regressionsalgorithmus (z. B. linear oder Lasso) so gewählt werden, dass er je nach den gewünschten Größen der Bewegungshüllen mehr oder weniger tolerant gegenüber Abweichungen ist. So kann beispielsweise ein Bewegungsbereich für Fahrzeuge, die von Zivilisten genutzt werden, eingeschränkt (oder klein) sein, während ein anderer Bewegungsbereich für Fahrzeuge, die für militärische Zwecke genutzt werden, lockerer sein kann.
• Der Komparator 3846 kann verwendet werden, um Grenzen auf das Fahrzeugverhaltensmodell 3842 anzuwenden. Der Komparator kann die Ausgangsklassifizierung von Fahrzeugverhaltensmodell 3842 und die Ausgabevorhersage des Regressionsmodells 3844 vergleichen und bestimmen, ob eine durch ein Steuerereignis angezeigte Bewegungsänderung ein Fehler oder eine akzeptable Bewegungsänderung ist, die innerhalb einer vorhergesagten Bewegungshüllkurve auftreten kann. Die Ausgangsklassifizierung des Fahrzeugverhaltensmodells kann einen Hinweis auf die Wahrscheinlichkeit geben, dass es sich bei der durch das Steuerereignis angezeigten Bewegungsänderung um einen Fehler handelt (z. B. einen böswilligen Angriff oder einen Fehler im Computersystem des Fahrzeugs). Die Ergebnisvorhersage des Regressionsmodells 3844 kann eine Wahrscheinlichkeit sein, dass die Bewegungsänderung in dem gegebenen Zeitintervall t eintritt, basierend auf Eingangsdaten von Sensoren, Edge-Vorrichtungen, anderen Modellen im Fahrzeug usw. Der Komparator kann das Regressionsmodell verwenden, um Grenzwerte auf die Ausgangsklassifizierung eines Steuerungsereignisses durch das Fahrzeugverhaltensmodell anzuwenden.
• In einem Beispiel der Vergleichsfunktion, wenn das Fahrzeugverhaltensmodell anzeigt, dass ein Bremsereignis möglicherweise anomal ist, aber das Regressionsmodell anzeigt, dass für die besonderen Umgebungsbedingungen, die als Eingabe empfangen werden (z. B. hohe Geschwindigkeit vom Sensor, Ampel vor der Straße von Straßenkarten, Regen von der Wettervorhersage), das erwartete Bremsereignis innerhalb eines akzeptablen Schwellenwerts liegt (z. B. innerhalb eines Bewegungsbereichs). Da das Bremsereignis innerhalb eines akzeptablen Schwellenwerts auf der Grundlage einer Bewegungshüllkurve liegt, kann der Komparator feststellen, dass die Einschätzung des Fahrzeugverhaltensmodells, dass das Bremsereignis potenziell anormal ist, außer Kraft gesetzt werden kann, und ein Steuersignal kann gesendet werden, um die Fortsetzung der Bremsung zu ermöglichen. Ein weiteres illustratives Beispiel, Regressionsmodell 3844 weiß, dass ein Fahrzeug in der Vergangenheit mit 35 gefahren ist und an einer Kreuzung ein Stoppschild erwartet, weil es Zugriff auf die Karte hat. Das Regressionsmodell weiß auch, dass die Wettervorhersage eisig ist. Im Gegensatz dazu, Fahrzeugverhaltensmodell 3842 ein Steuerereignis (z. B. einen Befehl an einen Aktuator) zum Beschleunigen, weil sein Bildklassifikator fälschlicherweise festgestellt hat, dass ein bevorstehendes Stoppschild eine höhere Geschwindigkeit bedeutet, oder weil ein Hacker Steuerdaten manipuliert und den falschen Befehl an das Gaspedal gesendet hat. In diesem Szenario kann der Komparator, obwohl eine Ausgangsklassifizierung des Fahrzeugverhaltensmodells nicht anzeigt, dass das Steuerereignis möglicherweise anormal ist, ein Fehler- oder Steuersignal erzeugen, das auf der Vorhersage des Regressionsmodells basiert, dass das Steuerereignis angesichts der Bewegungshüllkurve für das gegebene Zeitintervall t unwahrscheinlich ist, was bedeutet, dass das Fahrzeug bremsen sollte, wenn es sich dem Stoppschild nähert.
• Zur Umsetzung der Wahrscheinlichkeitsvergleichsfunktion des zeitlichen Normalverhaltensmodells 3841 kann einer von mehreren geeigneten Komparatoren verwendet werden zeitlichen Normalverhaltensmodells 3841. In mindestens einer Ausführungsform kann der Komparator auf der Grundlage des jeweiligen Fahrzeugverhaltensmodells und des verwendeten Regressionsmodells ausgewählt werden.
• Komparator 3846 kann ausgelöst werden, um eine Rückmeldung an das Fahrzeugverhaltensmodell 3842 zu senden, um sein Modell zu ändern. Rückmeldungen für das Fahrzeugverhaltensmodell ermöglichen eine Nachschulung. In einem Beispiel erstellt das System auf der Grundlage des Feedbacks einen Speicher für begangene Fehler und wird neu trainiert, um ähnliche Szenarien zu erkennen, z. B. auf der Grundlage von Ort und Zeit. Bei der Umschulung können auch andere Variablen verwendet werden.
• Cloud-Fahrzeugdatensystem 3820 kann Regressionsmodelle (z. B. 3844) für mehrere Fahrzeuge trainieren und aktualisieren. In einem Beispiel kann das Cloud-Fahrzeugdatensystem 3820 Rückmeldungen 3825 von Regressionsmodellen (z. B. 3844) in Betriebsfahrzeugen (z. B. 3850) empfangen. Die Rückmeldung 3825 kann an das Cloud-Fahrzeugdatensystem 3820 zur Aggregation und Neuberechnung gesendet werden, um Regressionsmodelle in mehreren Fahrzeugen zu aktualisieren und das Verhalten zu optimieren. Zumindest in einigen Beispielen können eine oder mehrere Edge-Vorrichtungen 3830 eine Aggregation und möglicherweise einige Trainings-/Aktualisierungsoperationen durchführen. In diesen Beispielen, kann eine Rückmeldung 3835 von Regressionsmodellen (z. B. 3844) empfangen werden, um diese Aggregationen, Trainings- und/oder Aktualisierungsoperationen zu ermöglichen.
• Bezug nehmend nun auf 40 ist ein Blockdiagramm einer vereinfachten zentralisierten Fahrzeugsteuerungsarchitektur 4000 für ein Fahrzeug gemäß mindestens einer Ausführungsform dargestellt. In der Fahrzeugsteuerungsarchitektur verbindet ein Bus 4020 (z. B. Controller Area Network (CAN), FlexRay-Bus, usw.) die Reifen 4010A, 4010B, 4010Cund 4010D und ihre jeweiligen Aktuatoren 4012A, 4012B, 4012C und 4012D mit verschiedenen Motorsteuereinheiten (ECUs; engine control units), darunter eine Lenkungs-ECU 4056A, eine Drosselklappen-ECU 4056B und eine Brems-ECU 4056C. Der Bus verbindet auch eine Konnektivitätssteuereinheit (CCU; connectivity control unit) 4040 mit den ECUs. CCU 4040 ist kommunikativ verbunden mit Sensoren wie zum Beispiel einem Lenkungssensor 4055A, einem Drosselklappensensor 4055B und einem Bremssensor 4055C. CCU 4040 kann Anweisungen von einem autonomen Steuergerät oder dem Fahrer empfangen, zusätzlich zu den Rückmeldungen von einem oder mehreren Lenk-, Drosselklappen- und Bremssensoren und/oder Aktuatoren, und sendet Befehle an die entsprechenden Steuergeräte. Beim Lernen des Fahrzeugverhaltens zur Erstellung von Fahrzeugverhaltensmodellen werden häufig Rohdaten verwendet, die wie oben beschrieben erzeugt werden können. Zum Beispiel, dass die Räder derzeit in einem bestimmten Winkel stehen, dass der Bremsdruck einen bestimmten Prozentsatz beträgt, dass die Beschleunigung hoch ist usw.
• 41 ist ein vereinfachtes Blockdiagramm einer autonomen Erfassungs- und Steuerpipeline 4100. Die Steuerung eines Fahrzeugs erfolgt über eine Motorsteuereinheit (ECU), die für die Betätigung verantwortlich ist. 41 veranschaulicht eine autonome Verarbeitungspipeline von den Sensoren über die Sensorfusion und die Planungs-ECU bis hin zu den Fahrzeugsteuerungs-ECUs. 41 zeigt eine Vielzahl von Sensoreingängen, einschließlich Nicht-Sichtlinie, Sichtlinie, Fahrzeugzustand und Positionierung. Solche Eingaben können insbesondere von V2X 4154A, einem Radar 4154B, einer Kamera 4154C, einem LIDAR 4154D, einem Ultraschallgerät 4154E, der Bewegung des Fahrzeugs 4154F, Geschwindigkeit des Fahrzeugs 4154GGPS, Trägheitsmessung, und Telemetrie 4154Hund/oder Hochauflösenden (HD-) Karten 41541 bereitgestellt werden. Diese Eingaben werden in eine zentrale Einheit (z. B. Zentraleinheit) über Sensormodelle 4155 gespeist. Die Sensormodelle 4155 liefern Eingaben für probabilistische Sensorfusion und Bewegungsplanung 4110. Im Allgemeinen umfasst die Sensorfusion die Auswertung aller Eingangsdaten, um den Fahrzeugzustand, die Bewegung und die Umgebung zu verstehen. Eine Endlosschleife kann verwendet werden, um den nächsten Betrieb des Fahrzeugs vorherzusagen und die entsprechenden Informationen in einem Instrumentencluster 4120 des Fahrzeugs anzuzeigen und entsprechende Signale an Fahrzeugsteuerungsaktuatoren 4130 zu senden.
• 42 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung einer beispielhaften x-by-draht-Architektur 4200 eines hochautomatisierten oder autonomen Fahrzeugs. Eine CCU 4240 kann Eingaben (z. B. Steuersignale) von einem Lenkrad 4202 und Pedalen 4204 des Fahrzeugs empfangen. In einem autonomen Fahrzeug sind das Lenkrad und/oder die Pedale jedoch möglicherweise nicht vorhanden. Stattdessen kann ein Steuergerät für autonomes Fahren (AD) diese Mechanismen ersetzen und alle Fahrentscheidungen treffen.
• Kabelgebundene Netzwerke (z. B. CAN, FlexRay) verbinden CCU 4240 mit einer Lenkungs-ECU 4256A und deren Lenkungsaktuator 4258A, mit einer Brems-ECU 4256B und deren Bremsaktuator 4258B und mit einer Drosselklappen-ECU 4256C und deren Drosselklappenaktuator 4258C. Kabelgebundene Netzwerke werden durch Steer-by- Wire 4210, Brake-by-Wire 4220 und Throttle-by-Wire 4230 bezeichnet. In einem autonomen oder hochgradig autonomen Fahrzeug ist eine CCU, wie z. B CCU 4240, ein geschlossenes System mit sicherem Systemstart, Bescheinigung und Softwarekomponenten, bei denen eine digitale Signierung erforderlich ist. Es ist jedoch möglich, dass ein Angreifer die Eingaben in die Sensoren kontrolliert (z. B. Bilder, Radarspoofing usw.), den Netzwerkverkehr bis zur CCU manipuliert und/oder andere Steuergeräte im Fahrzeug (außer der CCU) kompromittiert. Netzwerke zwischen CCU 4240 und antrieben 4258A-4258C können aufgrund zusätzlicher Hardwareprüfungen des zulässigen Datenverkehrs und der Verbindungen nicht kompromittiert werden. Insbesondere darf keine andere ECU als CCU 4240 ist in den verdrahteten Netzwerken erlaubt. Die Durchsetzung kann kryptografisch erfolgen, indem diese Geräte angebunden werden und/oder indem andere physische Durchsetzungsmaßnahmen unter Verwendung von Verkehrstransceivern und -empfängern (Tx/Rx) eingesetzt werden.
• 43 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung einer beispielhaften Sicherheits-Reset-Architektur 4300 eines hochautomatisierten oder autonomen Fahrzeugs gemäß mindestens einer Ausführungsform. Architektur 4300 umfasst eine CCU 4340 verbunden mit einem bus 4320 (z. B. CAN, FlexRay) und einen hardware/Software-Überwachung 4360. HW/SW-Überwachung 4360 überwacht die CCU 4340 auf Fehler und setzt die CCU zurück, wenn eine durch ein Steuerereignis angezeigte Bewegungsänderung außerhalb des vom Regressionsmodell berechneten Bewegungsbereichs liegt. In mindestens einer Ausführungsform, HW/SW-Überwachung 4360 eine Eingabe von einem Komparator erhalten, der entscheidet, ob ein Fehlersignal gesendet werden soll. Wenn ein Fehlersignal gesendet wird und ein Selbst-Reset der CCU das Verhalten des Fahrzeugs nicht wirksam korrigiert, so dass es sich innerhalb einer vorhergesagten Bewegungshüllkurve befindet, wird in zumindest einigen Ausführungsformen die CCU 4340 das Fahrzeug sicher anhalten.
• 44 ist ein vereinfachtes Blockdiagramm, das ein Beispiel für eine allgemeinen Sicherheitsarchitektur 4400 eines hochautomatisierten oder autonomen Fahrzeugs gemäß mindestens einer Ausführungsform. Die Sicherheitsarchitektur 4400 umfasst eine CCU 4440, die mit einer Lenkungs-ECU 4456A und ihrem Lenkungsaktuator 4458A, einer Drosselklappen-ECU 4456B und ihrem Drosselklappenaktuator 4458B und einer Brems-ECU 4456C und ihrem Bremsaktuator 4458C über einen Bus 4420 (z. B. CAN, FlexRay) verbunden ist. CCU 4440 ist auch kommunikativ verbunden mit einem Lenkungssensor 4455A, a Drosselklappensensor 4455B und einem Bremssensor 4455C. CCU 4440 kann auch mit anderen Einheiten kommunikativ verbunden sein, um Umweltmetadaten 4415 zu empfangen. Solche anderen Einheiten können andere Sensoren, Edge-Vorrichtungen, andere Fahrzeuge usw. sein, sind aber nicht unbedingt darauf beschränkt.
• Es können mehrere sicherheitsrelevante Mitteilungen erfolgen. Zunächst werden Gas-, Lenk- und Bremsbefehle sowie sensorische Rückmeldungen von den Aktuatoren und/oder Sensoren an der CCU empfangen. Darüber hinaus, umgebungs-Metadaten 4415 von einem autonomen Fahrerassistenzsystem (ADAS) oder einem autonomen Fahrersteuergerät (AD ECU) übermittelt werden. Diese Metadaten können z. B. die Art der Straße und des Weges, die Wetterbedingungen und Verkehrsinformationen umfassen. Sie kann dazu verwendet werden, eine einschränkende Bewegungshüllkurve zu erstellen und die Bewegung für die nächsten Minuten vorherzusagen. Wenn zum Beispiel ein Kraftfahrzeug auf einer Vorstadtstraße fährt, kann die Höchstgeschwindigkeit auf 25 oder 35 Meilen pro Stunde beschränkt sein. Wenn ein Befehl von der AD ECU empfangen wird, der nicht mit der Geschwindigkeitsbegrenzung übereinstimmt, kann die CCU dies als Fehler identifizieren (z. B. böswilliger Angriff oder nichtböswilliger Fehler).
• Es können auch andere Redundanzsysteme verwendet werden, um zu sehen, ob das System wiederhergestellt werden kann. Zeitliche Redundanz 4402 kann verwendet werden, um Befehle mehrfach zu lesen und eine Medianabstimmung durchzuführen. Informationsredundanz 4404 kann verwendet werden, um Werte mehrfach zu verarbeiten und mehrere Kopien im Speicher abzulegen. Darüber hinaus kann eine Mehrheitsentscheidung 4406 verwendet werden, um Steuerbefehle für die ECUs zu planen. Wenn die Redundanzpläne nicht dazu führen, dass sich das System von dem Fehler erholt, kann die CCU das Fahrzeug sicher anhalten. Bei 4408 können andere Sicherheitskontrollen beispielsweise die Erstellung einer Hypothese für den Bewegungsvektor des Fahrzeugs, die Beschränkung der Bewegung innerhalb der Hypothesenhüllkurve und das Anhalten des Fahrzeugs umfassen, wenn die Kontrollwerte außerhalb der Hüllkurve liegen.
• 45 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung eines beispielhaften Betriebsablaufs 4500 eines Fehler- und Angriffserkennungssystems für hochautomatisierte und autonome Fahrzeuge gemäß mindestens einer Ausführungsform. In 45 werden mehrere Vorgänge innerhalb einer CCU 4540 gezeigt. Die CCU 4540 ist ein Beispiel für die CCU 3840 und veranschaulicht mögliche Vorgänge und Aktivitäten, die in der CCU 3840 stattfinden können. Die Operationen entsprechen den Algorithmen eines zeitlichen Normalverhaltensmodells (z. B. 3841). Eine HMM-Auswertung 4542 entspricht einem Fahrzeugverhaltensmodell (z. B. 3842), eine Regressionsauswertung 4544 entspricht einem Regressionsmodell (z. B. 3844), und ein Wahrscheinlichkeitsvergleich 4546 entspricht einem Komparator (z. B. 3846).
• Steuerereignisse 4502 werden von CCU 4540 empfangen und können in sowohl der HMM-Auswertung 4542 als auch der Regressionsauswertung 4544 verwendet werden. Ein Steuerungsereignis kann von einem Fahrerbefehl, von Sensoren eines autonomen Fahrzeugs, die die nächste Aktion des Fahrzeugs anzeigen, oder von einer Rückkopplungsschleife der Sensoren oder Aktoren ausgehen. Mit der HMM-Auswertung kann die Wahrscheinlichkeit ermittelt werden, dass es sich bei der durch das Steuerereignis angezeigten Bewegungsänderung um einen Fehler handelt. HMM-Bewertung 4542 kann auch Sensordaten 4555 (z. B. Drosselklappensensordaten, Lenksensordaten, Reifendrucksensordaten usw.) empfangen, um festzustellen, ob es sich bei der Bewegungsänderung um ein normales Verhalten handelt oder ob sie auf einen Fehler hindeutet. Das Fahrzeugverhaltensmodell kann eine Rückmeldung 4504 von einem Komparator (z. B. 3846) empfangen, wobei die Rückmeldung das Fahrzeugverhaltensmodell modifiziert, um zuvor begangene Fehler zu erkennen und ähnliche Fälle zu identifizieren (z. B. basierend auf Ort und/oder Zeit). Dementsprechend kann die HMM-Bewertung 4542 je nach Rückmeldung von einem Komparator unterschiedlich ausfallen.
• Die Regressionsauswertung 4544 sagt die Wahrscheinlichkeit voraus, dass eine Bewegungsänderung, die durch ein Kontrollereignis angezeigt wird, in einem bestimmten Zeitintervall t unter normalen Bedingungen eintritt. Zu den Eingaben für die Regressionsauswertung können Sensordaten 4555 und Eingabedaten aus entfernten Datenquellen 4530 (z. B. andere Edge-Vorrichtungen 3830) gehören. Darüber hinaus kann eine Rückmeldung 4504 aus der Cloud (z. B. vom Cloud-Fahrzeugdatensystem 3820) das Regressionsmodell aktualisieren, das die Regressionsauswertung 4544 durchführt, wobei das Regressionsmodell aktualisiert wird, um das Fahrzeugverhalten zu optimieren und vom Lernen in anderen Fahrzeugen zu profitieren.
• In einem Beispiel erzeugt die Regressionsauswertung 4544 eine Bewegungshüllkurve, die durch einen oder mehrere Grenz- oder Schwellenwerte für normales Fahrzeugverhalten auf der Grundlage der Prüfung der Eingaben von Sensoren, anderen Modellen, anderen Edge-Vorrichtungen usw. definiert ist. Die Regressionsauswertung 4544 kann dann feststellen, ob die durch ein Steuerereignis angezeigte Bewegungsänderung außerhalb eines oder mehrerer Grenz- oder Schwellenwerte der Bewegungshüllkurve liegt.
• Der Wahrscheinlichkeitsvergleich 4546 kann auf der Grundlage der Ausgangsklassifizierung der Bewegungsänderung aus der HMM-Auswertung 4542 und der Ausgabevorhersage aus der Regressionsauswertung 4544 ausgeführt werden. Die Ausgangsklassifizierung aus der HMM-Auswertung kann einen Hinweis auf die Wahrscheinlichkeit geben, dass es sich bei einer Bewegungsänderung um einen Fehler handelt (z. B. einen böswilligen Angriff oder einen Fehler im Computersystem des Fahrzeugs). Die Ergebnisvorhersage aus der Regressionsauswertung 4544 kann eine Wahrscheinlichkeit sein, dass die Bewegungsänderung in dem gegebenen Zeitintervall t eintritt, basierend auf Eingabedaten von Sensoren, Edge-Vorrichtungen, anderen Modellen im Fahrzeug usw. Wenn die Ausgangsvorhersage aus der Regressionsauswertung anzeigt, dass es unwahrscheinlich ist, dass die Bewegungsänderung während des gegebenen Zeitintervalls t auftritt, und wenn die Ausgangsklassifizierung aus der HMM-Auswertung anzeigt, dass es sich bei der Bewegungsänderung wahrscheinlich um einen Fehler handelt, dann kann die Vorhersage außerhalb einer Bewegungshüllkurvengrenze oder eines Schwellenwerts liegen und die Ausgangsklassifizierung kann außerhalb eines normalen Schwellenwerts liegen, wie bei 4547 angegeben, und ein Fehlersignal 4506 kann an geeignete Steuergeräte gesendet werden, um Korrekturmaßnahmen zu ergreifen, und/oder an geeignete Instrumentenanzeigen. Wenn die Ausgangsvorhersage aus der Regressionsauswertung anzeigt, dass die Bewegungsänderung wahrscheinlich während des gegebenen Zeitintervalls t auftritt, und wenn die Ausgangsklassifizierung durch die HMM-Auswertung anzeigt, dass die Bewegungsänderung wahrscheinlich kein Fehler ist (z. B. dass sie wahrscheinlich normal ist), dann kann die Vorhersage innerhalb einer Bewegungshüllkurvengrenze oder eines Schwellenwerts liegen und die Ausgangsklassifizierung kann innerhalb eines normalen Schwellenwerts liegen, wie bei 4548 angegeben, und die Aktion 4508 zur Verursachung der durch das Steuerereignis angezeigten Bewegungsänderung wird zugelassen. Zumindest bei einigen Implementierungen kann ein Signal gesendet werden, um die Aktion zu ermöglichen. In anderen Implementierungen kann die Aktion auch ohne Fehlersignal erfolgen.
• In anderen Szenarien können die Ergebnisvorhersage durch die Regressionsauswertung 4544 und die Ergebnisklassifizierung durch die HMM-Auswertung 4542 im Widerspruch zueinander stehen. Wenn beispielsweise die Ausgangsvorhersage der Regressionsauswertung anzeigt, dass die Bewegungsänderung während des gegebenen Zeitintervalls t wahrscheinlich nicht auftritt, und wenn die Ausgangsklassifizierung der HMM-Auswertung anzeigt, dass es sich bei der Bewegungsänderung wahrscheinlich nicht um einen Fehler handelt (z. B. um ein normales Verhalten), dann wird ein Fehlersignal 4506 an die entsprechenden Steuergeräte zur Steuerung des Fahrzeugverhaltens und/oder an die entsprechenden Instrumentenanzeigen gesendet. Dies kann darauf zurückzuführen sein, dass bei der Regressionsauswertung zusätzliche Bedingungen und Faktoren (z. B. aus anderen Sensordaten, Umgebungsdaten usw.) berücksichtigt werden, die die Bewegungshüllkurve so einschränken, dass die Bewegungsänderung außerhalb eines oder mehrerer Grenz- oder Schwellenwerte der Bewegungshüllkurve liegt und unter diesen spezifischen Bedingungen und Faktoren nicht zu erwarten ist. Folglich kann die Regressionsauswertung zu einem Fehlersignal führen, auch wenn die Ausgangsklassifizierung durch die HMM-Auswertung anzeigt, dass die Änderung der Bewegung normal ist.
• In einem anderen Beispiel, wenn die Ausgangsvorhersage durch die Regressionsauswertung anzeigt, dass die durch ein Steuerereignis angezeigte Bewegungsänderung wahrscheinlich während des gegebenen Zeitintervalls t auftritt, und wenn die Ausgangsklassifizierung durch die HMM-Auswertung anzeigt, dass die Bewegungsänderung wahrscheinlich ein Fehler ist, dann kann ein Schwellenwert ausgewertet werden, um zu bestimmen, ob die Ausgangsklassifizierung aus der HMM-Auswertung eine Fehlerwahrscheinlichkeit anzeigt, die einen gewünschten Schwellenwert überschreitet. Wenn beispielsweise die HMM-Ausgangsklassifizierung eine Wahrscheinlichkeit von 95 % angibt, dass es sich bei der Bewegungsänderung um ein anormales Verhalten handelt, die Regressionsauswertungs-Ausgangsvorhersage jedoch angibt, dass die Bewegungsänderung wahrscheinlich ist, weil sie innerhalb der Grenzen oder Schwellenwerte der vorhergesagten Bewegungshüllkurve liegt, kann die HMM-Ausgangsklassifizierung ausgewertet werden, um festzustellen, ob die Wahrscheinlichkeit eines anormalen Verhaltens einen gewünschten Schwellenwert überschreitet. Wenn ja, dann wird ein Fehlersignal 4506 an entsprechende Steuergeräte gesendet, um das Fahrzeugverhalten zu steuern oder anderweitig zu beeinflussen, und/oder an entsprechende Instrumentenanzeigen. Wird jedoch ein gewünschter Schwellenwert nicht überschritten, kann die Aktion, die die Bewegungsänderung hervorruft, aufgrund der Regressionsauswertung unter Berücksichtigung zusätzlicher Bedingungen und Faktoren (z. B. aus anderen Sensordaten, Umgebungsdaten usw.), die die Bewegungshüllkurve lockern, zugelassen werden, so dass die Bewegungsänderung innerhalb der Grenzen oder Schwellenwerte der Bewegungshüllkurve liegt und das erwartete Verhalten unter diesen spezifischen Bedingungen und Faktoren darstellt.
• Zusätzlich kann eine Abtastwertaufbewahrung 4549 der Ergebnisse des Wahrscheinlichkeitsvergleichs 4546 für bestimmte Steuerereignisse (oder alle Steuerereignisse) gespeichert und zum erneuten Trainieren des Fahrzeugverhaltensmodells und/oder des Regressionsmodells verwendet und/oder gespeichert und zur Auswertung verwendet werden.
• 46 ist ein vereinfachtes Flussdiagramm, das Folgendes veranschaulicht detaillierten möglichen Ablauf 4600 von Vorgängen im Zusammenhang mit einem Fehler- und Angriffserkennungssystem, wie z. B System 3800. In mindestens einer Ausführungsform entspricht eine Reihe von Vorgängen den Aktivitäten von 46. Eine CCU in einem Fahrzeug, wie z. B CCU 3840 in Fahrzeug 3850 kann zumindest einen Teil des Satzes von Operationen verwenden. Fahrzeug 3850 kann einen oder mehrere Datenprozessoren (z. B. 3857) zur Durchführung der Operationen umfassen. In mindestens einer Ausführungsform führt Fahrzeugverhaltensmodell 3842 eine oder mehrere der Operationen durch.
• Bei 4602 wird ein Steuerereignis von Fahrzeugverhaltensmodell 3842 empfangen. Bei 4604 werden die Sensordaten des Fahrzeugs durch das Fahrzeugverhaltensmodell ermittelt. Bei 4606 wird das Fahrzeugverhaltensmodell verwendet, um eine durch das Steuerereignis angezeigte Bewegungsänderung (z. B. Bremsen, Beschleunigen, Lenken) als Fehler oder nicht als Fehler zu klassifizieren. In mindestens einer Ausführungsform kann die Klassifizierung einen Hinweis auf die Wahrscheinlichkeit geben, dass es sich bei der Bewegungsänderung um einen Fehler handelt (z. B. Wahrscheinlichkeit). Bei 4608 wird die Ausgangsklassifizierung der Bewegungsänderung an den Komparator übermittelt.
• 47 ist ein vereinfachtes Flussdiagramm, das einen detaillierten möglichen Ablauf 4700 von Vorgängen im Zusammenhang mit einem Fehler- und Angriffserkennungssystem, wie z. B System 3800, darstellt. In mindestens einer Ausführungsform entspricht eine Reihe von Vorgängen den Aktivitäten von 47. Eine CCU in einem Fahrzeug, wie z. B CCU 3840 in Fahrzeug 3850 kann zumindest einen Teil des Satzes von Operationen verwenden. Fahrzeug 3850 kann einen oder mehrere Datenprozessoren (z. B. 3857) zur Durchführung der Operationen umfassen. In mindestens einer Ausführungsform führt Regressionsmodell 3844 eine oder mehrere der Operationen durch.
• Bei 4702 wird ein Steuerereignis von Regressionsmodell 3844 empfangen. Das Steuerereignis zeigt eine Bewegungsänderung wie Bremsen, Lenken oder Beschleunigen an. Bei 4704 werden die Sensordaten des Fahrzeugs durch das Regressionsmodell ermittelt. Bei 4706 werden relevante Daten aus anderen Quellen (z. B. Fernquellen wie Edge-Vorrichtungen 3830, lokale Quellen, die im Fahrzeug heruntergeladen und aktualisiert werden, usw.) durch das Regressionsmodell ermittelt.
• Bei 4708 wird das Regressionsmodell verwendet, um die Wahrscheinlichkeit vorherzusagen, dass die durch das Steuerereignis angezeigte Bewegungsänderung während eines bestimmten Zeitintervalls t eintritt. Die Vorhersage basiert zumindest teilweise auf Sensordaten und Daten aus anderen Quellen. Bei 4710 wird die Ausgangsvorhersage der Wahrscheinlichkeit, dass die Bewegungsänderung während des Zeitintervalls t eintritt, an den Komparator übermittelt.
• 48A ist ein vereinfachtes Flussdiagramm, das einen detaillierten möglichen Ablauf 4800 von Vorgängen im Zusammenhang mit einem Fehler- und Angriffserkennungssystem, wie z. B System 3800. In mindestens einer Ausführungsform entspricht eine Reihe von Vorgängen den Aktivitäten von 47. Eine CCU in einem Fahrzeug, wie z. B CCU 3840 in Fahrzeug 3850 kann zumindest einen Teil des Satzes von Operationen verwenden. Fahrzeug 3850 umfasst einen oder mehrere Datenprozessoren (z. B. 3857) zur Durchführung der Operationen. In mindestens einer Ausführungsform führt Komparator 3846 eine oder mehrere der Operationen durch.
• Bei 4802 wird eine Klassifizierung einer Bewegungsänderung für ein Fahrzeug von dem Fahrzeugverhaltensmodell empfangen. Die Ausgangsklassifizierung, die dem Komparator bei 4608 von 46 bereitgestellt wird, entspricht dem Empfang der Klassifizierung aus dem Fahrzeugverhaltensmodell bei 4802 von 48A.
• Bei 4804 wird vom Regressionsmodell eine Vorhersage über die Wahrscheinlichkeit erhalten, dass die Bewegungsänderung während des Zeitintervalls t auftritt. Die Ausgangsprognose, die dem Komparator bei 4710 von 47 bereitgestellt wird, entspricht dem Empfang der Vorhersage bei 4804 von 48A.
• Bei 4806 vergleicht der Komparator die Klassifizierung der Bewegungsänderung mit der Vorhersage der Wahrscheinlichkeit, dass die Bewegungsänderung während des Zeitintervalls t auftritt. Bei 4808 wird bestimmt, ob die vom Fahrzeugverhaltensmodell klassifizierte Bewegungsänderung innerhalb eines Schwellenwerts (oder Grenzwerts) des vom Regressionsmodell vorhergesagten erwarteten Fahrzeugverhaltens liegt. Wenn die vom Fahrzeugverhaltensmodell klassifizierte Bewegungsänderung innerhalb des vom Regressionsmodell vorhergesagten Schwellenwerts des erwarteten Fahrzeugverhaltens liegt, kann im Allgemeinen bei 4810 ein Signal gesendet werden, um die Bewegungsänderung zuzulassen (oder die Bewegungsänderung kann bei Ausbleiben eines Fehlersignals fortgesetzt werden). Wenn die vom Fahrzeugverhaltensmodell klassifizierte Bewegungsänderung nicht innerhalb des vom Regressionsmodell vorhergesagten Schwellenwerts (oder Grenzwerts) des Fahrzeugverhaltens liegt, kann bei 4812 ein Fehlersignal gesendet werden, um den Fahrer zu warnen, Korrekturmaßnahmen zu ergreifen, oder um das autonome Fahrsystem zu alarmieren, Korrekturmaßnahmen zu ergreifen. Eine ausführlichere Diskussion der möglichen Komparatoroperationen findet sich in 48B.
• 48B ist ein vereinfachtes Flussdiagramm, das einen detaillierten möglichen Ablauf 4850 von zusätzlichen Operationen veranschaulicht, die einer Komparatoroperation wie in 48A gezeigt, und zwar bei 4808 zugeordnet sind.
• Bei 4852 wird festgestellt, ob die folgenden Bedingungen zutreffen: Die Ausgangsklassifizierung des Fahrzeugverhaltensmodells (z. B. HMM) weist auf einen Fehler hin, und die Ausgangsvorhersage des Regressionsmodells weist auf einen Fehler auf der Grundlage desselben Steuerereignisses hin. Wenn beide Bedingungen erfüllt sind, kann bei 4854 ein Fehlersignal (oder ein Steuersignal) gesendet werden, um den Fahrer zu alarmieren, Korrekturmaßnahmen zu ergreifen, oder um das autonome Fahrsystem zu alarmieren, Korrekturmaßnahmen zu ergreifen.
• Wenn mindestens eine Bedingung in 4852 nicht zutrifft, wird in 4856 bestimmt, ob die folgenden beiden Bedingungen zutreffen: Die Ausgangsklassifizierung des Fahrzeugverhaltensmodells zeigt einen Fehler an, und die Ausgangsvorhersage des Regressionsmodells zeigt keinen Fehler auf der Grundlage desselben Steuerereignisses an. Wenn beide Bedingungen erfüllt sind, wird bei 4858 eine weitere Bestimmung vorgenommen, ob die Ausgangsklassifizierung des Fahrzeugverhaltensmodells einen gewünschten Schwellenwert überschreitet, der die Ausgabe des Regressionsmodells außer Kraft setzen kann. Wenn dies der Fall ist, kann bei 4854 ein Fehlersignal (oder ein Kontrollsignal) gesendet werden, um den Fahrer zu warnen, Korrekturmaßnahmen zu ergreifen, oder um das autonome Fahrsystem zu alarmieren, Korrekturmaßnahmen zu ergreifen. Ist dies nicht der Fall, kann bei 4860 ein Signal gesendet werden, damit das durch das Steuerereignis angezeigte Fahrzeugverhalten fortgesetzt werden kann (oder die Änderung der Bewegung kann fortgesetzt werden, wenn kein Fehlersignal vorliegt).
• Wenn mindestens eine Bedingung in 4856 nicht erfüllt ist, wird in 4862 ermittelt, ob die folgenden Bedingungen erfüllt sind: die Ausgangsklassifizierung des Fahrzeugverhaltensmodells keinen Fehler anzeigt und die Ausgangsvorhersage des Regressionsmodells auf der Grundlage desselben Steuerereignisses einen Fehler anzeigt. Wenn beide Bedingungen erfüllt sind, kann bei 4864 ein Fehlersignal (oder ein Steuersignal) gesendet werden, um den Fahrer zu warnen, Korrekturmaßnahmen zu ergreifen, oder um das autonome Fahrsystem zu alarmieren, Korrekturmaßnahmen zu ergreifen.
• Wenn mindestens eine Bedingung in 4862 nicht erfüllt ist, dann sollten in 4866 die folgenden Bedingungen erfüllt sein: die Ausgangsklassifizierung des Fahrzeugverhaltensmodells keinen Fehler anzeigt und die Ausgangsvorhersage des Regressionsmodells auf der Grundlage desselben Steuerereignisses keinen Fehler anzeigt. Wenn beide Bedingungen erfüllt sind, kann bei 4868 ein Signal gesendet werden, um das durch das Steuerereignis angezeigte Verhalten des Fahrzeugs fortzusetzen (oder die Änderung der Bewegung kann fortgesetzt werden, wenn kein Fehlersignal vorliegt).
• Ein Ansatz, bei dem kontinuierlich Daten gesammelt werden, um Kl-Algorithmen für ein autonomes Fahrzeug zu trainieren, kann Probleme mit der Skalierbarkeit (aufgrund der großen Menge an erforderlichen Daten und der zu fahrenden Kilometer, um diese Daten zu erhalten) und der genauen Verfügbarkeit (die Wahrscheinlichkeit, dass eine ausreichende Anzahl von Datensätzen vorhanden ist, um alle möglichen Straßenszenarien abzudecken, denen ein autonomes Fahrzeug begegnen könnte) aufwerfen. Dementsprechend können autonome Fahrzeuge von effizienteren und umfangreicheren Datensätzen für das Training von KI-Systemen für autonome Fahrzeuge profitieren. In verschiedenen Ausführungsformen der vorliegenden Offenbarung können Datensätze verbessert werden, indem ein Datensatz kategorisiert wird, um den Erfassungsprozess für jede Kategorie zu steuern. In einigen Ausführungsformen kann jeder Datensatz auf der Grundlage seiner Kategorie bewertet werden, und die Bewertung des Datensatzes kann verwendet werden, um Verarbeitungstechniken für die gesammelten Daten zu bestimmen.
• In einer bestimmten Ausführungsform werden die von autonomen Fahrzeugen gesammelten Daten einer neuartigen Verarbeitung unterzogen, die eine Kategorisierung, Bewertung und Verarbeitung auf der Grundlage der Kategorisierung oder Bewertung umfasst. In verschiedenen Ausführungsformen kann diese neuartige Verarbeitung (oder ein oder mehrere Teilbereiche davon) offline von einem mit dem autonomen Fahrzeug vernetzten Rechnersystem (z. B. Fernverarbeitungssystem 4904) (z. B. in der Cloud) und/oder online von einem Rechnersystem des autonomen Fahrzeugs (z. B. autonomes Fahrzeugrechnersystem 4902) durchgeführt werden.
• 49 zeigt einen Ablauf der Datenkategorisierung, -bewertung und - verarbeitung gemäß bestimmten Ausführungsformen. 1 zeigt ein autonomes Fahrzeug-Rechensystem 4902, das mit einem entfernten Verarbeitungssystem 4904 gekoppelt ist. Jedes der verschiedenen Module in den Systemen 4902 und 4904 kann mit jeder geeigneten Computerlogik implementiert werden. Das autonome Fahrzeug-Rechensystem 4902 kann über jede geeignete Verbindung, einschließlich Punkt-zu-Punkt-Verbindungen, Netzwerke, Fabrics usw., mit dem entfernten Verarbeitungssystem 4904 gekoppelt werden, um Daten vom Fahrzeug an das entfernte Verarbeitungssystem zu übertragen (z. B. ein spezielles Gerät, das Daten aus dem Kraftfahrzeug kopiert und dann die Daten erneut in einen Cloud-Cluster kopiert). In anderen Ausführungsformen können Daten aus dem System 4902 dem System 4904 (oder umgekehrt) über einen geeigneten Kommunikationskanal zur Verfügung gestellt werden (z. B. durch Entfernen des Speichers, der diese Daten umfasst, aus einem der Systeme und Kopplung mit dem anderen). Das autonome Fahrzeug-Rechensystem 4902 kann in ein autonomes Fahrzeug integriert werden, das alle geeigneten Komponenten oder Merkmale anderer hierin beschriebener Fahrzeuge aufweisen kann, und das Fernverarbeitungssystem 4904 kann alle geeigneten Komponenten oder Merkmale anderer hierin beschriebener Fernverarbeitungssysteme (z. B. Cloud) aufweisen. Beispielsweise kann das Fernverarbeitungssystem 4904 alle geeigneten Merkmale der Systeme 140 oder 150 und das Rechensystem 4902 alle geeigneten Merkmale des Rechensystems des Fahrzeugs 105 aufweisen.
• In diesem Fluss werden verschiedene Datenströme 4906 vom Fahrzeug 4902 erfasst. Jeder Datenstrom 4906 kann von einem Sensor des Fahrzeugs, wie einem oder mehreren der hier beschriebenen Sensoren oder anderen geeigneten Sensoren, erfasst werden. Die Datenströme 4906 können in einem Speichermedium 4908 des Fahrzeugs gespeichert und auch in das entfernte Verarbeitungssystem 4904 hochgeladen werden.
• Die Datenströme können an einen Objektdetektor mit künstlicher Intelligenz (KI) 4910 weitergeleitet werden. Der Detektor 4910 kann Operationen im Zusammenhang mit der Objekterkennung durchführen. In einer bestimmten Ausführungsform kann der Detektor 4910 ein Trainingsmodul und ein Inferenzmodul umfassen. Das Trainingsmodul kann für das Training des Inferenzmoduls verwendet werden. Beispielsweise kann das Trainingsmodul im Laufe der Zeit mehrere hochgeladene Datensätze analysieren, um Parameter zu bestimmen, die vom Schlussfolgerungsmodul verwendet werden sollen. Ein hochgeladener Datenstrom kann als Eingabe in das Inferenzmodul eingespeist werden, und das Inferenzmodul kann Informationen ausgeben, die mit einem oder mehreren erkannten Objekten 4912 verbunden sind.
• Das Format der Ausgabe des Inferenzmoduls des Objektdetektors 4910 kann je nach Anwendung variieren. Ein Beispiel: Die Informationen über erkannte Objekte 4912 können ein oder mehrere Bilder mit einem oder mehreren erkannten Objekten umfassen. Beispielsweise kann die Information 4912 über erkannte Objekte einen Interessenbereich eines größeren Bildes umfassen, wobei der Interessenbereich ein oder mehrere erkannte Objekte umfasst. In einigen Ausführungsformen umfasst jede Instanz der Informationen über erkannte Objekte 4912 ein Bild eines Objekts von Interesse. In einigen Fällen kann das Objekt von Interesse mehrere erkannte Objekte umfassen. So kann ein erkanntes Fahrzeug beispielsweise mehrere erkannte Objekte wie Räder, einen Rahmen, Fenster usw. umfassen. In verschiedenen Ausführungsformen können die Informationen zu den erkannten Objekten 4912 auch Metadaten umfassen, die mit dem/den erkannten Objekt(en) verbunden sind. Beispielsweise können die Metadaten für jedes in einer Instanz von Informationen über erkannte Objekte 4912 erkannte Objekt einen oder mehrere Klassifikatoren umfassen, die den Typ eines Objekts (z. B. Fahrzeug, Baum, Fußgänger usw.), eine Position (z. B. Koordinaten) des Objekts, die Tiefe des Objekts, den mit dem Objekt verbundenen Kontext (z. B. einen der hier beschriebenen Kontexte, wie die Tageszeit, die Art der Straße oder den geografischen Standort, der mit der Erfassung der zur Erkennung des Objekts verwendeten Daten verbunden ist) oder andere geeignete Informationen beschreiben.
• Die Informationen zu den erkannten Objekten 4912 können dem Objektprüfer 4914 zur weiteren Verarbeitung übergeben werden. Der Objekt-Checker 4914 kann irgendeine Anzahl von Checkern umfassen, die Ausgaben liefern, die dazu dienen, der Instanz der erkannten Objektinformationen 4912 eine Kategorie zuzuweisen. In der dargestellten Ausführungsform umfasst die Objektprüfung 4914 eine Prüfung des besten bekannten Objekts (BKO) 4916, eine Prüfung der Objektvielfalt 4918 und eine Rauschprüfung 4920, obwohl jede geeignete Prüfung oder Kombination von Prüfungen im Rahmen dieser Offenbarung in Betracht gezogen wird. In verschiedenen Ausführungsformen können die Prüfer eines Objektprüfers 4914 ihre Operationen parallel zueinander oder nacheinander durchführen.
• Zusätzlich zu den Informationen über die erkannten Objekte 4912 kann der Objekt-Checker 4914 auch die hochgeladenen Datenströme empfangen. In verschiedenen Ausführungsformen können einer oder mehrere der BKO-Prüfer 4916, Objektdiversitätsprüfer 4918 und Rauschprüfer 4920 die Rohdatenströme verwenden.
• Ansprechend auf den Empfang einer Instanz von Informationen über erkannte Objekte 4912 konsultiert der BKO-Checker 4916 die BKO-Datenbank (DB) 4922, um den Grad der Gemeinsamkeit von einem oder mehreren erkannten Objekten der Instanz der Informationen über erkannte Objekte 4912 zu bestimmen. BKO DB 4922 ist eine Datenbank, in der Hinweise auf die bekanntesten (z. B. am häufigsten entdeckten) Objekte gespeichert werden. In einigen Ausführungsformen kann die BKO DB 4922 eine Liste der bekanntesten Objekte umfassen, und Objekte, die nicht in dieser Liste umfassen sind, können als nicht bekannteste Objekte betrachtet werden, so dass der Grad der Gemeinsamkeit eines bestimmten Objekts durch einen binären Wert (bekanntestes oder nicht bekanntestes Objekt) ausgedrückt werden kann. In anderen Ausführungsformen kann die BKO DB 4922 einen feineren Grad der Gemeinsamkeit für jedes Objekt aus einer Mehrzahl von Objekten umfassen. Zum Beispiel kann BKO DB 4922 für jedes Objekt eine Bewertung aus einem Bereich (z. B. von 0 bis 10) umfassen. In bestimmten Ausführungsformen können für jedes Objekt mehrere Grade der Gemeinsamkeit gespeichert werden, wobei jeder Grad den Grad der Gemeinsamkeit des Objekts für einen bestimmten Kontext angibt. So kann beispielsweise ein Fahrrad auf den Straßen der Stadt einen hohen Grad der Gemeinsamkeit aufweisen, auf den Autobahnen jedoch einen niedrigen Grad der Gemeinsamkeit. Ein weiteres Beispiel: Ein Tier wie ein Esel oder ein Pferd, das einen Karren zieht, kann bis auf wenige Ausnahmen in allen Kontexten und Regionen der Welt einen geringen Grad der Gemeinsamkeit aufweisen. Es kann auch ein Kombinationsgrad der Gemeinsamkeit bestimmt werden, z. B. sind ein oder mehrere Mopeds, die auf der Fahrbahn fahren, in südostasiatischen Ländern auch auf Autobahnen häufiger als in westlichen Ländern. Die Gemeinsamkeitsbewertung (commonness score) kann je nach dem spezifischen Regelsatz, der für eine bestimmte Umgebung gilt, definiert werden.
• Die BKO DB 4922 kann dynamisch aktualisiert werden, wenn Daten gesammelt werden. Zum Beispiel kann die Logik der BKO DB 4922 Informationen zur Identifizierung eines erkannten Objekts vom BKO Checker 4916 (z. B. können solche Informationen in einer Anforderung nach dem Grad der Gemeinsamkeit des Objekts umfassen sein) oder von einer anderen Einheit (z. B. Objektdetektor 4910) erhalten. In verschiedenen Ausführungsformen können die Informationen auch den mit dem erkannten Objekt verbundenen Kontext umfassen. Die Logik kann Informationen in der BKO DB 4922 aktualisieren, die angeben, wie oft und/oder wie häufig das bestimmte Objekt erkannt wurde. In einigen Ausführungsformen kann die Logik auch feststellen, ob sich der Grad der Gemeinsamkeit des Objekts geändert hat (z. B. wenn die Häufigkeit, mit der das Objekt erkannt wurde, einen Schwellenwert überschritten hat, kann der Grad der Gemeinsamkeit des Objekts steigen).
• Als Antwort auf eine Anfrage des BKO-Checkers 4916 kann die BKO-DB 4922 einen Grad der Gemeinsamkeit des Objekts zurückgeben. Der BKO-Checker 4916 gibt diese Stufe dann an den Kategoriezuweiser 24 weiter.
• Der Objects Diversity Checker 4918 bewertet eine Instanz der erkannten Objektinformationen 4912 auf der Grundlage der Diversität (z. B. ob der Strom mit Objekten divers ist oder nicht, was auf der Anzahl der Objekte pro Strom und der Gemeinsamkeit der einzelnen Objekte basieren kann). Die Diversitätsbewertung einer Instanz von Informationen über erkannte Objekte 4912 kann höher sein, wenn die Instanz eine große Anzahl von erkannten Objekten umfasst, und noch höher, wenn die erkannten Objekte heterogen sind. Beispielsweise kann ein erkanntes Kraftfahrzeug oder Fahrrad eine Mehrzahl von erkannten Objekten (z. B. Räder, Rahmen usw.) umfassen und eine relativ hohe Diversitätsbewertung erhalten. Homogene Objekte können jedoch zu relativ niedrigen Diversitätswerten führen. Mehrere Objekte, die selten zusammen gesehen werden, können jedoch eine relativ hohe Diversitätsbewertung erhalten. So können beispielsweise mehrere Fahrräder in einem Rennen oder mehrere Läufer auf der Straße (z. B. bei einem Marathon) im Vergleich zu einer Szene mit einer laufenden Person als vielfältig angesehen werden. Der Objektdiversitätsprüfer 4918 kann die Diversität auf der Grundlage aller geeigneten Informationen bestimmen, wie z. B. den Sensor-Rohdaten, den Angaben zu erkannten Objekten vom BKO-Prüfer 4916 und der Anzahl der erkannten Objekte vom BKO-Prüfer 4916.
• Der Noise Checker 4920 analysiert die hochgeladenen Datenströme, die mit einer Instanz von erkannten Objekten (4912) verbunden sind, und bestimmt einen Noise Score, der mit der Instanz verbunden ist. So kann eine Instanz beispielsweise eine höhere Bewertung erhalten, wenn die zugrunde liegenden Datenströme ein geringes Signal-Rausch-Verhältnis aufweisen. Wenn einer oder mehrere der zugrundeliegenden Datenströme verfälscht zu sein scheinen, ist die Rauschbewertung niedriger.
• Der Kategoriezuweiser 4924 empfängt die Ausgaben der verschiedenen Prüfer des Objektprüfers 4914 und wählt auf der Grundlage der Ausgaben der Prüfer eine oder mehrere Kategorien für die Instanz der erkannten Objektinformationen 4912 aus. Diese Offenbarung bezieht sich auf alle geeigneten Kategorien, die zur Beeinflussung der Datenverarbeitungspolitik verwendet werden können. Einige Beispielkategorien sind Common Data (gemeinsame Daten), Minority Class Data (Minderheitsklassendaten), Data Rich of Diverse Objects (Daten mit vielen verschiedenen Objekten) und Noisy Data (verrauschte Daten). Eine oder mehrere dieser Kategorien können auf der Grundlage der von der Objektprüfung 4914 erhaltenen Ergebnisse auf die Instanz angewendet werden.
• Die Common Data-Kategorie kann auf Objekte angewandt werden, die häufig vorkommen, so dass das System möglicherweise bereits über solide Datensätze für solche Objekte verfügt. Die Minority Class Data-Kategorie kann auf Instanzen angewendet werden, die erstmalige oder relativ seltene Objekte umfassen. In verschiedenen Ausführungsformen können sowohl die Common Data- Kategorie als auch die Minority Class Data-Kategorie auf einer absoluten Häufigkeit der Erfassung des Objekts und/oder einer kontextspezifischen Häufigkeit der Erfassung des Objekts beruhen. Die Data Rich of Diverse Objects-Kategorie kann auf Instanzen angewendet werden, die mehrere unterschiedliche Objekte umfassen. Die Noisy Data-Kategorie kann auf Instanzen mit Daten mit relativ starkem Rauschen angewendet werden. In anderen Ausführungsformen können alle geeigneten Kategorien verwendet werden. Die Kategorien können zum Beispiel „Sehr selten“, „Mäßig selten“, „Mäßig häufig“ und „Sehr häufig“ oder „Sehr laut“, „Etwas laut“ und „Nicht laut“ lauten.
• In einigen Ausführungsformen können, nachdem eine oder mehrere Kategorien für eine Instanz der Informationen über erkannte Objekte 4912 ausgewählt wurden (oder keine Kategorien ausgewählt wurden), zusätzliche Metadaten auf der Grundlage der Kategorieauswahl durch das Metadatenmodul 4926 mit der Instanz verknüpft werden. In einer bestimmten Ausführungsform können solche Metadaten eine Bewertung für die Instanz der erkannten Objektinformationen 4912 auf der Grundlage der Kategorieauswahl umfassen. In einer bestimmten Ausführungsform kann die Bewertung die Bedeutung der Daten angeben. Die Bewertung kann auf jede geeignete Weise ermittelt werden. Ein Beispiel: Eine Instanz, die als „Common Data“ kategorisiert ist (oder der eine andere Kategorie zugewiesen wurde, die auf eine hohe Häufigkeit des Auftretens hinweist), kann eine relativ niedrige Bewertung erhalten, da solche Daten die Funktionalität des Systems möglicherweise nicht verbessern, da die Wahrscheinlichkeit hoch ist, dass ähnliche Daten bereits zum Trainieren des Systems verwendet wurden. Ein weiteres Beispiel: Eine Instanz, die als Minority Class Data kategorisiert ist, kann eine relativ hohe Bewertung erhalten, da solche Daten wahrscheinlich noch nicht für das Training des Systems verwendet wurden. Ein weiteres Beispiel: Eine Instanz, die als „Data Rich of Diverse Objects“ kategorisiert wurde, kann eine höhere Bewertung erhalten als eine ähnliche Instanz, die nicht als Data Rich of Diverse Objects kategorisiert wurde, da eine Instanz mit verschiedenen Objekten für Trainingszwecke als nützlicher angesehen werden kann. Ein weiteres Beispiel: Eine Instanz, die als Noisy Data kategorisiert wurde, kann eine niedrigere Bewertung erhalten als eine ähnliche Instanz, die nicht als Noisy Data kategorisiert wurde, da eine Instanz mit höherem Rauschen als weniger nützlich für Trainingszwecke angesehen werden kann.
• In einigen Ausführungsformen können zusätzlich (oder alternativ) zur Bewertung alle geeigneten Metadaten mit der Information 4912 über die erkannten Objekte verknüpft werden. So kann beispielsweise jeder mit den zugrunde liegenden Datenströmen verbundene Kontext in die Metadaten aufgenommen werden, und der Kontext kann sich auf die Bewertung auswirken (z. B. kann Common Data in einem ersten Kontext Minority Data in einem zweiten Kontext sein).
• Die Dateninstanz, die Kategorisierungsentscheidung, die auf der Kategorisierung basierende Bewertung und/oder zusätzliche Metadaten können dem Datenhandler 4930 zur Verfügung gestellt werden. Der Datenhandler 4930 kann eine oder mehrere Aktionen in Bezug auf die Dateninstanz durchführen. Alle geeigneten Maßnahmen werden im Rahmen dieser Offenbarung in Betracht gezogen. So kann der Data Handler 4930 beispielsweise Instanzen mit niedrigeren Bewertungen oder einer bestimmten Kategorie oder Kombination von Kategorien bereinigen. Als weiteres Beispiel kann der Data Handler 4930 Instanzen mit höheren Bewertungen oder einer bestimmten Kategorie oder Kombination von Kategorien speichern. Als weiteres Beispiel kann der Datenhandler 4930 eine Anforderung zur Erzeugung synthetischer Daten generieren, die mit der Instanz verbunden sind (z. B. kann der Datenhandler 4930 die Erzeugung synthetischer Daten anfordern, die mit einem Objekt verbunden sind, das als Minority Class Data klassifiziert ist). Als weiteres Beispiel kann der Datenhandler 4930 eine Anforderung zur Sammlung weiterer Daten in Bezug auf das Objekt der Instanz durch die Sensoren eines oder mehrerer autonomer Fahrzeuge erzeugen. Als weiteres Beispiel kann der Data Handler 4930 bestimmen, dass die Instanz (und/oder die zugrundeliegenden Datenströme) in einen Datensatz aufgenommen werden soll, der für das Training verwendet werden kann (z. B. durch den Objektdetektor 4910).
• Die Dateninstanz, die Kategorisierungsentscheidung, die auf der Kategorisierung basierende Bewertung und/oder zusätzliche Metadaten können auch dem Datenbewertungs-Trainer 4928 bereitgestellt werden. Der Data Scoring Trainer 4928 trainiert Modelle auf Kategorien und/oder Bewertungen. In verschiedenen Ausführungsformen können die Instanzen der detektierten Objekte und ihre zugehörigen Bewertungen und/oder Kategorien vom Datenbewertungs-Trainer 4928 als Basiswahrheit verwendet werden. Trainer 4928 gibt Trainingsmodelle 4932 aus. Die Trainingsmodelle werden dem Fahrzeug-Kl-System 4934 zur Verfügung gestellt und können vom Fahrzeug verwendet werden, um vom Fahrzeug-Kl-System 4934 erkannte Objekte zu kategorisieren und/oder zu bewerten. In verschiedenen Ausführungsformen werden die Dateninstanzen, die zum Trainieren der Modelle verwendet werden, anhand von Kategorien und/oder Bewertungen gefiltert. So können beispielsweise Instanzen, die häufig vorkommende Objekte umfassen, aus der Trainingsmenge ausgelassen werden.
• Das Fahrzeug-KI-System 4934 kann Schaltkreise und andere Logik umfassen, um alle geeigneten autonomen Fahrvorgänge durchzuführen, wie z. B. einen oder mehrere der Vorgänge eines autonomen Fahrzeugstapels. In einer bestimmten Ausführungsform kann das Fahrzeug-KI-System 4934 Datenströme 4906 empfangen und die Datenströme 4906 verarbeiten, um Objekte zu erkennen.
• Ein bordeigener Kategoriezuweiser 4936 kann eines oder mehrere Merkmale des Kategoriezuweisers 4924 aufweisen. Informationen über eine Instanz der erkannten Objekte (z. B. die erkannten Objekte sowie der Kontext) können dem Kategoriezuweiser 4936 zur Verfügung gestellt werden, der eine oder mehrere Kategorien für die Instanz auswählt (wie eine oder mehrere der oben beschriebenen Kategorien oder andere geeignete Kategorien). In einigen Ausführungsformen kann der Kategoriezuweiser 4936 oder eine andere Logik des Rechensystems 4902 auch (oder alternativ) der Instanz des/der erkannten Objekts/Objekte eine Bewertung zuweisen. In einigen Ausführungsformen kann die Bewertung auf der Kategorisierung der erkannten Objekte durch den Kategoriezuweiser 4936 basieren. In anderen Ausführungsformen kann das autonome Fahrzeug eine Bewertung ermitteln, ohne dass das autonome Fahrzeug ausdrücklich Kategorien festlegt. In verschiedenen Ausführungsformen werden die Kategorien und/oder Bewertungen, die den erkannten Objekten zugewiesen werden, mit einem oder mehreren Modulen für maschinelles Lernen bestimmt, die Parameter verwenden, die vom Datenbewertungs-Trainer 4928 erzeugt werden.
• Die Ausgabe des Kategoriezuweisers 4936 kann an einen fahrzeuginternen Datenhandler 4938 weitergeleitet werden, der eines oder mehrere Merkmale des Datenhandlers 4930 aufweisen kann. In verschiedenen Ausführungsformen kann die Ausgabe des Kategoriezuweisers 4936 auch der BKO DB 4922 zur Verfügung gestellt werden, um die Aktualisierung der BKO-Daten basierend auf dem Online-Lernen und der Bewertung zu erleichtern
• Der Datenhandler 4938 kann eines oder mehrere Merkmale des Datenhandlers 4930 aufweisen. Die Datenverarbeitungseinheit 4938 kann auf der Grundlage der Ausgaben der fahrzeuginternen Kategoriezuweisungseinheit 4936 Entscheidungen über die Behandlung der vom Fahrzeug erfassten Datenströme treffen. Beispielsweise kann der Datenhandler 4938 jede der oben beschriebenen Aktionen durchführen oder andere geeignete Aktionen im Zusammenhang mit den Daten auf der Grundlage der Ausgabe des Kategoriezuweisers 4936 ausführen. Beispielsweise kann der Datenhandler 4938 auf der Grundlage der Datenbewertung bestimmen, ob die mit einem erkannten Objekt verbundenen Daten im Fahrzeug gespeichert oder gelöscht werden sollen.
• In verschiedenen Ausführungsformen kann ein ortsbezogenes Modell, das zur Bewertung der Daten verwendet wird, die Dringlichkeit und Wichtigkeit der Daten zusammenfassen und nützliche Hinweise für eine bessere Entscheidungsfindung durch ein autonomes Fahrzeug liefern. Der Standort der erfassten Daten kann von dem autonomen Fahrzeug-Rechensystem 4902 oder dem entfernten Rechensystem 4904 verwendet werden, um andere kontextbezogene Daten zu erhalten, die mit der Erfassung der Daten verbunden sind, wie z. B. Wetter, Verkehr, Fußgängerströme usw. (z. B. aus einer Datenbank oder einem anderen Dienst, indem der Standort als Eingabe verwendet wird). Solche erfassten Daten können mit einer bestimmten Granularität gesammelt werden, um eine Zeitreihe von Informationen zu bilden. Jedem Datenstrom, der innerhalb eines Radius um den Standort erfasst wird, kann derselbe Standort zugeordnet werden, so dass das Fahrzeug seine Wahrnehmungs- und Entscheidungsfähigkeiten innerhalb dieses Bereichs verbessern kann. Der Standort kann von jedem der oben beschriebenen Module berücksichtigt werden. So kann die BKO DB 4922 beispielsweise ortsspezifische Daten speichern (z. B. eine Reihe von Gemeinsamkeitsgraden verschiedener Objekte für einen ersten Ort, eine separate Liste von Gemeinsamkeitsgraden verschiedener Objekte für einen zweiten Ort usw.).
• 50 zeigt einen beispielhaften Ablauf für die Verarbeitung von Daten auf der Grundlage von Kategorisierungen gemäß bestimmten Ausführungsformen. Bei 5002 wird eine Instanz von einem oder mehreren Objekten aus Daten, die von einem oder mehreren Sensoren eines Fahrzeugs erfasst wurden, identifiziert. Bei 5004 wird eine Kategorisierung der Instanz durchgeführt, indem die Instanz mit einer Mehrzahl von Kategorien verglichen und der Instanz mindestens eine Kategorie aus der Mehrzahl von Kategorien zugewiesen wird. Bei 5006 wird eine Bewertung auf der Grundlage der Kategorisierung der Instanz bestimmt. Bei 5008 wird eine Datenverarbeitungsrichtlinie für die Instanz zumindest teilweise auf der Grundlage der Bewertung ausgewählt. In 5010 wird die Instanz auf der Grundlage der festgelegten Datenverarbeitungsrichtlinie verarbeitet.
• Zur Erstellung qualitativ hochwertiger Modelle für maschinelles Lernen gehört die Verwendung robuster Datensätze beim Training für die Modellerstellung. Im Allgemeinen ist ein Modell nur so gut wie der Datensatz, den es zum Training verwendet. Bei vielen Anwendungen, wie z. B. dem Training auf Bildern zur Objekt- oder Personenidentifikation, ist die Datensatzerfassung recht einfach. In anderen Fällen kann die Erhebung von Datensätzen für weniger häufige Zusammenhänge oder Kombinationen davon jedoch äußerst schwierig sein. Dies stellt eine schwierige Herausforderung für die Modellentwicklung dar, da das Modell unter Umständen einen Kontext auf der Grundlage unzureichender Daten identifizieren oder klassifizieren muss. Im Idealfall haben die Datensätze, die zum Trainieren von Objekterkennungsmodellen verwendet werden, eine gleiche oder ähnliche Menge an Daten für jede Kategorie. Die von den Fahrzeugsensoren erfassten Datensätze sind jedoch im Allgemeinen unausgewogen, da die Fahrzeuge weit mehr positive als negative Daten erhalten.
• In verschiedenen Ausführungsformen der vorliegenden Offenbarung kann ein System synthetische Daten erstellen, um Datensätze zu ergänzen, denen echte Daten für einen oder mehrere Kontexte fehlen. In einigen Ausführungsformen werden die synthetischen Daten von einem generativen adversen Netzwerk (GAN) erzeugt. GAN ist eine Art generatives Modell, das maschinelles Lernen, genauer gesagt Deep Learning, verwendet, um Bilder (z. B. Standbilder oder Videoclips) auf der Grundlage einer Liste von Schlüsselwörtern zu generieren, die dem GAN als Eingabe vorgelegt werden. Der GAN verwendet diese Schlüsselwörter, um ein Bild zu erstellen. In verschiedenen Ausführungsformen wird auch eine Logik eingesetzt, um zu bestimmen, welche Schlüsselwörter dem GAN zur Bilderzeugung zugeführt werden. Die bloße Eingabe von Zufallsdaten in das GAN würde zu einer Mehrzahl unbrauchbarer Daten führen. Bestimmte Kontextkombinationen stimmen möglicherweise nicht mit den Vorkommnissen in der realen Welt überein. Ein Clown mitten auf einer Autobahn in einem Schneesturm in Saudi-Arabien ist zum Beispiel ein so unwahrscheinliches Ereignis, dass es praktisch unmöglich ist. Ein weiteres Beispiel: Es ist unwahrscheinlich (wenn auch weitaus wahrscheinlicher als das vorherige Szenario), dass man auf einer verschneiten Autobahn auf Fahrräder trifft. Dementsprechend kann ein System Bilder für dieses Szenario generieren (z. B. unter Verwendung der Schlüsselwörter „Fahrrad“, „Schnee“ und „Autobahn“), aber nicht für das vorherige Szenario. Durch die intelligente Steuerung der Erzeugung synthetischer Daten kann das System Bilder (für das Training) erzeugen, für die ein Fahrzeug in der Realität sonst sehr viel Zeit benötigen würde.
• Verschiedene Ausführungsformen können für die Demokratisierung der Datenverfügbarkeit und der Modellerstellung von Nutzen sein. Beispielsweise kann der Erfolg eines Unternehmens in einem Bereich wie dem autonomen Fahren als Dienstleistung in hohem Maße von der Menge und der Vielfalt der Datensätze abhängen, die dem Unternehmen zugänglich sind. In einigen Jahren, wenn der Markt ausgereift ist, könnten die bestehenden Akteure, die schon früh mit der Datenerhebung begonnen haben, einen unfairen Vorteil haben, der die Innovationen der neuen Marktteilnehmer verdrängen könnte. Eine solche Datendiskrepanz kann auch die Forschung im akademischen Bereich behindern, es sei denn, eine Einrichtung hat durch ihre Beziehungen zu anderen Stellen, die große Datensätze gesammelt haben, Zugang zu großen Datenmengen. Verschiedene Ausführungsformen können diesen Druck mindern, indem sie die Verfügbarkeit von Daten zum Trainieren von Modellen erhöhen.
• 51 zeigt ein System 5100 zur intelligenten Erzeugung synthetischer Daten in Übereinstimmung mit bestimmten Ausführungsformen. Das System 5100 stellt ein beliebiges geeignetes Rechensystem dar, das beliebige geeignete Komponenten umfasst, wie z. B. einen Speicher zum Speichern von Informationen und einen oder mehrere Prozessoren zur Ausführung der Funktionen des Systems 5100. In der dargestellten Ausführungsform greift das System 5100 auf reale Datenquellen 5102 zu und speichert die realen Datenquellen im Bilddatensatz 5104 und im Nicht-Bildsensordatensatz 5106. Bei den realen Datenquellen 5102 kann es sich um Daten handeln, die von realen Fahrzeugen oder simulierten Fahrumgebungen gesammelt wurden. Zu diesen realen Daten können Bilddaten gehören, wie z. B. Videodaten, die von einer oder mehreren Kameras gestreamt werden, Punktwolken von einem oder mehreren LIDARs oder ähnliche Bilddaten, die von einem oder mehreren Fahrzeugen oder unterstützender Infrastruktur (z. B. Straßenkameras) gewonnen werden. Die gesammelten Bilddaten können im Bilddatensatz 5104 auf einem beliebigen Speichermedium gespeichert werden. Die realen Datenquellen können auch Nicht-Bildsensordaten umfassen, wie z. B. Daten von zahlreichen Sensoren, die mit einem Fahrzeug verbunden sein können. Die Nicht-Bildsensordaten können auch als Zeitreihendaten bezeichnet werden. Diese Daten können jede geeignete Form annehmen, z. B. einen Zeitstempel und einen zugehörigen Wert. Zu den Nicht-Bildsensordaten können z. B. Messungen von Bewegungssensoren, GPS, Temperatursensoren oder anderen im Fahrzeug verwendeten Verfahren gehören, die Daten mit irgendeiner Rate erzeugen. Die gesammelten Nicht-Bild-Sensordaten können in einem Nicht-Bild-Datensatz 5106 unter Verwendung eines geeigneten Speichermediums gespeichert werden.
• Das Kontextextraktionsmodul 5108 kann auf Instanzen der Bilddaten und Nicht-Bildsensordaten zugreifen und einen mit den Daten verbundenen Kontext bestimmen. Die beiden Datentypen können gemeinsam oder getrennt verwendet werden, um einen Kontext zu erzeugen (der eine einzelne Bedingung oder eine Kombination von Bedingungen darstellen kann), wie z. B. einen der hier beschriebenen Kontexte. So können beispielsweise allein die Bilddaten verwendet werden, um den Kontext „Schnee“ zu erzeugen. Als weiteres Beispiel können Bilddaten und Temperaturdaten verwendet werden, um den Kontext „neblig und feucht“ zu erzeugen. In einem weiteren Beispiel können die Sensordaten allein verwendet werden, um einen Kontext „Geschwindigkeitsüberschreitung“ zu erzeugen. Der ermittelte Kontext bzw. die ermittelten Kontexte werden häufig als Metadaten mit den Rohdaten verknüpft.
• Das Kontextextraktionsmodul 5108 kann jede geeignete Form annehmen. In einer bestimmten Ausführungsform implementiert das Modul 5108 einen Klassifizierungsalgorithmus (z. B. einen Algorithmus für maschinelles Lernen), der einen oder mehrere Datenströme als Eingabe empfangen und daraus einen Kontext erzeugen kann. Der ermittelte Kontext wird im Metadaten-/Kontextdatensatz 5110 mit dem zugehörigen Zeitstempel gespeichert, der verwendet werden kann, um den Kontext auf den Rohdatenstrom (z. B. die Bilddaten und/oder den Nicht-Bildsensordatensatz) zurückzuführen. Diese gespeicherten Metadatenströme können einen Bericht über die Fahrbedingungen über einen bestimmten Zeitraum hinweg liefern. Für die Modellentwicklung werden die Bilddaten und die nicht-sensorischen Bilddaten häufig in der Cloud gesammelt, und Datenwissenschaftler und Experten für maschinelles Lernen erhalten Zugang, damit sie Modelle erstellen können, die in verschiedenen Teilen des autonomen Fahrzeugs verwendet werden können.
• Das Modul 5112 zur Bewertung von Schlüsselwörtern untersucht Instanzen der Kontextdaten (wobei ein Kontext ein oder mehrere Metadaten umfassen kann) und ermittelt für jede untersuchte Instanz einen Grad der Gemeinsamkeit, der die Häufigkeit des Auftretens jeder Kontextinstanz angibt. Dieser Grad der Gemeinsamkeit kann ein Hinweis darauf sein, wie oft das System auf den bestimmten Kontext gestoßen ist (sei es durch Kontexte, die auf reale Datenquellen angewandt wurden, oder durch Kontexte, die auf synthetisch erzeugte Bilder angewandt wurden). Der Grad der Gemeinsamkeit für einen bestimmten Kontext kann angeben, wie viele Daten mit diesem bestimmten Kontext dem System zur Verfügung stehen (z. B. für das Modelltraining). Der Grad der Gemeinsamkeit kann in Verbindung mit dem Kontext gespeichert werden (z. B. in dem Metadaten-/Kontextdatensatz 5110 oder an einem anderen geeigneten Speicherort).
• Das Modul 5112 zur Bewertung von Schlüsselwörtern kann den Grad der Gemeinsamkeit auf jede geeignete Weise bestimmen. So kann beispielsweise bei jedem Auftreten einer Kontextinstanz ein für diesen Kontext spezifischer Zähler erhöht werden. In anderen Beispielen kann der Metadaten-/Kontextdatensatz 5110 durchsucht werden, um festzustellen, wie viele Instanzen dieses Kontexts in der Datenbank 5110 gespeichert sind. In einem Beispiel kann ein Kontext, sobald er eine bestimmte Schwellenzahl erreicht hat, als „allgemein bekannt“ oder ähnliches eingestuft werden, so dass er nicht mehr als Kandidat für die Erzeugung synthetischer Bilder ausgewählt wird. In einigen Ausführungsformen kann der Metadaten-/Kontextdatensatz 5110 eine Tabelle von Kontexten mit dem jedem Kontext zugeordneten Grad der Gemeinsamkeit speichern.
• Das Modul 5114 zur Auswahl von Schlüsselwörtern/Kontexten kann auf den Metadaten-/Kontextdatensatz (oder einen anderen Speicher) zugreifen und verschiedene Kontexte und die damit verbundenen Gemeinsamkeitsgrade analysieren, um Kandidaten für die Erzeugung synthetischer Bilder zu identifizieren. In einer bestimmten Ausführungsform sucht das Modul 5114 nach Kontexten, die weniger häufig vorkommen (da das System möglicherweise bereits über genügend Daten für sehr häufig vorkommende Kontexte verfügt). Das Modul 5114 kann nach solchen Kontexten stapelweise suchen, indem es eine Mehrzahl von Kontexten in einer Sitzung analysiert (z. B. regelmäßig oder bei einem Auslöser), oder es kann einen Kontext ansprechend auf eine Änderung des Grades seiner Gemeinsamkeit analysieren. Modul 5114 kann einen oder mehrere Kontexte auswählen, die jeweils ein oder mehrere Schlüsselwörter umfassen, die den Kontext beschreiben. Ein ausgewählter Kontext kann zum Beispiel die Schlüsselwörter „Fahrrad“, „Schnee“ und „Autobahn“ umfassen.
• Nach der Auswahl eines Kontexts als Kandidat für die Erzeugung eines synthetischen Bildes kann das Modul 5114 die Kontextwahrscheinlichkeitsdatenbank 5116 konsultieren, um festzustellen, ob der ausgewählte Kontext in der realen Welt vorkommt. Die Kontext-Wahrscheinlichkeitsdatenbank 5116 kann mit Hilfe von Daten (z. B. Text, Bilder und Videos) erstellt werden, die aus Büchern, Artikeln, Internet-Websites oder anderen geeigneten Quellen stammen. Die Daten der Kontext-Wahrscheinlichkeitsdatenbank 5116 können erweitert werden, wenn mehr Daten online verfügbar werden. Die Daten können auf jede geeignete Weise aus Online-Quellen gewonnen werden, z. B. durch Crawlen von Websites und Extrahieren von Daten aus solchen Websites, durch Nutzung von Anwendungsprogrammierschnittstellen einer Datenquelle oder durch andere geeignete Methoden. Bilddaten (einschließlich Bilder und Videos) können mithilfe von maschinellem Lernen oder anderen Klassifizierungsalgorithmen verarbeitet werden, um Schlüsselwörter zu bestimmen, die mit Objekten und dem Kontext in den Bildern verbunden sind. Die gesammelten Daten können indiziert werden, um die Suche nach Schlüsselwörtern in der Datenbank zu erleichtern, z. B. die Suche nach der Nähe von Schlüsselwörtern zu anderen Schlüsselwörtern. Die gesammelten Daten können eine Bibliothek von Kontexten bilden, aus der sich ableiten lässt, ob bestimmte Kontexte in der realen Welt vorkommen.
• Nach der Auswahl eines Kontexts als Kandidat für die Erzeugung eines synthetischen Bildes kann das Modul q14 die Kontextwahrscheinlichkeitsdatenbank 5116 konsultieren, um festzustellen, wie oft die Schlüsselwörter des Kontexts in den gesammelten Datenquellen innerhalb der Kontextwahrscheinlichkeitsdatenbank 5116 gemeinsam auftreten. Wenn die Schlüsselwörter nie zusammen auftreten, kann das Modul 5114 feststellen, dass der Kontext nicht in der realen Welt vorkommt, und festlegen, dass keine synthetischen Bilder für den Kontext erzeugt werden. In einigen Ausführungsformen wird, wenn die Schlüsselwörter zusammen vorkommen (oder mehr als eine bestimmte Anzahl von Malen zusammen vorkommen), entschieden, dass der Kontext in der realen Welt vorkommt, und die Schlüsselwörter des Kontexts werden an den GAN-Bildgenerator 5118 weitergeleitet.
• In einer bestimmten Ausführungsform kann ein Hinweis darauf, ob der Kontext im wirklichen Leben vorkommt und/oder ob synthetische Bilder für den Kontext erzeugt wurden, in Verbindung mit dem Kontext im Metadaten-/Kontextdatensatz 5110 (oder einem anderen geeigneten Speicher) gespeichert werden, so dass das Modul 5114 unnötige Abfragen der Kontextwahrscheinlichkeitsdatenbank 5116 für den bestimmten Kontext vermeiden kann. Wenn festgestellt wird, dass ein bestimmter Kontext in der realen Welt nicht vorkommt, kann Modul 5114 außerdem feststellen, dass untergeordnete Kontexte für diesen bestimmten Kontext ebenfalls nicht in der realen Welt vorkommen (wobei ein untergeordneter Kontext alle Schlüsselwörter des übergeordneten Kontexts erbt und mindestens ein zusätzliches Schlüsselwort umfasst). In einigen Ausführungsformen kann ein Kontext unter bestimmten Bedingungen (z. B. bei einer größeren Aktualisierung der Kontextwahrscheinlichkeitsdatenbank 5116) erneut auf sein Vorkommen in der realen Welt analysiert werden, selbst wenn in einer ersten Analyse festgestellt wurde, dass er in der realen Welt nicht vorkommt.
• Wenn festgestellt wird, dass ein Kontext, der als Kandidat für die Erzeugung eines synthetischen Bildes ausgewählt wurde, gemäß den Informationen in der Kontextwahrscheinlichkeitsdatenbank 5116 in der realen Welt vorkommt, wird der Kontext dem GAN-Bildgenerator 5118 zur Verfügung gestellt. Der Bildgenerator 5118 kann eine geeignete Logik umfassen, um Bilddaten (z. B. ein oder mehrere Bilder oder Videoclips) zu erzeugen, die den Kontext darstellen. Um das obige Beispiel fortzusetzen: Wenn ein Kontext die Schlüsselwörter „Fahrrad“, „Schnee“ und „Autobahn“ umfasst, kann der Bildgenerator 5118 eine oder mehrere Instanzen von Bilddaten erzeugen, die jeweils ein Fahrrad auf einer Autobahn im Schnee zeigen. In verschiedenen Ausführungsformen kann der GAN-Bildgenerator 5118 so eingestellt werden, dass er für das Modelltraining nützliche Bilddaten liefert. Beispielsweise kann der Generator 5118 Bilder mit verschiedenen Fahrradtypen (optional in verschiedenen Positionen innerhalb der Bilder) auf verschiedenen Arten von Autobahnen im Schnee erzeugen.
• Die vom Bildgenerator 5118 erzeugten Bilddaten können in den Bilddatensatz eingefügt und in Verbindung mit dem zur Erzeugung der Bilder verwendeten Kontext gespeichert werden. Solche Bilder können dazu verwendet werden, ein oder mehrere Modelle (z. B. Modelle für maschinelles Lernen) zu trainieren, die von einem autonomen Fahrzeug zur Erkennung von Objekten verwendet werden. Dementsprechend kann das System 5100 unwahrscheinliche Kontexte identifizieren, feststellen, ob solche Kontexte wahrscheinlich in der realen Welt existieren, und dann synthetische Bilder solcher Kontexte erzeugen, um den Datensatz zu bereichern und die Klassifizierungs- und Objektidentifikationsleistung zu verbessern.
• In verschiedenen Ausführungsformen kann das System 100 auch Module umfassen, die Eingaben von Menschen oder anderen Akteuren (z. B. Computereinheiten) empfangen, um eine der hier beschriebenen Funktionen zu steuern. So können beispielsweise explizite Angaben darüber gemacht werden, ob ein bestimmter Kontext möglich ist. In einigen Ausführungsformen kann eine Teilmenge der Abfragen an die Kontextwahrscheinlichkeitsdatenbank 5116 verwendet werden, um einen menschlichen Bediener zu fragen, ob ein Kontext realistisch ist. Wenn beispielsweise eine Suche in der Datenbank 5116 nur sehr wenige Instanzen der Schlüsselwörter des Kontexts ergibt, kann ein menschlicher Bediener gefragt werden, ob der Kontext realistisch ist, bevor er den Kontext an den Bildgenerator 5118 weitergibt. Als weiteres Beispiel kann ein menschlicher Bediener oder eine Recheneinheit Schlüsselwörter direkt in den GAN-Bildgenerator 5118 eingeben, um Bilder für den gewünschten Kontext zu erzeugen. Diese Bilder können dann zusammen mit den zugehörigen Kontexten im Bilddatensatz 5104 gespeichert werden. In einigen Ausführungsformen kann die menschliche Eingabe durch einen Entwickler eines Rechenmodells, das von einem autonomen Fahrzeug verwendet werden soll, oder durch eine Crowdsourcing-Plattform, wie Amazon Mechanical Turk, erfolgen.
• In einigen Ausführungsformen kann das System auf eine bestimmte Gruppe von Kontexten und zugehörigen Schlüsselwörtern ausgerichtet sein. Wenn ein Modellentwickler beispielsweise weiß, dass das Modell bei Nebel oder in der Nacht weniger genau ist, könnte er die Erzeugung zusätzlicher synthetischer Bilddatensätze mit diesen Schlüsselwörtern veranlassen, um das Modell für eine bessere Leistung zu trainieren. In verschiedenen Ausführungsformen können die erzeugten synthetischen Bilddaten auch für Modelltests verwendet werden, um die Genauigkeit des Modells zu bestimmen. In einigen Ausführungsformen können synthetische Datenbilder zum Testen eines Modells verwendet werden, bevor sie dem Bilddatensatz hinzugefügt werden. Wenn zum Beispiel ein aktuelles Modell Schwierigkeiten hat, die synthetischen Bilder genau zu klassifizieren, können solche Bilder als nützlich für das Training angesehen werden, um die Leistung des Modells zu verbessern, und können dann dem Bilddatensatz 5104 hinzugefügt werden.
• In verschiedenen Ausführungsformen kann das gesamte System 5100 oder ein Teil davon von einem bordeigenen Rechensystem eines Fahrzeugs getrennt sein (z. B. können das System 5100 oder Komponenten davon in einer Cloud-Computing-Umgebung untergebracht sein). In anderen Ausführungsformen kann das gesamte System 5100 oder ein Teil davon in ein bordeigenes, fahrzeuginternes Rechensystem eines Fahrzeugs integriert werden, wie hier beschrieben.
• In einer bestimmten Ausführungsform kann ein bordseitiger Kontexterkennungsalgorithmus von einem Fahrzeug ansprechend auf eine Datenerfassung durch das Fahrzeug durchgeführt werden. Das Fahrzeug kann einen Snapshot der Kontextwahrscheinlichkeitsdatenbank 5116 speichern und verwenden (z. B. als paralleles Verfahren zum GAN). Nach dem Hochladen von Daten, die mit einem seltenen Ereignis verbunden sind, kann der Bildgenerator 5118 Daten aus einem vom Fahrzeug durchgeführten Kontexterkennungsalgorithmus als Eingabe verwenden, um weitere Instanzen dieser seltenen Kontexte zu erzeugen.
• 52 zeigt einen Ablauf zur Erzeugung synthetischer Daten in Übereinstimmung mit bestimmten Ausführungsformen. Bei 5202 wird der Kontext, der mit den von einem oder mehreren Sensoren eines Fahrzeugs erfassten Sensordaten verbunden ist, identifiziert, wobei der Kontext eine Mehrzahl von Textschlüsselwörtern umfasst. Bei 5204 wird festgestellt, dass zusätzliche Bilddaten für den Kontext erwünscht sind. Bei 5206 wird die Mehrzahl von Textschlüsselwörtern des Kontexts einem Generator für synthetische Bilder zur Verfügung gestellt, wobei der Generator für synthetische Bilder eine Mehrzahl von Bildern auf der Grundlage der Mehrzahl von Textschlüsselwörtern des Kontexts erzeugt.
• Während des Betriebs autonomer Fahrzeuge werden umfangreiche Algorithmen zur Sicht- und Audioerkennung durchgeführt. Aufgrund ihrer hochmodernen Leistung können Deep-Learning-Algorithmen für solche Anwendungen eingesetzt werden. Solche Algorithmen können jedoch trotz ihrer hocheffektiven Klassifizierungsleistung anfällig für Angriffe sein. Im Bereich der Computer Vision können Angreifer die Bilder durch sehr kleine Störungen manipulieren, die für das menschliche Auge unbemerkt bleiben, aber ein Bild so stark verzerren können, dass ein Deep Learning-Algorithmus das Bild falsch klassifiziert. Ein solcher Angriff kann ungezielt sein, so dass dem Angreifer die resultierende Klassifizierung des Bildes gleichgültig ist, solange das Bild falsch klassifiziert wird, oder ein Angriff kann gezielt sein, so dass das Bild so verzerrt wird, dass es mit einem gezielten Klassifikator klassifiziert wird. In ähnlicher Weise kann ein Angreifer im Audiobereich Geräusche einfügen, die das menschliche Hören der eigentlichen Sätze nicht beeinträchtigen, aber der Sprache-zu-Text-Algorithmus wird die Sprache völlig missverstehen. Jüngste Ergebnisse zeigen auch, dass die Anfälligkeit für negative Störungen nicht auf Deep-Learning-Algorithmen beschränkt ist, sondern auch klassische maschinelle Lernverfahren betreffen kann.
• Um die Sicherheit von Algorithmen des maschinellen Lernens zu verbessern, umfassen verschiedene Ausführungsformen der vorliegenden Offenbarung ein System zur Erzeugung synthetischer Daten, das speziell die Angriffe nachahmt, die ein Angreifer erzeugen könnte. Um Angriffsdaten für Bilder zu synthetisieren, werden mehrere Gegner in Betracht gezogen, und die gegnerischen Bilder werden aus Bildern erzeugt, für die die Klassifizierer bereits bekannt sind, und dann in einem Trainingssatz zusammen mit den zugrunde liegenden gutartigen Bildern (von denen zumindest einige als die zugrunde liegenden Bilder für die gegnerischen Bilder verwendet wurden) verwendet, um ein maschinelles Lernmodell zu trainieren, das für die Objekterkennung durch ein Fahrzeug verwendet werden soll.
• 53 zeigt einen Ablauf für die Erzeugung gegnerischer Abtastwerte und das Training eines Maschinelles-Lernen-Modells auf der Grundlage der gegnerischen Abtastwerte. Der Ablauf kann die Verwendung einer Mehrzahl verschiedener Angriffsmethoden 5302 umfassen, um gegnerische Abtastwerte zu erzeugen. Ein oder mehrere Parameter 5304 können bestimmt werden, um den Trainingsdatensatz zu erstellen. Die Parameter können z. B. eines oder mehrere der folgenden Elemente umfassen: ein Verhältnis von gutartigen zu gegnerischen Abtastwerten, verschiedene zu verwendende Angriffsstärken (und Verhältnisse der jeweiligen Angriffsstärken für jede der Angriffsmethoden), Anteile von Angriffstypen (z. B. wie viele Angriffe eine erste Angriffsmethode verwenden, wie viele eine zweite Angriffsmethode verwenden usw.) und einen Strafbegriff für die Fehlklassifizierung von gegnerischen Abtastwerten. Die gegnerischen Abtastwerten können durch jede geeignete Berechnungsmethode, wie hier beschrieben, erzeugt werden.
• Nachdem die gegnerischen Abtastwerten entsprechend den Parametern erzeugt wurden, können die gegnerischen Abtastwerten bei 5306 zu den gutartigen Abtastwerten eines Trainingssatzes hinzugefügt werden. Der Trainingssatz kann dann zum Trainieren eines Klassifikationsmodells bei 5308 durch ein Rechensystem verwendet werden. Die Ergebnisse des Trainings können verwendet werden, um ein robustes KI-Klassifizierungssystem für ein Fahrzeug bei 5310 zu erstellen (z. B. ein ML-Modell, das z. B. von der Inferenzmaschine 254 ausgeführt werden kann). Die einzelnen Abschnitte des Ablaufs werden im Folgenden näher beschrieben.
• Zur Erzeugung der synthetischen Bilder kann irgendeine Anzahl von erwarteten Angriffsmethoden verwendet werden. Zum Beispiel kann eine oder mehrere der folgenden Methoden zur Erzeugung der synthetischen Bilder verwendet werden: eine schnelle Gradientenvorzeichenmethode (Fast Gradient Sign-Methode), eine iterative schnelle Gradientenvorzeichenmethode (Iterative Fast Gradient Sign-Methode), eine Deep-Fool-Methode, eine universelle gegnerische Störung (Universal Adversarial Perturbation) oder eine andere geeignete Angriffsmethode.
• Die Erzeugung eines gegnerischen Bildes mittels einer schnellen Gradientenvorzeichenmethode kann umfassen, dass ein Gradient einer Verlustfunktion eines neuronalen Netzwerkes entsprechend einem zugrundeliegenden Bild ausgewertet wird, das Vorzeichen des Gradienten genommen und dann mit einer Schrittgröße (z. B. einer Stärke des Angriffs) multipliziert wird. Das Ergebnis wird dann zu dem Originalbild hinzugefügt, um ein Gegenbild zu erstellen. Die Erzeugung eines Negativbildes mittels einer iterativen schnellen Gradientenvorzeichenmethode kann einen iterativen Angriff mit einer Schrittgröße über eine Anzahl von Gradientenschritten umfassen, anstatt eines einzelnen Angriffs (wie es bei der schnellen Gradientenvorzeichenmethode der Fall ist), bei dem jede Iteration dem Bild hinzugefügt wird. Die Erzeugung eines gegnerischen Bildes mittels einer Deep-Fool-Methode kann die Linearisierung der Verlustfunktion an einem Eingabepunkt und die Anwendung der minimalen Störung umfassen, die für einen Klassenwechsel erforderlich wäre, wenn die lineare Approximation korrekt ist. Dies kann iterativ durchgeführt werden, bis die gewählte Klasse des Netzes wechselt. Die Erzeugung eines Störungsbildes mit Hilfe einer Universelle-Gegnerische-Störung-Methode kann die Berechnung einer Störung auf einem gesamten Trainingssatz und das anschließende Hinzufügen dieser Störung zu allen Bildern umfassen (während einige der anderen Angriffsmethoden Bilder einzeln angreifen).
• In einigen Ausführungsformen können aus einem einzigen Bild mit einem bekannten Klassifikator und unter Verwendung unterschiedlicher Angriffsstärken mehrere ungünstige Bilder erzeugt werden. Beispielsweise kann für eine bestimmte Angriffsmethode ein erstes Feindbild aus einem gutartigen Bild mit einer ersten Angriffsstärke und ein zweites Feindbild aus demselben gutartigen Bild mit einer zweiten Angriffsstärke erzeugt werden.
• In einigen Ausführungsformen können mehrere Angriffsmethoden angewandt werden, um aus einem einzigen gutartigen Bild mehrere schädliche Bilder zu erzeugen. Beispielsweise kann eine erste Angriffsmethode mit einer oder mehreren Angriffsstärken verwendet werden, um aus einem gutartigen Bild ein oder mehrere nachteilige Bilder zu erzeugen, und eine zweite Angriffsmethode kann mit einer oder mehreren Angriffsstärken verwendet werden, um aus demselben gutartigen Bild ein oder mehrere zusätzliche nachteilige Bilder zu erzeugen.
• Es kann irgendeine Anzahl von Angriffsmethoden und irgendeine Anzahl von Angriffsstärken verwendet werden, um für den synthetischen Datensatz gegnerische Bilder zu erzeugen. Darüber hinaus können in einigen Ausführungsformen die Angriffsmethoden und Angriffsstärken auf gutartige Bilder verteilt sein (z. B. werden nicht alle Methoden und/oder Stärken auf jedes gutartige Bild angewendet). Beispielsweise können eine oder mehrere Angriffsmethoden und/oder eine oder mehrere Angriffsstärken auf ein erstes gutartiges Bild angewandt werden, um ein oder mehrere nachteilige Bilder zu erzeugen, eine oder mehrere andere Angriffsmethoden und/oder eine oder mehrere Angriffsstärken können auf ein zweites gutartiges Bild angewandt werden, um ein oder mehrere zusätzliche nachteilige Bilder zu erzeugen, und so weiter. In einigen Ausführungsformen kann die Angriffsstärke für Angriffe auf Bilder aus jeder zu trainierenden Klasse variiert werden.
• In verschiedenen Ausführungsformen können die Anteile der einzelnen Angriffsarten auf der Grundlage einer Schätzung der realen Bedingungen variiert werden (z. B. um das Verhältnis der erwarteten Angriffsarten anzupassen). Beispielsweise können 50 % der falschen Bilder im synthetischen Datensatz mit einer ersten Angriffsmethode erzeugt werden, 30 % der falschen Bilder mit einer zweiten Angriffsmethode und 20 % der falschen Bilder mit einer dritten Angriffsmethode.
• In verschiedenen Ausführungsformen kann das Verhältnis von gutartigen zu bösartigen Bildern auch von einem synthetischen Datensatz zu einem anderen synthetischen Datensatz variiert werden. So können beispielsweise mehrere synthetische Datensätze mit unterschiedlichen Verhältnissen zwischen gutartigen und bösartigen Bildern getestet werden, um das optimale Verhältnis zu ermitteln (z. B. anhand der Genauigkeit der Objekterkennung).
• Jedes Negativbild wird mit einer Assoziation zum korrekten Ground-Truth-Label (z. B. der Klasse des zugrunde liegenden gutartigen Bildes) gespeichert. In einigen Ausführungsformen können die gegnerischen Bilder jeweils mit einem entsprechenden Angriffslabel gespeichert werden (z. B. das Label, das das gegnerische Bild normalerweise erhalten würde, wenn der Klassifikator nicht auf den gegnerischen Daten trainiert worden wäre, was bei einem gezielten Angriff das gewünschte Label des Angreifers sein kann). Eine Sammlung solcher Schadbilder und zugehöriger Klassifikatoren kann einen simulierten Angriffsdatensatz bilden.
• Ein simulierter Angriffsdatensatz kann mit einem Satz gutartiger Bilder (und zugehörigen bekannten Klassifizierern) gemischt und zum Trainieren eines überwachten Klassifizierungsmodells für maschinelles Lernen verwendet werden, z. B. eines neuronalen Netzwerkes, eines Entscheidungsbaums, einer Support-Vektor-Maschine, einer logistischen Regression, eines k-nächste-Nachbarn- (k-nearest neighbors-) Algorithmus oder eines anderen geeigneten Klassifizierungsmodells. So können die synthetischen Angriffsdaten als Ergänzung verwendet werden, um die Widerstandsfähigkeit gegen Angriffe auf Deep-Learning-Algorithmen oder klassische ML-Algorithmen zu erhöhen. Während des Trainings werden die gegnerischen Bilder mit ihren korrekten Bezeichnungen als Teil des Trainingssatzes aufgenommen, um das Lernmodell zu verfeinern. Darüber hinaus kann in einigen Ausführungsformen die Verlustfunktion des Lernmodells mit einem Malus belegt werden, wenn der Lernalgorithmus dazu neigt, die gegnerischen Bilder während des Trainings in die vom Angreifer gewünschten Etiketten zu klassifizieren. Dadurch wird der Lernalgorithmus widerstandsfähiger gegen gegnerische Angriffe auf die Bilder.
• Jeder der oben beschriebenen Ansätze kann für ähnliche Angriffe auf Audiodaten angepasst werden. Für die Erzeugung der gegnerischen Audio-Abtastwerte können alle geeigneten Angriffsmethoden für Audiodaten verwendet werden. So können beispielsweise Methoden verwendet werden, die auf der Störung eines Eingabeabtastwertes auf der Grundlage des Gradientenabstiegs beruhen. Bei diesen Angriffsmethoden kann es sich um einmalige Angriffe oder um iterative Angriffe handeln. Wie bei den Bildangriffen können mehrere verschiedene Angriffsmethoden verwendet werden, die Audioangriffe können in ihrer Angriffsstärke variieren, das Verhältnis der durch die Angriffsmethoden erzeugten gegnerischen Abtastwerten kann variieren, und das Verhältnis von gegnerischen Abtastwerten zu gutartigen Abtastwerten kann ebenfalls variieren. Die gegnerischen Audio-Abtastwerte können verwendet werden, um ein beliebiges geeignetes Text-to-Speech- (z. B. WaveNet, DeepVoice, Tacotron usw.) oder Spracherkennung- (z. B. Deep-Modelle mit Hidden-Markov-Modellen, konnektionistische temporale Klassifizierungsmodelle, aufmerksamkeitsbasierte Modelle usw.) Modell für maschinelles Lernen zu trainieren.
• 54 zeigt einen Ablauf zum Erzeugen eines simulierten Angriffsdatensatzes und zum Trainieren eines Klassifikationsmodells unter Verwendung des simulierten Angriffsdatensatzes in Übereinstimmung mit bestimmten Ausführungsformen. Bei 5402 wird auf einen gutartigen Datensatz zugegriffen, der eine Mehrzahl von Bildabtastwerten oder eine Mehrzahl von Audio-Abtastwerte umfasst. Die Abtastwerte des gutartigen Datensatzes haben bekannte Bezeichnungen. Bei 5404 wird ein simulierter Angriffsdatensatz erzeugt, der eine Mehrzahl von gegnerischen Abtastwerten umfasst, wobei die gegnerischen Abtastwerten erzeugt werden, indem eine Mehrzahl von verschiedenen Angriffsmethoden an Abtastwerten des gutartigen Datensatzes durchgeführt werden. Bei 5406 wird ein maschinelles Lernklassifizierungsmodell unter Verwendung der gegnerischen Abtastwerten, der bekannten Kennzeichnungen und einer Mehrzahl gutartiger Abtastwerte trainiert.
• Teilautonome und autonome Fahrzeugsysteme sind in hohem Maße auf Techniken des maschinellen Lernens (ML) zur Objekterkennung angewiesen. Im Laufe der Zeit müssen die Modelle, die für die Klassifizierung verwendet werden, aktualisiert werden (einschließlich eines erneuten Trainings), damit sie die sich verändernden Umgebungen, die während der Nutzung auftreten, weiterhin genau widerspiegeln, und zwar sowohl in Bezug auf neue Ereignisse (z. B. eine Änderung eines Schneesturms) als auch auf veränderte Muster (z. B. eine Zunahme der Verkehrsdichte). Zwar können Aktualisierungen eines ML-Modells in regelmäßigen Abständen vorgenommen werden, doch können solche Aktualisierungen zu einer übermäßigen Ressourcennutzung führen, wenn ein gültiges Modell unnötigerweise ersetzt wird, oder sie können zu einer größeren Anzahl von Fehlklassifizierungen führen, wenn die Aktualisierungen nicht häufig genug erfolgen.
• In verschiedenen Ausführungsformen der vorliegenden Offenbarung werden bei der Objekterkennung mehrere Klassifikatoren mit jeweils unterschiedlichen Eigenschaften verwendet, und das Verhalten eines Klassifikators kann verwendet werden, um zu bestimmen, wann der/die anderen Klassifikatoren aktualisiert werden sollten (z. B. erneutes Trainieren anhand kürzlich erkannter Objekte). So kann beispielsweise das Verhalten eines einfachen Klassifizierers (z. B. eines linearen Klassifizierers) verwendet werden, um zu bestimmen, wann ein robusterer oder komplizierterer Klassifizierer (z. B. ein nichtlinearer Klassifizierer) aktualisiert werden muss. Der einfache Klassifikator kann als Frühwarnsystem (wie ein „Kanarienvogel in der Kohlenmine“) für notwendige Aktualisierungen des robusteren Klassifikators dienen. Während der einfache Klassifikator möglicherweise keine so robuste oder genaue Objekterkennung bietet wie der andere Klassifikator, kann der einfache Klassifikator anfälliger für Veränderungen in der Umgebung sein und somit eine einfachere Erkennung von Veränderungen in der Umgebung im Vergleich zu einem nichtlinearen Klassifikator ermöglichen. In einer bestimmten Ausführungsform wird ein Klassifikator, der in einem sich verändernden Umfeld relativ anfällig für eine Verschlechterung der Genauigkeit ist, überwacht, und wenn die Genauigkeit dieses Klassifikators um einen bestimmten Wert abfällt, wird eine Umschulung der Klassifikatoren ausgelöst.
• Obwohl sich diese Offenbarung auf Ausführungsformen konzentriert, die einen linearen Klassifikator als einfachen Klassifikator und einen nichtlinearen Klassifikator als robusteren Klassifikator verwenden, können andere Ausführungsformen jeden geeigneten Klassifikator als einfachen und robusten Klassifikator verwenden. In einer bestimmten Ausführungsform kann beispielsweise der robuste Klassifikator ein komplexer nichtlinearer Klassifikator und der einfache Klassifikator ein weniger anspruchsvoller nichtlinearer Klassifikator sein. Der einfache Klassifikator (z. B. linearer Klassifikator) und der robuste Klassifikator (z. B. nichtlinearer Klassifikator) können von jedem geeigneten Rechensystem implementiert werden.
• Obwohl die Klassengrenzen der linearen und nichtlinearen Klassifikatoren in den folgenden Beispielen zur Vereinfachung der Erklärung als Klassifizierung von Abtastwerten entlang von zwei Dimensionen (x- und y-Dimensionen) dargestellt sind, können der lineare Klassifikator oder der nichtlineare Klassifikator in verschiedenen Ausführungsformen Abtastwerte entlang irgendeiner Anzahl von Dimensionen klassifizieren (z. B. kann der Eingangsvektor des Klassifikators irgendeine Anzahl von Merkmalswerten aufweisen). Anstelle einer Linie als Klassengrenze für einen linearen Klassifikator kann beispielsweise eine Hyperebene verwendet werden, um einen n-dimensionalen Eingaberaum aufzuteilen, wobei alle Abtastwerte auf einer Seite der Hyperebene mit einem Label klassifiziert werden, während die Abtastwerte auf der anderen Seite der Hyperebene mit einem anderen Label klassifiziert werden.
• Ein linearer Klassifikator kann eine Klassifizierungsentscheidung auf der Grundlage des Wertes einer linearen Kombination mehrerer Merkmale (auch als Merkmalswerte bezeichnet) eines Eingabeabtastwertes treffen. Im Rahmen dieser Offenbarung kann jeder geeignete lineare Klassifikator als einfacher Klassifikator verwendet werden. Beispielsweise kann ein Klassifikator auf der Grundlage der regulierten kleinsten Quadrate, einer logistischen Regression, einer Support-Vektor-Maschine, Naive Bayes, eines linearen diskriminanten Klassifikators, eines Perceptrons oder einer anderen geeigneten linearen Klassifizierungstechnologie verwendet werden.
• Ein nichtlinearer Klassifikator bestimmt im Allgemeinen Klassengrenzen, die nicht gut durch lineare Hyperebenen approximiert werden können, und somit sind die Klassengrenzen nichtlinear. Im Rahmen dieser Offenbarung kann jeder geeignete nichtlineare Klassifikator als robuster Klassifikator verwendet werden. Beispielsweise kann ein Klassifikator auf der Grundlage eines quadratischen Diskriminanzklassifikators, eines mehrschichtigen Perzeptrons, von Entscheidungsbäumen, eines Zufallswaldes, eines K-Nächster-Nachbar, eines Ensembles oder einer anderen geeigneten nichtlinearen Klassifizierungstechnologie verwendet werden.
• 55 veranschaulicht die Funktionsweise eines nichtlinearen Klassifizierers in Übereinstimmung mit bestimmten Ausführungsformen. Der nichtlineare Klassifikator kann zur Klassifizierung beliebiger geeigneter Eingabeabtastwerte (z. B. Ereignisse) mit einem oder mehreren Merkmalswerten verwendet werden. 55 zeigt einen ersten Datensatz 5500 mit einer Mehrzahl von Abtastwerten 5504 einer ersten Klasse und einer Mehrzahl von Abtastwerten 5506 einer zweiten Klasse. Der nichtlineare Klassifikator ist so ausgebildet, dass er auf der Grundlage der Merkmalswerte der Probe und einer durch den nichtlinearen Klassifikator definierten Klassengrenze unterscheidet, ob ein Abtastwert der ersten oder der zweiten Klasse angehört.
• Der Datensatz 5500 kann Abtastwerte darstellen, die zum Trainieren des nichtlinearen Klassifikators verwendet werden, während der Datensatz 5550 dieselben Abtastwerte sowie zusätzliche Abtastwerte 5508 des ersten Typs und zusätzliche Abtastwerte 5510 des zweiten Typs darstellt. Die Klassengrenze 5512 stellt die Klassengrenze für den nichtlinearen Klassifikator dar, nachdem der nichtlineare Klassifikator auf der Grundlage eines Trainingssatzes mit den neuen Abtastwerten 5508 und 5510 neu trainiert wurde. Die neue Klassengrenze 5512 ermöglicht es dem nichtlinearen Klassifikator zwar immer noch, die neuen Abtastwerte korrekt zu kennzeichnen, aber die sich verschiebenden Datenmuster sind möglicherweise nicht ohne weiteres erkennbar, da die Klassengrenzen 5502 und 5512 im Allgemeinen ähnliche Eigenschaften aufweisen.
• 56 veranschaulicht die Funktionsweise eines linearen Klassifizierers in Übereinstimmung mit bestimmten Ausführungsformen. 56 zeigt die gleichen Datensätze 5500 und 5550 wie 55. Die Klassengrenze 5602 stellt eine Klassengrenze des linearen Klassifizierers nach dem Training auf dem Datensatz 5500 dar, während die Klassengrenze 5604 eine Klassengrenze des linearen Klassifizierers darstellt, nachdem der lineare Klassifizierer auf der Grundlage eines Trainingssatzes, der die neuen Abtastwerte 5508 und 5510 umfasst, neu trainiert wurde. Die neuen Datenmuster (z. B. die neuen Abtastwerte 5508 und 5510) können offensichtlich sein, da die neuen Abtastwerte ohne erneutes Training des linearen Klassifikators falsch kategorisiert würden.
• Auf diese Weise kann der lineare Klassifikator eine frühzeitige Warnung aussprechen, dass sich die Daten verändern, was dazu führt, dass der sich verändernde Datensatz überwacht und proaktiv neue Modelle trainiert werden können. In bestimmten Ausführungsformen kann ein System die Genauigkeit des linearen Klassifizierers überwachen, und wenn die Genauigkeit unter einen Schwellenwert fällt, kann ein Neutraining sowohl des linearen als auch des nichtlinearen Klassifizierers ausgelöst werden. Die Umschulung kann mit Trainingssätzen durchgeführt werden, die neuere Daten umfassen.
• Da die Kombination von Klassifikatoren darauf ausgelegt ist, Veränderungen frühzeitig zu erkennen und gleichzeitig eine robuste Klassifizierung zu gewährleisten, können verschiedene Ausführungsformen neben der Erkennung von Veränderungen in der Umgebung auch zur Erkennung von Angriffen verwendet werden. Die Angriffsdaten unterscheiden sich im Allgemeinen von den Trainingsdaten, bei denen davon ausgegangen wird, dass sie auf saubere Weise (z. B. von Sensoren eines oder mehrerer autonomer Fahrzeuge) oder mit Hilfe synthetischer Generierungstechniken (wie den hier erörterten oder anderen geeigneten Datengenerierungstechniken) gesammelt wurden. Dementsprechend ist ein Verlust der Genauigkeit des linearen Klassifizierers ein frühzeitiger Hinweis auf einen Angriff (z. B. verschlechtert sich die Genauigkeit des linearen Klassifizierers schneller als die Genauigkeit des nichtlinearen Klassifizierers). Da die Klassifikatoren unterschiedlich funktionieren, kann es für einen Angreifer schwieriger sein, beide Systeme gleichzeitig zu umgehen.
• Insbesondere können Änderungen im linearen Klassifikator im Laufe der Zeit einem System ermöglichen, zu bestimmen, welche Daten neu oder interessant sind, um sie für weiteres Training zu erhalten. Wenn beispielsweise eine Änderung der Genauigkeit des linearen Klassifizierers festgestellt wird, können die kürzlich erfassten Daten (und/oder die falsch klassifizierten Daten) analysiert werden, um Daten von Interesse zu bestimmen, und diese Daten von Interesse können verwendet werden, um verwandte Datensätze synthetisch zu erzeugen (unter Verwendung der hier beschriebenen Techniken oder anderer geeigneter Techniken zur Erzeugung synthetischer Daten), die zum Trainieren der linearen und nichtlinearen Klassifizierer verwendet werden.
• Da sich der Klassifikator aufgrund von Daten ändert, die sich von den Trainingsdaten unterscheiden, können die neuen Abtastwertinstanzen analysiert und für weiteres Training beibehalten werden. Zum Beispiel verursachten in 56 die Abtastwerte 5508 und 5510 eine Verschiebung der Klassengrenze des linearen Klassifikators. Eine Teilmenge dieser neuen Abtastwerte kann für künftige Trainingssätze abgetastet und beibehalten werden. In einer bestimmten Ausführungsform können diese neuen Abtastwerte nach dem Zufallsprinzip abgetastet werden, um zu vermeiden, dass Datenverzerrungen in den Trainingssatz einfließen. In anderen Ausführungsformen kann ein überproportionaler Anteil einer bestimmten Klasse für einen zukünftigen Trainingssatz beibehalten werden (z. B. wenn die Anzahl der Abtastwerte dieser Klasse deutlich geringer ist als die Anzahl der Abtastwerte der anderen Klasse).
• Obwohl das Beispiel einen Zwei-Klassen-Klassifikator beschreibt, können verschiedene Ausführungsformen auch eine Mehrklassen-Klassifikation gemäß den hier beschriebenen Konzepten ermöglichen (z. B. unter Verwendung einfacher und robuster Klassifikatoren). So kann beispielsweise eine Reihe von Hyperebenen verwendet werden, wobei jede Klasse i (für 1-n) mit den anderen Klassen als Ganzes verglichen wird (z. B. eine gegen alle). Als weiteres Beispiel kann eine Reihe von Hyperebenen verwendet werden, wobei jede Klasse i (für 1-n) einzeln mit den anderen Klassen j (für 1-n) verglichen wird (z. B. eins gegen eins).
• 57 zeigt einen Ablauf zur Auslösung einer Aktion auf der Grundlage der Genauigkeit eines linearen Klassifikators. Bei 5702 klassifiziert ein linearer Klassifikator die Abtastwerte eines Fahrzeugs. Bei 5704 klassifiziert ein nichtlinearer Klassifikator dieselben Eingabeabtastwerte des Fahrzeugs. In bestimmten Ausführungsformen kann eine solche Klassifizierung parallel durchgeführt werden. Bei 5706 wird eine Änderung der Genauigkeit des linearen Klassifikators festgestellt. Bei 5708 wird ansprechend auf die Änderung der Genauigkeit des linearen Klassifikators mindestens eine Aktion ausgelöst.
• Verkehrssicherheitsmodelle können als mathematische Modelle implementiert werden, die Sicherheit garantieren, wenn alle Verkehrsteilnehmer das Modell einhalten, oder die Schuld im Falle eines Unfalls korrekt zuweisen. So können sich beispielsweise Verkehrssicherheitsmodelle auf mathematisch berechnete Sicherheitsabstände in Längs- und Querrichtung zwischen zwei Verkehrsteilnehmern stützen, um eine Kollision in einem Worst-Case-Szenario zu vermeiden, bei dem das Verhalten der Verkehrsteilnehmer an eine Reihe von festgelegten Bedingungen gebunden ist.
• Wann immer eine Situation eintritt, in der der Abstand zwischen zwei Agenten einen von einem Verkehrssicherheitsmodell festgelegten Sicherheitsabstand unterschreitet (z. B. eine „Gefahrensituation“), und beide Agenten darauf mit Beschleunigungen innerhalb der zuvor festgelegten Grenzen reagieren (z. B. eine „angemessene Reaktion“ zeigen), garantiert ein Verkehrssicherheitsmodell mathematisch die Vermeidung von Kollisionen. Hält sich hingegen einer der Bearbeiter nicht an die Vorschriften, so ist er im Falle eines Unfalls dafür verantwortlich.
• Das Modell der Straßenverkehrssicherheit vereinfacht die Analyse einer Situation, an der zwei Akteure beteiligt sind, indem es die Längs- und die Querdimension getrennt betrachtet. So werden beispielsweise die Geschwindigkeiten und Beschleunigungen der Agenten, die anhand dieser Geschwindigkeiten und Beschleunigungen berechneten minimalen Sicherheitsabstände und die tatsächlichen Abstände zwischen den Agenten anhand ihrer Längs- und Seitenkomponenten in einem Koordinatensystem analysiert, in dem der Mittelpunkt der Fahrbahn als auf der y-Achse liegend betrachtet wird (daher wird die Längskomponente in y und die Seitenkomponente in x ausgedrückt).
• 58 zeigt verschiedene Fahrphasen des Verkehrssicherheitsmodells in Übereinstimmung mit bestimmten Ausführungsformen. In 58 werden die Mittel 5802 und 5804 in drei Phasen 5806, 5808 und 5810 dargestellt. Um einem Verkehrssicherheitsmodell zu entsprechen, müssen die Agenten eine angemessene Reaktion zeigen, wenn sowohl der Sicherheitsabstand in Längs- als auch in Querrichtung verletzt wird, wobei die angemessene Reaktion selbst davon abhängt, welche Verletzung zuletzt aufgetreten ist. In der ersten Phase 5806 sind die Agenten 5802 und 5804 durch einen nicht sicheren seitlichen Abstand, aber einen sicheren Längsabstand getrennt. Die zweite Phase ww08 stellt den letzten Zeitpunkt dar, an dem der Längsabstand noch sicher ist (als „Schuldzeit“ bezeichnet). Zum nächsten Zeitpunkt nach der Tadelzeit wird auch der Sicherheitsabstand in Längsrichtung verletzt. In der dritten Phase 5810 sind die Agenten in eine sichere Situation zurückgekehrt und haben eine Kollision vermieden, nachdem sie eine angemessene Reaktion in Längsrichtung ausgeführt haben.
• RSS ist so konzipiert, dass es vollständig von der Politik des Agenten entkoppelt ist. Um RSS-konform zu sein, kann ein Autonomes-Fahren-Stack eine zusätzliche Komponente umfassen, um die RSS-Konformität von Entscheidungen zu prüfen, die von den Richtlinien des Agenten getroffen werden, und um standardmäßige RSS-konforme Entscheidungen zu erzwingen, wenn die Richtlinien des Agenten Aktionen verlangen, die nicht RSS-konform sind.
• Obwohl RSS mit Blick auf autonome Fahrzeuge entwickelt wurde, umfassen verschiedene Ausführungsformen der vorliegenden Offenbarung Fahrzeuge mit Steuerungssystemen, die RSS (oder ein ähnliches mathematisches Modell zur Unfallvermeidung) als Mechanismus zur Vermeidung von Unfällen durch menschliche Fahrerentscheidungen verwenden. Solche Ausführungsformen können möglicherweise zu einer höheren Gesamtsicherheit für einen menschlichen Fahrer führen und auch den Beweis oder die Garantie liefern, dass der Fahrer nicht für Unfälle verantwortlich gemacht wird, bei denen das geltende Recht die Schuld in einer Weise zuweist, die mit dem Schuldzuweisungsmechanismus der RSS vergleichbar ist (z. B. wird die Schuld einem Agenten zugewiesen, der die Bedingungen des Modells verletzt hat). In Anlehnung an das RSS-Modell bieten verschiedene hier beschriebene Ausführungsformen einen weiteren potenziellen, längerfristigen Vorteil: Wenn beispielsweise immer mehr Agenten (menschliche oder andere) mit einem RSS-Enforcer (oder einem Enforcer eines ähnlichen Modells) ausgestattet werden, wird die Gesamtzahl der Verkehrsunfälle abnehmen und sich zu einer idealen Situation für alle Agenten entwickeln.
• In einer besonderen Ausführungsform der vorliegenden Offenbarung umfasst ein Fahrzeug ein Steuersystem, das Fahrereingaben, die zu nicht RSS-konformen Beschleunigungen führen würden, durch synthetisch erzeugte Eingaben ersetzt, die garantiert eine Beschleunigung erzeugen, die im Bereich der RSS-konformen Beschleunigungen liegt. RSS-konforme Fahrereingaben werden unverändert an das Betätigungssystem weitergegeben, so dass das System nur in potenziell gefährlichen Situationen übernimmt.
• 59 zeigt ein Diagramm eines Systems 5900 zur Modifizierung von Fahrereingaben, um RSS-konforme Beschleunigungen gemäß bestimmten Ausführungsformen zu gewährleisten. In verschiedenen Ausführungsformen kann das System 5900 Teil eines Fahrzeugs, z. B. 105, sein, und jedes dergezeigten Module kann durch jede geeignete Logik eines Rechensystems eines Fahrzeugs, z. B. 105, implementiert werden. In anderen Ausführungsformen kann jedes der Module außerhalb des Fahrzeugs implementiert werden (z. B. durch 140 oder 150), und die Ergebnisse können an das Fahrzeug übermittelt werden. Das System 5900 umfasst die Steuerungen 5902 (in verschiedenen Ausführungsformen können die Steuerungen 5902 alle geeigneten Merkmale der Antriebssteuerungen 220 aufweisen), das Sensorpaket 5904 (in verschiedenen Ausführungsformen kann das Sensorpaket 590r alle geeigneten Merkmale der Sensoren 225 aufweisen), das RSS-Modell 5906, den RSS-Enforcer 5908, den Wandler 5910 zur Umwandlung von Steuerung in Beschleunigung und den Wandler 5912 zur Umwandlung von Beschleunigung in Steuerung. In einer bestimmten Ausführungsform können die Komponenten des Systems 5900 alle in ein Fahrzeug integriert werden. In anderen Ausführungsformen können eine oder mehrere Komponenten vom Fahrzeug getrennt und kommunikationsfähig mit dem Fahrzeug verbunden sein.
• Bedienelemente 5902 können vorgesehen werden, damit ein menschlicher Fahrer Eingaben in ein Betätigungssystem des Fahrzeugs machen kann. Zu den Bedienelementen können zum Beispiel ein Lenkrad oder ein anderer Lenkmechanismus, ein Gaspedal oder ein anderer Gashebel und ein Bremspedal oder ein anderer Bremsmechanismus gehören. In einer Ausführungsform können die Bedienelemente auch andere Komponenten umfassen, wie z. B. einen Schalthebel, eine Notbremse, einen Joystick, einen Touchscreen, ein Gestenerkennungssystem oder andere geeignete Eingabemöglichkeiten, die die Geschwindigkeit oder die Fahrtrichtung des Fahrzeugs beeinflussen können.
• Das Sensorpaket 5904 kann eine beliebige Kombination von einem oder mehreren Sensoren umfassen, die vom Fahrzeug verwendet werden, um Informationen über den Zustand der Welt in Verbindung mit dem Fahrzeug zu sammeln. Die Sensoreinheit 5904 kann beispielsweise ein oder mehrere LIDARs, Radare, Kameras, globale Positionierungssysteme (GPS), Trägheitsmesseinheiten (IMU), Audiosensoren, Infrarotsensoren oder andere hierin beschriebene Sensoren umfassen. Die Weltzustandsinformationen können alle geeigneten Informationen umfassen, wie z. B. die hier beschriebenen Zusammenhänge, von den Sensoren erfasste Objekte, mit Objekten verknüpfte Standortinformationen oder andere geeignete Informationen.
• Der Weltzustand kann allen geeigneten Komponenten des Systems 5900 zur Verfügung gestellt werden, z. B. dem RSS-Modell 5906, dem Wandler für die Umwandlung von Steuerung in Beschleunigung 5910 oder dem Wandler für die Umwandlung von Beschleunigung in Steuerung 5912. Die Weltzustandsinformationen können zum Beispiel dem RSS-Modell 5906 zur Verfügung gestellt werden. Das RSS-Modell 5906 kann die Weltzustandsinformationen nutzen, um einen Bereich von RSS-konformen Beschleunigungen für das Fahrzeug zu bestimmen. Dabei kann das RSS-Modell 5906 die Längs- und Querabstände zwischen dem Fahrzeug und anderen Fahrzeugen oder anderen Objekten verfolgen. Darüber hinaus kann das RSS-Modell 5906 auch die Geschwindigkeit des Fahrzeugs in Längs- und Querrichtung erfassen. Das RSS-Modell 5906 kann in regelmäßigen Abständen den Bereich der RSS-konformen Beschleunigungen aktualisieren und den Beschleunigungsbereich an den RSS-Enforcer 5908 weitergeben. Die RSS-konformen Beschleunigungen können einen Bereich von RSS-konformen Beschleunigungen in einer Längsrichtung sowie einen Bereich von RSS-konformen Beschleunigungen in einer Breitenrichtung angeben. Die Beschleunigungen können in jeder geeigneten Einheit ausgedrückt werden, z. B. in Metern pro Sekunde zum Quadrat, und können positive oder negative Werte haben (oder auch Nullwerte).
• Der RSS-Enforcer 5908 empfängt Steuersignale von Fahrereingaben und ruft den Steuerungs-/Beschleunigungswandler 5910 auf, der die Fahrereingaben in einen Beschleunigungswert umwandelt, der eine voraussichtliche Fahrzeugbeschleunigung angibt, wenn die Fahrereingaben an das Betätigungssystem 5914 weitergeleitet werden (das in einigen Ausführungsformen sowohl eine Breiten- als auch eine Längsbeschleunigungskomponente umfasst). Der RSS Enforcer 5908 kann feststellen, ob der Beschleunigungswert innerhalb des letzten Bereichs von RSS-konformen Beschleunigungen liegt, die vom RSS-Modell 5906 empfangen wurden. Liegt der Beschleunigungswert innerhalb des Bereichs der RSS-konformen Beschleunigungen, erlaubt der RSS-Enforcer die Weitergabe der Fahrereingabe von der Steuerung 5902 an das Betätigungssystem 5914. Liegt der Beschleunigungswert nicht innerhalb des Bereichs der RSS-konformen Beschleunigungen, blockiert der RSS-Enforcer die Fahrereingabe und wählt einen RSS-konformen Beschleunigungswert innerhalb des empfangenen Bereichs. Der RSS Enforcer 5908 kann dann den Beschleunigungs-Steuerungs-Wandler 5912 mit dem ausgewählten Beschleunigungswert aufrufen und im Gegenzug ein oder mehrere Steuersignale empfangen. In einer bestimmten Ausführungsform können die vom Beschleunigungs-Steuerungs-Wandler 5912 gelieferten Steuersignale das gleiche Format haben wie die Steuersignale, die dem Betätigungssystem 5914 ansprechend auf die Fahrereingabe bereitgestellt werden. Die Steuersignale können z. B. die Stärke der Bremsung, die Stärke der Beschleunigung und/oder die Stärke und Richtung der Lenkung oder andere geeignete Steuersignale angeben. Der RSS-Enforcer 5908 kann diese neuen Steuersignale an das Betätigungssystem 5914 weiterleiten, das die Steuersignale verwenden kann, um das Fahrzeug wie angegeben zu beschleunigen.
• In verschiedenen Ausführungsformen kann der RSS Enforcer 5908 jeden geeigneten Beschleunigungswert innerhalb des Bereichs der RSS-konformen Beschleunigungen wählen. In einer bestimmten Ausführungsform kann der RSS Enforcer 5908 den Beschleunigungswert zufällig aus dem Bereich auswählen. In einer anderen Ausführungsform kann der RSS Enforcer 5908 den konservativsten oder den am wenigsten konservativen Wert aus dem Bereich auswählen. In einer anderen Ausführungsform kann der RSS Enforcer 5908 einen Wert in der Mitte des Bereichs wählen. In einer weiteren Ausführungsform kann der RSS Enforcer 5908 Richtlinieninformationen verwenden (z. B. basierend auf den Präferenzen des Fahrers oder auf Sicherheitsüberlegungen), um den Beschleunigungswert zu bestimmen. Beispielsweise kann der RSS Enforcer 5908 Längsbeschleunigungen gegenüber Querbeschleunigungen bevorzugen oder umgekehrt. Ein weiteres Beispiel: Der RSS Enforcer 5908 kann Beschleunigungen bevorzugen, die für den Fahrer angenehmer sind (z. B. langsameres Bremsen oder kleinere Lenkeingriffe können gegenüber starkem Bremsen oder Ausweichen bevorzugt werden). In verschiedenen Ausführungsformen kann die Entscheidung sowohl auf der Sicherheit als auch auf dem Komfort beruhen, wobei die entsprechenden Messwerte aus demselben Satz von Bewegungsparametern und Fahrzeugeigenschaften berechnet werden.
• Wie bereits erwähnt, wandelt der Steuerungs-/Beschleunigungswandler 5910 die Eingaben des Fahrers (z. B. Lenkraddrehung und Druck auf das Gas-/Bremspedal) in Beschleunigungen um. In verschiedenen Ausführungsformen kann der Konverter 5910 während der Konvertierung alle geeigneten Informationen berücksichtigen, wie z. B. den Zustand der Welt (z. B. Geschwindigkeit des Fahrzeugs, Wetter, Straßenbedingungen, Straßenführung usw.) und physikalische Eigenschaften des Host-Fahrzeugs (z. B. Gewicht des Fahrzeugs, Form des Fahrzeugs, Reifeneigenschaften, Bremseigenschaften usw.). In einer Ausführungsform kann die Umrechnung auf einem ausgefeilten mathematischen Modell der Fahrzeugdynamik beruhen (z. B. wie es von einem Fahrzeughersteller geliefert wird). In einigen Ausführungsformen kann der Konverter 5910 ein maschinelles Lernmodell implementieren (z. B. ein beliebiges geeignetes Regressionsmodell), um die Konvertierung durchzuführen. Ein Beispiel für ein maschinelles Lernmodell für die Umwandlung von Steuerung in Beschleunigung wird in Verbindung mit den 60 und 61 ausführlicher beschrieben.
• Ein Beschleunigungs-/Steuerungswandler 5912 kann eine Logik umfassen, um eine RSS-konforme Beschleunigung, die vom RSS-Enforcer 5908 während einer Übernahme erzwungen wird, in einen für das Betätigungssystem 5914 geeigneten Eingang umzuwandeln. Der Konverter 5912 kann jede geeignete Information verwenden, um diese Umwandlung durchzuführen. So kann der Wandler 5912 beispielsweise eine oder mehrere der Informationen nutzen, die der Wandler 5910 für die Umwandlung von Steuerung in Beschleunigung verwendet. In ähnlicher Weise kann der Konverter 5912 ähnliche Methoden wie der Konverter 5910 verwenden, wie z. B. ein maschinelles Lernmodell, das angepasst ist, um Steuersignale auszugeben, wenn eine Beschleunigung eingegeben wird. In einer besonderen Ausführungsform kann ein Beschleunigungs-Regelungs-Wandler einen Proportional-Integral-Derivativ-Regler (PID) umfassen, um die gewünschten Steuersignale auf der Grundlage eines Beschleunigungswerts zu bestimmen. Der PID-Regler könnte mit einem klassischen Regelalgorithmus mit Proportional-, Integral- und Differenzialkoeffizienten implementiert werden oder auf maschinellem Lernen basieren, wobei diese Koeffizienten mit einem ML-Algorithmus vorhergesagt werden (z. B. implementiert durch das maschinelle Lernsystem 232), der eine Optimierungsmetrik verwendet, die Sicherheit und Komfort berücksichtigt.
• 5914 kann ein beliebiges geeignetes Betätigungssystem darstellen, das ein oder mehrere Steuersignale empfängt und ein Fahrzeug veranlasst, auf die ein oder mehreren Steuersignale zu reagieren. Das Betätigungssystem kann zum Beispiel die Menge an Benzin oder elektrischer Energie (oder einer anderen Energiequelle), die dem Motor eines Fahrzeugs zugeführt wird, die Menge an Bremsdruck, die auf die Räder des Fahrzeugs ausgeübt wird, die Höhe des Winkels, der auf ein oder mehrere Räder des Fahrzeugs ausgeübt wird, einstellen oder jede andere geeignete Einstellung vornehmen, die die Beschleunigung des Fahrzeugs beeinflussen kann.
• 60 zeigt eine Trainingsphase für den Regelungs-Beschleunigungs-Wandler 5910 in Übereinstimmung mit bestimmten Ausführungsformen. Zu den Trainingseingaben 6002 für das Modell können alle geeigneten Informationen gehören, die eine ansprechend auf Steuersignale ausgelöste Beschleunigung beeinflussen können. Zu den Trainingseingaben kann beispielsweise eine beliebige Kombination aus der Anfangsgeschwindigkeit eines Fahrzeugs, dem Straßenzustand, dem Reifenzustand, den Wetterbedingungen, der Raddrehung, der Höhe des Beschleunigungspedaldrucks, der Höhe des Bremspedaldrucks, dem Straßenlayout, den physikalischen Eigenschaften des Fahrzeugs oder anderen geeigneten Informationen gehören, zusammen mit einer resultierenden Beschleunigung unter jedem Satz solcher Informationen. Solche Daten können während einer Trainingsphase 6004 für maschinelles Lernen verwendet werden, um ein Regressionsmodell 6006 zu trainieren, das von einem Fahrzeug verwendet werden kann, um Steuersignale und andere Informationen (z. B. Informationen über den Weltzustand, physikalische Eigenschaften des Fahrzeugs) in Beschleunigungswerte umzuwandeln. In verschiedenen Ausführungsformen wird das Regressionsmodell 6006 auf Basis von Echtdaten trainiert, die mit einem oder mehreren Fahrzeugen der Fahrzeugklasse unter vielen verschiedenen Wetter-, Straßen- und Fahrzeugzustandsbedingungen gesammelt wurden. In verschiedenen Ausführungsformen kann das Training von jedem geeigneten Rechensystem durchgeführt werden (sei es in einem fahrzeuginternen Rechensystem, in einem Cloud-basierten System oder einer anderen Datenverarbeitungsumgebung).
• 61 zeigt eine Inferenzphase des Regelungs-Beschleunigungs-Wandlers 5910 in Übereinstimmung mit bestimmten Ausführungsformen. Während der Inferenzphase werden verschiedene Eingaben 6102, die mit dem Fahrzeug in Verbindung stehen, dem Regressionsmodell 6006 zugeführt, das auf der Grundlage der Eingaben eine vorhergesagte Beschleunigung ausgibt. Die Eingaben können die Eingabetypen widerspiegeln, die zum Trainieren des Modells 6006 verwendet werden, können aber auch Echtzeitwerte für solche Eingaben umfassen. Das Regressionsmodell 6006 gibt einen Beschleunigungswert 6104 aus.
• Ein ähnliches Regressionsmodell kann für den Beschleunigungs-Regelungs-Wandler 5912 verwendet werden. Ähnliche Eingabedaten können zum Trainieren des Modells verwendet werden, aber während der Inferenz kann das Modell eine gewünschte Beschleunigung als Eingabe erhalten (zusammen mit Echtzeitwerten des Weltzustands und/oder des Fahrzeugzustands) und Steuersignale ausgeben, die voraussichtlich die gewünschte Beschleunigung bewirken.
• 62 zeigt einen Ablauf für die Bereitstellung akzeptabler Steuersignale für ein Fahrzeugbetätigungssystem in Übereinstimmung mit bestimmten Ausführungsformen. Bei 6202 wird ein erster Satz von einem oder mehreren Steuersignalen ansprechend auf menschliche Eingaben an ein Fahrzeug erzeugt. Bei 6204 wird festgestellt, ob der erste Satz von Steuersignalen eine akzeptable Beschleunigung des Fahrzeugs bewirken würde. Wenn die Steuersignale eine akzeptable Beschleunigung bewirken würden, werden die Steuersignale bei 6206 unverändert an das Fahrzeugbetätigungssystem weitergegeben. Wenn die Steuersignale eine inakzeptable Beschleunigung verursachen würden, wird bei 6208 eine akzeptable Beschleunigung ermittelt. Bei 6210 wird die zulässige Beschleunigung in einen zweiten Satz von einem oder mehreren Steuersignalen umgewandelt. Bei 6212 wird der zweite Satz von einem oder mehreren Steuersignalen anstelle des ersten Satzes von einem oder mehreren Steuersignalen an das Fahrzeugbetätigungssystem übermittelt.
• Die sichere Übergabe der Fahrverantwortung von einem autonomen Fahrzeug an einen Menschen oder umgekehrt ist eine sehr kritische Aufgabe. Wie oben beschrieben, kann ein Ansatz für die Übergabe von einem Menschen an ein autonomes Fahrzeug auf dem RSS-Modell oder ähnlichem basieren, wobei ein autonomes Fahrzeug inakzeptable menschliche Eingaben abfangen und durch sicherere Eingaben ersetzen kann.
• In verschiedenen Ausführungsformen der vorliegenden Offenbarung kann die Übergabebereitschaft auf einer Messung der Gesamtsignalqualität der Sensoren eines Fahrzeugs im Verhältnis zu dem Kontext, in dem eine solche Messung stattfindet, basieren. Der Kontext kann jeder hierin beschriebene geeignete Kontext sein, wie z. B. eine Verkehrssituation (z. B. eine Autobahn oder eine stark befahrene Straße) oder Wetterbedingungen (z. B. klarer Himmel, regnerisch, Pfützen, Glatteis usw.). Die Signalqualitätsmetrik kann mithilfe eines Algorithmus für maschinelles Lernen (ML) bestimmt werden, der Sensordaten und Kontextinformationen als Eingabe erhält und eine Signalqualitätsmetrik ausgibt. Diese Signalqualitätsmetrik wird wiederum verwendet, um die Übergabebereitschaft mithilfe eines anderen ML-Algorithmus zu bestimmen, der anhand von Fahrzeug-Crash-Informationen trainiert wurde. Wenn die Signalqualitätsmetrik angesichts des Kontexts eine schlechte Signalqualität anzeigt, kann eine Übergabe von einem menschlichen Fahrer an ein autonomes Fahrzeug untersagt werden, da eine solche Übergabe unsicher sein kann.
• 63 zeigt eine Trainingsphase zur Erstellung eines Kontextmodells 6308 in Übereinstimmung mit bestimmten Ausführungsformen. In verschiedenen Ausführungsformen kann das Kontextmodell 6308 ein Klassifizierungsmodell sein, das auf der Grundlage von Sensordaten 6304 und der Grundwahrheit der Kontextinformationen 6306 erstellt wird. Der ML-Algorithmus 6302 kann ein beliebiger geeigneter Algorithmus zum Trainieren des Kontextmodells 6308 auf der Grundlage der Sensordaten 6304 und der Grundwahrheit der Kontextinformationen 6306 sein. Sensordaten 6304 können alle geeigneten Sensordaten von einem oder mehreren Sensoren eines Fahrzeugs umfassen, wie z. B. ein oder mehrere LIDARs, Radare, Kameras, globale Positionierungssysteme (GPS), Trägheitsmesseinheiten (IMU), Audiosensoren, Infrarotsensoren oder andere Sensoren. Der ML-Algorithmus 6302 kann das Kontextmodell 6308 unter Verwendung verschiedener Instanzen von Sensordaten 6304 und Kontextinformationsgrunddaten 6306 trainieren, wobei jede Instanz einen Satz von Sensordaten sowie einen zugehörigen Kontext umfassen kann. In verschiedenen Ausführungsformen können die Trainingsdaten tatsächliche Sensordaten und zugehörige Kontexte, simulierte Daten und zugehörige Kontexte und/oder synthetische Daten und zugehörige Kontexte (z. B. aus synthetischen Bildern, die mit einem hier beschriebenen Verfahren erzeugt wurden) umfassen. In einer bestimmten Ausführungsform kann ein Kontext ein oder mehrere Textschlüsselwörter umfassen, die den Kontext beschreiben, wie z. B. „neblig“ und „nasse Straßen“, aber jeder geeignete Ausdruck von Kontexten wird in dieser Offenbarung in Betracht gezogen.
• 64 zeigt eine Trainingsphase zum Aufbau eines Signalqualitätsmetrikmodells 6408 in Übereinstimmung mit bestimmten Ausführungsformen. In verschiedenen Ausführungsformen kann das Signalqualitätsmetrikmodell 6408 ein Regressionsmodell sein, das auf Basis von Sensordaten und Kontextinformationen erstellt wird. In verschiedenen Ausführungsformen können die Sensordaten 6404 dieselben Sensordaten sein wie die Sensordaten 6304 oder sie können sich zumindest teilweise unterscheiden. In einigen Ausführungsformen kann die Kontextinformations-Grundwahrheit 6406 dieselbe Kontextinformation sein wie die Kontextinformations-Grundwahrheit 6306 oder sie kann sich zumindest teilweise davon unterscheiden. Der ML-Algorithmus 6402 kann das Signalqualitätsmetrikmodell 6408 unter Verwendung verschiedener Instanzen von Sensordaten 6404 und Kontextinformationsgrundwahrheit 6406 trainieren, wobei jede Instanz einen Satz von Sensordaten sowie einen zugehörigen Kontext umfassen kann. In verschiedenen Ausführungsformen können die Trainingsdaten tatsächliche Sensordaten und zugehörige Kontexte, simulierte Daten und zugehörige Kontexte und/oder synthetische Daten und zugehörige Kontexte umfassen. Durch die Analyse mehrerer unterschiedlicher Instanzen von Sensordaten, die mit einem bestimmten Kontext verbunden sind, kann der ML-Algorithmus 6402 in der Lage sein, das Signalqualitätsmetrikmodell 6408 zu trainieren, um zwischen den Qualitäten der verschiedenen Instanzen von Sensordaten 6404 für den bestimmten Kontext zu unterscheiden. Ein ähnliches Training kann für irgendeine Anzahl von verschiedenen Kontexten durchgeführt werden.
• Nachdem das Signalqualitätsmetrikmodell trainiert wurde, kann es eine Instanz von Sensordaten (wobei eine Instanz von Sensordaten über einen bestimmten Zeitraum gesammelte Sensordaten umfasst) und einen zugehörigen Kontext empfangen und eine oder mehrere Angaben zur Sensordatenqualität ausgeben. Die Signalqualitätsmetrik kann zum Beispiel eine zusammengesetzte Bewertung für die Qualität einer Instanz von Sensordaten umfassen. In einem anderen Beispiel kann die Signalqualitätsmetrik eine Bewertung für die Qualität jeder einzelnen Art von Sensordaten umfassen. Die Signalqualitätsmetrik kann zum Beispiel eine Bewertung für Kameradaten und eine Bewertung für LIDAR-Daten umfassen. In einigen Ausführungsformen kann eine Bewertung eine beliebige von mehreren Arten von Qualitätsmetriken sein, wie z. B. eine Messung des Signal-Rausch-Verhältnisses, eine Messung der Auflösung oder eine andere geeignete Art von Qualitätsmetrik. In einigen Ausführungsformen kann die Signalqualitätsmetrik Bewertungen für mehrere Arten von Qualitätsmetriken oder eine einzige Bewertung auf der Grundlage mehrerer Arten von Qualitätsmetriken umfassen. In einigen Ausführungsformen kann der Wert einer Signalqualitätsmetrik ein normalisierter Wert sein (z. B. von 0 bis 1).
• 65 zeigt eine Trainingsphase zur Erstellung eines Übergabebereitschaftsmodells 6508 in Übereinstimmung mit bestimmten Ausführungsformen. In verschiedenen Ausführungsformen kann das Übergabebereitschaftsmodell 6508 ein Klassifizierungsmodell sein, das auf der Grundlage von Signalqualitätsmetriken 6504 und Crash-Informationen 6506 erstellt wird.
• Der ML-Algorithmus 6502 kann ein beliebiger geeigneter Algorithmus zum Trainieren des Übergabebereitschaftsmodells 6508 auf der Grundlage der Signalqualitätsmetriken 6504 und der Crash-Info-Basiswahrheit 6506 sein. Der ML-Algorithmus 6502 kann das Kontextmodell 6308 unter Verwendung verschiedener Instanzen von Signalqualitätsmetriken 6504 und Crash-Info-Ground-Truth 6506 trainieren. Eine für das Training verwendete Instanz kann sowohl eine Signalqualitätsmetrik als auch eine Reihe von Unfallinformationen umfassen. Ein Satz von Crash-Informationen kann jedes geeignete Sicherheitsergebnis umfassen, das mit einer bestimmten Instanz einer Signalqualitätsmetrik verbunden ist. Beispielsweise kann eine Instanz von Unfallinformationen angeben, ob sich ein Unfall ereignet hat, als ein autonomes Fahrzeug unter der Signalqualitätsmetrik betrieben wurde. Als weiteres Beispiel kann eine Instanz von Crash-Informationen anzeigen, ob sich ein Unfall beinahe ereignet hätte, als ein autonomes Fahrzeug unter der Signalqualitätsmetrik betrieben wurde. Als weiteres Beispiel kann eine Instanz von Unfallinformationen anzeigen, ob ein Unfall stattgefunden hat oder beinahe stattgefunden hätte (z. B. können Beinahe-Unfälle genauso behandelt werden wie tatsächliche Unfälle), wenn ein autonomes Fahrzeug unter der Signalqualitätsmetrik betrieben wurde. In verschiedenen Ausführungsformen können die Trainingsdaten tatsächliche Datensignalqualitätsmetriken und Crash-Informationen, simulierte Datensignalqualitätsmetriken und Crash-Informationen, synthetische Datensignalqualitätsmetriken und Crash-Informationen oder eine Kombination davon umfassen.
• 66 zeigt eine Inferenzphase zur Bestimmung einer Übergabeentscheidung 6608 auf der Grundlage von Sensordaten 6602 in Übereinstimmung mit bestimmten Ausführungsformen. In der Inferenzphase, die zum Beispiel von einem fahrzeuginternen Rechensystem während der Fahrt durchgeführt werden kann, werden Sensordaten 6602 gesammelt und dem trainierten Kontextmodell 6308 zur Verfügung gestellt. Das Kontextmodell analysiert die Sensordaten 6308 und ermittelt aus den Sensordaten 6602 einen Kontext 6604. Der ermittelte Kontext 6604 wird zusammen mit den Sensordaten 6602 dem Signalqualitätsmetrikmodell 6408 zur Verfügung gestellt. Das Signalqualitätsmetrikmodell 6408 analysiert die Sensordaten 6602 und den Kontext 6604 und bestimmt eine Signalqualitätsmetrik 6606 basierend auf der Qualität der Sensordaten 6602 unter Berücksichtigung des Kontexts 6604. Die Signalqualitätsmetrik 6606 wird dem Übergabebereitschaftsmodell 6508 zur Verfügung gestellt, das auf dieser Grundlage eine Übergabeentscheidung 6608 trifft. In einer bestimmten Ausführungsform ist die Übergabeentscheidung 6608 eine binäre Angabe darüber, ob die Übergabe sicher ist oder nicht. In anderen Ausführungsformen kann es sich um eine Mehrklassenentscheidung mit drei oder mehr möglichen Ergebnissen handeln. So könnte die Übergabeentscheidung beispielsweise irgendeine Anzahl von Ergebnissen umfassen, die jeweils einen anderen Sicherheitsbereich der Übergabe darstellen. In verschiedenen Ausführungsformen kann das Fahrzeug das Ergebnis der Übergabeentscheidung 6608 nutzen, um zu bestimmen, ob eine Übergabe stattfindet oder nicht, oder um eine teilweise Übergabe durchzuführen, z. B. die Übergabe einiger Bedienelemente, aber nicht anderer (z. B. nur die Lenkung, aber nicht die Bremsen oder umgekehrt).
• In verschiedenen Ausführungsformen kann die Inferenzphase periodisch oder ansprechend auf einen Auslöser (oder beides) durchgeführt werden. Während das autonome Fahrzeug die Fahrsteuerung übernimmt, kann die Inferenzphase beispielsweise in regelmäßigen Abständen durchgeführt werden, um festzustellen, ob das autonome Fahrzeug noch in der Lage ist, die Fahrsteuerung zuverlässig zu übernehmen. Ein weiteres Beispiel: Die Schlussfolgerungsphase kann ausgelöst werden, wenn ein menschlicher Fahrer eine Aufforderung zur Übertragung der Kontrolle auf das Fahrzeug erhält. Ein weiteres Beispiel: Die Inferenzphase kann durch eine Änderung des Kontexts oder eine signifikante Änderung der Qualität der Sensordaten ausgelöst werden.
• In bestimmten Ausführungsformen erfolgt die vorausschauende Planung der Übergabe auf der Grundlage bekannter statischer Daten, z. B. der Verfügbarkeit von hochauflösenden Karten für die Straßen, die das Fahrzeug befahren soll. Diese Art von Daten kann für bestimmte Gebiete, die das Fahrzeug befahren muss, nicht verfügbar sein, z. B. weil die HD-Kartendaten für ein bestimmtes Gebiet noch nicht erfasst worden sind. In solchen Fällen kann das System die Übergabe im Voraus planen (z. B. vor Beginn der Fahrt) und den Fahrer mit einer der hier beschriebenen Übergabetechniken auf die sichere Übergabe vorbereiten. In einem bestimmten Beispiel wird die Inferenzphase zur Bestimmung einer Weitergabeentscheidung bei der Einfahrt (oder kurz vor der Einfahrt) des Fahrzeugs in eine Zone ohne HD-Kartendaten ausgelöst. In einigen Ausführungsformen kann die Verfügbarkeit von HD-Kartendaten als Eingabe für das Signalqualitätsmetrikmodell 6408 verwendet werden, um die Signalqualitätsmetrik positiv zu beeinflussen, wenn die HD-Kartendaten verfügbar sind, oder negativ, wenn sie nicht verfügbar sind. In einigen Ausführungsformen werden die HD-Karten grundsätzlich wie ein zusätzlicher Sensoreingang behandelt.
• In verschiedenen Ausführungsformen können die ML-Algorithmen oder - Modelle, die unter Bezugnahme auf 63-66 können von jedem geeigneten Rechensystem trainiert oder durchgeführt werden, beispielsweise von einem fahrzeuginternen Rechensystem, einem Unterstützungssystem, das mit Hilfe von Cloud- und/oder Fog-basierten Computerressourcen implementiert wird, oder in einer anderen Datenverarbeitungsumgebung.
• 67 zeigt einen Ablauf, mit dem bestimmt wird, ob die Kontrolle über ein Fahrzeug in Übereinstimmung mit bestimmten Ausführungsformen weitergegeben werden soll. Bei 6702 bestimmt ein Rechnersystem eines Fahrzeugs eine Signalqualitätsmetrik auf der Grundlage von Sensordaten und einem Kontext der Sensordaten. Bei 6704 wird auf der Grundlage der Signalqualitätsmetrik eine Wahrscheinlichkeit der Sicherheit im Zusammenhang mit einer Übergabe der Kontrolle über das Fahrzeug bestimmt. Bei 6706 wird eine Übergabe auf der Grundlage der Sicherheitswahrscheinlichkeit verhindert oder eingeleitet.
• Es wird erwartet, dass autonome Fahrzeuge mögliche Vorteile gegenüber menschlichen Fahrern bieten, indem sie besser und konsistenter auf Fahrereignisse reagieren, da sie unempfindlich gegenüber Faktoren sind, die sich negativ auf den Menschen auswirken, wie z. B. Müdigkeit, unterschiedliche Aufmerksamkeitsstufen, Stimmungsschwankungen oder andere Faktoren. Bei autonomen Fahrzeugen kann es jedoch zu Ausrüstungsfehlern oder zu Situationen kommen, in denen das autonome Fahrzeug nicht auf einen angemessenen Betrieb vorbereitet ist (z. B. wenn das autonome Fahrzeug in eine Zone mit neuen Merkmalen einfährt, für die die Fahrzeugalgorithmen nicht trainiert sind), was eine Übergabe des Fahrzeugs an einen menschlichen Fahrer oder ein Anhalten des Fahrzeugs erforderlich macht.
• In verschiedenen Ausführungsformen der vorliegenden Offenbarung wird vor der Übergabe eines Fahrzeugs an einen menschlichen Fahrer der Zustand des Fahrers (z. B. Ermüdungsgrad, Wachheitsgrad, emotionaler Zustand oder ein anderer Zustand) analysiert, um die Sicherheit des Übergabeprozesses zu verbessern. Eine plötzliche Übergabe der Kontrolle an eine Person, die dazu nicht bereit ist, könnte sich als gefährlicher erweisen als die Nichtübergabe, wie eine Reihe von Unfällen mit aktuellen Testfahrzeugen gezeigt hat.
• Autonome Fahrzeuge verfügen in der Regel über Sensoren, die nach außen gerichtet sind, da sich Wahrnehmungssysteme auf die Kartierung der Umgebung und Lokalisierungssysteme auf die Ermittlung des Standorts des Ego-Fahrzeugs auf der Grundlage der Daten dieser Sensoren und der Kartendaten konzentrieren. Verschiedene Ausführungsformen der vorliegenden Offenbarung bieten eine oder mehrere fahrzeuginterne Kameras oder andere Sensoren zur Verfolgung des Fahrerstatus.
• 68 zeigt eine Trainingsphase für ein Fahrerzustandsmodell 6808 in Übereinstimmung mit bestimmten Ausführungsformen. In der Trainingsphase werden dem ML-Algorithmus 6802 Sensordaten 6804 und Grundwahrheitsdaten des Fahrerzustands 6806 zur Verfügung gestellt, die das Fahrerzustandsmodell 6808 auf der Grundlage dieser Daten trainieren. In verschiedenen Ausführungsformen kann das Fahrerzustandsmodell 6808 ein Klassifizierungsmodell sein, das eine Klasse ausgibt, die den Zustand eines Fahrers beschreibt. In anderen Ausführungsformen kann das Fahrerzustandsmodell 6808 ein Regressionsmodell sein, das eine Bewertung für den Zustand des Fahrers ausgibt (wobei höhere Bewertungen einen wünschenswerteren Zustand darstellen).
• In verschiedenen Ausführungsformen können die Sensordaten 6804 alle geeigneten Sensordaten und/oder aus den Sensordaten abgeleitete Informationen darstellen. Die Sensordaten 6804 können beispielsweise Bilddaten umfassen oder auf Bilddaten basieren, die von einer oder mehreren Kameras erfasst wurden, die Bilder aus dem Inneren des Fahrzeugs aufnehmen. In einigen Ausführungsformen können die eine oder mehrere Kameras oder mit den Kameras gekoppelte Rechensysteme Kl-Algorithmen implementieren, um Gesichts-, Augenbrauen- oder Augenbewegungen zu erkennen und Merkmale zu extrahieren, um den Grad der Müdigkeit und Wachsamkeit zu verfolgen, der durch die erkannten Merkmale angezeigt wird.
• In verschiedenen Ausführungsformen können die Sensordaten 6804 eine oder mehrere von einer Infrarotkamera erfasste Temperaturkarten umfassen oder darauf basieren. In einigen Ausführungsformen kann die Infrarotkamera oder ein mit der Infrarotkamera gekoppeltes Rechensystem Kl-Algorithmen implementieren, um den emotionalen Zustand oder einen anderen physischen Zustand des Fahrers auf der Grundlage dieser Temperaturkarten zu verfolgen. So kann beispielsweise ein Anstieg der Körpertemperatur eines menschlichen Fahrers (z. B. durch eine erhöhte Anzahl von Regionen mit roter Farbe in einer Temperaturkarte) auf einen erregten Zustand hindeuten. In verschiedenen Ausführungsformen können die Sensordaten 6804 Druckdaten umfassen oder auf Druckdaten basieren, die von taktilen oder haptischen Sensoren am Lenkrad, Gaspedal oder Fahrersitz erfasst werden. In einigen Ausführungsformen kann ein Rechensystem, das mit solchen taktilen oder haptischen Sensoren gekoppelt ist, Kl-Algorithmen implementieren, um solche Druckdaten zu analysieren, um den Grad der Wachsamkeit oder einen anderen physischen Zustand des Fahrers zu verfolgen.
• In verschiedenen Ausführungsformen können die Sensordaten 6804 Elektrokardiogramm- (EKG) oder Trägheitsmessungsdaten (IMU) von Wearables, wie z. B. einer intelligenten Uhr oder einem Gesundheitsarmband, umfassen oder auf diesen basieren. Ein mit solchen Wearables gekoppeltes Rechensystem oder die Wearables selbst können Kl-Algorithmen verwenden, um EKG-Merkmale zu extrahieren, um den Gesundheitszustand oder andere physische Zustände des Fahrers zu verfolgen, oder um IMU-Daten zu analysieren, um Merkmale zu extrahieren, um den Wachheitsgrad oder andere physische Zustände des Fahrers zu verfolgen.
• In verschiedenen Ausführungsformen können die Sensordaten 6804 Audiodaten von Mikrofonen in der Kabine umfassen oder auf diesen basieren. Diese Daten können mit Techniken zur Geräuschunterdrückung vorverarbeitet werden, um die von den Fahrgästen im Fahrzeug erzeugten Geräusche zu isolieren. Wenn z. B. das Infotainment-System des Fahrzeugs Ton abspielt, kann das Signal des abgespielten Tons vor der weiteren Verarbeitung von dem mit den Mikrofonen in der Kabine aufgenommenen Ton abgezogen werden. Rohe Audiomerkmale können direkt verwendet werden, um die Reaktionsfähigkeit des Benutzers oder den allgemeinen körperlichen Zustand zu beurteilen (undeutliches Sprechen kann z. B. auf Trunkenheit hindeuten), können aber auch zur Klassifizierung von Audioereignissen (z. B. Lachen, Weinen, Gähnen, Schnarchen, Würgen oder andere Ereignisse) verwendet werden, die als weitere Merkmale für den Zustand des Fahrers dienen können. Die analysierten Audiodaten können auch erkannte Sprache (z. B. Sprache, die von einer automatischen Spracherkennungsmaschine oder ähnlichem in Text umgewandelt wurde) aus Dialogen umfassen, die die Fahrgäste miteinander oder mit dem Infotainmentsystem des Fahrzeugs führen. So kann beispielsweise das Dialogsystem des Fahrzeugs nicht nur mit dem Fahrer über eine Übergabe kommunizieren, sondern auch versuchen, die Bestätigung des Fahrers für eine bevorstehende Übergabe einzuholen. Sprache kann in Text umgewandelt und anschließend durch hochentwickelte Pipelines für die Verarbeitung natürlicher Sprache (oder ähnliches) analysiert werden, um die Absicht des Sprechers zu klassifizieren (z. B. positive oder negative Bestätigung), die Stimmung der Interaktionen zu analysieren (z. B. negative Stimmung bei sprachlichem Material wie Schimpfwörtern) oder die diskutierten Themen zu modellieren. Diese Ausgaben können anschließend als zusätzliche Merkmale für den Algorithmus zur Verfolgung des Fahrerzustands verwendet werden.
• Merkmale über den Zustand des Fahrzeugs können auch Aufschluss über den aktuellen Aufmerksamkeitsgrad des Fahrers geben. Zu diesen Merkmalen können beispielsweise eines oder mehrere der Medien gehören, die gerade im Fahrzeug abgespielt werden (z. B. Filme, Videospiele, Musik), der Lichtpegel im Insassenraum, der Grad der Interaktivität des Fahrers mit den Bedienelementen des Armaturenbretts, der Öffnungsgrad der Fenster, der Zustand der Temperaturregelungssysteme im Insassenraum (z. B. Klimaanlage oder Heizung), der Zustand von Geräten, die mit dem Fahrzeug verbunden sind (z. B. ein über Bluetooth verbundenes Mobiltelefon), oder andere Fahrzeugzustandseingaben. Solche Merkmale können in den Sensordaten 6804 als Eingaben für den ML-Algorithmus 6802 umfassen sein, um das Fahrerzustandsmodell 6808 zu trainieren.
• In bestimmten Ausführungsformen können Aktivitätskennzeichnungen aus den Sensordaten durch ein Aktivitätsklassifizierungsmodell abgeleitet werden. So kann das Modell beispielsweise erkennen, ob der Fahrer schläft (z. B. anhand von geschlossenen Augen in den Bilddaten, Schnarchen in den Audiodaten und verringerter Körpertemperatur), sich mit einem anderen Insasse in der Kabine streitet (z. B. wenn die Lautstärke der Stimme ansteigt, der Herzschlag rast, Beleidigungen ausgetauscht werden), sich krank fühlt (z. B. wenn ein Würgegeräusch von den Mikrofonen aufgezeichnet wird und der Fahrer in den Bilddaten mit nach unten gebeugtem Kopf zu sehen ist) oder andere geeignete Aktivitäten ausführt.
• In verschiedenen Ausführungsformen können die Sensor-Rohdaten dem Trainingsalgorithmus 6802 zugeführt werden. Zusätzlich oder alternativ können Klassifizierungen, die auf den Rohsensordaten basieren, dem ML-Algorithmus 6802 zugeführt werden, um das Fahrerzustandsmodell 6808 zu trainieren. In einigen Ausführungsformen können die oben beschriebenen Aktivitätskennzeichnungen dem Trainingsalgorithmus 6802 zugeführt werden (optional auch mit den Merkmalen der unteren Ebene und/oder den Rohsensordaten), um robustere Ergebnisse bei der Verfolgung des Fahrerzustands zu erzielen.
• Die Grundwahrheit des Fahrerzustands 6806 kann bekannte Fahrerzustände umfassen, die den Instanzen der Sensordaten 6804 entsprechen. Wenn das Fahrerzustandsmodell 6808 einen Klassifizierungsalgorithmus implementiert, kann die Grundwahrheit des Fahrerzustands 6806 verschiedene Klassen des Fahrerzustands umfassen. Wenn das Fahrerstatusmodell 6808 einen Regressionsalgorithmus implementiert, kann jede Instanz der Fahrerstatus-Grundwahrheit 6806 einen numerischen Wert umfassen, der einen Fahrerstatus angibt.
• In verschiedenen Ausführungsformen können die Grundwahrheit des Fahrerzustands 6806 und die Sensordaten 6804 spezifisch für den Fahrer sein oder Daten umfassen, die für mehrere verschiedene Fahrer zusammengefasst wurden.
• 69 zeigt eine Trainingsphase für ein Übergabeentscheidungsmodell 6910. Ein ML-Trainingsalgorithmus 6902 verwendet historische Fahrerdaten 6904, Fahrerzustände 6906 und die Übergabeentscheidungen-Ground-Truth 6908, um das Übergabeentscheidungsmodell 6910 zu trainieren. In einer alternativen Ausführungsform kann der ML-Algorithmus 6902 einfach die Fahrerzustände 6906 und die Übergabeentscheidungen-Ground-Truth 6908 verwenden, um das Übergabeentscheidungsmodell 6910 zu trainieren. Die Übergabeentscheidungen-Ground-Truth 6908 kann tatsächliche frühere Übergabeentscheidungen und die entsprechenden Ergebnisse umfassen (z. B. ob ein Unfall oder ein anderes gefährliches Ereignis eingetreten ist). In bestimmten Ausführungsformen können alle oder eine Teilmenge der Übergabeentscheidungen-Ground-Truth 6908 simuliert werden, um den Datensatz zu erweitern.
• Die historischen Fahrerdaten 6904 können alle geeigneten Hintergrundinformationen umfassen, die Aufschluss über den Grad der Aufmerksamkeit des Fahrers geben können. Zu den historischen Daten 6904 können beispielsweise historische Daten für einen Fahrer gehören, darunter Fälle von Trunkenheit am Steuer, frühere Unfälle, potenziell gefährliche Aktionen eines Fahrers (z. B. Abbiegen in den Gegenverkehr, Vollbremsung, um ein Auffahren auf ein anderes Fahrzeug zu vermeiden, Überfahren von Rüttelstreifen), der Gesundheitszustand des Fahrers oder andere geeignete Hintergrundinformationen. In einigen Ausführungsformen kann das autonome Fahrzeug über einen Schlitz für die Fahrer-ID verfügen, in den der Fahrer eine spezielle ID einfügt, und das Konnektivitätssystem des autonomen Fahrzeugs ruft die relevanten historischen Daten für den Fahrer ab. Die Hintergrundinformationen über den Fahrer können auf jede andere geeignete Weise eingeholt werden.
• In der dargestellten Ausführungsform werden während der Trainingsphase die historischen Daten 6904 des Fahrers zusammen mit den Informationen über den Zustand des Fahrers 6906 an den ML-Algorithmus 6902 übermittelt, um ein Modell für die Weitergabeentscheidung 6910 zu erstellen, das zwei oder mehr Klassen ausgibt. In einer Ausführungsform gibt das Übergabeentscheidungsmodell 6910 drei Klassen aus: Übergabe, keine Übergabe oder kurzfristige Übergabe. In einer anderen Ausführungsform gibt das Übergabe-Entscheidungsmodell 6910 zwei Klassen aus: Übergabe oder keine Übergabe. In einer weiteren Ausführungsform kann eine der Klassen eine Teilübergabe sein. Als verschiedene Beispiele kann die Klasse „Übergabe“ anzeigen, dass die Übergabe mit einem hohen Maß an Vertrauen durchgeführt werden kann, die Klasse „keine Übergabe“ kann ein niedriges Maß an Vertrauen anzeigen und kann in Situationen, in denen eine fortgesetzte Kontrolle durch das Fahrzeug unerwünscht ist, dazu führen, dass die Übergabe an ein Fernüberwachungssystem verschoben wird, das die Kontrolle über das Fahrzeug übernimmt, bis der Fahrer bereit ist oder das Fahrzeug zu einem sicheren Halt gebracht wird; eine Klasse der „kurzfristigen Übergabe“ kann ein mittleres Maß an Vertrauen in den Fahrer darstellen und kann in einigen Ausführungsformen dazu führen, dass die Kontrolle an einen Fahrer mit einem Zeitlimit übergeben wird, innerhalb dessen das Fahrzeug zum Anhalten gezwungen wird (z. B. das Kraftfahrzeug kann von einer Bereitschaftseinheit, z. B. einem Kommunikationssystem, das die Kabine steuert oder einen Aufbewahrungsort für die Kabine bereitstellt, zum sicheren Halt gebracht werden). In einer anderen Ausführungsform kann eine „teilweise Übergabe“ ein mittleres Maß an Vertrauen in den Fahrer darstellen und dazu führen, dass nur ein Teil der Kontrolle an den Fahrer übergeben wird (z. B. nur die Bremskontrolle oder nur die Lenkkontrolle). In einer Ausführungsform kann eine „bedingte Übergabe“ ein mittleres Maß an Vertrauen in den Fahrer darstellen und dazu führen, dass die Übergabe an den Fahrer erfolgt und die Aktionen des Fahrers und/oder der Zustand des Benutzers überwacht werden, um sicherzustellen, dass das Fahrzeug sicher betrieben wird. Die obigen Angaben stellen lediglich Beispiele für mögliche Übergabeklassen dar, und das Übergabe-Entscheidungsmodell 6910 kann jede beliebige Kombination der obigen Übergabeklassen oder andere geeignete Übergabeklassen ausgeben.
• In verschiedenen Ausführungsformen kann auch der von den äußeren Sensoren des Fahrzeugs erfasste Kontext berücksichtigt werden, um die Fähigkeit des Fahrers zu bewerten, eine Übergabe erfolgreich durchzuführen. So können beispielsweise die Wetterbedingungen, die Sichtverhältnisse, die Straßenverhältnisse, die Verkehrssituation oder andere Bedingungen den für eine Übergabe erforderlichen Grad der Wachsamkeit beeinflussen. Bei ungünstigen Wetterverhältnissen kann beispielsweise eine andere Aufmerksamkeit erforderlich sein, bevor man einem Fahrer das Fahrzeug übergibt. Dies kann durch Einspeisung von Kontextinformationen in den Algorithmus für maschinelles Lernen 6902 oder auf andere geeignete Weise erfolgen.
• 70 zeigt eine Inferenzphase zur Bestimmung einer Weitergabeentscheidung 7008 in Übereinstimmung mit bestimmten Ausführungsformen. Die oben beschriebenen Sensordaten 7002 werden dem Treiberzustandsmodell 6808 zugeführt, das einen Treiberzustand 7004 ausgibt. Der Fahrerstatus 7004 und die historischen Daten 7006 werden dem Übergabeentscheidungsmodell 6910 zur Verfügung gestellt, das eine Übergabeentscheidung 7008 wie oben beschrieben oder eine andere geeignete Übergabeentscheidung ausgibt. In anderen Ausführungsformen kann das Übergabe-Entscheidungsmodell andere Faktoren berücksichtigen (z. B. einen Kontext der Fahrsituation, der von einem oder mehreren nach außen gerichteten Sensoren ermittelt wird) oder die historischen Daten 7006 weglassen.
• Die Inferenzphase kann ansprechend auf jeden geeigneten Auslöser durchgeführt werden. Die Schlussfolgerungsphase kann beispielsweise durchgeführt werden, wenn festgestellt wird, dass das Fahrzeug nicht in der Lage ist, sich selbständig mit einem akzeptablen Sicherheitsniveau zu bewegen. Ein weiteres Beispiel: Die Inferenzphase kann regelmäßig durchgeführt werden, während ein menschlicher Fahrer das Fahrzeug führt, und das Ergebnis der Inferenzphase kann die Feststellung sein, ob der Fahrer in der Lage ist, das Fahrzeug zu führen. Ist der Fahrer nicht fit, kann das Fahrzeug die gesamte oder einen Teil der Fahrkontrolle übernehmen, den Fahrer warnen oder Maßnahmen ergreifen, um die Wachsamkeit des Fahrers zu erhöhen (z. B. laute Musik einschalten, die Fenster öffnen, den Fahrersitz oder das Lenkrad vibrieren lassen oder andere geeignete Maßnahmen).
• Wenn das System die Übergabe an den menschlichen Fahrer beschließt, wird der Fahrer über die bevorstehende Übergabe informiert. Zu diesem Zweck kann das System mit dem Fahrer auf eine oder mehrere Arten in Kontakt treten. Das System kann zum Beispiel verbal mit dem Fahrer kommunizieren. So kann beispielsweise ein Text mit korrekter Semantik und Syntax von einer Engine zur Erzeugung natürlicher Sprache erstellt und dann von einer Text-to-Speech-Engine in synthetische Sprachausgabe umgewandelt werden, um eine verbale Nachricht zu erzeugen, die die Übergabe beschreibt. Ein weiteres Beispiel ist der physische Kontakt des Systems mit dem Fahrer. So kann beispielsweise ein am Fahrersitz oder am Lenkrad angebrachter Motor dazu führen, dass der Sitz oder das Lenkrad stark vibriert, wobei die Sicherheit des Fahrers zu berücksichtigen ist, um ihn nicht zu erschrecken und einen Unfall zu verursachen. In anderen Ausführungsformen kann das System auf jede geeignete Weise mit dem Fahrer in Kontakt treten, um die Übergabe zu kommunizieren.
• 71 zeigt einen Ablauf zur Generierung einer Übergabeentscheidung in Übereinstimmung mit bestimmten Ausführungsformen. In 7102 werden Sensordaten von mindestens einem Sensor gesammelt, der sich im Fahrzeug befindet. Bei 7104 werden die Sensordaten analysiert, um den physischen Zustand einer Person im Fahrzeug zu bestimmen. Bei 7106 wird eine Übergabeentscheidung generiert, die zumindest teilweise auf dem physischen Zustand der Person basiert, wobei die Übergabeentscheidung angibt, ob die Person voraussichtlich in der Lage ist, das Fahrzeug sicher zu bedienen.
• Wie hier beschrieben, können einige autonome Fahrsysteme mit Funktionen ausgestattet sein, die die Übertragung der Kontrolle vom autonomen Fahrzeug auf einen menschlichen Benutzer im Fahrzeug oder an einem entfernten Ort (z. B. bei einer Remote-Valet--Anwendung) unterstützen. In einigen Implementierungen kann ein autonomes Fahrsystem einen logikbasierten Rahmen für die reibungslose Übertragung der Kontrolle von Fahrgästen (EGO) auf autonome Fahrzeuge (Agenten) und umgekehrt unter verschiedenen Bedingungen und in verschiedenen Situationen verwenden, um sowohl die Sicherheit der Fahrgäste als auch die Sicherheit im Straßenverkehr zu erhöhen. Zumindest einige Aspekte dieses Rahmens können durch die Implementierung auf der Hardware des autonomen Fahrsystems parallelisiert werden (z. B. durch einen FPGA, einen Hadoop-Cluster usw.).
• So könnte ein Beispielrahmen die verschiedenen Situationen berücksichtigen, in denen es entweder für das autonome Fahrzeug oder für einen menschlichen Fahrer sicherer ist, die Kontrolle über das Fahrzeug zu übernehmen, und Mechanismen vorschlagen, um diese Kontrollanfragen zwischen den beiden Parteien umzusetzen. Beispielsweise kann es Situationen geben, in denen das autonome Fahrzeug die Kontrolle über das Fahrzeug wiedererlangen möchte, um sicherer fahren zu können. Das autonome Fahrzeug kann mit Kameras oder anderen internen Sensoren (z. B. Mikrofonen) ausgestattet sein, die dazu verwendet werden können, den Bewusstseinszustand des Fahrers zu erfassen (z. B. um festzustellen, ob der Fahrer durch einen Telefonanruf abgelenkt ist oder sich schläfrig/übermüdet fühlt) und auf der Grundlage des Bewusstseins des Fahrers zu entscheiden, ob die Kontrolle übernommen werden soll. Das autonome Fahrzeug kann einen Mechanismus umfassen, um Sensordaten zu analysieren (z. B. Analyse der Kamera- und Mikrofondaten aus dem Fahrzeuginneren) und die Kontrolle vom Fahrer anzufordern und zu übernehmen, wenn der Aufmerksamkeitsgrad des Fahrers niedrig ist oder der Fahrer anderweitig als unsicher gilt (z. B. Trunkenheit am Steuer, Freisprechen am Steuer, Schlafen am Steuer, Simsen am Steuer, rücksichtsloses Fahren usw.) oder wenn das autonome Fahrzeug anormale Aktivitäten im Fahrzeug wahrnimmt (z. B. einen Streit, einen Schrei oder ein anderes unsicheres Fahrverhalten des Fahrers oder der Fahrgäste). Auf diese Weise kann die Sicherheit der Personen sowohl innerhalb als auch außerhalb des autonomen Fahrzeugs erhöht werden.
• In einigen Implementierungen kann eine auf Authentifizierung basierende (z. B. unter Verwendung eines biometrischen) Befehlssteuerung verwendet werden, um eine unbefugte Nutzung des autonomen Fahrzeugs zu verhindern. Wenn zum Beispiel ein autonomes Fahrzeug gestohlen wird oder in falsche Hände gerät, kann das autonome Fahrzeug dieses Szenario erkennen und sich selbst gegen die Kontrolle sperren. So kann beispielsweise ein Authentifizierungsmechanismus in das autonome Fahrzeug eingebaut werden, der biometrische Daten (z. B. Fingerabdrücke, Sprach- und Gesichtserkennung, Führerschein usw.) verwendet, um einen Benutzer zu authentifizieren, der die Kontrolle über das autonome Fahrzeug beantragt. Diese Mechanismen können die unautorisierte Nutzung des autonomen Fahrzeugs verhindern. In einigen Fällen kann die Nutzung des autonomen Fahrzeugs oder von Aspekten davon auf der Grundlage verschiedener Berechtigungsstufen erfolgen. So kann beispielsweise ein Benutzer das Fahrzeug an einem beliebigen Ort vollständig manuell steuern, während ein anderer Benutzer das Fahrzeug nur an einem bestimmten geografisch eingegrenzten Ort steuern kann. Ein weiteres Beispiel: In einigen Ausführungsformen kann ein Insasse die Kontrolle über das autonome Fahrzeug anfordern, wenn bestimmte Situationen eintreten, wie z. B. stark befahrene Straßen, schlechtes Wetter, defekte Sensoren (z. B. Kameras, LIDAR, Radar usw.) usw. ansprechend auf die Anforderung kann das autonome Fahrzeug den Benutzer auf der Grundlage eines oder mehrerer biometrischer Merkmale des Benutzers authentifizieren, und wenn er authentifiziert ist, kann es die Kontrolle über das autonome Fahrzeug an den Benutzer übergeben. Ein weiteres Beispiel: Wenn eine Einrichtung/Benutzer (z. B. Strafverfolgungsbehörden, Ersthelfer, Regierungsbeamte usw.) das autonome Fahrzeug aus der Ferne steuern möchte, kann das autonome Fahrzeug den Benutzer validieren, bevor es die Steuerung an die Einrichtung/Benutzer überträgt.
• In einigen Ausführungsformen kann die Steuerung eines autonomen Fahrzeugs von mehreren umliegenden Fahrzeugen (einschließlich Strafverfolgungsfahrzeugen) oder infrastrukturbasierten Sensoren/Steuergeräten übernommen werden, z. B. wenn die umliegenden autonomen Fahrzeuge der Meinung sind, dass das autonome Fahrzeug gefährlich fährt oder nicht innerhalb der akzeptablen Grenzen der Verhaltensmodelle der anderen Fahrzeuge liegt. In solchen Fällen können die die Kontrolle anfordernde(n) Einheit(en) authentifiziert werden, z. B. durch biometrische Daten bei Personen, die die Kontrolle anfordern, oder durch digitale Sicherheitsinformationen (z. B. digitale Zertifikate) bei autonomen Fahrzeugen/Infrastruktursensoren.
• 72 zeigt ein übergeordnetes Blockdiagramm des obigen Rahmens in Übereinstimmung mit mindestens einer Ausführungsform. In Szenario 7202 fährt das autonome Fahrzeug beispielsweise im menschengesteuerten/manuellen Betriebsmodus, wenn das autonome Fahrzeug (z. B. über Kamera- oder Mikrofondaten aus dem Inneren des autonomen Fahrzeugs) unsichere Fahrbedingungen erkennt (z. B. die in 72 aufgeführt sind oder andere unsichere Bedingungen) und gibt dementsprechend die Kontrolle an das autonome Fahrzeug zurück, um im autonomen Fahrmodus fortzufahren. In diesem Szenario kann das autonome Fahrzeug den Fahrer auffordern, die Kontrolle über das Fahrzeug wiederzuerlangen, bevor es selbst die Kontrolle übernimmt.
• In Szenario 7204 fordert ein menschlicher Fahrer die Kontrolle über das autonome Fahrzeug an, z. B. als Reaktion darauf, dass der Fahrer eine Situation identifiziert (z. B. die in 72 aufgeführt sind oder andere), in denen sich der Fahrer nicht wohl dabei fühlt, im autonomen Modus zu fahren. Das autonome Fahrzeug kann eine Authentifizierungsanforderung bei 7205 einleiten, um den menschlichen Fahrer zu authentifizieren, z. B. unter Verwendung biometrischer oder anderer Authentifizierungsmethoden, und kann bei gültiger Authentifizierung die Kontrolle vom autonomen Fahrzeug an den menschlichen Fahrer übergeben (andernfalls behält das autonome Fahrzeug die Kontrolle).
• Im Szenario 7206 kann ein Strafverfolgungsbeamter oder ein benachbartes autonomes Fahrzeug die Kontrolle über das autonome Fahrzeug anfordern, z. B. aufgrund einer beobachteten unsicheren Fahrweise des autonomen Fahrzeugs, weil das autonome Fahrzeug als gestohlen gemeldet wurde, weil das autonome Fahrzeug für die Kontrolle von Menschenmengen/Straßen bewegt werden muss usw. Das autonome Fahrzeug kann eine Authentifizierungsanforderung bei 7207 einleiten, um die anfragende Person/Einheit zu authentifizieren, und bei gültiger Authentifizierung die Kontrolle vom autonomen Fahrzeug an den Beamten/das benachbarte autonome Fahrzeug übergeben (andernfalls behält das autonome Fahrzeug die Kontrolle).
• 73 ist ein Diagramm eines Beispiels für einen Prozess zur Kontrolle von Übernahmen eines autonomen Fahrzeugs gemäß mindestens einer Ausführungsform. Die Vorgänge im Beispielprozess können durch Aspekte oder Komponenten eines autonomen Fahrzeugs durchgeführt werden. Der Beispielprozess 7300 kann zusätzliche oder andere Vorgänge umfassen, und die Vorgänge können in der gezeigten oder einer anderen Reihenfolge durchgeführt werden. In manchen Fällen können eine oder mehrere der in 73 gezeigten Operationen als Prozesse implementiert werden, die mehrere Operationen, Unterprozesse oder andere Arten von Routinen umfassen. In einigen Fällen können Vorgänge kombiniert, in anderer Reihenfolge, parallel, iterativ oder auf andere Weise wiederholt oder durchgeführt werden.
• Bei 7302 wird ein autonomes Fahrzeug im autonomen Modus betrieben, wobei das autonome Fahrzeug viele oder alle Aspekte des Betriebs des autonomen Fahrzeugs steuert.
• Um 7304 erhält das autonome Fahrzeug eine Aufforderung von einer anderen Einheit, die Kontrolle über das autonome Fahrzeug zu übernehmen. Die Einheit kann ein menschlicher Insasse/Fahrer des autonomen Fahrzeugs, eine vom autonomen Fahrzeug entfernte Person (z. B. Strafverfolgungs- oder Regierungsbeamte) oder ein anderes autonomes Fahrzeug oder mehrere autonome Fahrzeuge in der Nähe des autonomen Fahrzeugs (z. B. Crowdsourced Control) sein.
• Um 7306 fordert das autonome Fahrzeug die Entität auf, sich zu authentifizieren, um die Kontrolle anzufordern. Die Aufforderung kann eine Aufforderung für ein biometrisches Merkmal, wie z. B. einen Fingerabdruck, einen Stimmenabtastwert für die Stimmerkennung, einen Gesichtsabtastwert für die Gesichtserkennung oder eine andere Art von biometrischem Merkmal umfassen. Die Aufforderung kann eine Aufforderung zur Eingabe anderer Arten von Anmeldeinformationen wie Benutzername, Passwort usw. umfassen.
• Bei 7308 empfängt das autonome Fahrzeug Eingaben von der anfragenden Einheit und stellt bei 7310 fest, ob die Einheit auf der Grundlage der empfangenen Eingaben authentifiziert ist. Wenn die Einheit authentifiziert ist, erlaubt das autonome Fahrzeug die Übernahme und übergibt die Kontrolle an die anfragende Einheit bei 7312. Wird die Entität aufgrund der Eingabe nicht authentifiziert, lehnt das autonome Fahrzeug die Übernahmeanfrage ab und fährt im autonomen Betriebsmodus fort.
• 74 ist ein Diagramm eines weiteren Beispiels für die Kontrolle von Übernahmen eines autonomen Fahrzeugs in Übereinstimmung mit mindestens einer Ausführungsform. Die Vorgänge im Beispielprozess können durch Aspekte oder Komponenten eines autonomen Fahrzeugs durchgeführt werden. Der Beispielprozess 7400 kann zusätzliche oder andere Vorgänge umfassen, und die Vorgänge können in der gezeigten oder einer anderen Reihenfolge durchgeführt werden. In manchen Fällen können eine oder mehrere der in 74 gezeigten Operationen als Prozesse implementiert werden, die mehrere Operationen, Unterprozesse oder andere Arten von Routinen umfassen. In einigen Fällen können Vorgänge kombiniert, in anderer Reihenfolge, parallel, iterativ oder auf andere Weise wiederholt oder durchgeführt werden.
• In 7402 wird ein autonomes Fahrzeug in einer manuellen/menschgesteuerten Betriebsart betrieben, wobei ein Mensch (entweder innerhalb des autonomen Fahrzeugs oder entfernt vom autonomen Fahrzeug) einen oder mehrere Aspekte des Betriebs des autonomen Fahrzeugs steuert.
• Um 7404 empfängt das autonome Fahrzeug Sensordaten von einem oder mehreren Sensoren, die sich im Inneren des autonomen Fahrzeugs befinden, und um 7406 analysiert es die Sensordaten, um festzustellen, ob die Eingaben des menschlichen Bedieners sicher sind. Wird die Eingabe als sicher eingestuft, fährt das autonome Fahrzeug im manuellen Betriebsmodus fort. Wird die Eingabe als unsicher eingestuft, fordert das autonome Fahrzeug bei 7408 eine Kontrollübernahme durch den menschlichen Bediener an und betreibt das autonome Fahrzeug bei 7410 in der autonomen Betriebsart.
• Der Übergang von autonomen Fahrzeugen der Stufe 2 („L2“ oder „L2+“) zu autonomen Fahrzeugen der Stufe 5 („L5“) mit vollständiger Autonomie kann mehrere Jahre dauern, und die Branche der autonomen Fahrzeuge wird möglicherweise einen allmählichen Übergang der Zuständigkeiten von der Rolle des menschlichen Fahrers bis zum Erreichen des Zustands der vollständigen Autonomie (ohne Fahrer) überall und jederzeit beobachten. Die sichere Umstellung von der maschinellen Steuerung (autonomer Modus) auf die menschliche Steuerung (menschengesteuerter Modus) ist in dieser Übergangsphase von entscheidender Bedeutung, bringt jedoch einige Herausforderungen mit sich. Eine der potenziellen Herausforderungen ist zum Beispiel die Kontrolle der zufälligen Eingriffe des menschlichen Fahrers, die ohne Aufforderung durch das autonome System erfolgen. Eine weitere Herausforderung ergibt sich aus ereignisorientierten Maßnahmen. Es gibt drei Arten von Übernahmen, die bei autonomen Fahrzeugen vorkommen können:
• Fahrzeug Angeforderte Übernahme: Wenn das Fahrzeug den Fahrer auffordert, das Steuer zu übernehmen und vom autonomen Modus in den vom Menschen gesteuerten Modus zu wechseln. Dies kann in einigen Fällen der Fall sein, wenn das autonome Fahrzeug mit einer für sein Wahrnehmungssystem neuen Situation konfrontiert ist, z. B. wenn die beste Entscheidung ungewiss ist oder wenn das Fahrzeug aus einem geografisch abgegrenzten Gebiet herauskommt. Der allgemeine Ansatz für die Aufforderung zur Übernahme durch den Menschen besteht darin, den Fahrer auf eine oder mehrere Arten zu warnen (z. B. durch Meldungen auf dem Armaturenbrett, Signaltöne oder Vibrationen am Lenkrad). Während der menschliche Fahrer sich auf die Übernahme einstellt, kann es zu Fehlern bei der Übernahme kommen, weil die Reaktionszeit des Menschen länger dauert als erwartet, weil der Mensch unkonzentriert ist oder aus anderen Gründen.
• Zufällige Übernahme durch einen menschlichen Fahrer: Eine mögliche Übernahme durch den menschlichen Fahrer kann willkürlich (z. B. ohne Aufforderung durch das Fahrzeug) und aus unvorhergesehenen Gründen erfolgen. So kann der menschliche Fahrer beispielsweise abgelenkt sein oder aus einem ungewollten Schlaf erwachen und unangemessen reagieren (das Steuer schnell und unbewusst übernehmen). Ein weiteres Beispiel: Der menschliche Fahrer hat es vielleicht eilig (z. B. um einen Flug oder ein wichtiges Ereignis einzuholen) und ist mit der Geschwindigkeit des Fahrzeugs im autonomen Modus unzufrieden, so dass er die Kontrolle übernimmt, um schneller zu fahren. Solche zufälligen Übernahmen können unerwünscht sein, da es nicht möglich wäre, für solche unvorhergesehenen Übernahmen Fahrregeln/Politiken aufzustellen, und die zufällige Übernahme selbst kann zu Unfällen/Unfällen führen.
• Ereignisgesteuerte Übernahme durch einen Menschen: Eine weitere mögliche Übernahme kann durch den Menschen aufgrund unvorhergesehener Ereignisse erfolgen. Der menschliche Fahrer kann beispielsweise das plötzliche Bedürfnis verspüren, aus dem Kraftfahrzeug auszusteigen (z. B. aufgrund von Klaustrophobie, Übelkeit usw.). Ein weiteres Beispiel: Ein Beifahrer, der mit dem menschlichen Fahrer mitfährt, gerät in eine plötzliche Gefahrensituation, und der menschliche Fahrer kann die Kontrolle übernehmen und das Fahrzeug anhalten. Ein weiteres Beispiel: Ein menschlicher Fahrer kann sich auf der Straße unwohl fühlen (z. B. auf einer dunklen und unbekannten Straße), was das Bedürfnis auslöst, die Kontrolle zu übernehmen, um sich wohler zu fühlen. Solche Übernahmen können unerwünscht sein, da sie den autonomen Fahrmodus auf unvorhersehbare Weise stören können, und die Übernahmen selbst können zu Unfällen führen. Ähnlich wie im vorhergehenden Fall ist auch diese Art der Übernahme unerwünscht, da es nicht möglich wäre, für solche unvorhergesehenen Übernahmen Regeln/Politiken aufzustellen, und eine Übernahme, die durch unvorhergesehene Ereignisse ausgelöst wird, ist wahrscheinlich nicht sicher.
• Von diesen Typen können die zufälligen und ereignisgesteuerten Übernahmen als unsicher angesehen werden, und dementsprechend können autonome Fahrsysteme speziell so ausgebildet werden, dass sie diese Arten von Übernahmen erkennen und kontrollieren, was ein sichereres Fahren und die Vermeidung von unvorhersehbarem Verhalten während des autonomen Fahrmodus ermöglichen kann. In bestimmten Ausführungsformen können diese potenziell unsicheren Übernahmesituationen entschärft werden:
• • Die Wahrnehmungsphase des autonomen Fahrens (z. B. in der bordeigenen Wahrnehmungssoftware) kann um ein Softwaremodul zur Erkennung unsicherer Übernahmen in Echtzeit erweitert werden;
• • Die Phase des autonomen Fahrens (z. B. die im bordeigenen System implementierte Fahrzeugsteuerungssoftware und -hardware) kann um ein Softwaremodul erweitert werden, mit dem die erkannte unsichere Übernahme in Echtzeit gemildert werden kann
• • Die Planphase des autonomen Fahrens (z. B. das/die Teilsystem(e) der Routenplanung) kann als Mittel zur Schadensbegrenzung um die Berücksichtigung möglicher Umleitungen oder anderer Anpassungen des autonomen Fahrmodus erweitert werden, um Unannehmlichkeiten für Fahrgäste oder Fahrer zu vermeiden.
• 75 ist ein Diagramm einer beispielhaften Pipeline 7600 für Wahrnehmung, Planung und autonomes Fahren für ein autonomes Fahrzeug in Übereinstimmung mit mindestens einer Ausführungsform. Insbesondere gibt 75 einen Überblick über bestimmte Überlegungen zur Wahrnehmung und Steuerung autonomer Fahrzeuge, um potenziell unsichere Übernahmen in Echtzeit zu erkennen und zu entschärfen. Die Vorgänge in der Wahrnehmungs-, Planungs- und Handlungspipeline können von einem bordeigenen Steuersystem des autonomen Fahrzeugs durchgeführt werden. Wie dargestellt, umfasst die beispielhafte Wahrnehmungs-, Planungs- und Handlungspipeline eine Erfassungs-/Wahrnehmungsphase, eine Planungsphase und eine Handlungs-/Kontrollphase.
• Im gezeigten Beispiel empfängt das Steuersystem Sensordaten von einer Mehrzahl von Sensoren, die mit dem autonomen Fahrzeug gekoppelt sind, einschließlich Fahrzeugwahrnehmungssensoren (z. B. Kamera(s), LIDAR usw.) und Fahrzeugsteuerungselemente (z. B. Lenkradsensor, Brems-/Beschleunigungspedalsensoren, interne Kamera(s), interne Mikrofone usw.). Das Kontrollsystem verwendet die Sensordaten in der Erkennungs-/Wahrnehmungsphase, um eine unsichere Übernahmeaufforderung durch einen menschlichen Fahrer des autonomen Fahrzeugs zu erkennen. Die Erkennung von unsicheren Übernahmen kann auf mindestens einem Teil der empfangenen Sensordaten basieren. Beispielsweise können unsichere Übernahmen auf der Grundlage von Sensoren erkannt werden, die mit dem Gaspedal, dem Bremspedal und/oder dem Lenkrad verbunden sind, um eine Übernahmehandlung zu erkennen. In einigen Fällen können Kameras und/oder Mikrofone im Inneren des Fahrzeugs (z. B. mit künstlicher Intelligenz) verwendet werden, um zu erkennen, dass der Fahrer die Kontrolle über das autonome Fahrzeug übernimmt. In einigen Ausführungsformen können die Daten der Pedal-/Lenkradsensoren und der Fahrzeugkameras miteinander korreliert werden, um eine potenzielle Übernahmeanforderung durch den Menschen zu erkennen und festzustellen, ob es sich bei den Aktionen tatsächlich um eine gewünschte Übernahme handelt oder nicht. So kann ein plötzlich erwachter oder abgelenkter Fahrer die Bremse, das Gaspedal oder das Lenkrad betätigen, ohne die Absicht zu haben, eine willkürliche Übernahme der Kontrolle einzuleiten.
• Nachdem festgestellt wurde, dass die angeforderte Übernahme unsicher ist, entschärft das Kontrollsystem die unsichere Übernahmeanforderung. Dies kann z. B. bedeuten, dass die Übernahmeanforderung blockiert wird, so dass der menschliche Fahrer das autonome Fahrzeug nicht steuern darf. So können beispielsweise das Lenkrad, das Bremsbetätigungselement/-pedal und das Gasbetätigungselement/-pedal während des autonomen Fahrmodus verriegelt sein und erst dann entriegelt werden, wenn das autonome Fahrzeug eine Übernahme durch den Menschen anfordert (dies kann ansprechend auf die Erkennung erfolgen, dass eine zufällige Übernahmeanforderung sicher ist, wie unten beschrieben). Darüber hinaus können die Türen bei einer unsicheren Übernahmeanforderung verriegelt bleiben, da in einigen Fällen die Entriegelung der Türen nur möglich ist, wenn sich das Fahrzeug im Stillstand befindet (nicht in Bewegung ist).
• In einigen Fällen kann die Entschärfung der unsicheren Übernahmeanforderung darin bestehen, den autonomen Fahrmodus so zu ändern, dass er den Wünschen des Fahrers/Beifahrers entspricht. So kann das Kontrollsystem beispielsweise die Route des autonomen Fahrzeugs neu planen (z. B. Richtung, Geschwindigkeit usw.), um den Komfort des Fahrers/Beifahrers zu gewährleisten und das durch die Übernahmeaufforderung verursachte Risiko für den Fahrer/Beifahrer zu minimieren. In einigen Fällen kann das Steuersystem den menschlichen Fahrer und/oder die Fahrgäste auffordern, ansprechend auf die Übernahmeaufforderung Eingaben zu machen (z. B. mit einer Sprachansage (bei spracherkennungsfähigen autonomen Fahrzeugen) und/oder einer Texteingabe), und kann einen oder mehrere Aspekte des autonomen Modus auf der Grundlage der vom Fahrer/Beifahrer erhaltenen Eingaben ändern.
• 76 ist ein Diagramm eines Beispielprozesses zur Kontrolle von Übernahmeanfragen durch menschliche Fahrer eines autonomen Fahrzeugs in Übereinstimmung mit mindestens einer Ausführungsform. Insbesondere veranschaulicht 76 ein Verfahren zur Erkennung und Eindämmung unsicherer Übernahmen. Die Vorgänge im Beispielprozess können von Komponenten eines autonomen Fahrzeugs (z. B. einem Steuerungssystem eines autonomen Fahrzeugs) durchgeführt werden. Der Beispielprozess 7600 kann zusätzliche oder andere Vorgänge umfassen, und die Vorgänge können in der gezeigten oder einer anderen Reihenfolge durchgeführt werden. In manchen Fällen können eine oder mehrere der in 76 gezeigten Operationen als Prozesse implementiert werden, die mehrere Operationen, Unterprozesse oder andere Arten von Routinen umfassen. In einigen Fällen können Vorgänge kombiniert, in anderer Reihenfolge, parallel, iterativ oder auf andere Weise wiederholt oder durchgeführt werden.
• Um 7602 befindet sich ein autonomes Fahrzeug in einem autonomen Fahrmodus. Beispielsweise kann ein Steuersystem des autonomen Fahrzeugs einen oder mehrere Aspekte des Betriebs des autonomen Fahrzeugs steuern, z. B. durch eine Wahrnehmungs-, Planungs- und Handlungspipeline. Bei 7604 bestimmt das autonome Fahrzeug (z. B. auf der Grundlage von Sensordaten, die an das Steuerungssystem übermittelt werden), ob eine unregelmäßige oder unbekannte Situation vorliegt. Wenn dies der Fall ist, fordert das autonome Fahrzeug bei 7606 den menschlichen Fahrer auf, die Kontrolle über das autonome Fahrzeug zu übernehmen, und bei 7608 tritt das autonome Fahrzeug in den Betriebsmodus „menschliches Fahren“ ein (bei dem ein menschlicher Fahrer das autonome Fahrzeug steuert) und fährt in diesem Modus. Das autonome Fahrzeug kann dann während der Betriebsart „Menschliches Fahren“ um 7610 feststellen, ob eine reguläre/bekannte Bedingung vorliegt. Ist dies der Fall, kann das autonome Fahrzeug bei 7612 die Übernahme der Kontrolle beantragen oder die Kontrolle über das autonome Fahrzeug wiedererlangen und wieder in den autonomen Betriebsmodus eintreten. Wird bei 7604 keine irreguläre/unbekannte Situation angetroffen, setzt das autonome Fahrzeug den Betrieb im autonomen Fahrmodus fort, wobei es kontinuierlich feststellen kann, ob es auf eine irreguläre/unbekannte Situation trifft.
• Bei 7614 erkennt das autonome Fahrzeug eine Übernahmeaufforderung durch einen menschlichen Fahrer. Die Übernahmeanforderung kann auf Sensordaten von einem oder mehreren Sensoren basieren, die mit dem autonomen Fahrzeug gekoppelt sind. Dazu können Sensoren gehören, die sich im Inneren des autonomen Fahrzeugs befinden (z. B. Sensoren, die mit dem Lenkrad, dem Bremsenbetätigungselement, dem Gaspedalbetätigungselement oder internen Kameras oder Mikrofonen gekoppelt sind).
• Bei 7616 bestimmt das autonome Fahrzeug, ob die Übernahmeanfrage unsicher ist. Ist dies der Fall, kann das autonome Fahrzeug die unsichere Übernahmeanforderung entschärfen. Zum Beispiel kann das autonome Fahrzeug bei 7618 die Übernahmeanfrage blockieren. Darüber hinaus kann das autonome Fahrzeug den Fahrer um Eingaben bitten (z. B. ein Gespräch mit dem Fahrer unter Verwendung einer Spracherkennungssoftware ermöglichen) (7618), um mehr über den Grund für die Übernahmeanfrage oder die irreguläre Situation zu erfahren.
• Bei 7620 bestimmt das autonome Fahrzeug auf der Grundlage der vom Fahrer erhaltenen Eingaben, wie die Situation mit dem Fahrer ist oder aus welchem Grund der Fahrer die Übernahmeanfrage gestellt hat. Wird beispielsweise festgestellt, dass die Situation ein Risiko für einen Fahrer oder Beifahrer darstellt (z. B. Schreien, unsicheres Verhalten usw.), muss die Route möglicherweise neu geplant werden, und das autonome Fahrzeug kann den autonomen Fahrmodus so ändern, dass es an der Haltestelle 7622 anhält. Wenn beispielsweise festgestellt wird, dass der autonome Fahrmodus für den Fahrer und/oder Beifahrer unangenehm ist (z. B. eine unbekannte Strecke/Straße, eine sehr dunkle Umgebung usw.), kann das autonome Fahrzeug den autonomen Fahrmodus so ändern, dass dem Fahrer/Beifahrer mehr visuelle Informationen zur Verfügung gestellt werden (z. B. Anzeige von (zusätzlichen) Streckendetails; das autonome Fahrzeug kann auch die Fahrzeugbeleuchtung so einstellen, dass der Fahrer die zusätzlichen Informationen sehen kann), die bei 7624 angezeigt werden, um dem Fahrer und/oder Beifahrer zu helfen, mehr Komfort mit dem autonomen Fahrmodus zu erreichen. Wird beispielsweise eine Situation als Beschwerde über die Geschwindigkeit identifiziert (z. B. möchte der Fahrer, dass das autonome Fahrzeug langsamer oder schneller fährt), kann in der Planungsphase eine andere Geschwindigkeit und/oder Route in Betracht gezogen werden, und das autonome Fahrzeug kann den autonomen Fahrmodus ändern, um die Geschwindigkeit (oder Route) zu ändern. In Abhängigkeit von den Fahrereingaben können auch andere Abhilfemaßnahmen ergriffen werden.
• Einer der potenziellen Vorteile autonomer Fahrzeuge ist die Möglichkeit, das Fahren wesentlich sicherer zu machen. Trotz aller Bemühungen, ein fehlerfreies System für die Automatisierung zu schaffen, sind mechanische, physische und/oder elektronische Schäden, die durch den Verschleiß der Fahrzeuge verursacht werden, unvermeidlich. Solche Schäden können zu einer Fehlfunktion des autonomen Fahrzeugs führen.
• Wenn ein autonomes Fahrzeug, insbesondere seine Sensoren, beschädigt wird, kann die Funktion des Fahrzeugs unweigerlich beeinträchtigt werden. Der Automatisierungsgrad eines autonomen Fahrzeugs wird in Abhängigkeit von der erforderlichen Beteiligung des menschlichen Fahrers definiert, wie in 77 gezeigt. Wenn ein autonomes Fahrzeug auf Probleme stößt, kann es erforderlich sein, dass ein menschlicher Beifahrer (oder eine Fernüberwachungsinstanz) die Kontrolle über das Fahrzeug übernimmt oder dass das Fahrzeug den Betrieb einstellt.
• Wenn es Probleme mit einem Fahrzeug gibt, sei es ein Sensorproblem, eine Prozessor- oder Speicherstörung oder ein anderes Hardware-/Softwareproblem, steigt die Wahrscheinlichkeit eines Unfalls. Dies kann auch der Fall sein, wenn ein menschlicher Fahrer gezwungen ist, die Kontrolle über das Fahrzeug zu übernehmen, insbesondere wenn dieser Fahrer nicht darauf vorbereitet ist. Die Möglichkeit, zu verfolgen, was in einem Fahrzeug geschieht, könnte sich für viele Parteien als unschätzbar erweisen. So könnten beispielsweise Versicherungsgesellschaften, der Fahrer oder der Hersteller des Fahrzeugs in Bezug auf verschiedene Haftungsfragen profitieren. Außerdem könnten die Konstrukteure des Fahrzeugs davon profitieren, wenn sie wüssten, was in kritischen Situationen passiert.
• Ein umfassendes kognitives Überwachungssystem 7800 ist in FIG dargestellt. 78. Das System 7800 ist ein Rechensystem (wie ein Teilsystem oder eine Implementierung der hier erörterten Rechensysteme), das mit einer Logik ausgebildet ist, um den Grad der Autonomie eines Fahrzeugs auf der Grundlage der kontinuierlichen Analyse der Fahrbedingungen und der Genauigkeit des autonomen Fahrzeugs, insbesondere der Erfassungs-, Planungs- und Handlungsebenen des autonomen Fahrzeugs, zu überwachen und anzupassen. Das System 7800 kann einen mehrstufigen intelligenten Mechanismus zur Behandlung von Problemen umfassen, die bei einem autonomen Fahrzeug auftreten können, indem es einen menschlichen Fahrer überwacht, warnt und wieder einschaltet und eine sichere Übergabe der Fahrkontrolle an den menschlichen Fahrer durchführt. Das System 7800 kann auch so ausgebildet werden, dass es eine Fernüberwachung und/oder -steuerung des autonomen Fahrzeugs ermöglicht. Das System 7800 kann auch als System zur Verringerung des Autonomiegrades eines autonomen Fahrzeugs betrachtet werden, so dass man sich in Situationen, in denen Sensoren oder Komponenten des Fahrzeugs ausfallen oder andere Situationen, die das Fahrzeug nicht bewältigen kann, stärker auf einen menschlichen Fahrer verlässt.
• Das System 7800 kann den Grad der Autonomie in einem autonomen Fahrzeug überwachen. Außerdem kann das System feststellen, ob der Autonomiegrad korrekt ist, und, falls nicht, den Autonomiegrad des Fahrzeugs ändern. Wenn eine Änderung erforderlich ist, kann das System 7800 den Fahrer auf diese Änderung hinweisen. Das System kann auch ein Fernüberwachungssystem 7810 über die Änderung informieren.
• Das umfassende kognitive Überwachungssystem (C2S2) 7805 kann zusätzlich zu den regulären Automatisierungssystemen eines autonomen Fahrzeugs eingesetzt werden (z. B. zur Überwachung). In einem Beispiel sitzt das System 7805 auf den Sensor- (7820), Planungs-(7830) und Ausführungssystemen (7840) des Fahrzeugs. Es sei darauf hingewiesen, dass die C2S2 in einigen Fällen auf den fahrzeugeigenen Rechensystemen des autonomen Fahrzeugs aufsetzen oder mit diesen zusammenarbeiten kann. Insbesondere kann die C2S2 auf jedes System aufgesetzt werden, das den Autonomiegrad des Fahrzeugs beeinflussen könnte. Das System 7805 kann auch den Verlauf der autonomen Fahrstufe und die Überwachung des Sensorzustands aufzeichnen. Die gesammelten Daten können sehr übersichtlich und offline zugänglich sein, so dass im Falle einer Störung oder eines Unfalls auf sie zurückgegriffen werden kann.
• In einigen Beispielen umfasst C2S2 7805 eine ausführbare Logik zur Überwachung des Autonomiegrades des Fahrzeugs und umfasst drei Hauptmodule: Funktionssicherung, Qualitätssicherung und Sicherheitssicherung. Jedes dieser Hauptmodule kann über eine Reihe von vordefinierten Leistungsindikatoren (KPI) verfügen, um den aktuellen Autonomiezustand des Fahrzeugs zu akzeptieren oder abzulehnen. Stellt die C2S2 fest, dass der Autonomiegrad aufgrund eines der überwachten Module nicht akzeptabel ist, kann die C2S2 den Autonomiegrad des Fahrzeugs ändern. Außerdem informiert das System den menschlichen Fahrer über die Änderung. Die Möglichkeit, den Autonomiegrad zu ändern, kann sehr vorteilhaft sein. Anstatt die Autonomie des Fahrzeugs bei einem Sensorausfall vollständig abzuschalten, kann die C2S2 beispielsweise feststellen, dass der Autonomiegrad herabgesetzt werden kann, anstatt die Autonomie vollständig aufzuheben. Dies kann bedeuten, dass das Fahrzeug von einer L4- auf eine L3-Ebene wechselt (z. B. wie in FIG dargestellt). 79) umfassen. Bei einer solchen Änderung muss der menschliche Fahrer nicht unbedingt in die Steuerung des Fahrzeugs eingreifen, aber in einigen Ausführungsformen kann die Änderung der Autonomie dem Fahrer mitgeteilt werden, damit er im Bedarfsfall besser aufpassen kann.
• Um mit dem Beispiel von 78 fortzufahren, C2S2 7805 wird die KPI jedes der drei Hauptblöcke (Funktions-, Qualitäts- und Sicherheitsgarantie) der drei Systeme (Sensor 7820, Planung 7830 und Ausführung 7840) bewerten. Wenn der C2S2 7805 ein Problem mit den Systemen feststellt, kann er beurteilen, ob der Autonomiegrad geändert werden muss. Nicht jedes Problem erfordert eine Änderung des Autonomiegrades. Zum Beispiel kann das Fahrzeug ein Problem mit einem der Sensoren haben. Wenn dieser Sensor jedoch Daten liefert, die sich mit denen eines anderen Sensors wiederholen, darf das Fahrzeug seine Fähigkeit zur Aufrechterhaltung seines derzeitigen Autonomiegrades nicht verlieren.
• In anderen Fällen kann jedoch auch ein Problem mit einem Sensor ein Problem verursachen. Auch wenn ein Hersteller ein bestimmtes Fahrzeug mit dem Autonomiegrad L4 auf den Markt gebracht hat, ist eine solche Bezeichnung in der Praxis an Bedingungen geknüpft, und die Autonomiefähigkeit des Fahrzeugs kann sich im Laufe der Zeit ändern. Wenn z. B. ein Sensor ausfällt oder die Sicherheit der Fahrgäste in Szenarien wie Sensor-/Komponentenausfall gefährdet ist, muss der Autonomiegrad möglicherweise geändert werden. C2S2 7805 kann den Autonomiegrad ändern und sowohl den Fahrer als auch das Fernüberwachungssystem (7810) informieren.
• Neben der Überwachung und Änderung des Autonomiegrades kann C2S2 7805 auch Aktionen an das Fernüberwachungssystem 7810 zurückmelden. C2S2 7805 kann nicht nur eine Änderung des Autonomiegrades melden, sondern auch alle wichtigen Daten an das entfernte System 7810 übermitteln. In Situationen, in denen eine Änderung des Autonomiegrades erforderlich ist, oder sogar in Situationen, in denen es zu einem Unfall kommt, an dem ein autonomes Fahrzeug beteiligt ist, können beispielsweise eine vollständige Aufzeichnung der Änderung des Autonomiegrades und Daten über die Bewegungen des Fahrzeugs, die Planung, den Autonomiegrad usw. an das Überwachungssystem 7810 gesendet und von diesem gespeichert werden. Solche Daten können nützlich sein, um die Schuld an Unfällen zu ermitteln, Daten für Verbesserungen usw. Es ist vorgesehen, dass alle Daten, die erfasst werden können, an das Fernüberwachungssystem 7810 gesendet werden können, wenn dies gewünscht wird.
• Das in FIG. beschriebene System 78 ist lediglich repräsentativ für Module, die in bestimmten Ausführungsformen vorkommen können. Andere Ausführungsformen können zusätzliche, hier nicht ausdrücklich erwähnte Module umfassen. Darüber hinaus ist möglicherweise nicht jedes Modul erforderlich, oder die Module können in anderen Ausführungsformen kombiniert werden.
• Obwohl es ideal wäre, wenn autonome Fahrzeuge völlig ohne menschlichen Eingriff fahren könnten, kann es je nach Autonomiegrad eines autonomen Fahrzeugs notwendig sein, dass der Fahrer während des Betriebs des Fahrzeugs in gewissem Umfang eingreifen muss. Dies gilt insbesondere für Notfälle, in denen ein menschlicher Fahrer das Steuer übernehmen muss. In solchen Situationen kann eine typische Übergabe an einen menschlichen Fahrer, sofern sie erfolgreich ist, durchschnittlich etwa drei Sekunden dauern. Menschen sind jedoch oft unaufmerksam, lassen sich leicht ablenken und reagieren oft nur langsam auf bestimmte Situationen. Daher kann es eine Herausforderung sein, den Fahrer während des autonomen Betriebs des Fahrzeugs bei der Stange zu halten, um eine schnelle und sichere Übergabe zu erreichen.
• Dementsprechend kann zumindest in einigen Situationen eine Person als Backup bei einer Übergabe in einem autonomen Fahrzeug unzuverlässig sein. Wenn eine Person nicht schnell genug reagieren kann, kann eine potenziell gefährliche Situation durch einen unaufmerksamen Fahrer, der nicht rechtzeitig reagieren kann, noch verschlimmert werden. Verschiedene Implementierungen der oben genannten Systeme können einen sichereren Weg für die Übergabe zwischen einem autonomen Fahrer und einem menschlichen Fahrer bieten.
• 80 veranschaulicht ein Beispiel für einen architektonischen Datenfluss eines autonomen Fahrzeugs, das auf einem Autonomiegrad L4 betrieben wird. Der Beispielablauf von 80 umfasst ein Sense-Modul 8010, ein Plan-Modul 8020, ein Act-Modul 8030 und ein Driver-by-Wire (DBW)-Modul 8040. Das Sensormodul 8010 kann beispielsweise für die Verarbeitung der Daten von verschiedenen Wahrnehmungssensoren (z. B. Kameras, Radar, LIDAR, GPS usw.) zuständig sein. Das Sensormodul 8010 kann alle geeigneten Eigenschaften der Sensoren 225 aufweisen. Die vom Erfassungsmodul ausgegebenen Daten, die die Bewegungsparameter des Fahrzeugs (z. B. Geschwindigkeit, Position, Ausrichtung usw.) darstellen können, können zusammen mit Daten, die Objekte in der Umgebung des Fahrzeugs repräsentieren, an das Planungsmodul 8020 weitergeleitet werden (das alle geeigneten Merkmale von Bahnplanungsmodulen (z. B. 242) aufweisen kann, wie an anderer Stelle hierin beschrieben). Das Planmodul 8020 kann während der Fahrt auf der Grundlage der aktuellen Situation relevante Entscheidungen für die zu ergreifenden Maßnahmen auf der Straße treffen. Die vom Planmodul getroffene Entscheidung kann an das Aktionsmodul 8030 übermittelt werden, das aus einem Steuergerät bestehen kann, um spezifische Fahrzeugbefehle zu generieren, die an das DBW-Modul 8040 weitergegeben werden. Solche Befehle können z. B. einen bestimmten Lenkwinkel und/oder Befehle zur Beschleunigung umfassen. Diese Befehle werden dann von dem DBW-Modul ausgeführt. Es sei darauf hingewiesen, dass der oben beschriebene Ablauf nur beispielhaft ist und dass es auch andere Abläufe geben kann. Darüber hinaus ist es möglich, dass es für verschiedene Fahrzeuge unterschiedliche Intelligenzniveaus gibt. Ein Fahrzeug der Klasse L2 hat beispielsweise eine andere Intelligenz als ein Fahrzeug der Klasse L4.
• In einer Situation, in der es einen Fehler auf einer der Modulebenen des Beispiels von 80 gibt, oder wenn der Planungsalgorithmus eines Fahrzeugs in bestimmten Fahrszenarien nicht in der Lage ist, Maßnahmen zu ergreifen, sendet das Fahrzeug derzeit automatisch ein Signal an den Fahrer, das anzeigt, dass der Fahrer übernehmen muss. Dieses Signal kann visuell, akustisch oder eine Kombination davon sein. 81 veranschaulicht ein Beispiel für ein Videosignal an den Treiber.
• 82 veranschaulicht den Ablauf einer beispielhaften Übergabesituation eines autonomen Fahrzeugs. Wie zu sehen ist, kann sich das Fahrzeug zu Beginn des Ablaufs im autonomen Modus 8210 befinden. Sobald ein Problem festgestellt wird und der Autonomiegrad geändert werden muss, wird ein Übernahmesignal gesendet 8220. Schließlich wird der autonome Modus um 8230 deaktiviert.
• Eine nicht abrupte und plötzliche Übergabe hilft dem Fahrer, das Fahrzeug bei Bedarf zu übernehmen. Darüber hinaus muss das Fahrzeug bei einem Ausfall der Sensoren nicht unbedingt völlig nicht-autonom werden. Es kann sicher sein, nur den Autonomiegrad zu verringern. Bei einem autonomen Fahrzeug, das im L4-Modus betrieben wird, ist es beispielsweise nicht unbedingt erforderlich, dass das Fahrzeug direkt an einen menschlichen Fahrer übergeben wird und seine Autonomie abschaltet. Ein Planungsalgorithmus (z. B. vom Planungsmodul 8020) ist von mehreren Sensoreingaben abhängig. Die Zuverlässigkeit des autonomen Systems wird durch die Präzision definiert, mit der ein Planungsalgorithmus auf der Grundlage dieser Sensoreingaben Entscheidungen treffen kann. Jedes System hat eine Reihe von kritischen und unkritischen Sensoreingängen, die den Vertrauensgrad der vom Planungsmodul getroffenen Entscheidungen bestimmen. Ein Fahrzeug der Stufe L4 kann nicht mehr mit demselben Vertrauensgrad betrieben werden, wenn eine Teilmenge seiner Sensoren (in erster Linie redundante Sensoren) nicht mehr funktioniert. In einer Beispielsituation könnte das Fahrzeug einfach von der Vertrauensstufe L4 auf L3 herabgestuft worden sein, was eine höhere Aufmerksamkeit des Fahrers erfordert. Es ist jedoch nicht unbedingt notwendig, dass der Fahrer vollständig die Kontrolle übernimmt und das Fahrzeug die autonomen Systeme abschaltet.
• 83 zeigt ein Beispiel für einen Ablauf zur Übergabe der Kontrolle eines autonomen Fahrzeugs an einen menschlichen Fahrer. Darüber hinaus veranschaulicht 83 die Koordination zwischen menschlichen Reaktionen und den Aktionen des autonomen Fahrzeugs. Diese Koordinierung ist durch gestrichelte Linien dargestellt. Der Beispielablauf von 83 kann im Planmodul 8020 eines autonomen Fahrzeugs stattfinden. Es ist jedoch zu beachten, dass der Fluss von 83 von jedem Modul oder jeder Kombination eines Rechensystems ausgeführt werde kann, auch von solchen, die hier nicht erwähnt sind.
• Das Beispiel von 83 zeigt zunächst (8310), dass das autonome Fahrzeug in seinem autonomen Modus normal arbeitet, in diesem Beispiel auf der Stufe L4. Infolgedessen ist der menschliche Fahrer nicht aktiv (8315). Dies kann insbesondere bei einem hohen Autonomiegrad eines autonomen Fahrzeugs der Fall sein.
• Wenn ein Problem auftritt, kann das Fahrzeug eine Systemfehlermeldung (8320) ausgeben. Dementsprechend erhält der menschliche Fahrer die Meldung (8325). Dieser Alarm kann visuell, akustisch, taktisch oder in anderer Form erfolgen.
• Wenn festgestellt wird, dass die Störung nicht so schwerwiegend ist, dass ein sofortiger Eingriff des Fahrers erforderlich ist, kann das Fahrzeug in einen niedrigeren autonomen Modus (8330) wechseln. In diesem Beispiel wechselte das Fahrzeug von L4 nach L3. Der menschliche Fahrer ist sich dieses Übergangs bewusst (z. B. aufgrund der bei 8325 empfangenen Warnung) und kann auf die Fahrbedingungen achten und bei Bedarf innerhalb einer bestimmten Zeitspanne die Kontrolle über das Fahrzeug übernehmen (8335). In einigen Beispielen kann das Fahrzeug das Einschalten des Fahrers durch den Einsatz bestimmter Sensoren und Überwachungseinrichtungen bestätigen. Das Fahrzeug kann zum Beispiel Blickkontrolle, haptisches Feedback, Audio-Feedback usw. verwenden.
• Tritt ein weiterer Fehler auf, kann das Fahrzeug erneut eine Systemstörungsmeldung (8340) ausgeben. Auch hier erhält der Fahrer die Meldung nach dem Senden (8345).
• Wenn dann erneut festgestellt wird, dass der Autonomiegrad wieder gesenkt werden kann (in diesem Beispiel von L3 auf L2), senkt das Fahrzeug seinen Autonomiegrad erneut (8350). Dementsprechend beginnt der Fahrer nun, noch besser aufzupassen (8355). In diesem Beispiel wird der menschliche Fahrer ständig aufmerksam sein, da sich das Fahrzeug im L2-Modus befindet.
• Wenn das Kraftfahrzeug erneut seinen Autonomiegrad absenken muss, dieses Mal auf L1, muss der Fahrer das Kommando übernehmen. Daher kann das Fahrzeug ein Übernahmesignal (8360) aussenden. In einem entsprechenden Zug kann der Triebfahrzeugführer das Übernahmesignal (8370) empfangen.
• Jetzt kann das Fahrzeug bestätigen, ob der Fahrer in der Lage ist, die Kontrolle über das Fahrzeug zu übernehmen. Daher wartet das Fahrzeug darauf, dass der Fahrer die Kontrolle übernimmt (8362). Wie bereits erwähnt, kann das Fahrzeug mithilfe von Überwachung und Sensoren den Bereitschaftszustand des Fahrers ermitteln und darüber hinaus überwachen, ob der Fahrer tatsächlich die Kontrolle übernimmt.
• Wenn das Fahrzeug nach einer gewissen Zeit feststellt, dass der Fahrer die Kontrolle nicht übernommen hat (oder nicht in der Lage ist, die Kontrolle sicher zu übernehmen), wird ein Notfallsystem aktiviert (8364). Dabei können je nach Situation verschiedene Maßnahmen durchgeführt werden. So kann es zum Beispiel erforderlich sein, dass das Fahrzeug anhält. In manchen Situationen kann es nicht sicher sein, anzuhalten, so dass das Fahrzeug eine Zeit lang weiterfahren kann. Daher kann das Fahrzeug langsamer werden und/oder an den Straßenrand fahren, bis es sicher zum Anhalten ist. Sobald das Notfallsystem aktiviert ist, wird der Zustand der Notfallaktion entsprechend abgeschlossen (8374).
• Wenn der Fahrer jedoch in der Lage ist, das Fahrzeug zu übernehmen und die Übergabe erfolgreich ist, kann der autonome Modus deaktiviert werden (8366). Bei einer entsprechenden Aktion wird der Fahrer voll eingekuppelt und fährt das Fahrzeug (8376). Wie man sieht, ermöglichen es die frühzeitigen Warnungen (mehrere Male, bevor eine Übergabe erforderlich ist) dem Fahrer, sich auf eine Übergabe vorzubereiten, bevor das System ausfällt und der Fahrer unbedingt übernehmen muss.
• Ein autonomes Fahrzeug kann mit mehreren Sensoren ausgestattet sein, die selbst über einen relativ kurzen Zeitraum (z. B. Millisekunden) eine große Menge an Daten erzeugen. Unter der Annahme einer Echtzeit-Datenverarbeitung, die für solche Systeme unerlässlich ist, sollten die zum Zeitpunkt T erfassten Daten verarbeitet werden, bevor die nächsten zum Zeitpunkt T+1 generierten Daten aufgezeichnet werden (wobei die Einheit 1 hier die maximale Auflösung des jeweiligen Sensors ist). Für eine Kamera (die im Allgemeinen mit 30 Bildern pro Sekunde arbeitet) und ein LIDAR (das im Allgemeinen mit 20 Sweeps pro Sekunde arbeitet) kann eine Auflösung von 33 ms bzw. 50 ms als akzeptabel angesehen werden. Daher sind rasche Entscheidungen wünschenswert. Ein Ereignis oder eine Situation besteht aus einer Reihe von Aufzeichnungen über einen bestimmten Zeitraum hinweg, so dass verschiedene Entscheidungen auf der Grundlage eines Zeitreihenproblems getroffen werden können, das sowohl auf dem aktuellen Datenpunkt als auch auf früheren Datenpunkten basiert. In der Praxis wird ein vordefiniertes Verarbeitungsfenster in Betracht gezogen, da es unter Umständen nicht möglich ist, alle aufgezeichneten Daten zu verarbeiten, und die Wirkung der aufgezeichneten Daten im Laufe der Zeit nachlässt.
• Der Prozess der Erkennung von Mustern, die nicht mit dem erwarteten Verhalten von Sensordaten übereinstimmen, wird als Anomalieerkennung bezeichnet. Die Ermittlung des Grundes für eine Anomalie wird als Anomalieerkennung bezeichnet. Die Erkennung von Anomalien ist aus verschiedenen Gründen eine schwierige Aufgabe für Algorithmen des maschinellen Lernens. Die Algorithmen des maschinellen Lernens stützen sich zunächst auf die gesichteten Daten (Trainingsphase), um die Parameter des Vorhersagemodells für die Erkennung eines Objekts zu schätzen. Dies steht jedoch im Widerspruch zu den Merkmalen von Anomalien, bei denen es sich um seltene Ereignisse ohne vordefinierte Merkmale handelt (und die daher wahrscheinlich nicht in den herkömmlichen Trainingsdaten umfassen sind). Zweitens ist das Konzept einer Anomalie nicht notwendigerweise konstant und kann daher bei herkömmlichen Klassifizierungsproblemen nicht als eine einzige Klasse betrachtet werden. Drittens ist die Anzahl der Klassen in herkömmlichen Algorithmen für maschinelles Lernen vordefiniert, und wenn Eingabedaten eingehen, die nicht relevant sind, findet der ML-Algorithmus möglicherweise die wahrscheinlichste Klasse und kennzeichnet die Daten entsprechend, so dass die Anomalie möglicherweise unentdeckt bleibt.
• In verschiedenen Ausführungsformen der vorliegenden Offenbarung wird eine Architektur für maschinelles Lernen zur Erkennung von Anomalien bereitgestellt. In einer bestimmten Ausführungsform wird eine neue Klasse (z. B. „Nicht bekannt“) zu einem rekurrenten neuronalen Netz hinzugefügt, um das Modell so zu verbessern, dass es sowohl eine zeitbasierte Anomalieerkennung ermöglicht als auch die Anomalieerkennungsrate durch Entfernen falsch positiver Fälle erhöht. Verschiedene Ausführungsformen können für unterschiedliche Anwendungen geeignet sein, unter anderem für die Objekterkennung in einem autonomen Fahrzeug. Dementsprechend kann in einer Ausführungsform zumindest ein Teil der Architektur von der Wahrnehmungsmaschine 238 implementiert werden.
• In bestimmten Ausführungsformen kann die Architektur ein oder mehrere ML-Modelle umfassen, einschließlich eines neuronalen Netzwerkes, das auf einer Gated Recurrent Unit (GRU) oder einem Long Short Term Memory-Netzwerk (LSTM) basiert. 84 zeigt Beispiele für GRU- und LSTM-Architekturen. Solche Netze werden häufig für die Verarbeitung natürlicher Sprache (NLP) verwendet. GRU wurde 2014 eingeführt, hat eine einfachere Architektur als LSTM und wurde in den letzten Jahren in einer zunehmenden Zahl von Anwendungen eingesetzt. In der GRU-Architektur werden Vergessens- und Eingangsgatter zu „Aktualisierungsgattern“ zusammengeführt. Außerdem werden der Zellstatus und der verborgene Status kombiniert.
• 85 zeigt ein System 8500 zur Erkennung von Anomalien in Übereinstimmung mit bestimmten Ausführungsformen. Die Hinzufügung eines Anomalie-Detektors kann die Intelligenz eines Systems erhöhen, so dass unbekannte Situationen (z. B. zeitbasierte Ereignisse) gemeldet werden können, die zuvor nicht erkannt worden wären. Ein neues ML-Modell, das auf einer LSTM- oder GRU-Architektur basiert (hier als Smart Recurrent Unit (SRU)-Modell 8502 bezeichnet), kann bereitgestellt und in Verbindung mit einem Standard-LSTM- oder GRU-Modell („Basismodell“ 8504) verwendet werden. In verschiedenen Ausführungsformen kann die Architektur des SRU-Modells 8502 der Architektur des Basisprädiktors ähnlich sein, aber speziell auf die Erkennung von Anomalien abgestimmt werden. In verschiedenen Ausführungsformen ist das System 8500 in der Lage, sowohl eine neu eintreffende Sequenz von Anomaliedaten zu codieren (z. B. die Sequenz als eine unbekannte Klasse zu codieren) als auch eine gegebene Datendarstellung zu einem Anomalie-Tag zu decodieren (z. B. im Laufe der Zeit neue Anomalieklassen zu identifizieren und entsprechend zu kennzeichnen). Jede geeignete Datenfolge kann vom System 8500 als Anomalie erkannt werden. Eine Anomalie kann zum Beispiel ein unbekanntes erkanntes Objekt oder eine unbekannte erkannte Ereignisfolge sein. In verschiedenen Ausführungsformen kann die Hinzufügung des SRU-Modells die Intelligenz des Systems erhöhen, um unbekannte Situationen (zeitbasierte Ereignisse) zu melden, die das System zuvor nicht gesehen hat (entweder in der Trainings- oder in der Testphase). Das System kann eine neue Sequenz von Anomaliedaten codieren und ihnen eine Bezeichnung zuweisen, um eine neue Klasse zu bilden. Wenn das Etikett erstellt wird, kann jede beliebige Datendarstellung dieser Art von Anomalie entschlüsselt werden.
• Das System 8500 demonstriert einen Ansatz zur Extraktion anomaler Ereignisse in der Trainings- und Inferenzphase. Die Anomalie-Schwelle 8506 wird während der Trainingsphase berechnet, in der das Netz die Grenze zwischen gelernten, nicht gelernten und anomalen Ereignissen ermittelt. In einer bestimmten Ausführungsform basiert der Anomalie-Schwellenwert 8506 auf einer Sigmoid-Funktion, die von einem oder beiden Modellen, dem Grundlinienmodell 8504 und dem SRU-Modell 8502, verwendet wird. Der Anomalie-Schwellenwert 8506 kann verwendet werden, um die Parameter des SRU-Modells 8502 während des Trainings anzupassen.
• Durch die Anreicherung des Trainingsdatensatzes 8508 mit den erwarteten Normalfällen kann das gesamte Netz zu einem Zustand konvergieren, in dem nur unbekannte Situationen als Anomalien betrachtet werden (so dass anomale Abtastwerte nicht in den Trainingsdatensatz aufgenommen werden müssen). Dies ist der Zeitpunkt, an dem der Anomaliedetektor 8510 erkennt, dass die Situation mit den gelernten Daten nicht korrekt behandelt werden kann. Der Trainingsdatensatz 8508 kann alle geeigneten Informationen umfassen oder darauf basieren, wie z. B. Bilder von Kameras, Punktwolken von LIDARs, aus Bildern oder Punktwolken extrahierte Merkmale oder andere geeignete Eingabedaten.
• Während des Trainings wird der Trainingsdatensatz 8508 sowohl dem Basismodell 8504 als auch dem SRU-Modell 8502 zur Verfügung gestellt. Jedes Modell kann z. B. eine vorhergesagte Klasse sowie eine Vorhersagewahrscheinlichkeit (z. B. die geschätzte Wahrscheinlichkeit, dass die Klassifizierung richtig ist) ausgeben. In einigen Ausführungsformen können die Ausgaben mehrere Klassen mit jeweils einer zugehörigen Vorhersagewahrscheinlichkeit umfassen. In einigen Ausführungsformen, z. B. auf der Grundlage von GRU-Modellen, können die Ausgaben eine Zeitreihe sein, die anzeigt, wie sich die Ausgabe auf der Grundlage der Eingabe verändert. Das SRU-Modell 8502 kann empfindlicher auf unbekannte Klassen reagieren als das Basismodell (z. B. 8504). Der Fehlerrechner 8512 kann einen Fehler auf der Grundlage der Differenz zwischen der Ausgabe des Basismodells 8504 und der Ausgabe des SRU-Modells 8502 bestimmen.
• Während der Inferenz werden Testdaten 8514 (die in einigen Ausführungsformen Informationen umfassen können, die von einem oder mehreren Sensoren eines autonomen Fahrzeugs gesammelt oder abgeleitet wurden) dem Basislinienmodell 8504 und dem SRU-Modell 8502 zur Verfügung gestellt. Wenn der Fehler, der die Differenz zwischen den Ausgaben der Modelle darstellt, relativ hoch ist, wie vom Fehlerrechner 8512 berechnet, dann bestimmt das System 8500 eine Klasse für das Objekt, die nicht in den Trainingsdaten umfassen war, und eine Anomalie wird erkannt. Zum Beispiel kann das System während der Inferenz den Anomalie-Detektor 8510 verwenden, um festzustellen, ob der Fehler für die Testdaten größer ist als der Anomalie-Schwellenwert 8506. In einem Beispiel kann dem Objekt eine Anomalieklasse zugewiesen werden, wenn der Fehler größer ist als der Anomalieschwellenwert 8506.
• In verschiedenen Ausführungsformen kann der Anomaliedetektor 8510 dem Objekt ein Catch-All-Label mit unbekannten Klassen zuweisen. In einer anderen Ausführungsform kann der Anomaliedetektor 8510 dem Objekt eine bestimmte Anomalieklasse zuordnen. In verschiedenen Ausführungsformen kann der Anomaliedetektor verschiedenen Objekten verschiedene Anomalieklassen zuordnen. Beispielsweise kann eine erste Auffälligkeitsklasse jedem aus einer ersten Mehrzahl von Objekten mit ähnlichen Merkmalen zugeordnet werden, eine zweite Auffälligkeitsklasse jedem aus einer zweiten Mehrzahl von Objekten mit ähnlichen Merkmalen und so weiter. In einigen Ausführungsformen kann eine Gruppe von Objekten als Catch-All (z. B. Standardklasse) klassifiziert werden, aber sobald das System 8500 erkennt, dass ähnliche Objekte ähnliche Merkmale aufweisen, kann eine neue Auffälligkeitsklasse für diese Objekte erstellt werden.
• Die beschriftete Ausgabe 8514 gibt die vorhergesagte Klasse an (die eine der Klassen des Trainingsdatensatzes oder eine Anomalieklasse sein kann). In verschiedenen Ausführungsformen kann die markierte Ausgabe auch eine Vorhersagekonfidenz für die vorhergesagte Klasse umfassen (die in einigen Fällen eine Vorhersagekonfidenz für eine Anomalieklasse sein kann).
• 86 zeigt einen Ablauf zur Erkennung von Anomalien in Übereinstimmung mit bestimmten Ausführungsformen. Bei 8602 wird ein aus den Bilddaten extrahiertes Merkmal an ein Vorhersagemodell erster Klasse und an ein Vorhersagemodell zweiter Klasse übermittelt. Bei 8604 wird eine Differenz zwischen einer Ausgabe des Vorhersagemodells der ersten Klasse und einer Ausgabe des Vorhersagemodells der zweiten Klasse bestimmt. Bei 8606 wird dem extrahierten Merkmal eine Anomalieklasse zugewiesen, die auf dem Unterschied zwischen der Ausgabe des Vorhersagemodells der ersten Klasse und der Ausgabe des Vorhersagemodells der zweiten Klasse basiert.
• Autonome Fahrzeuge unterscheiden sich stark in ihren Eigenschaften. Der Grad der Autonomie von Fahrzeugen kann beispielsweise von L1 bis L5 reichen. Ein weiteres Beispiel: Fahrzeuge können mit einer Vielzahl von Sensoren ausgestattet sein. Beispiele für solche Sensoren sind LIDAR, Kameras, GPS, Ultraschall, Radar, hyperspektrale Sensoren, Trägheitsmessgeräte und andere hier beschriebene Sensoren. Darüber hinaus können die Fahrzeuge in Bezug auf die Anzahl der einzelnen Sensortypen, mit denen sie ausgestattet sind, variieren. Ein bestimmtes Fahrzeug kann zum Beispiel zwei Kameras haben, während ein anderes Fahrzeug zwölf Kameras hat.
• Darüber hinaus haben die Fahrzeuge eine unterschiedliche physische Dynamik und sind mit unterschiedlichen Kontrollsystemen ausgestattet. Ein Hersteller hat möglicherweise ein anderes bordeigenes Verarbeitungssystem mit einem anderen Kontrollschema als ein anderer Hersteller. Ebenso können verschiedene Modelle desselben Herstellers oder sogar verschiedene Ausstattungsstufen desselben Fahrzeugmodells unterschiedliche bordeigene Verarbeitungs- und Steuersysteme haben. Darüber hinaus können verschiedene Fahrzeugtypen unterschiedliche Computer-Vision- oder andere Rechenalgorithmen verwenden, so dass die Fahrzeuge in ähnlichen Situationen unterschiedlich reagieren können.
• Angesichts der möglichen Unterschiede zwischen den autonomen Fahrzeugen (z. B. Autonomiegrad, Sensoren, Algorithmen, Verarbeitungssysteme usw.) wird es Unterschiede zwischen den relativen Sicherheitsniveaus der verschiedenen Fahrzeuge geben. Diese Unterschiede können auch von dem Straßenabschnitt abhängen, auf dem das jeweilige Fahrzeug unterwegs ist. Darüber hinaus können verschiedene Fahrzeuge bestimmte Situationen besser bewältigen als andere, wie z. B. schlechtes Wetter.
• Da derzeitige autonome Fahrzeuge nicht in der Lage sind, jede Situation zu bewältigen, insbesondere nicht unter allen möglichen Bedingungen, kann es nützlich sein, festzustellen, ob ein autonomes Fahrzeug in der Lage ist, einen Teil einer Straße unter den aktuellen Bedingungen zu bewältigen.
• 87 veranschaulicht ein Beispiel für ein Verfahren 8700 zur Einschränkung des Autonomiegrades eines Fahrzeugs auf einem Straßenabschnitt gemäß einer Ausführungsform. Die Methode 8700 kann als Methode des dynamischen Geo-Fencing unter Verwendung einer Sicherheitsbewertung für autonomes Fahren betrachtet werden.
• Das Verfahren 8700 umfasst die Bestimmung einer Verkehrssicherheitsbewertung für einen Straßenabschnitt bei 8710. Dies kann die Bestimmung eines Grenzwerts für die Sicherheit des autonomen Fahrens für einen Straßenabschnitt umfassen. Dieser Verkehrssicherheitswert kann ein einziger Wert sein, der durch Gewichtung und Bewertung von Fahrparametern berechnet wird, die für die Sicherheit von autonomen Fahrzeugen entscheidend sind. Diese Bewertung kann das aktuelle Sicherheitsniveau für einen Straßenabschnitt darstellen. Dieser Wert kann ein standardisierter Wert sein, was bedeutet, dass dieser Wert für jedes einzelne autonome Fahrzeug auf der Straße gleich ist. In einigen Ausführungsformen kann diese Sicherheitsbewertung dynamisch sein und sich je nach den aktuellen Bedingungen eines bestimmten Straßenabschnitts ständig ändern. Beispiele für Kriterien, die in die Berechnung der Bewertung einfließen können, sind u. a.: die Wetterbedingungen, die Tageszeit, der Zustand der Fahrbahn, die Anzahl der anderen Fahrzeuge auf der Straße, der Anteil autonomer Fahrzeuge auf der Straße, die Anzahl der Fußgänger in der Umgebung und ob es eine Baustelle gibt. Jede dieser Bedingungen oder andere Bedingungen, die die Sicherheit eines autonom fahrenden Fahrzeugs auf diesem Straßenabschnitt beeinträchtigen können, können bei der Ermittlung der Straßenbewertung berücksichtigt werden. In einigen Beispielen können die Bewertungskriterien von einer Gruppe von Experten und/oder Regulierungsbehörden festgelegt werden. Die Kriterien können gewichtet werden, so dass bestimmte Bedingungen die Sicherheitsbewertung stärker beeinflussen als andere. In einem Beispiel kann die Sicherheitsbewertung zwischen 0 und 100 liegen, obwohl jede beliebige Anzahl von Zahlen verwendet werden kann oder die Sicherheitsbewertung auf jede andere geeignete Weise ausgedrückt werden kann.
• 88 veranschaulicht ein Beispiel für eine Karte 8800, in der jeder Bereich der aufgelisteten Straßen 8810 eine Verkehrssicherheitsbewertung 8820 für diesen Abschnitt der Straße zeigt. Diese Karte kann von einem Fahrzeug in ähnlicher Weise angezeigt werden wie die aktuellen GPS-Karten, auf denen Verkehr und Geschwindigkeitsbegrenzungen verzeichnet sind. In einigen Beispielen kann das Kartierungssystem (z. B. das Pfadplanungsmodul 242) die Sicherheitsbewertung auf der Grundlage von Eingaben von Sensoren oder anderen Daten in der geografischen Region der Straße berechnen. In anderen Beispielen kann die Bewertung außerhalb des Fahrzeugs berechnet werden (z. B. von 140 oder 150), und die Bewertung wird an das Fahrzeug übermittelt.
• Das Verfahren 8700 umfasst ferner die Bestimmung einer Sicherheitsbewertung für ein Fahrzeug in 8720. Dieser Sicherheitswert kann als Sicherheitswert für autonome Fahrzeuge betrachtet werden. Die Sicherheitsbewertung kann dazu verwendet werden, die relative Sicherheit eines autonomen Fahrzeugs darzustellen und die Grenzwerte der Straßen zu bestimmen, die ein Kraftfahrzeug autonom befahren kann. Ähnlich wie bei der Straßenverkehrssicherheitsbewertung kann es sich bei der Fahrzeugsicherheitsbewertung um eine einzige Bewertung handeln, die durch Gewichtung wichtiger Sicherheitselemente des Fahrzeugs berechnet wird. Beispiele für Kriterien, die bei der Bewertung der Fahrzeugsicherheit zu berücksichtigen sind, können sein: die Art der Sensoren im Fahrzeug (z. B. LIDAR, Kameras, GPS, Ultraschall, Radar, hyperspektrale Sensoren und Trägheitsmessgeräte), die Anzahl der einzelnen Sensoren, die Qualität der Sensoren, die Qualität der vom Fahrzeug implementierten Fahralgorithmen, die Menge der verfügbaren Straßenkartendaten usw. Sachverständige/Regulierungsbehörden können Tests für jeden Fahrzeugtyp durchführen, um den Sicherheitswert jedes Fahrzeugs (oder einen Teil davon) zu ermitteln. In einem Beispiel kann ein Fahrzeug mit fortschrittlichen Algorithmen und einer Mehrzahl von Sensoren eine höhere Bewertung erreichen, z. B. 80 von 100. Ein anderes Fahrzeug mit weniger fortschrittlichen Algorithmen und einer geringeren Anzahl und Art von Sensoren wird eine niedrigere Bewertung erreichen, beispielsweise 40 von 100.
• Als Nächstes umfasst das Verfahren 8700 den Vergleich des Fahrzeugsicherheitswertes mit dem Straßensicherheitswert bei 8730. der Vergleich kann die Feststellung umfassen, ob ein autonomes Fahrzeug sicher genug ist, um auf einem bestimmten Straßenabschnitt autonom gefahren zu werden. Wenn zum Beispiel die Straße eine Sicherheitsbewertung von 95 hat und das Kraftfahrzeug eine Bewertung von 50, wird das Kraftfahrzeug als nicht sicher genug angesehen, um auf diesem Streckenabschnitt autonom zu fahren. Sobald der Sicherheitswert der Straße jedoch auf 50 oder darunter sinkt, kann das Kraftfahrzeug wieder autonom fahren. Wenn das Fahrzeug nicht sicher genug ist, um autonom zu fahren, sollte der Fahrer das Fahren übernehmen, so dass das Fahrzeug den Fahrer vor einer Übergabe warnen kann. In einigen Beispielen kann ein mehrstufiger Ansatz verfolgt werden, um festzustellen, ob ein Fahrzeug sicher genug für das autonome Fahren ist. So kann die Straße beispielsweise mehrere Werte haben: einen L5-Wert, einen L4-Wert, einen L3-Wert usw. In solchen Beispielen kann die Fahrzeugsicherheitsbewertung verwendet werden, um zu bestimmen, welchen Grad an Autonomie ein einzelnes Fahrzeug für einen bestimmten Abschnitt der Straße nutzen darf. Wenn das Fahrzeug eine Bewertung von 50 hat und diese Bewertung in einem Bereich liegt, der für den L4-Betrieb geeignet ist, kann das Fahrzeug mit einem L4-Autonomiegrad gefahren werden.
• Das Verfahren 8700 schließt damit ab, dass autonome Fahrzeuge an unsicheren Straßenabschnitten gehindert werden (8740). Dazu kann auch gehören, dass ein Fahrzeug darauf hingewiesen wird, dass es auf einem bestimmten Streckenabschnitt nicht autonom fahren kann. Zusätzlich oder alternativ kann der Fahrer gewarnt werden, dass er die Fahrdienste übernehmen muss, und die Fahrdienste können an den Fahrer übergeben werden, sobald der Fahrer eingeschaltet ist. Wenn die Straße, wie oben erwähnt, ein abgestuftes Bewertungsniveau hat, kann der richtige Autonomiegrad des Fahrzeugs bestimmt werden und eine Warnung ausgegeben werden, dass der Autonomiegrad herabgesetzt wird und der Fahrer eingreifen oder sich darauf vorbereiten muss, je nachdem, welcher Autonomiegrad für dieses Fahrzeug auf einem bestimmten Straßenabschnitt zulässig ist.
• Bild- und Videodaten können von einer Vielzahl von Akteuren in einer Fahrumgebung gesammelt werden, z. B. von mobilen Fahrzeugen (z. B. Autos, Bussen, Zügen, Drohnen, U-Bahnen usw.) und anderen Transportfahrzeugen, straßenseitigen Sensoren, Fußgängern und anderen Quellen. Solche Bild- und Videodaten umfassen wahrscheinlich manchmal Bilder von Personen. Solche Bilder können z. B. durch eine nach außen oder innen gerichtete Bilderfassungsvorrichtung, die an einem Fahrzeug angebracht ist, oder durch Datenübertragung von Bildern von anderen elektronischen Geräten oder Netzen an ein in das Fahrzeug integriertes Rechensystem gewonnen werden. Diese Daten könnten verwendet werden, um Personen und ihre Standorte zu bestimmten Zeitpunkten zu identifizieren, was sowohl Sicherheits- als auch Datenschutzbedenken aufwirft. Dies ist besonders problematisch, wenn die Bilder Kinder oder andere schutzbedürftige Personen zeigen.
• In einigen Implementierungen kann ein Beispiel für ein autonomes Fahrsystem (einschließlich fahrzeuginterner autonomer Fahrsysteme und Unterstützungssysteme, die in der Cloud oder im Nebel implementiert sind) maschinelle Lernmodelle verwenden, um Gesichter unkenntlich zu machen, die in Bildern dargestellt sind, die von einer Kamera oder einem anderen Bildaufnahmegerät aufgenommen wurden, das in Fahrzeuge integriert oder an ihnen angebracht ist. In einem Ausführungsbeispiel kann ein trainiertes Generative Adversarial Network (GAN) verwendet werden, um Bild-zu-Bild-Übersetzungen für mehrere Domänen (z. B. Gesichtsattribute) mit einem einzigen Modell durchzuführen. Das trainierte GAN-Modell kann getestet werden, um ein Gesichtsattribut oder eine Kombination von Gesichtsattributen auszuwählen, die, wenn sie auf ein bekanntes, in einem Bild dargestelltes Gesicht übertragen werden, um das bekannte Gesicht zu verändern (oder unkenntlich zu machen), dazu führen, dass ein Gesichtserkennungsmodell das bekannte Gesicht in dem veränderten (oder unkenntlich gemachten) Gesicht nicht identifizieren kann. Das trainierte GAN-Modell kann mit dem ausgewählten Gesichtsattribut oder einer Kombination von Gesichtsattributen ausgebildet werden. Das ausgebildete GAN-Modell kann in einem Fahrzeug bereitgestellt werden, um Bilder zu empfangen, die von einem mit dem Fahrzeug verbundenen Bilderfassungsgerät aufgenommen wurden, oder andere Bilder, die von einem Rechensystem im Fahrzeug von anderen elektronischen Geräten oder Netzwerken empfangen wurden. Das ausgebildete GAN-Modell kann auf ein aufgenommenes oder empfangenes Bild angewendet werden, das ein Gesicht zeigt, um das Gesicht unkenntlich zu machen, während bestimmte Attribute (oder Merkmale) erhalten bleiben, die Informationen über die mit dem Gesicht verbundene Person offenbaren. Zu diesen Informationen gehören beispielsweise der Blick und/oder die Emotion der Person, als das Bild aufgenommen wurde.
• Da die in mobilen Fahrzeugen eingesetzten intelligenten Fahrsysteme immer ausgefeilter werden und sogar teilweise oder vollständig autonom sind, hat die Menge und Qualität der von diesen Fahrzeugen gesammelten Bild- und Videodaten erheblich zugenommen. Bild- und Videodaten können von jeder Art von mobilem Fahrzeug erfasst werden, einschließlich, aber nicht unbedingt beschränkt auf Autos, Busse, Züge, Drohnen, Boote, U-Bahnen, Flugzeuge und andere Transportfahrzeuge. Die erhöhte Qualität und Quantität der Bild- und Videodaten, die von auf mobilen Fahrzeugen montierten Bildaufnahmegeräten gewonnen werden, kann die Identifizierung von Personen ermöglichen, die in den Bild- und Videodaten erfasst sind, und Informationen über den Standort dieser Personen zu bestimmten Zeitpunkten liefern. Derartige Informationen werfen sowohl Sicherheits- als auch Datenschutzbedenken auf, was besonders problematisch sein kann, wenn die erfassten Daten Kinder oder andere schutzbedürftige Personen betreffen.
• Bei autonomen Fahrzeugen können die von den Fahrzeugen gesammelten Bild- und Videodaten (z. B. bis zu 5 TB/Stunde) zum Trainieren von Modellen für maschinelles Lernen beim autonomen Fahren verwendet werden. Diese Modelle zielen darauf ab, die Szene um das Fahrzeug herum zu verstehen, Objekte und Fußgänger zu erkennen und ihre Flugbahn vorherzusagen.
• In einigen Ländern (z. B. in der Europäischen Union, in einigen Bundesstaaten der Vereinigten Staaten von Amerika usw.) sind Identifizierungsdaten geschützt, und gegen Unternehmen, die diese geschützten Daten aufbewahren, können harte Geldstrafen verhängt werden. Darüber hinaus kann das Wissen, dass Transportfahrzeuge diese Daten kontinuierlich sammeln, das Vertrauen der Öffentlichkeit und die Akzeptanz autonomer Fahrzeuge beeinträchtigen und sich sogar negativ auf die öffentliche Meinung gegenüber Servicefahrzeugen auswirken. Folglich könnten diese Fragen des Schutzes der Privatsphäre der Nutzer, wenn sie nicht gelöst werden, die Einführung zumindest einiger autonomer Fahrzeugtechnologien behindern.
• Ein Ansatz zur Wahrung der Privatsphäre von Bild- und Videodaten besteht darin, Gesichter in den Daten unkenntlich zu machen oder zu verpixeln. Während Unschärfe und Pixilation in Fällen funktionieren können, in denen grundlegende Computer-Vision-Algorithmen mit dem Ziel eingesetzt werden, eine Person ganzheitlich zu erkennen, funktionieren diese Ansätze nicht mit modernen Algorithmen, die darauf abzielen, den Blick und die Absicht einer Person zu verstehen. Solche Informationen können besonders nützlich und sogar notwendig sein, wenn ein autonomes Fahrzeug auf einen Fußgänger trifft und eine Reaktion (z. B. Verlangsamen, Anhalten, Hupen, normales Weiterfahren usw.) auf der Grundlage der Vorhersage des Verhaltens des Fußgängers (z. B. Überqueren des Zebrastreifens, Warten auf den Wechsel der Ampel usw.) bestimmt. Die Blicke und Absichten von Fußgängern werden zunehmend erforscht, um die „Intelligenz“ der Fahrzeuge zu erhöhen. Durch die Erkennung von Blicken und Absichten aus dem Gesicht eines Fußgängers sollen intelligente Algorithmen die Flugbahn des Fußgängers vorhersagen und so Unfälle vermeiden. So ist es zum Beispiel wahrscheinlicher, dass ein Fußgänger, der auf sein Handy schaut, ein vorbeifahrendes Fahrzeug übersieht, als ein anderer Fußgänger, der das Fahrzeug direkt ansieht. Algorithmen des maschinellen Lernens müssen einige Orientierungspunkte aus dem Gesicht extrahieren, um den Blick voraussagen zu können. Das Verwischen oder Verpixeln eines Gesichts macht diese Aufgabe unpraktisch.
• Ein Kommunikationssystem 8900, wie es in 89 gezeigt ist, löst viele der vorgenannten Probleme (und mehr). In mindestens einer Ausführungsform verwendet ein die Privatsphäre schützendes Computer-Vision-System ein Generative Adversarial Network (GAN), um die Privatsphäre in Computer-Vision-Anwendungen zu schützen und gleichzeitig den Nutzen der Daten aufrechtzuerhalten und die Computer-Vision-Fähigkeiten nur minimal zu beeinträchtigen. GANs bestehen in der Regel aus zwei neuronalen Netzen, die hier als „Generator“ (oder „generatives Modell“) und „Diskriminator“ (oder „diskriminatives Modell“) bezeichnet werden können. Der Generator lernt von einem (echten) Datensatz und versucht dann, neue Daten zu erzeugen, die dem Trainingsdatensatz ähneln. Der Diskriminator versucht, zwischen den neuen (vom Generator erzeugten) Daten und den echten Daten zu unterscheiden. Das Ziel des Generators ist es, die Fehlerrate des diskriminierenden Netzes zu erhöhen (d.h. das diskriminierende Netz zu „täuschen“), indem er neue synthetische Instanzen produziert, die scheinbar aus der wahren Datenverteilung stammen.
• Mindestens eine Ausführungsform kann ein vortrainiertes GAN-Modell verwenden, das auf die Übertragung von Gesichtsmerkmalen spezialisiert ist. Im Kommunikationssystem 8900 kann das vortrainierte GAN-Modell verwendet werden, um Gesichtsattribute in Bildern von realen Personen durch eine Variation dieser Attribute zu ersetzen, während Gesichtsattribute beibehalten werden, die von anderen maschinellen Lernfähigkeiten benötigt werden, die Teil der Computersichtfähigkeiten eines Fahrzeugs sein können. Im Allgemeinen wird das GAN-Modell so trainiert, dass es ein Eingangsbild, das ein Gesicht darstellt (z. B. ein digitales Bild des Gesichts einer realen Person), verarbeitet, um ein neues Bild zu erzeugen, das das Gesicht mit veränderten oder variierten Attributen darstellt. Dieses neue Bild wird hier als „verdecktes“ Gesicht oder „falsches“ Gesicht bezeichnet. Das Kommunikationssystem 8900 kann das vortrainierte GAN-Modell mit einem oder mehreren ausgewählten Domänenattributen (z. B. Alter, Geschlecht) konfigurieren, um zu steuern, welche Attribute oder Merkmale verwendet werden, um die Eingabebilder zu ändern.
• Das ausgebildete GAN-Modell kann in einem Fahrzeug eingesetzt werden, das über ein oder mehrere Bilderfassungsgeräte verfügt, um Bilder von Fußgängern, anderen Fahrzeugführern, Fahrgästen oder anderen Personen zu erfassen, die sich in einem bestimmten Bereich des Fahrzeugs befinden. Wenn ein Bild einer Person von einem der Bildaufnahmegeräte des Fahrzeugs erfasst wird, kann das Bild für die Verarbeitung durch das ausgebildete GAN-Modell vorbereitet werden. Die Verarbeitung kann z. B. die Größenänderung des Bildes, die Erkennung eines im Bild dargestellten Gesichts und die Ausrichtung des Gesichts umfassen. Das verarbeitete Bild kann dem vorausgebildeten GAN-Modell zur Verfügung gestellt werden, das das im Bild dargestellte Gesicht auf der Grundlage der vorausgebildeten Domänenattribute (z. B. Alter, Geschlecht) modifiziert. Der Generator des GAN-Modells erzeugt das neue Bild, das ein verändertes oder verdecktes Gesicht zeigt, und stellt es anderen Fahrzeug-Computer-Vision-Anwendungen und/oder Datenerfassungsspeichern (z. B. in der Cloud) zur Informationsgewinnung oder für andere Zwecke zur Verfügung, ohne dass dabei identifizierende Informationen über die Person, deren Gesicht verdeckt wurde, preisgegeben werden. Das durch das GAN-Modell erzeugte neue Bild wird hier als „unkenntlich gemachtes Bild“ und „gefälschtes Bild“ bezeichnet.
• Das Kommunikationssystem 8900 kann mehrere mögliche Vorteile bieten. Das zu erwartende weitere Wachstum der autonomen Fahrzeugtechnologie wird wahrscheinlich zu großen Mengen an identifizierbaren Bildern im täglichen Gebrauch führen. Die hier beschriebenen Ausführungsformen gehen auf die Bedenken hinsichtlich des Datenschutzes beim Fotografieren von Personen ein, wobei der Nutzen der Daten erhalten bleibt und die Fähigkeiten der Computer Vision nur minimal beeinträchtigt werden. Insbesondere können die hierin umfassten Ausführungsformen ein Bild des Gesichts einer Person unkenntlich machen, während die Gesichtsattribute erhalten bleiben, die für andere im Fahrzeug implementierte Computer-Vision-Funktionen benötigt werden. Die Privatsphäre der Nutzer kann sowohl gesellschaftliche als auch rechtliche Auswirkungen haben. Wenn beispielsweise die Fragen des Schutzes der Privatsphäre des Benutzers bei Bildern, die in Echtzeit aufgenommen werden, nicht geklärt sind, kann die Nutzung der Bildverarbeitungsfunktionen behindert werden. Da die hierin umfassten Ausführungsformen die Datenschutzprobleme der Benutzer von autonomen Fahrzeugen (und anderen Fahrzeugen mit Bildaufnahmegeräten) entschärfen, können die Ausführungsformen dazu beitragen, das Vertrauen in autonome Fahrzeuge zu stärken und die Einführung der Technologie zu erleichtern, sowie den Fahrzeugherstellern, Fahrzeugbesitzern und Mobilfunkanbietern dabei helfen, die zunehmende Zahl von Datenschutzvorschriften auf Bundes-, Landes- und/oder lokaler Ebene einzuhalten.
• Bezug nehmend nun auf 89, 89 veranschaulicht das Kommunikationssystem 8900 zur Wahrung der Privatsphäre in Computer-Vision-Systemen von Fahrzeugen gemäß mindestens einer hier beschriebenen Ausführungsform. Das Kommunikationssystem 8900 umfasst ein Generative Adversarial Network (GAN)-Konfigurationssystem 8910, ein Datenerfassungssystem 8940 und ein Fahrzeug 8950. Ein oder mehrere Netzwerke, wie das Netzwerk 8905, können die Kommunikation zwischen dem Fahrzeug 8950 und dem GAN-Konfigurationssystem 8910 sowie zwischen dem Fahrzeug 8950 und dem Datenerfassungssystem 8940 erleichtern.
• Das GAN-Konfigurationssystem 8910 umfasst ein GAN-Modell 8920 mit einem Generator 8922 und einem Diskriminator 8924. Das GAN-Modell 8920 kann mit einer ausgewählten Zieldomäne ausgebildet werden, was zu einem ausgebildeten GAN-Modell 8930 mit einem Generator 8932, einem Diskriminator 8934 und einer Zieldomäne 8936 führt. Das GAN-Modell 8920 umfasst auch geeignete Hardwarekomponenten, einschließlich, aber nicht unbedingt beschränkt auf einen Prozessor 8937 und einen Speicher 8939, die in zahlreichen verschiedenen Ausführungsformen implementiert werden können.
• Das ausgebildete GAN-Modell kann in Fahrzeugen, wie dem Fahrzeug 8950, bereitgestellt werden. In mindestens einer Ausführungsform kann das ausgebildete GAN-Modell als Teil eines die Privatsphäre schützenden Computer-Vision-Systems 8955 des Fahrzeugs bereitgestellt werden. Das Fahrzeug 8950 kann auch eine oder mehrere Bildaufnahmevorrichtungen umfassen, wie z. B. die Bildaufnahmevorrichtung 8954 zur Aufnahme von Bildern (z. B. Digitalfotos) von Fußgängern, wie dem Fußgänger 8902, anderen Fahrern, Fahrgästen und anderen Personen in der Nähe des Fahrzeugs. Das Bildverarbeitungssystem 8955 kann auch Anwendungen 8956 zur Verarbeitung eines unkenntlich gemachten Bildes aus dem ausgebildeten GAN-Modell 8930 umfassen, um Bewertungen des Bildes durchzuführen und geeignete Maßnahmen auf der Grundlage bestimmter Implementierungen zu ergreifen (z. B. Fahrreaktionen für autonome Fahrzeuge, Senden von Warnungen an den Fahrer usw.). Geeignete Hardwarekomponenten sind ebenfalls im Fahrzeug 8950 vorhanden, einschließlich, aber nicht notwendigerweise beschränkt auf einen Prozessor 8957 und einen Speicher 8959, die in zahlreichen verschiedenen Ausführungsformen implementiert werden können.
• Das Datenerfassungssystem 8940 kann einen Datenspeicher 8942 zur Speicherung unkenntlich gemachter Bilder umfassen, die von dem ausgebildeten GAN-Modell 8930 erzeugt werden, wenn es in einem Fahrzeug bereitgestellt wird. Die unkenntlich gemachten Bilder können in Verbindung mit Informationen gespeichert werden, die sich auf die Bildauswertungen und/oder die vom Computer Vision System 8952 durchgeführten Aktionen beziehen. In einer Beispielimplementierung kann das Datenerfassungssystem 8940 ein Cloud-Verarbeitungssystem sein, das Fahrzeugdaten wie unkenntlich gemachte Bilder und möglicherweise andere von autonomen Fahrzeugen erzeugte Daten empfängt. Das Datenerfassungssystem 8940 umfasst auch geeignete Hardwarekomponenten, einschließlich, aber nicht notwendigerweise beschränkt auf einen Prozessor 8947 und einen Speicher 8949, die in zahlreichen verschiedenen Ausführungsformen implementiert werden können.
• 90A und 90B zeigen beispielhafte maschinelle Lernphasen für ein Generative Adversarial Network (GAN) zur Erstellung eines GAN-Modells (z. B. 8920), das in den hier beschriebenen Ausführungsformen verwendet werden kann, um die Übertragung von Gesichtsattributen auf ein in einem digitalen Bild dargestelltes Gesicht zu bewirken.
• In 90A ist eine erste Trainingsphase für den Diskriminator 8924 dargestellt. In einem Beispiel kann der Diskriminator 8924 ein standardmäßiges neuronales Faltungsnetzwerk (CNN) sein, das Bilder verarbeitet und lernt, diese Bilder als echt oder gefälscht zu klassifizieren. Die Trainingsdaten 9010 können echte Bilder 9012 und gefälschte Bilder 9014 umfassen. Die echten Bilder 9012 zeigen menschliche Gesichter, und die gefälschten Bilder 9014 zeigen andere Dinge als menschliche Gesichter. Die Trainingsdaten werden in den Diskriminator 8924 eingespeist, der Deep Learning anwendet (z. B. über ein Faltungsneuronales Netzwerk), um zu lernen, Bilder als echte Gesichter oder falsche Gesichter zu klassifizieren.
• Sobald der Diskriminator darauf trainiert ist, Bilder menschlicher Gesichter als echt oder unecht zu klassifizieren, kann das GAN wie in FIG trainiert werden. 90B. In einem Beispiel kann der Generator 8922 ein dekonvolutives (oder inverses) neuronales Netz sein. Der Generator 8922 nimmt ein Eingabebild aus den Eingabebildern 9022 und wandelt es in ein unkenntlich gemachtes (oder gefälschtes) Bild um, indem er Gesichtsattributübertragungen auf der Grundlage einer Zieldomäne 9024 durchführt. In mindestens einer Ausführungsform wird das Domänenattribut räumlich repliziert und mit dem Eingabebild verkettet. Der Generator 8922 versucht, gefälschte Bilder 9026 zu erzeugen, die der Diskriminator nicht von echten Bildern unterscheiden kann.
• Diskriminator 8924, der darauf trainiert wurde, echte oder gefälschte menschliche Gesichter zu erkennen, wie in 90A gezeigt, empfängt die gefälschten Bilder 9026 und wendet Faltungsoperationen auf das gefälschte Bild an, um es als „echt“ oder „gefälscht“ zu klassifizieren. Anfänglich kann der Generator gefälschte Bilder mit einem hohen Verlustwert erzeugen. Mit Hilfe der Backpropagation des Generatorverlustes können die Gewichte und Verzerrungen des Generators aktualisiert werden, um im Laufe des Trainings realistischere Bilder zu erzeugen. Wenn ein gefälschtes Bild den Diskriminator so „austrickst“, dass er es als „echt“ einstuft, wird Backpropagation verwendet, um die Gewichte und Verzerrungen des Diskriminators zu aktualisieren, um ein „echtes“ menschliches Gesicht genauer von einem „gefälschten“ (z. B. vom Generator erzeugten) menschlichen Gesicht zu unterscheiden. Das Training kann fortgesetzt werden, wie in 90B gezeigt ist, bis ein bestimmter Prozentsatz der gefälschten Bilder vom Diskriminator als echt eingestuft worden ist.
• 91 veranschaulicht weitere mögliche Komponenten und Betriebsdetails des GAN-Konfigurationssystems 8910 gemäß mindestens einer Ausführungsform. Im GAN-Konfigurationssystem 8910 kann eine Zieldomäne identifiziert und zur Konfiguration des GAN-Modells 8920 verwendet werden. Eine Zieldomäne bezeichnet ein oder mehrere Attribute, die vom GAN-Modell verwendet werden sollen, um ein in einem Eingabebild dargestelltes Gesicht zu verändern. Bestimmte andere Attribute, die nicht in der Zieldomäne liegen, werden nicht verändert und bleiben daher in dem vom Generator 8922 des GAN-Modells erzeugten unkenntlich gemachten Bild erhalten. In der Fahrzeugtechnik kann es beispielsweise wünschenswert sein, ein Blickattribut zu erhalten, das die Absicht der durch das Gesicht dargestellten Person anzeigen kann. Anhand des Blicks der Person und der daraus abgeleiteten Absicht kann eine Flugbahn der Person bestimmt werden. Ein weiteres Attribut, das in der Fahrzeugtechnik nützlich sein kann, sind Emotionen. Die von einem Gesicht in einem aufgenommenen Bild angezeigte Emotion kann anzeigen, ob die durch das Gesicht dargestellte Person zu einem bestimmten Zeitpunkt eine bestimmte Emotion empfindet (z. B. ob der Insasse eines Mitfahrdienstes zufrieden ist oder nicht, ob der Fahrer eines anderen Fahrzeugs Anzeichen von Verkehrsrowdytum zeigt, ob ein Fußgänger Angst hat oder aufgeregt ist usw.). Obwohl alle Gesichtsattribute beibehalten werden können, wird zur Veranschaulichung das in 91 dargestellte GAN-Konfigurationssystem 8910 unter Bezugnahme auf die Konfiguration des GAN-Modells 8920 mit einer optimalen Zieldomäne beschrieben, die die Blick- und Emotionsattribute in einem Gesicht unverändert lässt, ohne dass andere identifizierende Merkmale des Gesichts beibehalten werden müssen.
• In mindestens einer Ausführungsform kann ein für die Bildtransformation verwendeter Zielbereich so ausgewählt werden, dass eine maximale Identitätsverschleierung erreicht wird, während der Blick und/oder die Emotion des Gesichts erhalten bleiben. Ein optimaler Zielbereich kann beispielsweise ein oder mehrere Attribute angeben, die die Wahrscheinlichkeit des Erkennens einer Person minimieren, während ihr Blick und ihr emotionaler Ausdruck wie im Originalbild oder im Wesentlichen wie im Originalbild erhalten bleiben. 91 veranschaulicht eine mögliche Ausführungsform zur Bestimmung eines optimalen Zielbereichs.
• Das GAN-Konfigurationssystem 8910 umfasst das GAN-Modell 8920, ein Attributerkennungsmodul 8917 (z. B. ein Modul zur Erkennung von Emotionen und/oder ein Modul zur Erkennung von Blicken) und ein Gesichtserkennungsmodul 8918. Das GAN-Modell 8920 ist so vortrainiert, dass es ein in einem Bild abgebildetes Gesicht modifiziert, um ein neues unkenntlich gemachtes Bild (z. B. unkenntlich gemachte Bilder 9116) zu erzeugen, indem es ein oder mehrere Gesichtsattribute auf das Gesicht überträgt. Die zu übertragenden Gesichtsattribute basieren auf einer ausgewählten Zieldomäne 9114, die dem Generator des GAN-Modells zur Verfügung gestellt wird. Es kann irgendeine Anzahl geeigneter GAN-Modelle verwendet werden, wie z. B. StarGAN, IcGAN, DIAT oder CycleGAN.
• Um das GAN-Modell 8920 mit einer optimalen Zieldomäne für die Anonymisierung eines Gesichts zu konfigurieren und gleichzeitig die gewünschten Gesichtsattribute (z. B. Blick und Absicht, Emotion) zu erhalten, können Testbilder 9112 zusammen mit der ausgewählten Zieldomäne 9114 in den Generator 8922 des GAN-Modells 8920 eingespeist werden. Für ein bestimmtes Testbild kann der Generator 8922 ein unkenntlich gemachtes Bild (z. B. unkenntlich gemachte Bilder 9116) erzeugen, bei dem die Attribute im Testbild, die der ausgewählten Zieldomäne 9114 entsprechen, geändert werden. Wenn die gewählte Zieldomäne beispielsweise Attributkennungen für „Alter“ und „Geschlecht“ umfasst, wird das im unkenntlich gemachten Bild dargestellte Gesicht gegenüber dem Testbild so verändert, dass es älter und vom anderen Geschlecht ist. Andere Merkmale des Gesichts wie Blick und Emotion bleiben jedoch unverändert oder werden zumindest geringfügig verändert.
• In mindestens einer Ausführungsform kann eine Attributerkennungsmaschine 8917 bereitgestellt werden, die auswertet, ob die gewünschten Attribute in den unkenntlich gemachten Bildern 9116 noch erkennbar sind. Beispielsweise kann ein Emotionserkennungsmodul ein unkenntlich gemachtes Bild auswerten, um festzustellen, ob die Emotion, die in dem veränderten Gesicht auf dem unkenntlich gemachten Bild erkannt wurde, die gleiche (oder im Wesentlichen die gleiche) ist wie die Emotion, die in dem entsprechenden realen Gesicht auf dem Testbild (z. B. 9112) erkannt wurde. In einem anderen Beispiel kann ein Blickdetektormodul ein unkenntlich gemachtes Bild auswerten, um festzustellen, ob der Blick, der in dem im unkenntlich gemachten Bild dargestellten veränderten Gesicht erkannt wurde, derselbe (oder im Wesentlichen derselbe) ist wie der Blick, der in dem entsprechenden, im Testbild dargestellten realen Bild erkannt wurde. Dementsprechend können zumindest in einigen Ausführungsformen auch Testbilder 9112 oder Beschriftungen, die die in den Testbildern angegebenen Attribute (z. B. glücklich, wütend, abgelenkt, Blickrichtung usw.) spezifizieren, an die Attributerkennungsmaschine 8917 übermittelt werden, um den Vergleich durchzuführen. Andere gewünschte Attribute können ebenfalls ausgewertet werden, um festzustellen, ob sie in den unkenntlich gemachten Bildern erkennbar sind. Wenn die gewünschten Attribute (z. B. Emotion, Blick) nicht erkannt werden, kann eine neue Zieldomäne, die ein neues Attribut oder einen Satz neuer Attribute angibt, zur Eingabe in den Generator 8922 ausgewählt werden. Werden jedoch die gewünschten Attribute erkannt, kann das unkenntlich gemachte Bild dem Gesichtserkennungsprogramm 8918 zugeführt werden, um festzustellen, ob das unkenntlich gemachte Gesicht erkennbar ist.
• Bei der Gesichtserkennungssoftware 8918 kann es sich um jede geeignete Gesichtserkennungssoftware handeln, die so ausgebildet oder trainiert ist, dass sie eine ausgewählte Gruppe von Personen (z. B. eine Gruppe von Prominenten) erkennt. Zum Beispiel ist Celebrity Endpoint eine Gesichtserkennungsmaschine, die mehr als zehntausend Prominente erkennen kann und in einem oder mehreren hier beschriebenen Testszenarien verwendet werden kann, wobei die Testbilder 9112 Bilder von Prominenten sind, die von Celebrity Endpoint erkannt werden können. In mindestens einem Szenario können diese Testbilder vor der Verarbeitung der Testbilder 9112 durch das GAN-Modell 8920 von der Gesichtserkennungsmaschine 8918 verarbeitet werden, um sicherzustellen, dass sie von der Gesichtserkennungsmaschine erkannt werden können. In einem anderen Szenario können bestimmte Bilder, die von der Gesichtserkennungsmaschine 8918 erkannt werden, dem GAN-Konfigurationssystem 8910 zur Verwendung als Testbilder 9112 zugänglich sein.
• Sobald ein unkenntlich gemachtes Bild erzeugt wurde (und die gewünschten Attribute in auf dem unkenntlich gemachten Bild noch erkennbar sind), kann das unkenntlich gemachte Bild dem Gesichtserkennungsmodul 8918 zugeführt werden, um festzustellen, ob eine Person anhand des unkenntlich gemachten Bildes identifiziert werden kann. Wenn die Gesichtserkennungsmaschine die Person auf dem unkenntlich gemachten Bild wiedererkennt, hat der Generator das Gesicht nicht ausreichend anonymisiert. So kann eine neue Zieldomäne, die ein neues Attribut oder einen Satz neuer Attribute angibt, zur Eingabe in den Generator 8922 ausgewählt werden. Wenn die Gesichtserkennungsmaschine die Person auf dem unkenntlich gemachten Bild jedoch nicht erkennt, wird festgestellt, dass die ausgewählte Zieldomäne, die zur Erzeugung des unkenntlich gemachten Bildes verwendet wurde, das Gesicht erfolgreich anonymisiert hat, wobei die gewünschten Attribute erhalten bleiben. In mindestens einer Ausführungsform kann, sobald eine bestimmte Anzahl (oder ein bestimmter Prozentsatz) von Bildern unter Beibehaltung der gewünschten Attribute erfolgreich anonymisiert wurde, die ausgewählte Zieldomäne, die das Bild erfolgreich anonymisiert hat, zur Konfiguration des GAN-Modells 8920 verwendet werden. In einem Beispiel kann die ausgewählte Zieldomäne als die Zieldomäne des GAN-Modells 8920 für den Echtzeitbetrieb eines autonomen Fahrzeugs festgelegt werden.
• Es sollte klar sein, dass einige der Aktivitäten im GAN-Konfigurationssystem 8910 durch Benutzeraktionen durchgeführt werden können oder automatisiert werden können. Beispielsweise können neue Zieldomänen für die Eingabe in das GAN-Modell 8920 von einem Benutzer ausgewählt werden, der damit beauftragt ist, das GAN-Modell mit einer optimalen Zieldomäne zu konfigurieren. In anderen Szenarien kann eine Zieldomäne automatisch ausgewählt werden. Auch wenn visuelle Vergleiche zwischen den unkenntlich gemachten Bildern und den Testbildern durchgeführt werden können, kann ein solcher manueller Aufwand die Effizienz und Genauigkeit der Bestimmung, ob die Identität einer in einem Bild dargestellten Person ausreichend unkenntlich gemacht ist und ob die gewünschten Attribute ausreichend erhalten sind, so dass das unkenntlich gemachte Bild in Computer-Vision-Anwendungen nützlich sein wird, erheblich verringern.
• 92 zeigt Beispiel für unkenntlich gemachte Bilder 9204, die mit Hilfe eines StarGAN-basierten Modells erzeugt wurden, um verschiedene Gesichtsattribute eines Eingabebildes 9202 zu verändern. Zu den Attributen, die zur Änderung des Eingabebildes 9202 verwendet werden, gehören Haarfarbe (z. B. schwarzes Haar, blondes Haar, braunes Haar) und Geschlecht (z. B. männlich, weiblich). Ein StarGAN-basiertes Modell könnte auch verwendet werden, um Bilder mit anderen veränderten Attributen wie Alter (z. B. älter aussehend) und Hautfarbe (z. B. blass, braun, olivfarben usw.) zu erzeugen. Darüber hinaus können auch Kombinationen dieser Attribute verwendet werden, um ein Bild zu verändern, einschließlich H+G (z. B. Haarfarbe und Geschlecht), H+A (z. B. Haarfarbe und Alter), G+A (z. B. Geschlecht und Alter) und H+G+A (z. B. Haarfarbe, Geschlecht und Alter). Andere bestehende GAN-Modelle können Attributänderungen anbieten, wie Rekonstruktion (z. B. Veränderung der Gesichtsstruktur), Glatze, Ponyfrisur, Brille, starkes Make-up und Lächeln. Eine oder mehrere dieser Attributtransformationen können auf Testbilder angewandt werden, und die transformierten (oder unkenntlich gemachten) Bilder können ausgewertet werden, um die optimale Zieldomäne zu bestimmen, die zur Konfiguration eines GAN-Modells für die Verwendung in einem Fahrzeug zu verwenden ist, wie zuvor hier beschrieben.
• 93 zeigt ein Beispiel für unkenntlich gemachte Bilder 9304, die von einem StarGAN-basierten Modell aus einem Eingabebild 9302 eines echten Gesichts erzeugt wurden, und die Ergebnisse einer Gesichtserkennungsmaschine (z. B. 8918), die die echten und unkenntlich gemachten Bilder auswertet. Die unkenntlich gemachten Bilder 9304 werden durch Veränderung verschiedener Gesichtsattribute des Eingangsbildes 9302 erzeugt. Zu den Attributen, mit denen das Eingabebild 9302 in diesem Beispiel verändert wird, gehören schwarze Haare, blonde Haare, braune Haare und das Geschlecht (z. B. männlich). Die Verwendung der Gesichtserkennungsmaschine zeigt, wie die von einem GAN-Modell erzeugten Bilder ein Gesicht anonymisieren können. Ein Beispiel für eine Gesichtserkennungsmaschine ist die Erkennung von Berühmtheiten. Dementsprechend können die Ergebnisse bei der Verarbeitung eines Eingabebildes, das kein Prominenter ist, durch die Gesichtserkennungsmaschine darauf hinweisen, dass das Eingabebild nicht erkannt wird oder das Eingabebild, das kein Prominenter ist, möglicherweise falsch identifiziert wird. Die Ergebnisse 9306 der Gesichtserkennungsmaschine, dargestellt in 93, zeigen an, dass es sich bei der durch das Eingangsbild 9302 dargestellten Person nicht um einen Prominenten handelt, auf den die Gesichtserkennungsmaschine trainiert wurde. Die Gesichtserkennungsmaschine erkennt jedoch einige der unkenntlich gemachten Bilder 9304 falsch. Die Ergebnisse 9306 zeigen zum Beispiel, dass das unkenntlich gemachte Bild mit schwarzen Haaren als weiblicher Prominenter 1 und das unkenntlich gemachte Bild mit einem Geschlechtswechsel als männlicher Prominenter 2 erkannt wird. Darüber hinaus ist es bemerkenswert, dass die Gesichtserkennungsmaschine bei einer Änderung des Geschlechts das unkenntlich gemachte Bild als das einer Person des anderen Geschlechts erkennt, was den Schutz der Privatsphäre der echten Person erhöht.
• In anderen Testszenarien können die Eingabebilder prominente Persönlichkeiten umfassen, die von der Gesichtserkennungsmaschine erkannt werden. Diese Eingabebilder von Prominenten können durch das GAN-Modell geleitet und auf der Grundlage ausgewählter Zielbereiche verfremdet werden. Eine optimale Zieldomäne kann auf der Grundlage der Gesichtserkennungsmaschine identifiziert werden, die eine Schwellenanzahl der unkenntlich gemachten Bilder nicht erkennt und/oder eine Schwellenanzahl der unkenntlich gemachten Bilder falsch erkennt, wie zuvor hierin beschrieben.
• 94A zeigt ein Beispiel für unkenntlich gemachte Bilder 9404, die von einem StarGAN-basierten Modell aus einem Eingabebild 9402 eines realen Gesichts erzeugt wurden, sowie die Ergebnisse einer Emotionserkennungsmaschine, die die realen und die unkenntlich gemachten Bilder auswertet. Die unkenntlich gemachten Bilder 9404 werden durch Veränderung verschiedener Gesichtsattribute des Eingangsbildes 9402 erzeugt. Zu den Attributen, die zur Modifizierung des Eingabebildes 9402 verwendet werden, gehören schwarze Haare, blonde Haare, braune Haare und das Geschlecht (z. B. männlich). 94A zeigt auch Beispielergebnisse 9408A-9408E einer Emotionserkennungsmaschine. Ein Beispiel für eine Emotionserkennungsmaschine kann einen Gesichtsausdruck in einem Bild als Eingabe verwenden und Emotionen im Gesichtsausdruck erkennen. Wie die Ergebnisse 9408A-9408E zeigen, werden die Emotionen Wut, Verachtung, Ekel, Angst, Neutral, Traurigkeit und Überraschung von der Emotionserkennungsmaschine weitgehend nicht erkannt, mit Ausnahme von minimalen Erkennungen von Wut in den Ergebnissen 9408B für das unkenntlich gemachte Bild mit schwarzen Haaren und minimalen Erkennungen von Wut und Überraschung in den Ergebnissen 9408E für das unkenntlich gemachte Bild mit einer Geschlechtsumwandlung. Stattdessen erkennt das System Glücksgefühle im Eingabebild und in jedem unkenntlich gemachten Bild. 94A zeigt, dass der Verkleidungsansatz des GAN-Modells die Emotion aus dem Eingabebild 9402 in jedem der unkenntlich gemachten Bilder 9404 beibehalten hat, obwohl die Person nicht erkannt wurde.
• 94B ist eine Auflistung 9450 von Eingabeparametern und Ausgabeergebnissen, die der Beispielverarbeitung der Emotionserkennungsmaschine für das Eingabebild 9402 und die unkenntlich gemachten Bilder 9404, dargestellt in 94A, entsprechen.
• 95 zeigt eine Beispieltransformation eines Eingabebildes 9510 eines echten Gesichts in ein unkenntlich gemachtes Bild 9520, wie sie von einem IcGAN-basierten Modell durchgeführt wird. In 95, ist der Blick der Person auf dem Eingabebild, hervorgehoben durch das Bild 9512, auf dem unkenntlich gemachten Bild, hervorgehoben durch das Bild 9522, derselbe oder im Wesentlichen derselbe. Auch wenn das Gesicht nicht mehr als dieselbe Person erkennbar ist, weil bestimmte Erkennungsmerkmale verändert wurden, bleiben andere Merkmale des Gesichts, wie der Blick, erhalten. In einem autonomen Fahrzeugszenario ermöglicht die Erhaltung des Blicks in einem Gesichtsbild der bordeigenen Intelligenz, die Flugbahn einer gehenden Person auf der Grundlage ihres Blicks vorherzusagen und zu projizieren und möglicherweise andere wertvolle Informationen aus den erhaltenen Merkmalen zu gewinnen, ohne die Privatsphäre der Person zu opfern.
• 96 veranschaulicht weitere mögliche Betriebsdetails eines ausgebildeten GAN-Modells (z. B. 8930), das in einem Fahrzeug (z. B. 8950) implementiert ist. Das ausgebildete GAN-Modell 8930 ist mit der Zieldomäne 8936 ausgebildet, die ein oder mehrere Attribute angibt, die auf die erfassten Bilder angewendet werden sollen. In mindestens einer Ausführungsform kann die Zieldomäne 8936 einen oder mehrere Attributidentifikatoren umfassen, die Attribute wie Geschlecht, Haarfarbe, Alter, Hautfarbe usw. darstellen. In einem Beispiel kann der Generator 8932 die von der Zieldomäne 8936 angegebenen Attribute auf ein in einem erfassten Bild 9612 dargestelltes Gesicht übertragen. Das Ergebnis dieser Attributübertragung ist ein vom Generator 8932 erzeugtes unkenntlich gemachtes Bild 9616. In einem nicht einschränkenden Beispiel umfasst die Zieldomäne 8936 die Attributkennungen Geschlecht und Alter.
• Das erfasste Bild 9612 kann von einer Kamera oder einem anderen am Fahrzeug montierten Bildaufnahmegerät aufgenommen werden. Beispiele für mögliche Arten von aufgenommenen Bildern sind unter anderem Fußgänger, Radfahrer, Jogger, Fahrer anderer Fahrzeuge und Insassen des Fahrzeugs. Jede dieser Arten von aufgenommenen Bildern kann relevante Informationen für ein Computer-Vision-System des Fahrzeugs bieten, um intelligente Vorhersagen über Echtzeit-Ereignisse zu machen, die Personen und andere Fahrzeuge in unmittelbarer Nähe des Fahrzeugs betreffen.
• Das unkenntlich gemachte Bild 9616 kann allen geeigneten Systemen, Anwendungen, Clouds usw. zur Verfügung gestellt werden, die zum Empfang der Daten berechtigt sind. Beispielsweise kann das unkenntlich gemachte Bild 9616 an Anwendungen (z. B. 8956) eines Computer-Vision-Systems (z. B. 8955) im Fahrzeug oder in einer Cloud und/oder an ein Datenerfassungssystem (z. B. 89140) übermittelt werden.
• Zumindest in einigen Ausführungsformen kann das ausgebildete GAN-Modell 8930 weiterhin in Echtzeit trainiert werden. In diesen Ausführungsformen führt das ausgebildete GAN-Modell 8930 den Diskriminator 8934 aus, der vom Generator erzeugte unkenntlich gemachte Bilder, wie das unkenntlich gemachte Bild 9616, empfängt. Der Diskriminator stellt fest, ob ein unkenntlich gemachtes Bild echt oder gefälscht ist. Wenn der Diskriminator das unkenntlich gemachte Bild als echt einstuft, kann ein Diskriminator-Verlustwert auf den Diskriminator rückproportional übertragen werden, um zu lernen, wie man besser vorhersagen kann, ob ein Bild echt oder gefälscht ist. Wenn der Diskriminator das unkenntlich gemachte Bild als falsch einstuft, kann ein Verlustwert des Generators an den Generator zurückgegeben werden, um den Generator weiter zu trainieren, unkenntlich gemachte Bilder zu erzeugen, die den Diskriminator eher dazu bringen, sie als echt einzustufen. Es sollte jedoch klar sein, dass zumindest in einigen Ausführungsformen kein kontinuierliches Echtzeittraining durchgeführt werden kann. Stattdessen kann der Generator 8932 des ausgebildeten GAN-Modells 8930 ohne den entsprechenden Diskriminator 8934 implementiert werden, oder der Diskriminator 8934 kann inaktiv oder selektiv aktiv sein.
• 97 veranschaulicht einen Beispielbetrieb des ausgebildeten GAN-Modells 8930 im Fahrzeug 8950 zur Erzeugung eines unkenntlich gemachten Bildes 9716 und die Verwendung des unkenntlich gemachten Bildes bei Aufgaben des maschinellen Lernens gemäß mindestens einer Ausführungsform. Bei 9712 werden Fahrzeugdaten mit menschlichen Gesichtern von einem oder mehreren am Fahrzeug montierten Bildaufnahmegeräten erfasst. Um die in 97 gezeigten Vorgänge visuell zu veranschaulichen, werden ein Beispiel-Eingabebild 9702, das ein echtes Gesicht darstellt, und ein Beispiel-Verschleierungsbild 9708, das ein verändertes Gesicht darstellt, gezeigt. Diese Beispielbilder wurden zuvor unter Bezugnahme auf FIG gezeigt und beschrieben. 95. Es sei darauf hingewiesen, dass das Bild 9702 nur zur Veranschaulichung dient und dass ein Gesicht nur ein kleiner Teil eines Bildes sein kann, das typischerweise von einem mit einem Fahrzeug verbundenen Bildaufnahmegerät aufgenommen wird. Darüber hinaus können die Fahrzeugdaten mit menschlichen Gesichtern 9712 in einigen Szenarien Bilder umfassen, die von Bildaufnahmegeräten, die mit dem Fahrzeug verbunden sind, und/oder von Bildaufnahmegeräten, die vom Fahrzeug getrennt sind (z. B. andere Fahrzeuge, Drohnen, Ampeln usw.), aufgenommen wurden.
• Ein Gesichtserkennungs- und Ausrichtungsmodell 9720 kann Gesichter in Bildern aus den Fahrzeugdaten erkennen und ausrichten. In mindestens einer Ausführungsform kann ein überwachtes Lernmodell, wie z. B. ein kaskadiertes Multitask-Faltungsnetz (MTCNN), sowohl für die Erkennung als auch für den Abgleich verwendet werden. Bei der Gesichtsausrichtung handelt es sich um eine Computer-Vision-Technologie, bei der die Positionen bestimmter Gesichtsteile (z. B. Augen, Nase, Mund) geschätzt werden. In 97 ist die Gesichtserkennung in einem Beispielbild 9704 und die Ausrichtung der Augen in einem Beispielbild 9706 dargestellt.
• Das erkannte Gesicht wird in das ausgebildete GAN-Modell 8930 zusammen mit der Zieldomäne 8936 eingespeist. In einem Beispiel kann eine Kombination von Geschlechts- und Alterstransformationen des erkannten Gesichts die Wahrscheinlichkeit der Gesichtserkennung senken, während die gewünschten Merkmale des Gesichts, wie Emotionen und Blickinformationen, erhalten bleiben. Der Generator des ausgebildeten GAN-Modells 8930 erzeugt auf der Grundlage der Zieldomäne 8936 und des Eingangsbildes des Gesichtserkennungs- und Ausrichtungsmodells 9720 ein unkenntlich gemachtes Bild 9716, wie in Bild 9708 dargestellt.
• Beachten Sie, dass die Gesichtserkennung 9718 in diesem Beispiel zwar fehlschlägt (z. B. ist das Gesicht des unkenntlich gemachten Bildes 9708 nicht als dieselbe Person erkennbar, die im Originalbild 9702 gezeigt wird), aber bestimmte Merkmale des Gesichts wie der Blick bleiben erhalten. In einem autonomen Fahrzeugszenario kann die bordeigene Intelligenz (z. B. das Bildverarbeitungssystem 8955) immer noch die Flugbahn einer sich bewegenden Person (z. B. gehend, laufend, Fahrrad fahrend, Kraftfahrzeug fahrend usw.) anhand ihres Blicks vorhersagen und projizieren. Da einige der Identifizierungsmerkmale von Personen in Bilddaten zum Zeitpunkt der Bildverarbeitung verworfen werden (z. B. durch Umwandlung oder Veränderung), werden Versuche böswilliger oder neugieriger Akteure (z. B. Hacker oder Überwachungseinrichtungen), die Identität von Personen in den Daten wiederherzustellen, scheitern, ohne die Fähigkeit von Bildverarbeitungsanwendungen zu beeinträchtigen, wertvolle Informationen aus den unkenntlich gemachten Bildern zu erhalten.
• Das unkenntlich gemachte Bild kann je nach Implementierung und Bedarf beliebigen Systemen, Anwendungen oder Clouds zur Verfügung gestellt werden. In diesem Beispiel wird das unkenntlich gemachte Bild 9716 einer Bildverarbeitungsanwendung 9740 im Fahrzeug zur Verfügung gestellt, um die Aktionen der durch das Gesicht dargestellten Person vorherzusagen. Beispielsweise kann die Blickerkennung 9742 feststellen, wohin eine Person (z. B. ein Fußgänger, ein anderer Fahrer usw.) schaut, und die Flugbahnvorhersage 9744 kann eine Flugbahn oder einen Weg vorhersagen, den die Person wahrscheinlich nehmen wird. Wenn beispielsweise ein Fußgänger auf sein Handy schaut oder andere Anzeichen von Ablenkung zeigt und die vorausberechnete Flugbahn darauf hindeutet, dass die Person wahrscheinlich in den Fahrweg des Fahrzeugs gerät, können die entsprechenden Befehle für eine oder mehrere Aktionen erteilt werden, wie z. B. Warnen des Fahrers, Hupen, Verringern der Geschwindigkeit, Anhalten oder jede andere geeignete Aktion oder Kombination von Aktionen.
• In einem anderen Beispiel kann das unkenntlich gemachte Bild 9716 verwendet werden, um die Emotionen der durch das Gesicht dargestellten Person zu bestimmen. Dies kann z. B. für einen Dienstleister, wie einen Transportdienstleister, nützlich sein, um festzustellen, ob sein Insasse mit dem Service zufrieden oder unzufrieden ist. Zumindest in einigen Szenarien können solche Auswertungen fern vom Fahrzeug durchgeführt werden, beispielsweise durch ein Cloud-Verarbeitungssystem 9750 des Dienstanbieters. So können Fotos von Personen (z. B. von Fahrgästen in einem Taxi), die von Bildaufnahmegeräten im Fahrzeug aufgenommen wurden, mit anderen Systemen, Anwendungen, Geräten usw. geteilt werden. Zum Beispiel kann die Emotionserkennung 9752 eine bestimmte Emotion einer Person erkennen, die auf dem unkenntlich gemachten Bild abgebildet ist. Die Handlungsvorhersage/Bewertung 9754 kann eine bestimmte Handlung vorhersagen, die eine auf dem unkenntlich gemachten Bild dargestellte Person wahrscheinlich ausführen wird. So kann z. B. extreme Wut oder Verzweiflung genutzt werden, um den Fahrer zu alarmieren. Die hier vorgestellten Modelle schützen die Privatsphäre des Benutzers, indem sie das Gesicht unkenntlich machen, um eine Gesichtserkennung zu verhindern, und gleichzeitig bestimmte Attribute beibehalten, die eine erfolgreiche Blick- und Emotionserkennung ermöglichen.
• Bezug nehmend nun auf 98, ist 98 ein vereinfachtes Flussdiagramm, das einen detaillierten möglichen Fluss 9800 von Operationen veranschaulicht, die mit der Konfiguration eines Generative Adversarial Network (GAN) verbunden sind, das darauf trainiert ist, Attributübertragungen auf Bilder von Gesichtern durchzuführen. In mindestens einer Ausführungsform entspricht eine Reihe von Vorgängen den Aktivitäten von 98. Das GAN-Konfigurationssystem 8910 kann zumindest einen Teil des Satzes von Operationen verwenden. Das GAN-Konfigurationssystem 8910 kann einen oder mehrere Datenprozessoren 8937 zur Durchführung der Operationen umfassen. In mindestens einer Ausführungsform können der Generator 8922 des GAN-Modells 8920, das Attributerkennungsmodul 8917 und das Gesichtserkennungsmodul 8918 jeweils eine oder mehrere der Operationen durchführen. In einigen Ausführungsformen können zumindest einige der Vorgänge des Ablaufs 9800 mit Benutzerinteraktion durchgeführt werden. In einigen Szenarien kann ein Benutzer beispielsweise Attribute für einen neuen zu testenden Zielbereich auswählen. In anderen Ausführungsformen können die Attribute für eine neue Zieldomäne beispielsweise automatisch nach dem Zufallsprinzip oder auf der Grundlage eines Algorithmus ausgewählt werden.
• Um 9802 erhält der Generator des GAN-Modells ein Testbild eines Gesichts. In mindestens einer Ausführungsform können die in Fluss 9800 verarbeiteten Testbilder a priori von der Gesichtserkennungsmaschine 8918 bewertet werden, um sicherzustellen, dass sie von der Maschine erkannt werden können. Bei 9804 erhält der Generator eine Zieldomäne, die ein oder mehrere Attribute angibt, die zur Verschleierung des Gesichts im Testbild verwendet werden sollen.
• Bei 9806 wird der Generator auf das Testbild angewendet, um ein unkenntlich gemachtes Bild auf der Grundlage der ausgewählten Zieldomäne (z. B. Geschlecht, Alter, Haarfarbe usw.) zu erzeugen. Das unkenntlich gemachte Bild zeigt das Gesicht aus dem Testbild, das anhand eines oder mehrerer Attribute verändert wurde.
• Bei 9808 wird das unkenntlich gemachte Bild einer Attributerkennungsmaschine zur Verfügung gestellt, um festzustellen, ob gewünschte Attribute in dem unkenntlich gemachten Bild erkennbar sind. So kann es beispielsweise wünschenswert sein, ein Blickattribut beizubehalten, damit eine Computer-Vision-Systemanwendung den Blick erkennen und die mit dem Blick verbundene Absicht und/oder Flugbahn der Person vorhersagen kann. In einem anderen Beispiel können Emotionen ein wünschenswertes Attribut sein, damit ein Dritter die Emotion einer Person, die ein Kunde ist, bewerten und feststellen kann, welche Art von Erfahrung der Kunde macht (z. B. zufrieden, verärgert usw.). Alle anderen wünschenswerten Attribute können auf der Grundlage bestimmter Implementierungen und Bedürfnisse und/oder der Arten von maschinellen Lernsystemen, die die unkenntlich gemachten Bilder verwenden, bewertet werden.
• Bei 9810 wird festgestellt, ob die gewünschten Eigenschaften nachweisbar sind. Sind eines oder mehrere der gewünschten Attribute nicht nachweisbar, kann bei 9816 eine neue Zieldomäne zur Prüfung ausgewählt werden. Die neue Zieldomäne kann ein einzelnes Attribut oder eine Kombination von Attributen bezeichnen und kann von einem Benutzer manuell oder automatisch ausgewählt werden. Der Datenfluss geht zurück zu 9804, wo die neu gewählte Zieldomäne am Generator empfangen wird und ein weiterer Test mit der neu gewählten Zieldomäne durchgeführt wird.
• Wenn bei 9810 festgestellt wird, dass die gewünschten Attribute in dem unkenntlich gemachten Bild erkennbar sind, wird bei 9812 das unkenntlich gemachte Bild dem Gesichtserkennungsprogramm zur Verfügung gestellt, um festzustellen, ob das unkenntlich gemachte Bild erkennbar ist. Bei 9814 wird festgestellt, ob das unkenntlich gemachte Bild von der Gesichtserkennungsmaschine erkannt wird. Wird das unkenntlich gemachte Bild erkannt, kann bei 9816 eine neue Zieldomäne zur Prüfung ausgewählt werden. Die neue Zieldomäne kann ein einzelnes Attribut oder eine Kombination von Attributen bezeichnen und kann von einem Benutzer manuell oder automatisch ausgewählt werden. Der Datenfluss geht zurück zu 9804, wo die neu gewählte Zieldomäne am Generator empfangen wird und ein weiterer Test mit der neu gewählten Zieldomäne durchgeführt wird.
• Wenn bei 9814 festgestellt wird, dass das unkenntlich gemachte Bild von der Gesichtserkennungsmaschine nicht erkannt wird, kann bei 9818 das GAN-Modell ausgebildet werden, indem seine Zieldomäne als die Zieldomäne festgelegt wird, die vom Generator verwendet wurde, um das unkenntlich gemachte Bild zu erzeugen. In mindestens einer Ausführungsform kann der ausgewählte Zielbereich, der vom Generator verwendet wird, erst dann zur Konfiguration des Generators verwendet werden, wenn eine bestimmte Schwellenzahl von unkenntlich gemachten Bildern, die auf der Grundlage desselben ausgewählten Zielbereichs unkenntlich gemacht wurden, von der Gesichtserkennungsmaschine nicht erkannt worden ist.
• 99 ist ein vereinfachtes Flussdiagramm, das eine hohe Ebene eines möglichen Flusses 9900 von Operationen veranschaulicht, die mit Operationen eines datenschutzfreundlichen Computer-Vision-Systems (z. B. 8955) eines Fahrzeugs (z. B. 8950) verbunden sind, wenn ein ausgebildetes GAN-Modell (z. B. 8930) in dem System implementiert ist. In mindestens einer Ausführungsform entspricht eine Reihe von Vorgängen den Aktivitäten von 99. Das ausgebildete GAN-Modell 8930 und das Gesichtserkennungs- und - Ausrichtungsmodell 9720 können jeweils mindestens einen Teil des Satzes von Operationen verwenden. Das ausgebildete GAN-Modell 8930 und das Gesichtserkennungs- und Ausrichtungsmodell 9720 können einen weiteren Datenprozessor 8957 zur Durchführung der Operationen umfassen.
• In 9902 empfängt ein die Privatsphäre schützendes Computer-Vision-System ein Bild, das von einer mit einem Fahrzeug verbundenen Bilderfassungsvorrichtung aufgenommen wurde. In anderen Szenarien kann das Bildverarbeitungssystem ein Bild von einem anderen Gerät in unmittelbarer Nähe des Fahrzeugs empfangen. Das Bild könnte zum Beispiel von einem anderen Fahrzeug aufgenommen werden, das an dem Fahrzeug vorbeifährt, das das Bild empfängt.
• In 9904 wird festgestellt, ob das aufgenommene Bild ein Gesicht darstellt. Wenn festgestellt wird, dass das erfasste Bild kein Gesicht darstellt, kann der Ablauf 9900 beendet werden und das ausgebildete GAN-Modell verarbeitet das erfasste Bild nicht.
• Wenn in 9904 festgestellt wird, dass das aufgenommene Bild ein Gesicht zeigt, wird in 9906 das Gesicht in dem aufgenommenen Bild erkannt. Zum Beispiel kann eine Gruppe von Pixeln, die dem Gesicht entsprechen, in dem aufgenommenen Bild erkannt werden. Bei 9908 wird das erkannte Gesicht ausgerichtet, um die Positionen der Gesichtskomponenten (z. B. Augenwinkel, Mundwinkel, Nasenecken usw.) zu schätzen. Bei 9910 kann ein Eingabebild für den Generator auf der Grundlage des erkannten Gesichts und der geschätzten Positionen der Gesichtskomponenten erzeugt werden. In mindestens einem Beispiel kann ein überwachtes Lernmodell wie z. B. ein kaskadiertes Multitasking-Faltungsnetz (MTCNN) sowohl für die Erkennung als auch für den Abgleich verwendet werden.
• Bei 9912 wird der Generator des ausgebildeten GAN-Modells auf das Eingangsbild angewendet, um ein unkenntlich gemachtes Bild auf der Grundlage einer im Generator festgelegten Zieldomäne zu erzeugen. Zu den von der Zieldomäne angegebenen Attributen können in mindestens einer Ausführungsform Alter und/oder Geschlecht gehören. In anderen Ausführungsformen können auch andere Kombinationen von Attributen (z. B. Haarfarbe, Augenfarbe, Hautfarbe, Make-up usw.) oder ein einzelnes Attribut von der Zieldomäne angegeben werden, wenn diese Attribute zu einem unkenntlich gemachten Bild führen, das nicht erkennbar ist, aber die gewünschten Attribute beibehält.
• Bei 9914 wird das unkenntlich gemachte Bild an geeignete Datenempfänger gesendet, einschließlich, aber nicht notwendigerweise beschränkt auf ein oder mehrere Cloud-Datenerfassungssysteme, Anwendungen im Computer-Vision-System und staatliche Stellen (z. B. Regulierungsbehörden wie ein staatliches Verkehrsministerium usw.).
• 100 ist ein vereinfachtes Flussdiagramm, das eine hohe Ebene eines möglichen Flusses 10000 von Operationen veranschaulicht, die mit Operationen verbunden sind, die auftreten können, wenn ein ausgebildetes GAN-Modell (z. B. 8930) auf ein Eingangsbild angewendet wird. In mindestens einer Ausführungsform entspricht eine Reihe von Vorgängen den Aktivitäten von 100. Das ausgebildete GAN-Modell 8930, einschließlich des Generators 8932 und des Diskriminators 8934, kann jeweils mindestens einen Teil des Satzes von Operationen verwenden. Das ausgebildete GAN-Modell 8930 kann einen oder mehrere Datenprozessoren 8957 zur Durchführung der Operationen umfassen. In mindestens einer Ausführungsform können die Vorgänge des Flusses 10000 dem unter 9912 angegebenen Vorgang entsprechen.
• Bei 10002 erhält der Generator eines ausgebildeten GAN-Modells in einem Fahrzeug ein Eingangsbild. Ein Eingabebild kann z. B. durch Erkennung und Ausrichtung eines Gesichts in einem von einem Fahrzeug aufgenommenen Bild erzeugt werden. Bei 10004 erzeugt der Generator aus dem Eingangsbild ein unkenntlich gemachtes Bild, das auf der vorausgebildeten Zieldomäne des Generators basiert (z. B. Geschlecht und Alter).
• Bei 10006 empfängt ein Diskriminator des ausgebildeten GAN-Modells das unkenntlich gemachte Bild vom Generator. Bei 10008 führt der Diskriminator Operationen eines neuronalen Faltungsnetzwerks auf dem unkenntlich gemachten Bild durch, um das unkenntlich gemachte Bild als echt oder gefälscht zu klassifizieren.
• In 10010 wird die Klassifizierung des unkenntlich gemachten Bildes bestimmt. Wenn der Diskriminator das unkenntlich gemachte Bild als Fälschung einstuft, wird bei 10012 ein Generatorverlust an den Generator zurückgegeben, um den Generator weiter zu trainieren, unkenntlich gemachte Bilder zu erzeugen, die vom Diskriminator als „echt“ eingestuft werden (z. B. unkenntlich gemachte Bilder, die den Diskriminator überlisten). Bei 10014 kann der Generator ein anderes unkenntlich gemachtes Bild aus dem Eingangsbild auf der Grundlage der Zieldomäne und des Generatorverlusts erzeugen. Der Datenfluss kann dann zu 10010 übergehen, um festzustellen, wie der Diskriminator das neue unkenntlich gemachte Bild klassifiziert hat.
• Wenn der Diskriminator ein unkenntlich gemachtes Bild bei 10010 als echt klassifiziert, kann bei 10016 ein Diskriminatorverlust an den Diskriminator zurückgegeben werden, um den Diskriminator weiter zu trainieren, damit er gefälschte Bilder genauer erkennt.
• Fluss 10000 veranschaulicht einen Beispielfluss, bei dem das ausgebildete GAN-Modell seinen Generator und Diskriminator in Echtzeit weiter trainiert, wenn es in einem Fahrzeug eingesetzt wird. In einigen Szenarien kann das Training während ausgewählter Zeiträume pausiert werden, bis zusätzliches Training gewünscht wird, zum Beispiel um das ausgebildete GAN-Modell zu aktualisieren. In diesen Szenarien kann zumindest während einiger Zeiträume nur der Generator neuronale Netzwerkoperationen durchführen, wenn ein aufgenommenes Bild verarbeitet wird. Der Diskriminator darf nicht ausgeführt werden, bis ein zusätzliches Training eingeleitet wird.
• In einigen Implementierungen können zusätzliche (oder alternative) Funktionen bereitgestellt werden, um den Schutz der Privatsphäre im Zusammenhang mit Bilddaten zu gewährleisten, die in Verbindung mit autonomen Fahrsystemen erfasst werden. So kann beispielsweise für autonome Fahrzeuge ein System zur Einhaltung des Datenschutzes auf Abruf bereitgestellt werden. In einer Ausführungsform werden beschreibende Tags in Verbindung mit einem „lazy“ On-Demand-Ansatz verwendet, um die Anwendung von Datenschutzmaßnahmen auf gesammelte Fahrzeugdaten zu verzögern, bis die Datenschutzmaßnahmen benötigt werden. Beschreibende Tags werden verwendet, um verschiedene Attribute der Daten anzugeben. Wie unter Bezugnahme auf 101 bis 111 bezeichnet der Begriff „Attribut“ ein Merkmal, eine Eigenschaft oder ein Charakteristikum von Daten. Attribute können verwendet werden, um subjektiv Datenschutzbestimmungen zur Einhaltung von Datenschutzvorschriften und - anforderungen zu definieren. Tags, die auf Datensätze eines bestimmten Fahrzeugs angewendet werden, werden in einer Cloud oder im Fahrzeug ausgewertet, um festzustellen, ob eine „faule“ Richtlinie auf den Datensatz angewendet werden soll. Wird eine „Lazy Policy“ (müßige Richtlinie) angewandt, so wird die Verarbeitung zur Privatisierung oder Anonymisierung bestimmter Aspekte des Datensatzes so lange hinausgezögert, bis der Datensatz in einer Weise verwendet werden soll, die möglicherweise die Privatsphäre beeinträchtigen könnte.
• Neue Technologien wie autonome Fahrzeuge zeichnen sich dadurch aus, dass (i) riesige Mengen an Sensordaten gesammelt werden und (ii) strenge Gesetze und Vorschriften für die Nutzung und den Umgang mit den gesammelten Daten bestehen, in Arbeit sind und sich häufig ändern. Bei einigen Edge-Vorrichtungen, wie z. B. autonomen L4/L5-Fahrzeugen, können Kamera- und Videodaten mit einer Geschwindigkeit von 5 TB/Stunde erzeugt werden. Diese Daten können personenbezogene Informationen umfassen, die Bedenken hinsichtlich des Datenschutzes und der Sicherheit aufwerfen und verschiedenen staatlichen Vorschriften unterliegen können. Zu diesen personenbezogenen Daten können unter anderem Bilder von Personen, einschließlich Kindern, Adressen oder Bilder von Privatgrundstücken, genaue Koordinaten des Standorts eines Fahrzeugs und/oder Bilder von Kfz-Kennzeichen gehören, sind aber nicht unbedingt darauf beschränkt. In einigen Ländern (z. B. in der Europäischen Union) sind personenbezogene Daten gesetzlich geschützt, und gegen Unternehmen, die im Besitz dieser geschützten Daten sind, können harte Geldstrafen verhängt werden.
• In einem herkömmlichen Rechenzentrum werden Datenverwaltungstechniken in der Regel für einen gesamten Datenbestand implementiert, in der Regel nur einmal, und zwar unter Verwendung einer einzigen Compliance-Richtlinie, die aufgrund neuer oder geänderter gesetzlicher Bestimmungen plötzlich veraltet sein kann. Darüber hinaus macht die von einigen Edge-Vorrichtungen erzeugte Datenmenge (z. B. 5 TB/Stunde) die Anwendung effizienter Compliance-Richtlinien nicht skalierbar.
• Im Allgemeinen werden die aktuellen Compliance-Richtlinien, wie z. B. der Datenschutz, durch die Verarbeitung aller Dateien angewandt, um die Einhaltung zu gewährleisten. Diese Richtlinien verwenden in der Regel eine Reihe von vordefinierten Suchkriterien, um mögliche Verletzungen der Privatsphäre zu erkennen. Dieser Ansatz ist für datenintensive Umgebungen wie autonome Fahrzeuge ineffizient und nicht skalierbar. Derzeit kann ein autonomes Fahrzeug mit seinen Sensoren bis zu 5 TB/Stunde an Daten sammeln. In Kombination mit anderen mobilen Edge-Vorrichtungen kann die Geschwindigkeit, mit der Sensordaten generiert werden, die Standardverarbeitungskanäle überschwemmen, ebenso wie zusätzliche Datenmanagement-Analysen, die die Einhaltung von Vorschriften erzwingen.
• Darüber hinaus handelt es sich bei den aktuellen Compliance-Lösungen um starre, einmalige Implementierungen, die sich nicht schnell an die ständigen Änderungen und Weiterentwicklungen der Datenschutzbestimmungen anpassen lassen. So kann beispielsweise ein autonomer Krankenwagen in den Vereinigten Staaten Daten sammeln, die sowohl den Vorschriften des Verkehrsministeriums als auch dem Health Insurance Portability and Accountability Act (HIPAA) unterliegen. Außerdem können die Datenschutzbestimmungen von Staat zu Staat und von Land zu Land unterschiedlich sein. Ein autonomes Fahrzeug, das Staats- oder Landesgrenzen überquert, muss seine Datenverarbeitung in Echtzeit anpassen, um den Vorschriften des neuen Standorts zu entsprechen. Eine starre, einmalige Implementierung kann in diesen und anderen Szenarien zu einem Haftungsrisiko für die Einhaltung der Vorschriften führen.
• Moderne Datenkonformitätstechniken können auch die Anwendungsentwicklung behindern und Probleme bei der Bereitstellung verursachen. In der Regel werden bei diesen Techniken Daten entweder in Silos gespeichert oder unverarbeitete Daten ganz gelöscht. Solche Maßnahmen können eine erhebliche Belastung für die auf der Datenverarbeitung basierende Kompetenzentwicklung eines Unternehmens darstellen.
• Ein bedarfsgesteuertes System zur Einhaltung der Privatsphäre 10100 für autonome Fahrzeuge, wie in 101 gezeigt, löst viele der oben genannten Probleme (und mehr). Diese Ausführungsformen reichern Daten, die von einem Fahrzeug erfasst oder auf andere Weise gewonnen werden, an, indem sie den Daten beschreibende Tags beifügen. Mit Hilfe von Tags werden verschiedene Attribute festgelegt, die zur subjektiven Definition der für die Einhaltung der Vorschriften erforderlichen Datenschutzbestimmungen verwendet werden können. In mindestens einer Ausführungsform sind die Tags flach und können von Menschen leicht zugewiesen und verstanden werden. Sie können verwendet werden, um verschiedene Aspekte der Daten zu beschreiben, z. B. Standort, Qualität, Tageszeit und/oder Nutzung. Zumindest einige der hier beschriebenen Ausführungsformen umfassen auch die automatische Zuweisung von Tags mithilfe von maschinellem Lernen auf der Grundlage des tatsächlichen Inhalts der Daten, z. B. der Objekte in einem Bild, des aktuellen Standorts und/oder der Tageszeit.
• Bei einigen Modellen wird auch ein „lazy“ On-Demand-Konzept zur Einhaltung der Datenschutzbestimmungen angewandt. Bei einem lazy On-Demand-Ansatz wird die Verarbeitung von Daten zur Anwendung von Datenschutzrichtlinien so weit wie möglich aufgeschoben, bis die Daten tatsächlich in einer Situation verwendet werden, die den Datenschutz beeinträchtigen könnte. Die in autonomen Fahrzeugen gesammelten Daten werden häufig für maschinelles Lernen (ML) verwendet. Beim maschinellen Lernen wird Sampling in der Regel auf Daten angewandt, um Trainings- und Testdatensätze zu erzeugen. Angesichts der großen Datenmengen, die von einem einzigen autonomen Fahrzeug gesammelt werden, gewährleistet die Verarbeitung dieser Abtastwertdatensätze zur Anwendung von Datenschutzrichtlinien auf Abruf eine bessere Nutzung der Computerressourcen. Darüber hinaus können die Daten anhand von Tags für die Indizierung und/oder Speicherung ausgewählt werden, was ebenfalls die Ressourcennutzung optimiert.
• Das System 10100 zur Einhaltung des Datenschutzes auf Abruf bietet mehrere Vorteile. Das System umfasst eine rechnereffiziente und kontextgesteuerte Compliance-Richtlinien-Engine, die entweder im Fahrzeug (dem mobilen Endgerät) oder in einem Rechenzentrum/einer Cloud-Infrastruktur ausgeführt werden kann. Der Nutzen der Fahrzeugdatenerfassung wird durch die Verwendung von Tags erhöht, die im Gegensatz zu strukturierten Metadaten flach und leicht zuzuordnen sind und von Menschen, sowohl technischen als auch nicht-technischen, verstanden werden können. Die Verwendung von Tags in den hier beschriebenen Ausführungsformen stellt sicher, dass die richtigen Prozesse zur Einhaltung des Datenschutzes für die richtigen Datensätze ausgeführt werden, ohne dass jedes Bild oder jede Datei in einem Datensatz untersucht werden muss. Dadurch können erhebliche Ressourcen im Rechenzentrum eingespart werden. Diese Tags stellen sicher, dass die Fahrzeugdaten nicht gegen die Datenschutzbestimmungen verstoßen. Auf diese Weise bleiben Unternehmen (z. B. Konzerne, Dienstleister, Fahrzeughersteller usw.), die Fahrzeugdaten verwenden, speichern oder verarbeiten, im Einklang mit den einschlägigen Vorschriften und gesetzlichen Bestimmungen. Dadurch kann verhindert werden, dass solche Einrichtungen mit erheblichen Geldstrafen belegt werden. Wenn sich die Vorschriften ändern, können die hierin umfassten Ausführungsformen diesen Änderungen angepasst werden, ohne dass wesentliche Codeänderungen oder eine Neuimplementierung des Systems erforderlich sind. Vorschriften können sich ändern, z. B. wenn Aufsichtsbehörden Datenschutzvorschriften hinzufügen oder aktualisieren, wenn ein Fahrzeug ein Gebiet verlässt, das einer Aufsichtsbehörde unterliegt, und in ein Gebiet einfährt, das einer anderen Aufsichtsbehörde unterliegt (z. B. beim Überqueren von Staatsgrenzen, beim Überqueren von Landesgrenzen usw.). Durch die Einhaltung gesetzlicher Vorschriften können die hierin beschriebenen Ausführungsformen auch das Vertrauen in die von Fahrzeugen (und anderen Edge-Vorrichtungen) gesammelten Daten und deren Verwaltungslebenszyklus erhöhen. Zusätzlich zu den Datenschutzgarantien ermöglichen die Ausführungsformen die Rückverfolgbarkeit zu Prüfungs- und Berichtszwecken. Darüber hinaus kann der hier beschriebene modulare, erweiterbare Rahmen neue, innovative Prozesse umfassen.
• Bezug nehmend nun auf 101 umfasst das System 10100 zur Einhaltung des Datenschutzes auf Abruf ein Cloud-Verarbeitungssystem 10110, ein Fahrzeug 10150 und ein Netzwerk 10105, das die Kommunikation zwischen dem Fahrzeug 10150 und dem Cloud-Verarbeitungssystem 10110 ermöglicht. Das Cloud-Verarbeitungssystem 10110 umfasst ein Cloud-Fahrzeugdatensystem 10120, eine Datenaufnahmekomponente 10112 für den Empfang von Fahrzeugdaten, Cloud-Richtlinien 10114 und mit Tags versehene indizierte Daten 10116. Das Fahrzeug 10150 umfasst ein Fahrzeugdatensystem 10140, Edge Policies 10154, einen Datensammler 10152 und zahlreiche Sensoren 10155A-10155F. Elemente von 101 umfassen auch geeignete Hardwarekomponenten, einschließlich, aber nicht notwendigerweise beschränkt auf Prozessoren (z. B. 10117, 10157) und Speicher (z. B. 10119, 10159), die in zahlreichen verschiedenen Ausführungsformen implementiert werden können.
• Im Fahrzeug 10150 kann der Datensammler 10152 nahezu kontinuierliche Daten von den Sensoren 10155A-10155F empfangen. Zu den Sensoren kann jede hier beschriebene Art von Sensor gehören, einschließlich Bildaufnahmegeräten zur Erfassung von Standbildern (z. B. Fotos) und bewegten Bildern (z. B. Videos). Die gesammelten Daten können zumindest vorübergehend im Datensammler 10152 gespeichert und dem Randfahrzeugdatensystem 10140 zur Verfügung gestellt werden, um Tags und Randrichtlinien 10154 auf die aus den gesammelten Daten gebildeten Datensätze anzuwenden. Ein Tag kann ein beliebiges vom Benutzer erzeugtes Wort sein, das dazu beiträgt, Webinhalte zu organisieren, sie auf eine leicht verständliche Weise zu kennzeichnen und für die Suche zu indizieren. Die Edge-Policies 10154 können auf der Grundlage der Tags auf einen Datensatz angewendet werden. Eine Richtlinie ordnet ein oder mehrere Tags, die mit einem Datensatz verbunden sind, einem oder mehreren Prozessen zu. Prozesse werden als Entitäten erster Klasse im Systementwurf definiert, die eine Art von Veränderung des Datensatzes vornehmen, um den Zugang zu personenbezogenen Informationen zu verhindern.
• In zumindest einigen Szenarien werden Datensätze von Fahrzeugdaten, die vom Fahrzeug gesammelt wurden, dem Cloud-Fahrzeugdatensystem 10120 im Cloud-Verarbeitungssystem 10110 zur Verfügung gestellt, um Cloud-Richtlinien 10114 auf die Datensätze basierend auf ihren Tags anzuwenden. In diesem Szenario können die vom Fahrzeug gesammelten Daten zu Datensätzen zusammengestellt, mit Tags versehen und an die Datenaufnahmekomponente 10112 weitergeleitet werden, die dann die Datensätze an das Cloud-Fahrzeugdatensystem 10120 weiterleitet, damit die Cloud-Richtlinien 10114 auf die Datensätze basierend auf ihren Tags angewendet werden können. In mindestens einer Ausführungsform können die Cloud-Richtlinien 10114, die auf die Datensätze eines bestimmten Fahrzeugs (z. B. 10150) angewendet werden, dieselben Richtlinien sein, die vom Edge-Fahrzeugdatensystem 10140 auf die Datensätze angewendet würden, wenn die Datensätze im Fahrzeug verblieben. Zumindest in einigen Szenarien kann das Cloud-Fahrzeugdatensystem 10120 die Daten auch mit Tags versehen (oder mit zusätzlichen Tags, die die bereits vom Edge-Fahrzeugdatensystem 10140 angebrachten Tags ergänzen). Zumindest in einigen Ausführungsformen kann die Kennzeichnung dort erfolgen, wo sie am effizientesten durchgeführt werden kann. So gibt es zwar Techniken, die eine geografische Kennzeichnung (Geo-Tagging) in der Cloud ermöglichen, doch wird diese häufig von einem Fahrzeug vorgenommen, da die Bildaufnahmegeräte über globale Positionierungssysteme verfügen und Echtzeitinformationen über den Standort der Objekte liefern können.
• Bezug nehmend nun auf 102, 102 zeigt eine Darstellung der von einem Fahrzeug gesammelten Daten 10210 und der Objekte, die definiert wurden, um die Einhaltung des Datenschutzes für die Daten zu gewährleisten. Zu den Objekten gehören ein oder mehrere Tags 10220, eine oder mehrere Richtlinien 10230 und ein oder mehrere Prozesse 10240. In mindestens einer Ausführungsform kann es sich bei den Daten 10210 um einen Datensatz handeln, der eine oder mehrere Dateien, Bilder, Videoframes, Aufzeichnungen oder ein beliebiges Objekt umfasst, das Informationen in einem elektronischen Format umfasst. Im Allgemeinen ist ein Datensatz eine Sammlung zusammenhängender Informationsmengen, die aus separaten Elementen (z. B. Dateien, Bilder, Videoframes usw.) bestehen.
• Ein Tag, wie z. B. Tag 10220, kann ein Metadatum zur Charakterisierung von Daten sein. Ein Tag kann das Datenformat (z. B. Video usw.), die Qualität (z. B. niedrige Auflösung usw.), den Ort (z. B. USA, Europäische Union usw.), das Gebiet (z. B. Autobahn, ländlich, vorstädtisch, Stadt usw.), die Verkehrsbelastung (z. B. leicht, mittel, schwer usw.), das Vorhandensein von Menschen (z. B. Fußgänger, Radfahrer, Fahrer usw.) und andere für die Daten relevante Informationen angeben. Ein Tag kann ein beliebiges vom Benutzer erzeugtes Wort sein, das dazu beiträgt, Webinhalte zu organisieren, sie auf eine leicht verständliche Weise zu kennzeichnen und für die Suche zu indizieren. In einigen Ausführungsformen können ein oder mehrere Tags manuell zugewiesen werden. Zumindest einige Tags können mithilfe von maschinellem Lernen automatisch zugewiesen werden. So kann beispielsweise ein neuronales Netz trainiert werden, um verschiedene Merkmale der gesammelten Daten zu erkennen und jeden Datensatz entsprechend zu klassifizieren. So kann beispielsweise ein neuronales Faltungsnetzwerk (CNN) oder ein Support-Vector-Machine-Algorithmus (SVM) verwendet werden, um Bilder oder Videobilder in einem Datensatz zu identifizieren, die auf einer Autobahn oder in einem Vorort aufgenommen wurden. Bei Letzteren ist die Wahrscheinlichkeit höher, dass sie Bilder von Fußgängern und Privatgrundstücken umfassen und möglicherweise den Datenschutzbestimmungen unterliegen. Der Datensatz kann als „vorstädtisch“ eingestuft und mit einer entsprechenden Kennzeichnung versehen oder anderweitig mit dem Datensatz verknüpft werden.
• Ein Prozess, wie z. B. Prozess 10240, kann eine Betätigungsaktion sein, die als REST-Anwendungsprogrammierschnittstelle (API) definiert ist, die als Eingabe einen Datensatz nimmt und eine Verarbeitung auf den Datensatz anwendet, die zu einem neuen Datensatz führt. Beispiele für solche Verfahren sind unter anderem die Anwendung eines Datenanonymisierungsskripts auf personenbezogene Daten (z. B. GPS-Standort usw.), die Unschärfe personenbezogener Daten oder Bilder (z. B. Gesichter, Nummernschilder, private oder sensible Immobilienadressen usw.), die Verpixelung sensibler Daten und die Schwärzung sensibler Daten.
• Prozesse werden im Systementwurf als Entitäten erster Klasse definiert. In mindestens einer Ausführungsform können die Prozesse typischerweise Anonymisierung, Änderung, Berichtigung, Komprimierung, Speicherung usw. sein. Dies ermöglicht einen modularen Aufbau der Pipeline, bei dem die Prozesse leicht einsteckbar, austauschbar und nachvollziehbar sind. Auf diese Weise lassen sich Datenänderungen nachverfolgen und die Einhaltung von Vorschriften überprüfen. Darüber hinaus erleichtert dieser modulare Aufbau der Pipeline die Einführung neuer Datenschutzverfahren, wenn neue Vorschriften erlassen oder bestehende Vorschriften aktualisiert werden.
• Eine Richtlinie, wie z. B. Richtlinie 10230, ordnet ein oder mehrere Tags einem oder mehreren Prozessen zu. So könnte beispielsweise ein Datensatz, der wie oben beschrieben mit „vorstädtisch“ gekennzeichnet ist, einer Richtlinie unterliegen, die die Kennzeichnung „vorstädtisch“ mit einem Datenschutzprozess zur Anonymisierung (z. B. Unschärfe, Schwärzung, Verpixelung usw.) von Gesichtern von Personen und Informationen über Privateigentum verbindet. Die Kennzeichnung ermöglicht es in diesem Fall, die richtigen Prozesse auf der Grundlage der Art des Datensatzes und der potenziellen Auswirkungen auf die Privatsphäre, die er umfasst, mit dem richtigen Datensatz abzustimmen.
• 103 zeigt eine beispielhafte Richtlinienvorlage 10310 für das System 10100 zur Einhaltung des Datenschutzes auf Abruf gemäß mindestens einer Ausführungsform. Die Richtlinienvorlage 10310 umfasst ein „Lazy“-Attribut 10312, das die Richtlinie als „On-Demand“-Richtlinie definiert, deren Anwendung aufgeschoben und erst auf Anforderung angewendet wird. Genauer gesagt wird die Richtlinie erst dann angewandt, wenn der Datensatz in einer Situation verwendet werden soll, die möglicherweise die Privatsphäre beeinträchtigen könnte. Wenn festgestellt wird, dass es sich um eine „Lazy Policy“ handelt, wird der Datensatz für eine spätere Verarbeitung markiert. Bevor ein markierter Datensatz (z. B. Bilder) für das maschinelle Lernen abgetastet wird, kann die Richtlinie beispielsweise angewendet werden, um Gesichter in den Bildern des Datensatzes zu verwischen.
• Die Richtlinienvorlage 10310 umfasst auch eine Bedingung 10314, die durch die Konjunktion oder Disjunktion von Tags angezeigt wird. So können in Bedingung 10314 ein oder mehrere Tags mit gewünschten Konjunktionen und/oder Disjunktionen verwendet werden. Beispiele für Tags sind u. a. Fußgänger, Nacht, Tag, Autobahn, Land, Vorstadt, Stadt, USA, EU, Asien, niedrige Auflösung, hohe Auflösung, geografischer Standort (Geo) sowie Datum und Uhrzeit.
• Die Richtlinienvorlage 10310 umfasst außerdem eine Aktion 10316, die einen einzelnen Prozess oder die Verbindung von Prozessen angibt, die auf einem Datensatz ausgeführt werden sollen, wenn die Bedingung aus den Tags auf dem Datensatz erfüllt ist. Wie in 103 gezeigt könnte eine Beispielbedingung sein: Hochauflösend UND Fußgänger UND (USA ODER Europa), und eine beispielhafte Kombination von Prozessen ist ausgebildet, Gesichter unscharf zu machen und die Daten zu komprimieren. Diese Beispielrichtlinie gilt also für einen Datensatz, der den Tags zufolge hochauflösende Daten und Fußgänger umfasst und entweder in den USA oder in Europa erhoben wird. Wenn der Datensatz diese Kombination von Tags erfüllt, werden ein oder mehrere Verfahren angewandt, um die Gesichter von Fußgängern in den Bildern unscharf zu machen und die Daten zu komprimieren.
• 104 ist ein vereinfachtes Blockdiagramm zur Veranschaulichung möglicher Komponenten und eines allgemeinen Betriebsablaufs eines Fahrzeugdatensystems 10400. Das Fahrzeugdatensystem 10400 kann für ein Cloud-Fahrzeugdatensystem (z. B. 10120) und/oder ein Edge-Fahrzeugdatensystem (z. B. 10140) stehen. Das Fahrzeugdatensystem 10400 umfasst eine Segmentierungs-Engine 10410, eine Tagging-Engine 10420 und eine Richtliniendurchsetzungs-Engine 10430. Das Fahrzeugdatensystem 10400 gewährleistet die Einhaltung des Datenschutzes für Daten, die von an einem autonomen Fahrzeug (z. B. 10150) angebrachten Sensoren (z. B. 10155A-10155F) gesammelt wurden, indem es Datensätze des Fahrzeugs kennzeichnet und Richtlinien auf die Datensätze anwendet, die auf den an den Datensätzen angebrachten Kennzeichnungen basieren.
• Das Segmentierungsmodul 10410 kann neue Daten 10402 empfangen, die von einem Datensammler (z. B. 10152) eines Fahrzeugs (z. B. 10150) erfasst werden. Das Segmentierungsmodul 10410 kann einen Segmentierungsprozess für neue Daten 10402 durchführen, um Datensätze aus den neuen Daten zu bilden. So können die neuen Daten beispielsweise in Datensätze unterteilt werden, die jeweils eine Sammlung zusammengehöriger Informationsgruppen umfassen. So kann ein Datensatz beispielsweise Daten umfassen, die mit einem bestimmten Tag, einem geografischen Ort usw. verbunden sind. Die Segmentierung kann auch spezifisch für eine Anwendung sein. In mindestens einer Ausführungsform können die Tags pro Datensatz angebracht werden.
• Die Tagging-Engine 10420 kann ein maschinelles Lernmodell 10422 umfassen, das Tags 10424 für Datensätze ausgibt. Das Modell 10422 für maschinelles Lernen kann so trainiert werden, dass es auf der Grundlage der eingegebenen Daten geeignete Tags erkennt. Bei Bildern oder Videobildern einer Autobahn, einer Vorstadtstraße, einer Stadtstraße oder einer Landstraße kann das Modell 10422 beispielsweise geeignete Tags wie „Autobahn“, „Vorstadt“, „Stadt“ oder „Landstraße“ erkennen. Beispiele für geeignete maschinelle Lerntechniken, die verwendet werden können, sind unter anderem ein Faltungsneuronales Netzwerk (CNN) oder ein Support-Vector-Machine-Algorithmus (SVM). In einigen Beispielen kann ein einziges maschinelles Lernmodell 10422 ein oder mehrere Tags für jeden Datensatz erzeugen. In anderen Ausführungsformen können ein oder mehrere maschinelle Lernmodelle in der Tagging-Engine verwendet werden, um verschiedene Tags zu identifizieren, die auf einen Datensatz anwendbar sein könnten.
• Die Richtliniendurchsetzungs-Engine 10430 kann einen Richtlinienselektor 10432, Richtlinien (Policies) 10434 und eine Verarbeitungswarteschlange 10439 umfassen. Der Richtlinienselektor 10432 kann getaggte Datensätze von der Tagging-Engine 10420 empfangen. Richtlinien 10434 stellen Edge-Richtlinien (z. B. 10154) dar, wenn das Fahrzeugdatensystem 10400 in einer Edge-Vorrichtung (z. B. Fahrzeug 10150) implementiert ist, oder Cloud-Richtlinien (z. B. 10113), wenn das Fahrzeugdatensystem 10400 in einem Cloud-Verarbeitungssystem (z. B. 10110) implementiert ist. Der Richtlinienselektor 10432 erkennt die ein oder mehreren Tags in einem Datensatz und identifiziert bei 10433 eine oder mehrere Richtlinien auf der Grundlage der erkannten Tags. Eine Richtlinie legt fest, welches Verfahren in welchem Fall anwendbar ist. Eine Richtlinie kann beispielsweise vorsehen, dass bei allen Bildern, die als USA gekennzeichnet sind, die Nummernschilder unscharf dargestellt werden.
• Wie in 10435 gezeigt, bestimmt der Richtlinienselektor 10432, ob die identifizierte(n) Richtlinie(n) als faule Richtlinien bezeichnet werden. Wenn eine Richtlinie, die für einen Datensatz auf der Grundlage der Tags des Datensatzes identifiziert wird, als faul bezeichnet wird, dann wird der Datensatz für die Verarbeitung auf Abruf markiert, wie in 10436 gezeigt. Dementsprechend wird die „Lazy Policy“ nicht sofort auf den Datensatz angewendet. Vielmehr wird der Datensatz mit der Richtlinie gespeichert, bis der Datensatz abgefragt, gelesen, kopiert oder auf eine andere Weise zugegriffen wird, die die Vertraulichkeit des Inhalts des Datensatzes gefährden könnte. Wenn beispielsweise eine identifizierte Richtlinie einen Prozess zum Unscharfmachen von Gesichtern in Bildern angibt und als „Lazy Policy“ bezeichnet wird, dann werden alle Bilder im Datensatz nicht sofort verarbeitet, um Gesichter unscharf zu machen, sondern der Datensatz wird für die Verarbeitung auf Abruf markiert und gespeichert. Wenn anschließend auf den Datensatz zugegriffen wird, kann der Datensatz zur Verarbeitungswarteschlange 10439 hinzugefügt werden, um die identifizierte Richtlinie auf unscharfe Gesichter in den Bildern des Datensatzes anzuwenden. Sobald die Richtlinie angewandt wird, kann einer Zugriffsanfrage auf den Datensatz stattgegeben werden.
• Wenn eine Richtlinie, die für einen Datensatz auf der Grundlage der Tags des Datensatzes identifiziert wird, nicht als faul bezeichnet wird, dann wird der Datensatz zu einer Verarbeitungswarteschlange 10439 hinzugefügt, wie in 10438 angegeben. Die ermittelte Strategie wird dann auf den Datensatz angewendet. Wenn beispielsweise eine identifizierte Richtlinie für einen Datensatz einen Prozess zur Verschlüsselung von Daten in einer Datei angibt und nicht als „Lazy Policy“ bezeichnet wird, wird der Datensatz zur Verschlüsselung des Datensatzes zur Verarbeitungswarteschlange 10439 hinzugefügt. Wenn dem Datensatz keine Richtlinien zugeordnet und als faul gekennzeichnet sind, wird die Richtlinie, sobald alle Richtlinien auf den Datensatz angewendet (z. B. verschlüsselt) wurden, den richtlinienkonformen Daten 10406 hinzugefügt, auf die ohne weitere Verarbeitung der Datenschutzrichtlinien zugegriffen werden kann.
• Einige der Funktionen des Fahrzeugdatensystems 10400 können in einem Randgerät (z. B. Fahrzeug 10150) implementiert werden, um den Datenfluss zu optimieren. So können beispielsweise Datenschutzfilter am Rande angewendet werden, um zu verhindern, dass sensible Daten in einer Cloud (z. B. 10110) gespeichert werden, und so die Einhaltung der Regeln zur Datenminimierung zu gewährleisten, wie sie durch die jüngsten Vorschriften wie die Allgemeine Datenschutzverordnung der Europäischen Union (GDPR) durchgesetzt wurden. So kann beispielsweise eine Datenschutzrichtlinie festgelegt werden, um Standortdaten zu anonymisieren, indem GPS-Koordinaten durch weniger präzise Standortdaten wie die Stadt ersetzt werden. Diese Richtlinie kann als eine nicht lasche Richtlinie definiert werden, die auf alle Standortdaten im Fahrzeug (Edge) angewendet wird, um zu verhindern, dass genaue Standorte an die Cloud gesendet werden.
• In mindestens einer Ausführungsform können kontextbezogene Richtlinien verwendet werden, um die Verarbeitung im Fahrzeug auf der Grundlage von Echtzeitereignissen oder anderen Informationen zu beeinflussen, die den markierten Datensätzen zusätzlichen Kontext verleihen. Zur Veranschaulichung, aber nicht als Einschränkung, werden nun zwei Beispiele beschrieben. Ein erstes Beispiel: In vielen Ländern gibt es ein System, bei dem ein Alarm (z. B. der AMBER-Alarm in den USA) ausgelöst wird, wenn ein Kind gefährdet ist. Diese kontextbezogene Kindersicherheitsrichtlinie kann in einem gezielten geografischen Bereich, z. B. in einem dynamischen Suchradius um den Vorfall, an Fahrzeuge übermittelt werden, deren Besitzer sich für dieses AMBER-Warnsystem entschieden haben. Für Daten, die mit „Autobahn“ gekennzeichnet sind, wird unter einer AMBER-Alarm-ähnlichen Bedingung die „Lazy“-Richtlinie auf „Nein“ gesetzt, und die Daten werden zur Echtzeitverarbeitung von Nummernschildern mit optischer Zeichenerkennung (OCR), der Fahrzeugfarbe, falls vorhanden, und der Fahrzeugbeschreibung, falls vorhanden, an die Maschine für maschinelles Lernen im Fahrzeug gesendet. In diesem Szenario werden zur Wahrung der Privatsphäre der „Massenfahrzeuge“ nur die GPS-Informationen, die im Rahmen von „Anfangs- und Endtreffern“ gewonnen wurden, an die Strafverfolgungsbehörden übermittelt, die die Pings oder Treffer aus der „Menge der Fahrzeuge“ um den Akteur und das Fahrzeug, das Gegenstand des AMBER-Alarms ist, triangulieren können.
• In einem zweiten, nicht einschränkenden Beispiel für die Anwendung kontextbezogener Richtlinien können mikrogeografische Regionen für kontextbezogene Richtlinien ausgewählt werden. In einigen Städten konzentrieren sich beispielsweise große Gruppen von Obdachlosen in der Nähe von öffentlichen Parks und an der Seite oder an der Unterseite von Autobahnauffahrten, was zu einzigartigen geografischen Regionen führt, die auf Mikroziele ausgerichtet sind. Für diese lokalisierten Mikroregionen könnte eine kontextbezogene Politik oder Funktion lauten: „Die Wahrscheinlichkeit, dass Menschen vorkommen, ist hoch“. Auch wenn ein Datensatz als „Autobahn“ oder „Schnellstraßenrampe“ gekennzeichnet ist und die entsprechende Richtlinie für diese Kennzeichnungen als „Lazy Policy“ bezeichnet werden kann, könnte eine kontextbezogene Richtlinie die „lazy“-Verarbeitung außer Kraft setzen und die Daten an das bordeigene Fahrzeugdatensystem (z. B. 10400) zur Verarbeitung für Menschen/Fußgänger weiterleiten. Während die Menschen/Fußgänger möglicherweise nicht als auf der Straße befindlich erkannt werden, kann es in der Nähe von Autobahnen häufiger vorkommen, dass einzelne Personen ohne Vorwarnung über die Straße springen. Die Erkennung von Menschen/Fußgängern könnte dem Entscheidungsverarbeitungssystem im Fahrzeug signalisieren, eine langsamere Geschwindigkeit zu wählen, um dem Fahrzeug Zeit zum Reagieren zu geben, als es sonst gerechtfertigt wäre.
• Das Fahrzeugdatensystem 10400 kann sowohl in Forschungs- und Entwurfssystemen eingesetzt werden, in denen große Datenmengen von Fahrzeugen gesammelt werden, um maschinelle Lernmodelle zu erstellen, als auch in operativen Systemen, in denen Daten von Fahrzeugen gesammelt werden, um kontinuierlich hochauflösende Karten zu aktualisieren, Verkehrsstaus zu verfolgen oder Modelle neu zu trainieren, wenn neue Anwendungsfälle auftreten. In einem Forschungs- und Entwurfssystem kann das Maschinelles-Lernen-Modell 10414 kontinuierlich mit Testdaten trainiert werden, um zu lernen, wie man Datensätze mit geeigneten Tags klassifiziert. Die Testdaten können reale Daten von Testfahrzeugen umfassen.
• Kennzeichnung, Richtlinien und Verarbeitung im Fahrzeugdatensystem 10400 werden verwendet, um einen hocheffizienten Durchsetzungsworkflow zu schaffen, der leicht in den Rahmen der Nutzung von Rechenressourcen des Fahrzeugs integriert werden kann. In Fahrzeugen mit mehr als 150 elektronischen Steuergeräten, 1-2 ADAS-/AV-Motoren und einem zentralen Server-Controller ist es möglich, die Verarbeitung je nach Verfügbarkeit der Rechenleistung und den entsprechenden Richtlinien an verschiedene Recheneinheiten zu verteilen.
• Bezug nehmend nun auf 105, 105 veranschaulicht Merkmale und Aktivitäten 10500 eines Edge- oder Cloud-Fahrzeugdatensystems 10400 aus der Perspektive verschiedener möglicher menschlicher Akteure und Hardware- und/oder Softwareakteure. In mindestens einem Beispiel bezieht sich das Tagging 10550 auf die Anwendung geeigneter Tags (z. B. Fußgänger, Autobahn, Landstraße, Vorstadt, Stadt, GPS-Standort usw.) auf Datensätze. In mindestens einer Ausführungsform kann das automatische Taggen von Datensätzen 10412 von derTagging-Engine 10420 durchgeführt werden. Wie bereits beschrieben, kann ein maschinelles Lernmodell der Tagging-Engine 10420 (z. B. CNN, SVM) trainiert werden, um Bilder und andere Informationen in den von Fahrzeugen gesammelten Daten zu erkennen und Tags auszugeben, die auf die Eingangsdaten zutreffen. Die manuelle Kennzeichnung kann auch (oder alternativ) in einem Fahrzeugdatensystem verwendet werden. Zum Beispiel kann ein Datenanbieter 10538 Tags 10515 definieren, Tags 10517 aktualisieren und eine manuelle Datensatzkennzeichnung 10519 durchführen.
• Ein Datenwissenschaftler 10536 kann Tags 10515 definieren und Tags 10517 aktualisieren, und zusätzlich kann er Modelle 10512 definieren und Modelle 10513 aktualisieren. Modelle des maschinellen Lernens, wie CNN oder SVM, können so trainiert werden, dass sie zwischen den Inhalten von Datensätzen unterscheiden können, um geeignete Tags auszuwählen. Beispielsweise kann ein Modell so trainiert werden, dass es zwischen Bildern von Autobahnen und Landstraßen und Bildern von Vorstadtstraßen und städtischen Straßen unterscheidet. Auf Bildern von Straßen in Vororten und in der Stadt sind wahrscheinlich mehr Fußgänger zu sehen, bei denen Datenschutzrichtlinien zur Unkenntlichmachung von Gesichtern angewandt werden sollten. Dementsprechend kann in einem Beispiel ein trainiertes CNN- oder SVM-Modell von der Tagging-Engine 10420 verwendet werden, um einen Datensatz von Bildern als „Autobahn“, „ländlich“, „Stadt“ oder „Vorstadt“ zu klassifizieren. Die Tagging Engine 10420 kann die Tags automatisch an den Datensatz anhängen.
• Für die Durchsetzung von Richtlinien 10560 kann ein Dateningenieur 10534 Prozesse 10525 und Aktualisierungsprozesse 10527 definieren. Beispielsweise kann ein erster Prozess so definiert werden, dass Gesichter in einem Bild unscharf werden, ein zweiter Prozess kann so definiert werden, dass Nummernschilder von Autos unscharf werden, ein dritter Prozess kann so definiert werden, dass GPS-Koordinaten durch weniger präzise Standortinformationen ersetzt werden, ein vierter Prozess kann so definiert werden, dass Daten verschlüsselt werden. Ein Dateneigentümer 10532 kann Richtlinien 10521 definieren und Richtlinien 10523 aktualisieren. Eine Richtlinie kann beispielsweise durch die Auswahl einer bestimmten Bedingung (z. B. Konjunktion oder Disjunktion von Tags) und die Zuweisung einer Aktion (z. B. Konjunktion von Prozessen) zu dieser Bedingung definiert werden. Die Richtlinie kann mit Datensätzen verknüpft werden, die die Bedingung erfüllen. Die durch die Richtlinie festgelegte Aktion ist für die markierten Datensätze entweder sofort oder bei Bedarf durchzuführen, wenn die Richtlinie als „träge“ Richtlinie bezeichnet wird, wie hierin weiter beschrieben.
• Die Richtliniendurchsetzungs-Engine 10430 kann eine Richtlinie 10504 in Echtzeit durchsetzen, wenn die Richtlinie nicht als „lazy“ bezeichnet wird, und kann eine Richtlinie on-demand 10502 durchsetzen, wenn die Richtlinie als „lazy“ bezeichnet wird. Ein Datenkonsument 10540, der einen Datensatz konsumiert (z. B. den Zugriff auf einen Datensatz anfordert), kann die Richtliniendurchsetzungs-Engine 10430 veranlassen, eine mit dem Datensatz verbundene Richtlinie durchzusetzen. Dies kann der Fall sein, wenn der Datensatz für die bedarfsgesteuerte Verarbeitung markiert ist, weil eine mit dem Datensatz verknüpfte Richtlinie als „Lazy Policy“ bezeichnet wird.
• 106 ist ein Beispiel für die Portalanzeige 10600 eines On-Demand-Systems zur Einhaltung des Datenschutzes für die Erstellung von Richtlinien für von autonomen Fahrzeugen gesammelte Daten. Auf dem Portalbildschirm 10600 können Richtlinien erstellt und optional als „faul“ gekennzeichnet werden. In einem Beschreibungsfeld 10602 kann ein Benutzer eine Beschreibung einer Richtlinie eingeben, z. B. „Nummernschilder verwischen“. Ein Tag-Auswahlfeld 10604 ermöglicht es dem Benutzer, Tags auszuwählen, die als Bedingung für die Richtlinie verwendet werden sollen. Ein Abruffeld 10606 kann von einem Benutzer ausgewählt werden, um die Richtlinie als „faul“ zu kennzeichnen. Ist das Kästchen nicht angekreuzt, wird die Richtlinie nicht als „faul“ eingestuft. Eine Richtlinienbeschreibungstabelle 10608 gibt Aufschluss darüber, welche Richtlinien als „lazy“ und welche nicht als „lazy“ eingestuft sind. Zum Beispiel im Beispiel von 106 wird eine Richtlinie zur Unschärfe von Gesichtern als „lazy“ (träge) bezeichnet und soll daher bei Bedarf auf Datensätze angewendet werden. In einem anderen Beispiel wird die Richtlinie zum Verwischen von Nummernschildern nicht als „faul“ bezeichnet und daher sofort auf Datensätze angewandt, um Nummernschilder in Bildern des Datensatzes zu verwischen.
• 107 zeigt ein Beispielbild, das von einem Fahrzeug aufgenommen wurde, bevor und nachdem ein Verfahren zum Verwischen von Nummernschildern auf das Bild angewendet wurde. Das Bild 10700A ist ein Bild mit einer nicht verdeckten und entzifferbaren Lizenzstelle 10704A. Ein Verfahren zur Unschärfung des Nummernschildes wird bei 10710 angewendet und führt zu Bild 10700B, das ein verdecktes und nicht entzifferbares Nummernschild 10704B aufgrund einer Unschärfetechnik aufweist, die auf Pixel angewendet wird, die das Nummernschild im Bild darstellen.
• 108 zeigt ein Beispielbild, das von einem Fahrzeug aufgenommen wurde, bevor und nachdem eine Gesichtsverwischungsstrategie auf das Bild angewendet wurde. Bild 10800A ist ein Bild mit einigen ungetrübten und erkennbaren menschlichen Gesichtern (durch weiße Rahmen hervorgehoben). Ein Verfahren zur Unschärfe von Gesichtern wird bei 10810 angewendet und führt zu Bild 10800B, das aufgrund einer auf die Pixel, die die Gesichter im Bild darstellen, angewendeten Unschärfetechnik verdeckte und unerkennbare Gesichter aufweist (hervorgehoben durch weiße Rahmen).
• Bezug nehmend nun auf 109, 109 ist ein vereinfachtes Flussdiagramm, das einen detaillierten möglichen Fluss 10900 von Vorgängen veranschaulicht, die mit der Kennzeichnung von Daten verbunden sind, die an einem Fahrzeug in einem System zur Einhaltung des Datenschutzes auf Abruf, wie dem System 10100, erfasst werden. In mindestens einer Ausführungsform entspricht eine Reihe von Vorgängen den Aktivitäten von 109. Das Fahrzeugdatensystem 10400 kann zumindest einen Teil des Satzes von Operationen verwenden. Das Fahrzeugdatensystem 10400 kann einen oder mehrere Datenprozessoren (z. B. 10127 für ein Cloud-Fahrzeugdatensystem, 10157 für ein Edge-Fahrzeugdatensystem) umfassen, um die Operationen durchzuführen. In mindestens einer Ausführungsform führen das Segmentierungssystem 10410 und das Kennzeichnungssystem 10420 jeweils einen oder mehrere der Vorgänge aus. Zur Erleichterung der Diskussion wird der Ablauf 10900 unter Bezugnahme auf das Randfahrzeug-Datensystem 10140 im Fahrzeug 10150 beschrieben.
• Bei 10902 werden die vom Fahrzeug 10150 gesammelten Daten vom Randfahrzeug-Datensystem 10140 empfangen. Daten können von einer Mehrzahl von Sensoren, einschließlich Bildaufnahmegeräten, durch den Datensammler 10152 im Fahrzeug erfasst werden.
• Bei 10904 wird ein Geostandort des Fahrzeugs ermittelt und bei 10906 können Datum und Uhrzeit bestimmt werden. In einigen Implementierungen kann es wünschenswert sein, dass die Geokennzeichnung und/oder die Datums- und Zeitkennzeichnung am Rande des Fahrzeugs erfolgt, wo die Echtzeitinformationen leicht verfügbar sind, selbst wenn die gesammelten Daten anschließend an ein entsprechendes Cloud-Fahrzeugdatensystem zur zusätzlichen Kennzeichnung und Durchsetzung von Richtlinien gesendet werden. Dementsprechend können die Daten bei 10908 in einen Datensatz segmentiert werden.
• Bei 10910 werden ein oder mehrere Tags an den Daten angebracht, die den Standort des Fahrzeugs und/oder das Datum und die Uhrzeit der Datenerfassung angeben. In diesem Szenario wird die Segmentierung vor dem Anbringen des Tags durchgeführt, und der Geostandort-Tag und/oder der Datums- und Zeit-Tag können auf den Datensatz angewendet werden. In anderen Szenarien kann ein Geostandort-Tag und/oder ein Datums- und Zeit-Tag auf einzelne Dateninstanzen angewendet werden, die anschließend in Datensätze segmentiert und mit dem entsprechenden Geostandort-Tag und/oder Datums- und Zeit-Tag versehen werden.
• Bei 10912 wird ein maschinelles Lernmodell (z. B. CNN, SVM) auf den Datensatz angewendet, um ein oder mehrere Tags zu identifizieren, die dem Datensatz zugeordnet werden sollen. Bei 10914 werden die identifizierten ein oder mehreren Tags mit dem Datensatz verknüpft. Eine Richtlinie kann an einen Datensatz „angehängt“ werden, indem sie mit dem Datensatz gespeichert, ihm angehängt, ihm zugeordnet, mit ihm verknüpft oder anderweitig mit ihm verbunden wird.
• Zumindest in einigen Szenarien kann ein Benutzer (z. B. der Fahrzeugeigentümer oder der Datenlieferant) dem Datensatz manuell eine Kennzeichnung zuweisen. Wenn ein Fahrer zum Beispiel ein Hindernis oder einen Unfall auf der Straße sieht, könnte er die Informationen manuell in das Fahrzeugdatensystem eingeben. Die Tagging-Engine könnte diese Informationen nutzen, um ein neues Tag für einen oder mehrere relevante Datensätze zu erstellen. So können zusätzliche Kontextinformationen manuell und in Echtzeit zu den Daten hinzugefügt werden.
• 110 ist ein vereinfachtes Flussdiagramm, das einen detaillierten möglichen Fluss 11000 von Vorgängen veranschaulicht, die mit der Durchsetzung von Richtlinien in einem System zur Einhaltung des Datenschutzes auf Abruf, wie dem System 10100, verbunden sind. In mindestens einer Ausführungsform entspricht eine Reihe von Vorgängen den Aktivitäten von 110. Ein Fahrzeugdatensystem, wie z. B. das Fahrzeugdatensystem 10400, kann zumindest einen Teil des Satzes von Operationen verwenden. Das Fahrzeugdatensystem 10400 kann einen oder mehrere Datenprozessoren (z. B. 10127 für ein Cloud-Fahrzeugdatensystem, 10157 für ein Edge-Fahrzeugdatensystem) zur Durchführung der Operationen umfassen. In mindestens einer Ausführungsform führt die Richtliniendurchsetzungs-Engine 10430 einen oder mehrere der Vorgänge aus. Zur Erleichterung der Diskussion wird der Ablauf 11000 unter Bezugnahme auf das Randfahrzeug-Datensystem 10140 im Fahrzeug 10150 beschrieben.
• Bei 11002 empfängt eine Richtliniendurchsetzungs-Engine im Edge Vehicle Data System 10140 des Fahrzeugs 10150 einen mit Tags versehenen Datensatz, der vom Fahrzeug gesammelte Daten umfasst. Der Datensatz kann im Anschluss an die in FIG beschriebenen Aktivitäten empfangen werden. 109. Sobald beispielsweise die vom Fahrzeug gesammelten Daten in einen Datensatz segmentiert und von einer Tagging-Engine markiert wurden, wird der markierte Datensatz von der Richtliniendurchsetzungs-Engine empfangen.
• Bei 11004 werden ein oder mehrere mit den Daten verbundene Tags identifiziert. Bei 11006 wird bestimmt, welche Richtlinie auf den Datensatz angewendet werden soll. Erfüllen beispielsweise die mit dem Datensatz verknüpften Tags eine Bedingung einer bestimmten Richtlinie, so ist diese Richtlinie auf den Datensatz anzuwenden. Um 11008 wird die ermittelte Richtlinie mit dem Datensatz verknüpft. Eine Richtlinie kann mit einem Datensatz „assoziiert“ werden, indem sie mit dem Datensatz gespeichert, ihm beigefügt, ihm angehängt, ihm zugeordnet, mit ihm verknüpft oder anderweitig auf geeignete Weise mit ihm verbunden wird.
• Bei 11010 wird festgestellt, ob eine kontextbezogene Richtlinie mit dem Datensatz verbunden ist. Eine kontextbezogene Richtlinie kann eine „Lazy Policy“ und/oder eine Nicht-„Lazy Policy“ außer Kraft setzen. Wenn beispielsweise für ein Fahrzeug eine Kinderwarnmeldung vom Typ AMBER eingeht, könnte eine „Lazy Policy“ für das Unschärfen von Nummernschildern in Datensätzen, die als „Highway“ gekennzeichnet sind, auf „NO“ gesetzt werden. Anstatt jedoch die Nummernschilder im Datensatz sofort zu verwischen, kann OCR verwendet werden, um die Nummernschildinformationen im Datensatz zu erhalten. Wenn eine kontextbezogene Richtlinie anwendbar ist, wird der Datensatz um 11012 in die Verarbeitungswarteschlange aufgenommen, damit die kontextbezogene Richtlinie auf den Datensatz angewendet werden kann. Der Datenfluss kann dann an 11024 weitergeleitet werden, wo der Datensatz als richtlinienkonform markiert und für die spätere Verwendung (z. B. Übermittlung an Strafverfolgungsbehörden usw.) gespeichert wird. In einigen Fällen kann die Verwendung vorübergehend sein, bis die kontextbezogene Richtlinie nicht mehr gültig ist (z. B. wenn der AMBER-Kinderalarm aufgehoben wird). In diesem Szenario kann das System zur Durchsetzung von Richtlinien den Datensatz erneut verarbeiten, um alle nicht-lazy-Richtlinien anzuwenden und den Datensatz für die Verarbeitung auf Abruf zu markieren, wenn irgendwelche lazy-Richtlinien mit dem Datensatz verbunden sind und noch nicht auf den Datensatz angewendet wurden.
• Wenn in 11010 festgestellt wird, dass dem Datensatz keine kontextbezogene Richtlinie zugeordnet ist, kann in 11014 festgestellt werden, ob dem Datensatz irgendwelche nicht-flüssigen Richtlinien zugeordnet sind. Wenn dem Datensatz keine „Non-Lazy“-Richtlinien zugeordnet sind, bedeutet dies, dass dem Datensatz eine oder mehrere „Lazy“-Richtlinien zugeordnet sind, wie in 11016 gezeigt. Das heißt, wenn eine oder mehrere Richtlinien mit dem Datensatz bei 11008 verknüpft sind, und wenn die eine oder mehreren Richtlinien nicht kontextabhängig (bestimmt bei 11010) und nicht nicht-lazy (bestimmt bei 11014) sind, dann sind die Richtlinien lazy. Daher wird der Datensatz um 11018 für die bedarfsgesteuerte Verarbeitung nach dem „Lazy Policy“-Prinzip markiert und gespeichert.
• Wenn bei 11014 festgestellt wird, dass dem Datensatz eine oder mehrere nichtlose Richtlinien zugeordnet sind, wird der Datensatz bei 11020 in die Verarbeitungswarteschlange für die auf den Datensatz anzuwendende(n) nicht-lose(n) Richtlinie(n) aufgenommen. Um 11022 wird festgestellt, ob mit dem Datensatz irgendwelche faulen Richtlinien verbunden sind. Wenn dem Datensatz eine oder mehrere „Lazy Policies“ zugeordnet sind, wird der Datensatz bei 11018 für die bedarfsgesteuerte Verarbeitung von „Lazy Policies“ markiert und gespeichert. Wenn eine oder mehrere „lazy“ (müßige) Richtlinien nicht mit dem Datensatz verbunden sind, wird der Datensatz bei 11024 als richtlinienkonform markiert und für den späteren Zugriff und/oder die Verwendung gespeichert.
• 111 ist ein vereinfachtes Flussdiagramm, das einen detaillierten möglichen Fluss 11100 von Vorgängen veranschaulicht, die mit der Durchsetzung von Richtlinien in einem System zur Einhaltung des Datenschutzes auf Abruf, wie dem System 10100, verbunden sind. In mindestens einer Ausführungsform entspricht eine Reihe von Vorgängen den Aktivitäten von 111. Ein Fahrzeugdatensystem, wie z. B. das Fahrzeugdatensystem 10400, kann zumindest einen Teil des Satzes von Operationen verwenden. Das Fahrzeugdatensystem 10400 kann einen oder mehrere Datenprozessoren (z. B. 10127 für ein Cloud-Fahrzeugdatensystem, 10157 für ein Edge-Fahrzeugdatensystem) zur Durchführung der Operationen umfassen. In mindestens einer Ausführungsform führt die Richtliniendurchsetzungs-Engine 10430 einen oder mehrere der Vorgänge aus. Im Allgemeinen kann die Bewegung 11100 auf einen Datensatz angewendet werden, der für die Verarbeitung auf Abruf markiert wurde.
• Es sollte beachtet werden, dass in mindestens einer Ausführungsform bei Eingang einer Anfrage für den Zugriff auf einen Datensatz bestimmt werden kann, ob der Datensatz für die Verarbeitung auf Abruf markiert ist. Wenn der Datensatz für die Verarbeitung auf Abruf gekennzeichnet ist, wird bei 11102 festgestellt, dass der Datensatz, auf den der Zugriff beantragt wurde, für die Verarbeitung auf Abruf gekennzeichnet ist. Da der Datensatz für die Verarbeitung auf Abruf gekennzeichnet wurde, ist mindestens eine mit dem Datensatz verbundene Richtlinie als „Lazy Policy“ gekennzeichnet. Eine Anfrage für den Zugriff auf den Datensatz kann eine Anfrage von einem beliebigen Gerät oder irgendeiner Anwendung sein, z. B. um den Datensatz zu lesen, zu teilen, zu empfangen, abzutasten oder auf eine andere geeignete Weise darauf zuzugreifen.
• Bei 11104 wird eine mit dem Datensatz verbundene Richtlinie identifiziert. Bei 11104 wird festgestellt, ob die identifizierte Police als faul bezeichnet wird. Wenn festgestellt wird, dass die identifizierte Richtlinie als faul bezeichnet wird, wird die identifizierte Richtlinie bei 11106 auf den Datensatz angewendet. Wenn die ermittelte Richtlinie nicht als faul bezeichnet wird oder wenn die ermittelte Richtlinie auf den Datensatz angewendet wird, wird bei 11108 festgestellt, ob eine andere Richtlinie mit dem Datensatz verbunden ist. Wenn dem Datensatz eine andere Richtlinie zugeordnet ist, kehrt der Fluss zu 11104 zurück, um eine andere, dem Datensatz zugeordnete Richtlinie zu identifizieren und die Verarbeitung wie zuvor beschrieben fortzusetzen. Der Datenfluss kann in einer Schleife weiterlaufen, bis alle mit dem Datensatz verbundenen und als faul bezeichneten Richtlinien auf den Datensatz angewendet wurden.
• Wenn bei 11108 festgestellt wird, dass keine andere Richtlinie mit dem Datensatz verbunden ist, wird bei 11110 festgestellt, ob sich der geltende Standort geändert hat. Wenn ein Fahrzeug beispielsweise einen Datensatz lokal (z. B. im Fahrzeug) speichert, bei dem mindestens eine Richtlinie als faul gekennzeichnet ist, und das Fahrzeug dann in einen anderen Regelungsbereich fährt, kann eine Bewertung durchgeführt werden, um festzustellen, ob der neue Regelungsbereich zusätzliche Maßnahmen zur Einhaltung des Datenschutzes erfordert. Wenn sich also die geltende Rechtslage nicht geändert hat, kann der Datenfluss an 11118 übergeben werden, um den Zugriff auf den richtlinienkonformen Datensatz zu gewähren.
• Wenn sich der maßgebliche Standort geändert hat, wird dem Datensatz bei 11112 eine aktualisierte Geo-Standortkennung zugeordnet. Bei 11114 wird festgestellt, ob eine oder mehrere neue Richtlinien für den Datensatz gelten. Wenn keine neuen Richtlinien für den Datensatz gelten (zumindest teilweise auf der Grundlage des neuen Geo-Standort-Tags), kann der Datenfluss an 11118 übergeben werden, um den Zugriff auf den richtlinienkonformen Datensatz zu gewähren.
• Wenn mindestens eine neue Richtlinie auf den Datensatz zutrifft, wird bei 11116 die neue Richtlinie (oder mehrere neue Richtlinien) auf den Datensatz angewendet. Dann kann unter 11118 der Zugriff auf den richtlinienkonformen Datensatz gewährt werden.
• Es sei darauf hingewiesen, dass, wenn ein Datensatz nicht für die Verarbeitung auf Abruf gekennzeichnet ist und eine Anfrage für den Zugriff auf den Datensatz eingeht, in mindestens einer Ausführungsform festgestellt wird, dass der Datensatz richtlinienkonform ist und der Datenfluss bei 11110 fortgesetzt werden kann. So kann ein richtlinienkonformer Datensatz noch ausgewertet werden, um festzustellen, ob ein neuer Standort des Fahrzeugs die auf den Datensatz anzuwendenden Richtlinien beeinflusst.
• 112 ist ein vereinfachtes Diagramm eines Regelkreises für die Automatisierung eines autonomen Fahrzeugs 11210 in Übereinstimmung mit mindestens einer Ausführungsform. Wie in 112 gezeigt, kann sich das automatisierte Fahren auf eine sehr schnelle Rückkopplungsschleife stützen, die eine Logik-Engine 11202 (die Aspekte der Wahrnehmung, Fusionsplanung, Fahrerpolitik und Entscheidungsfindung umfasst) und die verteilte Betätigung des Fahrzeugs 11204 auf der Grundlage der Ergebnisse dieser Engines nutzt. Jedes dieser Metamodule kann von Eingaben oder Verarbeitungen abhängig sein, die als vertrauenswürdig gelten.
• 113 ist ein vereinfachtes Diagramm eines Generalized Data Input (GDI) für die Automatisierung eines autonomen Fahrzeugs in Übereinstimmung mit mindestens einer Ausführungsform. Im Zusammenhang mit automatisiertem Fahren und Transport in intelligenten Städten und intelligenter Infrastruktur kann der Input in Form von Rohdaten 11302 (z. B. Zahlen, Symbole, Fakten), Informationen 11304 (z. B. verarbeitete und organisierte Daten zur Modellierung), Wissen (knowledge) 11308 (z. B. gesammelte Informationen, die strukturiert oder kontextbezogen sein können), Erfahrungen 11310 (z. B. Wissen, das durch vergangene Handlungen gewonnen wurde), Theorierahmen 11306 (z. B. zur Erklärung von Verhaltensweisen) oder Verständnis 11312 (z. B. Zuweisung von Bedeutung, Erklärung, warum ein Verhalten aufgetreten ist, oder Anwendung von Analysen). Jede dieser verschiedenen Arten von Eingaben kann als Generalized Data Input (GDI) bezeichnet werden. Wie in 113 gezeigt, kann die GDI genutzt werden, um Wissen (wisdom) zu vermitteln (z. B. Urteilsvermögen, bewertetes Verständnis, richtige/gut/korrekte/richtige Handlungen). Die angezeigten Daten können in jedem geeigneten Speichertyp gespeichert und/oder von einem oder mehreren Prozessoren eines bordeigenen Rechensystems eines autonomen Fahrzeugs verarbeitet werden.
• 114 ist ein Diagramm einer beispielhaften GDI-Freigabeumgebung 11400 in Übereinstimmung mit mindestens einer Ausführungsform. Im gezeigten Beispiel gibt es ein Ego-Fahrzeug (z. B. ein autonomes Fahrzeug) 11402, das von anderen Fahrzeugakteuren 11404 umgeben ist, und Flottenfahrzeugakteure 11406 in einer Umgebung 11412 um das Ego-Fahrzeug 11402. Darüber hinaus gibt es in der Umgebung des Ego-Fahrzeugs 11402 Infrastruktursensoren, darunter Ampelsensoren 11408 und Straßenlampensensoren 11410.
• Wie dargestellt, kann das Ego-Fahrzeug 11402 mit einem oder mehreren anderen Akteuren oder Sensoren in der Umgebung 11400 in Verbindung stehen. Die GDI kann von den gezeigten Akteuren gemeinsam genutzt werden. Die Kommunikation zwischen dem Ego-Fahrzeug 11402 und den anderen Akteuren kann in einem oder mehreren der folgenden Szenarien durchgeführt werden: (1) selbst-zu-selbst, (2) an andere autonome Fahrzeuge rundsenden (1:1 oder 1:viele), (3) an andere Arten von Akteuren/Sensoren rundsenden (1:1 oder 1:viele), (4) von anderen autonomen Fahrzeugen empfangen (1:1 oder 1:viele) oder (5) von anderen Arten von Akteuren/Sensoren empfangen (1:1 oder 1:viele).
• In einigen Ausführungsformen kann das Ego-Fahrzeug 11402 von seinen eigenen Sensoren erzeugte GDI verarbeiten und in einigen Fällen die GDI mit anderen Fahrzeugen in der Umgebung 11400 teilen, so dass die anderen Fahrzeuge die GDI verwenden können, um Entscheidungen zu treffen (z. B. unter Verwendung ihrer jeweiligen Logik-Engines für die Planung und Entscheidungsfindung). Die GDI (von der angenommen werden kann, dass sie vertrauenswürdig ist) kann von den eigenen heterogenen Sensoren des ego-autonomen Fahrzeugs stammen (die Informationen von einem oder mehreren der folgenden elektronischen Steuergeräte umfassen können: adaptiver Tempomat, elektronisches Bremssystem, Sensorcluster, Gateway-Datensender, Force-Feedback-Gaspedal, Türsteuergerät, Schiebedachsteuergerät, Gurtstraffer, Sitzsteuergerät, Bremsaktuatoren, Schließgeschwindigkeitssensor, Seitensatelliten, Upfront-Sensor, Airbag-Steuergerät oder andere geeignete Steuergeräte) oder von anderen GDI-Akteur-Fahrzeugen (z. B. Kraftfahrzeuge in der Nähe, Flottenfahrzeuge wie Busse oder andere Fahrzeugtypen), Smart-City-Infrastrukturelementen (z. B. Infrastruktursensoren wie Sensoren/Computer in Oberleitungsmasten oder Ampeln usw.), Apps von Drittanbietern wie einem Kartendienst oder einem Anbieter von Software-Updates, den OEMs der Fahrzeuge, staatlichen Stellen usw. Darüber hinaus kann das Ego-Fahrzeug 11402 in einigen Ausführungsformen GDI von einem oder mehreren der anderen Fahrzeuge in der Nachbarschaft und/oder den Infrastruktursensoren empfangen. Jeder böswillige Angriff auf eine dieser GDI-Quellen kann zur Verletzung oder zum Tod von einer oder mehreren Personen führen. Wenn böswillige Angriffe auf Fahrzeuge in einer Flotte, einer Stadt oder einer Infrastruktur durchgeführt werden, könnten die Fahrzeuge fehlerhafte Aktionen in großem Umfang mit schrecklichen Folgen verbreiten, Chaos verursachen und das Vertrauen der Öffentlichkeit in Technologien untergraben.
• In einigen Fällen kann die gemeinsame Nutzung von Daten mit potenziell nicht vertrauenswürdigen Quellen über Blockchain-Techniken erfolgen. Die gemeinsame Nutzung der GDI kann eines oder mehrere der folgenden Elemente umfassen, die von einem oder mehreren mit einem Fahrzeug verbundenen Rechnersystemen implementiert werden:
• • Eine Struktur für das Packaging der GDI.
• • Die Topologie, die beschreibt, wie die GDI mit anderen GDI zusammenhängt
• • Berechtigungsrichtlinien (z. B. ähnlich wie chmod in Linux/Unix-Systemen), zum Beispiel:
  • • Lesezugriffsrichtlinie, um festzulegen, wer die GDI lesen darf
  • • Eine Richtlinie zur Schreibkontrolle, um festzulegen, wer die GDI schreiben darf
  • • Eine Execute-Control-Richtlinie, um festzulegen, wer ausführbare GDI-Komponenten tatsächlich ausführen darf (z. B. Ausführen eines Modells, Aktualisieren von Software usw.).
• • Eine Zustandsrichtlinie zur Bestimmung des gültigen Zustands der Topologie
• • Auf die GDI angewandte Eigentumsrichtlinien (ähnlich wie chgrp/chownin Linux/Unix-Systemen). Zum Beispiel: Selbst, Gruppe, Alle.
• 115 ist ein Diagramm einer beispielhaften Blockchain-Topologie 11500 in Übereinstimmung mit mindestens einer Ausführungsform. Wie dargestellt, kann die Struktur der GDI einen „Block“ 11502 umfassen, der eine Kopfzeile, einen Hauptteil (der die GDI-Details umfasst) und eine Fußzeile umfasst. Die Topologie umfasst eine verknüpfte Liste von Blöcken (oder ein lineares Netz) mit einer kryptografisch gestützten Kopf- und Fußzeile (siehe z. B. 115) umfassen. Der Kopf eines Blocks, n, in einer Kette umfasst Informationen, die ihn als Nachfolger des Vorgängerblocks, n-1, in der verknüpften Liste ausweisen. In einigen Fällen können Rechensysteme, die die Blockchain implementieren (z. B. durch Speicherung von Blöcken und Verifizierung neuer Blöcke), eines oder mehrere der folgenden Elemente durchsetzen:
• • Genehmigungsrichtlinien, die z. B. Folgendes umfassen können:
  1. 1. Eine Lesezugriffsrichtlinie, die angibt, wer die Blockinformationen lesen darf, basiert auf Übereinstimmungen zwischen öffentlichen und privaten Schlüsselpaaren, die aus kryptografischen Hashes wie dem Elliptic Curve Digital Signal Algorithm generiert werden.
  2. 2. Eine Schreibkontroll-Richtlinie, die angibt, wer die Blöcke anhängen und somit die Kopfinformationen in den anhängenden Block „schreiben“ darf, basiert auf der Fähigkeit, den vorherigen Block zu verifizieren, wobei die Zeit bis zur Verifizierung die entscheidende Einschränkung ist.
  3. 3. Eine in die Blockinformationen eingebettete Execute-Control-Richtlinie als Smart Contract (intelligenter Vertrag).
• • Eine auf verteiltem Konsens basierende Zustandsrichtlinie, um bei widersprüchlichen Zustandsinformationen zu bestimmen, welcher Zustand der Blockchain gültig ist. Die Belohnung für die Herstellung des „gültigen Zustands“ ist die Erlaubnis zur Schreibkontrolle. Beispiele hierfür sind Proof-of-Work (der erste Miner, der ein kryptografisches Puzzle innerhalb einer bestimmten Zeit löst, dessen Schwierigkeitsgrad von einer zentralen Plattform dynamisch gedrosselt wird, gilt als derjenige, der den „gültigen Zustand“ hergestellt hat, und erhält somit zu diesem Zeitpunkt die Schreibberechtigung), Proof of Stake (weist das kryptografische Rätsel dem Schürfer mit dem höchsten Einsatz/Vermögen/Interesse zu und erteilt diesem Schürfer die Schreibkontrollerlaubnis, sobald das Rätsel gelöst ist), Proof of Burn (erteilt die Schreibkontrollerlaubnis im Gegenzug für das Verbrennen der eigenen Währung), usw.
• • Informationen über die Eigentümerschaft, die in den Details der Nachricht erfasst werden können.
• 116 ist ein Diagramm eines beispielhaften „kettenlosen“ Blocks unter Verwendung einer Topologie eines gerichteten azyklischen Graphen (DAG) 11600 in Übereinstimmung mit mindestens einer Ausführungsform. Um die Skalierbarkeit zu verbessern, wurden in einigen Fällen neue Plattformen entwickelt, die DAGs verwenden, wie z. B. die IOTA-Plattform. In DAGs kann die Zustandsrichtlinie (und damit die Berechtigung zur Schreibkontrolle) auf dem Proof-of-Work basieren, der dazu verwendet werden kann, frühere Blöcke für alle derzeit unbestätigten Blöcke zu bestätigen.
• In einigen Fällen können blockartige Technologien wie diese jedoch Herausforderungen mit sich bringen, die sich aus der Genehmigungspolitik, der Zustandspolitik oder der Skalierbarkeit der jeweiligen Plattform ergeben. So kann beispielsweise in den Genehmigungs- und Zustandsrichtlinien die Verwendung der Kryptographie mit elliptischen Kurven (ECC) umfassen sein, die bisher ausreichend war, aber diese Kryptographietechnologien könnten in Zukunft unzureichend sein. So können beispielsweise ECC-basierte Signaturen (die auf diskreten Log-Problemen mit elliptischen Kurven beruhen) eine der riskantesten Komponenten der Technologie sein, wenn sie effizienten Quantenalgorithmen unterworfen werden, wobei die unsichersten Komponenten sind: (1) eine statische Adresse, die mit dem öffentlichen Schlüssel verknüpft ist, und (2) unbearbeitete Blöcke (Blöcke, die noch nicht an die Blockchain oder die Block-DAG angehängt wurden). Außerdem können solche Technologien anfällig für das Abfangen der Lieferkette durch böswillige Akteure sein (z. B. bei Fahrzeugflotten).
• Ein Beispiel für Probleme mit solchen blockartigen Technologien und Systemen sind Probleme mit der Genehmigungspolitik. Wenn die statische Adresse gestohlen wird, können alle damit verbundenen Daten und Transaktionen sowie der Geldwert in den Besitz des Hacker-Diebs übergehen. Dies liegt daran, dass der Hacker-Dieb Lese-, Schreib- und/oder Ausführungsberechtigungen bis hin zum vollständigen Besitz erlangen kann. Andere Fragen können sich auf die staatliche Politik beziehen. So werden Quantenalgorithmen im Falle von unverarbeiteten Blöcken voraussichtlich bis zum Jahr 2028 in der Lage sein, den privaten Schlüssel aus dem öffentlichen Schlüssel abzuleiten. Insbesondere kann der Schor-Algorithmus mit Hilfe eines Quantencomputers Primfaktoren bestimmen. Und Grovers Algorithmus kann eine Schlüsselsuche durchführen. Wenn der private Schlüssel und die Adresse bekannt sind, ist es möglich, neue Blöcke (möglicherweise mit schädlichen Daten oder schädlichen Verträgen) von dieser Adresse aus einzuführen. Der Lesezugriff und der Konsens (und damit die Schreibkontrolle) basieren auf der elliptischen Kurvenkryptographie. Allerdings haben Verstöße bei der Implementierung von Kryptowährungen zu erheblichen finanziellen Verlusten geführt. Bei den aktuellen Blockchain-Technologien, die für autonome Fahrzeuge vorgeschlagen werden, kann der Diebstahl einer Adresse oder einer Nachricht (einschließlich des Diebstahls von Smart Contracts) in der Rückkopplungsschleife des Fahrzeugs nachhallen und zum Verlust von Menschenleben und/oder zu katastrophalen Schäden an der Infrastruktur führen. Andere Probleme können mit der Skalierbarkeit zusammenhängen. Moderne dezentrale Blockchain-Technologien führen derzeit <20 Transaktionen pro Sekunde aus (bei Verwendung eines dezentralen Peer-to-Peer-Push-Modells), während VisaNet bis zu 56K Transaktionsnachrichten pro Sekunde ausführen kann (bei Verwendung eines zentralen Pull-Modells). Für automatisiertes Fahren und Smart Cities müssen Transaktionen mindestens in der Größenordnung von VisaNet durchgeführt werden.
• Dementsprechend können Aspekte der vorliegenden Offenbarung eines oder mehrere der folgenden Elemente umfassen, die in einem Rechensystem für autonomes Fahren implementiert werden können, um zur Lösung dieser Probleme beizutragen:
• • Innerhalb des autonomen Fahrzeugs können ein oder mehrere sichere private Schlüssel (z. B. unter Verwendung von Intel SGX (Software Guard Extension)) erstellt werden. Die privaten Schlüssel können verwendet werden, um die entsprechenden öffentlichen Schlüssel zu erzeugen.
• • Digitale Signaturen können für alle Daten verwendet werden, die auf dem privaten Schlüssel basieren. Die digitale Signatur kann ein Hash der Sensordaten sein, der dann mit dem privaten Schlüssel verschlüsselt wird.
• • Eine erlaubnisfreie Blockchain kann innerhalb des autonomen Fahrzeugs verwendet werden (z. B. muss eine Person, die der Blockchain etwas hinzufügt, möglicherweise nicht verifiziert werden). Alle Kommunikationsbusse können Blöcke lesen, und das interne Netzwerk des autonomen Fahrzeugs kann bestimmen, wer in die Blockchain schreiben darf.
• • Das autonome Fahrzeug kann eine Schnittstelle zu einer genehmigten Blockchain (z. B. mit einer Zugriffsrichtlinie, die auf einem Fahrzeugtyp basieren kann, wie z. B. Flottenfahrzeug (z. B. Bus) vs. eigenes Insassenfahrzeug vs. temporäres/gemietetes Insassenfahrzeug (z. B. Taxi); der Lesezugriff kann auf Schlüsselvereinbarungen basieren) oder einem dynamischen DAG-System haben, wenn es exogene Daten erwartet. Der Lesezugriff kann auf derGrundlage von Abonnements erfolgen, z. B. können Software-Updates auf derGrundlage von kostenpflichtigen Upgrade-Richtlinien gewährt werden.
• • Bei der Übertragung von Daten zur gemeinsamen Nutzung können ephemere öffentliche Schlüssel (z. B. auf der Grundlage eines ephemeren Diffie-Hellman-Austauschs mit elliptischer Kurve oder einer anderen Art von Einmal-Signaturverfahren) verwendet werden, um einen geheimen Schlüssel zum Entsperren der gemeinsam zu nutzenden Daten zu erzeugen.
• Durch die Verwendung digitaler Signaturen können alle Daten mit einem Zeitstempel und einer Wahrheitssignatur versehen werden, die in der Folge weiterverwendet werden können. Statische private Schlüssel können in einer sicheren Enklave aufbewahrt werden. Indem die Zeitbeschränkungen für das Konsensprotokoll in der Größenordnung der Anpassungen der Betätigungszeit (z. B. Millisekunden) festgelegt werden, können außerdem Spoofing- oder Hacking-Versuche, die auf einen oder mehrere Sensoren gerichtet sind, verhindert werden. Außerdem dürfen Netz-/Gateway-Protokolle (auf der Ebene der Busschnittstelle oder des Gateway-Protokolls) innerhalb des/der internen Netzwerks/Netzwerke des autonomen Fahrzeugs nur die verifizierte Blockchain weiterleiten. Darüber hinaus kann durch die Einrichtung einer fahrzeuginternen Datenbank (über die Blockchain) eine „Blackbox“ (überprüfbarer Datenrekorder) für das autonome Fahrzeug geschaffen werden.
• 117 ist ein vereinfachtes Blockdiagramm eines Beispiels für ein sicheres fahrzeuginternes Kommunikationsprotokoll 11700 für ein autonomes Fahrzeug in Übereinstimmung mit mindestens einer Ausführungsform. Das Protokoll 11700 kann zum Beispiel vom Ego-Fahrzeug 11402 von FIG verwendet werden. 114 seine Daten gegen böswillige Akteure zu schützen. Das Beispielprotokoll kann für die Übermittlung von Daten von Sensoren, die mit einem autonomen Fahrzeug gekoppelt sind (z. B. LIDAR, Kameras, Radar, Ultraschall usw.), an eine Logikeinheit (z. B. eine Logikeinheit, die der oben in Bezug auf 112 Beschriebenen ähnlich ist) des autonomen Fahrzeugs verwendet werden. Im gezeigten Beispiel wird eine digitale Signatur an Sensordaten (z. B. Objektlisten) angehängt. Die digitale Signatur kann auf einem sicheren privaten Schlüssel für den Sensor beruhen. Der private Schlüssel kann z. B. auf der Grundlage eines ECC-basierten Protokolls wie secp256k1 erzeugt werden. In einigen Fällen kann die digitale Signatur durch Hashing der Sensordaten und Verschlüsselung des Hashes mit dem privaten Schlüssel erzeugt werden.
• Die Sensordaten 11702 (mit der digitalen Signatur) werden als Block in einer blockbasierten Topologie (z. B. einer erlaubnisfreien Blockchain, wie dargestellt) 11704 hinzugefügt, bevor sie über bestimmte Netzwerkprotokolle 11706 an die Wahrnehmungs-, Fusions- und Entscheidungslogikeinheit 11708 (z. B. ein fahrzeuginternes Rechensystem) übermittelt werden. In bestimmten Ausführungsformen können nur die Daten auf der Blockchain durch das Netzwerk/Kommunikationsprotokoll innerhalb des autonomen Fahrzeugs weitergeleitet werden. Das Netzwerkprotokoll kann die Daten des Blocks verifizieren (z. B. durch den Vergleich eines Zeitstempels der Sensordaten mit einer Zeitbeschränkung im Konsensprotokoll einer Blockchain), bevor die Block-/Sensordaten an die Logikeinheit übermittelt werden. In bestimmten Ausführungsformen kann das Netzprotokoll außerdem die digitale Signatur der Sensordaten im Block überprüfen, bevor der Block an die Logikeinheit weitergeleitet wird. Beispielsweise kann das Netzwerkprotokoll Zugriff auf einen öffentlichen Schlüssel haben, der mit einem privaten Schlüssel verknüpft ist, der zur Erzeugung der digitalen Signatur der Sensordaten verwendet wird, und kann den öffentlichen Schlüssel zur Überprüfung der digitalen Signatur verwenden (z. B. durch Entschlüsselung des Hashes mit dem öffentlichen Schlüssel und Überprüfung der Übereinstimmung der Hashes). Die Blockchain 11704 kann als erlaubnisfrei betrachtet werden, da sie keine Überprüfung erfordert, bevor sie der Blockchain hinzugefügt wird. In einigen Fällen können ein oder mehrere Aspekte des autonomen Fahrzeugs bestimmen, wer in die Blockchain schreiben darf. So ist es beispielsweise möglich, dass die internen Netzwerke des autonomen Fahrzeugs bei Fahrten durch unsichere Gegenden, ausgelöst durch die Erkennung einer „unsicheren“ Gegend durch die Kamera oder eine Warnung auf der Navigationskarte, so lange auf die Überprüfung aller Daten zurückgreifen, bis das Fahrzeug die Gegend sicher verlassen hat.
• 118 ist ein vereinfachtes Blockdiagramm eines Beispiels für ein sicheres Kommunikationsprotokoll 11800 zwischen Fahrzeugen für ein autonomes Fahrzeug in Übereinstimmung mit mindestens einer Ausführungsform. Das Protokoll 11800 kann zum Beispiel vom Ego-Fahrzeug 11402 von FIG verwendet werden. 114, um Daten von einem oder mehreren anderen Fahrzeugen, Backend-Systemen (z. B. Cloud-basiert) oder Infrastruktursensoren zu überprüfen. Das Beispielprotokoll kann für die Übermittlung von Sensordaten von einem autonomen Fahrzeug (das ein eigenes Fahrzeug, ein temporäres/gemietetes Fahrzeug oder ein Flottenfahrzeug umfassen kann) an eine Logikeinheit (z. B. eine Logikeinheit, die der oben in Bezug auf 112 Beschriebenen ähnlich ist) eines anderen autonomen Fahrzeugs verwendet werden. Im gezeigten Beispiel werden Sensordaten von einem ersten autonomen Fahrzeug (die eine digitale Signatur wie oben beschrieben umfassen können) als Block in einer blockbasierten Topologie (z. B. genehmigte Blockchain oder Knoten einer dynamischen DAG) 11802 hinzugefügt und an ein zweites autonomes Fahrzeug gesendet, wo ein oder mehrere Smart Contracts 11804 extrahiert werden. Die Smart Contracts können Informationen wie neue Verarbeitungsrichtlinien zur Einhaltung von Vorschriften oder sogar ausführbaren Code umfassen, der die Verarbeitung von Daten in der Logikeinheit 11808 für Wahrnehmung, Fusion und Entscheidungsfindung außer Kraft setzt. So kann beispielsweise eine neue Richtlinie den Wahrnehmungsfluss außer Kraft setzen, so dass die Komponente der Kamerawahrnehmungsmaschine, die Fußgänger/Personen und ihre Gesichter erkennt, nur Gesichtsmerkmale, Pose und Bewegung, nicht aber ihre gesamten Merkmalskarten extrahieren kann. Wenn es sich bei dem ersten autonomen Fahrzeug um ein Polizeifahrzeug handelt, kann der intelligente Vertrag eine vorübergehende Übersteuerung der Wahrnehmungsverarbeitung und eine Nummernschildsuche umfassen, um festzustellen, ob die Kameras des aktuellen autonomen Fahrzeugs ein Nummernschild von Interesse in seiner Nähe erkannt haben.
• In bestimmten Ausführungsformen können exogene Daten und Software-Updates für das Fahrzeug in Form eines Smart Contracts eingehen. Wenn die Smart Contracts und/oder Sensordaten durch das Netzwerkprotokoll 11806 verifiziert werden, werden die Sensordaten an die Wahrnehmungs-, Fusions- und Entscheidungslogikeinheit 11808 des zweiten autonomen Fahrzeugs übermittelt. In einigen Fällen kann das Netzprotokoll ephemere öffentliche Schlüssel verwenden (z. B. auf der Grundlage der elliptischen Kurve Diffie-Hellman). Die Verwendung von ephemeren öffentlichen Schlüsseln in dynamischen Umgebungen ermöglicht die Erstellung und Weitergabe von öffentlichen Schlüsseln im laufenden Betrieb, während das Fahrzeug vorübergehend mit anderen Fahrzeugen oder der Infrastruktur verbunden ist, die es auf seiner Fahrt passiert. Diese Art des ephemeren Schlüsselaustauschs ermöglicht einen sicheren Datenaustausch nur für die kurze Zeitspanne, in der das Ego-Car verbunden ist.
• 119 ist ein vereinfachtes Blockdiagramm eines Beispiels für ein sicheres fahrzeuginternes Kommunikationsprotokoll für ein autonomes Fahrzeug in Übereinstimmung mit mindestens einer Ausführungsform. In dem gezeigten Beispiel verwendet das sichere fahrzeuginterne Kommunikationsprotokoll zwei Blockchains (A und B), die miteinander interagieren. Darüber hinaus verwendet das fahrzeuginterne Kommunikationsprotokoll eine fahrzeuginterne „Blackbox“-Datenbank 11920. Die Beispielsensordaten 11902 und 11912, die Blockchains 11904 und 11914, die Netzwerkprotokolle 11906 und die Logikeinheit 11908 können ähnlich implementiert werden wie die in 117 gezeigten und oben beschriebenen Komponenten, und die Smart Contracts 11916 können ähnlich wie die Smart Contracts 11804 implementiert werden, die in 118 gezeigt und oben beschrieben sind.
• Im gezeigten Beispiel können die von der Logikeinheit 11908 erzeugten Informationen einer Betätigungseinheit 11910 eines autonomen Fahrzeugs zur Verfügung gestellt werden, um Operationen des autonomen Fahrzeugs zu betätigen und zu steuern (z. B. wie oben in Bezug auf 112), und die Betätigungseinheit kann eine Rückmeldung an die Logikeinheit geben. Nachdem die Sensordaten 11902, die von der Logikeinheit 11908 erzeugten Informationen oder die von der Betätigungseinheit 11910 erzeugten Informationen für die Betätigung verwendet wurden, können sie in einer fahrzeuginternen Datenbank 11920 gespeichert werden, die wiederum als „Black Box“ für das autonome Fahrzeug fungieren kann.
• Die „Black Box“ kann ähnlich funktionieren wie Black Boxes, die für die Aufzeichnung bestimmter Aspekte, Kommunikation und Daten bei der Erbringung von Luftverkehrsleistungen verwendet werden. Da die in der Blockchain aufgezeichnete GDI unveränderlich ist, kann sie, wenn sie in einem Speichersystem innerhalb des autonomen Fahrzeugs gespeichert ist, beispielsweise von staatlichen Stellen bei einem Unfall oder von Anbietern von Softwaresystemen bei einem Software-Update wiederhergestellt werden. Diese GDI kann dann verwendet werden, um eine große Anzahl möglicher nachgelagerter Vorgänge zu simulieren. Wenn der Betätigungslogger auch auf dem Speichersystem aufzeichnet, können die Daten des Endpunkt-Betätigungsloggers zusammen mit der vorgelagerten GDI verwendet werden, um fehlerhafte Zwischenstufen auszusortieren. Dies würde eine hohe Wahrscheinlichkeit der Fehleridentifizierung innerhalb des autonomen Fahrzeugs bieten, wobei der Fehler auf interne Komponenten des Ego-Fahrzeugs oder auf fehlerhafte Daten von anderen Fahrzeugen, Flotten, Infrastrukturen oder anderen Dritten zurückgeführt werden könnte.
• Ein autonomes Fahrzeug kann mit einer Vielzahl unterschiedlicher Sensoren ausgestattet sein, z. B. mit einem oder mehreren LIDARs, Radargeräten, Kameras, globalen Positionierungssystemen (GPS), Trägheitsmesseinheiten (IMU), Audiosensoren, Wärmesensoren oder anderen Sensoren (wie den hier beschriebenen oder anderen geeigneten Sensoren). Die Sensoren können zusammen eine große Menge an Daten (z. B. Terabytes) pro Sekunde erzeugen. Diese Daten können von den Wahrnehmungs- und Sensorfusionssystemen des autonomen Fahrzeugs genutzt werden. In vielen Situationen können die Sensordaten verschiedene Redundanzen umfassen, da verschiedene Sensoren dieselben Informationen erfassen oder ein bestimmter Sensor Informationen erfasst, die sich nicht oder nur geringfügig ändern (z. B. während der Fahrt auf einer ruhigen Autobahn, bei geringem Verkehrsaufkommen oder beim Anhalten an einer Ampel). Diese Redundanzen können den Bedarf an Ressourcen wie Hardware, speziellen Big-Data-Ökosystemen für die Datenverarbeitung, Sensorfusionsalgorithmen und anderen Algorithmusoptimierungen, die zur Verarbeitung von Daten in nahezu Echtzeit in verschiedenen Phasen der Verarbeitungspipeline eingesetzt werden, erheblich erhöhen. In einigen Systemen können zur Verbesserung des Signal-Rausch-Verhältnisses (SNR) des Sensorsystems Algorithmen zur Sensorfusion (z. B. auf Kalman-Filtern basierende Algorithmen) Daten von mehreren Sensoren mit gleicher Gewichtung kombinieren. Dies kann zu einem verbesserten SNR im Vergleich zu Daten von einem einzelnen Sensor führen, da die Gesamtvarianz verbessert wird.
• In bestimmten Ausführungsformen der vorliegenden Offenbarung kann ein verbessertes Sensorfusionssystem Signale geringerer Qualität von kostengünstigen und/oder stromsparenden Sensoren verwenden und dennoch die SNR-Anforderungen des Gesamtsystems erfüllen, was zu einer Kostenreduzierung für das Gesamtsystem führt. Verschiedene Ausführungsformen können die mit der Redundanz von Sensordaten verbundenen Nachteile durch eine oder beide der folgenden Maßnahmen verringern: 1) ungleichmäßige, kontextabhängige Datenabtastung und 2) adaptive, kontextabhängige Sensorfusion.
• In einer besonderen Ausführungsform kann ein Abtastsystem eines autonomen Fahrzeugs eine ungleichmäßige Datenabtastung durchführen, indem es Daten auf der Grundlage des mit dem autonomen Fahrzeug verbundenen Kontexts abtastet. Die Abtastung kann auf jedem geeigneten Kontext basieren, wie z. B. der Häufigkeit des Szenenwechsels, den Wetterbedingungen, der Verkehrssituation oder anderen Kontextinformationen (wie z. B. einem der hier beschriebenen Kontexte). Eine solche ungleichmäßige Datenabtastung kann den Bedarf an Ressourcen und die Kosten dergesamten Verarbeitungspipeline erheblich reduzieren. Anstatt Daten von jedem Sensor in einem festgelegten Intervall (z. B. jede Sekunde) abzutasten, kann die Abtastung eines oder mehrerer Sensoren kontextabhängig angepasst werden.
• In einer Ausführungsform kann die Abtastrate eines Sensors auf die Empfindlichkeit des Sensors für eine bestimmte Wetterbedingung abgestimmt werden. So kann beispielsweise die Abtastrate für einen Sensor, der bei einer bestimmten Wetterlage nützliche Daten liefert, häufiger abgetastet werden als ein Sensor, der bei dieser Wetterlage unbrauchbare Daten liefert. In einigen Ausführungsformen sind die jeweiligen Abtastraten der verschiedenen Sensoren mit der Verkehrsdichte oder der Geschwindigkeit der Szenenänderung korreliert. So kann beispielsweise bei dichtem Verkehr eine höhere Abtastrate für einen oder mehrere Sensoren verwendet werden im Vergleich zu Abtastwerten, die bei leichtem Verkehr erfasst werden. Ein weiteres Beispiel: Wenn sich eine Szene schnell verändert, können mehr Abtastwerte pro Zeiteinheit erfasst werden relativ zu der Anzahl von Abtastwerten, die erfasst werden bei einer statischen Szene. In verschiedenen Ausführungsformen wird ein Sensor mit hohen Kosten, geringem Durchsatz pro verbrauchter Energieeinheit und/oder hohem Energiebedarf im Vergleich zu einem Sensor mit niedrigen Kosten, hohem Durchsatz pro verbrauchter Energieeinheit und/oder geringerem Energiebedarf sparsam eingesetzt, um Kosten und Energie zu sparen, ohne die Sicherheitsanforderungen zu gefährden.
• 120A zeigt ein System zur Bestimmung von Abtastraten für eine Mehrzahl von Sensoren in Übereinstimmung mit bestimmten Ausführungsformen. Das System umfasst Basisdaten 12002, einen Algorithmus für maschinelles Lernen 12004 und ein Ausgabemodell 12006. Die Basisdaten 12002 werden dem Algorithmus für maschinelles Lernen 12004 zur Verfügung gestellt, der diese Daten verarbeitet und das Ausgabemodell 12006 erstellt. In einer bestimmten Ausführungsform kann der maschinelle Lernalgorithmus 12004 und/oder das Ausgabemodell 12006 von der maschinellen Lernmaschine 232 oder einer maschinellen Lernmaschine eines anderen Rechnersystems (z. B. 140, 150) implementiert werden.
• Im vorliegenden Beispiel können die Ground-Truth-Daten 12002 Konfigurationsdaten der Sensoren, eine Abtastrate pro Sensor, Kontext und Sicherheitsdaten umfassen. Die Ground-Truth-Daten 12002 können mehrere Datensätze umfassen, die jeweils einer Abtastzeitperiode entsprechen und eine Sensorensuitekonfiguration, eine pro Sensor verwendete Abtastrate, den Kontext für die Abtastzeitperiode und das Sicherheitsergebnis über die Abtastzeitperiode angeben. Ein Datensatz kann einer von einem tatsächlichen autonomen Fahrzeug durchgeführten Sampling oder von einem Simulator erzeugten Daten entsprechen. Die Konfigurationsdaten der Sensorensuite können Informationen umfassen, die mit der Konfiguration der Sensoren eines autonomen Fahrzeugs verbunden sind, wie z. B. die Arten von Sensoren (z. B. LIDAR, 2D-Kamera, 3D-Kamera usw.), die Anzahl der einzelnen Sensortypen, die Auflösung der Sensoren, die Positionen der Sensoren am autonomen Fahrzeug oder andere geeignete Sensorinformationen. Die Abtastrate pro Sensor kann die Abtastrate umfassen, die für jeden Sensor in einer entsprechenden Suite-Konfiguration während des Abtastzeitraums verwendet wird. Zu den Kontextdaten können alle geeigneten Kontextdaten (z. B. Wetter, Verkehr, Szenenänderungen usw.) gehören, die während der Abtastzeitperiode vorliegen. Zu den Daten über die Sicherheitsergebnisse können Sicherheitsdaten über die Abtastzeitperiode gehören. Die Daten über die Sicherheitsergebnisse können beispielsweise Aufschluss darüber geben, ob sich während des Abtastwertzeitraums ein Unfall ereignet hat, wie nahe ein autonomes Fahrzeug während der Abtastzeitperiode einem Unfall gekommen ist oder wie sich die Sicherheit während der Abtastzeitperiode auf andere Weise darstellt.
• Der Algorithmus für maschinelles Lernen 12004 kann ein beliebiger geeigneter Algorithmus für maschinelles Lernen sein, um die Grundwahrheitsdaten zu analysieren und ein Modell 12006 auszugeben, das so abgestimmt ist, dass es Abtastraten für jeden einer Mehrzahl von Sensoren einer gegebenen Sensorreihe auf der Grundlage eines bestimmten Kontexts liefert. Eine Abtastrate für jeden Sensor wird über den Algorithmus für maschinelles Lernen 12004 während einer Trainingsphase gelernt. Zur Erstellung des Ausgabemodells 12006 kann jeder geeignete maschinelle Lernalgorithmus verwendet werden. Als nicht einschränkende Beispiele kann der maschinelle Lernalgorithmus einen Random Forest, eine Support Vector Machine, ein beliebiges geeignetes neuronales Netz oder einen Verstärkungsalgorithmus (wie den unten beschriebenen oder einen anderen Verstärkungsalgorithmus) umfassen. In einer bestimmten Ausführungsform kann das Modell 12006 zusammen mit den Modellen für maschinelles Lernen 256 gespeichert werden.
• Das Ausgabemodell 12006 kann während einer Inferenzphase verwendet werden, um einen Vektor von Abtastraten (z. B. einen für jeden Sensor der verwendeten Sensorreihe) in einem bestimmten Kontext auszugeben. In verschiedenen Ausführungsformen kann das Ausgabemodell 12006 so eingestellt werden, dass die Abtastraten oder die während der Abtastung verbrauchte Leistung so weit wie möglich verringert werden, während gleichzeitig ein akzeptables Sicherheitsniveau aufrechterhalten wird (z. B. keine Unfälle, Einhaltung der Verkehrsvorschriften usw.). In anderen Ausführungsformen kann das Modell 12006 so eingestellt werden, dass es alle geeigneten Betriebseigenschaften wie Sicherheit, Stromverbrauch, Sensordurchsatz oder andere geeignete Eigenschaften begünstigt. In einer bestimmten Ausführungsform basiert das Modell 12006 auf einer gemeinsamen Optimierung zwischen Sicherheit und Stromverbrauch (z. B. kann das Modell versuchen, den Stromverbrauch zu minimieren und gleichzeitig einen Schwellenwert für die Sicherheit einzuhalten).
• Zusätzlich oder alternativ zur Änderung der Abtastrate der Sensoren wird in einigen Ausführungsformen eine Verbesserung der Sensorfusion erreicht, indem die Gewichte für jeden Sensor auf der Grundlage des Kontexts angepasst werden. Der SNR (und folglich die Gesamtvarianz) kann durch eine adaptive Gewichtung der Sensordaten je nach Kontext verbessert werden.
• In einer besonderen Ausführungsform können zur Unterstützung der Objektverfolgung, wenn die Grundwahrheitsdaten für verschiedene Kontexte und die Objektposition zu verschiedenen Zeitpunkten unter diesen verschiedenen Kontexten verfügbar sind, die Fusionsgewichte aus den Trainingsdaten unter Verwendung einer Kombination aus einem Algorithmus für maschinelles Lernen, der den Kontext vorhersagt, und einem Fusionsalgorithmus für die Verfolgung, der die Vorhersage der Objektposition erleichtert, bestimmt werden.
• 120B zeigt einen Algorithmus 12052 für maschinelles Lernen zur Erstellung eines Kontextmodells 12058 in Übereinstimmung mit bestimmten Ausführungsformen. In einer bestimmten Ausführungsform können der maschinelle Lernalgorithmus 12052 und das Kontextmodell 12058 von der maschinellen Lernmaschine 232 oder einer maschinellen Lernmaschine eines anderen Rechnersystems (z. B. 140, 150) ausgeführt werden. 120B zeigt eine Trainingsphase zur Erstellung eines ML-Modells zur Ermittlung des Kontexts. Der Algorithmus für maschinelles Lernen 12052 kann ein beliebiger geeigneter Algorithmus für maschinelles Lernen sein, um die Sensordaten 12056 und die entsprechenden Kontextinformationen 12054 (als Basisinformationen) zu analysieren. Die Sensordaten 12056 können von den Sensoren eines oder mehrerer autonomer Fahrzeuge erfasst werden oder es können simulierte Daten sein. Der Algorithmus für maschinelles Lernen 12052 gibt ein Modell 12058 aus, das so abgestimmt ist, dass es einen Kontext auf der Grundlage von Sensordaten liefert, die von einem in Betrieb befindlichen autonomen Fahrzeug eingegeben werden. Zum Trainieren und Ausgeben des Ausgabemodells 12058 kann jede geeignete Art von maschinellem Lernalgorithmus verwendet werden. Als nicht einschränkende Beispiele kann der maschinelle Lernalgorithmus zur Vorhersage des Kontexts einen Klassifizierungsalgorithmus wie eine Support-Vektor-Maschine oder ein tiefes neuronales Netz umfassen.
• 121 zeigt einen Fusionsalgorithmus 12102 zur Erzeugung eines Fusionskontext-Wörterbuchs 12110 in Übereinstimmung mit bestimmten Ausführungsformen. 121 zeigt die Trainingsphase für die Erstellung eines ML-Modells zur Ermittlung der Sensor-Fusionsgewichte. Der Fusionsalgorithmus 12102 kann ein beliebiger geeigneter Algorithmus für maschinelles Lernen sein, um Sensordaten 12104, entsprechende Kontextinformationen 12106 (als Grundwahrheit) und entsprechende Objektpositionen 12108 (als Grundwahrheit) zu analysieren. Die Sensordaten 12104 können von den Sensoren eines oder mehrerer autonomer Fahrzeuge erfasst werden oder es kann sich um simulierte Daten handeln (z. B. unter Verwendung eines der hier beschriebenen Simulationsverfahren oder anderer geeigneter Simulationsverfahren). In einigen Ausführungsformen können die Sensordaten 12104 die gleichen Sensordaten 12056 sein, die zum Trainieren eines ML-Modells verwendet werden, oder es können zumindest teilweise andere Daten sein. Ebenso können die Kontextinformationen 12106 mit den Kontextinformationen 12054 identisch sein oder sich zumindest teilweise unterscheiden. Der Fusionsalgorithmus 12102 gibt ein Fusionskontext-Wörterbuch 12110 aus, das so abgestimmt ist, dass es Gewichtungen auf der Grundlage von Sensordaten liefert, die von einem betriebsbereiten autonomen Fahrzeug eingegeben werden.
• Zum Trainieren und Implementieren des Fusionskontext-Wörterbuchs kann jeder geeignete Algorithmus für maschinelles Lernen verwendet werden. Als nicht einschränkendes Beispiel kann der maschinelle Lernalgorithmus ein Regressionsmodell zur Vorhersage der Sensorfusionsgewichte umfassen.
• In verschiedenen Ausführungsformen basiert der Fusionsalgorithmus 12102 auf einem neuronalen Netz. Während des Trainings kann der Fusionsalgorithmus 12102 Daten (z. B. Sensordaten 12104) von verschiedenen Sensoren und Grundwahrheits-Kontextinformationen 12106 als Eingabe nehmen, die Daten unter Verwendung verschiedener Gewichtungen zusammenführen, eine Objektposition unter Verwendung der zusammengeführten Daten vorhersagen und eine Kostenfunktion (wie einen quadratischen Fehler des Mittelwerts (RMSE) oder ähnliches) verwenden, die den Fehler zwischen der vorhergesagten Position und der Grundwahrheits-Position (z. B. die entsprechende Position der Objektpositionen 12108) minimiert. In verschiedenen Ausführungsformen kann der Fusionsalgorithmus Fusionsgewichte für einen bestimmten Kontext auswählen, um die Objektverfolgungsleistung zu maximieren. So kann der Fusionsalgorithmus 12102 mit einem Optimierungsalgorithmus trainiert werden, der versucht, ein bestimmtes Merkmal zu maximieren oder zu minimieren (z. B. die Objektverfolgungsleistung), und die resultierenden Gewichte des Fusionskontext-Wörterbuchs 12110 können dann verwendet werden, um neue Datensätze von Sensoren effektiver zu fusionieren, wobei die Ergebnisse der vorhergesagten Bedingungen berücksichtigt werden.
• 122 zeigt eine Inferenzphase zur Bestimmung der selektiven Abtastung und der fusionierten Sensorgewichte in Übereinstimmung mit bestimmten Ausführungsformen. In einer bestimmten Ausführungsform kann die Schlussfolgerungsphase durch das maschinelle Lernsystem 232 und/oder das Sensorfusionsmodul 236 durchgeführt werden. Während der Inferenzphase werden die von einem autonomen Fahrzeug erfassten Sensordaten 12202 dem Kontextmodell 12058 zur Verfügung gestellt. Die Ausgabe des Kontextmodells 12058 ist der Kontext 12206. Der Kontext 12206 kann verwendet werden, um die selektive Abtastung bei 12212 auszulösen. Der Kontext kann beispielsweise dem Ausgabemodell 12006 zur Verfügung gestellt werden, das eine Abtastrate für jeden Sensor einer Mehrzahl von Sensoren des autonomen Fahrzeugs bereitstellen kann. Das autonome Fahrzeug kann dann mit seinen Sensoren Daten mit den festgelegten Abtastraten erfassen.
• Bei 12214 kann eine Interpolation durchgeführt werden. Wenn beispielsweise ein erster Sensor doppelt so oft abgetastet wird wie ein zweiter Sensor und die Abtastwerte des ersten und zweiten Sensors miteinander verschmolzen werden sollen, können die Abtastwerte des zweiten Sensors so interpoliert werden, dass die Zeit zwischen den Abtastwerten für jeden Sensor gleich ist. Jeder geeignete Interpolationsalgorithmus kann verwendet werden. Ein interpolierter Abtastwert kann beispielsweise den Wert des (zeitlich) vorhergehenden aktuellen Abtastwertes annehmen. Ein weiteres Beispiel: Ein interpoliertes Sample kann der Durchschnitt des vorherigen aktuellen Abtastwertes und des nächsten aktuellen Abtastwertes sein. Obwohl sich das Beispiel auf die Fusion auf der Ebene der Sensordaten konzentriert, kann die Fusion zusätzlich oder alternativ auch auf der Ebene der Ausgabe durchgeführt werden. Beispielsweise können bei der Lösung eines Objektverfolgungsproblems verschiedene Ansätze mit unterschiedlichen Sensoren verfolgt werden. In der Post-Analyse-Phase schließlich werden die komplementären Aspekte der einzelnen Ergebnisse zu einem fusionierten Ergebnis kombiniert. In einigen Ausführungsformen kann die Interpolation also auch nach der Zusammenführung der Sensordaten erfolgen.
• Der Kontext 12206 kann auch dem Fusionskontext-Wörterbuch 12110 zur Verfügung gestellt werden, und eine Reihe von Fusionsgewichten 12210 wird aus dem Fusionskontext-Wörterbuch 12110 ausgegeben, wobei jedes Fusionsgewicht ein Gewicht für einen entsprechenden Sensor angibt. Die Fusionsgewichte werden im Modul für Fusionsrichtlinien 12216 verwendet, um die Sensordaten adaptiv zu gewichten und fusionierte Sensordaten 12218 auszugeben. Für die Kombination der Daten von zwei oder mehr Sensoren kann jede geeignete Fusionsstrategie verwendet werden. In einer Ausführungsform legt die Fusionspolitik einen einfachen gewichteten Durchschnitt der Daten von zwei oder mehr Sensoren fest. In anderen Ausführungsformen können auch anspruchsvollere Fusionsstrategien (wie die hier beschriebenen) verwendet werden. So kann beispielsweise ein auf Dempster-Shafer basierender Algorithmus für die Multisensor-Fusion verwendet werden. Die fusionierten Sensordaten 12218 können für jeden geeigneten Zweck verwendet werden, z. B. zur Erkennung von Objektpositionen.
• In verschiedenen Ausführungsformen können Simulationen und Techniken wie Reinforcement Learning auch zum automatischen Erlernen der kontextbasierten Abtaststrategien (z. B. Raten) und Sensor-Fusionsgewichte verwendet werden. Die Bestimmung der Häufigkeit der Abtastung der verschiedenen Sensoren und die Festlegung der Gewichtung dereinzelnen Sensoren ist aufgrund dergroßen Anzahl von Fahrszenarien eine Herausforderung. Die Komplexität der kontextbasierten Abtastung wird auch durch den Wunsch erhöht, verschiedene Ziele wie eine hohe Objektverfolgungsgenauigkeit und einen geringen Energieverbrauch zu erreichen, ohne die Sicherheit zu beeinträchtigen. Simulationsrahmen, die in der realen Welt gesammelte Sensordaten wiedergeben oder virtuelle Straßennetze und Verkehrsbedingungen simulieren, bieten sichere Umgebungen für das Training kontextbezogener Modelle und die Erforschung der Auswirkungen adaptiver Strategien.
• Zusätzlich zu den oben beschriebenen überwachten Lerntechniken können in verschiedenen Ausführungsformen kontextbasierte Abtast- und Fusionsstrategien durch das Trainieren von Verstärkungslernmodellen bestimmt werden, die mehrere Ziele unterstützen (z. B. sowohl Sicherheit als auch Stromverbrauch). In verschiedenen Ausführungsformen kann eines oder mehrere der folgenden Ziele optimiert werden: Objekterkennungsgenauigkeit, Objektverfolgungsgenauigkeit, Stromverbrauch oder Sicherheit. In einigen Ausführungsformen kann ein solches Lernen in einer simulierten Umgebung durchgeführt werden, wenn nicht genügend tatsächliche Daten zur Verfügung stehen. In einer bestimmten Ausführungsform wird mit Hilfe von Verstärkungslernen ein Agent trainiert, dessen Ziel es ist, die Sensorfusionsgewichte und Abtaststrategien zu finden, die den Stromverbrauch reduzieren und gleichzeitig die Sicherheit aufrechterhalten, indem sie Objekte (z. B. Autos und Fußgänger) auf dem Weg des Fahrzeugs genau identifizieren. Während des Trainings kann die Sicherheit eine harte Bedingung sein, so dass ein Schwellenwert für die Sicherheit erreicht wird, während die Verringerung des Energieverbrauchs eine weiche Bedingung ist, die erwünscht, aber nicht notwendig ist.
• 123 zeigt die unterschiedliche Gewichtung der Sensoren für verschiedene Kontexte. Das H in der Tabelle steht für Szenarien, in denen Messungen von bestimmten Sensoren eine höhere Bewertung erhalten. Verschiedene Beispiele zeigen, dass ein LIDAR-Sensor nachts relativ stärker gewichtet wird als ein Kamera-, Radar- oder Akustiksensor, während tagsüber ein Kamerasensor relativ stärker gewichtet werden kann.
• 123 stellt ein Beispiel für Ausgaben dar, die vom Fusionskontext-Wörterbuch 12110 oder von einem hierin beschriebenen Verstärkungslernmodell bereitgestellt werden können (z. B. stellt dieses Beispiel die relativen Gewichte verschiedener Sensoren unter verschiedenen Kontexten dar). In anderen Ausführungsformen können die Sensorgewichtsausgänge numerische Werte anstelle der in 123 gezeigten kategorischen Hoch- bzw. Niedrigbewertungen sein.
• 124A veranschaulicht einen Ansatz zum Erlernen von Gewichten für Sensoren in verschiedenen Kontexten in Übereinstimmung mit bestimmten Ausführungsformen. Zunächst kann für jeden einzelnen Sensor, z. B. Kamera, LIDAR oder Radar, ein Modell trainiert werden, das Objekte so genau wie möglich erkennt. Obwohl für die Objekterkennungsmodelle beliebige geeignete maschinelle Lernmodelle verwendet werden können, handelt es sich in einigen Ausführungsformen bei den Objekterkennungsmodellen um überwachte maschinelle Lernmodelle, wie z. B. tiefe neuronale Netze für Kameradaten, oder um nicht überwachte Modelle wie DBSCAN (Density-based spatial clustering of applications with noise) für LIDAR-Punktwolken.
• Als Nächstes kann ein Modell trainiert werden, um die kontextbasierten Sensorfusionsrichtlinien mithilfe von Reinforcement Learning automatisch zu erlernen. Das Reinforcement-Learning-Modell verwendet die aktuelle Menge der von jedem Sensor erkannten Objekte und den Kontext, um eine Sensorfusionsstrategie zu erlernen. Die Strategie sagt die Sensorgewichte voraus, die bei jedem Zeitschritt anzuwenden sind, um eine Belohnung zu maximieren, die mehrere Ziele umfasst, z. B. die Maximierung der Objektverfolgungsgenauigkeit und die Minimierung des Energieverbrauchs.
• Wie in 124A gezeigt, kann der Agent für den Verstärkungslernalgorithmus (z. B. implementiert durch eine maschinelle Lernmaschine eines Rechensystems) eine Sensorfusionspolitik auf der Grundlage einer Umgebung verwalten, die Sensordaten und Kontext sowie eine Belohnung auf der Grundlage von Ergebnissen wie Verfolgungsgenauigkeit und Energieverbrauch umfasst, und eine Aktion in Form von Sensorgewichtungen erzeugen, die während der Sensorfusion zu verwenden sind. Zur Implementierung des Agenten können beliebige geeignete Algorithmen des Verstärkungslernens verwendet werden, z. B. ein auf Q-Learning basierender Algorithmus.
• In diesem Rahmen kann ein Gewicht für einen bestimmten Sensor in einem bestimmten Kontext mit Null bewertet werden. Ein Gewicht von Null oder ein Gewicht unter einem bestimmten Schwellenwert zeigt an, dass der Sensor für diesen bestimmten Kontext nicht abgetastet werden muss, da seine Ausgabe bei der Sensorfusion nicht verwendet wird. In jedem Zeitschritt erzeugt das Modell einen Vektor mit einem Gewicht pro Sensor für den gegebenen Kontext.
• Eine alternative Implementierung dieses Ansatzes könnte ein Verstärkungslernmodell mit mehreren Agenten (ein Agent pro Sensor) verwenden, bei dem jeder Agent lokale Entscheidungen über Gewichte und Abtastraten trifft, das Modell jedoch versucht, ein globales Ziel (oder eine Kombination von Zielen) zu erreichen, wie z. B. eine höhere Objektverfolgungsgenauigkeit und einen geringeren Stromverbrauch. In einer solchen Ausführungsform kann ein bestimmter Agent bestraft werden, wenn er eine Entscheidung trifft, die das globale Ziel nicht erreicht.
• 124B veranschaulicht einen detaillierteren Ansatz für das Lernen von Gewichten für Sensoren unter verschiedenen Bedingungen in Übereinstimmung mit bestimmten Ausführungsformen. Bei diesem Ansatz wird ein Objekterkennungsmodell 12452 für ein LIDAR und ein Objekterkennungsmodell 12454 für eine Kamera trainiert. In einer besonderen Ausführungsform ist das Objekterkennungsmodell 12454 ein überwachtes maschinelles Lernmodell, z. B. ein tiefes neuronales Netz, und das Objekterkennungsmodell ist ein nicht überwachtes Modell, z. B. DBSCAN für LIDAR-Punktwolken.
• Wie in 124B gezeigt, kann der Agent des Verstärkungslernalgorithmus eine Sensorfusionspolitik 12456 verwalten, die auf einer Umgebung 12458 basiert, die z. B. Kontext, erkannte Objekte, Bodenwahrheitsobjekte, Sensorstromverbrauch und Sicherheit umfasst, sowie eine Belohnung 12460, die auf Ergebnissen wie Erkennungsgenauigkeit, Stromverbrauch und Sicherheit basiert. Eine Aktion 12462 kann in Form von Sensorgewichten 12464 zur Verwendung während der Sensorfusion erzeugt werden. Zur Implementierung des Agenten können beliebige geeignete Algorithmen des Verstärkungslernens verwendet werden, z. B. ein auf Q-Learning basierender Algorithmus.
• 125 zeigt einen Ablauf zur Bestimmung einer Abtastrichtlinie in Übereinstimmung mit bestimmten Ausführungsformen. Bei 12502 werden Sensordaten, die von einer Mehrzahl von Sensoren eines Fahrzeugs abgetastet wurden, erhalten. Bei 12504 wird ein mit den abgetasteten Sensordaten verbundener Kontext ermittelt. Bei 12506 werden eine oder beide Gruppen von Abtastraten für die Sensoren des Fahrzeugs oder eine Gruppe von Gewichtungen für die Sensoren, die für die Fusion der Sensordaten verwendet werden sollen, auf der Grundlage des Kontexts bestimmt.
• In verschiedenen Ausführungsformen kann jedes der oben beschriebenen Inferenzmodule von einem Rechensystem eines autonomen Fahrzeugs oder einem anderen mit dem autonomen Fahrzeug gekoppelten Rechensystem implementiert werden, während jedes der oben beschriebenen Trainingsmodule von einem mit einem oder mehreren autonomen Fahrzeugen gekoppelten Rechensystem (z. B. von einem mit mehreren autonomen Fahrzeugen gekoppelten zentralen Rechensystem) oder von einem Rechensystem eines autonomen Fahrzeugs implementiert werden kann.
• Obwohl die obigen Beispiele in Bezug auf die Objekterkennung beschrieben wurden, können die Konzepte auch auf andere autonome Fahrvorgänge angewendet werden, z. B. auf die semantische Segmentierung und die Objektverfolgung.
• Autonome Fahrzeuge der Stufe 5 („L5“, vollständig autonom) können LIDAR-Sensoren als primäre Sendequelle verwenden, was der wirtschaftlichen Skalierbarkeit für breite Endverbraucher nicht zuträglich ist. Stufe 2 („L2“) oder andere niedrigere autonome Fahrzeuge (mit geringerem Automatisierungsgrad) verwenden dagegen in der Regel Kameras als primäre Erfassungsquelle und können LIDAR in einem progressiven Modus (in der Regel eine kostengünstige Version eines LIDAR-Sensors) zur Informationsredundanz und auch zur Korrelation mit den Kamerasensoren einsetzen. Eine der Informationen, die LIDAR im Vergleich zu Kameras liefert, ist der Abstand zwischen dem Fahrzeug und den Fahrzeugen/Objekten in seiner Umgebung sowie die Höheninformationen der umliegenden Fahrzeuge und Objekte. LIDAR ist jedoch eine der teuersten Sensortechnologien, die in autonome Fahrzeuge eingebaut werden können.
• Dementsprechend kann in einigen Ausführungsformen eine kostengünstige lichtbasierte Kommunikationstechnologie als Ersatz für LIDAR-Sensoren verwendet werden, um Tiefen- und Höheninformationen zu liefern, die das LIDAR liefert, und gleichzeitig die Kosten für den Sensor durch den Ersatz der Informationen zu senken. Solche Kommunikationsmodule können in autonomen Fahrzeugen, Straßenrandeinheiten und anderen Systemen zur Überwachung des Verkehrs und von Ereignissen in einer Fahrumgebung eingesetzt werden. In einigen Fällen kann die Li-Fi- (Light Fidelity-) Technologie genutzt werden, um (in Echtzeit) den genauen Standort jedes Fahrzeugs, die Höhe des Fahrzeugs und andere für die Größe/Höhe des Fahrzeugs relevante Informationen zu übermitteln, die für umliegende Fahrzeuge nützlich sein können, um einen Sicherheitsabstand einzuhalten. Die lichtbasierte Kommunikationstechnologie (z. B. Li-Fi) kann auf verschiedene Fahrzeugtypen, einschließlich Autos, Motorräder und Fahrräder, angewendet werden, indem die Fahrzeuge mit Lichtquellen (z. B. LEDs) und Fotodetektoren ausgestattet werden. Li-Fi kann zwischen verschiedenen Fahrzeugtypen eingesetzt werden (z. B. kann ein Fahrrad LiFi nutzen, um einem Fahrzeug in seiner Umgebung seinen Standort und andere nützliche Informationen zu übermitteln, um den Sicherheitsabstand einzuhalten).
• Li-Fi ist eine aufkommende Technologie für die drahtlose Kommunikation zwischen Geräten, die Licht zur Übertragung von Daten (z. B. Positionsdaten) über Lichtwellen nutzt. Li-Fi kann in Bezug auf die drahtlose Kommunikation als ähnlich wie Wi-Fi angesehen werden (z. B. können ähnliche Protokolle wie IEEE 802.11 Protokolle verwendet werden), unterscheidet sich aber von Wi-Fi dadurch, dass Li-Fi Lichtkommunikation anstelle von Funkwellen verwendet, was eine viel größere Bandbreite ermöglichen kann. Li-Fi kann Hochgeschwindigkeitsdaten über Visible Light Communication (VLC) übertragen, wobei Bandbreiten von Gigabit pro Sekunde (Gbps) erreicht werden können. Li-Fi kann sichtbares Licht zwischen 400THz (780nm) und 800THz (375nm) für die Kommunikation verwenden, in manchen Fällen aber auch Ultraviolett (UV) oder Infrarot (IR).
• 126 ist ein vereinfachtes Diagramm einer beispielhaften VLC- oder Li-Fi-Kommunikation zwischen autonomen Fahrzeugen 12610, 12620 in Übereinstimmung mit mindestens einer Ausführungsform. Im gezeigten Beispiel überträgt eine sendende Lichtquelle (z. B. 12612, 12622) eines Fahrzeugs (z. B. eine mit Leuchtdioden (LEDs) bestückte Lampe des Fahrzeugs) einen modulierten Lichtstrahl (z. B. 12631, 12632) an einen Fotodetektor (z. B. eine Fotodiode) eines anderen Fahrzeugs. Die Fahrzeuge können mit Signalverarbeitungsmodulen (z. B. 12616, 12626) ausgestattet sein, die den ausgesandten Lichtstrahl so modulieren, dass der Strahl eingebettete Daten umfasst (z. B. Positions- oder Höheninformationen für das sendende Fahrzeug, wie oben und weiter unten beschrieben), und die empfangenen Lichtsignale demodulieren. Der Fotodetektor (z. B. 12614, 12624) des empfangenden Fahrzeugs empfängt die Lichtsignale des sendenden Fahrzeugs und wandelt die Amplitudenänderungen in ein elektrisches Signal um (das dann durch Demodulation wieder in Datenströme umgewandelt wird). In einigen Ausführungsformen ist der gleichzeitige Empfang von mehreren Lichtquellen für ein Li-Fi-Gerät durch Fotosensoren möglich, die eine Anordnung von Fotodetektoren (z. B. Fotodioden) umfassen.
• Dies kann auch den Mehrfachempfang von mehreren Kanälen einer Lichtquelle ermöglichen, um den Durchsatz zu erhöhen, oder von mehreren Lichtquellen. Die mehreren Kanäle können als verschiedene Kanäle (Wellenlängen) im Lichtspektrum (sichtbar, infrarot und/oder ultraviolett) implementiert werden.
• Positions- oder andere Fahrzeugdaten (z. B. Höhe des Fahrzeugs, Größe des Fahrzeugs oder andere Informationen, die anderen Fahrzeugen in der Umgebung helfen können, eine Struktur des sendenden Fahrzeugs zu erstellen) können durch Modulation von Lichtwellen übertragen werden. Die Größe der übertragenen Daten kann in der Größenordnung von wenigen Bytes liegen. Die Positionsangaben für das Fahrzeug können beispielsweise etwa 12 Ziffern und 2 Zeichen umfassen, wenn sie dem DMS-Format (Grad, Minute und Sekunde) folgen (z. B. 40° 41' 21,4" N 74° 02' 40,2" W für die nächstgelegene Position zur Freiheitsstatue), was etwa 7-8 Bytes (z. B. 4 Bits für jede Ziffer und 4 Bits für jedes Zeichen des „ASCII-Codes“) in Anspruch nehmen kann. Ein weiteres Beispiel: Für die Höhenangabe des Fahrzeugs (z. B. in Metern mit einer Dezimalstelle) werden etwa 4 Bit an Daten benötigt. Ein weiteres Beispiel ist die Größeninformation für das Fahrzeug (die eine Länge und Breite des Fahrzeugs in Metern umfassen kann), für die etwa 1 Byte Daten für die Länge und 4 Bits Daten für die Breite verwendet werden können (z. B. mit 1-2 Dezimalstellen für die Länge unter Berücksichtigung der Busse und 1 Dezimalstelle für die Breite).
• Für die Kommunikation zwischen den Fahrzeugen kann jedes geeignete Modulationsverfahren verwendet werden. Beispiele für Modulationsverfahren, die in Ausführungsformen der vorliegenden Offenbarung verwendet werden können, sind u. a:
• • On-Off Keying (OOK), eine Form von Amplitude Shift Keying (ASK), bei der LEDs ein- und ausgeschaltet werden können, um eine digitale Folge von Binärzahlen zu modellieren
• • Variable Pulspositionsmodulation (VPPM): M Bits werden codiert, indem ein einzelner Puls in einer von 2M möglichen Zeitverschiebungen übertragen wird. Dies wird alle T Sekunden (variabel) wiederholt, um eine Bitrate (M/T bps) zu erhalten
• • Color-Shift Keying (CSK): wird im IEEE 802.15.7-Standard eingeführt, der definiert, dass Daten im Licht codiert werden, indem eine Mischung aus roten, grünen und blauen LEDs verwendet wird und die Flackerrate jeder LED variiert wird, um Daten zu übertragen
• Die Abtastrate der von einem Fahrzeug übermittelten Positions-, Höhen-, Größen- oder sonstigen Informationen kann in mindestens zwei Formen erfolgen. Die Abtastung kann beispielsweise proaktiv erfolgen, indem jedes Fahrzeug seine Positionsdaten (oder andere Informationen) ständig mit einer bestimmten Frequenz sendet. So kann beispielsweise in stark befahrenen Gebieten, in Gebieten mit hohem Unfallrisiko oder in der Nacht proaktive Abtastung durchgeführt werden. Der Fotodetektor kann in diesem Fall als physikalischer Sensor betrachtet werden, der aus den empfangenen Daten „Tiefen“-Informationen ermittelt, wobei die Sensorfusion ständig die Eingaben des Fotodetektors berücksichtigt. Ein weiteres Beispiel ist die ereignisbasierte Abtastung, bei der jedes Fahrzeug seine Positionsdaten sendet, sobald es ein anderes Fahrzeug in seiner Umgebung entdeckt. Der Fotodetektor kann in diesem Fall als physischer Sensor betrachtet werden, der auf Anforderung „Tiefen“-Informationen aus den empfangenen Daten liefert, wenn ein Verkehrsfahrzeug in der Umgebung erkannt wird, und die Sensorfusion kann Eingaben des Fotodetektors ereignisbasiert berücksichtigen.
• In einigen Fällen kann jedes Fahrzeug vorhandene Lichtquellen (Frontscheinwerfer, Rückscheinwerfer, Seitenscheinwerfer oder LEDs auf dem Dach) nutzen und die Lichtwellen dieser Quellen modulieren, um die erforderlichen Daten mit einer bestimmten Frequenz oder in einer ereignisgesteuerten Form zu übertragen (z. B. wenn die Fahrzeugkameras umliegende Fahrzeuge erkennen oder wenn das Fahrzeug an einer Ampel oder einem Stoppschild anhält).
• 127A-127B sind vereinfachte Diagramme von beispielhaften VLC- oder Li-Fi-Sensorpositionen auf einem autonomen Fahrzeug 12700 gemäß mindestens einer Ausführungsform. 127A zeigt eine Vogelperspektive des autonomen Fahrzeugs 12700, während 127B zeigt eine Seitenansicht des autonomen Fahrzeugs 12700. Das autonome Fahrzeug 12700 umfasst Sensoren 12702, 12703, 12704, 12705, 12706, 12707, 12708. Jeder Sensor kann sowohl eine Lichtquelle (oder mehrere Lichtquellen, z. B. eine Anordnung von LEDs) als auch einen Photodetektor (oder mehrere Photodetektoren, z. B. eine Anordnung von Photodetektoren) umfassen. In einigen Ausführungsformen können vorhandene Lichtquellen der Fahrzeuge (z. B. Frontscheinwerfer (für die Sensoren 12702, 12703), Rücklichter (für die Sensoren 12707, 12708) und Seitenlichter (für die Sensoren 12704, 12705)) genutzt werden, um die Positionsinformationen für jedes Fahrzeug in Echtzeit an alle Fahrzeuge in der Umgebung zu übermitteln. Auf diese Weise kann jedes Fahrzeug den Abstand zu allen umliegenden Fahrzeugen berechnen (anstelle der Tiefeninformationen, die das LIDAR derzeit liefert). Die Höhe kann angegeben werden (ebenso wie die Größe oder andere relevante Informationen, die dabei helfen können, den Sicherheitsabstand einzuhalten und die Umgebung in Echtzeit zu entdecken). Die Sensoren können auch an anderen Stellen des Fahrzeugs angebracht werden, an denen sich keine aktuellen Lichtquellen befinden, z. B. auf dem Dach des Fahrzeugs, wie beim Sensor 12706 gezeigt. Die Sensoren können auch an anderen Stellen des autonomen Fahrzeugs 12700 angebracht werden als denjenigen in 127 Gezeigten.
• 128 ist ein vereinfachtes Diagramm einer beispielhaften VLC- oder Li-Fi-Kommunikation zwischen einem untersuchten Fahrzeug 12810 und einem Verkehrsfahrzeug 12820 in Übereinstimmung mit mindestens einer Ausführungsform. Insbesondere ist 128 zeigt, wie ein autonomes Fahrzeug in seinem Sensorfusionsprozess die Positionsinformationen der umgebenden Verkehrsfahrzeuge berücksichtigt, die von einer Li-Fi-Datenübertragung durch ein Verkehrsfahrzeug stammen (und wie ein Verkehrsfahrzeug die Positionsinformationen des betreffenden Fahrzeugs in seiner Umgebung auf ähnliche Weise erhält). Das betreffende autonome Fahrzeug kann den gleichen Prozess nutzen, um auch andere Li-Fi-Datenübertragungen von anderen Verkehrsfahrzeugen zu verarbeiten (nicht gezeigt).
• Im gezeigten Beispiel ist jedes Fahrzeug mit einem Bildverarbeitungssystem (neben anderen Sensoren) sowie Li-Fi-Sendern (z. B. LEDs und Signalverarbeitungsschaltungen/Software) und Li-Fi-Empfängern (z. B. Fotodetektoren (PD) und Signalverarbeitungsschaltungen/Software) ausgestattet. Wie gezeigt, nimmt das Sensorfusionsmodul/der Sensorstapel in jedem Fahrzeug die üblichen Eingaben vom kamerabasierten Sichtsystem und zusätzliche Eingaben vom Fotodetektor entgegen.
• 129 ist ein vereinfachtes Diagramm eines Beispiels für die Verwendung von VLC- oder Li-Fi-Informationen in einem Sensorfusionsprozess eines autonomen Fahrzeugs in Übereinstimmung mit mindestens einer Ausführungsform. Die Vorgänge im Beispielprozess 12900 können von Komponenten eines autonomen Fahrzeugs (z. B. eines oder beide der autonomen Fahrzeuge von 128) ausgeführt werden. Der Beispielprozess 12900 kann zusätzliche oder andere Vorgänge umfassen, und die Vorgänge können in der gezeigten oder einer anderen Reihenfolge durchgeführt werden. In manchen Fällen können eine oder mehrere der in 12900 gezeigten Operationen als Prozesse implementiert werden, die mehrere Operationen, Unterprozesse oder andere Arten von Routinen umfassen. In einigen Fällen können Vorgänge kombiniert, in anderer Reihenfolge, parallel, iterativ oder auf andere Weise wiederholt oder durchgeführt werden.
• Bei 12902 empfängt ein autonomes Fahrzeug modulierte Lichtsignale von einem anderen Fahrzeug (einem „Verkehrsfahrzeug“). In einigen Fällen kann das autonome Fahrzeug modulierte Lichtsignale von mehreren Verkehrsfahrzeugen empfangen.
• Bei 12904 werden die modulierten Lichtsignale abgetastet. Die Abtastung kann mit einer bestimmten Frequenz erfolgen (z. B. alle paar Millisekunden) oder ansprechend auf ein erkanntes Ereignis (z. B. Erkennung der Anwesenheit eines Verkehrsfahrzeugs in der Umgebung des autonomen Fahrzeugs).
• Bei 12906 werden die abgetasteten Signale demoduliert, um Positions- und Größeninformationen für das Verkehrsfahrzeug zu erhalten. Die Positionsdaten können Informationen über den genauen Standort des Verkehrsfahrzeugs umfassen. Die Positionsdaten können zum Beispiel Geokoordinaten des Verkehrsfahrzeugs in einem DMS-Format oder in einem anderen Format umfassen. Die Größenangaben können Informationen über die Größe des Verkehrsfahrzeugs umfassen und können eine Länge, Breite und/oder Höhe des Verkehrsfahrzeugs (z. B. in Metern) umfassen.
• Bei 12908 werden die bei 12906 gewonnenen Positionsinformationen in einem Sensorfusionsprozess des autonomen Fahrzeugs verwendet. Beispielsweise kann das autonome Fahrzeug die Positionsinformationen in einer Wahrnehmungsphase einer autonomen Fahrpipeline verwenden.
• Die Senkung der Kosten für die zugrundeliegende Technologie und die Komponenten, die für die Umsetzung der Funktionen des autonomen Fahrens verwendet werden, kann als Schlüsselelement betrachtet werden, um das autonome Fahren für den Massenmarkt wirtschaftlich machbar zu machen und seine Einführung im Straßenverkehr zu beschleunigen. Ein Teil der hohen Kosten für autonome Fahrzeuge liegt in der Verwendung von Hochleistungssensoren wie LIDAR-Sensoren, Radarsensoren, Kameras, Trägheitsmesseinheiten (IMU), GNSS-Empfängern (Global Navigation Satellite System) und anderen. Ein Teil der hohen Kosten liegt in der Notwendigkeit einer leistungsstarken Datenverarbeitung, einer Datenkommunikation mit hoher Bandbreite und einer Speicherung großer Mengen. Sowohl die Sensoren als auch die Rechenkapazitäten müssen sehr große Datenmengen in Echtzeit verarbeiten, und zwar auf äußerst robuste Weise, unter Verwendung von Komponenten in Automobilqualität und unter Einhaltung der Normen für funktionale Sicherheit. Ein Teil der hohen Kosten liegt im Entwicklungsprozess für autonome Fahrzeuge.
• Der Entwicklungsprozess für autonome Fahrzeuge und die dazugehörigen Sensoren umfasst in der Regel die Entwicklung, Schulung und Erprobung von Wahrnehmungs-, Planungs- und Steuerungssoftwarealgorithmen und Hardwarekomponenten mit Hilfe verschiedener Simulations- und Feldtestverfahren. Insbesondere können moderne Wahrnehmungssysteme für autonome Fahrzeuge maschinelle Lernmethoden verwenden, die ein Training von Wahrnehmungsalgorithmen (z. B. Computer Vision) erfordern, was zu trainierten Modellen führt, die für die jeweilige Aufgabe und den jeweiligen Sensor spezifisch sind. Moderne, auf maschinellem Lernen basierende Methoden erfordern die Sammlung sehr großer Datensätze sowie einen sehr großen Aufwand, um die wahre Ausgabe des Algorithmus zu erhalten (z. B. „Datenkennzeichnung“), was sehr kostspielig ist. Diese Datensätze sind in der Regel abhängig von dem verwendeten Sensor und den Merkmalen der Daten. Bemühungen, die Wiederverwendung von Wahrnehmungsalgorithmen in anderen Bereichen als denen, für die der Algorithmus ursprünglich entwickelt wurde, zu erleichtern, umfassen die Konzepte des Transferlernens und der Bereichsanpassung. Trotz erheblicher Anstrengungen bleibt die Wiederverwendung dieser Algorithmen ein schwieriges und ungelöstes Problem.
• Ein Ansatz zur Kostensenkung kann die Integration der verschiedenen Teilsysteme für die Verarbeitung von Erfassungs- und Planungsdaten in weniger Rechenkomponenten sein, wodurch der Platz- und Energiebedarf der Verarbeitungspipeline schrittweise verringert und Größenvorteile erzielt werden. Ein weiterer Ansatz zur Kostensenkung besteht darin, die Wiederverwendung weniger Datenverarbeitungskomponenten zu maximieren und gemeinsame Komponenten für die zahlreichen Aufgaben zu verwenden, die in einem einzigen autonomen Fahrzeug und in mehreren autonomen Fahrzeugtypen durchgeführt werden müssen. Dies kann die Verwendung gemeinsamer Wahrnehmungsalgorithmen, gemeinsamer Algorithmus-Trainingsdatensätze und gemeinsamer maschineller Lernmodelle umfassen.
• In einigen Ausführungsformen verwendet eine Datenverarbeitungspipeline gemeinsame Komponenten sowohl für Kameradaten (visuelle Daten) als auch für LIDAR-Daten (Tiefen-/Entfernungs-/Entfernungsdaten), was die Verwendung gemeinsamer Verarbeitungskomponenten sowohl für Kameradaten als auch für LIDAR-Daten ermöglichen kann. Dadurch können die Kosten für die Entwicklung autonomer Fahrzeuge und die Kosten für die Komponenten selbst gesenkt werden.
• In einigen Ausführungsformen können Sensordaten von den rohen physikalischen Eigenschaften, die sowohl Kameradaten als auch LIDAR-Daten aufweisen, in ein normalisiertes Format abstrahiert werden, das eine einheitlichere Verarbeitung der Daten ermöglicht. Diese Techniken können als eine Art Vorverarbeitung angesehen werden, die das Rauschen oder die sensorspezifischen Merkmale der Daten reduzieren kann, während die Genauigkeit der Daten und die darin umfassten wichtigen Szeneninformationen erhalten bleiben. Die daraus resultierenden abstrahierten und normalisierten Daten können Standard-Wahrnehmungskomponenten/-algorithmen (z. B. in einer Wahrnehmungsphase/einem Teilsystem eines Steuerungsprozesses für das autonome Fahrzeug) zur Verfügung gestellt werden, z. B. Objekterkennung, Verkehrszeichenerkennung, Verkehrsampelerfassung, Fahrzeugerkennung oder Fußgängererkennung, die für das autonome Fahren erforderlich sind. Die daraus resultierenden abstrahierten und normalisierten Daten ermöglichen ein einfacheres Transferlernen und eine Domänenanpassung für Wahrnehmungsalgorithmen und andere Verarbeitungskomponenten, die den Zustand der Welt um das autonome Fahrzeug aus den Daten erkennen müssen. Neben der Erkennung kann die Wahrnehmungsphase/ das Teilsystem auch Klassifizierungsfunktionen umfassen, z. B. die Erkennung bestimmter Verkehrszeichen und/oder die Klassifizierung des genauen Typs des Verkehrszeichens oder die Klassifizierung von Fahrzeugen in bestimmte Typen wie Pkw, Lieferwagen, Lkw, Einsatzfahrzeuge und andere. Darüber hinaus kann die Wahrnehmungsphase bzw. das Teilsystem eine Schätzung der Position und der Geschwindigkeit der Verkehrsteilnehmer und anderer Dimensionen ihres Zustands umfassen. Darüber hinaus kann die Wahrnehmungsphase/ das Teilsystem des autonomen Fahrzeugs die Aktionen oder das Verhalten der Verkehrsteilnehmer klassifizieren oder erkennen. Alle diese Funktionen der Wahrnehmungsphase/des Wahrnehmungssystems können von den Besonderheiten des Sensors/der Sensoren abhängig sein und von der Abstraktion der Sensordaten profitieren.
• In einigen Fällen kann die Abstraktion und Normalisierung von Sensordaten eine gemeinsame Verarbeitung verschiedener Sensoren desselben Typs, die in einem einzigen Fahrzeug verwendet werden, ermöglichen. So können in einem einzigen Fahrzeug mehrere Kameratypen verwendet werden (z. B. eine Kombination aus einer oder mehreren derfolgenden Kameras: Perspektivkameras, Fischaugenkameras, Panoramakameras). Die verschiedenen Kameratypen können stark unterschiedliche Sichtfelder oder unterschiedliche Projektionen in die Bildebene haben. Jeder Kameratyp kann auch in bestimmten Konfigurationen im Fahrzeug verwendet werden. Modalitäten wie sichtbares Licht, Infrarotlicht, thermisches Sehen und Bildgebung bei anderen Wellenlängen haben jeweils ihre eigenen Merkmale. Ebenso können mehrere LIDAR-Typen mit unterschiedlichen Eigenschaften an einem Fahrzeug verwendet werden. Dementsprechend können in bestimmten Aspekten der vorliegenden Offenbarung die Sensordaten von den verschiedenen Kameratypen in ein gemeinsames Format abstrahiert werden, und Sensordaten von verschiedenen LIDAR-Typen können ebenfalls in ein gemeinsames Format abstrahiert werden.
• Aspekte der vorliegenden Offenbarung können eine Low-Level-Fusion von Sensordaten innerhalb und zwischen verschiedenen Modalitäten und Sensortypen ermöglichen. Generell umfasst die Low-Level-Sensorfusion für das autonome Fahren und die mobile Robotik die Kombination von Sensordaten aus verschiedenen Modalitäten, die ein sich überschneidendes Sichtfeld haben. In einigen Fällen kann die Sensorfusion zum Beispiel eines oder mehrere der folgenden Elemente umfassen:
• • Kombination von Daten ausschließlich innerhalb des sich überschneidenden Sichtfelds, kann aber auch das Zusammenfügen von Daten aus verschiedenen Sichtfeldern mit einer gewissen Überschneidung umfassen (z. B. Bildmosaik, Erstellung von Panoramabildern).
• • Kombination mehrerer Kamerabilder, die mit einer bestimmten Auflösung aufgenommen wurden, um eine Superauflösung zu erreichen (z. B. Erstellung von Bildern mit einer höheren Auflösung als die Kameraauflösung). Auf diese Weise können kostengünstigere Kameras verwendet werden, um die Auflösung von teureren Kameras zu erreichen.
• • Kombination mehrerer LIDAR-Datenscans zur Erhöhung ihrer Auflösung. Soweit wir wissen, ist die Superauflösung mit LIDAR-Daten ein völlig neues Gebiet.
• • Kombination mehrerer Kamerabilder, die mit einem bestimmten begrenzten Dynamikbereich aufgenommen wurden, um einen höheren Dynamikbereich zu erreichen.
• • Kombination mehrerer Kamerabilder oder mehrerer LIDAR-Scans zur Rauschunterdrückung, z. B. zur Unterdrückung des Rauschens in jedem einzelnen Kamerabild oder LIDAR-Scan.
• • Kombination von Kamera- und LIDAR-Bildern, um eine höhere Erkennungsrate von Objekten zu erreichen, die in beiden Modalitäten vorhanden sind, jedoch mit unabhängigen „Rauschquellen“.
• Eine Ausführungsform ist in 130A gezeigt, die eine Verarbeitungspipeline 13000 für einen einzelnen Strom von Sensordaten 13002, die von einem einzelnen Sensor stammen, veranschaulicht. Durch mehrere Sensorabstraktionsaktionen 13004, 13006, 13008 werden die ursprünglichen Sensordaten in ein „Szenendaten“-Format 13010 umgewandelt und normalisiert. Die Szenendaten werden anschließend einer Erkennungsstufe/einem Algorithmus 13012 zur Verfügung gestellt, der die Erkennung von Fahrzeugen, Fußgängern oder anderen für das autonome Fahren wichtigen Erkennungskomponenten umfassen kann. Die Erkennungsstufe verwendet ein gemeinsames Objektmodell, das in Kombination mit Szenendaten verwendet werden kann, die von mehreren Sensortypen stammen, da die Szenendaten 13010 von den ursprünglichen Sensordaten 13002 abstrahiert wurden. Im Falle eines Modells für maschinelles Lernen, z. B. eines tiefen neuronalen Netzwerkes, eines neuronalen Faltungsnetzes, eines vollständig verbundenen neuronalen Netzwerkes, eines rekursiven neuronalen Netzwerkes usw., werden die Abstraktionsmaßnahmen (13004, 13006, 13008) sowohl beim Training als auch bei der Inferenz angewendet. Der Einfachheit halber zeigt 130A nur die Inferenzphase.
• In einem Beispiel kann ein beispielhafter Sensorabstraktionsprozess eine Aktion (z. B. 13004) zur Normalisierung der Sensorantwortwerte umfassen. Im Falle eines Kamerabildes kann dies beispielsweise die Normalisierung der Pixelwerte (z. B. Graustufen- oder Farbwerte) umfassen. Beispielsweise können verschiedene Kameras eines autonomen Fahrzeugs unterschiedliche Bittiefen haben, wie 8 Bit pro Pixel, 10 Bit oder 12 Bit pro Pixel, oder unterschiedliche Farbräume (oft als RGB oder als YUV (Luminanz, Chrominanz) oder in unterschiedlichen Farbräumen dargestellt). Bei der Normalisierung der Reaktion kann ein Modell der Sensorreaktion (z. B. eine Kamerareaktionsfunktion) verwendet werden, um die Reaktionswerte in einen normalisierten Bereich und eine normalisierte Darstellung zu transformieren. Dies kann auch die Kombination von Kamerabildern, die mit unterschiedlichen Belichtungen aufgenommen wurden, zu einem Bild mit hohem Dynamikbereich ermöglichen (in einigen Ausführungsformen). Die Parameter des Sensorreaktionsmodells können bekannt sein (z. B. aus der Exposition und anderen Sensoreinstellungen) oder aus den Daten selbst geschätzt werden.
• Im Falle von LIDAR können die Sensorrohdaten in Form von Tiefen- oder Entfernungswerten vorliegen. Basierend auf dem horizontalen Winkel (Azimutwinkel) und dem vertikalen Winkel (Elevationswinkel) können die Tiefenwerte in X-, Y- und Z-Punkt-Positionswerte umgewandelt werden. Beispielsweise kann die X-Achse annähernd senkrecht zur Fahrzeuglängsachse, die Y-Achse annähernd parallel zur Fahrzeuglängsachse und die Z-Achse annähernd nach oben, weg vom Boden, gerichtet sein. Für die Objekterkennung sind entweder der rohe Tiefenwert oder ein oder zwei der X,Y,Z-Werte am nützlichsten. Daher können LIDAR-Werte entweder als ein einzelner Skalar oder als ein Paar oder ein Tripel von Werten dargestellt werden. In einigen Ausführungsformen können die Werte selbst in einen normalisierten Bereich umgewandelt werden. In einigen Fällen können LIDAR-Sensoren ein zweidimensionales (2-D) Feld von Tiefen- oder Entfernungswerten über ein horizontales und vertikales Sichtfeld liefern, und das Feld kann die gleiche Form wie ein 2-D-Bild haben. Ein Beispiel für ein solches Bild, das direkt aus LIDAR-Daten gewonnen wurde, ist in FIG dargestellt. 130B. In bestimmten Aspekten der vorliegenden Offenbarung können die LIDAR-Sensordaten in dieser 2-D-Array-Form beibehalten werden, anstatt als Punktwolke dargestellt zu werden. Eine wichtige Folge der Beibehaltung der Daten im 2D-Array ist, dass sowohl Kamera- als auch LIDAR-Daten als 2D-Arrays oder -Bilder dargestellt werden.
• Im weiteren Verlauf dieses Beispiels kann der Sensorabstraktionsprozess durch Verzerren (z. B. 13006) der Sensordaten fortgesetzt werden. In einigen Ausführungsformen kann die Verformungsstufe eine räumliche Hoch- oder Herunterskalierung umfassen. Die räumliche Auflösung eines Kamerabildes oder eines LIDAR-Arrays kann durch einfaches Hochskalieren oder Herunterskalieren verändert werden. Wie in dem in 130B gezeigten Beispiel dargestellt, kann die Auflösung der LIDAR-Sensordaten 13050 in der horizontalen Dimension hoch, aber in der vertikalen Dimension niedrig sein. Zur Erleichterung der Sensorabstraktion, der Sensorfusion und der Objekterkennung mit gemeinsamen Erkennungsmodellen kann es daher wünschenswert sein, die vertikale Auflösung des LIDAR-Arrays zu erhöhen. Eine Methode hierfür ist die Anwendung einer Hochskalierung, wobei dieselben oder ähnliche Techniken wie bei der Bildverarbeitung verwendet werden.
• In einigen Ausführungsformen umfasst die Verzerrung (Warping) auch Korrekturen für geometrische Effekte, die dem Erfassungsprozess eigen sind. Beispielsweise kann die Verzerrung die Unterschiede zwischen perspektivischen Kameras und Fisheye-Kameras ausgleichen. Durch den Verzerrungsvorgang kann ein Fischaugenbild in ein perspektivisches Bild oder ein Panoramabild umgewandelt werden. Auch dies kann zu einem späteren Zeitpunkt ein gemeinsames Erkennungsmodell ermöglichen. Bei der Verzerrung können auch die Konfiguration und die Sichtfelder der Kamera oder des LIDAR-Sensors berücksichtigt werden, was die Kombination von Bildern oder LIDAR-Scans von mehreren Sensoren zu einem Mosaik- oder Panoramabild (auch bekannt als „Image Stitching“) ermöglichen kann.
• In einigen Ausführungsformen kann der Verzerrungsvorgang auch Korrekturen für die Kamerabewegung umfassen, einschließlich der Bewegung aufgrund der Fahrzeugbewegung sowie der unbeabsichtigten Bewegung aufgrund von Vibrationen. Auf diese Weise können mehrere Bilder oder LIDAR-Scans kombiniert werden, die zu leicht unterschiedlichen Zeiten aufgenommen wurden, wobei die Bewegung des Sensors zwischen den beiden Aufnahmezeitpunkten berücksichtigt wird. Die Kombination mehrerer Bilder desselben Motivs ermöglicht eine bessere Auflösung (Superresolution), Rauschunterdrückung und andere Formen der Sensorfusion. Die Parameter der Sensorbewegung und andere erforderliche Parameter können gemessen werden (z. B. mit anderen Sensoren) oder aus den Daten selbst geschätzt werden. Zusammenfassend lässt sich sagen, dass die Verzerrungsaktion viele Arten von geometrischen Unterschieden zwischen Sensordatenströmen berücksichtigen kann und zu einer räumlichen und zeitlichen Ausrichtung (oder Registrierung) der Daten in einer normalisierten Konfiguration führen kann.
• In einigen Implementierungen kann die Sensorabstraktion mit der Anwendung von Filterung (z. B. 13008) auf die Daten fortgesetzt werden. Diese Filterung kann Daten aus einem einzigen Zeitpunkt verwenden oder auch Daten aus früheren und aktuellen Zeitpunkten einbeziehen. So können beispielsweise ein einzelnes Kamerabild oder mehrere Kamerabilder (oder Bildrahmen) verwendet werden.
• In einigen Ausführungsformen kann eine zeitrekursive Filtermethode verwendet werden. Ein zeitrekursiver Bildfilter kann das zuvor gefilterte Bild zum vorherigen Zeitpunkt verwenden und es mit den zum aktuellen Zeitpunkt erfassten Bilddaten kombinieren. Als spezifisches Beispiel kann ein Kalman-Filter (oder eine Variante des Kalman-Filters) verwendet werden. Der Filter (z. B. ein Kalman-Filter oder eine Variante davon) kann eine Vorhersageaktion auf der Grundlage von Daten aus früheren Zeitpunkten und eine Aktualisierungsaktion auf der Grundlage von Daten aus der aktuellen Zeit umfassen. Es können auch andere bekannte Filter verwendet werden, z. B. Partikelfilter, Histogrammfilter, Informationsfilter, Bayes-Filter, Gauß-Filter.
• In einigen Fällen kann die Filterung ein Sensorrauschmodell verwenden, um das Rauschen der verschiedenen Sensortypen, der Kamera und/oder des LIDAR, angemessen zu berücksichtigen und zu unterdrücken. Das Rauschmodell beschreibt die Art und Stärke des Rauschens in den ursprünglichen Sensordaten, wobei die Pipeline-Operationen vor der Filterung (z. B. Reaktionsnormalisierung und Verzerrung) und ihre Auswirkungen auf das Rauschen in den Daten berücksichtigt werden. So wird zum Beispiel die Stärke des Rauschens in den Originaldaten während der Antwortnormalisierung moduliert. Außerdem können die räumlichen Eigenschaften des Rauschens während des Verzerrungvorgangs beeinträchtigt werden. Die Parameter des Sensorrauschmodells können auf Messungen beruhen oder aus den Daten selbst geschätzt werden. Bei der Filterung kann auch ein Szenenmodell verwendet werden, das die Unsicherheit oder das Rauschen erfasst, das die aktuellen Daten aus früheren Daten vorhersagt. So hängt beispielsweise die Beziehung zwischen den Daten zum aktuellen Zeitpunkt und den Daten zum vorherigen Zeitpunkt von der Bewegung des autonomen Fahrzeugs und seiner Sensoren ab. Diese Bewegung kann mit einem gewissen Rest an Unsicherheit oder Rauschen gemessen oder geschätzt werden. Das Szenenmodell trägt dieser Unsicherheit Rechnung. Das Szenenmodell kann auch das Ausmaß signifikanter Schwankungen des wahren Signals beschreiben, die auf die Szene selbst (ohne Rauschen) zurückzuführen sind. Diese Informationen können bei der Filterung verwendet werden, um die Bedeutung der in den Daten beobachteten Abweichungen abzuwägen. Bei der Filterung kann auch ein Sensormodell verwendet werden, das zusätzliche Merkmale umfasst, z. B. Objektiv-, Abbildungs- und Festkörpersensoreigenschaften im Falle von Kameras, was zu räumlicher Unschärfe oder anderen Effekten führen kann. Die Filterung kann die Auswirkungen dieser Merkmale reduzieren oder die Daten auf ein gemeinsames Niveau normalisieren, z. B. auf ein gemeinsames Niveau der Unschärfe. So kann z. B. bei Bildern durch die Filterung der Grad der Unschärfe je nach Situation verringert oder erhöht werden, wobei bekannte Faltungs- oder Entfaltungstechniken zum Einsatz kommen. Das Sensormodell verfolgt auch die Auswirkungen der vorherigen Datenabstraktionsmaßnahmen auf den Grad der Unschärfe in den Daten. Schließlich verfolgt die Filterung den Grad des Rauschens und der Unschärfe in ihrer Ausgabe über die gesamten Ausgabedaten hinweg. Diese Informationen können zum nächsten Zeitpunkt verwendet werden, wenn es sich bei der Filterung um einen zeitlich rekursiven Prozess handelt, z. B. eine Art Kalman-Filterung. Diese Informationen können auch von nachfolgenden Prozessen wie der Sensorfusion der abstrahierten Sensordaten oder der Detektionsphase verwendet werden.
• Die Filteraktionen können auch die Gültigkeit der einzelnen Abtastwerte berücksichtigen und eine Gültigkeits- oder Belegungskarte verwenden, um gültige Abtastwerte zu kennzeichnen. Bei LIDAR-Daten zum Beispiel können einzelne Abtastwerte ungültig sein, wenn ein LIDAR-Rücklauf nicht oder nicht mit ausreichender Signalstärke empfangen wurde. Bei mehreren Sensorbildern oder -anordnungen, die unter verschiedenen Blickwinkeln und mit unterschiedlichem Sichtfeld aufgenommen wurden, können einige Teile eines Bildes oder einer Sensoranordnung als unbrauchbar angesehen werden, z. B. bei der Kombination von Bildern mit sich überschneidenden (aber nicht identischen) Sichtfeldern.
• 131, 132 und 133 zeigen Ausführungsformen von Verarbeitungspipelines für mehrere Ströme von Sensordaten, die von mehreren Sensoren stammen.
• 131 zeigt ein Beispiel für parallele Verarbeitungspipelines 13100 zur Verarbeitung mehrerer Sensordatenströme 13102. Jeder Aspekt der Pipelines 13100 ist derselbe wie der entsprechende Aspekt in der Pipeline 13000, die in 130A gezeigt und oben beschrieben ist, wobei die Sensordaten jeder Pipeline von einem anderen Sensor stammen (Sensoren A und B). Im gezeigten Beispiel wird ein gemeinsamer Erkennungs-/Wahrnehmungsalgorithmus (oder ein trainiertes maschinelles Lernmodell) (z. B. 13112) auf mehr als einen Sensordatenstrom 13102 angewandt, jedoch ohne jegliche Fusionierung. Im gezeigten Beispiel wird das gemeinsame Objektmodell beispielsweise in beide Erkennungsblöcke 13112 der beiden Pipelines 13100 eingespeist. Ein Vorteil der Idee der Datenabstraktion ist, dass der Erkennungs-/Wahrnehmungsalgorithmus auf „abstrahierten“ Daten verschiedener Sensoren trainiert und angewendet werden kann, so dass weniger Kosten/Aufwand für die Entwicklung von Erkennungsalgorithmen für jeden Sensor erforderlich sind.
• 132 zeigt eine Verarbeitungspipeline 13200, in der die Daten von mehreren Sensoren durch die Filterung kombiniert werden. Im gezeigten Beispiel umfasst der Sensorabstraktionsprozess die Normalisierung jedes einzelnen Sensordatenstroms 13202 bei 13204 und die Verzerrung jedes einzelnen Sensordatenstroms 13202 bei 13206, bevor die Ströme bei der Filteraktion 13208 kombiniert werden. Jede Aktion des Sensorabstraktionsprozesses kann auf ähnliche Weise durchgeführt werden wie die entsprechenden Aktionen des Sensorabstraktionsprozesses, die Bezug nehmend auf 130A oben beschrieben sind. Die Filteraktion 13208 kann Sensorrauschmodelle für jeden entsprechenden Sensordatenstrom zusammen mit einem Szenenmodell verwenden, um abstrahierte Szenendaten 13210 zu erzeugen. Die abstrahierten Szenendaten können dann an einen Erkennungsprozess/Algorithmus 13212 zur Objekterkennung weitergeleitet werden. Der Erkennungsprozess/Algorithmus kann in ähnlicher Weise durchgeführt werden wie die Erkennungsstufe/der Algorithmus, die/der oben in Bezug auf 130A beschrieben ist/sind. Die Pipeline 13200 kann z. B. bei der Bildmosaikbildung, der Superauflösung oder der Bildgebung mit hohem dynamischen Bereich eingesetzt werden, wobei mehrere Bilder durch die Filterung kombiniert werden können.
• 133 zeigt eine Verarbeitungspipeline 13300, in der Daten von mehreren Sensoren durch eine Fusionsaktion nach allen oben beschriebenen Aktionen der Sensorabstraktion kombiniert werden. Im gezeigten Beispiel umfasst der Sensorabstraktionsprozess die Normalisierung jedes jeweiligen Sensordatenstroms 13302 bei 13304, die Verzerrung jedes jeweiligen Sensordatenstroms 13302 bei 13306 und die Anwendung der Filterung auf jeden jeweiligen Sensordatenstrom 13303 bei 13208. Jede Aktion des Sensorabstraktionsprozesses kann auf ähnliche Weise durchgeführt werden wie die entsprechenden Aktionen des Sensorabstraktionsprozesses, die in 130A oben beschrieben sind. Die jeweiligen Filteraktionen 13208 für jeden Datenstrom können Sensorrauschmodelle für den entsprechenden Sensordatenstrom zusammen mit einem Szenenmodell verwenden, um abstrahierte Szenendaten 13210 für die jeweiligen Sensordaten zu erzeugen. Die abstrahierten Szenendaten können dann an eine Verschmelzungsstufe 13312 weitergeleitet werden, in der die abstrahierten Szenendaten fusioniert werden, bevor die fusionierten Daten an den Erkennungsprozess/Algorithmus 13214 zur Objekterkennung weitergeleitet werden. Der Erkennungsprozess/Algorithmus kann in ähnlicher Weise durchgeführt werden wie die Erkennungsstufe/der Algorithmus, die/der oben in Bezug auf 130A beschrieben ist/sind. Die Pipeline 13300 kann beispielsweise bei der Fusion von LIDAR- und Kameradaten verwendet werden, wobei die Daten eines LIDAR-Sensors und die Daten einer Kamera vor der Erkennungsphase kombiniert werden.
• Die Vorgänge in den Beispielprozessen in 130, 132, 133 können von verschiedenen Aspekten oder Komponenten eines autonomen Fahrzeugs durchgeführt werden. Die Beispielprozesse können zusätzliche oder andere Vorgänge umfassen, und die Vorgänge können in der gezeigten oder in einer anderen Reihenfolge durchgeführt werden. In manchen Fällen können eine oder mehrere der in 130, 132, 133 gezeigten Operationen als Prozesse implementiert werden, die mehrere Operationen, Unterprozesse oder andere Arten von Routinen umfassen. In einigen Fällen können Vorgänge kombiniert, in anderer Reihenfolge, parallel, iterativ oder auf andere Weise wiederholt oder durchgeführt werden.
• Ein autonomes Fahrzeug kann mit einer Vielzahl unterschiedlicher Sensoren ausgestattet sein, z. B. mit einem oder mehreren LIDARs, Radargeräten, Kameras, globalen Positionierungssystemen (GPS), Trägheitsmesseinheiten (IMU), Audiosensoren, Wärmesensoren oder anderen Sensoren (wie den hier beschriebenen oder anderen geeigneten Sensoren). Diese Sensoren können zur Unterstützung der Wahrnehmung durch das Fahrzeug verwendet werden. Da die Wahrnehmung im Allgemeinen die erste Funktion ist, die im autonomen Fahrzeugstapel ausgeführt wird, wirken sich Fehler in der Wahrnehmung nachteilig auf nachfolgende Funktionen wie Sensorfusion, Lokalisierung, Pfadplanung oder andere Phasen aus. Solche Fehler können zu Unfällen und damit zu einem Vertrauens- und Akzeptanzverlust gegenüber autonomen Fahrzeugen führen. Um Wahrnehmungsfehler zu minimieren, werden in vielen Systemen hochwertige, hochauflösende Kameras und andere Sensoren eingesetzt. Diese hochwertigen Komponenten können jedoch die Kosten für autonome Fahrzeuge erhöhen und den Energieverbrauch steigern, was wiederum die Akzeptanz von autonomen Fahrzeugen verlangsamen kann.
• Verschiedene Ausführungsformen der vorliegenden Offenbarung können dieses Problem durch die Bereitstellung eines skalierbaren Sensoransatzes auf der Grundlage von Hochskalierungsverfahren mit Superauflösung lösen. So können beispielsweise Sensoren mit relativ geringer Auflösung eingesetzt werden. Die von solchen Sensoren erhaltenen niedrig aufgelösten Daten können dann durch den Einsatz von Superresolution-Verarbeitungsmethoden zu hochauflösenden Daten hochskaliert werden. Jede geeignete Methode zur Hochskalierung der Superauflösung kann verwendet werden. Die Hochskalierung kann zum Beispiel durch verschiedene tiefe neuronale Netze, wie tiefe generative Modelle, durchgeführt werden. Als weiteres Beispiel kann die Hochskalierung mit einem Modell durchgeführt werden, das mit Hilfe von Wissensdestillationstechniken trainiert wurde. In verschiedenen Ausführungsformen können solche Netze auf realen Daten trainiert werden, um hochauflösende Daten aus niedrigauflösenden Daten abzuleiten.
• 134 zeigt einen Ablauf zur Erzeugung von Trainingsdaten mit hochauflösenden und entsprechenden niedrigauflösenden Bildern in Übereinstimmung mit bestimmten Ausführungsformen. Der Ablauf kann mit der Erfassung eines hochauflösenden Bildes 13402 (mit hoher Qualität) mit einem oder mehreren hochauflösenden Sensoren beginnen. Bei 13404 wird das hochauflösende Bild dann so umgewandelt, dass es wie ein Bild aussieht, das mit einem oder mehreren Sensoren mit niedriger Auflösung erzeugt wurde (z. B. Bild mit niedriger Auflösung 13406). Die Transformation von hoher in niedrige Auflösung 13404 kann auf jede geeignete Weise durchgeführt werden. In verschiedenen Beispielen können ein oder mehrere Tiefpassfilter auf das hochauflösende Bild angewendet werden (was z. B. zu einer Glättung des Bildes führt), eine Unterabtastung des hochauflösenden Bildes kann durchgeführt werden, Rauschen kann dem hochauflösenden Bild hinzugefügt werden (z. B. Salz- und Pfeffer-Rauschen kann hinzugefügt werden, um Wetterbedingungen zu simulieren (z. B. Regen oder Schnee)), das hochauflösende Bild kann abwärts abgetastet werden, Kanäle (z. B. RGB-Werte) eines Farbbildes können randomisiert werden (z. B. zur Simulation verschiedener Beleuchtungsbedingungen), andere Techniken können durchgeführt werden, oder eine Kombination von Techniken kann von einem Rechensystem (z. B. einem fahrzeuginternen Rechensystem) durchgeführt werden. Der Ablauf von 134 kann beliebig oft mit Daten von beliebig vielen Sensoren durchgeführt werden, um einen umfangreichen Trainingsdatensatz zu erzeugen.
• Zusätzlich oder alternativ können die Trainingsdaten auch durch die gleichzeitige Aufnahme von Bildern mit einem hochauflösenden und einem niedrig auflösenden Sensor gewonnen werden. Die resultierenden Bilder können in Bezug auf Position und Zeit kalibriert werden, so dass die Bilder das gleiche Sichtfeld zur gleichen Zeit darstellen. Jedem Bild mit hoher Auflösung kann also ein Bild mit niedriger Auflösung zugeordnet sein.
• 135 zeigt eine Trainingsphase für ein Modell 13510 zur Erzeugung hochauflösender Bilder aus niedrig aufgelösten Bildern gemäß bestimmten Ausführungsformen. Während der Trainingsphase kann ein auf tiefem Lernen basierendes generatives Netzwerk 13502 hochauflösende Bilder 13506 als Basiswahrheit und entsprechende niedrigauflösende Bilder 13504 erhalten. Das Netzwerk 13502 generiert hochauflösende Bilder 13508 als Ausgabe und vergleicht diese mit den hochauflösenden Bildern 13506 der Grundwahrheit. Der Fehler zwischen einem erzeugten hochauflösenden Bild und dem entsprechenden Wahrheitsbild wird rückwärts propagiert, um die Parameter des Netzes 13502 zu trainieren. In einigen Ausführungsformen basiert der Fehler auf einer Verlustfunktion, die auch die Robustheit gegenüber gegnerischen Angriffen berücksichtigt. Sobald das Modell 13510 trainiert ist, kann es in Fahrzeugen eingesetzt werden, die mit Kameras mit niedriger Auflösung ausgestattet sind (z. B. unter Verwendung einer Inferenzmaschine). Ein besonderer Vorteil dieser Trainingsmethode besteht darin, dass sie keine aufwändige Kennzeichnung der Grundwahrheit erfordert und somit in gewisser Weise unbeaufsichtigt ist.
• In verschiedenen Ausführungsformen kann jedes geeignete maschinelle Lernmodell verwendet werden, um hochauflösende Bilder aus niedrig aufgelösten Bildern zu erzeugen (auch als Bild-Superauflösung bezeichnet). Zum Beispiel kann ein generatives neuronales Netz verwendet werden (wobei ein Gegner vorhanden sein kann oder auch nicht). In einigen Ausführungsformen kann das Modell auf einem Faltungsneuronalen Netz (CNN), einer Nachbarschaftseinbettungsregression, einem Random Forest oder einer anderen geeigneten maschinellen Lernarchitektur basieren. Als verschiedene Beispiele können ein Very-Deep Super-Resolution- (VDSR-) Modell, ein Lernmethode-Single Image Super-Resolution- (SISR-) Modell, ein Rekonstruktionsmethode-SISR-Modell, ein Super-Resolution Convolutional Neural Network (SRCNN) oder jedes andere geeignete Modell verwendet werden.
• 136 zeigt eine Inferenzphase für ein Modell 13510 zur Erzeugung hochauflösender Bilder aus niedrig aufgelösten Bildern gemäß bestimmten Ausführungsformen. Während der Inferenzphase wird ein Bild mit niedriger Auflösung (13602), das von einer oder mehreren Kameras mit niedriger Auflösung aufgenommen wurde, dem generativen Modell (13510) zugeführt. Das generative Modell 13510 verarbeitet das Bild 13602 unter Verwendung der beim Training ermittelten Parameter und gibt ein hochauflösendes Bild 13606 aus. Die vom generativen Modell 13510 erzeugten hochauflösenden Bilder können für die Wahrnehmung oder andere geeignete Blöcke des autonomen Fahrzeugstapels verwendet werden.
• Obwohl sich die obigen Beispiele auf die Verarbeitung von Kamerabilddaten konzentrieren, können ähnliche Methoden der Hochskalierung mit Superresolution auch auf andere Sensordaten, wie z. B. LIDAR-Daten, angewendet werden. LIDAR-Rohdaten können eine Reihe von Tiefen- oder Entfernungsmessungen über ein Sichtfeld umfassen. Die Super-Resolution-Verarbeitung kann auf ein solches zweidimensionales (2-D) Array in ähnlicher Weise wie bei Kamerabilddaten angewendet werden. Wie oben beschrieben, kann ein generatives Netzwerk auf der Grundlage von Deep Learning mit gesammelten hochauflösenden LIDAR-Daten als Basisdaten trainiert werden. Anschließend kann das trainierte Netzwerk in einem autonomen Fahrzeug eingesetzt werden, um LIDAR-Daten mit niedriger Auflösung in hochauflösende LIDAR-Daten umzuwandeln. In bestimmten Ausführungsformen kann ein ähnliches Super-Resolution-Verfahren auch zur Hochskalierung von LIDAR-Daten in einem Punktwolkenformat verwendet werden.
• In verschiedenen Ausführungsformen der vorliegenden Offenbarung können Techniken der Wissensdestillation zur Unterstützung einer skalierbaren Sensorik eingesetzt werden. Wissensdestillation ist eine Technik zur Verbesserung der Genauigkeit eines Schülermodells durch Übertragung von Wissen aus einem größeren Lehrermodell oder einem Ensemble von Lehrermodellen auf den Schüler. Trotz der unterschiedlichen Sensortechnologien von Sensoren wie LIDAR und Kameras gibt es Überschneidungen bei den Merkmalen, die sie erkennen können. So können 3D-Kameras beispielsweise Tiefeninformationen liefern, wenn auch mit einer geringeren Auflösung als LIDAR-Sensoren, die eine hochauflösende 3D-Kartierung einer Szene liefern. Im Allgemeinen sind Modelle, die mit Sensoren mit geringerer Auflösung trainiert wurden, weniger genau als Modelle, die mit Sensoren mit höherer Auflösung trainiert wurden, auch wenn ein menschlicher Beobachter in der Lage sein könnte, Objekte in den Bildern mit geringerer Auflösung korrekt zu identifizieren. In bestimmten Ausführungsformen der vorliegenden Offenbarung kann die Wissensdestillation verwendet werden, um Wissen von einem Ensemble von Lehrermodellen, die mit verschiedenen Arten von hochpreisigen Sensoren (z. B. LIDAR und hochauflösenden Kameras) trainiert wurden, auf Schülermodelle zu übertragen, die kostengünstige Sensoren verwenden (z. B. niedrig auflösende Kameras oder niedrig auflösende LIDARs).
• Während des Trainings überträgt die Wissensdestillation Wissen vom Lehrer auf den Schüler unter Verwendung eines Multitasking-Verlusts, der den Verlust für die primäre Aufgabe des Modells (z. B. Objekterkennung) sowie den Destillationsverlust zwischen der Art und Weise, wie das Lehrernetzwerk seine Merkmale codiert, und der Art und Weise, wie das Schülernetzwerk sie codiert, minimiert. Die Trainingsdaten werden durch die Synchronisierung der Daten mit Hilfe von Kalibrierung und Zeitstempeln erzeugt, um sicherzustellen, dass sowohl die teuren als auch die billigen Sensoren dieselbe Szene betrachten.
• 137 zeigt eine Trainingsphase für das Training eines Schülermodells 13704 unter Verwendung von Wissensdestillation in Übereinstimmung mit bestimmten Ausführungsformen. Zunächst wird ein Lehrermodell, bestehend aus einem Ensemble 13702 von Modellen 13710 und 13712, unter Verwendung der teuren Sensoren 13706 und 13708 trainiert, um Objekte so genau wie möglich zu erkennen. Als nächstes wird das Wissen aus dem Ensemble 13702 der Lehrermodelle 13710 und 13712 auf das Schülermodell 13720 übertragen, indem weiche Ziele 13712 und 13714 aus der Verteilung der vom Ensemble 13702 der Lehrermodelle vorhergesagten Objektwahrscheinlichkeiten berechnet und dazu verwendet werden, dem Schülermodell 13720 beizubringen, wie man Informationen generalisiert. Die Soft-Targets 13712 und 13714 werden in Verbindung mit den Hard-Targets (Vorhersagen 13724) verwendet, die aus den Ground-Truth-Labels 13726 gewonnen werden, um die Genauigkeit des Studentenmodells zu verbessern.
• Für das Modellensemble 13702 oder das Schülermodell 13720 können alle geeigneten Modelle verwendet werden. In bestimmten Ausführungsformen umfasst eines oder mehrere dieser Modelle ein Faltungsneuronales Netz (CNN). In einigen Ausführungsformen umfasst eines oder mehrere dieser Modelle ein rekurrentes neuronales Netz (RNN) (z. B. in einem Segmentierungsmodell, das lernt, wie man Pixel in einer Szene kategorisiert, indem es die Sequenz von Polygonkoordinaten vorhersagt, die Objekte begrenzen). Andere Ausführungsformen können Modelle umfassen, die ein beliebiges geeignetes neuronales Netz oder andere maschinelle Lernmodelle umfassen.
• In einer bestimmten Ausführungsform können die weichen Ziele 13712, 13714 und 13722 aus einer Schicht eines entsprechenden Klassifizierungsalgorithmus (z. B. eines neuronalen Netzwerkes) extrahiert werden, die nicht die endgültige Ausgabe ist. In einem Objekterkennungsmodell kann ein Soft-Target beispielsweise eine oder mehrere Dimensionen eines Begrenzungsrahmens eines Objekts, eine oder mehrere für das Objekt ermittelte Klassen oder eine mit jeder Klasse verbundene Wahrscheinlichkeit (z. B. 0,7 Katze, 0,3 Hund) angeben. In einem Segmentierungsmodell kann ein Soft-Target für jedes Pixel die Softmax-Wahrscheinlichkeit dieses Pixels in Bezug auf verschiedene semantische Kategorien angeben. In einer bestimmten Ausführungsform kann ein Soft Target Informationen aus einer Merkmalskarte einer bestimmten Schicht eines neuronalen Netzwerkes umfassen.
• Die verschmolzenen weichen Ziele 13716 können auf jede geeignete Weise aus den weichen Zielen 13712 und 13714 bestimmt werden. Als verschiedene Beispiele können die weichen Ziele mit Hilfe von gewichteten Mittelwerten, der Dempster-Shafer-Theorie, Entscheidungsbäumen, Bayes'scher Inferenz, Fuzzy-Logik, beliebigen Techniken, die von den hier beschriebenen kontextbasierten Sensorfusionsmethoden abgeleitet sind, oder auf andere geeignete Weise kombiniert werden. In einer Ausführungsform kann eine Vereinigungsoperation für die Begrenzungsrahmen durchgeführt werden, wobei der Bereich, der einem von Modell 13710 vorhergesagten Begrenzungsrahmen und einem von Modell 13712 vorhergesagten Begrenzungsrahmen gemeinsam ist, als der Begrenzungsrahmen des verschmolzenen weichen Ziels in 13716 bestimmt wird. In verschiedenen Ausführungsformen können die weichen Zielscheiben auf jede geeignete Weise miteinander verschmolzen werden.
• Die harte Vorhersage 13724 kann die endgültige Ausgabe des Modells 13720 sein. Die harte Vorhersage 13724 kann zum Beispiel die für ein erkanntes Objekt oder Pixel vorhergesagte Klasse umfassen.
• Der Destillationsverlust 13730 ist die Differenz zwischen den fusionierten Weichzielen 13716, die von den Hochkostensensoren vorhergesagt wurden, und den entsprechenden Weichzielen 13722, die von der Niedrigkostenkamera 13718 vorhergesagt wurden.
• Anstatt das Studentenmodell 13720 nur anhand des Studentenverlusts 13728 zu optimieren, z. B. anhand der Unterschiede zwischen den harten Vorhersagen 13724 und den Grundwahrheitsetiketten 13726, wird ein Multitasking-Verlust (einschließlich des Studentenverlusts 13728 und des Destillationsverlusts 13730) verwendet, um die Parameter des Studentenmodells 13720 einzustellen.
• 138 zeigt eine Inferenzphase für ein Schülermodell, das mit Hilfe der Wissensdestillation gemäß bestimmten Ausführungsformen trainiert wurde. Während der Inferenz erkennt das Schülermodell Objekte nur anhand der Daten von einem oder mehreren kostengünstigen Sensoren, im Falle von Kamerabilddaten. In anderen Ausführungsformen kann ein ähnlicher Inferenzprozess die Eingabe von LIDAR-Daten (z. B. von einem kostengünstigen LIDAR mit geringerer Auflösung) umfassen. In diesem Fall würde das Schülermodell auch mit LIDAR-Daten als Input trainiert werden.
• In verschiedenen Ausführungsformen kann das dargestellte Modell für jeden geeigneten Sensor angepasst werden. Die Elterngruppe 13702 oder das Schülermodell kann irgendeine Anzahl, Qualität und/oder Art von Sensoren umfassen. Das Schülermodell kann zum Beispiel mit Daten eines kostengünstigen LIDAR-Sensors trainiert werden (z. B. mit einer geringeren Auflösung als ein hochauflösender LIDAR-Sensor, der Teil des Lehrer-Ensembles ist). In einer anderen Ausführungsform kann das Schülermodell mit Daten sowohl von einer niedrig auflösenden Kamera 13718 als auch von einem niedrig auflösenden LIDAR (oder einer anderen geeigneten Qualität oder Art von Sensoren) trainiert werden, wobei fusionierte weiche und harte Ziele verwendet werden, um den Schülerverlust 13728 zu bestimmen und mit den fusionierten weichen Zielen 13716 verglichen werden, um den Destillationsverlust 13730 zu bestimmen. In solchen Ausführungsformen kann ein ähnlicher Inferenzprozess für eine Kombination von LIDAR- und Kameradaten verwendet werden, wenn sie in einem Fahrzeug eingesetzt werden.
• In einer besonderen Ausführungsform werden hochauflösende Sensordaten von einem autonomen Fahrzeug erfasst. Die hochauflösenden Sensordaten werden mit Techniken wie Tiefpassfilterung, Unterabtastung oder anderen geeigneten Techniken in niedrigauflösende Sensordaten umgewandelt. Ein generatives maschinelles Lernmodell wird trainiert, um niedrig aufgelöste Sensordaten in hoch aufgelöste Sensordaten umzuwandeln. Während der Inferenz werden Objekterkennungsoperationen an einem Fahrzeug durchgeführt, indem das trainierte generative maschinelle Lernmodell verwendet wird, um Sensordaten mit niedriger Auflösung in hochauflösende Sensordaten umzuwandeln.
• In einer anderen Ausführungsform wird ein Ensemble von Modellen des maschinellen Lernens trainiert, um eine Aufgabe eines autonomen Fahrzeugstapels unter Verwendung hochauflösender Daten von verschiedenen Sensortypen (z. B. Kamera, LIDAR usw.) auszuführen. Das Wissen aus dem Ensemble von Maschinelles-Lernen-Modellen, die mit hochauflösenden Sensordaten trainiert wurden, wird auf ein studentisches maschinelles Lernmodell übertragen, das mit niedrigauflösenden Sensordaten trainiert wurde, indem ein Destillationsverlust zwischen den fusionierten weichen Vorhersagezielen des Ensembles von Maschinelles-Lernen-Modellen und den weichen Vorhersagezielen des studentischen Maschinelles-Lernen-Modells berücksichtigt wird. Während der Inferenz wird die Objekterkennung an einem Fahrzeug mit Hilfe des trainierten Maschinelles-Lernen-Modells für Studenten unter Verwendung von Sensordaten mit niedriger Auflösung durchgeführt.
• 139 zeigt einen Ablauf zur Erhöhung der Auflösung aufgenommener Bilder zur Verwendung bei der Objekterkennung in Übereinstimmung mit bestimmten Ausführungsformen. Bei 13902 werden erste Bilddaten von einem ersten Sensor eines Fahrzeugs erfasst, wobei die ersten Bilddaten eine erste Auflösung haben. Bei 13904 werden die ersten Bilddaten unter Verwendung eines Maschinelles-Lernen-Modells in zweite Bilddaten mit einer zweiten Auflösung umgewandelt, wobei die zweite Auflösung höher ist als die erste Auflösung. Bei 13906 werden Objekterkennungsvorgänge für das Fahrzeug auf der Grundlage der zweiten Bilddaten durchgeführt.
• 140 zeigt einen Ablauf für das Training eines Maschinelles-Lernen-Modells auf der Grundlage eines Ensembles von Methoden in Übereinstimmung mit bestimmten Ausführungsformen. Bei 14002 wird ein Ensemble von Maschinelles-Lernen-Modellen trainiert, um eine Aufgabe eines autonomen Fahrzeugstapels durchzuführen, wobei das Ensemble ein erstes maschinelles Lernmodell, das unter Verwendung von Bilddaten mit einer ersten Auflösung trainiert wurde, und ein zweites maschinelles Lernmodell umfasst. Bei 14004 wird ein drittes maschinelles Lernmodell trainiert, das zumindest teilweise auf einem Destillationsverlust zwischen fusionierten weichen Vorhersagezielen des Ensembles von Maschinelles-Lernen-Modellen und weichen Vorhersagezielen des dritten Maschinelles-Lernen-Modells basiert.
• Es ist allgemein bekannt, dass Menschen nur über begrenzte Wahrnehmungsfähigkeiten verfügen. Einer der möglichen Vorteile autonomer Fahrzeuge ist die Möglichkeit, aufgrund der Anzahl der Sensoren in einem autonomen Fahrzeug eine größere Menge an Informationen über die Straße zu erhalten und damit die Sicherheit zu erhöhen. Doch auch autonome Fahrzeuge mit ihren zahlreichen Sensoren sind anfällig für Fehler und tote Winkel. Es ist wichtig, dass die Wahrnehmungs- und Bewegungsplaner der autonomen Fahrzeuge diese Einschränkungen erkennen und berücksichtigen.
• Entlang der Straßen können LIDARs und Radargeräte installiert sein, die zusätzliche Informationen für die Fahrzeuge auf der Straße liefern können. In ähnlicher Weise passt der Einsatz der kooperativen Sensorik gut zum kooperativen Fahren autonomer Fahrzeuge. So kann beispielsweise das Platooning von Lkw- und Serviceflotten die kooperative Erfassung nutzen, während das kooperative Fahren eingesetzt wird. Ein weiteres Beispiel: Verbraucherfahrzeuge auf der Straße (die sich möglicherweise nicht kennen) können ebenfalls zum kooperativen Fahren beitragen und kooperative Erkennung durchführen.
• 141 zeigt ein Beispiel für eine Situation, in der ein autonomes Fahrzeug die Sensoren verdeckt hat und dadurch eine Fahrsituation potenziell gefährlich wird. Wie man sieht, fährt das Fahrzeug 14105 hinter dem Fahrzeug 14110 her. Angesichts der Größe des Fahrzeugs 14110 ist das Fahrzeug 14115 für das Fahrzeug 14105 verdeckt. In der in 141 dargestellten Situation fährt Fahrzeug 14105 an Fahrzeug 14110 vorbei. Das Fahrzeug 14115 wechselt jedoch gleichzeitig die Fahrspur, und das Fahrzeug 14105 ist sich der möglichen Gefahren dieser Situation nicht bewusst. Wenn ein autonomes Fahrzeug jedoch in der Lage ist, zusätzliche Informationen von umliegenden Fahrzeugen und/oder anderen externen Sensoren zu empfangen, können einige der Gefahren entschärft werden. Darüber hinaus kann die Nutzung anderer Kommunikationsmittel zwischen Fahrzeugen ein noch sichereres Fahrumfeld schaffen.
• Das Konzept der Virtual-Reality-Wahrnehmung sieht vor, dass ein Kraftfahrzeug seine Umgebung mit den Augen der umgebenden Verkehrsteilnehmer sieht, wie z. B. dynamische Autos auf der Straße, Überwachungskameras, Kameras an Kreuzungen oder Abbiegungen, Verkehrsschilder und Ampeln. Diese Informationen können zur Verdeckungserkennung verwendet werden, wenn die Wahrnehmungs- und/oder dynamische Karte eines Fahrzeugs nicht aktuell ist. Darüber hinaus kann die erweiterte Wahrnehmung die Entscheidungsfindung verbessern, indem das Wahrnehmungsfeld in einer Weise erweitert wird, die nicht erreicht werden kann, wenn man sich nur auf die fahrzeugeigenen Sensoren verlässt. So können beispielsweise Informationen von Sensoren, die nicht am Fahrzeug angebracht sind, die Sicherheit erhöhen, wenn sich ein Fahrzeug einem verdeckten Fußgängerüberweg nähert. Die Geschwindigkeit des herannahenden Fahrzeugs kann richtig bestimmt werden, wenn das Kraftfahrzeug nun den verdeckten Zebrastreifen mithilfe der Sensoren anderer Verkehrsteilnehmer sehen kann.
• Systeme und Methoden, die kooperative Sensorik, kooperative Entscheidungsfindung und semantische Kommunikationssprache kombinieren, können die Sicherheit autonomer Fahrzeuge erheblich verbessern. Ein Beispiel für ein System, das die Zusammenarbeit von Fahrzeugen nutzt, ist in dem in 1 gezeigten detaillierten Architekturdiagramm dargestellt. 142. Das System 14200 von 142 kann kooperative Erkennung, Entscheidungsfindung und eine gemeinsame semantische Kommunikationssprache für autonome Fahrzeuge bieten. Bei der kooperativen Erfassung kommunizieren Fahrzeuge mit einem oder mehreren umliegenden Fahrzeugen, um Daten auf der Grundlage der von den Sensoren der jeweiligen Fahrzeuge erfassten Daten zu übermitteln.
• Das Beispiel von 142 zeigt ein System, das zwei Fahrzeuge (V₁ und V₂) umfasst, die miteinander kommunizieren. Nach dem in 142 dargestellten Beispiel umfasst jedes Fahrzeug ein internes Sensormodul 14220, ein erweitertes Sensormodul 14230, ein externes Sensormodul 14210, einen kooperativen Entscheider 14250, ein autonomes Fahrzeug-Entscheidermodul 14240 und ein Trajektorienplanungs- und Ausführungsmodul 14260.
• Die internen Erfassungsmodule 14220 umfassen Erfassungsinformationen eines autonomen Fahrzeugs, wie z. B. Daten, die traditionell von autonomen Fahrzeugen bei der Routenplanung und -ausführung verwendet werden. Die Erfassungsmodule 14220 können beispielsweise Informationen umfassen, die von fahrzeugeigenen Sensoren erfasst werden. Die externen Sensormodule 14210 umfassen Informationen, die von einem anderen Fahrzeug stammen (z. B. kann das Sensormodul 14210 von V1 Informationen umfassen, die von_v2 empfangen wurden) Diese Daten können in jeder Form vorliegen. In einigen Ausführungsformen werden die Daten über semantische Kommunikation ausgetauscht. In verschiedenen Ausführungsformen der vorliegenden Offenbarung ermöglicht eine neuartige semantische Sprache, die von Verkehrselementen (z. B. Fahrzeugen oder straßenseitigen Recheneinheiten) verwendet wird, den Fahrzeugen, ihre Kommunikation in einem schnellen und sicheren Modus zu verwalten. Diese verallgemeinerte Sprache für die Kommunikation im Verkehr kann sowohl Erfassungs- als auch Planungsdaten umfassen und kann von anderen Verkehrskomponenten gemeinsam genutzt werden. Die semantische Kommunikation kann entweder als Broadcast oder auf Anfrage/Antwort-Basis erfolgen. Darüber hinaus kann die semantische Sprache über jedes verfügbare Übertragungsprotokoll, wie z. B. Bluetooth oder ZigBee, übertragen werden. Wenn zwei Fahrzeuge versuchen, alle von ihren Sensoren empfangenen Daten gemeinsam zu nutzen, kann der Umfang der Datenübertragung zu groß sein und die Übertragung und Auswertung zu lange dauern. In einer Situation, in der Entscheidungen sofort getroffen werden müssen, ermöglicht die semantische Kommunikation eine schnelle Verständigung über wichtige Sicherheitsfragen im Straßenverkehr. Die semantische Sprache ermöglicht es den Fahrzeugen beispielsweise, sich gegenseitig Informationen mitzuteilen, z. B. den Standort eines Fahrzeugs oder eines anderen Objekts und ein Bewegungsmuster oder einen Plan für das Fahrzeug oder das Objekt, z. B. einen Plan für den Spurwechsel des Fahrzeugs.
• Die Übertragung der erfassten Daten von einem Fahrzeug zu einem anderen kann, wie oben erwähnt, als kooperative Erfassung betrachtet werden. Autonome Fahrzeuge sind in der Regel mit einer großen Anzahl von Sensoren ausgestattet. Die von diesen Sensoren gelieferten Daten können in Echtzeit mit Computer-Vision-Algorithmen oder LIDAR/RADARbasierten Datenverarbeitungsmethoden analysiert werden. Die Daten von den Sensoren können verarbeitet und analysiert werden, und die Ergebnisse können gemäß den hier vorgestellten Ausführungsformen von den Fahrzeugen gemeinsam genutzt werden. Jeder der physikalischen Sensoren hat seine eigenen Einschränkungen in Bezug auf Reichweite, Sichtfeld, Wetterbedingungen usw. Wie in Bezug auf das Beispiel von 141 gibt es im Straßenverkehr viele Fälle, in denen ein Fahrzeug einen oder mehrere seiner Sensoren verdeckt hat. Die kooperative Erfassung ermöglicht es einem Fahrzeug, die Daten eines anderen Fahrzeugs oder anderer Verkehrsobjekte (z. B. Verkehrssensoren und Kameras entlang der Straße, wie sie in 1 gezeigt sind, oder andere geeignete Sensoren), um das Sichtfeld des autonomen Fahrzeugs zu erweitern.
• Mit Bezug auf das Beispiel von 142 kann das System 14200 auch ein kooperatives Entscheidungsfindungsmodul 14250 in jedem Fahrzeug umfassen. Die kooperativen Entscheidungsfindungsmodule 14250 können Daten empfangen, die sich auf die Entscheidungsfindung eines anderen Fahrzeugs beziehen, wie z. B. eine geplante Route für das Fahrzeug. So kann das autonome Fahrzeug seine eigene Bahnplanung und insbesondere die Bewegungsplanung an den neuen Datensatz anpassen. Die Daten, die sich auf die Entscheidungsfindung eines anderen Fahrzeugs beziehen, können Daten umfassen, die sich auf eine Entscheidung beziehen, die das andere Fahrzeug trifft. Wenn zum Beispiel zwei Fahrzeuge einen Spurwechsel planen, können sie sich gegenseitig warnen, und die beiden Fahrzeuge können ihr Vorgehen entsprechend koordinieren und planen. Die kooperative Entscheidungsfindung kann allgemeiner und zuverlässiger sein als eine reine Verhandlung zwischen autonomen Fahrzeugen und kann in einigen Ausführungsformen zusätzliche von den Fahrzeugen oder anderen Sensoren erfasste Objekte berücksichtigen. Die kooperative Entscheidungsfindung kann es ermöglichen, ein komplexeres Optimierungsproblem zu lösen und das Ergebnis mit umliegenden Verkehrskomponenten (z. B. anderen Fahrzeugen oder Pannenhilfe-Recheneinheiten) zu teilen. In einigen Beispielen kommunizieren die kooperativen Entscheidungsfindungsmodule 14250 über eine semantische Sprache miteinander.
• Kooperative Entscheidungsfindung, kooperative Sensorik und semantische Sprache können es autonomen Fahrzeugen ermöglichen, effizienter und sicherer zu fahren. Zwei wichtige mögliche Kollisionssituationen sind zum Beispiel ein Geschwindigkeitsunterschied zwischen zwei Fahrzeugen und/oder ein geringer Abstand zwischen vorderem und hinterem Fahrzeug. Zeitbasierte Kollisionsindikatoren können mathematisch definiert werden. Solche Indikatoren können verwendet werden, um zwischen sicheren und unsicheren Flugbahnen zu unterscheiden. In einigen Ausführungsformen kann ein Fahrzeug ein umfassendes Bild einer potenziell gefährlichen Situation analysieren, ohne die Berechnung und Analyse der von einem anderen Fahrzeug wahrgenommenen Rohdaten zu wiederholen. Wenn die Datenmenge verdichtet wird, wird eine geringere Bandbreite für die Übertragung der Informationen verwendet. 143 veranschaulicht ein Beispiel für eine Situation, in der mehrere Aktionen von mehreren Fahrzeugen in Betracht gezogen werden. Die Kombination aus kooperativer Entscheidungsfindung, kooperativer Sensorik und semantischer Sprache wird es den Fahrzeugen ermöglichen, in dieser und anderen Situationen sicher zu manövrieren.
• Das System 14200 umfasst auch erweiterte Erfassungsmodule 14230. Diese Module empfangen Sensorinformationen von externen Quellen (z. B. von irgendeiner Quelle außerhalb des Fahrzeugs, wie einer der in 1 Gezeigten). Diese Daten können Sensordaten ergänzen, die von anderen Fahrzeugen über ein externes Sensormodul 14210 und die semantische Kommunikation empfangen werden. In einem Beispiel kann das Modul 14230 einen vollständigen Datenstrom empfangen, der Daten umfasst, die von einem oder mehreren Sensoren eines anderen Fahrzeugs oder Verkehrsagenten in der Nähe erfasst wurden (oder auf Daten basieren, die von diesen erfasst wurden).
• Das autonome Fahrzeug-Entscheidungsmodul 14240 kann autonome Fahrentscheidungen auf der Grundlage der von internen oder externen Sensoren empfangenen Informationen treffen. Gemäß einem Ausführungsbeispiel ist das kooperative Entscheidungsfindungsmodul 14250 vom Entscheidungsfindungsmodul 14240 des autonomen Fahrzeugs getrennt, so dass zusätzliche Informationen vom autonomen Fahrzeug bei seiner Entscheidungsfindung und Planung berücksichtigt werden können.
• Das System 14200 umfasst auch ein Modul 14260 zur Planung und Ausführung von Flugbahnen für jedes Fahrzeug. Das Modul 14260 kann die Fahrentscheidungen ausführen, die von den Modulen 14240 oder 14250, den Entscheidungsträgern des Fahrzeugs, getroffen wurden, oder kann die Flugbahn des Fahrzeugs auf der Grundlage der von diesen Modulen getroffenen Entscheidungen planen.
• Das in 142 beschriebene System ist lediglich repräsentativ für Module, die in bestimmten Ausführungsformen vorkommen können. Andere Ausführungsformen können zusätzliche, hier nicht ausdrücklich erwähnte Module umfassen. Darüber hinaus können ein oder mehrere Module weggelassen oder in anderen Ausführungsformen kombiniert werden.
• Um eine 360-Grad-Sicht auf die Umgebung eines autonomen Fahrzeugs zu erhalten, können verschiedene Systeme zahlreiche Sensoren mit unterschiedlichen Modalitäten umfassen. In manchen Situationen können solche Sensoren zu Redundanzen unter den Sensoren führen. Die größere Anzahl von Sensoren kann jedoch die Hardwarekosten erhöhen (z. B. in Bezug auf den Preis der Sensoren und der zugehörigen Verarbeitungseinheit) und dazu führen, dass der autonome Fahrzeugstapel von einer bestimmten Sensorkonfiguration abhängig ist. Dies behindert die Skalierbarkeit der autonomen Fahrzeuglösung für verschiedene Fahrzeugtypen (z. B. kann ein Kompaktfahrzeug eine Konfiguration verwenden, die sich stark von der Konfiguration eines Sport Utility Vehicle unterscheidet). Wenn feste Sensoren verwendet werden, wird die Sensorkonfiguration (z. B. die Art der Sensoren und die Position der Sensoren am Fahrzeug) für jeden autonomen Fahrzeugtyp angepasst, um eine vollständige Redundanz im Wahrnehmungsbereich um das Fahrzeug herum zu erreichen.
• Verschiedene Ausführungsformen der vorliegenden Offenbarung bieten adaptive Bildsensoren, die ein variables Sichtfeld (FOV) und einen variablen Fokusbereich ermöglichen. Ähnlich wie beim menschlichen Sehsystem können bestimmte Ausführungsformen den Sensoren physische Bewegungen hinzufügen, indem sie eine vertikale und horizontale Drehung der Sensoren ermöglichen (ähnlich wie die Bewegung des Augapfels und des Halses zur Erweiterung des Sichtfeldes). In einer bestimmten Ausführungsform können eine oder mehrere PTZ-Kameras (Pan-Tilt-Zoom) eingesetzt werden, die sich drehen können um größere FOVs abzudecken. Nach der Drehung einer Kamera kann eine Kalibrierungsphase mit Hilfe eines oder mehrerer am Fahrzeug angebrachter Marker durchgeführt werden. In einigen Ausführungsformen kann ein maschineller Lernalgorithmus trainiert werden, um den Kalibrierungsprozess zu automatisieren und die Verwendung der Marker aufzurufen, wenn ein bestimmter Sensor neu kalibriert werden soll. Verschiedene Ausführungsformen beseitigen die Abhängigkeit von der festen Position eines Sensors am Fahrzeug und der Anzahl der redundanten Sensoren, die für eine vollständige Abdeckung des Sichtfelds erforderlich sind. In verschiedenen Ausführungsformen können externe mechanische Verstärkungen und Intelligenz (z. B. Vorverarbeitung der Sensor-Rohdaten) die Funktionalität bereits vorhandener Sensoren erweitern. Verschiedene Vorteile, wie z. B. eine Verringerung der Anzahl der Sensoren, eine Verringerung der zu erfassenden Datenmenge oder eine Verringerung des Energieverbrauchs während der Erfassung, können durch eine oder mehrere der hier beschriebenen Ausführungsformen erreicht werden.
• Das Standard-Sichtfeld einer monokularen Standardkamera beträgt 40o × 30o, was im Zusammenhang mit autonomen Fahrzeugen ein relativ enges und begrenztes Sichtfeld darstellt. Aufgrund dieses eingeschränkten Sichtfelds des Sensors sind in vielen autonomen Fahrzeugen mehrere Sensoren an verschiedenen Positionen angebracht. Abhängig von der Flugbahn eines AV sind die von verschiedenen Sensoren um das Fahrzeug herum erfassten Daten weder gleich wichtig noch haben sie gleich nützliche Informationen. Bei einem AV, das auf einer leeren Autobahn fährt, können die nützlichsten Informationen für das AV von einem oder mehreren nach vorne gerichteten Sensoren gewonnen werden (während die Daten eines hinteren Sensors nicht so wichtig sind, aber gelegentlich überprüft werden können).
• In verschiedenen Ausführungsformen der vorliegenden Offenbarung kann ein Fahrzeug automatisierte mechanische Halterungen für Sensoren umfassen, die es den Sensoren ermöglichen, sich in die Richtungen links, rechts, oben und unten zu drehen. Obwohl der feste Blickwinkel einer Kamera begrenzt sein kann (z. B. auf 40o × 30o), wird durch die Bewegung der mechanischen Halterung das Sichtfeld effektiv vergrößert. So können nützliche Informationen aus der Umgebung eines Fahrzeugs durch die Bewegung des Blicks/der Aufmerksamkeit eines oder mehrerer Sensoren erfasst werden. In bestimmten Ausführungsformen wird die Bewegung des Sensors auf der Grundlage der in der Umgebung des Fahrzeugs erfassten Bewegungen intelligent automatisiert.
• 144 zeigt ein Fahrzeug 14400 mit dynamisch einstellbaren Bildsensoren 14402A-C und Kalibrierungsmarkierungen 14404A-D. Das Fahrzeug 144 kann eines oder mehrere der hier beschriebenen Fahrzeuge (z. B. 105) aufweisen. Die Bildsensoren 14402 können jede geeignete Logik umfassen, um die Funktionalität der Sensoren zu implementieren. Obwohl das Beispiel eine bestimmte Anzahl und Position von Bildsensoren 14402 und Kalibrierungsmarkern 14404 zeigt, können verschiedene Ausführungsformen irgendeine Anzahl von Bildsensoren und Kalibrierungsmarkern umfassen, die an beliebigen geeigneten Stellen des Fahrzeugs angebracht sind.
• In verschiedenen Ausführungsformen sind die Kalibrierungsmarker 14404 am Fahrzeug 14400 angebracht. Die Markierungen 14404 können an der Außenseite des Fahrzeugs an beliebigen geeigneten Stellen angebracht werden. Die Markierungen 14404 können jede geeignete Form haben (z. B. eine kleine Kugel, ein Punkt, ein Zylinder usw.). Die Markierungen können eine Farbe haben, die sich von dem äußeren Teil des Fahrzeugs 14400, an dem die Markierungen angebracht sind, unterscheidet, um die Erkennung bei der Bildaufnahme während der Kalibrierung zu erleichtern. Die spezifischen Positionen der Markierungen und Kameras (und die Abstände zwischen ihnen) können während der Kalibrierung verwendet werden, um das Sichtfeld oder andere Parameter der Bildsensoren 14402 dynamisch anzupassen.
• ansprechend auf ein Steuersignal von einer Steuereinheit (z. B. dem Systemmanager 250) des Fahrzeugs 14400 kann sich ein Bildsensor 14402 in horizontaler und/oder vertikaler Richtung drehen. In einigen Ausführungsformen kann ein Bildsensor 14402 auch auf einer Schiene oder einer anderen mechanischen Vorrichtung montiert werden, so dass der Bildsensor in Reaktion auf ein Steuersignal vertikal oder horizontal verschoben werden kann. Die Bildsensoren 14402 können ansprechend auf jede geeignete Bedingung in jede geeignete Position bewegt werden (z. B. gedreht und/oder in horizontaler und/oder vertikaler Richtung verschoben werden). In der dargestellten Ausführungsform kann das Fahrzeug beispielsweise im Normalbetrieb drei nach vorne gerichtete Kameras 14402A, 14402B und 1440C haben. ansprechend auf einen bevorstehenden Fahrspurwechsel kann der Bildsensor 14402C horizontal gedreht werden, wie in FIG dargestellt. 145 (z. B. um ein Sichtfeld zu erfassen, das sich seitlich und hinter dem Fahrzeug 14400 befindet). Nach Abschluss des Spurwechsels (oder wenn festgestellt wird, dass sich keine potenziell gefährlichen Objekte im Sichtfeld befinden) kann der Bildsensor in seine ursprüngliche Position zurückkehren. Der Sensor 14402B kann auf ähnliche Weise gedreht werden, um die andere Seite des Fahrzeugs ansprechend auf ein Steuersignal zu erfassen. In einem anderen Beispiel kann sich ein Sensor, der normalerweise nach vorne gerichtet ist (z. B. 14402A), in horizontaler Richtung drehen (z. B. um 180 Grad), um periodisch Bilder von der Rückseite des Fahrzeugs 14400 zu erfassen.
• Ein oder mehrere Marker 14404 können verwendet werden, um die Bewegung eines oder mehrerer Bildsensoren 14402 zu kalibrieren. Wenn beispielsweise ein Bildsensor 14402 bewegt werden soll, kann die Steuereinheit Einstellanweisungen bereitstellen (wobei die Anweisungen z. B. direkt Einstelleinheiten oder eine Identifikation einer Sensorkonfiguration umfassen können, die der Bildsensor 14402 in Einstelleinheiten umsetzen kann). In verschiedenen Beispielen können die Anpassungseinheiten einen Grad der horizontalen Drehung, einen Grad der vertikalen Drehung, einen horizontalen Abstand, einen vertikalen Abstand, eine Zoomstufe und/oder andere geeignete Anpassungen umfassen. Der Sensor 14402 kann die angewiesene Einstellung beeinflussen und die Erfassung von Bilddaten (z. B. Bilder oder Videos) einleiten.
• Die Bilddaten des Sensors 14402 werden an das Steuergerät des Fahrzeugs weitergeleitet. Die Steuereinheit kann das Bild verarbeiten und die Position und/oder Größe einer oder mehrerer Markierungen 14404D in den Bilddaten erkennen. Wenn sich die eine oder mehreren Markierungen nicht an der richtigen Stelle im Bild befinden und/oder nicht die richtige Größe haben, kann die Steuereinheit zusätzliche Anpassungsanweisungen ermitteln und diese an den Sensor weitergeben. Weitere Bilderfassungen und Anpassungen können durchgeführt werden, bis die Markierung(en) die gewünschte Größe und/oder die gewünschte Position innerhalb der Bilddaten haben (in einigen Ausführungsformen kann nach der zweiten Anpassung davon ausgegangen werden, dass der Bildsensor ohne zusätzliche Analyse der Markierung(en) eine geeignete Konfiguration aufweist). In verschiedenen Ausführungsformen werden die Anpassungsanweisungen und die Ergebnisse (z. B. in Form der Positionen und Größen der Markierungen in den Bildern) von der Steuereinheit gespeichert und zur Verfeinerung künftiger Anpassungsanweisungen verwendet.
• In bestimmten Ausführungsformen können anstelle von expliziten, in das Fahrzeug 14400 eingebetteten Markern die Konturen des Fahrzeugs als Marker für die Kalibrierung verwendet werden, obwohl solche Ausführungsformen eine intensivere Verarbeitung für die Kalibrierung erfordern können.
• In einigen Ausführungsformen wird die Kalibrierung nicht jedes Mal durchgeführt, wenn ein Sensor 14402 bewegt wird. In anderen Ausführungsformen wird die Kalibrierung nicht jedes Mal durchgeführt, wenn ein Sensor 14402 bewegt wird, sondern z. B. periodisch, einmal alle n-Mal, wenn ein Sensor bewegt wird, oder ansprechend auf die Feststellung, dass eine Kalibrierung sinnvoll wäre.
• In verschiedenen Ausführungsformen kann die Steuereinheit die Bewegung eines oder mehrerer Sensoren in Reaktion auf einen erkannten Zustand des Fahrzeugs steuern. In bestimmten Ausführungsformen können solche Bedingungen auf der Grundlage einer zeitbasierten Analyse von Sensordaten (z. B. von einem oder mehreren Bildsensoren 14402 oder anderen Sensoren des Fahrzeugs oder zugehörigen Sensoren) erkannt werden. In einigen Ausführungsformen kann die Bewegung eines Sensors ansprechend auf eine Bewegung im Sichtfeld eines oder mehrerer Sensoren gesteuert werden (z. B. kann die Bewegung eines bestimmten Bildsensors 14402 angepasst werden, um ein Objekt zu verfolgen, z. B. um ein anderes Fahrzeug zu verfolgen, das das Fahrzeug 100 passiert oder passiert wird). In verschiedenen Ausführungsformen kann die Bewegung ansprechend auf die Erkennung einer Veränderung der Fahrumgebung erfolgen (z. B. können die Sensoren während der Fahrt auf einer Autobahn überwiegend nach vorne gerichtet sein, während sie im Stadtverkehr häufiger zur Seite zeigen). In einigen Ausführungsformen kann eine Bedingung, die zur Steuerung der Sensorbewegung verwendet wird, eine vorhergesagte Bedingung sein (z. B. eine vorhergesagte Einmündung von einer Autobahn in eine Stadt, die auf einer Verlangsamung der Geschwindigkeit, der Erkennung von Objekten, die auf eine Stadtfahrt hinweisen, und/oder auf GPS-Daten basiert). In verschiedenen Ausführungsformen kann maschinelles Lernen eingesetzt werden, um Bedingungen zu erkennen, die die Bewegung eines oder mehrerer Sensoren auslösen.
• 146 zeigt einen Ablauf zum Einstellen eines Bildsensors eines Fahrzeugs in Übereinstimmung mit bestimmten Ausführungsformen. Bei 14602 wird eine Anweisung zur Positionseinstellung für einen Bildsensor eines Fahrzeugs erzeugt. Um 14604 werden Bilddaten vom Bildsensor des Fahrzeugs empfangen. Bei 14606 wird die Position und Größe eines Markers des Fahrzeugs in den Bilddaten erkannt. Bei 14608 wird eine zweite Positionsanweisung für den Bildsensor des Fahrzeugs auf der Grundlage der Position und Größe der Fahrzeugmarkierung in den Bilddaten erzeugt.
• Je nach Autonomiegrad eines autonomen Fahrzeugs kann es notwendig sein, dass der Fahrer während des Betriebs des Fahrzeugs mit dem Fahrer interagiert. Auch wenn ein Fahrzeug normalerweise völlig autonom fahren kann, kann es Situationen geben (z. B. Notfälle), in denen ein menschlicher Fahrer die Kontrolle übernehmen muss. In anderen Situationen kann es wünschenswert sein, dass ein Fahrer die Steuerung eines autonomen Fahrzeugs übernimmt, z. B. wenn der menschliche Fahrer den Wunsch hat zu fahren oder wenn es einen vorteilhaften Grund für eine Person gibt, das Fahrzeug zu steuern. Menschen sind jedoch oft unaufmerksam, lassen sich leicht ablenken und reagieren nur langsam auf bestimmte Situationen. Dementsprechend kann zumindest in einigen Situationen eine Person als Backup bei einer Übergabe in einem autonomen Fahrzeug unzuverlässig sein. Darüber hinaus können die Reaktionszeiten und Reaktionen von Menschen je nach Situation variieren. Manche Menschen haben zum Beispiel eine langsamere Reaktionszeit als andere. Ein weiteres Beispiel: Manche Menschen reagieren in Notsituationen ruhig, während andere in Panik geraten.
• Es kann für das Übergabesystem und -verfahren eines autonomen Fahrzeugs von Vorteil sein, einen personalisierten Ansatz für die Übergabe der Fahrzeugsteuerung an einen Menschen zu implementieren. Solche Systeme und Verfahren können die Sicherheit und Wirksamkeit der Übergabe verbessern. Dies kann insbesondere bei einem autonomen Fahrzeug der Stufe 5 der Fall sein, bei dem der menschliche Fahrer im Allgemeinen nicht benötigt wird. In manchen Situationen kann der menschliche Fahrer schlafen oder abgelenkt sein, was die Gefahr bei einer Übergabe erhöht. Ein personalisierter und koordinierter Ansatz für eine Übergabe kann den Aufmerksamkeitsgrad und/oder das Reaktionsverhalten des Fahrers in solchen Situationen bei der Planung einer Übergabe berücksichtigen.
• In verschiedenen Ausführungsformen kann ein personalisierter und koordinierter Ansatz für Übergaben sowohl bei geplanten als auch bei ungeplanten Übergaben in einem autonomen Fahrzeug angewendet werden. Auch wenn vollständige Autonomie wünschenswert ist, kann es in der Praxis zu Situationen kommen, die die Fähigkeiten eines autonomen Fahrzeugs übersteigen (z. B. kritische Sensorausfälle, unerwartete und plötzliche Änderungen der Straßenbedingungen (z. B. Sturzfluten) usw.).
• Gemäß den hierin umfassten Ausführungsformen können Lösungen für das Übergabeproblem einen mehrgleisigen Ansatz umfassen, der bei der Planung der Übergabe die Aktivität des Fahrers, seine persönlichen Fähigkeiten und die Zielstrecke berücksichtigt. Auf diese Weise kann das System (z. B. das bordeigene Verarbeitungssystem 210) besser beurteilen, ob und wann es die Kontrolle des Fahrzeugs an einen menschlichen Fahrer abgeben sollte. Darüber hinaus können verschiedene Ausführungsformen auch eine Personalisierung des Fahrers im Laufe der Zeit ermöglichen und kontextbezogene Informationsverweise ständig aufrechterhalten, um den Übergabeprozess schrittweise zu verbessern.
• 147 veranschaulicht ein Beispielsystem 14700 für die Übergabe eines autonomen Fahrzeugs an einen menschlichen Fahrer. Das System kann auch als ein System für die sichere, rechtzeitige und adaptive Übergabe eines autonomen Fahrzeugs an einen menschlichen Fahrer betrachtet werden. In einigen Ausführungsformen können die verschiedenen Module durch ein bordeigenes Verarbeitungssystem (z. B. 210) implementiert werden. In anderen Ausführungsformen können eines oder mehrere der Module von einem Cloud-basierten Rechensystem (z. B. 140 oder 150) implementiert werden. Das System 14700 umfasst ein Modul zur Überwachung der Bewohneraktivität 14710, eine personalisierte Datenbank mit den Fähigkeiten der Bewohner 14715, eine allgemeine Datenbank mit den Fähigkeiten der Bewohner 14720, ein Modul zur Vorhersage von Übergaben 14725, ein Modul zur Handhabung von Übergaben 14730 und ein Modul zur Bewertung und Optimierung der Ausführung 14735. Das System 14700 ist lediglich beispielhaft und nicht auf die hier speziell vorgestellten Ausführungsformen beschränkt.
• Das Modul 14710 zur Überwachung der Insassenaktivität („OAM“) extrahiert Informationen über den menschlichen Fahrer eines autonomen Fahrzeugs. In einer bestimmten Ausführungsform implementiert das OAM-Modul 14710 eine Kombination aus regelbasierten, maschinellen Lern- und Deep-Learning-Methoden. Das OAM kann Statusmerkmale in Verbindung mit einem menschlichen Fahrer bestimmen, z. B. die Richtung, in die der Fahrer blickt (z. B. ob die Person mit Blick auf die Straße oder das Heck des Fahrzeugs sitzt), die Position des Fahrersitzes (z. B. der Abstand des Fahrersitzes zum Lenkrad, der Neigungswinkel der Rückenlehne des Sitzes oder andere Merkmale eines Fahrersitzes im Verhältnis zum Lenkrad), ob der Fahrer wach ist oder schläft, ob der Fahrer einer anderen Tätigkeit nachgeht (z. B. lesen, ein Video ansehen, spielen usw.) oder andere Statusmerkmale. Die hier aufgeführten Feststellungen des OAM-Moduls 14710 sind lediglich beispielhaft, und das OAM kann verwendet werden, um alle Merkmale des Fahrers zu bestimmen, die für die Fähigkeit des Fahrers, die vollständige oder teilweise Kontrolle über das Fahrzeug zu übernehmen, als relevant erachtet werden.
• Das OAM-Modul 14710 kann Daten von mehreren verschiedenen Sensoren als Eingabe verwenden. Zu den fahrzeuginternen Sensoren, die dem OAM-Modul 14710 Informationen liefern können, gehören beispielsweise eine Kamera, eine Trägheitsmesseinheit, Sitz- und Rückenlehnensensoren, Ultraschallsensoren oder biometrische Sensoren (z. B. Herzfrequenzmesser, Körpertemperaturmesser usw.). Die Daten von den Sensoren können im Rohformat oder vorverarbeitet sein. Die hier aufgeführten Sensoren sind lediglich beispielhaft, und jede Art von Sensor, ob hier aufgeführt oder nicht, kann als Dateneingang für das OAM-Modul 14710 verwendet werden.
• Die Datenbank 14720 für generische Insassenfähigkeiten („GOC“) kann Daten umfassen, die sich auf statistische Informationen über die Eigenschaften eines generischen Fahrers beziehen, der dem tatsächlichen Fahrer des autonomen Fahrzeugs ähnelt. Zum Beispiel kann die GOC-Datenbank 14720 Informationen für charakteristische Antworten für einen Fahrer umfassen, der ähnliche Merkmale (z. B. Geschlecht, Alter, körperliche Fitness) wie der tatsächliche Fahrer aufweist. Außerdem können die in der Datenbank 14720 gespeicherten Informationen entweder global oder spezifisch für ein oder mehrere bestimmte geografische Gebiete sein. In einigen Ausführungsformen kann die GOC-Datenbank 14720 außerhalb des Fahrzeugs liegen und dem autonomen Fahrzeug über die Cloud zur Verfügung gestellt werden. Die GOC-Datenbank 14720 kann zu jedem geeigneten Zeitpunkt oder in jedem geeigneten Intervall aktualisiert werden, so dass der Übergabebetrieb des autonomen Fahrzeugs im Laufe der Zeit verbessert werden kann. Es ist zu beachten, dass die DOC-Datenbank 14720 aus mehr als einer Datenbank bestehen kann.
• Beispiele für die Arten von Daten in der GOC-Datenbank können die Zeit umfassen, die ein charakteristischer Fahrer (z. B. eine Person mit ähnlichen Merkmalen wie der Fahrer, z. B. Alter, Geschlecht usw.) benötigt, um auf eine Aufforderung zu reagieren, den Sitz um 180 Grad zu drehen, den Sitz in Längsrichtung um eine bestimmte Strecke zu verschieben, die Hände vom Schoß auf das Lenkrad zu legen, sich in Abwesenheit mit der Straße zu verbinden (dies kann von der Aktivität des Fahrers abhängen, bevor er auf das Verbinden aufmerksam gemacht wird), oder andere geeignete Aktivitäten, die mit einer Übergabe verbunden sind. Darüber hinaus können Merkmale des Fahrers (z. B. sein Gesundheitszustand) verwendet werden, um statistische Daten zu erzeugen, die dem Kontext der Fahrersituation entsprechen. In der Datenbank können beispielsweise Informationen erfasst werden, die darauf hinweisen, dass ein durchschnittlicher Fahrer mit demselben Problem im unteren Rückenbereich wie der Fahrer des autonomen Fahrzeugs im Durchschnitt eine bestimmte Zeit benötigt, um den Sitz in eine aufrechte Position zu bringen oder den Sitz in Richtung Lenkrad zu bewegen.
• Neben der Nutzung verfügbarer statistischer Daten können auch maschinelle Lernmodelle, die z. B. vom bordeigenen Verarbeitungssystem 210 implementiert werden, zur Verarbeitung von Rohdaten an Bord des autonomen Fahrzeugs verwendet werden. In anderen Ausführungsformen können solche maschinellen Lernmodelle in der Cloud (und nicht lokal an Bord des autonomen Fahrzeugs) ausgeführt werden, und die Ergebnisse der Schlussfolgerungen können an Bord des Fahrzeugs verwendet werden.
• Die Datenbank 14715 für personalisierte Insassenfähigkeiten („POC“) kann Daten umfassen, die der GOC-Datenbank 14720 ähnlich sind. Die POC-Datenbank umfasst jedoch fahrer- und fahrzeugspezifische Informationen und nicht, wie die GOC-Datenbank, aggregierte Informationen über mehrere Fahrer. Die Daten in der POC-Datenbank 14715 können dazu beitragen, die Funktion des Systems 14700 zu verbessern, da jede Person von der in der GOC-Datenbank 14720 festgelegten Grundlinie abweicht. Die Daten in der POC-Datenbank 14715 können im Laufe der Zeit beobachtet und gemessen werden. Das POC-Modul 14715 des Systems 14700 kann als die zentrale Stelle betrachtet werden, die die Unterschiede zwischen dem Fahrer und dem hypothetischen Fahrer festhält.
• Zusätzlich zu den fahrerspezifischen Informationen kann die POC-Datenbank 14715 auch fahrzeugspezifische Informationen umfassen. Beispielsweise kann die Zeit, die ein Fahrer benötigt, um einen Sitz um 180 Grad zu drehen, von den technischen Möglichkeiten des Fahrzeugs abhängen, und der Fahrer kann diesen Vorgang weder beschleunigen noch verlangsamen.
• In der POC-Datenbank können beispielsweise folgende Arten von Daten gespeichert werden: Der Fahrer braucht X1 Sekunden länger, um auf eine akustische Aufforderung zu reagieren, als der durchschnittliche Fahrer; der Fahrer braucht X2 Sekunden weniger als der Durchschnitt, um seinen Sitz zu drehen (z. B. der Fahrer benötigt X2 Sekunden weniger als der Durchschnitt, um seinen Sitz zu drehen (dies kann z. B. daran liegen, dass das Fahrzeug schnell gewendet werden kann und/oder der Fahrer relativ schnell reagiert), der Fahrer ist X3 Sekunden langsamer als ein durchschnittlicher Fahrer, um seinen Sitz in Längsrichtung zu bewegen, der Fahrer ist X4 Sekunden schneller als der Durchschnitt, um seine Hände auf das Lenkrad zu legen, und der Fahrer ist X5 Sekunden schneller als ein durchschnittlicher Fahrer, um die Straße zu erfassen, wenn er wach ist. Während in diesen Beispielen die Messungen relativ zum durchschnittlichen Fahrer beschrieben werden, können die in der POC-Datenbank gespeicherten Informationen in einigen Ausführungsformen auch absolute Messwerte umfassen (z. B. der Fahrer braucht im Durchschnitt Y1 Sekunden, um auf eine akustische Aufforderung zu reagieren, der Fahrer braucht im Durchschnitt Y2 Sekunden, um seinen Sitz zu drehen usw.). Darüber hinaus kann die POC-Datenbank, ähnlich wie die GOC-Datenbank, andere Merkmale des Fahrers umfassen, die zur Erstellung statistischer Daten verwendet werden können, die mehr Kontext zur Situation des Fahrers liefern können. Die POC-Datenbank kann beispielsweise Informationen darüber umfassen, wie schnell der Fahrer seinen Sitz in eine aufrechte Position bringen oder seinen Sitz aufgrund einer Rückenverletzung nach vorne schieben wird.
• Das Modul HOF (Handoff Forecast; Übergabeprognose) 14725 ermittelt, wann eine Übergabe erforderlich sein könnte. Das HOF-Modul kann Straßenbedingungen wie z. B. Unfälle, überfüllte Straßen, öffentliche Veranstaltungen, Fußgänger, Baustellen usw. berücksichtigen, um festzustellen, wo und wann eine Übergabe von einem autonomen Fahrer an einen menschlichen Fahrer erforderlich sein könnte. Das HOF-Modul kann z. B. lokale Karten- und Routeninformationen mit Echtzeit-Updates zu Verkehr, Unfällen, Gefahren und Straßenwartung empfangen. Teile oder alle diese Informationen können lokal im autonomen Fahrzeug oder in der Cloud gespeichert werden (und das Fahrzeug kann Aktualisierungen dieser Informationen über die Cloud erhalten).
• 148 zeigt eine Beispielroute 14800, die das Fahrzeug 14805 nimmt, um von Punkt A zu Punkt B zu gelangen. Die Route 14800 wurde vom Navigationssystem des Fahrzeugs 14805 (z. B. dem Pfadplanungsmodul 242) ausgewählt. Das HOF-Modul 14725 kann Straßenbedingungen wie Unfälle, überfüllte Straßenabschnitte und Straßenbaustellen berücksichtigen, um festzustellen, wo eine Übergabe an den menschlichen Fahrer erforderlich sein könnte. Bei dem Beispiel von 148 wurden drei Bereiche (14810, 14820 und 14830) festgelegt, in denen eine solche Übergabe erforderlich sein kann. Nachdem die wahrscheinlichen Übergabeorte identifiziert wurden, kann das HOF-Modul 14725 die Orte anhand verschiedener Kriterien einstufen. Beispiele für solche Kriterien können sein:
• 1 - Gibt es eine alternative Route, die möglicherweise weniger vorteilhaft ist, aber keine Übergabe an den menschlichen Fahrer an der angegebenen Stelle erfordert? Zum Beispiel kann der Ort 14820 mit einer alternativen Route 14815 verbunden sein.
• 2 - Kann das autonome Fahrzeug eine identifizierte Übergabestelle durch Verringerung der Geschwindigkeit und/oder bei Bedarf durch Zwischenstopps bewältigen? An der Stelle 14830 beispielsweise sind Straßenbauarbeiten im Gange, die den Verkehr auf kontrollierte und sichere Weise verlangsamen können.
• 3 - Gibt es einen Streckenabschnitt, den das autonome Fahrzeug nicht ohne menschlichen Eingriff bewältigen kann? Zum Beispiel kann der Ort 14810 ein solcher Ort sein, da ein Unfall zu erheblichen Verkehrsbehinderungen geführt haben kann. Das autonome Fahrzeug muss sich vergewissern, dass der menschliche Fahrer darauf vorbereitet ist, wenn er sich diesem Ort nähert.
• In verschiedenen Ausführungsformen kann das HOF-Modul 14725 die Übergabestellen entlang der Route bestimmen und ihre relative Wichtigkeit bewerten (z. B. welche Übergabestellen mit größerer Wahrscheinlichkeit eine Übergabe erfordern).
• Zurück zu 147 kann das Modul 14730 für die Übergabeabwicklung („HOH“) die Informationen über die Übergabe berücksichtigen, um Entscheidungen über die Übergabe zu treffen. Das HOH-Modul 14730 akzeptiert die Ausgaben des OAM-Moduls 14710, der POC-Datenbank 14715, der GOC-Datenbank 14720 und des HOF-Moduls 14725 und trifft Weitergabeentscheidungen auf der Grundlage einer oder mehrerer dieser Daten.
• Schließlich vergleicht das Modul 14735 zur Bewertung und Optimierung der Ausführung („EAO“) das erwartete Ergebnis der Übergabe mit den Handlungen des Fahrers. Die Ergebnisse des Vergleichs werden an die POC-Datenbank 14715 und das HOH-Modul 14730 zurückgemeldet, um die Übergabe in Zukunft zu verbessern. Um die Informationen zu sammeln, kann das EAO-Modul 14735 bei jedem Übergabeereignis entlang der Strecke die folgenden Beispielkriterien verwenden: wie lange der Fahrer brauchte, um auf eine Übergabeaufforderung zu reagieren; ob sich der Fahrer nach der Übergabe innerhalb des erwarteten Lenkbereichs befand; ob die Beschleunigung/Verzögerung des Fahrers nach der Übergabe innerhalb des erwarteten Beschleunigungs-/Verzögerungsbereichs lag; und wie lange der Fahrer brauchte, um kurz nach der Übergabe wieder auf die Straße zu gelangen. Die hier aufgeführten Kriterien sind lediglich beispielhaft, und in verschiedenen Ausführungsformen werden nicht alle Kriterien verwendet oder es können nicht aufgeführte Kriterien verwendet werden.
• Aktualisierungen in der POC-Datenbank 14715 ermöglichen es dem Übergabeprozess, die personalisierten Informationen je nach Fahrer und den technischen Fähigkeiten des autonomen Fahrzeugs zu berücksichtigen. Mit zunehmender Anzahl der Fahrten in einem autonomen Fahrzeug beginnt sich die POC-Datenbank 14715 immer mehr von der GOC-Datenbank 14720 zu unterscheiden.
• Das HOH-Modul 14730 verwendet die vom EAO-Modul 14735 stammenden Rückmeldeinformationen, um zu berechnen, wann und wo der Fahrer Anomalien gegenüber seinem typischen Verhalten gezeigt hat. Dies kann sich von dem unterscheiden, was die POC-Datenbank 14715 für den Fahrer speichert, da es sich auf Abweichungen vom erwarteten Verhalten des Fahrers bezieht und bei künftigen Übergaben berücksichtigt werden kann. Wenn das HOH-Modul 14730 solche Anomalien bei künftigen Übergaben berücksichtigt, kann die Verkehrssicherheit verbessert werden, da das autonome Fahrzeug die Übergabeentscheidungen und die Bewertungen der Übergabeausführung auf der Grundlage von Daten trifft, die für den Fahrer und das autonome Fahrzeug repräsentativer sind, da sie auf realen Beobachtungen beruhen.
• 149 zeigt ein Beispiel für den detaillierten Betriebsablauf 14900 des HOH-Moduls 14730. Dieser Betriebsablauf kann auch als Methode zur Übergabe eines autonomen Fahrzeugs an einen menschlichen Fahrer betrachtet werden. Das Verfahren beginnt damit, dass die ermittelten Übergabeorte vom HOF-Modul 14725 abgerufen werden. Diese können aus den berechneten Prioritäten der Route ermittelt werden.
• Als nächstes fährt die Methode 14900 mit dem Abrufen der allgemeinen Fahrdaten aus der GOC-Datenbank 14720 fort. Es ist zu beachten, dass es nicht unbedingt notwendig ist, allgemeine Fahrdaten zu erhalten. Wenn zum Beispiel eine ausreichende Menge an Daten in der POC-Datenbank 14715 gespeichert ist, können die Daten aus der GOC-Datenbank 14720 bei bestimmten Ermittlungen weggelassen werden. Es sollte auch beachtet werden, dass es möglich sein kann, die personalisierten Daten von einem Ort zum anderen zu übertragen, wie z. B. wenn ein Fahrer ein neues Fahrzeug kauft, können die Informationen vom alten Fahrzeug oder der Cloud auf das neue Fahrzeug übertragen werden.
• Nach dem Erhalt der allgemeinen Daten (falls verwendet), fährt das HOH-Modul mit dem Erhalt der personalisierten Daten aus der POC-Datenbank 14715 fort. Es ist zu beachten, dass es Situationen geben kann, in denen es keine personalisierten Daten gibt, wie z. B. wenn das Fahrzeug ganz neu ist und noch keine Daten erhoben wurden.
• Als Nächstes fährt das Verfahren 14900 mit dem Abrufen von Daten vom OAM-Modul 14710 fort. Diese Daten können Informationen über den Fahrer umfassen, die sich auf seine Aufmerksamkeit, seine Aktivitäten usw. beziehen.
• Das HOH-Modul kann dann das erwartete Fahrerverhalten für jede der möglichen Abgabestellen bestimmen, wie es vom HOF-Modul 14725 festgelegt wurde. Wenn das HOH-Modul 14730 feststellt, dass es Zeit für eine Übergabe ist, wird der Fahrer dazu aufgefordert. Ist dies nicht der Fall, kann das HOH-Modul 14730 feststellen, ob es Echtzeit-Updates von einem der anderen Module gibt. Wenn dies der Fall ist, kann die Aktualisierung oder können die Aktualisierungen verwendet werden, um das erwartete Verhalten des Treibers neu zu bestimmen.
• Um mit dem Beispiel von 149 fortzufahren, nach Aufforderung des Fahrers bestimmt das HOH-Modul 14730, ob der Fahrer in der Lage ist, den Betrieb zu übernehmen. Ist dies der Fall, kann das HOH-Modul dem EAO-Modul 14735 das erwartete Fahrerverhalten mitteilen und dann die Kontrolle über das Fahrzeug an den Fahrer übergeben. Darüber hinaus können vom EAO-Modul 14735 Daten darüber eingeholt werden, wie gut der Fahrer während der Übergabe gearbeitet hat, und das erwartete Fahrerverhalten kann daraufhin aktualisiert werden. Der Fahrer kann die Fahrt fortsetzen, z. B. bis er bereit ist, die Kontrolle abzugeben, oder bis festgestellt wird, dass der AV die Kontrolle sicher wieder übernehmen kann.
• Wenn der Fahrer nicht bereit ist, nach Aufforderung zu übernehmen, kann das HOH-Modul 14730 prüfen, ob es Alternativen zur Übergabe gibt. Dies kann z. B. bedeuten, eine andere Route zu nehmen, langsamer zu fahren, usw. Wenn es Alternativen gibt, kann eine Alternative gewählt werden. Wenn es keine Alternativen gibt, die eine Weiterfahrt des Fahrzeugs ermöglichen, kann das HOH-Modul das Fahrzeug zum Stillstand bringen. Es ist zu beachten, dass dies eine Änderung der gewünschten Route zur Folge haben könnte, um sicherzustellen, dass das Fahrzeug an einem sicheren Ort und auf sichere Weise anhalten kann. Wenn das Fahrzeug zum Stehen kommt, kann es stehen bleiben, bis der Fahrer bereit ist, das Steuer zu übernehmen. Dann kann der Fahrer so lange fahren, bis er bereit ist, das autonome Fahrzeug wieder zu übernehmen, und es sicher ist, dies zu tun. In anderen Ausführungsformen kann das Fahrzeug auch so lange stehen bleiben, bis es eine Alternative gibt, die es erlaubt, das Fahrzeug wieder zu bewegen. Dies kann zum Beispiel eine Änderung der Straßenverhältnisse sein, die das Fahrzeug zum Anhalten veranlasst hat, oder auch eine neue Strecke, die eröffnet wurde.
• Das nachstehende Beispiel veranschaulicht den Betrieb des HOH-Moduls 14730 unter Verwendung des Beispielbetriebsablaufs von 149 in Kombination mit dem Beispiel der Route von 148.
• Vor der Reise:
• 1. Die optimale Route (14800) zwischen A und B wurde berechnet und dem HOF-Modul zur Verfügung gestellt.
• 2. Das HOF-Modul 14725 verwendet die Echtzeit-Updates, um die drei Übergabebereiche (14810, 14820 und 14830) zu identifizieren
• 3. Das HOF-Modul entscheidet, dass an der Stelle 14810 am ehesten Fahrerunterstützung benötigt wird (weil es an dieser Stelle nur wenige Informationen über den Unfall gibt)
• 4. Der Standort 14830 wurde als nächster wahrscheinlicher Standort ausgewählt, an dem aufgrund der laufenden Straßenbauarbeiten eine weitere Übergabe erforderlich sein könnte.
• 5. Der Standort 14820 ist ein weiterer potenzieller Umsteigebereich, in dem ein erhöhter Fußgängerverkehr auf der Straße zu beobachten ist. Das autonome Fahrzeug kann diesen Abschnitt der Fahrt problemlos bewältigen, indem es eine alternative Route 14815 nimmt, ohne dass der Fahrer eingreifen muss.
• 6. Die GOC-Datenbank 14720 liefert dem HOH-Modul 14730 die allgemeinen Informationen über die Fahrer.
• 7. Die POC-Datenbank ist leer (da der Fahrer sein Kraftfahrzeug gerade erst gekauft hat und nur wenige personalisierte Informationen zu seiner Person vorliegen).
• 8. Das OAM-Modul 14710 bestätigt, dass der Fahrer hinter dem Steuer sitzt und sein Sohn auf dem Rücksitz.
• 9. Das Modell des Fahrzeugs, das der Fahrer fährt, hat einen vollständig drehbaren Fahrersitz, damit er während der Fahrt frei mit den Fahrgästen auf dem Rücksitz interagieren kann. Der Fahrer wendet also der Straße den Rücken zu und beginnt, mit seinem Sohn zu sprechen.
• 10. Die Innenraumkameras haben eine vollständige Abdeckung des Geschehens in der Kabine, so dass das OAM-Modul 14710 über diese Gesprächsaktivität sowie die Sitzposition des Fahrers in Echtzeit informiert wird. Das OAM-Modul 14710 stellt außerdem fest, dass der Fahrer seinen Sitz während des Gesprächs etwas näher an seinen Sohn herangerückt hat und sich nach vorne lehnt.
• Während der Reise:
• 11. Das autonome Fahrzeug beginnt, sich in Richtung der ersten Abgabestelle 14810 zu bewegen. Da diese erste Übergabestelle die kritischste ist und das Fahrzeug den Eingriff des Fahrers erfordert, beginnt das HOH-Modul 14730, den Fahrer frühzeitig über eine bevorstehende Übergabe zu informieren.
• 12. Das HOH-Modul 14730 weiß, wie lange der Fahrer voraussichtlich brauchen wird, um sich umzudrehen und die Hände ans Lenkrad zu legen.
• 13. Das HOH-Modul 14730 weiß auch aus der GOC-Datenbank 14720, dass es im Allgemeinen länger dauert, bis ein älterer Fahrer voll aufmerksam wird als ein jüngerer Fahrer. Wenn es sich bei dem Fahrer beispielsweise um einen 50-jährigen Mann handelt, kann es 15 bis 20 Sekunden dauern, bis sich der Fahrer des Fahrkontextes voll bewusst wird, sobald er die Hände ans Lenkrad legt. Daher wird diese zusätzliche Zeit auch vom HOH-Modul 14730 berücksichtigt, wenn sich die Übergabe am Standort 14810 nähert.
• 14. Das HOH-Modul 14730 übermittelt auch die erwarteten Reaktionszeiten des Triebfahrzeugführers an das EAO-Modul 14735, damit dieses beurteilen kann, wie die Übergabe durchgeführt wird. Der Fahrer reagiert auf die Aufforderung des Fahrzeugs, das Fahrzeug abzugeben, und lenkt das Kraftfahrzeug erfolgreich durch den Unfall auf der Straße.
• 15. Nachdem der Fahrer den Unfallort verlassen hat, übergibt er an das autonome Fahrzeug, als er einen Anruf auf seinem Smartphone erhält.
• 16. Das EAO-Modul 14735 beginnt an der Stelle 14810 mit der Bewertung der Übergabe. Es scheint, dass der Fahrer 10 Sekunden später geantwortet hat, als vom HOH-Modul 14730 erwartet wurde. Der Zeitstempel auf dem OAM-Modul 14710 deutet darauf hin, dass der Fahrer zu dem Zeitpunkt, als er die Kontrolle über das Fahrzeug erhalten sollte, damit beschäftigt war, seinem Sohn ein Spielzeug zu übergeben, was zu dieser unerwarteten Verzögerung führte.
• 17. Diese Anomalie wird an das HOH-Modul 14730 zurückgemeldet, um zusätzliche Zeit für geplante Übergaben zu haben.
• 18. Die Leistung des Treibers während der Übergabe wurde auch an das POC-Modul 14715 für interne Aktualisierungen zurückgemeldet.
• 19. Während sich das Fahrzeug der Übergabe 14820 nähert, bestätigt das OAM-Modul 14710, dass der Fahrer immer noch telefoniert und Signale eines erhöhten Notstands zu geben scheint.
• 20. Das HOH-Modul 14730 weiß, dass der Übergabeort 14820 vermieden werden kann, indem die alternative Route 14815 befolgt wird. Diese Route verlängert die Fahrt um 2 Minuten, ermöglicht es dem Fahrer aber, sein Telefongespräch ohne Unterbrechung fortzusetzen.
• 21. Das HOH-Modul 14730 beschließt, an der Stelle 14820 keine Übergabe anzufordern, und das Fahrzeug fährt autonom weiter.
• 22. Das HOH-Modul 14730 ist sich der Straßenbauarbeiten am Übergabeort 14830 bewusst, und obwohl die Übergabe an diesem Ort nicht so kritisch ist wie am Ort 14810, kann die Fahrtzeit durch menschliches Eingreifen etwas kürzer sein.
• 23. Das OAM-Modul 14710 zeigt an, dass der Fahrer nicht mehr telefoniert, sondern lässig nach vorne schaut und den Verkehr vor dem Kraftfahrzeug beobachtet.
• 24. Das HOH-Modul 14730 entscheidet, dass der Fahrer möglicherweise ohne weiteres übernehmen kann und meldet ihm eine optionale Übergabe, um Fahrzeit zu sparen.
• 25. Nachdem der Fahrer beschlossen hat, dass es eine gute Idee ist, ein paar Minuten zu sparen, indem er übernimmt, stimmt er der Übernahme zu, und die Übergabe am Standort 14830 wird erfolgreich durchgeführt.
• 26. Das POC-Modul 14715 wird nach der Übergabe durch das EAO-Modul 14735 aktualisiert, und da keine Anomalien festgestellt wurden, erhält das HOH-Modul 14730 diesmal keine Benachrichtigungen.
• 27. Für den Rest der Fahrt beschließt der Fahrer, nicht zu übergeben und fährt im manuellen Modus zu seinem Ziel.
• Das obige Beispiel ist lediglich beispielhaft, und es können mehr oder weniger, ja sogar andere Maßnahmen ergriffen werden. In ähnlicher Weise ist das Beispielverfahren von 149 ebenfalls beispielhaft, und es können mehr oder weniger Schritte dieser Methode durchgeführt werden.
• Es sollte auch beachtet werden, dass es Situationen geben kann, in denen das autonome Fahrzeug keine andere Wahl hat, als den menschlichen Fahrer zu übergeben (um die ursprünglichen Ziele der Fahrt in Bezug auf Routen, Ankunftszeit usw. zu erfüllen), während der menschliche Fahrer nicht in der Lage ist, zu übernehmen. In solchen Szenarien kann das autonome Fahrzeug die folgenden sichereren Optionen wählen: anhalten und sicheres Anhalten bis zu einem Zeitpunkt, an dem der menschliche Fahrer übernehmen kann; Anhalten auf der Langsamfahrspur und Reduzieren der Fahrgeschwindigkeit entsprechend dem Verkehr und den Straßenverhältnissen auf Kosten einer längeren Fahrzeit; Berechnen alternativer Routen, die es dem Fahrzeug ermöglichen, ohne Übergabe weiterzufahren (solche Routen können länger und/oder langsamer sein); oder Berechnen alternativer Routen, die es dem Fahrzeug nicht ermöglichen, ohne Übergabe bis zum endgültigen Ziel weiterzufahren, aber es dem Fahrzeug ermöglichen, sicher anzuhalten bis zu einem Zeitpunkt, an dem der menschliche Fahrer bereit ist, zu übernehmen. Diese Lösungen sind lediglich beispielhaft, und es kann auch andere Lösungen für eine obligatorische Übergabe des Fahrzeugs geben.
• Der Grad der Autonomie eines autonomen Fahrzeugs hängt stark von der Anzahl und Art der Sensoren ab, mit denen das autonome Fahrzeug ausgestattet ist. Darüber hinaus werden viele der verschiedenen Funktionen des autonomen Fahrzeugs, wie z. B. das autonome Fahren auf der Autobahn, durch eine bestimmte Anzahl gut funktionierender Sensoren erreicht, die dem autonomen Fahrzeug die entsprechenden Informationen liefern, die von den Algorithmen der Fahrzeugsteuerungssysteme verarbeitet werden.
• Da die Sensoren eine so wichtige Rolle beim Betrieb autonomer Fahrzeuge spielen, ist es wichtig, dass der Zustand der verschiedenen Sensoren bekannt ist. Neben dem Sicherheitsaspekt des Sensorzustands (bei einem Sensorausfall besteht die Gefahr, dass das Fahrzeug nicht mehr autonom fahren kann) gibt es noch weitere Vorteile, wenn man den Zustand der Sensoren des Fahrzeugs kennt. So kann beispielsweise das Vertrauen des Fahrers/Beifahrers gestärkt und die Effizienz des autonomen Fahrzeugs verbessert werden.
• Mit der Verbesserung der Technologie für autonome Fahrzeuge steigt auch die Zahl der Sensoren in diesen Fahrzeugen. Um beispielsweise die Automatisierungsstufe 3 zu erreichen, haben einige Automobilhersteller ein Fahrzeug mit 14 oder mehr Sensoren ausgestattet. 150 zeigt ein Beispiel für Sensoranordnungen, wie sie in autonomen Fahrzeugen üblich sind. Zu den Sensoren gehören z. B. Radar, LIDAR, Kameras und Ultraschallsensoren. Eine größere Anzahl von Sensoren kann für Redundanz und mehr Funktionalität sorgen, doch im Falle eines Sensorausfalls kann das autonome Fahrzeug so ausgebildet werden, dass es sich selbst erkennt und in der Lage ist, die Fähigkeiten des Fahrzeugs nach dem Ausfall zu bestimmen.
• 151 zeigt ein Beispiel für ein dynamisches Autonomiegrad-Erkennungssystem („DALD“) 15100, das die Funktionalitäten des autonomen Fahrzeugs auf der Grundlage der dem Fahrzeug zur Verfügung stehenden Erfassungs- und Verarbeitungsmöglichkeiten anpasst. In einigen Ausführungsformen kann das System 15100 die gewünschten Erfahrungen des Fahrers (z. B. den Grad der Autonomie, den der Fahrer wünscht) und den aktuellen Handlungsverlauf des Fahrzeugs berücksichtigen. Dieses DALD-System nutzt verschiedene Eingaben, wie z. B. eine oder mehrere Wetterbedingungen, die Leistung der Sensoren die Fahrzeuganpassung und die Pläne des Fahrers um dynamisch den maximal erforderlichen Grad an Autonomie zu bestimmen, mit dem das Fahrzeug auf einer bestimmten Strecke fahren sollte. So kann das Fahrzeug seine Funktionen je nach dem Zustand der vorhandenen Sensoren, der Fahrzeuganpassung (z. B. ein Fahrzeug mit Anhänger, der die hinteren Sensoren blockiert), den Wetterbedingungen usw. anpassen.
• Unter weiterer Bezugnahme auf 151 umfasst das System 15100 ein Bewertungsmodul 15105 und ein Sicherheitsmodul 15110. Das Bewertungsmodul 15105 kann auch als Modul zur Berechnung der „L“-Bewertung betrachtet werden. Das Bewertungsmodul schätzt den Grad („L“) der Autonomie, den das Fahrzeug auf der Grundlage der verschiedenen vom System 15100 empfangenen Eingaben erreichen kann. Beispiele für Eingaben, die vom DALD-System 15100 empfangen werden, können sein: Sensorzustands- (oder Gesundheits-) Informationen 15130, gewünschte Benutzererfahrung 15140, Wetterbedingungen 15150, Rechenressourcen 15120 und Fahrzeuganpassungszustand 15160. Es sei darauf hingewiesen, dass die Liste der Eingaben hier nur beispielhaft ist und dass mehr oder weniger Eingaben als die Aufgeführten als Eingaben für das System 15100 in Frage kommen.
• Die „L“-Bewertung kann zum Beispiel wie folgt definiert werden: $$L_{Bewertung}={\displaystyle \sum _{i=1}^N{w}_i}*Eingabe{t}_i$$

  
• Wobei Eingabe; eine der N verschiedenen Eingaben des in 151 dargestellten DALD-Systems 15100 ist, und wobei w_i die verschiedenen Gewichte sind, die mit jeder Eingabe_i verbunden sind. Die Gewichte können sich dynamisch ändern, wenn sich die Fähigkeiten des autonomen Fahrzeugs im Laufe der Zeit ändern, und hängen von der Architektur des autonomen Fahrzeugs ab, wie z. B. von den Sensoren und Algorithmen des Fahrzeugs. Ein w_i =0 bedeutet, dass die Eingabe_i deaktiviert wurde. Das autonome Fahrzeug sollte dann diese L_Bewertung in eine Zahl umwandeln, die den verschiedenen im Fahrzeug verfügbaren Automatisierungsgraden entspricht, die eine ganze Zahl von 0 bis 5 sein kann, wenn der maximale Automatisierungsgrad im Fahrzeug Grad 5 ist.
• Es ist zu beachten, dass zumindest in einigen Ausführungsformen die Gewichte auch die folgende Bedingung erfüllen müssen, um die L_Bewertung konsistent zu erzeugen, wenn sich die Anzahl der beitragenden Eingaben ändert: $$1={\displaystyle \sum _{i=1}^N{w}_i}$$

  
• Dementsprechend werden in einer Ausführungsform, wenn eine oder mehrere Eingaben Null-Gewichtungen haben, die verbleibenden Nicht-Null-Gewichtungen so angepasst, dass sie sich immer zu einer Einheit addieren.
• Obwohl das obige Beispiel für die L_Bewertung eine lineare Beziehung zeigt, ist es möglich, dass die L_Bewertung durch Polynome höherer Ordnung definiert werden kann, was eine komplexere Berechnung und Kalibrierung erfordern würde. Daher wurde die obige lineare Beziehung als Beispiel für eine relativ einfache Art der Berechnung der L_Bewertung angeführt.
• Unter weiterer Bezugnahme auf 151 ist das Modul 15105 zur Berechnung der „L“-Bewertung fahrzeugabhängig und soll die Fähigkeiten des Fahrzeugs auf der Grundlage seines aktuellen Zustands veranschaulichen. Beispiele für Eingaben, die sich auf die „L“-Bewertung auswirken können, sind: die Rechenleistung 15120 des Fahrzeugs, die Sensoren 15130 des Fahrzeugs, die Benutzererfahrung 15140, das Wetter 15150 und die Fahrzeuganpassung 15160. Diese Liste umfasst nicht alle Faktoren, die zur Berechnung der „L“-Bewertung herangezogen werden können, und nicht alle aufgeführten Faktoren müssen bei der Berechnung der „L“-Bewertung berücksichtigt werden.
• Wie bereits erwähnt, sind die Sensoren 15130 entscheidend für die Autonomie von autonomen Fahrzeugen. Daher können die Sensoren 15120 die „L“-Bewertung stark beeinflussen. Wenn ein Sensor oder mehrere Sensoren beschädigt sind, kann das DALD-System 15100 einen Sensor deaktivieren oder ein kleineres Eingangsgewicht für den betroffenen Sensor oder die betroffenen Sensoren einstellen. Dies zeigt ein niedrigeres Vertrauensniveau und senkt wahrscheinlich die „L“-Bewertung. Neben einem beschädigten Sensor kann die gewichtete Bewertung des Sensoreingangs bei der Berechnung der „L“-Bewertung auch aus folgenden Gründen herabgesetzt werden: ein schlecht funktionierender Sensor, ein nicht ordnungsgemäß funktionierender Sensor (z. B. ein Sensor, der aufgrund einer allmählichen Verschlechterung nicht mehr ordnungsgemäß funktioniert), Sensordrift und eine absichtliche Deaktivierung des Sensors, wenn er für die aktuelle Fahrleistung nicht benötigt wird, wodurch Rechen- und Batteriestrom gespart werden kann.
• Das Wetter 15150, zu dem auch andere Umweltbedingungen gehören können, kann sich ebenfalls auf den Autonomiegrad von Fahrzeugen auswirken. So könnte das autonome Fahrzeug beispielsweise seinen Autonomiegrad herabsetzen, wenn es eine gefährliche Wetterlage, wie z. B. Schnee auf der Strecke, feststellt, auf die es nicht vorbereitet ist. Solche Umgebungsbedingungen können die Erkennungsfähigkeiten des autonomen Fahrzeugs beeinträchtigen oder die Traktion der Reifen erheblich verringern, was zu einem Rückgang des Autonomiegrades führen kann.
• Die Fahrzeuganpassung 15160 kann auch den Autonomiegrad des Fahrzeugs beeinflussen. Wenn eine Person nach der Kalibrierung der Sensoren Elemente am Fahrzeug anbringt, können einige Sensoren verdeckt sein. In einigen Fällen kann es erforderlich sein, einen Sensor zu deaktivieren, wenn Änderungen am Fahrzeug vorgenommen werden. In solchen Situationen kann es sein, dass die Sensoren aufgrund vorübergehender oder dauerhafter Änderungen weniger stark gewichtet werden müssen. Beispiele für Fahrzeugmodifikationen können z. B. angehängte Anhänger/Andere am Heck des Fahrzeugs, ein angebauter Dachgepäckträger oder sogar zusätzliche Nutzlast (z. B. Koffer, Möbel, etc.) sein. Es sollte beachtet werden, dass jede Änderung am Fahrzeug, die die Sensoren oder das Handling des Fahrzeugs beeinflussen kann, in die Fahrzeuganpassung 15160 einbezogen werden kann.
• Ein Fahrer/Beifahrer des Fahrzeugs möchte möglicherweise bestimmten Aspekten der Fahrt/Route Vorrang einräumen. Diese Nutzererfahrung 15140 kann sich auch auf den Autonomiegrad des Fahrzeugs auswirken. So könnte der Fahrer beispielsweise der Fahrzeit den Vorrang geben, unabhängig davon, wie oft das autonome Fahrzeug eine Übernahme anfordern könnte (Fahrt durch städtische Gebiete), oder der Fahrer könnte einer landschaftlichen Aussicht den Vorrang geben, die mehr Zeit in Anspruch nimmt. Der Fahrer kann sogar Routen bevorzugen, auf denen ein höheres Maß an Autonomie nicht erforderlich ist, wie z. B. Autobahnfahrten (die mit einem minimalen Satz von Sensoren erreicht werden können) In manchen Situationen kann der Grad der Autonomie völlig unerheblich sein, z. B. wenn der Fahrer einfach nur gerne Kraftfahrzeug fährt oder die Landschaft genießt.
• Ein weiterer Faktor für die „L“-Bewertung ist die verfügbare Rechenleistung 15120. Wenn beispielsweise die Fahrzeugbatterie nicht vollständig aufgeladen oder defekt ist, kann es sein, dass nicht genügend Energie für die zusätzlichen Berechnungen zur Verfügung steht, die erforderlich sind, um einen höheren Automatisierungsgrad eines autonomen Fahrzeugs zu erreichen. Ein weiteres Beispiel: Wenn eine für die Selbstfahrfähigkeiten des autonomen Fahrzeugs relevante Komponente, z. B. eine Festplatte, defekt ist oder nur über begrenzten Speicherplatz für Daten verfügt, sollte das autonome Fahrzeug seinen Autonomiegrad auf der Grundlage seiner Rechenkapazitäten anpassen.
• Nach Erhalt der oben genannten Eingaben kann das DALD-System 15100 bestimmen, welche Funktionalitäten entlang der Strecke aktiviert werden sollen. So bietet das System 15100 dem autonomen Fahrzeug vor einer Fahrt ein erweitertes Kontextbewusstsein. Wenn z. B. ein Sensor nicht ordnungsgemäß funktioniert, kann das Fahrzeug diesen Sensor deaktivieren und feststellen, wie dieser Sensor zum aktuellen Autonomiestatus beigetragen hat und welche Algorithmen von diesen Sensorinformationen abhängig waren. Wenn das Fahrzeug dank der Redundanz der Sensoren auch dann funktioniert, wenn dieser Sensor deaktiviert ist, kann der L-Wert gleich bleiben. Wenn dieser Sensor jedoch entscheidend für die Leistung des autonomen Fahrzeugs ist, wie z. B. ein 360-Grad-LIDAR-Sensor, der für die Lokalisierung in Stufe 4 verwendet wird, dann sollte das autonome Fahrzeug seinen Autonomiegrad so weit reduzieren, dass es die Automatisierungsfunktionen auch ohne diesen Sensor maximieren kann. Dies kann bedeuten, dass der Autonomiegrad gesenkt wird, z. B. auf L3 oder L2, je nach Konstruktion des Fahrzeugs. In einem anderen Beispiel kann es auch notwendig sein, den Autonomiegrad herabzusetzen, wenn ein Anhänger an das Fahrzeug angehängt ist und dadurch die hinteren Sensoren blockiert werden. Ein weiteres Beispiel: Der Autonomiegrad kann herabgesetzt werden, wenn ein Dachträger mit Snowboards das GPS-Signal des Fahrzeugs stört.
• Unter weiterer Bezugnahme auf 151 kann eine Automatisierungsgradanzeige 15170 den aktuellen „L“-Score zur besseren Visualisierung anzeigen, was das Bewusstsein und das Vertrauen des Benutzers in das autonome Fahrzeug erhöhen kann. Mit der Anzeige 15170 kann der Benutzer sehen, wie sich der Autonomiegrad nach Ereignissen ändert, die die Fähigkeiten des Fahrzeugs beeinträchtigen können. So kann der Benutzer erkennen, wie sich Veränderungen am Fahrzeug (z. B. Sensorschäden, Anpassungen usw.) auf den Autonomiegrad des Fahrzeugs auswirken, und andere Alternativen in Betracht ziehen, wie z. B. das Nichtanhängen eines Anhängers, wenn der Benutzer mehr Wert auf die Sicherheit und die Automatisierungsmöglichkeiten entlang der Strecke legt. Ein weiteres Beispiel: Es könnte sich sogar auf das Selbstvertrauen des Nutzers in seine Fähigkeiten auswirken, Situationen auf einer Strecke zu meistern, oder den Fahrer/Eigentümer dazu veranlassen, das Fahrzeug zur Wartung zu bringen, wenn das Fahrzeug ständig oder gelegentlich unter seinen Fähigkeiten/Erwartungen bleibt.
• Das DALD-System 15100 umfasst auch ein Sicherheitsprüfungsmodul 15180, das dafür zuständig ist, zu ermitteln, welche Parameter des autonomen Fahrzeugs für die Bahnplanungsalgorithmen wichtig sind. Beispiele für solche Parameter sind der Reibungskoeffizient in bestimmten Bereichen der Strecke, der sich aufgrund unterschiedlicher Wetterbedingungen ändern kann, das Gewicht des autonomen Fahrzeugs, das sich aufgrund der Fahrzeuganpassung ändern kann und die maximale Beschleunigung sowie die maximale und minimale Bremswirkung des autonomen Fahrzeugs beeinflusst. Die Möglichkeit, die jedem Routen- und Bahnplanungsalgorithmus innewohnenden Parameter zu ändern, wird eine wichtige Rolle für die Sicherheit der autonomen Fahrzeuge spielen. Die Sicherheitsmodule sind auf die Genauigkeit dieser Parameter angewiesen, um die besten Steuerungsparameter für den Benutzer zu ermitteln.
• Neben den offensichtlichen Sicherheitsvorteilen besteht ein zusätzlicher Vorteil des Systems 15100 darin, dass der Energieverbrauch des Fahrzeugs und die Wartungskosten des autonomen Fahrzeugs langfristig gesenkt werden können, indem das autonome Fahrzeug sich selbst erkennt und seine Funktionen dynamisch anpasst. Daher kann die Eingabe des Benutzers für das System 15100 wichtig sein. Je nachdem, ob der Nutzer die schnellste oder die landschaftlich reizvollste Route wünscht, könnte ein autonomes L5-Fahrzeug nach Überprüfung des Sensorstatus und der vorhergesagten Wetterbedingungen beschließen, auf der Strecke (oder Teilen davon) im L3-Modus zu bleiben, um so den Verschleiß teurer Sensoren und Rechenressourcen zu vermeiden.
• Wenn autonome Fahrzeuge allgegenwärtig werden, werden sie zu einem festen Bestandteil der Familienhaushalte werden und das normale Familienfahrzeug ersetzen. In dem Maße, in dem sie universeller werden, wird man von ihnen erwarten, dass sie die Funktionen der traditionellen, von Menschen gesteuerten Fahrzeuge übernehmen und nicht nur die täglichen Fahrten zur Arbeit oder zur Schule. Das bedeutet, dass die Menschen von autonomen Fahrzeugen mehr Vielseitigkeit erwarten, wie z. B. die Erleichterung von Campingausflügen, Wochenendausflügen an den Strand oder See oder einer Grillparty bei einem Sportereignis. Daher wird von autonomen Fahrzeugen erwartet, dass sie in der Lage sind, vorübergehend Geräte zu transportieren. Solche Ausrüstungen können beispielsweise Campingausrüstung, Fahrräder, Boote, Jetskis, Kühlboxen, Grills usw. sein. Dementsprechend können autonome Fahrzeuge die Möglichkeit bieten, einen Anhänger, Haken, Plattformen, Verlängerungen oder Ähnliches anzukoppeln.
• Solche Anbauteile an einem autonomen Fahrzeug können jedoch zu einer Verdeckung der Sensoren und zu einer Änderung des Fahrzeugverhaltens in Bezug auf die Abmessungen des Fahrzeugs führen. Dies gilt insbesondere für die bereits vorhandenen Parameter, die für die Einhaltung eines Sicherheitsabstands wichtig sind und die das Fahrzeug nun beim Manövrieren auf der Straße kompensieren muss. Als Beispiel und unter Bezugnahme auf 152, wenn ein autonomes Fahrzeug glaubt, dass es genug Platz hat, um vor einem anderen Fahrzeug zu fahren, aber stattdessen viel länger ist, als sein Steuerungssystem erkennt, könnte es verhindern, dass das nachfolgende Fahrzeug genug Platz zum Anhalten hat, oder schlimmer noch, es könnte auf das Fahrzeug auffahren, das das autonome Fahrzeug überholt.
• Ähnliche Überlegungen müssen auch angestellt werden, wenn Fahrzeugbesitzer ihr Fahrzeug anpassen, z. B. durch Tieferlegung, übergroße Reifen (die aus den Radkästen herausragen können), Spoiler oder andere Anbauteile. Diese Anpassungen können die Modellierung und Kalibrierung der Fahrzeugparameter verändern.
• Daher kann es wichtig sein, die neuen Fahrzeugabmessungen in dem Maße zu erhalten, wie sich die Abmessungen des Fahrzeugs durch die Änderungen erweitert haben. Auf diese Weise kann das autonome Fahrzeug ermitteln, wie viel Schutzstreifen erforderlich ist, um die Modelle für den Sicherheitsabstand zu ändern und die Erweiterungen zu kompensieren. Dieser Abstand ist von entscheidender Bedeutung für die Navigation, die es dem autonomen Fahrzeug ermöglicht, Unfälle zu vermeiden, und für Systeme wie die adaptive Geschwindigkeitsregelung, das Ausparken aus einer Parklücke und ähnliche autonome Aktionen.
• Es gibt zwar Modelle für die Fahrsicherheit, wie z. B. Sicherheitsabstände, aber die Sicherheit eines autonomen Fahrzeugs kann erhöht werden, wenn das autonome Fahrzeug weiß, dass sich die Abmessungen des Fahrzeugs geändert haben. Darüber hinaus sind Roboterfahrer von autonomen Fahrzeugen auf Sensoren und eine strenge Kalibrierung angewiesen, um ordnungsgemäß zu funktionieren. Im Rahmen der Kalibrierung der Fahrzeugsensoren wird ein Koordinatensystem verwendet, bei dem es sehr unwahrscheinlich ist, dass der Referenzpunkt des Fahrzeugs bewegt/verändert wird, außer vielleicht in der Höhe. Ein Beispiel, das Ackerman-Modell, wie in 153 gezeigt, umfasst den Mittelpunkt der Hinterachse des Fahrzeugs zwischen den beiden Rädern. Alle Änderungen an diesem Modell können in Bezug auf diese Koordinaten berücksichtigt und referenziert werden. Wenn zum Beispiel die Erweiterung der Fahrzeugabmessungen auf eine am Fahrzeug angebrachte Anhängerkupplung zurückzuführen ist, werden die Koordinaten versetzt, um den Kupplungspunkt zu berücksichtigen
• Zusätzlich zur Störung des Fahrzeugmodellierungssystems können Anpassungen, wie z. B. das Anbringen einer Anhängerkupplung, sowohl die Sensoren des Fahrzeugs als auch die Manövrierfähigkeit des Fahrzeugs beeinträchtigen. Diese Störungen werden sich wahrscheinlich auf den Grad der Autonomie des Fahrzeugs auswirken. 154 zeigt ein Beispiel für ein Fahrzeug 15400 mit einem Anbaugerät 15410 (z. B. ein Boot, das in diesem Beispiel von dem Fahrzeug gezogen wird) Wie in diesem Beispiel gezeigt, erzeugt die Anpassung verdeckte Bereiche 15420.
• Eine mögliche Lösung zur Bewältigung der neuen Fahrzeugabmessungen wäre die Ausstattung des Anhängers oder der Anhängerkupplung mit entsprechenden Sensoren. Dies würde jedoch die Komplexität des Systems erhöhen und könnte sowohl zeitaufwendig als auch teuer sein. So müsste sich der Benutzer beispielsweise Gedanken über die Kompatibilität der neuen Sensorsysteme mit dem bestehenden Fahrzeugsystem machen; es wäre teuer und zeitaufwändig, die strengen Kalibrierungsschritte durchzuführen; die Sensoren könnten den Elementen ausgesetzt sein (z. B. könnten sie ins Wasser getaucht werden, wenn es sich bei der Verlängerung um ein Boot, einen Jetski, ein Kanu usw. handelt); und es könnten Stangen oder andere Teile vorhanden sein, die über den Anhänger hinausragen (z. B. kann ein Boot viel größer sein als sein Anhänger) Außerdem wäre die Verwendung eines solchen Anhängers (z. B. für ein Boot) nur vorübergehend (ein Wochenendausflug), so dass diese Lösung unpraktisch wäre und wahrscheinlich nicht durchgesetzt/beachtet werden könnte.
• Eine weitere mögliche Alternative wäre die Implementierung eines Arrays von Ultraschallsensoren entlang desselben Koordinatensystems wie das Fahrzeugmodell, das zur 3D-Modellierung fähig ist und mit einer gewissen Annäherung die Breite und Tiefe der Anpassung erfassen könnte, die die Verdeckung der Sensoren verursacht.
• Ein weiteres Beispiel für eine einfache und kostengünstige Lösung ist eine Methode zur Erfassung und Verfolgung der neuen Außenabmessungen des Fahrzeugs, die sich aus der Anpassung ergeben (z. B. ein angehängter Anhänger). Das autonome Fahrzeug könnte dann bei Bedarf (während der Anhänger/die Anhängerkupplung angehängt ist) vorübergehend einen Ausgleich vornehmen.
• 155 veranschaulicht ein Beispiel für die Anwendung eines einfachen Verfahrens zur Ermittlung der neuen Abmessungen des Fahrzeugs unter Einbeziehung der durch eine an das Fahrzeug angekoppelte Verlängerung hinzugefügten Abmessungen. Zum Vergleich: 15510 zeigt eine 3D-Ultraschallkarte des Fahrzeugs und der Ausdehnung, die von einem Ultraschallsensor erfasst werden kann, der am Fahrzeug angebracht sein kann oder auch nicht. In einigen Beispielen kann das Beispiel von 15510 automatisiert werden. In solchen Beispielen kann, wenn das Fahrzeug eine Verdeckung erkennt oder ein Anhänger angehängt ist, eine automatische Ultraschallabtastung beginnen, die das Rendering des 3D-Modells erstellt. Ein weiteres Beispiel ist unter der Nummer 15530 abgebildet. Im Beispiel von 15530 werden die neuen Abmessungen des Fahrzeugs mit Hilfe von LIDARs erfasst, z. B. mit Hilfe einer LIDARbasierten Station. 15520 zeigt ein Beispiel für einen Benutzer, der eine manuelle Begehung durchführt, um die Verfolgung der neuen Abmessungen des Fahrzeugs zu erleichtern. Nach der Begehung wird das neue Modell 15540 für die Abmessungen des Fahrzeugs erstellt. Um die Begehung durchzuführen, kann der Fahrzeughalter den Weg des Fahrzeugs und die Verlängerungen auf einer bestimmten Länge (z. B. Armlänge) entlanggehen und dabei einen Sensor tragen. In einigen Beispielen kann dieser Sensor mit einem Smartphone gekoppelt (z. B. kommunikativ verbunden) werden. In anderen Beispielen kann der Sensor mit dem Fahrzeug gekoppelt werden. In verschiedenen Ausführungsformen, wie in 15520 dargestellt, können die Abmessungen des Fahrzeugs mit Hilfe einer Drohne und einer Kamera verfolgt werden, anstatt physisch um das Fahrzeug herumzugehen. Die Ergebnisse der Verfolgung können dann an das autonome Fahrzeug übermittelt werden, und es kann eine Polygonmodelldarstellung 15540 approximiert werden. Dieses Modell kann in die Fahralgorithmen des autonomen Fahrzeugs integriert werden.
• Ein System, das die oben genannten Optionen umfasst, kann eines oder mehrere der folgenden Elemente umfassen: ein Fahrzeug mit einer in das Fahrzeug integrierten Anhängevorrichtung mit einem Sensor, der registriert, wenn eine Anhängevorrichtung an einem Anbaugerät angebracht oder von diesem getrennt wird; einen Alarm, der den Fahrer warnt, dass eine „Sicherheitsdurchfahrt“ erforderlich ist, wenn eine Anhängevorrichtung erkannt wird; ein Sensorelement/eine Vorrichtung zur Erstellung der Rückverfolgung; nicht ausgeschlossene Sensoren, die während der laufenden Rückverfolgung als Querverweis dienen; und ein Fahrzeugwarnsystem, das den Fahrer vor Änderungen des Autonomiegrades warnt, die sich aus der Rückverfolgung und den verbleibenden funktionalen Sensoren ergeben. In einer Ausführungsform kann das Erfassungselement/Verfolgungsgerät eine Smartphone-App umfassen, die die neuen Abmessungen des autonomen Fahrzeugs auf der Grundlage eines oder mehrerer von der Smartphone-Kamera aufgenommener Bilder berechnet. Der Benutzer kann einfach um das Fahrzeug herumgehen oder eine Drohne einsetzen, um die neuen Dimensionen zu erfassen. In einem anderen Beispiel kann die Abtastvorrichtung eine integrierte, abnehmbare Fahrzeugkamera umfassen, die ähnliche Funktionen wie die oben beschriebenen erfüllt. Wenn nach dem Scannen Lücken in der Kurve vorhanden sind oder das Ergebnis nicht genau eine geradlinige Kurve ist (oder nicht genau am Ausgangspunkt endet), kann die Kurve immer noch in ein geschlossenes Polygon/eine Schleife um das Fahrzeug auf der Grundlage der erfassten Punkte der Kurve umgewandelt werden. Das Fahrzeug kann die ursprünglichen Abmessungen berücksichtigen, um die Auswirkungen eines „Drehpunkts“ auf Krümmungen zu kompensieren, und das neue Modell der Abmessungen kann einen Versatz umfassen, der gewährleistet, dass das Modell außerhalb der Fahrzeuggrenzen liegt, was einen zusätzlichen Sicherheitspuffer darstellen kann. In anderen Ausführungsformen können auch andere Methoden zur Bestimmung der neuen Abmessungen verwendet werden, wie z. B. Ultraschall- und LIDAR-Sensoren, die am Fahrzeug angebracht sein können oder auch nicht.
• 156 zeigt ein Beispiel für einen Fluss zur Kompensation von Fahrzeugmodellverdeckungen gemäß mindestens einer Ausführungsform. Das Beispiel von 156 kann auch als eine Methode zur Aktualisierung der Fahrzeugabmessungen eines autonomen Fahrzeugs betrachtet werden.
• Das Beispiel von 156 umfasst Aktionen, bei denen unter anderem festgestellt wird, ob ein Kupplungsschalter betätigt wurde. In einigen Ausführungsformen kann die Anhängevorrichtung einen automatischen Sensor (z. B. einen Schalter) umfassen, der anzeigt, ob die Anhängevorrichtung eingerastet ist. In verschiedenen Ausführungsformen kann das autonome Fahrzeug zusätzlich oder alternativ einen manuellen Schalter umfassen, der anzeigt, dass die Anhängevorrichtung eingerastet ist.
• Wenn der Kupplungsschalter eingeschaltet ist, kann das Fahrzeug eine Prüfung durchführen, um festzustellen, ob alle erforderlichen Sicherheitsmaßnahmen durchgeführt wurden, bevor das Fahrzeug mit den zusätzlichen Abmessungen fährt. Wenn sie das getan haben, endet der Fluss. Ist dies nicht der Fall, kann das Fahrzeug feststellen, ob ein Sicherheitsrundgang, der die neuen Fahrzeugabmessungen erfasst, abgeschlossen wurde. Ist dies nicht der Fall, kann der Fahrer gewarnt werden, dass eine Nachprüfung erforderlich ist, und die Nachprüfung kann beginnen.
• Um die Begehung durchzuführen, wird das Fahrzeug zunächst aktiviert und/oder mit einem Sensor gekoppelt. Dabei kann es sich um einen Sensor handeln, der in ein Smartphone oder ein ähnliches Gerät integriert oder mit diesem gekoppelt ist, oder um ein separates Gerät, das direkt mit dem Fahrzeug verbunden wird. Nachdem das Gerät gekoppelt/aktiviert wurde, führt der Besitzer einen Rundgang durch das Fahrzeug durch.
• Anschließend überträgt das Messgerät die während des Rundgangs gewonnenen Daten an das autonome Fahrzeug. Das autonome Fahrzeug kann dann die von der Erfassungsvorrichtung erhaltenen Daten in ein Polygonmodell umwandeln. Das autonome Fahrzeug kann dann die neuen Dimensionen in seinen Algorithmen für autonome Fahrzeuge verwenden, z. B. im Algorithmus für den Sicherheitsabstand. Schließlich kann das autonome Fahrzeug einen Selbsttest durchführen, um festzustellen, ob sich die neuen Dimensionen auf den Autonomiegrad auswirken, mit dem das Fahrzeug betrieben wird. Wenn sich der Pegel geändert hat, kann dieser neue Pegel dem Fahrer angezeigt (oder auf andere Weise mitgeteilt) werden (oder es kann dem Fahrer angezeigt oder auf andere Weise mitgeteilt werden, dass sich der Pegel nicht geändert hat).
• 157-158 sind Blockdiagramme von beispielhaften Computerarchitekturen, die in Übereinstimmung mit den hier offengelegten Ausführungsformen verwendet werden können. Andere im Stand der Technik für Prozessoren und Rechensysteme bekannte Computerarchitekturentwürfe können auch verwendet werden. Im Allgemeinen können geeignete Computerarchitekturen für die hierin offengelegten Ausführungsformen die in den 157-158 dargestellten Konfigurationen umfassen, sind aber nicht darauf beschränkt.
• 157 ist ein Beispiel für die Darstellung eines Prozessors gemäß einer Ausführungsform. Der Prozessor 15700 ist ein Beispiel eines Typs von Hardware-Vorrichtung, die in Verbindung mit den vorangehenden Implementierungen verwendet werden kann. Der Prozessor 15700 kann irgendeine Art von Prozessor sein, z. B. ein Mikroprozessor, ein eingebetteter Prozessor, ein digitaler Signalprozessor (DSP), ein Netzwerkprozessor, ein Mehrkernprozessor, ein Einkernprozessor oder eine andere Vorrichtung zum Ausführen eines Codes. Obwohl in 157 nur ein Prozessor 15700 abgebildet ist, kann ein Verarbeitungselement alternativ mehr als einen der in 157 dargestellten Prozessoren 15700 umfassen. Der Prozessor 15700 kann ein Einzel-Thread-Kern sein oder bei zumindest einem Ausführungsbeispiel kann der Prozessor 15700 dahingehend multi-threaded sein, dass er mehr als einen Hardware-Thread-Kontext (oder „logischen Prozessor“) pro Kern umfassen kann.
• 157 zeigt auch einen Speicher 15702, der mit dem Prozessor 15700 gemäß einer Ausführungsform verbunden ist. Der Speicher 15702 kann irgendeiner einer breiten Vielzahl von Speichern (umfassend verschiedene Schichten von Speicherhierarchie) sein, wie sie Fachleuten auf dem Gebiet bekannt oder anderweitig für sie verfügbar sind. Solche Speicherelemente können umfassen, sind aber nicht beschränkt auf, Direktzugriffsspeicher (RAM; Random Access Memory), Nur-Lese-Speicher (ROM; Read Only Memory), logische Blöcke eines feldprogrammierbaren Gate-Arrays (FPGA; Field Programmable Gate Array), löschbaren programmierbaren Nur-Lese-Speicher (EPROM; Erasable Programmable Read Only Memory) und elektrisch löschbaren, programmierbaren ROM (EEPROM; electrically erasable programmable ROM).
• Der Prozessor 15700 kann jede Art von Anweisungen ausführen, die mit den hierin beschriebenen Algorithmen, Prozessen oder Operationen verbunden sind. Im Allgemeinen kann der Prozessor 15700 ein Element oder einen Artikel (z. B. Daten) von einem Zustand oder Ding in einen anderen Zustand oder Ding transformieren.
• Ein Code 15704, der eine oder mehrere durch den Prozessor 15700 auszuführende Anweisungen sein kann, kann in dem Speicher 15702 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 15700 einer Programmsequenz von Anweisungen folgen, die durch den Code 15704 angezeigt wird. Jede Anweisung geht in eine Frontend-Logik 15706 und wird durch einen oder mehrere Decodierer 15708 verarbeitet. Der Decodierer kann als seine Ausgabe eine Mikrooperation wie z. B. eine Feste-Breite-Mikrooperation in einem vordefinierten Format erzeugen, oder kann andere Anweisungen, Mikroanweisungen oder Steuersignale erzeugen, die die ursprüngliche Codeanweisung widerspiegeln. Die Frontend-Logik 15706 umfasst auch die Register-Umbenennungslogik 15710 und die Zeitplanungs-Logik 15712, die im Allgemeinen Ressourcen zuweisen, und die Operation, die der Anweisung zur Ausführung entspricht, in eine Warteschlange stellen.
• Der Prozessor 15700 kann auch eine Ausführungslogik 15714 umfassen, die einen Satz von Ausführungseinheiten 15716a, 15716b, 15716n 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 können nur eine Ausführungseinheit oder eine Ausführungseinheit, die eine bestimmte Funktion ausführen kann, umfassen. Die Ausführungslogik 15714 führt die durch Code-Anweisungen spezifizierten Operationen aus.
• Nach Abschluss der Ausführung der durch die Code-Anweisungen spezifizierten Operationen kann die Backend-Logik 15718 die Anweisungen von Code 15704 zurückziehen. Bei einem Ausführungsbeispiel erlaubt der Prozessor 15700 die Ausführung außerhalb der Reihenfolge, fordert aber ein Zurückziehen von Anweisungen der Reihenfolge nach. Die Zurückziehen-Logik 15720 kann eine Vielzahl bekannter Formen annehmen (z. B. Neuanordnungs- (re-order) Puffer oder Ähnliches). Auf diese Weise wird der Prozessor 15700 während der Ausführung von Code 15704 transformiert, zumindest hinsichtlich der Ausgabe, die durch den Decodierer, die Hardware-Register und Tabellen, die durch die Registerumbenennungslogik 15710 verwendet werden, und irgendwelchen Registern (nicht gezeigt), die durch die Ausführungslogik 15714 modifiziert werden, erzeugt wird.
• Obwohl in 157 nicht gezeigt, kann ein Verarbeitungselement andere Elemente auf einem Chip mit Prozessor 15700 umfassen. Zum Beispiel kann ein Verarbeitungselement neben dem Prozessor 15700 eine Speichersteuerlogik umfassen. Das Verarbeitungselement kann eine I/O- Steuerungslogik umfassen und/oder kann 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 beispielsweise Flash-Speicher oder Sicherungen) auf dem Chip mit Prozessor 15700 umfasst sein.
• 158 veranschaulicht ein Rechensystem 15800, das in einer Punkt-zu-Punkt-Konfiguration (PtP) gemäß einer Ausführungsform angeordnet ist. Insbesondere zeigt 158 ein System, in dem Prozessoren, Speicher und Eingabe-/Ausgabegeräte über eine Reihe von Punkt-zu-Punkt-Schnittstellen miteinander verbunden sind. Im Allgemeinen können ein oder mehrere der hierin beschriebenen Rechensysteme auf die gleiche oder ähnliche Weise wie das Rechensystem 15700 ausgebildet sein.
• Die Prozessoren 15870 und 15880 können auch jeweils die integrierte Speichersteuerungslogik (MC) 15872 und 15882 umfassen, um mit den Speicherelementen 15832 und 15834 zu kommunizieren. Bei alternativen Ausführungsbeispielen kann die Speichersteuerlogik 15872 und 15882 eine von den Prozessoren 15870 und 15880 getrennte diskrete Logik sein. Die Speicherelemente 15832 und/oder 15834 können verschiedene Daten speichern, die durch die Prozessoren 15870 und 15880 verwendet werden sollen, um die hierin dargestellten Operationen und Funktionalität zu erreichen.
• Die Prozessoren 15870 und 15880 können irgendein Typ von Prozessor sein, wie jene, die im Zusammenhang mit anderen Figuren hierin erörtert sind. Die Prozessoren 15870 und 15880 können Daten über eine Punkt-zu-Punkt- (PtP) Schnittstelle 15850 jeweils unter Verwendung von Punkt-zu-Punkt-Schnittstellenschaltungen 15878 und 15888 austauschen. Die Prozessoren 15870 und 15880 können jeweils Daten mit einem Chipsatz 15890 über individuelle Punkt-zu-Punkt-Schnittstellen 15852 und 15854 unter Verwendung der Punkt-zu-Punkt-Schnittstellenschaltungen 15876, 15886, 15894 und 15898 austauschen. Der Chipsatz 15890 kann über eine Schnittstelle 15839, die eine PtP-Schnittstellenschaltung sein könnte, auch Daten mit einem Co-Prozessor 15838 austauschen, z. B. einer Hochperformance-Grafikschaltung, einem Maschinelles-Lernen-Beschleuniger oder einem anderen Co-Prozessor 15838. In alternativen Ausführungsformen können einige oder alle der in 158 gezeigten PtP-Verbindungen (PtP-Links) als Multi-Drop-Bus und nicht als PtP-Verbindung implementiert werden.
• Der Chipsatz 15890 kann über eine Schnittstellenschaltung 15896 mit einem Bus 15820 kommunizieren. Der Bus 15820 kann eine oder mehrere Vorrichtungen aufweisen, die über ihn kommunizieren, wie beispielsweise eine Busbrücke 15818 und I/O-Vorrichtungen 15816. Über einen Bus 15810 kann die Busbrücke 15818 mit anderen Vorrichtungen kommunizieren, wie beispielsweise einer Benutzerschnittstelle 15812 (wie beispielsweise Tastatur, Maus, Touchscreen oder anderen Eingabevorrichtungen), Kommunikationsvorrichtungen 15826 (wie beispielsweise Modems, Netzwerkschnittstellenvorrichtungen oder anderen Arten von Kommunikationsvorrichtungen, die durch ein Computernetzwerk 15860 kommunizieren können), Audio-I/O-Vorrichtungen 15814 und/oder einer Datenspeicherungsvorrichtung 15828. Die Datenspeicherungsvorrichtung 15828 kann den Code 15830 speichern, der von den Prozessoren 15870 und/oder 15880 ausgeführt werden kann. Bei alternativen Ausführungsbeispielen können irgendwelche Abschnitte der Busarchitekturen mit einem oder mehreren PtP-Verbindungen implementiert sein.
• Das in FIG. dargestellte Computersystem 158 ist eine schematische Darstellung einer Ausführungsform eines Rechensystems, das zur Umsetzung verschiedener hier beschriebener Ausführungsformen verwendet werden kann. Es wird darauf hingewiesen, dass verschiedene Komponenten des in 158 gezeigten Systems in einer System-on-a-Chip (SoC)-Architektur oder in einer anderen geeigneten Konfiguration kombiniert werden können, die in der Lage ist, die Funktionalität und die Merkmale der hier aufgeführten Beispiele und Implementierungen zu erreichen.
• Während einige der hierin beschriebenen und dargestellten Systeme und Lösungen so beschrieben wurden, dass sie eine Mehrzahl von Elementen umfassen oder einer Mehrzahl derselben zugeordnet sind, werden möglicherweise nicht alle explizit dargestellten oder beschriebenen Elemente bei jeder alternativen Implementierung der vorliegenden Offenbarung verwendet. Zusätzlich können sich eines oder mehrere der hierin beschriebenen Elemente außerhalb eines Systems befinden, während in anderen Fällen bestimmte Elemente innerhalb eines oder als ein Abschnitt eines oder mehrerer der anderen beschriebenen Elemente umfasst sein können, ebenso wie andere Elemente, die in der dargestellten Implementierung nicht beschrieben sind. Ferner können bestimmte Elemente mit anderen Komponenten kombiniert werden, sowie für alternative oder zusätzliche Zwecke neben 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 implementiert werden, umfassend Kombinationen, die durch die verschiedenen Implementierungen der hierin beschriebenen Komponenten implementiert werden. Andere Implementierungen, Merkmale und Details sollten dem Inhalt dieser Beschreibung entnommen werden.
• Obwohl diese Offenbarung in Bezug auf bestimmte Implementierungen und allgemein zugeordnete Verfahren beschrieben wurde, sind Abänderungen und Permutationen dieser Implementierungen und Verfahren für den Fachmann offensichtlich. Beispielsweise können die hierin beschriebenen Handlungen in einer anderen Reihenfolge als beschrieben durchgeführt werden und dennoch die erwünschten Ergebnisse erzielen. Als Beispiel erfordern die in den beiliegenden Figuren dargestellten Prozesse nicht notwendigerweise die bestimmte gezeigte Reihenfolge oder sequenzielle Reihenfolge, um die erwünschten Ergebnisse zu erzielen. Bei bestimmten Implementierungen können Multitasking und parallele Verarbeitung vorteilhaft sein. Zusätzlich können andere Benutzerschnittstellen-Layouts und Funktionalität unterstützt werden. Andere Variationen sind innerhalb des Schutzbereichs der folgenden Ansprüche.
• Diese Spezifikation umfasst viele spezifische Ausführungsdetails, die jedoch nicht als Beschränkungen des Umfangs der Erfindungen oder der beanspruchten Leistungen zu verstehen sind, sondern vielmehr als Beschreibungen von Merkmalen, die für bestimmte Ausführungsformen bestimmter Erfindungen spezifisch sind. Bestimmte Merkmale, die in dieser Beschreibung in dem Kontext separater Ausführungsbeispiele beschrieben sind, 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. Ferner, obwohl Merkmale vorstehend als in bestimmten Kombinationen wirkend beschrieben und sogar ursprünglich als solche beansprucht werden können, können in einigen Fällen ein oder mehrere Merkmale einer beanspruchten Kombination aus der Kombination herausgeschnitten werden, und die beanspruchte Kombination kann auf eine Teilkombination oder Variation einer Teilkombination gerichtet sein.
• Ähnlich sollte, auch wenn die Operationen in den Zeichnungen in einer bestimmten Reihenfolge dargestellt sind, dies nicht so verstanden werden, dass es erforderlich ist, dass solche Operationen in der gezeigten bestimmten Reihenfolge oder in sequenzieller Reihenfolge ausgeführt werden oder dass alle dargestellten Operationen ausgeführt werden, um die erwünschten Ergebnisse zu erzielen. Unter bestimmten Umständen können Multitasking und parallele Verarbeitung vorteilhaft sein. Ferner sollte die Trennung verschiedener Systemkomponenten bei den vorangehend beschriebenen Ausführungsbeispielen nicht so verstanden werden, dass eine solche Trennung bei allen Ausführungsbeispielen erforderlich ist, und es versteht sich, dass die beschriebenen Programmkomponenten und Systeme im Allgemeinen zusammen in ein einzelnes Softwareprodukt integriert oder in mehrere Softwareprodukte gepackagt werden können.
• Es können Rechnersysteme bereitgestellt werden, darunter fahrzeuginterne Rechnersysteme (z. B. zur Implementierung mindestens eines Teils eines Stapels für automatisiertes Fahren und zur Ermöglichung des automatisierten Fahrens des Fahrzeugs), straßenseitige Rechnersysteme (z. B. getrennt von Fahrzeugen; implementiert in speziellen straßenseitigen Schränken, auf Verkehrsschildern, auf Verkehrssignal- oder Ampelmasten usw.), auf einem oder mehreren Rechensystemen, die ein cloud- oder nebelbasiertes System implementieren, das autonome Fahrumgebungen unterstützt, oder auf Rechensystemen, die von autonomen Fahrumgebungen entfernt sind, kann eine Logik umfassen, die unter Verwendung eines oder einer Kombination von einem oder mehreren Datenverarbeitungsgeräten (z. B. Zentralverarbeitungseinheiten, Grafikverarbeitungseinheiten, Tensor-Verarbeitungseinheiten, ASICs, FPGAs usw.), Beschleunigerhardware, andere Hardwareschaltungen, Firmware und/oder Software implementiert ist, um eine oder eine Kombination der folgenden Punkte durchzuführen oder zu implementieren:
• Beispiel 1 ist eine nicht-transitorische maschinenlesbare Speichervorrichtung mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen zum Empfangen von Sensordaten von einer Mehrzahl von Sensoren, wobei die Mehrzahl von Sensoren einen ersten Satz von Sensoren und einen zweiten Satz von Sensoren umfasst und mindestens ein Teil der Mehrzahl von Sensoren mit einem Fahrzeug gekoppelt ist; Automatisieren der Steuerung des Fahrzeugs unter Verwendung eines Datenprozessors auf dem Fahrzeug, basierend auf mindestens einem Teil der Sensordaten, die von dem ersten Satz von Sensoren erzeugt werden; Bestimmen, unter Verwendung eines Datenprozessors im Fahrzeug, von Insassenattributen eines oder mehrerer Insassen innerhalb der autonomen Fahrzeuge aus Sensordaten, die durch den zweiten Satz von Sensoren erzeugt wurden; und Modifizieren von Fahrzeugattributen des Fahrzeugs, basierend auf den Insassenattributen und den Sensordaten, die durch den ersten Satz von Sensoren erzeugt wurden.
• Beispiel 2 umfasst den Gegenstand von Beispiel 1, wobei die automatische Steuerung des Fahrzeugs die Bestimmung eines ersten Weges des Fahrzeugs umfasst und die Änderung der Fahrzeugattribute auf der Grundlage der Insassenattribute bewirkt, dass der erste Weg in einen zweiten Weg geändert wird und die anschließende automatische Steuerung des Fahrzeugs auf dem zweiten Weg basiert.
• Beispiel 3 umfasst den Gegenstand eines der Beispiele 1-2, wobei die Fahrzeugattribute physikalische Attribute einer Fahrzeugkabine umfassen und sich die Fahrgäste in der Kabine befinden.
• Beispiel 4 umfasst den Gegenstand von Beispiel 3, wobei die Kabine eine oder mehrere Vorrichtungen umfasst, die so ausgebildet sind, dass sie den Komfort der Fahrgäste erleichtern, und die Änderung der Fahrzeugeigenschaften die autonome Einstellung der einen oder mehreren Vorrichtungen umfasst.
• Beispiel 5 umfasst den Gegenstand eines der Beispiele 1-4, wobei das Modifizieren der Fahrzeugattribute das Präsentieren einer Empfehlung an die Fahrgäste unter Verwendung einer Präsentationsvorrichtung auf der Grundlage eines Pfades umfasst, der in Verbindung mit der automatischen Steuerung des Fahrzeugs und den Insassenattributen bestimmt wurde.
• Beispiel 6 umfasst den Gegenstand von Beispiel 5, wobei die Empfehlung eine Empfehlung zur Änderung eines Ziels oder des Weges des Fahrzeugs auf der Grundlage der Insassenattribute umfasst.
• Beispiel 7 umfasst den Gegenstand eines der Beispiele 1-6, wobei die Insassenattribute Attribute umfassen, die den Komfort oder die Präferenzen des einen oder der mehreren Insassen im Fahrzeug beeinflussen.
• Beispiel 8 umfasst den Gegenstand eines der Beispiele 1-7, wobei die automatische Steuerung des Fahrzeugs mit Hilfe eines ersten Maschinelles-Lernen-Modells bestimmt wird und die Insassenattribute mit Hilfe eines zweiten Maschinelles-Lernen-Modells bestimmt werden.
• Beispiel 9 umfasst den Gegenstand eines der Beispiele 1-8, wobei die Fahrzeugattribute einen Fahrstil umfassen, der durch die automatisierte Steuerung des Fahrzeugs implementiert werden soll, und das Ändern der Fahrzeugattribute bewirkt, dass der Fahrstil basierend auf den Insassenattributen geändert wird.
• Beispiel 10 umfasst den Gegenstand eines der Beispiele 1-9, wobei der erste und der zweite Satz von Sensoren mindestens einen gemeinsamen Sensor umfassen.
• Beispiel 11 umfasst den Gegenstand eines der Beispiele 1-10, wobei mindestens ein Sensor des ersten und des zweiten Sensorsatzes fahrzeugfremd ist.
• Beispiel 12 umfasst den Gegenstand eines der Beispiele 1-11, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: die Identität jedes der Insassen auf der Grundlage von Sensordaten aus dem zweiten Satz von Sensoren zu bestimmen; und auf Präferenzinformationen zuzugreifen, die den Identitäten eines oder mehrerer der Insassen entsprechen, wobei die Insassenattribute die Präferenzinformationen umfassen.
• Beispiel 13 umfasst den Gegenstand eines der Beispiele 1-12, wobei die Insassenattribute menschliche Eigenschaften der Insassen beschreiben.
• Beispiel 14 umfasst den Gegenstand von Beispiel 13, wobei die Fahrgäste eine Mehrzahl von Fahrgästen umfassen und die menschlichen Attribute kombinierte Attribute einer Gruppe von Fahrgästen umfassen, die die Mehrzahl von Fahrgästen einschließt, und die Fahrzeugattribute basierend auf den kombinierten Attributen modifiziert werden.
• Beispiel 15 umfasst den Gegenstand eines der Beispiele 1-14, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, bestimmte Sensordaten, die Daten von dem ersten Satz von Sensoren oder dem zweiten Satz von Sensoren umfassen, über einen drahtlosen Kommunikationskanal an ein entferntes Rechensystem zu senden; und Empfangen von Empfehlungsdaten von dem entfernten Rechensystem auf der Grundlage der bestimmten Sensordaten, wobei die Fahrzeugattribute auf der Grundlage der Empfehlungsdaten geändert werden.
• Beispiel 16 ist ein Verfahren, das Folgendes umfasst: empfangen von Sensordaten von einer Mehrzahl von Sensoren, wobei die Mehrzahl von Sensoren einen ersten Satz von Sensoren und einen zweiten Satz von Sensoren umfasst und mindestens ein Teil der Mehrzahl von Sensoren mit einem Fahrzeug gekoppelt ist; Automatisieren der Steuerung des Fahrzeugs unter Verwendung eines Datenprozessors in dem Fahrzeug auf der Grundlage von mindestens einem Teil der von dem ersten Satz von Sensoren erzeugten Sensordaten; bestimmen, unter Verwendung eines Datenprozessors in dem Fahrzeug, von Insassenattributen eines oder mehrerer Insassen innerhalb der autonomen Fahrzeuge aus Sensordaten, die von dem zweiten Satz von Sensoren erzeugt werden; und Modifizieren von Fahrzeugattributen des Fahrzeugs, basierend auf den Insassenattributen und den Sensordaten, die von dem ersten Satz von Sensoren erzeugt werden.
• Beispiel 17 umfasst den Gegenstand von Beispiel 16, wobei die automatische Steuerung des Fahrzeugs die Bestimmung eines ersten Weges des Fahrzeugs umfasst und die Änderung der Fahrzeugattribute auf der Grundlage der Insassenattribute bewirkt, dass der erste Weg in einen zweiten Weg geändert wird und die anschließende automatische Steuerung des Fahrzeugs auf dem zweiten Weg basiert.
• Beispiel 18 umfasst den Gegenstand eines der Beispiele 16-17, wobei die Fahrzeugattribute physische Attribute einer Kabine des Fahrzeugs umfassen und die Fahrgäste sich in der Kabine befinden.
• Beispiel 19 umfasst den Gegenstand von Beispiel 18, wobei die Kabine eine oder mehrere Vorrichtungen umfasst, die so ausgebildet sind, dass sie den Komfort der Fahrgäste erleichtern, und die Änderung der Fahrzeugeigenschaften die autonome Einstellung der einen oder mehreren Vorrichtungen umfasst.
• Beispiel 20 umfasst den Gegenstand eines der Beispiele 16-19, wobei das Ändern der Fahrzeugattribute das Präsentieren einer Empfehlung an die Fahrgäste unter Verwendung einer Präsentationsvorrichtung auf der Grundlage eines Pfades umfasst, der in Verbindung mit der automatischen Steuerung des Fahrzeugs und den Insassenattributen bestimmt wurde.
• Beispiel 21 umfasst den Gegenstand von Beispiel 20, wobei die Empfehlung eine Empfehlung zur Änderung eines Ziels oder des Weges des Fahrzeugs auf der Grundlage der Insassenattribute umfasst.
• Beispiel 22 umfasst den Gegenstand eines der Beispiele 16-21, wobei die Insassenattribute Attribute umfassen, die den Komfort oder die Präferenzen des einen oder der mehreren Insassen im Fahrzeug beeinflussen.
• Beispiel 23 umfasst den Gegenstand eines der Beispiele 16-22, wobei die automatische Steuerung des Fahrzeugs unter Verwendung eines ersten Maschinelles-Lernen-Modells bestimmt wird und die Insassenattribute unter Verwendung eines zweiten Maschinelles-Lernen-Modells bestimmt werden.
• Beispiel 24 umfasst den Gegenstand eines der Beispiele 16-23, wobei die Fahrzeugattribute einen Fahrstil umfassen, der durch die automatische Steuerung des Fahrzeugs implementiert werden soll, und die Änderung der Fahrzeugattribute bewirkt, dass der Fahrstil auf der Grundlage der Insassenattribute geändert wird.
• Beispiel 25 umfasst den Gegenstand eines der Beispiele 16-24, wobei der erste und der zweite Satz von Sensoren mindestens einen gemeinsamen Sensor umfassen.
• Beispiel 26 umfasst den Gegenstand eines der Beispiele 16 bis 25, wobei mindestens ein Sensor des ersten und des zweiten Sensorsatzes fahrzeugfremd ist.
• Beispiel 27 umfasst den Gegenstand von einem der Beispiele 16-26, ferner umfassend: Bestimmen der Identität jedes der Insassen auf der Grundlage von Sensordaten aus dem zweiten Satz von Sensoren; und Zugreifen auf Präferenzinformationen, die den Identitäten von einem oder mehreren der Insassen entsprechen, wobei die Insassenattribute die Präferenzinformationen umfassen.
• Beispiel 28 umfasst den Gegenstand eines der Beispiele 16-27, wobei die Insassenattribute menschliche Eigenschaften der Insassen beschreiben.
• Beispiel 29 umfasst den Gegenstand von Beispiel 28, wobei die Fahrgäste eine Mehrzahl von Fahrgästen umfassen und die menschlichen Attribute kombinierte Attribute einer Gruppe von Fahrgästen umfassen, die die Mehrzahl von Fahrgästen einschließt, und die Fahrzeugattribute basierend auf den kombinierten Attributen modifiziert werden.
• Beispiel 30 umfasst den Gegenstand eines der Beispiele 16 bis 29 und schließt ferner ein:
  • senden bestimmter Sensordaten, die Daten von dem ersten Satz von Sensoren oder dem zweiten Satz von Sensoren umfassen, über einen drahtlosen Kommunikationskanal an ein entferntes Rechensystem; und
  • empfangen von Empfehlungsdaten von dem entfernten Rechnersystem auf der Grundlage der bestimmten Sensordaten, wobei die Fahrzeugattribute auf der Grundlage der Empfehlungsdaten geändert werden.
• Beispiel 31 ist ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 16-30.
• Beispiel 32 ist ein nicht-transitorisches, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun empfangen von ersten Sensordaten, die von einem ersten Satz von Sensoren erzeugt werden, wobei die ersten Sensordaten Attribute einer Fahrumgebung identifizieren; Empfangen von zweiten Sensordaten, die von einem zweiten Satz von Sensoren erzeugt werden, wobei die zweiten Sensordaten Attribute eines Satzes von Fahrgästen in einem bestimmten Fahrzeug in der Fahrumgebung identifizieren; Bestimmen einer Empfehlung auf der Grundlage der ersten Sensordaten und der zweiten Sensordaten; Senden von Empfehlungsdaten über einen drahtlosen Kommunikationskanal an ein bordeigenes Rechensystem des bestimmten Fahrzeugs, wobei die Empfehlungsdaten die Empfehlung identifizieren und von dem bordeigenen Rechensystem konsumierbar sind, um den Betrieb des bestimmten Fahrzeugs zu beeinflussen.
• Beispiel 33 umfasst den Gegenstand von Beispiel 32, wobei der erste Satz von Sensoren einen oder mehrere in das jeweilige Fahrzeug integrierte Sensoren umfasst.
• Beispiel 34 umfasst den Gegenstand eines der Beispiele 32 bis 33, wobei der erste Satz von Sensoren einen oder mehrere fahrzeugfremde Sensoren umfasst.
• Beispiel 35 umfasst den Gegenstand von Beispiel 34, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: einen Standort des bestimmten Fahrzeugs zu bestimmen; einen oder mehrere bestimmte Sensoren an dem Standort zu identifizieren; und auf bestimmte Sensordaten von den bestimmten Sensoren zuzugreifen, wobei die ersten Sensordaten die bestimmten Sensordaten umfassen.
• Beispiel 36 umfasst den Gegenstand von Beispiel 35, wobei der erste Satz von Sensoren einen oder mehrere Sensoren umfasst, die an einem anderen Fahrzeug an dem Ort angebracht sind.
• Beispiel 37 umfasst den Gegenstand eines der Beispiele 35-36, wobei der erste Satz von Sensoren eine straßenseitige Einheit an dem Ort umfasst.
• Beispiel 38 umfasst den Gegenstand eines der Beispiele 32-37, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, aus den zweiten Sensordaten ein oder mehrere Profile zu bestimmen, die mit der Gruppe von Fahrgästen verbunden sind, wobei die Empfehlung auf dem einen oder den mehreren Profilen basiert.
• Beispiel 39 umfasst den Gegenstand eines der Beispiele 32-38, wobei die Empfehlung von dem bordeigenen Rechensystem konsumiert werden kann, um das bordeigene Rechensystem zu veranlassen, die automatische Steuerung des bestimmten Fahrzeugs auf der Grundlage der Empfehlung zu ändern.
• Beispiel 40 umfasst den Gegenstand von Beispiel 39, wobei die Änderung der automatischen Steuerung dazu führt, dass das Fahrzeug von einem zuvor festgelegten Weg abweicht.
• Beispiel 41 umfasst den Gegenstand eines der Beispiele 39-40, wobei die Änderung der automatischen Steuerung das Fahrzeug veranlasst, auf der Grundlage der Empfehlung von einem ersten Fahrstil zu einem zweiten Fahrstil zu wechseln.
• Beispiel 42 ist ein Verfahren, das Folgendes umfasst: empfangen von ersten Sensordaten, die von einem ersten Satz von Sensoren erzeugt werden, wobei die ersten Sensordaten Attribute einer Fahrumgebung identifizieren; Empfangen von zweiten Sensordaten, die von einem zweiten Satz von Sensoren erzeugt werden, wobei die zweiten Sensordaten Attribute eines Satzes von Fahrgästen in einem bestimmten Fahrzeug in der Fahrumgebung identifizieren; Bestimmen einer Empfehlung auf der Grundlage der ersten Sensordaten und der zweiten Sensordaten; und Senden von Empfehlungsdaten über einen drahtlosen Kommunikationskanal an ein bordeigenes Rechensystem des bestimmten Fahrzeugs, wobei die Empfehlungsdaten die Empfehlung identifizieren und von dem bordeigenen Rechensystem konsumierbar sind, um den Betrieb des bestimmten Fahrzeugs zu beeinflussen
• Beispiel 43 umfasst den Gegenstand von Beispiel 42, wobei der erste Satz von Sensoren einen oder mehrere in das jeweilige Fahrzeug integrierte Sensoren umfasst.
• Beispiel 44 umfasst den Gegenstand eines der Beispiele 42-43, wobei der erste Satz von Sensoren einen oder mehrere fahrzeugfremde Sensoren umfasst.
• Beispiel 45 umfasst den Gegenstand von Beispiel 44, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: einen Standort des bestimmten Fahrzeugs zu bestimmen; einen oder mehrere bestimmte Sensoren an dem Standort zu identifizieren; und auf bestimmte Sensordaten von den bestimmten Sensoren zuzugreifen, wobei die ersten Sensordaten die bestimmten Sensordaten umfassen.
• Beispiel 46 umfasst den Gegenstand von Beispiel 45, wobei der erste Satz von Sensoren einen oder mehrere Sensoren umfasst, die an einem anderen Fahrzeug an dem Ort angebracht sind.
• Beispiel 47 umfasst den Gegenstand eines der Beispiele 45-46, wobei der erste Satz von Sensoren eine straßenseitige Einheit an dem Ort umfasst.
• Beispiel 48 umfasst den Gegenstand eines der Beispiele 42-47, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, aus den zweiten Sensordaten ein oder mehrere Profile zu bestimmen, die mit der Gruppe von Fahrgästen verbunden sind, wobei die Empfehlung auf dem einen oder den mehreren Profilen basiert.
• Beispiel 49 umfasst den Gegenstand eines der Beispiele 42-48, wobei die Empfehlung von dem bordeigenen Rechensystem konsumiert werden kann, um das bordeigene Rechensystem zu veranlassen, die automatische Steuerung des bestimmten Fahrzeugs auf der Grundlage der Empfehlung zu ändern.
• Beispiel 50 umfasst den Gegenstand von Beispiel 49, wobei die Änderung der automatischen Steuerung dazu führt, dass das Fahrzeug von einem zuvor festgelegten Weg abweicht.
• Beispiel 51 umfasst den Gegenstand eines der Beispiele 49-50, wobei die Änderung der automatischen Steuerung bewirkt, dass das Fahrzeug auf der Grundlage der Empfehlung von einem ersten Fahrstil zu einem zweiten Fahrstil wechselt.
• Beispiel 52 ist ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 42-51.
• Beispiel 53 ist ein System, das Folgendes umfasst: ein bordeigenes Rechensystem für ein Fahrzeug, wobei das bordeigene Rechensystem Prozessor-Hardware umfasst, wobei die Prozessor-Hardware Maschinenlern-Hardware umfasst; einen Satz lokaler Sensoren; einen Satz von Aktoren; und ein Empfehlungssystem, das von der Prozessor-Hardware ausgeführt werden kann, um: erste Sensordaten zu identifizieren, um Fahrbedingungen in einer Umgebung zu beschreiben, wobei das Fahrzeug in oder nahe der Umgebung positioniert ist, wobei das On-Board-Rechensystem die ersten Sensordaten verwendet, um die Steuerung des Fahrzeugs zu automatisieren; zweite Sensordaten zu identifizieren, wobei zumindest ein Teil der zweiten Sensordaten von dem Satz lokaler Sensoren erzeugt wird; bestimmen eines oder mehrerer Insassenattribute eines Satzes von Insassen innerhalb des Fahrzeugs aus den zweiten Sensordaten; Bestimmen einer Empfehlung für das bordeigene Rechensystem auf der Grundlage der ersten und zweiten Sensordaten; wobei das bordeigene Rechensystem die Empfehlung verwenden soll, um einen oder mehrere des Satzes von Aktuatoren zu betätigen, um Bedingungen des Fahrzeugs zu ändern.
• Beispiel 54 umfasst den Gegenstand von Beispiel 53, wobei der eine oder die mehreren Aktuatoren Aktuatoren zur Steuerung der Lenkung, der Beschleunigung oder des Bremsens des Fahrzeugs umfassen.
• Beispiel 55 umfasst den Gegenstand von Beispiel 54, wobei das bordeigene Rechensystem eine Pfadplanungsmaschine umfasst, um: einen ersten Pfadplan für das Fahrzeug zu bestimmen; und den ersten Pfadplan zu ergänzen, um einen anderen, zweiten Pfadplan für das Fahrzeug auf der Grundlage der Empfehlung zu bilden.
• Beispiel 56 umfasst den Gegenstand von Beispiel 53, wobei der eine oder die mehreren Aktuatoren Aktuatoren zur Einstellung der physikalischen Bedingungen in einer Fahrzeugkabine umfassen, in der die Fahrgäste mitfahren.
• Beispiel 57 umfasst den Gegenstand von Beispiel 53, wobei mindestens ein Teil der ersten Sensordaten von der Gruppe der lokalen Sensoren erzeugt wird.
• Beispiel 58 umfasst den Gegenstand von Beispiel 53, wobei das Empfehlungssystem dazu dient: über einen drahtlosen Kommunikationskanal mit einem entfernten Rechensystem zu kommunizieren; und Empfangen von Empfehlungsdaten von dem entfernten Rechensystem, wobei die Empfehlung weiterhin auf der Grundlage der Empfehlungsdaten bestimmt wird.
• Beispiel 59 umfasst den Gegenstand von Beispiel 53, wobei ein Teil der ersten Sensordaten oder der zweiten Daten von fahrzeugexternen Sensoren empfangen wird.
• Beispiel 60 umfasst den Gegenstand eines der Beispiele 53-59, wobei das Empfehlungssystem weiterhin Empfehlungsdaten erzeugt, um die Empfehlung zu beschreiben, und veranlasst, dass die Empfehlungsdaten an ein anderes mit der Umgebung verbundenes System übertragen werden
• Beispiel 61 ist ein Verfahren, das Folgendes umfasst: Empfangen von Sensordaten von einer Mehrzahl von Sensoren, wobei die Mehrzahl von Sensoren einen ersten Satz von Sensoren und einen zweiten Satz von Sensoren umfasst und mindestens ein Teil der Mehrzahl von Sensoren mit einem Fahrzeug gekoppelt ist; Bestimmen, unter Verwendung eines Datenprozessors im Fahrzeug, eines Pfades für das Fahrzeug aus Daten, die von mindestens dem ersten Satz von Sensoren erzeugt werden; und Bestimmen, unter Verwendung eines Datenprozessors im Fahrzeug, von Attributen, die den Komfort oder die Präferenzen von Insassen innerhalb der autonomen Fahrzeuge beeinflussen, aus Daten, die von mindestens dem zweiten Satz von Sensoren erzeugt werden.
• Beispiel 62 schließt den Gegenstand von Beispiel 61 ein, einschließlich der Bestimmung einer Änderung des Pfades basierend auf den menschlichen Attributen.
• Beispiel 63 umfasst den Gegenstand eines der Beispiele 61-62, wobei eine oder mehrere Vorrichtungen in einer Fahrzeugkabine automatisch auf der Grundlage der Attribute eingestellt werden.
• Beispiel 64 umfasst den Gegenstand von Beispiel 63, wobei die eine oder mehreren Vorrichtungen eine in die Kabine integrierte Vorrichtung umfassen.
• Beispiel 65 umfasst den Gegenstand eines der Beispiele 63-64, wobei die eine oder mehreren Vorrichtungen eine fahrzeugfremde Vorrichtung umfassen.
• Beispiel 66 umfasst den Gegenstand eines der Beispiele 61-65, wobei der Pfad unter Verwendung eines ersten Maschinelles-Lernen-Modells bestimmt wird und die Attribute unter Verwendung eines zweiten Maschinelles-Lernen-Modells bestimmt werden.
• Beispiel 67 umfasst den Gegenstand eines der Beispiele 61-66, einschließlich der Anpassung eines Fahrstils, der von der autonomen Fahrsteuerung des Fahrzeugs auf der Grundlage der Attribute angewendet wird.
• Beispiel 68 umfasst den Gegenstand eines der Beispiele 61-67, wobei der erste und der zweite Satz von Sensoren mindestens einen gemeinsamen Sensor umfassen.
• Beispiel 69 umfasst den Gegenstand eines der Beispiele 61-68, wobei ein oder mehrere Sensoren in der zweiten Gruppe von Sensoren Umgebungsinformationen sammeln, die sich auf die Umgebung des Fahrzeugs beziehen.
• Beispiel 70 umfasst den Gegenstand eines der Beispiele 61-69, wobei ein oder mehrere Sensoren in der zweiten Gruppe von Sensoren Informationen über Merkmale von Fahrgästen im Fahrzeug erfassen.
• Beispiel 71 umfasst den Gegenstand von einem der Beispiele 61-70, ferner: Bestimmen der Identität jedes der Insassen; und Zugreifen auf Präferenzinformationen, die den Identitäten von einem oder mehreren der Insassen entsprechen.
• Beispiel 72 umfasst den Gegenstand eines der Beispiele 61-71, wobei die Attribute menschliche Eigenschaften der Fahrgäste beschreiben.
• Beispiel 73 umfasst den Gegenstand von Beispiel 72, wobei die Fahrgäste eine Mehrzahl von Fahrgästen umfassen und die menschlichen Attribute kombinierte Attribute einer Gruppe von Fahrgästen einschließlich der Mehrzahl von Fahrgästen umfassen.
• Beispiel 74 umfasst den Gegenstand eines der Beispiele 61-73, wobei die Attribute Attribute einer Fahrbahn beschreiben, die einem Autonomes-Fahren-Pfadplan entsprechen.
• Beispiel 75 umfasst den Gegenstand eines der Beispiele 61-74, wobei die Attribute die Wetterbedingungen auf einem Autonomes-Fahren-Pfadplan beschreiben.
• Beispiel 76 ist ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 61-75.
• Beispiel 77 umfasst den Gegenstand von Beispiel 76, wobei die Mittel ein computerlesbares Medium zum Speichern von Anweisungen umfassen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, mindestens einen Teil des Verfahrens eines der Beispiele 61-75 durchzuführen.
• Beispiel 78 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen zum: Empfangen von Sensordaten von einer Mehrzahl von Sensoren, wobei die Mehrzahl von Sensoren einen ersten Satz von Sensoren und einen zweiten Satz von Sensoren umfasst und mindestens ein Teil der Mehrzahl von Sensoren mit einem Fahrzeug gekoppelt ist; Bestimmen, unter Verwendung eines Datenprozessors auf dem Fahrzeug, eines Pfades für das Fahrzeug aus Daten, die von mindestens dem ersten Satz von Sensoren erzeugt werden; und Bestimmen, unter Verwendung eines Datenprozessors auf dem Fahrzeug, von Attributen, die den Komfort oder die Präferenzen von Insassen innerhalb der autonomen Fahrzeuge beeinflussen, aus Daten, die von mindestens dem zweiten Satz von Sensoren erzeugt werden.
• Beispiel 79 umfasst den Gegenstand von Beispiel 78, wobei die Anweisungen weiterhin ausführbar sind, um eine Änderung des Pfades auf der Grundlage der menschlichen Attribute zu bestimmen.
• Beispiel 80 umfasst den Gegenstand eines der Beispiele 78-79, wobei die Anweisungen ferner ausführbar sind, um eine oder mehrere Vorrichtungen in einer Fahrzeugkabine automatisch auf der Grundlage der Attribute einzustellen.
• Beispiel 81 umfasst den Gegenstand von Beispiel 80, wobei die eine oder mehreren Vorrichtungen eine in die Kabine integrierte Vorrichtung umfassen.
• Beispiel 82 umfasst den Gegenstand eines der Beispiele 80-81, wobei die eine oder mehreren Vorrichtungen eine fahrzeugfremde Vorrichtung umfassen.
• Beispiel 83 umfasst den Gegenstand eines der Beispiele 78-82, wobei der Pfad unter Verwendung eines ersten Maschinelles-Lernen-Modells bestimmt wird und die Attribute unter Verwendung eines zweiten Maschinelles-Lernen-Modells bestimmt werden.
• Beispiel 84 umfasst den Gegenstand eines der Beispiele 78-83, wobei die Anweisungen ferner ausführbar sind, um einen von der autonomen Fahrsteuerung des Fahrzeugs angewandten Fahrstil auf der Grundlage der Attribute anzupassen.
• Beispiel 85 umfasst den Gegenstand eines der Beispiele 78-84, wobei der erste und der zweite Satz von Sensoren mindestens einen gemeinsamen Sensor umfassen.
• Beispiel 86 umfasst den Gegenstand eines der Beispiele 78-85, wobei ein oder mehrere Sensoren in der zweiten Gruppe von Sensoren Umgebungsinformationen in Bezug auf die Umgebung des Fahrzeugs erfassen.
• Beispiel 87 umfasst den Gegenstand eines der Beispiele 78-86, wobei ein oder mehrere Sensoren in der zweiten Gruppe von Sensoren Informationen über die Eigenschaften der Fahrgäste im Fahrzeug erfassen.
• Beispiel 88 umfasst den Gegenstand eines der Beispiele 78-87, wobei die Anweisungen ferner ausführbar sind, um: die Identität jedes der Insassen zu bestimmen; und auf Präferenzinformationen zuzugreifen, die den Identifikationen eines oder mehrerer der Insassen entsprechen.
• Beispiel 89 umfasst den Gegenstand eines der Beispiele 78-88, wobei die Attribute menschliche Eigenschaften der Insassen beschreiben.
• Beispiel 90 umfasst den Gegenstand von Beispiel 89, wobei die Fahrgäste eine Mehrzahl von Fahrgästen umfassen und die menschlichen Attribute kombinierte Attribute einer Gruppe von Fahrgästen umfassen, die die Mehrzahl von Fahrgästen einschließt.
• Beispiel 91 umfasst den Gegenstand eines der Beispiele 78-90, wobei die Attribute Attribute einer Fahrbahn beschreiben, die einem Autonomes-Fahren-Pfadplan entsprechen.
• Beispiel 92 umfasst den Gegenstand eines der Beispiele 78-91, wobei die Attribute die Wetterbedingungen auf einem Autonomes-Fahren-Pfadplan beschreiben.
• Beispiel 93 ist ein Verfahren, das Folgendes umfasst: Identifizieren eines bestimmten Fahrzeugs an einem bestimmten Ort; Bestimmen von Fähigkeiten des bestimmten Fahrzeugs, wobei die Fähigkeiten Sensorfähigkeiten des bestimmten Fahrzeugs umfassen; und Senden von Empfehlungsdaten an das bestimmte Fahrzeug, wobei die Empfehlungsdaten auf Sensordaten basieren, die von einem oder mehreren Sensoren außerhalb des bestimmten Fahrzeugs erzeugt werden, wobei die Empfehlungsdaten bewirken sollen, dass den Fahrgästen in dem bestimmten Fahrzeug eine Empfehlung präsentiert wird.
• Beispiel 94 umfasst den Gegenstand von Beispiel 93, wobei der eine oder die mehreren Fremdsensoren Sensoren an einer Luftdrohne, einem autonomen Fahrzeug oder einer Straßenrandeinheit umfassen.
• Beispiel 95 umfasst den Gegenstand eines der Beispiele 93-94, wobei der eine oder die mehreren Fremdsensoren eine Mehrzahl von Sensoren aus einer Mehrzahl von verschiedenen Geräten umfassen.
• Beispiel 96 umfasst den Gegenstand eines der Beispiele 93-95, wobei ferner die Sensordaten von dem einen oder den mehreren Fremdsensoren in einem Rechensystem außerhalb des bestimmten Fahrzeugs gesammelt werden, wobei das Rechensystem die Empfehlungsdaten an das bestimmte Fahrzeug sendet.
• Beispiel 97 umfasst den Gegenstand von Beispiel 96, wobei das Rechensystem die Empfehlungsdaten aus einer Analyse der Sensordaten erzeugt.
• Beispiel 98 umfasst den Gegenstand von Beispiel 97, wobei die Analyse die Anwendung eines Maschinelles-Lernen-Modells umfasst.
• Beispiel 99 umfasst den Gegenstand von einem der Beispiele 93-98, einschließlich der Bestimmung eines Typs von Empfehlungsdaten, die dem bestimmten Fahrzeug auf der Grundlage der Fähigkeiten des bestimmten Fahrzeugs zur Verfügung gestellt werden sollen.
• Beispiel 100 umfasst den Gegenstand von einem der Beispiele 93-99, einschließlich der Bestimmung des Zeitpunkts für das Senden der Empfehlungsdaten an das bestimmte Fahrzeug auf der Grundlage der Fähigkeiten des bestimmten Fahrzeugs.
• Beispiel 101 ist ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 93-100.
• Beispiel 102 umfasst den Gegenstand von Beispiel 101, wobei die Mittel ein computerlesbares Medium zum Speichern von Anweisungen umfassen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, mindestens einen Teil des Verfahrens von einem der Beispiele 93-100 durchzuführen.
• Beispiel 103 ist ein Verfahren, das Folgendes umfasst: Empfangen von Daten, die von einem oder mehreren angeschlossenen Sensoren erzeugt werden, die fest mit einem ersten Fahrzeug verbunden sind; Empfangen von Empfehlungsdaten von einer Quelle außerhalb des ersten Fahrzeugs, wobei die Empfehlungsdaten auf Sensordaten basieren, die von einem oder mehreren Sensoren außerhalb des ersten Fahrzeugs erzeugt werden; Bestimmen einer Empfehlung für einen oder mehrere Fahrgäste in einer Kabine des ersten Fahrzeugs; und Darstellen der Empfehlung im ersten Fahrzeug.
• Beispiel 104 umfasst den Gegenstand von Beispiel 103, wobei der eine oder die mehreren Fremdsensoren Sensoren an einer Luftdrohne, einem anderen Fahrzeug oder einer Straßenrandeinheit umfassen.
• Beispiel 105 umfasst den Gegenstand eines der Beispiele 103-104, wobei die Fremdsensoren Sensoren umfassen, die nicht in dem einen oder mehreren angeschlossenen Sensoren vorhanden sind.
• Beispiel 106 umfasst den Gegenstand von einem der Beispiele 103-105, einschließlich der Bestimmung von Identitäten von einem oder mehreren Insassen in der Kabine des ersten Fahrzeugs unter Verwendung von Daten, die von den angeschlossenen Sensoren erzeugt werden.
• Beispiel 107 umfasst den Gegenstand von Beispiel 106, ferner die Bestimmung von Präferenzen eines oder mehrerer Insassen auf der Grundlage der Identitäten, wobei die Empfehlung zumindest teilweise auf der Grundlage der Präferenzen bestimmt wird.
• Beispiel 108 umfasst den Gegenstand eines der Beispiele 103-107, wobei die Empfehlung eine Empfehlung für ein Einzelhandelsgeschäft, ein Restaurant oder eine andere Einrichtung umfasst
• Beispiel 109 umfasst den Gegenstand eines der Beispiele 103-108, wobei die Empfehlung eine Empfehlung umfasst, einen für das erste Fahrzeug ermittelten Weg zu ändern.
• Beispiel 110 umfasst den Gegenstand von Beispiel 109, wobei das erste Fahrzeug eine autonome Fahrlogik aufweist und die Empfehlung die autonome Fahrlogik veranlasst, die Änderung des Pfades vorzunehmen.
• Beispiel 111 ist ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 103-110.
• Beispiel 112 umfasst den Gegenstand von Beispiel 111, wobei die Mittel ein computerlesbares Medium zum Speichern von Anweisungen umfassen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, mindestens einen Teil des Verfahrens eines der Beispiele 103-110 durchzuführen.
• Beispiel 113 umfasst den Gegenstand von Beispiel 111, wobei die Mittel ein fahrzeuginternes Rechensystem innerhalb des ersten Fahrzeugs umfassen.
• Beispiel 114 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, ein bestimmtes Fahrzeug innerhalb eines bestimmten Ortes zu identifizieren; Fähigkeiten des bestimmten Fahrzeugs zu bestimmen, wobei die Fähigkeiten Sensorfähigkeiten des bestimmten Fahrzeugs umfassen; und Empfehlungsdaten an das bestimmte Fahrzeug zu senden, wobei die Empfehlungsdaten auf Sensordaten basieren, die von einem oder mehreren Sensoren außerhalb des bestimmten Fahrzeugs erzeugt werden, wobei die Empfehlungsdaten bewirken sollen, dass den Fahrgästen in dem bestimmten Fahrzeug eine Empfehlung präsentiert wird.
• Beispiel 115 umfasst den Gegenstand von Beispiel 114, wobei der eine oder die mehreren Fremdsensoren Sensoren an einer Luftdrohne, einem autonomen Fahrzeug oder einer Straßenrandeinheit umfassen.
• Beispiel 116 umfasst den Gegenstand eines der Beispiele 114-115, wobei der eine oder die mehreren Fremdsensoren eine Mehrzahl von Sensoren aus einer Mehrzahl von verschiedenen Geräten umfassen.
• Beispiel 117 umfasst den Gegenstand eines der Beispiele 114-116, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Sensordaten von dem einen oder den mehreren Fremdsensoren an einem Rechensystem außerhalb des bestimmten Fahrzeugs zu sammeln, wobei das Rechensystem die Empfehlungsdaten an das bestimmte Fahrzeug sendet.
• Beispiel 118 umfasst den Gegenstand von Beispiel 117, wobei das Rechensystem die Empfehlungsdaten aus einer Analyse der Sensordaten erzeugt.
• Beispiel 119 umfasst den Gegenstand von Beispiel 58, wobei die Analyse die Anwendung eines Maschinelles-Lernen-Modells umfasst.
• Beispiel 120 umfasst den Gegenstand eines der Beispiele 114-119, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, eine Art von Empfehlungsdaten zu sammeln, die dem bestimmten Fahrzeug auf der Grundlage der Fähigkeiten des bestimmten Fahrzeugs bereitgestellt werden sollen.
• Beispiel 121 umfasst den Gegenstand eines der Beispiele 114-120, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, den Zeitpunkt für das Senden der Empfehlungsdaten an das bestimmte Fahrzeug basierend auf den Fähigkeiten des bestimmten Fahrzeugs zu bestimmen.
• Beispiel 122 ist ein nicht-transitorisches, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: Daten zu empfangen, die von einem oder mehreren angeschlossenen Sensoren erzeugt werden, die fest mit einem ersten Fahrzeug verbunden sind; Empfangen von Empfehlungsdaten von einer Quelle außerhalb des ersten Fahrzeugs, wobei die Empfehlungsdaten auf Sensordaten basieren, die von einem oder mehreren Sensoren außerhalb des ersten Fahrzeugs erzeugt werden; Bestimmen einer Empfehlung für einen oder mehrere Fahrgäste in einer Kabine des ersten Fahrzeugs; und Präsentieren der Empfehlung in dem ersten Fahrzeug.
• Beispiel 123 umfasst den Gegenstand von Beispiel 122, wobei der eine oder die mehreren Fremdsensoren Sensoren an einer Luftdrohne, einem anderen Fahrzeug oder einer Straßenrandeinheit umfassen.
• Beispiel 124 umfasst den Gegenstand eines der Beispiele 122-123, wobei die Fremdsensoren Sensoren umfassen, die nicht in dem einen oder mehreren angeschlossenen Sensoren vorhanden sind.
• Beispiel 125 umfasst den Gegenstand eines der Beispiele 122-124, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Identitäten eines oder mehrerer Fahrgäste in der Kabine des ersten Fahrzeugs unter Verwendung von Daten zu bestimmen, die von den angeschlossenen Sensoren erzeugt werden.
• Beispiel 126 umfasst den Gegenstand von Beispiel 125, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, Präferenzen eines oder mehrerer der Insassen auf der Grundlage der Identitäten zu bestimmen, wobei die Empfehlung zumindest teilweise auf der Grundlage der Präferenzen bestimmt wird.
• Beispiel 127 umfasst den Gegenstand eines der Beispiele 122-126, wobei die Empfehlung eine Empfehlung für ein Einzelhandelsgeschäft, ein Restaurant oder eine andere Einrichtung umfasst
• Beispiel 128 umfasst den Gegenstand eines der Beispiele 122-127, wobei die Empfehlung eine Empfehlung umfasst, einen für das erste Fahrzeug ermittelten Pfad zu ändern.
• Beispiel 129 umfasst den Gegenstand von Beispiel 128, wobei das erste Fahrzeug eine autonome Fahrlogik aufweist und die Empfehlung die autonome Fahrlogik veranlasst, die Änderung des Pfades vorzunehmen.
• Beispiel 130 ist ein Verfahren, das Folgendes umfasst: Feststellen, unter Verwendung mindestens eines Datenprozessors eines autonomen Fahrzeugs, dass der Betrieb mindestens eines bestimmten Sensors an dem autonomen Fahrzeug beeinträchtigt ist; Empfangen von Empfehlungsdaten an dem autonomen Fahrzeug über einen drahtlosen Kommunikationskanal, wobei die Empfehlungsdaten auf Sensordaten basieren, die von einem oder mehreren Sensoren außerhalb des autonomen Fahrzeugs erzeugt werden; und Verwenden der Empfehlungsdaten zur Unterstützung des autonomen Fahrens des autonomen Fahrzeugs auf der Grundlage der Feststellung, dass der Betrieb des mindestens einen Sensors beeinträchtigt ist.
• Beispiel 131 umfasst den Gegenstand von Beispiel 130, wobei die Empfehlungsdaten die Sensordaten umfassen.
• Beispiel 132 umfasst den Gegenstand von einem der Beispiele 130-131, ferner das Erzeugen von lokalen Sensordaten unter Verwendung eines Satzes von Sensoren des autonomen Fahrzeugs, wobei der bestimmte Sensor außerhalb des Satzes von Sensoren liegt; wobei die Empfehlungsdaten zusammen mit den lokalen Sensordaten verwendet werden, um das autonome Fahren des autonomen Fahrzeugs zu unterstützen.
• Beispiel 133 umfasst den Gegenstand von einem der Beispiele 130-132, ferner umfassend: Bestimmen eines Standorts des bestimmten Sensors am autonomen Fahrzeug; Identifizieren, dass die Empfehlungsdaten einer Position außerhalb des autonomen Fahrzeugs entsprechen, wobei der bestimmte Sensor Informationen erfassen soll, die der Position auf der Grundlage des Standorts des bestimmten Sensors entsprechen, wobei die Empfehlungsdaten Informationen bereitstellen sollen, um zumindest teilweise Informationen zu ersetzen, die durch den bestimmten Sensor zu erhalten sind.
• Beispiel 134 umfasst den Gegenstand eines der Beispiele 130-133, wobei der Verlust des bestimmten Sensors dazu führt, dass ein vom autonomen Fahrzeug unterstützter maximaler Autonomiegrad von einem bestimmten Grad auf einen anderen, niedrigeren Grad fällt, und die Verwendung der Empfehlungsdaten dem autonomen Fahrzeug ermöglicht, den Betrieb auf dem bestimmten Grad aufrechtzuerhalten.
• Beispiel 135 umfasst den Gegenstand von einem der Beispiele 130-134, weiterhin umfassend: Anwenden eines Maschinelles-Lernen-Modells auf Eingaben am autonomen Fahrzeug, um eine Wahrscheinlichkeit vorherzusagen, dass einer oder mehrere der Sensoren am autonomen Fahrzeug während der Fahrt beeinträchtigt werden; und Konfigurieren eines Empfehlungssystems basierend auf der Wahrscheinlichkeit.
• Beispiel 136 umfasst den Gegenstand von Beispiel 135, wobei das Konfigurieren des Empfehlungssystems auf der Grundlage der Wahrscheinlichkeit das präventive Auslösen des Betriebs des Empfehlungssystems umfasst, um mit dem Empfang und der Verarbeitung von Empfehlungsdaten zu beginnen, bevor festgestellt wird, dass der bestimmte Sensor gefährdet ist.
• Beispiel 137 umfasst den Gegenstand eines der Beispiele 130-136, wobei der bestimmte Sensor einer aus einer Reihe von Sensoren am autonomen Fahrzeug ist, um eine Sammlung von Sensordaten zu erzeugen, die als Eingaben zur Unterstützung des autonomen Fahrens verwendet werden, und das Verfahren ferner das Filtern der Empfehlungsdaten umfasst, um den Teil der Empfehlungsdaten beizubehalten, der einem Teil der Sammlung von Sensordaten entspricht, der als Folge der Beeinträchtigung des bestimmten Sensors fehlt.
• Beispiel 138 umfasst den Gegenstand eines der Beispiele 130-137, wobei der eine oder die mehreren Fremdsensoren Sensoren an einer Mehrzahl anderer Geräte umfassen.
• Beispiel 139 umfasst den Gegenstand von Beispiel 138, wobei die mehreren anderen Geräte eines oder mehrere andere autonome Fahrzeuge, Luftdrohnen und straßenseitige Sensoren umfassen.
• Beispiel 140 umfasst den Gegenstand eines der Beispiele 130-139, einschließlich des Erstellens eines Reiseplans für das autonome Fahrzeug, wobei die Empfehlungsdaten die Bedingungen auf einem bevorstehenden Straßenabschnitt basierend auf dem Reiseplan beschreiben.
• Beispiel 141 ist ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 130-140.
• Beispiel 142 umfasst den Gegenstand von Beispiel 141, wobei die Mittel ein computerlesbares Medium zum Speichern von Anweisungen umfassen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, mindestens einen Teil des Verfahrens von einem der Beispiele 130-140 durchzuführen.
• Beispiel 143 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun unter Verwendung mindestens eines Datenprozessors eines autonomen Fahrzeugs festzustellen, dass der Betrieb mindestens eines bestimmten Sensors an dem autonomen Fahrzeug beeinträchtigt ist; Empfangen von Empfehlungsdaten an dem autonomen Fahrzeug über einen drahtlosen Kommunikationskanal, wobei die Empfehlungsdaten auf Sensordaten basieren, die von einem oder mehreren Sensoren außerhalb des autonomen Fahrzeugs erzeugt werden; und Verwenden der Empfehlungsdaten zur Unterstützung des autonomen Fahrens des autonomen Fahrzeugs auf der Grundlage der Feststellung, dass der Betrieb des mindestens einen Sensors beeinträchtigt ist.
• Beispiel 144 umfasst den Gegenstand von Beispiel 143, wobei die Empfehlungsdaten die Sensordaten umfassen.
• Beispiel 145 umfasst den Gegenstand eines der Beispiele 143-144, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, lokale Sensordaten unter Verwendung eines Satzes von Sensoren des autonomen Fahrzeugs zu erzeugen, wobei der bestimmte Sensor außerhalb des Satzes von Sensoren liegt; wobei die Empfehlungsdaten zusammen mit den lokalen Sensordaten verwendet werden, um das autonome Fahren des autonomen Fahrzeugs zu unterstützen.
• Beispiel 146 umfasst den Gegenstand eines der Beispiele 143-145, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: einen Standort des bestimmten Sensors an dem autonomen Fahrzeug zu bestimmen; zu identifizieren, dass die Empfehlungsdaten einer Position außerhalb des autonomen Fahrzeugs entsprechen, wobei der bestimmte Sensor Informationen erfassen soll, die der Position auf der Grundlage des Standorts des bestimmten Sensors entsprechen, wobei die Empfehlungsdaten Informationen bereitstellen sollen, um Informationen, die durch den bestimmten Sensor erhalten werden sollen, zumindest teilweise zu ersetzen.
• Beispiel 147 umfasst den Gegenstand eines der Beispiele 143-146, wobei der Verlust des bestimmten Sensors dazu führt, dass ein vom autonomen Fahrzeug unterstützter maximaler Autonomiegrad von einem bestimmten Grad auf einen anderen, niedrigeren Grad fällt, und die Verwendung der Empfehlungsdaten es dem autonomen Fahrzeug ermöglicht, den Betrieb auf dem bestimmten Grad aufrechtzuerhalten.
• Beispiel 148 umfasst den Gegenstand eines der Beispiele 143-147, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: ein maschinelles Lernmodell auf Eingaben an dem autonomen Fahrzeug anzuwenden, um eine Wahrscheinlichkeit vorherzusagen, dass einer oder mehrere der Sensoren an dem autonomen Fahrzeug während der Fahrt beeinträchtigt werden; und ein Empfehlungssystem auf der Grundlage der Wahrscheinlichkeit zu konfigurieren.
• Beispiel 149 umfasst den Gegenstand von Beispiel 148, wobei das Konfigurieren des Empfehlungssystems auf der Grundlage der Wahrscheinlichkeit das präventive Auslösen des Betriebs des Empfehlungssystems umfasst, um mit dem Empfang und der Verarbeitung von Empfehlungsdaten zu beginnen, bevor festgestellt wird, dass der bestimmte Sensor gefährdet ist.
• Beispiel 150 umfasst den Gegenstand eines der Beispiele 143-149, wobei der bestimmte Sensor einer aus einer Reihe von Sensoren am autonomen Fahrzeug ist, um eine Sammlung von Sensordaten zur Verwendung als Eingaben zur Unterstützung des autonomen Fahrens zu erzeugen, und das Speichermedium ferner das Filtern der Empfehlungsdaten umfasst, um den Teil der Empfehlungsdaten beizubehalten, der einem Teil der Sammlung von Sensordaten entspricht, der als Folge der Beeinträchtigung des bestimmten Sensors fehlt.
• Beispiel 151 umfasst den Gegenstand eines der Beispiele 143-150, wobei der eine oder die mehreren Fremdsensoren Sensoren an einer Mehrzahl anderer Geräte umfassen.
• Beispiel 152 umfasst den Gegenstand von Beispiel 151, wobei die mehreren anderen Geräte eines oder mehrere andere autonome Fahrzeuge, Luftdrohnen und straßenseitige Sensoren umfassen.
• Beispiel 153 umfasst den Gegenstand eines der Beispiele 143-152, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, einen Reiseplan für das autonome Fahrzeug zu erzeugen, wobei die Empfehlungsdaten die Bedingungen auf einem bevorstehenden Straßenabschnitt basierend auf dem Reiseplan beschreiben.
• Beispiel 154 ist ein Verfahren, das Folgendes umfasst: Erzeugen von Sensordaten an einem autonomen Fahrzeug aus einem Satz von einem oder mehreren Sensoren an dem Fahrzeug; Bestimmen von Bedingungen einer Umgebung, in der das autonome Fahrzeug betrieben werden soll, aus den Sensordaten; autonomes Bestimmen eines oder mehrerer Verfahren zum Verwalten von an dem autonomen Fahrzeug erzeugten Sensordaten durch Bereitstellen der Bedingungen als Eingaben für mindestens ein maschinelles Lernmodell; und Anwenden des einen oder der mehreren Verfahren auf das Sammeln der Sensordaten an dem Fahrzeug und/oder das Auslagern der Sensordaten auf ein oder mehrere Rechensysteme außerhalb des Fahrzeugs.
• Beispiel 155 umfasst den Gegenstand von Beispiel 154, wobei die eine oder die mehreren Prozeduren Prozeduren zum Auslagern mindestens eines Teils der Sensordaten auf ein oder mehrere Rechensysteme außerhalb des Fahrzeugs umfassen.
• Beispiel 156 umfasst den Gegenstand von Beispiel 155, wobei die Bedingungen die Bedingungen der für das Fahrzeug verfügbaren drahtlosen Kommunikationskanäle umfassen.
• Beispiel 157 umfasst den Gegenstand von einem der Beispiele 155-156, wobei die Bedingungen eine Menge des Datenanteils und eine Dringlichkeit des Datenanteils umfassen.
• Beispiel 158 umfasst den Gegenstand eines der Beispiele 155-157, wobei die Verfahren zum Auslagern des Datenanteils das Senden des Datenanteils mit einer bestimmten Auflösung umfassen.
• Beispiel 159 umfasst den Gegenstand eines der Beispiele 155-158, wobei die Verfahren zum Auslagern des Teils der Daten das Senden der Daten an ein bestimmtes externes Zielrechnersystem umfassen.
• Beispiel 160 umfasst den Gegenstand eines der Beispiele 155-159, wobei das eine oder die mehreren Rechensysteme außerhalb des Fahrzeugs eines oder mehrere andere Fahrzeuge, straßenseitige Einheiten, nebelbasierte Rechensysteme und cloudbasierte Rechensysteme umfassen.
• Beispiel 161 umfasst den Gegenstand eines der Beispiele 154-160, wobei das eine oder die mehreren Verfahren Verfahren zum Filtern von Sensordaten umfassen, die im Fahrzeug erzeugt werden, um in einem Datenspeicher innerhalb des Fahrzeugs gesammelt zu werden.
• Beispiel 162 umfasst den Gegenstand von Beispiel 161, wobei die Verfahren zum Filtern von Sensordaten dazu führen, dass ein gefilterter Teil der Sensordaten verworfen wird.
• Beispiel 163 umfasst den Gegenstand eines der Beispiele 154-162, einschließlich der Bestimmung eines Pfadplans für das Fahrzeug unter Verwendung eines oder mehrerer Modelle für maschinelles Lernen beim autonomen Fahren, wobei zumindest einige der Sensordaten den Modellen für maschinelles Lernen beim autonomen Fahren als Eingaben zur Verfügung gestellt werden sollen.
• Beispiel 164 umfasst den Gegenstand von Beispiel 163, wobei die Bedingungen Ereignisse umfassen, die als einen Routenabschnitt im ermittelten Pfadplan beeinflussend erkannt wurden.
• Beispiel 165 umfasst den Gegenstand eines der Beispiele 163-164, wobei die Bedingungen die Identifizierung einer Fahrumgebung auf dem bestimmten Pfadplan umfassen und die Fahrumgebung eines oder mehrere der folgenden Elemente umfasst: Wetter, das den Pfadplan beeinflusst, Verkehrsbedingungen, die den Pfadplan beeinflussen, und Straßenbedingungen, die den Pfadplan beeinflussen.
• Beispiel 166 umfasst den Gegenstand eines der Beispiele 154-165, wobei das eine oder die mehreren Verfahren als Empfehlung eines auf maschinellem Lernen basierenden Empfehlungssystems bereitgestellt werden, das im Fahrzeug implementiert ist.
• Beispiel 167 umfasst den Gegenstand eines der Beispiele 154-166, wobei das eine oder die mehreren Verfahren dazu dienen, die Effizienz der Nutzung einer oder mehrerer der internen Rechenressourcen des Fahrzeugs, der internen Speicherressourcen des Fahrzeugs, der Netzwerkbandbreite und der Ressourcen externer Rechensysteme durch das Fahrzeug zu verbessern.
• Beispiel 168 umfasst den Gegenstand eines der Beispiele 154-167, einschließlich der Anpassung eines Qualitätsniveaus eines oder mehrerer Sensoren auf der Grundlage der Bedingungen.
• Beispiel 169 ist ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 154-168.
• Beispiel 170 umfasst den Gegenstand von Beispiel 16, wobei die Mittel ein computerlesbares Medium zum Speichern von Anweisungen umfassen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, zumindest einen Teil des Verfahrens von einem der Beispiele 154-168 durchzuführen.
• Beispiel 171 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun erzeugen von Sensordaten an einem autonomen Fahrzeug aus einem Satz von einem oder mehreren Sensoren an dem Fahrzeug; Bestimmen von Bedingungen einer Umgebung, in der das autonome Fahrzeug betrieben werden soll, aus den Sensordaten; autonomes Bestimmen von einem oder mehreren Verfahren zum Verwalten von an dem autonomen Fahrzeug erzeugten Sensordaten durch Bereitstellen der Bedingungen als Eingaben für mindestens ein maschinelles Lernmodell; und Anwenden des einen oder der mehreren Verfahren auf mindestens eines von Sammeln der Sensordaten an dem Fahrzeug und Auslagern der Sensordaten zu einem oder mehreren Rechensystemen außerhalb des Fahrzeugs.
• Beispiel 172 umfasst den Gegenstand von Beispiel 171, wobei die eine oder die mehreren Prozeduren Prozeduren zum Auslagern mindestens eines Teils der Sensordaten auf ein oder mehrere Rechensysteme außerhalb des Fahrzeugs umfassen.
• Beispiel 173 umfasst den Gegenstand von Beispiel 172, wobei die Bedingungen die Bedingungen der für das Fahrzeug verfügbaren drahtlosen Kommunikationskanäle umfassen.
• Beispiel 174 umfasst den Gegenstand von einem der Beispiele 172-173, wobei die Bedingungen eine Menge des Datenanteils und eine Dringlichkeit des Datenanteils umfassen.
• Beispiel 175 umfasst den Gegenstand eines der Beispiele 172-174, wobei die Verfahren zum Auslagern des Datenanteils das Senden des Datenanteils mit einer bestimmten Auflösung umfassen.
• Beispiel 176 umfasst den Gegenstand eines der Beispiele 172-175, wobei die Verfahren zum Auslagern des Teils der Daten das Senden der Daten an ein bestimmtes externes Zielrechnersystem umfassen.
• Beispiel 177 umfasst den Gegenstand eines der Beispiele 172-176, wobei das eine oder die mehreren Rechensysteme außerhalb des Fahrzeugs eines oder mehrere andere Fahrzeuge, straßenseitige Einheiten, nebelbasierte Rechensysteme und cloudbasierte Rechensysteme umfassen.
• Beispiel 178 umfasst den Gegenstand eines der Beispiele 171-177, wobei das eine oder die mehreren Verfahren Verfahren zum Filtern von Sensordaten umfassen, die im Fahrzeug erzeugt werden, um in einem Datenspeicher im Fahrzeug gesammelt zu werden.
• Beispiel 179 umfasst den Gegenstand von Beispiel 178, wobei die Verfahren zum Filtern von Sensordaten dazu führen, dass ein gefilterter Teil der Sensordaten verworfen wird.
• Beispiel 180 umfasst den Gegenstand eines der Beispiele 171-179, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, einen Pfadplan für das Fahrzeug unter Verwendung eines oder mehrerer autonomer maschineller Fahrlernmodelle zu bestimmen, wobei zumindest einige der Sensordaten den autonomen maschinellen Fahrlernmodellen als Eingaben zur Verfügung gestellt werden sollen.
• Beispiel 181 umfasst den Gegenstand von Beispiel 180, wobei die Bedingungen Ereignisse umfassen, die als einen Routenabschnitt im ermittelten Pfadplan beeinflussend erkannt wurden.
• Beispiel 182 umfasst den Gegenstand eines der Beispiele 180-181, wobei die Bedingungen die Identifizierung einer Fahrumgebung auf dem bestimmten Pfadplan umfassen und die Fahrumgebung eines oder mehrere der folgenden Elemente umfasst: Wetter, das den Pfadplan beeinflusst, Verkehrsbedingungen, die den Pfadplan beeinflussen, und Straßenbedingungen, die den Pfadplan beeinflussen.
• Beispiel 183 umfasst den Gegenstand eines der Beispiele 171-182, wobei das eine oder die mehreren Verfahren als Empfehlung eines auf maschinellem Lernen basierenden Empfehlungssystems bereitgestellt werden, das im Fahrzeug implementiert ist.
• Beispiel 184 umfasst den Gegenstand eines der Beispiele 171-183, wobei das eine oder die mehreren Verfahren dazu dienen, die Effizienz der Nutzung einer oder mehrerer der internen Rechenressourcen des Fahrzeugs, der internen Speicherressourcen des Fahrzeugs, der Netzwerkbandbreite und der Ressourcen externer Rechensysteme durch das Fahrzeug zu verbessern.
• Beispiel 185 umfasst den Gegenstand eines der Beispiele 171-184, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, ein Qualitätsniveau eines oder mehrerer Sensoren aus dem Satz von Sensoren auf der Grundlage der Bedingungen anzupassen.
• Beispiel 186 ist ein Verfahren, das Folgendes umfasst: Erzeugen von Sensordaten von einem Satz von Sensoren an einem Fahrzeug; Bestimmen eines Pfadplans für das Fahrzeug; autonomes Steuern des Fahrens des Fahrzeugs gemäß dem Pfadplan auf der Grundlage eines oder mehrerer maschineller Lernmodelle und der Sensordaten; Bestimmen, dass die autonome Steuerung des Fahrzeugs beendet werden sollte; Senden einer Übergabeanforderung an ein entferntes Rechensystem, wobei das entfernte Rechensystem einen Remote-Valet-Service bereitstellt; Empfangen von Fahranweisungsdaten von dem entfernten Rechensystem; und Wiederaufnehmen des automatischen Fahrens des Fahrzeugs ansprechend auf Anweisungen, die in den Anweisungsdaten umfassen sind.
• Beispiel 187 umfasst den Gegenstand von Beispiel 186, wobei die Fahranweisungsdaten auf der Grundlage von Eingaben eines menschlichen Benutzers an dem entfernten Rechensystem erzeugt werden.
• Beispiel 188 umfasst den Gegenstand von einem der Beispiele 186-187, weiterhin umfassend: Erkennen eines Anhalte-Ereignisses, wobei das Fahrzeug anhalten und die Fahrt in Verbindung mit dem Anhalte-Ereignis beenden soll, wobei die Übergabeanforderung in Reaktion auf das Anhalte-Ereignis gesendet wird.
• Beispiel 189 umfasst den Gegenstand eines der Beispiele 186-188, wobei die Bestimmung, dass die autonome Steuerung des Fahrzeugs beendet werden sollte, die Vorhersage unter Verwendung eines bestimmten Maschinelles-Lernen-Modells umfasst, dass die Bedingungen auf einem bevorstehenden Abschnitt des Pfadplans Schwierigkeiten für das autonome Fahren während des bevorstehenden Abschnitts darstellen.
• Beispiel 190 umfasst den Gegenstand eines der Beispiele 186-189, bei dem bestimmt wird, dass die autonome Steuerung aufgrund der Erkennung eines oder mehrerer beeinträchtigter Sensoren am Fahrzeug beendet werden sollte.
• Beispiel 191 umfasst den Gegenstand von einem der Beispiele 186-190, einschließlich der Feststellung, dass keine qualifizierten Fahrgäste im Fahrzeug anwesend sind, wobei die Übergabeanforderung zumindest teilweise aufgrund der Feststellung gesendet wird, dass keine qualifizierten Fahrgäste anwesend sind.
• Beispiel 192 umfasst den Gegenstand eines der Beispiele 186-191, wobei ferner die Sensordaten an das entfernte Rechensystem gesendet werden, um einem Benutzer des entfernten Rechensystems eine dynamische Darstellung der Umgebung des Fahrzeugs zu präsentieren.
• Beispiel 193 umfasst den Gegenstand von Beispiel 192, wobei die Sensordaten Videodaten umfassen.
• Beispiel 194 umfasst den Gegenstand eines der Beispiele 192-193, wobei die Sensordaten über einen oder mehrere Kommunikationskanäle mit niedriger Latenz und hoher Priorität gesendet und die Fahranweisungsdaten empfangen werden
• Beispiel 195 umfasst den Gegenstand eines der Beispiele 186 bis 194, einschließlich der Darstellung einer Warnung für den Konsum durch die Fahrgäste des Fahrzeugs, um anzuzeigen, dass die Kontrolle über das Fahrzeug an den Remote-Valet-Service übergeben wurde.
• Beispiel 196 umfasst den Gegenstand eines der Beispiele 186-195, ferner: Erkennen einer Änderung der Bedingungen entlang des Pfadplans; Wiederherstellung der Kontrolle über das Fahren des Fahrzeugs von dem Remote-Valet-Service zur autonomen Fahrlogik des Fahrzeugs.
• Beispiel 197 ist ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 186-196.
• Beispiel 198 umfasst den Gegenstand von Beispiel 197, wobei die Mittel ein computerlesbares Medium zum Speichern von Anweisungen umfassen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, mindestens einen Teil des Verfahrens von einem der Beispiele 186-196 durchzuführen.
• Beispiel 199 ist ein Verfahren, das Folgendes umfasst: Bereitstellen einer Benutzerschnittstelle für einen menschlichen Benutzer an einem Computerendgerät; Empfangen einer Übergabeanforderung von einem Fahrzeug, das zum autonomen Fahren ausgebildet ist; Empfangen von Sensordaten von entfernten Sensorvorrichtungen, die eine Umgebung um das Fahrzeug herum beschreiben; Darstellen einer Darstellung der Umgebung auf der Benutzerschnittstelle auf der Grundlage der Sensordaten; Empfangen von Benutzereingaben an dem Computerendgerät ansprechend auf die Darstellung, wobei die Benutzereingaben Eingaben zum direkten Fahren des Fahrzeugs in der Umgebung umfassen; und Senden von Anweisungsdaten an das Fahrzeug entsprechend den Benutzereingaben, um das Fahrzeug gemäß den Benutzereingaben fernzusteuern.
• Beispiel 200 umfasst den Gegenstand von Beispiel 199, wobei die Übergabeanforderung einen Standort des Fahrzeugs angibt.
• Beispiel 201 umfasst den Gegenstand von Beispiel 200, ferner: Bestimmen von Sensorvorrichtungen, die dem Standort entsprechen, wobei sich die Sensorvorrichtungen außerhalb des Fahrzeugs befinden; und Zugreifen auf zusätzliche Sensordaten von den Sensorvorrichtungen, wobei die Darstellung zumindest teilweise auf der Grundlage der zusätzlichen Sensordaten dargestellt wird.
• Beispiel 202 umfasst den Gegenstand eines der Beispiele 199-201, wobei die Sensorvorrichtungen Sensorvorrichtungen am Fahrzeug umfassen.
• Beispiel 203 umfasst den Gegenstand eines der Beispiele 199-202, wobei die Sensorvorrichtungen vom Fahrzeug getrennte Sensorvorrichtungen umfassen.
• Beispiel 204 umfasst den Gegenstand eines der Beispiele 199-203, ferner: Empfangen einer Anforderung vom Fahrzeug, die Kontrolle über den Antrieb des Fahrzeugs an das Fahrzeug zurückzugeben; Senden einer Bestätigung der Rückgabe der Kontrolle an das Fahrzeug; und Beenden der Übertragung der Anweisungsdaten an das Fahrzeug.
• Beispiel 205 umfasst den Gegenstand von einem der Beispiele 199-203 und umfasst ferner: Erzeugen von Berichtsdaten, die die Umgebung und die Leistung des Fahrzeugs auf derGrundlage der Benutzereingaben während derSteuerung des Fahrzeugs durch den Remote-Valet-Service beschreiben; und Senden der Berichtsdaten an ein cloudbasiertes System.
• Beispiel 206 ist ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 199-205.
• Beispiel 207 umfasst den Gegenstand von Beispiel 206, wobei die Mittel ein computerlesbares Medium zum Speichern von Anweisungen umfassen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, mindestens einen Teil des Verfahrens von einem der Beispiele 199-205 durchzuführen.
• Beispiel 208 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun erzeugen von Sensordaten von einem Satz von Sensoren an einem Fahrzeug; Bestimmen eines Pfadplans für das Fahrzeug; autonomes Steuern des Fahrens des Fahrzeugs gemäß dem Pfadplan auf der Grundlage eines oder mehrerer maschineller Lernmodelle und der Sensordaten; Bestimmen, dass die autonome Steuerung des Fahrzeugs beendet werden sollte; Senden einer Übergabeanforderung an ein entferntes Rechensystem, wobei das entfernte Rechensystem einen Remote-Valet bereitstellt; Empfangen von Fahranweisungsdaten von dem entfernten Rechensystem; und Wiederaufnehmen des automatisierten Fahrens des Fahrzeugs in Reaktion auf Anweisungen, die in den Anweisungsdaten umfassen sind.
• Beispiel 209 umfasst den Gegenstand von Beispiel 208, wobei die Fahranweisungsdaten auf der Grundlage von Eingaben eines menschlichen Benutzers an dem entfernten Rechensystem erzeugt werden.
• Beispiel 210 umfasst den Gegenstand eines der Beispiele 208-209, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: ein Anhalte-Ereignis zu erkennen, wobei das Fahrzeug anhalten und in Verbindung mit dem Anhalte-Ereignis aufhören soll zu fahren, wobei die Übergabeanforderung in Reaktion auf das Anhalte-Ereignis gesendet wird.
• Beispiel 211 umfasst den Gegenstand eines der Beispiele 208-209, wobei die Bestimmung, dass die autonome Steuerung des Fahrzeugs beendet werden sollte, die Vorhersage unter Verwendung eines bestimmten Maschinelles-Lernen-Modells umfasst, dass die Bedingungen auf einem bevorstehenden Abschnitt des Pfadplans Schwierigkeiten für das autonome Fahren während des bevorstehenden Abschnitts darstellen.
• Beispiel 212 umfasst den Gegenstand eines der Beispiele 208-211, bei dem bestimmt wird, dass die autonome Steuerung aufgrund der Erkennung eines oder mehrerer beeinträchtigter Sensoren am Fahrzeug beendet werden sollte.
• Beispiel 213 umfasst den Gegenstand eines der Beispiele 208-212, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, festzustellen, dass keine qualifizierten Fahrgäste im Fahrzeug anwesend sind, wobei die Übergabeanforderung zumindest teilweise aufgrund der Feststellung, dass keine qualifizierten Fahrgäste anwesend sind, gesendet wird.
• Beispiel 214 umfasst den Gegenstand eines der Beispiele 208-213, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Sensordaten an das entfernte Rechensystem zu senden, um einem Benutzer des entfernten Rechensystems eine dynamische Darstellung der Umgebung des Fahrzeugs zu präsentieren.
• Beispiel 215 umfasst den Gegenstand von Beispiel 214, wobei die Sensordaten Videodaten umfassen.
• Beispiel 216 umfasst den Gegenstand eines der Beispiele 214-215, wobei die Sensordaten über einen oder mehrere Kommunikationskanäle mit niedriger Latenz und hoher Priorität gesendet und die Fahranweisungsdaten empfangen werden
• Beispiel 217 umfasst den Gegenstand eines der Beispiele 208-216, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, eine Warnung für den Konsum durch die Insassen des Fahrzeugs zu präsentieren, um zu erkennen, dass die Kontrolle des Fahrzeugs an den Remote-Valet-Service übergeben wird.
• Beispiel 218 umfasst den Gegenstand eines der Beispiele 208-217, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: eine Änderung der Bedingungen entlang des Pfadplans zu erkennen; die Steuerung des Fahrens des Fahrzeugs von dem Remote-Valet-Service auf die autonome Fahrlogik des Fahrzeugs zurückzuführen.
• Beispiel 219 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun bereitstellen einer Benutzerschnittstelle für einen menschlichen Benutzer an einem Computerendgerät; Empfangen einer Übergabeanforderung von einem Fahrzeug, das zum autonomen Fahren ausgebildet ist; Empfangen von Sensordaten von entfernten Sensorvorrichtungen, die eine Umgebung um das Fahrzeug herum beschreiben; Darstellen einer Darstellung der Umgebung auf der Benutzerschnittstelle auf der Grundlage der Sensordaten; Empfangen von Benutzereingaben an dem Computerendgerät ansprechend auf die Darstellung, wobei die Benutzereingaben Eingaben zum Lenken des Fahrens des Fahrzeugs innerhalb der Umgebung umfassen; und Senden von Anweisungsdaten an das Fahrzeug entsprechend den Benutzereingaben, um das Fahrzeug gemäß den Benutzereingaben fernzusteuern.
• Beispiel 220 umfasst den Gegenstand von Beispiel 219, wobei die Übergabeanforderung einen Standort des Fahrzeugs identifiziert.
• Beispiel 221 umfasst den Gegenstand von Beispiel 220, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: Sensorvorrichtungen zu bestimmen, die dem Standort entsprechen, wobei die Sensorvorrichtungen außerhalb des Fahrzeugs sind; und auf zusätzliche Sensordaten von den Sensorvorrichtungen zuzugreifen, wobei die Darstellung zumindest teilweise auf den zusätzlichen Sensordaten basiert.
• Beispiel 222 umfasst den Gegenstand eines der Beispiele 219-221, wobei die Sensorvorrichtungen Sensorvorrichtungen am Fahrzeug umfassen.
• Beispiel 223 umfasst den Gegenstand eines der Beispiele 219-222, wobei die Sensorvorrichtungen vom Fahrzeug getrennte Sensorvorrichtungen umfassen.
• Beispiel 224 umfasst den Gegenstand eines der Beispiele 219-223, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: eine Anforderung von dem Fahrzeug zu empfangen, die Kontrolle über den Antrieb des Fahrzeugs an das Fahrzeug zurückzugeben; eine Bestätigung der Rückgabe der Kontrolle an das Fahrzeug zu senden; und die Übertragung der Anweisungsdaten an das Fahrzeug zu beenden.
• Beispiel 225 umfasst den Gegenstand eines der Beispiele 219-224, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: Berichtsdaten zu erzeugen, die die Umgebung und die Leistung des Fahrzeugs auf der Grundlage der Benutzereingaben während der Steuerung des Fahrzeugs durch den Remote-Valet-Service beschreiben; und die Berichtsdaten an ein cloudbasiertes System zu senden.
• Beispiel 226 ist ein Verfahren, das Folgendes umfasst: erzeugen von Sensordaten von einem Satz von Sensoren an einem Fahrzeug; Bestimmen eines Pfadplans für das Fahrzeug; autonomes Steuern des Fahrens des Fahrzeugs gemäß dem Pfadplan auf der Grundlage eines oder mehrerer maschineller Lernmodelle und der Sensordaten; Identifizieren von Bedingungen auf einem bevorstehenden Abschnitt des Pfadplans; Bestimmen einer Gelegenheit, die Steuerung des Fahrens des Fahrzeugs auf der Grundlage der Bedingungen an einen Remote-Valet-Service zu übergeben; senden einer Übergabeanforderung an ein entferntes Rechensystem auf der Grundlage der Gelegenheit, wobei das entfernte Rechensystem den Remote-Valet-Service bereitstellt; Empfangen von Fahranweisungsdaten von dem entfernten Rechensystem; und Automatisieren des Fahrens des Fahrzeugs ansprechend auf die in den Anweisungsdaten umfassten Anweisungen.
• Beispiel 227 umfasst den Gegenstand von Beispiel 226, ferner das Senden von Berichtsdaten an ein anderes Rechensystem, die die Übergabe und die der Übergabe entsprechenden Bedingungen identifizieren.
• Beispiel 228 umfasst den Gegenstand von Beispiel 227, wobei die Berichtsdaten an eine cloudbasierte Anwendung gesendet werden.
• Beispiel 229 umfasst den Gegenstand eines der Beispiele 227-228, wobei die Berichtsdaten an eine straßenseitige Einheit gesendet werden.
• Beispiel 230 umfasst den Gegenstand eines der Beispiele 226-229, wobei die Bedingungen aus Daten identifiziert werden, die von einem anderen Rechensystem empfangen werden.
• Beispiel 231 umfasst den Gegenstand von Beispiel 230, wobei die Bedingungen durch Anwendung eines Maschinelles-Lernen-Modells identifiziert werden und die Daten von dem anderen System als Eingabe für das Maschinelles-Lernen-Modell bereitgestellt werden.
• Beispiel 232 umfasst den Gegenstand von Beispiel 231, wobei das Maschinelles-Lernen-Modell auf der Grundlage von Daten trainiert wird, die andere Fälle von entweder einer Übergabe an einen Remote-Valet-Service oder ein Anhalte-Ereignis melden.
• Beispiel 233 umfasst den Gegenstand eines der Beispiele 226-232, wobei die Weiterreichungsanforderung gesendet wird, um ein Anhalte-Ereignis zu vermeiden.
• Beispiel 234 umfasst den Gegenstand eines der Beispiele 226-233, wobei die Gelegenheit einer Vorhersage entspricht, dass die autonome Fahrfunktion des Fahrzeugs angesichts der Bedingungen schlecht funktionieren wird.
• Beispiel 235 umfasst den Gegenstand eines der Beispiele 226-234, wobei die Gelegenheit zumindest teilweise auf der Grundlage der in den Sensordaten umfassten Informationen bestimmt wird.
• Beispiel 236 schließt den Gegenstand eines der Beispiele 226-235 ein und umfasst ferner: Zugriff auf zusätzliche Daten; Vorhersage einer Verbesserung der Bedingungen auf einem anderen Abschnitt des Pfadplans, der dem bevorstehenden Weg folgt, auf der Grundlage der zusätzlichen Daten; und Senden von Anforderungsdaten an das entfernte Rechensystem, um anzufordern, dass die Steuerung auf der Grundlage der vorhergesagten Verbesserung der Bedingungen an das Fahrzeug zurückgegeben wird; und Wiederaufnahme der autonomen Steuerung des Fahrens des Fahrzeugs.
• Beispiel 237 umfasst den Gegenstand eines der Beispiele 226-236, wobei das Bestimmen der Gelegenheit zur Übergabe der Kontrolle das Erkennen eines Anhalte-Ereignisses umfasst.
• Beispiel 238 umfasst den Gegenstand von Beispiel 237, ferner: Bestimmen von Bedingungen aus den Sensordaten, die mit dem Anhalte-Ereignis verbunden sind; und Hochladen von Daten, die die Bedingungen beschreiben, zu einem entfernten Rechnersystem.
• Beispiel 239 ist ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 226-238.
• Beispiel 240 umfasst den Gegenstand von Beispiel 239, wobei die Mittel ein computerlesbares Medium zum Speichern von Anweisungen umfassen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, mindestens einen Teil des Verfahrens von einem der Beispiele 226-238 durchzuführen.
• Beispiel 241 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun erzeugen von Sensordaten von einem Satz von Sensoren an einem Fahrzeug; Bestimmen eines Pfadplans für das Fahrzeug; autonomes Steuern des Fahrens des Fahrzeugs gemäß dem Pfadplan auf der Grundlage von einem oder mehreren Maschinenlernmodellen und den Sensordaten; Identifizieren von Bedingungen auf einem bevorstehenden Abschnitt des Pfadplans; Bestimmen einer Gelegenheit, die Steuerung des Fahrens des Fahrzeugs auf der Grundlage der Bedingungen an einen Remote-Valet-Service zu übergeben; Senden einer Übergabeanforderung an ein entferntes Rechensystem auf der Grundlage der Gelegenheit, wobei das entfernte Rechensystem den Remote-Valet-Service bereitstellt; Empfangen von Fahranweisungsdaten von dem entfernten Rechensystem; und Automatisieren des Fahrens des Fahrzeugs in Reaktion auf die in den Anweisungsdaten umfassten Anweisungen.
• Beispiel 242 umfasst den Gegenstand von Beispiel 241, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, Berichtsdaten an ein anderes Rechensystem zu senden, die die Übergabe und die der Übergabe entsprechenden Bedingungen identifizieren.
• Beispiel 243 umfasst den Gegenstand von Beispiel 242, wobei die Berichtsdaten an eine cloudbasierte Anwendung gesendet werden.
• Beispiel 244 umfasst den Gegenstand eines der Beispiele 242-243, wobei die Berichtsdaten an eine straßenseitige Einheit gesendet werden.
• Beispiel 245 umfasst den Gegenstand eines der Beispiele 241-244, wobei die Bedingungen aus Daten identifiziert werden, die von einem anderen Rechensystem empfangen werden.
• Beispiel 246 umfasst den Gegenstand von Beispiel 245, wobei die Bedingungen durch Anwendung eines Maschinelles-Lernen-Modells identifiziert werden und die Daten des anderen Systems als Eingabe für das Maschinelles-Lernen-Modell bereitgestellt werden.
• Beispiel 247 schließt den Gegenstand von Beispiel 246 ein, wobei das Maschinelles-Lernen-Modell auf der Grundlage von Daten trainiert wird, die andere Fälle von entweder einer Übergabe an einen Remote-Valet-Service oder ein Anhalte-Ereignis melden.
• Beispiel 248 umfasst den Gegenstand eines der Beispiele 241-247, wobei die Weiterreichungsanforderung gesendet wird, um ein Anhalte-Ereignis zu vermeiden.
• Beispiel 249 umfasst den Gegenstand eines der Beispiele 241-248, wobei die Gelegenheit einer Vorhersage entspricht, dass die autonome Fahrfunktion des Fahrzeugs angesichts der Bedingungen schlecht funktionieren wird.
• Beispiel 250 umfasst den Gegenstand eines der Beispiele 241-249, wobei die Gelegenheit zumindest teilweise auf der Grundlage der in den Sensordaten umfassten Informationen bestimmt wird.
• Beispiel 251 umfasst den Gegenstand eines der Beispiele 241-250, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: auf zusätzliche Daten zuzugreifen; eine Verbesserung der Bedingungen auf einem anderen Abschnitt des Pfadplans, der dem bevorstehenden Weg folgt, auf der Grundlage der zusätzlichen Daten vorherzusagen; und Anforderungsdaten an das entfernte Rechensystem zu senden, um anzufordern, dass die Steuerung auf der Grundlage der vorhergesagten Verbesserung der Bedingungen an das Fahrzeug zurückgegeben wird; und die autonome Steuerung des Fahrens des Fahrzeugs wieder aufzunehmen.
• Beispiel 252 umfasst den Gegenstand eines der Beispiele 241-251, wobei das Bestimmen der Gelegenheit zur Übergabe der Kontrolle das Erkennen eines Anhalte-Ereignisses umfasst.
• Beispiel 253 umfasst den Gegenstand von Beispiel 252, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: Bedingungen aus den Sensordaten zu bestimmen, die mit dem Anhalte-Ereignis verbunden sind; und Daten, die die Bedingungen beschreiben, zu einem entfernten Rechensystem hochzuladen.
• Beispiel 254 ist ein Verfahren, das Folgendes umfasst: empfangen eines Umgebungsmodells, das auf der Grundlage von Sensordaten von einer Mehrzahl von Sensoren, die mit einem autonomen Fahrzeug gekoppelt sind, erzeugt wurde; Bestimmen, auf der Grundlage von Informationen in dem Umgebungsmodell, einer Variation in einem oder mehreren Verhaltensweisen von anderen Fahrzeugen als dem autonomen Fahrzeug; bestimmen, basierend auf Informationen in dem Umgebungsmodell, einer Abweichung zwischen einem oder mehreren Verhaltensweisen der Fahrzeuge, die nicht das autonome Fahrzeug sind, und demselben oder denselben Verhaltensweisen, die von dem autonomen Fahrzeug ausgeführt werden; Bestimmen, basierend auf der bestimmten Variation und der Abweichung, einer oder mehrerer Beschränkungen für ein Verhaltensmodell für das autonome Fahrzeug; und Anwenden der einen oder mehreren Beschränkungen auf das Verhaltensmodell, um den Betrieb des autonomen Fahrzeugs zu steuern.
• Beispiel 255 umfasst den Gegenstand von Beispiel 254, ferner: Konstruieren eines Szenarios auf der Grundlage des Umgebungsmodells und dergeographischen Standortinformationen für das autonome Fahrzeug; und Zuordnen der Beschränkungen zu dem Szenario in einem sozialen Normprofil für das Verhaltensmodell des autonomen Fahrzeugs.
• Beispiel 256 umfasst den Gegenstand von Beispiel 255, wobei das Szenario auf einer oder mehreren der folgenden Informationen basiert: Anzahl der Fahrzeuge in der Nähe des autonomen Fahrzeugs, Geschwindigkeit für jedes der ein oder der mehreren Fahrzeuge in der Nähe des autonomen Fahrzeugs, Tageszeit und Wetterbedingungen.
• Beispiel 257 umfasst den Gegenstand eines der Beispiele 254-256, wobei das Bestimmen der Variation das Bestimmen umfasst, ob das beobachtete Verhalten innerhalb der aktuellen Parameter des Verhaltensmodells für das autonome Fahrzeug liegt.
• Beispiel 258 umfasst den Gegenstand von Beispiel 257, wobei die Variation auf einem euklidischen Abstand zu dem aktuellen Verhaltensmodell aus den Beobachtungen der umgebenden Fahrzeuge basiert.
• Beispiel 259 umfasst den Gegenstand eines der Beispiele 254-256, wobei die Bestimmung der Abweichung die Bestimmung umfasst, ob die Abweichung des Verhaltens innerhalb der aktuellen Parameter des Verhaltensmodells für das autonome Fahrzeug liegt.
• Beispiel 260 umfasst den Gegenstand von Beispiel 259, wobei die Abweichung auf negativen Rückkopplungsübertretungen basiert, die als Grenzen für das Verhalten dienen.
• Beispiel 261 umfasst den Gegenstand eines der Beispiele 254-260, wobei die Variation und die Abweichung auf Informationen im Umgebungsmodell beruhen, die mit dynamischen Hindernissen verbunden sind.
• Beispiel 262 ist eine Vorrichtung, die Folgendes umfasst: einen Speicher; und eine mit dem Speicher gekoppelte Verarbeitungsschaltung zur Durchführung eines oder mehrerer der Verfahren der Beispiele 254-261.
• Beispiel 263 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 254-261.
• Beispiel 264 ist ein Produkt, das ein oder mehrere greifbare, computerlesbare, nicht-übertragbare Speichermedien umfasst, die computerausführbare Anweisungen umfassen, die, wenn sie von mindestens einem Computerprozessor ausgeführt werden, den mindestens einen Computerprozessor in die Lage versetzen, Operationen der Verfahren der Beispiele 254-261 zu implementieren.
• Beispiel 265 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun empfangen eines Umgebungsmodells, das auf der Grundlage von Sensordaten von einer Mehrzahl von Sensoren, die mit einem autonomen Fahrzeug gekoppelt sind, erzeugt wurde; Bestimmen, auf der Grundlage von Informationen in dem Umgebungsmodell, einer Variation in einem oder mehreren Verhaltensweisen von anderen Fahrzeugen als dem autonomen Fahrzeug; bestimmen, basierend auf Informationen in dem Umgebungsmodell, einer Abweichung zwischen einem oder mehreren Verhaltensweisen der Fahrzeuge, die nicht das autonome Fahrzeug sind, und demselben oder denselben Verhaltensweisen, die von dem autonomen Fahrzeug ausgeführt werden; Bestimmen, basierend auf der bestimmten Variation und Abweichung, einer oder mehrerer Beschränkungen für ein Verhaltensmodell für das autonome Fahrzeug; und Anwenden der einen oder mehreren Beschränkungen auf das Verhaltensmodell, um den Betrieb des autonomen Fahrzeugs zu steuern.
• Beispiel 266 umfasst den Gegenstand von Beispiel 265, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: ein Szenario auf der Grundlage des Umgebungsmodells und der geografischen Standortinformationen für das autonome Fahrzeug zu konstruieren; und die Einschränkungen mit dem Szenario in einem sozialen Normprofil für das Verhaltensmodell des autonomen Fahrzeugs zu verknüpfen.
• Beispiel 267 umfasst den Gegenstand von Beispiel 266, wobei das Szenario auf einer oder mehreren der folgenden Informationen basiert: Anzahl der Fahrzeuge in der Nähe des autonomen Fahrzeugs, Geschwindigkeit für jedes der ein oder mehreren Fahrzeuge in der Nähe des autonomen Fahrzeugs, Tageszeit und Wetterbedingungen.
• Beispiel 268 umfasst den Gegenstand eines der Beispiele 265-267, wobei das Bestimmen der Variation das Bestimmen umfasst, ob das beobachtete Verhalten innerhalb der aktuellen Parameter des Verhaltensmodells für das autonome Fahrzeug liegt.
• Beispiel 269 umfasst den Gegenstand von Beispiel 268, wobei die Variation auf einem euklidischen Abstand zu dem aktuellen Verhaltensmodell aus den Beobachtungen der umgebenden Fahrzeuge basiert.
• Beispiel 270 umfasst den Gegenstand eines der Beispiele 265-267, wobei die Bestimmung der Abweichung die Bestimmung einschließt, ob die Abweichung des Verhaltens innerhalb der aktuellen Parameter des Verhaltensmodells für das autonome Fahrzeug liegt.
• Beispiel 271 umfasst den Gegenstand von Beispiel 270, wobei die Abweichung auf negativen Rückkopplungsübertretungen basiert, die als Grenzen für das Verhalten dienen.
• Beispiel 272 umfasst den Gegenstand eines der Beispiele 265-271, wobei die Variation und die Abweichung auf Informationen im Umgebungsmodell beruhen, die mit dynamischen Hindernissen verbunden sind.
• Beispiel 273 ist ein Verfahren, das Folgendes umfasst: erzeugen von Sensordaten von einem Satz von Sensoren an einem ersten Fahrzeug; Bestimmen eines Pfadplans für das erste Fahrzeug; autonomes Steuern des Fahrens des ersten Fahrzeugs gemäß dem Pfadplan auf der Grundlage eines oder mehrerer maschineller Lernmodelle und der Sensordaten; Empfangen eines Signals an dem ersten Fahrzeug, das ein anderes, zweites Fahrzeug in der Nähe des ersten Fahrzeugs identifiziert; kommunizieren mit dem zweiten Fahrzeug, um ein mit dem zweiten Fahrzeug assoziiertes Verhaltensmodell zu erhalten, wobei das Verhaltensmodell ein bestimmtes maschinelles Lernmodell umfasst, um das Fahrverhalten des zweiten Fahrzeugs zu bestimmen; Bestimmen der Vertrauenswürdigkeit des Verhaltensmodells; und Verwenden des Verhaltensmodells, um Aktionen des zweiten Fahrzeugs vorherzusagen.
• Beispiel 274 umfasst den Gegenstand von Beispiel 273, wobei das zweite Fahrzeug eine autonome Fahrfunktionalität aufweist und das Verhaltensmodell den Maschinelles-Lernen-Modellen entspricht, die vom zweiten Fahrzeug zur Bestimmung des autonomen Fahrverhaltens verwendet werden.
• Beispiel 275 umfasst den Gegenstand eines der Beispiele 273-274, wobei das Bestimmen der Vertrauenswürdigkeit des Verhaltensmodells das Verifizieren eines Formats des Modells umfasst.
• Beispiel 276 umfasst den Gegenstand eines der Beispiele 273-275, wobei die Bestimmung der Vertrauenswürdigkeit des Verhaltensmodells die Überprüfung der Genauigkeit des Modells umfasst.
• Beispiel 277 umfasst den Gegenstand von Beispiel 276, wobei die Überprüfung der Genauigkeit des Verhaltensmodells Folgendes umfasst: Speichern von Eingaben, die mindestens einem der maschinellen Lernmodelle zur Verfügung gestellt werden, und entsprechender Ausgaben durch das mindestens eine maschinelle Lernmodell; wobei die Genauigkeit des Modells überprüft wird, indem die Eingaben dem Verhaltensmodell zur Verfügung gestellt werden und die Ausgaben des Verhaltensmodells mit den Ausgaben des mindestens einen Maschinelles-Lernen-Modells verglichen werden.
• Beispiel 278 umfasst den Gegenstand von Beispiel 276, wobei die Überprüfung der Genauigkeit des Verhaltensmodells Folgendes umfasst: Bereitstellen von Eingaben für das Verhaltensmodell, die beobachteten Bedingungen entsprechen; Bestimmen des erwarteten Verhaltens des zweiten Fahrzeugs anhand des Verhaltensmodells auf der Grundlage der Eingaben; Beobachten des Verhaltens des zweiten Fahrzeugs entsprechend den beobachteten Bedingungen; und Vergleichen des beobachteten Verhaltens mit dem erwarteten Verhalten.
• Beispiel 279 umfasst den Gegenstand eines der Beispiele 273-278, wobei die Kommunikation mit dem zweiten Fahrzeug den Aufbau einer sicheren Kommunikationssitzung zwischen dem ersten Fahrzeug und dem zweiten Fahrzeug umfasst und das Verhaltensmodell in der Kommunikation innerhalb der sicheren Kommunikationssitzung empfangen wird.
• Beispiel 280 umfasst den Gegenstand von Beispiel 279, wobei der Aufbau der sicheren Kommunikationssitzung den Austausch von Token zwischen dem ersten und dem zweiten Fahrzeug umfasst, und jedes Token einen jeweiligen Identifikator des entsprechenden Fahrzeugs, einen jeweiligen öffentlichen Schlüssel und einen gemeinsam genutzten geheimen Wert umfasst.
• Beispiel 281 umfasst den Gegenstand eines der Beispiele 273-280, wobei das Signal einen Beacon umfasst, um die Identität und Position des zweiten Fahrzeugs anzuzeigen.
• Beispiel 282 umfasst den Gegenstand eines der Beispiele 273 bis 281 und umfasst ferner: Senden eines Signals an andere Fahrzeuge in der Nähe des ersten Fahrzeugs, um das erste Fahrzeug für die anderen Fahrzeuge zu identifizieren.
• Beispiel 283 umfasst den Gegenstand eines der Beispiele 273-282, wobei das Verhaltensmodell ein zweites Verhaltensmodell umfasst, das zweite Verhaltensmodell in einem Austausch von Verhaltensmodellen zwischen dem ersten und dem zweiten Verhaltensmodell erhalten wird und das erste Fahrzeug ein erstes Verhaltensmodell, das auf einem oder mehreren der maschinellen Lernmodelle basiert, an das zweite Fahrzeug in dem Austausch von Verhaltensmodellen sendet.
• Beispiel 284 umfasst den Gegenstand eines der Beispiele 273-283, wobei ferner festgestellt wird, ob das Verhaltensmodell für das zweite Modell in einer Modelldatenbank des ersten Fahrzeugs umfassen ist, wobei das Verhaltensmodell für das zweite Modell auf der Grundlage der Feststellung erhalten wird, dass das Verhaltensmodell noch nicht in der Modelldatenbank umfassen ist.
• Beispiel 285 umfasst den Gegenstand von Beispiel 273, wobei das zweite Fahrzeug einen menschlichen Fahrmodus aufweist und das Verhaltensmodell die Eigenschaften menschlicher Fahrer im zweiten Fahrzeug während des menschlichen Fahrmodus modelliert.
• Beispiel 286 umfasst den Gegenstand eines der Beispiele 273-285, wobei das Verhaltensmodell eines aus einem Satz von Verhaltensmodellen für das zweite Fahrzeug umfasst und der Satz von Verhaltensmodellen eine Mehrzahl von szenariospezifischen Verhaltensmodellen umfasst.
• Beispiel 287 umfasst den Gegenstand von Beispiel 286, ferner umfassend: Bestimmen eines bestimmten Szenarios zumindestteilweise auf der Grundlage der Sensordaten; Bestimmen, dass ein bestimmtes Verhaltensmodell in dem Satz von Verhaltensmodellen dem bestimmten Szenario entspricht, wobei das bestimmte Verhaltensmodell verwendet wird, um Aktionen des zweiten Fahrzeugs auf der Grundlage der Bestimmung, dass das bestimmte Verhaltensmodell dem bestimmten Szenario entspricht, vorherzusagen.
• Beispiel 288 umfasst den Gegenstand eines der Beispiele 273 bis 287, ferner umfassend: Bereitstellen von Daten, die die vorhergesagten Aktionen des zweiten Fahrzeugs beschreiben, die aus dem Verhaltensmodell abgeleitet werden, als Eingaben für mindestens eines der maschinellen Lernmodelle des ersten Fahrzeugs; und Veranlassen des ersten Fahrzeugs, auf der Grundlage einer Ausgabe zu fahren, die von dem mindestens einen der maschinellen Lernmodelle auf der Grundlage der Eingaben abgeleitet wird.
• Beispiel 289 umfasst den Gegenstand von Beispiel 288, wobei das Führen des ersten Fahrzeugs auf der Grundlage der vorhergesagten Aktionen zu einem anderen Verhalten des ersten Fahrzeugs führt als die Standardfahrentscheidungen des ersten Fahrzeugs.
• Beispiel 290 ist ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 273-289.
• Beispiel 291 umfasst den Gegenstand von Beispiel 290, wobei die Mittel ein computerlesbares Medium zum Speichern von Anweisungen umfassen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, mindestens einen Teil des Verfahrens eines der Beispiele 273-289 durchzuführen.
• Beispiel 292 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen zum: Erzeugen von Sensordaten von einem Satz von Sensoren an einem ersten Fahrzeug; Bestimmen eines Pfadplans für das erste Fahrzeug; autonomen Steuern des Fahrens des ersten Fahrzeugs gemäß dem Pfadplan auf der Grundlage eines oder mehrerer maschineller Lernmodelle und der Sensordaten; Empfangen eines Signals an dem ersten Fahrzeug, das ein anderes, zweites Fahrzeug in der Nähe des ersten Fahrzeugs identifiziert; Kommunizieren mit dem zweiten Fahrzeug, um ein Verhaltensmodell zu erhalten, das dem zweiten Fahrzeug zugeordnet ist, wobei das Verhaltensmodell ein bestimmtes maschinelles Lernmodell umfasst, um das Fahrverhalten des zweiten Fahrzeugs zu bestimmen; Bestimmen der Vertrauenswürdigkeit des Verhaltensmodells; und Verwenden des Verhaltensmodells, um Aktionen des zweiten Fahrzeugs vorherzusagen.
• Beispiel 293 umfasst den Gegenstand von Beispiel 292, wobei das zweite Fahrzeug eine autonome Fahrfunktionalität aufweist und das Verhaltensmodell den Maschinelles-Lernen-Modellen entspricht, die vom zweiten Fahrzeug zur Bestimmung des autonomen Fahrverhaltens verwendet werden.
• Beispiel 294 umfasst den Gegenstand eines der Beispiele 292-293, wobei das Bestimmen der Vertrauenswürdigkeit des Verhaltensmodells das Verifizieren eines Formats des Modells umfasst.
• Beispiel 295 umfasst den Gegenstand eines der Beispiele 292-294, wobei die Bestimmung der Vertrauenswürdigkeit des Verhaltensmodells die Überprüfung der Genauigkeit des Modells umfasst.
• Beispiel 296 umfasst den Gegenstand von Beispiel 295, wobei die Überprüfung der Genauigkeit des Verhaltensmodells Folgendes umfasst: Speichern von Eingaben, die mindestens einem der maschinellen Lernmodelle zur Verfügung gestellt werden, und entsprechender Ausgaben durch das mindestens eine maschinelle Lernmodell; wobei die Genauigkeit des Modells überprüft wird, indem die Eingaben dem Verhaltensmodell zur Verfügung gestellt werden und die Ausgaben des Verhaltensmodells mit den Ausgaben des mindestens einen Maschinelles-Lernen-Modells verglichen werden.
• Beispiel 297 umfasst den Gegenstand von Beispiel 295, wobei das Überprüfen der Genauigkeit des Verhaltensmodells Folgendes umfasst: Bereitstellen von Eingaben für das Verhaltensmodell, die beobachteten Bedingungen entsprechen; Bestimmen des erwarteten Verhaltens des zweiten Fahrzeugs anhand des Verhaltensmodells auf der Grundlage der Eingaben; Beobachten des Verhaltens des zweiten Fahrzeugs, das den beobachteten Bedingungen entspricht; und Vergleichen des beobachteten Verhaltens mit dem erwarteten Verhalten.
• Beispiel 298 umfasst den Gegenstand eines der Beispiele 292 bis 297, wobei die Kommunikation mit dem zweiten Fahrzeug den Aufbau einer sicheren Kommunikationssitzung zwischen dem ersten Fahrzeug und dem zweiten Fahrzeug umfasst, und das Verhaltensmodell in der Kommunikation innerhalb der sicheren Kommunikationssitzung empfangen wird.
• Beispiel 299 umfasst den Gegenstand von Beispiel 298, wobei der Aufbau der sicheren Kommunikationssitzung den Austausch von Token zwischen dem ersten und dem zweiten Fahrzeug umfasst, und jedes Token einen jeweiligen Identifikator des entsprechenden Fahrzeugs, einen jeweiligen öffentlichen Schlüssel und einen gemeinsam genutzten geheimen Wert umfasst.
• Beispiel 300 umfasst den Gegenstand eines der Beispiele 292-299, wobei das Signal einen Beacon umfasst, um die Identität und Position des zweiten Fahrzeugs anzuzeigen.
• Beispiel 301 umfasst den Gegenstand eines der Beispiele 292 bis 300 und umfasst außerdem: Senden eines Signals an andere Fahrzeuge in der Nähe des ersten Fahrzeugs, um das erste Fahrzeug für die anderen Fahrzeuge zu identifizieren.
• Beispiel 302 umfasst den Gegenstand eines der Beispiele 292-301, wobei das Verhaltensmodell ein zweites Verhaltensmodell umfasst, das zweite Verhaltensmodell in einem Austausch von Verhaltensmodellen zwischen dem ersten und dem zweiten Verhaltensmodell erhalten wird und das erste Fahrzeug ein erstes Verhaltensmodell basierend auf einem oder mehreren der maschinellen Lernmodelle an das zweite Fahrzeug in dem Austausch von Verhaltensmodellen sendet.
• Beispiel 303 umfasst den Gegenstand eines der Beispiele 292-302, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, festzustellen, ob das Verhaltensmodell für das zweite Modell in einer Modelldatenbank des ersten Fahrzeugs ist, wobei das Verhaltensmodell für das zweite Modell auf der Grundlage der Feststellung erhalten wird, dass das Verhaltensmodell noch nicht in der Modelldatenbank ist.
• Beispiel 304 umfasst den Gegenstand von Beispiel 292, wobei das zweite Fahrzeug einen menschlichen Fahrmodus aufweist und das Verhaltensmodell Eigenschaften menschlicher Fahrer im zweiten Fahrzeug während des menschlichen Fahrmodus modelliert.
• Beispiel 305 umfasst den Gegenstand eines der Beispiele 292-304, wobei das Verhaltensmodell eines aus einem Satz von Verhaltensmodellen für das zweite Fahrzeug umfasst, und der Satz von Verhaltensmodellen eine Mehrzahl von szenariospezifischen Verhaltensmodellen umfasst.
• Beispiel 306 umfasst den Gegenstand von Beispiel 305, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: ein bestimmtes Szenario zumindest teilweise auf der Grundlage der Sensordaten zu bestimmen; zu bestimmen, dass ein bestimmtes Verhaltensmodell in dem Satz von Verhaltensmodellen dem bestimmten Szenario entspricht, wobei das bestimmte Verhaltensmodell verwendet wird, um Aktionen des zweiten Fahrzeugs auf der Grundlage der Bestimmung, dass das bestimmte Verhaltensmodell dem bestimmten Szenario entspricht, vorherzusagen.
• Beispiel 307 umfasst den Gegenstand eines der Beispiele 292-306, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: Daten, die die vorhergesagten Aktionen des zweiten Fahrzeugs beschreiben, die aus dem Verhaltensmodell abgeleitet werden, als Eingaben für mindestens eines der maschinellen Lernmodelle des ersten Fahrzeugs bereitzustellen; und das erste Fahrzeug zu veranlassen, auf der Grundlage einer Ausgabe zu fahren, die von dem mindestens einen der maschinellen Lernmodelle auf der Grundlage der Eingaben abgeleitet wird.
• Beispiel 308 umfasst den Gegenstand von Beispiel 307, wobei das Führen des ersten Fahrzeugs auf der Grundlage der vorhergesagten Aktionen zu einem anderen Verhalten des ersten Fahrzeugs führt als die Standardfahrentscheidungen des ersten Fahrzeugs.
• Beispiel 309 ist ein Verfahren, das Folgendes umfasst: Teilnehmen an einer ersten Konsensverhandlung mit einer ersten Mehrzahl von Fahrzeugen, wobei in der ersten Konsensverhandlung Verhaltensmodelle von mindestens einem Teil der ersten Mehrzahl von Fahrzeugen ausgetauscht werden, und das Teilnehmen an der ersten Konsensverhandlung das Empfangen jedes der ausgetauschten Verhaltensmodelle und das Bestimmen der Gültigkeit jedes der Verhaltensmodelle in der ersten Konsensverhandlung umfasst; Teilnehmen an einer zweiten Konsensverhandlung mit einer zweiten Mehrzahl von Fahrzeugen, wobei Verhaltensmodelle von mindestens einem Teil der zweiten Mehrzahl von Fahrzeugen in der zweiten Konsensverhandlung ausgetauscht werden und das Teilnehmen an der zweiten Konsensverhandlung das Empfangen jedes der ausgetauschten Verhaltensmodelle und das Bestimmen der Gültigkeit jedes der Verhaltensmodelle in der zweiten Konsensverhandlung umfasst; und Erzeugen eines Konsensverhaltensmodells aus den ersten und zweiten Konsensverhandlungen.
• Beispiel 310 umfasst den Gegenstand von Beispiel 309, wobei das Konsens-Verhaltensmodell an eine dritte Mehrzahl von Fahrzeugen verteilt wird.
• Beispiel 311 umfasst den Gegenstand von Beispiel 310, wobei das Konsensverhaltensmodell in einer dritten Konsensverhandlung verteilt wird.
• Beispiel 312 umfasst den Gegenstand eines der Beispiele 309-311, wobei die erste und zweite Konsensverhandlung auf einem byzantinischen Fehlertoleranz-Konsensalgorithmus basieren.
• Beispiel 313 umfasst den Gegenstand eines der Beispiele 309-312, wobei die Verhaltensmodelle auf neuronalen Netzen basierende Modelle umfassen.
• Beispiel 314 umfasst den Gegenstand eines der Beispiele 309-313, wobei mindestens eines der ersten oder zweiten Mehrzahl von Fahrzeugen ein nicht-autonomes Fahrzeug mit einem menschlichen Fahrer umfasst.
• Beispiel 315 umfasst den Gegenstand von Beispiel 314, einschließlich der Bestimmung eines Verhaltensmodells, das dem nicht-autonomen Fahrzeug entspricht.
• Beispiel 316 umfasst den Gegenstand von Beispiel 315, ferner das Erzeugen von Sensordaten an einem oder mehreren lokalen Sensoren, um eine Mehrzahl von Verhaltensweisen eines oder mehrerer nicht-autonomer Fahrzeuge zu beobachten, wobei das dem nicht-autonomen Fahrzeug entsprechende Verhaltensmodell auf den Sensordaten basiert.
• Beispiel 317 umfasst den Gegenstand von Beispiel 316, wobei das Verhaltensmodell, das dem nicht-autonomen Fahrzeug entspricht, weiterhin auf dem Konsens-Verhaltensmodell basiert.
• Beispiel 318 umfasst den Gegenstand eines der Beispiele 309-317, wobei das Verfahren unter Verwendung eines stationären Rechenknotens durchgeführt wird, der einem bestimmten Straßenabschnitt entspricht, und der stationäre Rechenknoten in der Nähe des bestimmten Straßenabschnitts angeordnet ist.
• Beispiel 319 umfasst den Gegenstand von Beispiel 318, wobei das Konsensverhaltensmodell versucht, das ideale Fahrverhalten auf dem jeweiligen Straßenabschnitt zu beschreiben.
• Beispiel 320 ist ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 309-319.
• Beispiel 321 umfasst den Gegenstand von Beispiel 320, wobei die Mittel ein computerlesbares Medium zum Speichern von Anweisungen umfassen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, mindestens einen Teil des Verfahrens eines der Beispiele 309-319 durchzuführen.
• Beispiel 322 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen zum: Teilnehmen an einer ersten Konsensverhandlung mit einer ersten Mehrzahl von Fahrzeugen, wobei Verhaltensmodelle von mindestens einem Teil der ersten Mehrzahl von Fahrzeugen in der ersten Konsensverhandlung ausgetauscht werden, und das Teilnehmen an der ersten Konsensverhandlung das Empfangen jedes der ausgetauschten Verhaltensmodelle und das Bestimmen der Gültigkeit jedes der Verhaltensmodelle in der ersten Konsensverhandlung umfasst; Teilnehmen an einer zweiten Konsensverhandlung mit einer zweiten Mehrzahl von Fahrzeugen, wobei Verhaltensmodelle von mindestens einem Teil der zweiten Mehrzahl von Fahrzeugen in der zweiten Konsensverhandlung ausgetauscht werden und das Teilnehmen an der zweiten Konsensverhandlung das Empfangen jedes der ausgetauschten Verhaltensmodelle und das Bestimmen der Gültigkeit jedes der Verhaltensmodelle in der zweiten Konsensverhandlung umfasst; und Erzeugen eines Konsensverhaltensmodells aus den ersten und zweiten Konsensverhandlungen.
• Beispiel 323 umfasst den Gegenstand von Beispiel 322, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, das Konsens-Verhaltensmodell an eine dritte Mehrzahl von Fahrzeugen zu verteilen.
• Beispiel 324 umfasst den Gegenstand von Beispiel 323, wobei das Konsensverhaltensmodell in einer dritten Konsensverhandlung verteilt wird.
• Beispiel 325 umfasst den Gegenstand eines der Beispiele 322-324, wobei die erste und die zweite Konsensverhandlung auf einem byzantinischen Fehlertoleranz-Konsensalgorithmus beruhen.
• Beispiel 326 umfasst den Gegenstand eines der Beispiele 322-325, wobei die Verhaltensmodelle auf neuronalen Netzen basierende Modelle umfassen.
• Beispiel 327 umfasst den Gegenstand eines der Beispiele 322-326, wobei mindestens eines der ersten oder zweiten Mehrzahl von Fahrzeugen ein nicht-autonomes Fahrzeug mit einem menschlichen Fahrer umfasst.
• Beispiel 328 umfasst den Gegenstand von Beispiel 327, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, ein Verhaltensmodell zu bestimmen, das dem nicht-autonomen Fahrzeug entspricht.
• Beispiel 329 umfasst den Gegenstand von Beispiel 328, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, Sensordaten an einem oder mehreren lokalen Sensoren zu erzeugen, um eine Mehrzahl von Verhaltensweisen eines oder mehrerer nicht-autonomer Fahrzeuge zu beobachten, wobei das dem nicht-autonomen Fahrzeug entsprechende Verhaltensmodell auf den Sensordaten basiert.
• Beispiel 330 umfasst den Gegenstand von Beispiel 329, wobei das dem nicht-autonomen Fahrzeug entsprechende Verhaltensmodell weiterhin auf dem Konsens-Verhaltensmodell basiert.
• Beispiel 331 umfasst den Gegenstand eines der Beispiele 322-330, wobei das Speichermedium unter Verwendung eines stationären Rechenknotens ausgeführt wird, der einem bestimmten Straßenabschnitt entspricht, und der stationäre Rechenknoten in der Nähe des bestimmten Straßenabschnitts angeordnet ist.
• Beispiel 332 umfasst den Gegenstand von Beispiel 331, wobei das Konsensverhaltensmodell versucht, das ideale Fahrverhalten auf dem jeweiligen Straßenabschnitt zu beschreiben.
• Beispiel 33 ist ein Verfahren, das Folgendes umfasst: Empfangen von HD-Kartendaten von einem Server; Empfangen von Sensordaten von einer mit einem autonomen Fahrzeug gekoppelten Sensorvorrichtung; Berechnen eines Vertrauenswertes für die Sensordaten auf der Grundlage von Informationen, die mit der Sammlung der Sensordaten verbunden sind; Berechnen eines Delta-Wertes auf der Grundlage eines Vergleichs der Sensordaten und von Informationen in der HD-Karte, die einem Standort des autonomen Fahrzeugs entsprechen, als die Sensordaten erhalten wurden; Bestimmen, auf der Grundlage des Vertrauenswertes und des Delta-Wertes, ob die Sensordaten zur Aktualisierung der HD-Karte an den Server veröffentlicht werden sollen.
• Beispiel 334 schließt den Gegenstand von Beispiel 333 ein, ferner die Veröffentlichung der Sensordaten an den Server ansprechend auf die Feststellung, dass der Konfidenzwert über einem ersten Schwellenwert liegt und der Delta-Wert über einem zweiten Schwellenwert liegt.
• Beispiel 335 umfasst den Gegenstand von Beispiel 333, wobei die mit der Erfassung der Sensordaten verbundenen Informationen eine oder mehrere der folgenden Informationen umfassen: Wetterdaten zum Zeitpunkt der Datenerfassung, Informationen zur Konfiguration des Sensorgeräts, Informationen zum Betrieb des Sensorgeräts, lokale Sensorbestätigungsdaten oder Informationen zum Authentifizierungsstatus des Sensorgeräts.
• Beispiel 336 umfasst den Gegenstand eines der Beispiele 333-335, wobei die Sensordaten mit einem pseudo-anonymen digitalen Zertifikat signiert werden.
• Beispiel 337 umfasst den Gegenstand von Beispiel 336, wobei das pseudoanonyme digitale Zertifikat auf einem V2X-Protokoll basiert.
• Beispiel 338 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 333-337.
• Beispiel 339 ist ein Produkt, das ein oder mehrere greifbare, computerlesbare, nicht-übertragbare Speichermedien umfasst, die computerausführbare Anweisungen umfassen, die, wenn sie von mindestens einem Computerprozessor ausgeführt werden, den mindestens einen Computerprozessor in die Lage versetzen, Operationen der Verfahren der Beispiele 333-337 zu implementieren.
• Beispiel 340 ist ein Verfahren, das Folgendes umfasst: Empfangen von Sensordaten von einem autonomen Fahrzeug, wobei die Sensordaten einen Vertrauenswert umfassen, der ein Vertrauensniveau in die Sensordaten anzeigt; Bestimmen, ob dem autonomen Fahrzeug vertraut wird, zumindest teilweise auf der Grundlage eines Vertrauenswertes, der dem autonomen Fahrzeug zugeordnet ist, wobei der Vertrauenswert zumindest teilweise auf dem Vertrauenswert und einem oder mehreren anderen Vertrauenswerten für Sensordaten basiert, die zuvor von dem autonomen Fahrzeug empfangen wurden; und Aktualisieren einer HD-Karte unter Verwendung der Sensordaten ansprechend auf eine Bestimmung, dass dem autonomen Fahrzeug vertraut wird.
• Beispiel 341 umfasst den Gegenstand von Beispiel 340, wobei ferner bestimmt wird, ob der Konfidenzwert über einem Schwellenwert liegt, wobei die Aktualisierung der HD-Karte ferner in Reaktion auf den Konfidenzwert erfolgt, der über dem Schwellenwert liegt.
• Beispiel 342 umfasst den Gegenstand von Beispiel 340, wobei die Vertrauensbewertung weiterhin darauf basiert, ob die Sensordaten von dem autonomen Fahrzeug unter Verwendung eines pseudo-anonymen digitalen Zertifikats signiert sind.
• Beispiel 343 umfasst den Gegenstand von Beispiel 340, wobei die Bestimmung, ob dem autonomen Fahrzeug vertraut wird, ferner darauf basiert, ob das autonome Fahrzeug auf einer schwarzen Liste steht.
• Beispiel 344 umfasst den Gegenstand von Beispiel 340, wobei die Bestimmung, ob das autonome Fahrzeug vertrauenswürdig ist, weiterhin auf einer Korrelation der Sensordaten mit Sensordaten von anderen autonomen Fahrzeugen in der Nähe des autonomen Fahrzeugs basiert.
• Beispiel 345 schließt den Gegenstand von Beispiel 340 ein, einschließlich des Aktualisierens der Vertrauensbewertung für das autonome Fahrzeug basierend auf der Vertrauensbewertung.
• Beispiel 346 schließt den Gegenstand von Beispiel 345 ein, wobei das Aktualisieren des Vertrauenswertes einen oder mehrere der folgenden Schritte umfasst: Erhöhen des Vertrauenswertes in Reaktion darauf, dass der Vertrauenswert über einem ersten Schwellenwert liegt, und Verringern des Vertrauenswertes in Reaktion darauf, dass der Vertrauenswert unter einem zweiten Schwellenwert liegt.
• Beispiel 347 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 340-346.
• Beispiel 348 ist ein Produkt, das ein oder mehrere greifbare, computerlesbare, nicht-übertragbare Speichermedien umfasst, die computerausführbare Anweisungen umfassen, die, wenn sie von mindestens einem Computerprozessor ausgeführt werden, den mindestens einen Computerprozessor in die Lage versetzen, Operationen der Verfahren der Beispiele 340-346 zu implementieren.
• Beispiel 349 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun empfangen von HD-Kartendaten von einem Server; Empfangen von Sensordaten von einem Sensorgerät, das mit einem autonomen Fahrzeug gekoppelt ist; Berechnen eines Vertrauenswertes für die Sensordaten auf der Grundlage von Informationen, die mit der Sammlung der Sensordaten verbunden sind; Berechnen eines Delta-Wertes auf der Grundlage eines Vergleichs der Sensordaten und von Informationen in der HD-Karte, die einem Standort des autonomen Fahrzeugs entsprechen, als die Sensordaten erhalten wurden; Bestimmen, auf der Grundlage des Vertrauenswertes und des Delta-Wertes, ob die Sensordaten an den Server zur Aktualisierung der HD-Karte veröffentlicht werden sollen.
• Beispiel 350 umfasst den Gegenstand von Beispiel 349, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Sensordaten ansprechend auf die Feststellung, dass der Konfidenzwert über einem ersten Schwellenwert und der Deltawert über einem zweiten Schwellenwert liegt, an den Server zu veröffentlichen.
• Beispiel 351 umfasst den Gegenstand von Beispiel 349, wobei die mit der Erfassung der Sensordaten verbundenen Informationen eine oder mehrere der folgenden Informationen umfassen: Wetterdaten zum Zeitpunkt der Datenerfassung, Informationen über die Konfiguration des Sensorgeräts, Informationen über den Betrieb des Sensorgeräts, lokale Sensorbestätigungsdaten oder Informationen über den Authentifizierungsstatus des Sensorgeräts.
• Beispiel 352 umfasst den Gegenstand eines der Beispiele 349 bis 351, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Sensordaten mit einem pseudo-anonymen digitalen Zertifikat zu signieren.
• Beispiel 353 umfasst den Gegenstand von Beispiel 352, wobei das pseudoanonyme digitale Zertifikat auf einem V2X-Protokoll basiert.
• Beispiel 354 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun empfangen von Sensordaten von einem autonomen Fahrzeug, wobei die Sensordaten einen Vertrauenswert umfassen, der ein Vertrauensniveau in die Sensordaten anzeigt; Bestimmen, ob dem autonomen Fahrzeug vertraut wird, zumindest teilweise auf der Grundlage eines Vertrauenswertes, der dem autonomen Fahrzeug zugeordnet ist, wobei der Vertrauenswert zumindest teilweise auf dem Vertrauenswert und einem oder mehreren anderen Vertrauenswerten für Sensordaten basiert, die zuvor von dem autonomen Fahrzeug empfangen wurden; und Aktualisieren einer HD-Karte unter Verwendung der Sensordaten ansprechend auf eine Bestimmung, dass dem autonomen Fahrzeug vertraut wird.
• Beispiel 355 schließt den Gegenstand von Beispiel 354 ein, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, zu bestimmen, ob der Vertrauenswert über einem Schwellenwert liegt, wobei das Aktualisieren der HD-Karte ferner in Reaktion auf den Vertrauenswert erfolgt, der über dem Schwellenwert liegt.
• Beispiel 356 umfasst den Gegenstand von Beispiel 354, wobei die Vertrauensbewertung ferner darauf basiert, ob die Sensordaten von dem autonomen Fahrzeug unter Verwendung eines pseudo-anonymen digitalen Zertifikats signiert wurden.
• Beispiel 357 umfasst den Gegenstand von Beispiel 354, wobei die Bestimmung, ob dem autonomen Fahrzeug vertraut wird, ferner darauf basiert, ob das autonome Fahrzeug auf einer schwarzen Liste steht.
• Beispiel 358 umfasst den Gegenstand von Beispiel 354, wobei die Bestimmung, ob das autonome Fahrzeug vertrauenswürdig ist, weiterhin auf einer Korrelation der Sensordaten mit Sensordaten von anderen autonomen Fahrzeugen in der Nähe des autonomen Fahrzeugs basiert.
• Beispiel 359 umfasst den Gegenstand von Beispiel 354, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Vertrauensbewertung für das autonome Fahrzeug auf der Grundlage der Vertrauensbewertung zu aktualisieren.
• Beispiel 360 umfasst den Gegenstand von Beispiel 359, wobei das Aktualisieren des Vertrauenswertes einen oder mehrere der folgenden Schritte umfasst: Erhöhen des Vertrauenswertes als Reaktion darauf, dass der Vertrauenswert oberhalb eines ersten Schwellenwertes liegt, und Verringern des Vertrauenswertes als Reaktion darauf, dass der Vertrauenswert unterhalb eines zweiten Schwellenwertes liegt.
• Beispiel 361 ist ein Verfahren, das Folgendes umfasst: Empfangen von Sensordaten von einem autonomen Fahrzeug; Erhalten von Geolokalisierungsinformationen aus den Sensordaten, wobei die Geolokalisierungsinformationen einen Standort des autonomen Fahrzeugs angeben; Berechnen einer Gütebewertung für die Sensordaten auf der Grundlage von mindestens den Geolokalisierungsinformationen; Vergleichen der Gütebewertung mit einem Schwellenwert; und Speichern der Sensordaten in einer Datenbank als Reaktion darauf, dass die Gütebewertung über einem Schwellenwert liegt.
• Beispiel 362 umfasst den Gegenstand von Beispiel 361, wobei: das Verfahren ferner die Berechnung einer Standortbewertung auf der Grundlage der Geolokalisierungsinformationen umfasst; und die Berechnung der Gütebewertung auf der Standortbewertung und einer oder mehreren anderen Bewertungen basiert, die mit den Sensordaten verbunden sind.
• Beispiel 363 umfasst den Gegenstand von Beispiel 362, wobei das Berechnen der Standortbewertung Folgendes umfasst: Zugreifen auf eine Heatmap, die mit den Geolokalisierungsinformationen verknüpft ist, wobei die Heatmap eine Menge an Sensordaten anzeigt, die an einer Mehrzahl von Standorten gesammelt wurden; Erhalten eines Wertes aus der Heatmap, die mit dem durch die Geolokalisierungsinformationen angezeigten Standort verknüpft ist; und Verwenden des Wertes aus der Heatmap zum Berechnen der Standortbewertung.
• Beispiel 364 umfasst den Gegenstand eines der Beispiele 362-363, wobei die Gütebewertung eine gewichtete Summe der Standortbewertung und der einen oder mehreren anderen Bewertungen ist, die mit den Sensordaten verbunden sind.
• Beispiel 365 umfasst den Gegenstand eines der Beispiele 362-364, wobei die Standortbewertung eine gewichtete Summe der Geolokalisierungsinformationen und einer oder mehrerer zusätzlicher Kategorien von Umgebungsinformationen ist, wobei jede Kategorie von Umgebungsinformationen einen Zustand eines Standorts des autonomen Fahrzeugs angibt.
• Beispiel 366 umfasst den Gegenstand von Beispiel 365, wobei die eine oder mehrere zusätzliche Kategorien von Umgebungsinformationen eine oder mehrere Höheninformationen, die eine Höhe des autonomen Fahrzeugs angeben, Temperaturinformationen, die eine Temperatur außerhalb des autonomen Fahrzeugs angeben, Wetterinformationen, die Wetterbedingungen in der Nähe des autonomen Fahrzeugs angeben, und Geländeinformationen, die Merkmale des von dem autonomen Fahrzeug durchfahrenen Gebiets angeben, umfassen.
• Beispiel 367 umfasst den Gegenstand von Beispiel 365, wobei das Berechnen der Standortbewertung für jede der einen oder mehreren zusätzlichen Kategorien von Umgebungsinformationen Folgendes umfasst: Zugreifen auf eine Heatmap, die mit der zusätzlichen Kategorie verbunden ist, wobei die Heatmap eine Menge an Sensordaten anzeigt, die an einer Mehrzahl von Orten gesammelt wurden; Erhalten eines Wertes aus der Heatmap, die mit dem durch Geolokalisierungsinformationen angezeigten Ort verbunden ist; und Verwenden des erhaltenen Wertes zum Berechnen der Standortbewertung
• Beispiel 368 umfasst den Gegenstand eines der Beispiele 362-367, wobei die eine oder mehreren anderen Bewertungen eine oder mehrere der folgenden Bewertungen umfassen: eine Rauschbewertung für die Sensordaten und eine Objektdiversitätsbewertung für die Sensordaten.
• Beispiel 369 umfasst den Gegenstand eines der Beispiele 361-368, wobei das Erhalten der Geolokalisierungsinformationen aus den Sensordaten eines oder mehrere der folgenden Elemente umfasst: Erhalten von geografischen Koordinateninformationen in den Sensordaten und Analysieren von Metadaten der Sensordaten, um die Geolokalisierungsinformationen zu erhalten.
• Beispiel 370 umfasst den Gegenstand von einem der Beispiele 361-369, ferner die Berechnung eines Vehicle Dependability Score, der dem autonomen Fahrzeug zugeordnet ist, basierend auf dem Gütewert.
• Beispiel 271 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 361-370.
• Beispiel 372 ist ein Produkt, das ein oder mehrere greifbare, computerlesbare, nicht-übertragbare Speichermedien umfasst, die computerausführbare Anweisungen umfassen, die, wenn sie von mindestens einem Computerprozessor ausgeführt werden, den mindestens einen Computerprozessor in die Lage versetzen, Operationen der Verfahren der Beispiele 361-370 zu implementieren.
• Beispiel 373 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: Sensordaten von einem autonomen Fahrzeug zu empfangen; Geolokalisierungsinformationen von den Sensordaten zu erhalten, wobei die Geolokalisierungsinformationen einen Standort des autonomen Fahrzeugs anzeigen; eine Gütebewertung für die Sensordaten zumindest auf der Grundlage der Geolokalisierungsinformationen zu berechnen; die Gütebewertung mit einem Schwellenwert zu vergleichen; und die Sensordaten in einer Datenbank als Reaktion darauf zu speichern, dass die Gütebewertung über einem Schwellenwert liegt.
• Beispiel 374 umfasst den Gegenstand von Beispiel 373, wobei: das Speichermedium ferner die Berechnung einer Standortbewertung auf der Grundlage der Geolokalisierungsinformationen umfasst; und die Berechnung der Gütebewertung auf der Standortbewertung und einer oder mehreren anderen Bewertungen, die mit den Sensordaten verbunden sind, basiert.
• Beispiel 375 umfasst den Gegenstand von Beispiel 374, wobei das Berechnen der Standortbewertung Folgendes umfasst: Zugreifen auf eine Heatmap, die mit den Geolokalisierungsinformationen verknüpft ist, wobei die Heatmap eine Menge an Sensordaten anzeigt, die an einer Mehrzahl von Standorten gesammelt wurden; Erhalten eines Wertes aus der Heatmap, die mit dem durch die Geolokalisierungsinformationen angezeigten Standort verknüpft ist; und Verwenden des Wertes aus der Heatmap zum Berechnen der Standortbewertung.
• Beispiel 376 umfasst den Gegenstand eines der Beispiele 374-375, wobei die Gütebewertung eine gewichtete Summe der Standortbewertung und der einen oder mehreren anderen Bewertungen ist, die mit den Sensordaten verbunden sind.
• Beispiel 377 umfasst den Gegenstand eines der Beispiele 374-376, wobei die Standortbewertung eine gewichtete Summe der Geolokalisierungsinformationen und einer oder mehrerer zusätzlicher Kategorien von Umgebungsinformationen ist, wobei jede Kategorie von Umgebungsinformationen einen Zustand eines Standorts des autonomen Fahrzeugs angibt.
• Beispiel 378 umfasst den Gegenstand von Beispiel 377, wobei die eine oder mehrere zusätzliche Kategorien von Umgebungsinformationen eine oder mehrere Höheninformationen, die eine Höhe des autonomen Fahrzeugs angeben, Temperaturinformationen, die eine Temperatur außerhalb des autonomen Fahrzeugs angeben, Wetterinformationen, die Wetterbedingungen in der Nähe des autonomen Fahrzeugs angeben, und Geländeinformationen, die Merkmale des von dem autonomen Fahrzeug durchfahrenen Gebiets angeben, umfassen.
• Beispiel 379 umfasst den Gegenstand von Beispiel 378, wobei das Berechnen der Standortbewertung für jede der einen oder mehreren zusätzlichen Kategorien von Umgebungsinformationen Folgendes umfasst: Zugreifen auf eine Heatmap, die mit der zusätzlichen Kategorie verbunden ist, wobei die Heatmap eine Menge von Sensordaten anzeigt, die an einer Mehrzahl von Standorten gesammelt wurden; Erhalten eines Wertes aus der Heatmap, die mit dem durch Geolokalisierungsinformationen angezeigten Standort verbunden ist; und Verwenden des erhaltenen Wertes zum Berechnen der Standortbewertung.
• Beispiel 380 umfasst den Gegenstand eines der Beispiele 374-379, wobei die eine oder mehreren anderen Bewertungen eine oder mehrere der folgenden Bewertungen umfassen: eine Rauschbewertung für die Sensordaten und eine Objektdiversitätsbewertung für die Sensordaten.
• Beispiel 381 umfasst den Gegenstand eines der Beispiele 373-380, wobei das Erhalten der Geolokalisierungsinformationen aus den Sensordaten eines oder mehrere der folgenden Elemente umfasst: Erhalten von geografischen Koordinateninformationen in den Sensordaten und Analysieren von Metadaten der Sensordaten, um die Geolokalisierungsinformationen zu erhalten.
• Beispiel 382 umfasst den Gegenstand eines der Beispiele 373-381, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, einen Vehicle Dependability Score zu berechnen, die dem autonomen Fahrzeug auf der Grundlage der Gütebewertung zugeordnet ist.
• Beispiel 383 ist ein Verfahren, das Folgendes umfasst: Empfangen von Sensordaten von einer Mehrzahl von Sensoren, die mit einem autonomen Fahrzeug gekoppelt sind; Erkennen eines irregulären Verhaltens, das von einem bestimmten Fahrzeug, das nicht das autonome Fahrzeug ist, ausgeführt wird, auf der Grundlage der Sensordaten; Erzeugen einer Kennung für das bestimmte Fahrzeug; und Einleiten einer dynamischen Verhaltenspolitik des autonomen Fahrzeugs ansprechend auf das Erkennen des irregulären Verhaltens, das von dem bestimmten Fahrzeug eine Anzahl von Malen ausgeführt wird, die größer als eine Schwellenzahl ist.
• Beispiel 384 umfasst den Gegenstand von Beispiel 383, wobei das Erkennen des irregulären Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, umfasst: Vergleichen eines beobachteten Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, mit einem Sicherheitsmodell des autonomen Fahrzeugs; und Bestimmen, basierend auf dem Vergleich, dass das beobachtete Verhalten das Sicherheitsmodell des autonomen Fahrzeugs verletzt.
• Beispiel 385 umfasst den Gegenstand von Beispiel 383, wobei das Erkennen des unregelmäßigen Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, Folgendes umfasst: Vergleichen eines beobachteten Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, mit beobachteten Verhaltensweisen, die von anderen Fahrzeugen ausgeführt werden; und Bestimmen, basierend auf dem Vergleich, dass das beobachtete Verhalten, das von dem bestimmten Fahrzeug ausgeführt wird, von den beobachteten Verhaltensweisen abweicht, die von den anderen Fahrzeugen ausgeführt werden.
• Beispiel 386 umfasst den Gegenstand von Beispiel 383, wobei das Erkennen des unregelmäßigen Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, Folgendes umfasst: Vergleichen eines beobachteten Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, mit beobachteten Verhaltensweisen, die von anderen Fahrzeugen ausgeführt werden; und Bestimmen, basierend auf dem Vergleich, dass die beobachteten Verhaltensweisen, die von den anderen Fahrzeugen ausgeführt werden, ansprechend auf das beobachtete Verhalten, das von dem bestimmten Fahrzeug ausgeführt wird, ausgeführt werden.
• Beispiel 387 umfasst den Gegenstand eines der Beispiele 383-386, wobei die Erkennung des unregelmäßigen Verhaltens auf Audio- und visuellen Kontextinformationen in den Sensordaten basiert.
• Beispiel 388 umfasst den Gegenstand von einem der Beispiele 383-387, wobei das Erzeugen eines Identifikators für das bestimmte Fahrzeug umfasst: erhalten von Werten für die jeweiligen Merkmale des bestimmten Fahrzeugs; und Anwenden eines kryptographischen Hashes auf eine Kombination der Werte, um die Kennung zu erhalten.
• Beispiel 389 umfasst den Gegenstand von Beispiel 388, wobei die Werte durch Extraktion repräsentativer Merkmale aus einem Deep-Learning-Modell gewonnen werden, das vom autonomen Fahrzeug zur Erkennung anderer Fahrzeuge verwendet wird.
• Beispiel 390 umfasst den Gegenstand eines der Beispiele 383-389, einschließlich der Verfolgung der Häufigkeit der Erkennung des unregelmäßigen Verhaltens durch andere Fahrzeuge.
• Beispiel 391 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 383-390.
• Beispiel 392 ist ein Produkt, das ein oder mehrere greifbare, computerlesbare, nicht-übertragbare Speichermedien umfasst, die computerausführbare Anweisungen umfassen, die, wenn sie von mindestens einem Computerprozessor ausgeführt werden, den mindestens einen Computerprozessor in die Lage versetzen, Operationen eines oder mehrerer der Verfahren der Beispiele 383-390 zu implementieren.
• Beispiel 393 ist ein Verfahren, umfassend: empfangen von Verfolgungsdaten für irreguläres Verhalten von mehreren autonomen Fahrzeugen, wobei die Verfolgungsdaten für irreguläres Verhalten Einträge umfassen, die eine Fahrzeugkennung, ein zugehöriges irreguläres Verhalten, das als von einem der Fahrzeugkennung zugeordneten Fahrzeug ausgeführt beobachtet wurde, und Kontextdaten, die einen Kontext anzeigen, in dem das irreguläre Verhalten von den autonomen Fahrzeugen erfasst wurde, umfassen; Identifizieren einer oder mehrerer Sequenzen von irregulärem Verhalten, das von einem oder mehreren Fahrzeugen ausgeführt wurde; Identifizieren eines kontextbezogenen Verhaltensmusters auf der Grundlage der identifizierten Sequenzen und der Verfolgungsdaten für irreguläres Verhalten; und Modifizieren einer Verhaltensrichtlinie für ein oder mehrere autonome Fahrzeuge auf der Grundlage des identifizierten kontextbezogenen Verhaltensmusters.
• Beispiel 394 umfasst den Gegenstand von Beispiel 393, wobei das Identifizieren eines kontextbezogenen Verhaltensmusters Folgendes umfasst: Erzeugen eines kontextbezogenen Graphen, der einen ersten Satz von Knoten, die identifizierte Sequenzen anzeigen, und einen zweiten Satz von Knoten, die kontextbezogene Daten anzeigen, umfasst, wobei die Kanten des kontextbezogenen Graphen eine Häufigkeit von Assoziationen zwischen den Knoten anzeigen; und Verwenden des kontextbezogenen Graphen zum Identifizieren des kontextbezogenen Verhaltensmusters.
• Beispiel 395 umfasst den Gegenstand von Beispiel 393, wobei die Änderung der Verhaltensrichtlinie für das eine oder die mehreren autonomen Fahrzeuge auf der Erkennung basiert, dass sich das eine oder die mehreren autonomen Fahrzeuge in einem bestimmten Kontext befinden, der mit dem identifizierten kontextbezogenen Verhaltensmuster verbunden ist.
• Beispiel 396 umfasst den Gegenstand eines der Beispiele 393 bis 395, wobei die Kontextdaten eine oder mehrere der folgenden Informationen umfassen: Trajektorieninformationen für die Fahrzeuge, die die unregelmäßigen Verhaltensweisen ausführen, Fahrzeugattribute für die Fahrzeuge, die die unregelmäßigen Verhaltensweisen ausführen, Fahrerattribute für die Fahrzeuge, die die unregelmäßigen Verhaltensweisen ausführen, einen geografischen Standort der Fahrzeuge, die die unregelmäßigen Verhaltensweisen ausführen, Wetterbedingungen in der Umgebung der Fahrzeuge, die die unregelmäßigen Verhaltensweisen ausführen, und Verkehrsinformationen, die die Verkehrsbedingungen in der Umgebung der Fahrzeuge anzeigen, die die unregelmäßigen Verhaltensweisen ausführen.
• Beispiel 397 umfasst den Gegenstand eines der Beispiele 393-396, wobei die eine oder mehrere Sequenzen unregelmäßigen Verhaltens auf der Grundlage der längsten gemeinsamen Folgen (Longest Common Subsequences, LCS) identifiziert werden.
• Beispiel 398 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 393-396.
• Beispiel 399 ist ein Produkt, das ein oder mehrere greifbare, computerlesbare, nicht-übertragbare Speichermedien umfasst, die computerausführbare Anweisungen umfassen, die, wenn sie von mindestens einem Computerprozessor ausgeführt werden, den mindestens einen Computerprozessor in die Lage versetzen, Operationen eines oder mehrerer der Verfahren der Beispiele 393-396 zu implementieren.
• Beispiel 400 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen,: empfangen von Sensordaten von einer Mehrzahl von Sensoren, die mit einem autonomen Fahrzeug gekoppelt sind; Erkennen eines irregulären Verhaltens, das von einem bestimmten Fahrzeug, das nicht das autonome Fahrzeug ist, ausgeführt wird, basierend auf den Sensordaten; Erzeugen eines Identifizierers für das bestimmte Fahrzeug; und Initiieren einer dynamischen Verhaltensrichtlinie des autonomen Fahrzeugs ansprechend auf das Erkennen des irregulären Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, und zwar eine Anzahl von Malen, die größer ist als eine Schwellenzahl.
• Beispiel 401 umfasst den Gegenstand von Beispiel 400, wobei das Erkennen des irregulären Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, umfasst: Vergleichen eines beobachteten Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, mit einem Sicherheitsmodell des autonomen Fahrzeugs; und Bestimmen, basierend auf dem Vergleich, dass das beobachtete Verhalten das Sicherheitsmodell des autonomen Fahrzeugs verletzt.
• Beispiel 402 umfasst den Gegenstand von Beispiel 400, wobei das Erkennen des unregelmäßigen Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, Folgendes umfasst: Vergleichen eines beobachteten Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, mit beobachteten Verhaltensweisen, die von anderen Fahrzeugen ausgeführt werden; und Bestimmen, basierend auf dem Vergleich, dass das beobachtete Verhalten, das von dem bestimmten Fahrzeug ausgeführt wird, von den beobachteten Verhaltensweisen, die von den anderen Fahrzeugen ausgeführt werden, abweicht.
• Beispiel 403 umfasst den Gegenstand von Beispiel 400, wobei das Erkennen des unregelmäßigen Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, Folgendes umfasst: Vergleichen eines beobachteten Verhaltens, das von dem bestimmten Fahrzeug ausgeführt wird, mit beobachteten Verhaltensweisen, die von anderen Fahrzeugen ausgeführt werden; und Bestimmen, basierend auf dem Vergleich, dass die beobachteten Verhaltensweisen, die von den anderen Fahrzeugen ausgeführt werden, ansprechend auf das beobachtete Verhalten, das von dem bestimmten Fahrzeug ausgeführt wird, ausgeführt werden.
• Beispiel 404 umfasst den Gegenstand eines der Beispiele 400-403, wobei die Erkennung des unregelmäßigen Verhaltens auf Audio- und visuellen Kontextinformationen in den Sensordaten basiert.
• Beispiel 405 umfasst den Gegenstand eines der Beispiele 400-404, wobei das Erzeugen eines Identifikators für das bestimmte Fahrzeug Folgendes umfasst: Erhalten von Werten für entsprechende Merkmale des bestimmten Fahrzeugs; und Anwenden einer kryptographischen Funktion auf eine Kombination der Werte, um den Identifikator zu erhalten.
• Beispiel 406 umfasst den Gegenstand von Beispiel 405, wobei die Werte durch Extraktion repräsentativer Merkmale aus einem Deep-Learning-Modell gewonnen werden, das vom autonomen Fahrzeug zur Erkennung anderer Fahrzeuge verwendet wird.
• Beispiel 407 umfasst den Gegenstand eines der Beispiele 400-406, einschließlich der Verfolgung der Häufigkeit der Erkennung des unregelmäßigen Verhaltens durch andere Fahrzeuge.
• Beispiel 408 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen,: empfangen von Verfolgungsdaten für irreguläres Verhalten von mehreren autonomen Fahrzeugen, wobei die Verfolgungsdaten für irreguläres Verhalten Einträge umfassen, die eine Fahrzeugkennung, ein zugehöriges irreguläres Verhalten, das als von einem der Fahrzeugkennung zugeordneten Fahrzeug ausgeführt beobachtet wurde, und Kontextdaten, die einen Kontext anzeigen, in dem das irreguläre Verhalten von den autonomen Fahrzeugen erkannt wurde, umfassen; Identifizieren einer oder mehrerer Sequenzen von irregulärem Verhalten, das von einem oder mehreren Fahrzeugen ausgeführt wurde; Identifizieren eines kontextbezogenen Verhaltensmusters auf der Grundlage der identifizierten Sequenzen und der Verfolgungsdaten für irreguläres Verhalten; und Modifizieren einer Verhaltensrichtlinie für ein oder mehrere autonome Fahrzeuge auf der Grundlage des identifizierten kontextbezogenen Verhaltensmusters.
• Beispiel 409 umfasst den Gegenstand von Beispiel 408, wobei das Identifizieren eines kontextbezogenen Verhaltensmusters Folgendes umfasst: Erzeugen eines kontextbezogenen Graphen, der einen ersten Satz von Knoten, die identifizierte Sequenzen anzeigen, und einen zweiten Satz von Knoten, die kontextbezogene Daten anzeigen, umfasst, wobei die Kanten des kontextbezogenen Graphen eine Häufigkeit von Assoziationen zwischen den Knoten anzeigen; und Verwenden des kontextbezogenen Graphen zum Identifizieren des kontextbezogenen Verhaltensmusters.
• Beispiel 410 umfasst den Gegenstand von Beispiel 408, wobei das Modifizieren der Verhaltensrichtlinie für das eine oder die mehreren autonomen Fahrzeuge auf dem Erkennen basiert, dass sich das eine oder die mehreren autonomen Fahrzeuge in einem bestimmten Kontext befinden, der mit dem identifizierten kontextbezogenen Verhaltensmuster verbunden ist.
• Beispiel 411 umfasst den Gegenstand eines der Beispiele 408-410, wobei die Kontextdaten eine oder mehrere Trajektorieninformationen für die Fahrzeuge, die die irregulären Verhaltensweisen ausführen, Fahrzeugattribute für die Fahrzeuge, die die irregulären Verhaltensweisen ausführen, Fahrerattribute für die Fahrzeuge, die die irregulären Verhaltensweisen ausführen, einen geographischen Standort der Fahrzeuge, die die irregulären Verhaltensweisen ausführen, Wetterbedingungen um die Fahrzeuge, die die irregulären Verhaltensweisen ausführen, und Verkehrsinformationen, die die Verkehrsbedingungen um die Fahrzeuge, die die irregulären Verhaltensweisen ausführen, anzeigen, umfassen.
• Beispiel 412 umfasst den Gegenstand eines der Beispiele 408-411, wobei die eine oder mehrere Sequenzen unregelmäßigen Verhaltens auf der Grundlage der längsten gemeinsamen Folge (Longest Common Subsequences, LCS) identifiziert werden.
• Beispiel 413 ist ein Verfahren, das Folgendes umfasst: empfangen einer Klassifizierung einer ersten Bewegungsänderung für ein Fahrzeug von einem Fahrzeugverhaltensmodell; Empfangen einer Vorhersage einer Wahrscheinlichkeit, dass die erste Bewegungsänderung für das Fahrzeug während eines gegebenen Zeitintervalls auftritt, von einem Regressionsmodell; Vergleichen der Klassifizierung von dem Fahrzeugverhaltensmodell mit der Vorhersage von dem Regressionsmodell; Bestimmen, dass die erste Bewegungsänderung für das Fahrzeug ein Fehler ist, zumindest teilweise basierend auf dem Vergleich; und Senden eines ersten Steuersignals, um die erste Bewegungsänderung für das Fahrzeug zu beeinflussen, basierend auf der Bestimmung, dass die erste Bewegungsänderung für das Fahrzeug ein Fehler ist.
• Beispiel 414 umfasst den Gegenstand von Beispiel 413, ferner: Empfangen eines ersten Steuerereignisses am Fahrzeugverhaltensmodell, das die erste Bewegungsänderung für das Fahrzeug anzeigt; und Erzeugen der Klassifizierung der ersten Bewegungsänderung zumindest teilweise auf der Grundlage des ersten Steuerereignisses und von Daten von einem oder mehreren Sensoren im Fahrzeug.
• Beispiel 415 schließt den Gegenstand von Beispiel 413 ein und umfasst ferner: Empfangen eines ersten Steuerereignisses am Regressionsmodell; Erhalten einer oder mehrerer Variablen, die aktuelle Bedingungen anzeigen; und Erzeugen der Vorhersage zumindest teilweise auf der Grundlage des ersten Steuerereignisses und der einen oder mehreren Variablen, die die aktuellen Bedingungen anzeigen.
• Beispiel 416 umfasst den Gegenstand von Beispiel 415, wobei die aktuellen Bedingungen mindestens eine Umgebungsbedingung umfassen.
• Beispiel 417 umfasst den Gegenstand von einem der Beispiele 415-416, wobei die aktuellen Bedingungen mindestens einen Fahrzeugzustand umfassen.
• Beispiel 418 umfasst den Gegenstand eines der Beispiele 415-417, wobei mindestens eine der einen oder mehreren Variablen von einer oder mehreren entfernten Quellen erhalten wird.
• Beispiel 419 umfasst den Gegenstand eines der Beispiele 414-418, wobei das erste Steuerereignis mit einem Bremsaktuator, einem Lenkaktuator oder einem Drosselaktuator verbunden ist.
• Beispiel 420 umfasst den Gegenstand eines der Beispiele 413-419, wobei das Fahrzeugverhaltensmodell ein Hidden Markov Model (HMM)-Algorithmus ist.
• Beispiel 421 umfasst den Gegenstand von einem der Beispiele 413-420, wobei das Regressionsmodell ein Erwartungsmaximierungs- (EM-) Algorithmus ist.
• Beispiel 422 umfasst den Gegenstand eines der Beispiele 413-421, wobei der Fehler entweder ein böswilliger Angriff auf ein Rechensystem des Fahrzeugs oder ein Ausfall des Rechensystems des Fahrzeugs ist.
• Beispiel 423 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 413-422.
• Beispiel 424 ist ein maschinenlesbares Medium, das Anweisungen umfasst, wobei die Anweisungen, wenn sie ausgeführt werden, eine Vorrichtung realisieren oder ein Verfahren implementieren, wie es in einem der Beispiele 413-422 beschrieben wurde.
• Beispiel 425 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun von einem Fahrzeugverhaltensmodell eine Klassifizierung einer ersten Bewegungsänderung für ein Fahrzeug zu empfangen; von einem Regressionsmodell eine Vorhersage einer Wahrscheinlichkeit des Auftretens der ersten Bewegungsänderung für das Fahrzeug während eines gegebenen Zeitintervalls zu empfangen; die Klassifizierung von dem Fahrzeugverhaltensmodell mit der Vorhersage von dem Regressionsmodell zu vergleichen; zumindest teilweise auf der Grundlage des Vergleichs zu bestimmen, dass die erste Bewegungsänderung für das Fahrzeug ein Fehler ist; und ein erstes Steuersignal zu senden, um die erste Bewegungsänderung für das Fahrzeug auf der Grundlage der Bestimmung, dass die erste Bewegungsänderung für das Fahrzeug ein Fehler ist, zu beeinflussen.
• Beispiel 426 schließt den Gegenstand von Beispiel 425 ein, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: am Fahrzeugverhaltensmodell ein erstes Steuerereignis zu empfangen, das die erste Bewegungsänderung für das Fahrzeug anzeigt; und die Klassifizierung der ersten Bewegungsänderung zumindest teilweise auf der Grundlage des ersten Steuerereignisses und Daten von einem oder mehreren Sensoren im Fahrzeug zu erzeugen.
• Beispiel 427 umfasst den Gegenstand von Beispiel 425, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen: am Regressionsmodell ein erstes Steuerereignis zu empfangen; eine oder mehrere Variablen zu erhalten, die aktuelle Bedingungen anzeigen; und die Vorhersage zumindest teilweise auf der Grundlage des ersten Steuerereignisses und der einen oder mehreren Variablen zu erzeugen, die die aktuellen Bedingungen anzeigen.
• Beispiel 428 umfasst den Gegenstand von Beispiel 427, wobei die aktuellen Bedingungen mindestens eine Umgebungsbedingung umfassen.
• Beispiel 429 umfasst den Gegenstand eines der Beispiele 427-428, wobei die aktuellen Bedingungen mindestens einen Fahrzeugzustand umfassen.
• Beispiel 430 umfasst den Gegenstand eines der Beispiele 427-429, wobei mindestens eine der einen oder mehreren Variablen von einer oder mehreren entfernten Quellen erhalten wird.
• Beispiel 431 umfasst den Gegenstand eines der Beispiele 426-430, wobei das erste Steuerereignis mit einem Bremsaktuator, einem Lenkaktuator oder einem Drosselaktuator verbunden ist.
• Beispiel 432 umfasst den Gegenstand eines der Beispiele 425-431, wobei das Fahrzeugverhaltensmodell ein Hidden Markov Model (HMM) Algorithmus ist.
• Beispiel 433 umfasst den Gegenstand von einem der Beispiele 425-432, wobei das Regressionsmodell ein Erwartungsmaximierungs- (EM-) Algorithmus ist.
• Beispiel 434 umfasst den Gegenstand eines der Beispiele 425-433, wobei der Fehler entweder ein böswilliger Angriff auf ein Rechensystem des Fahrzeugs oder ein Fehler im Rechensystem des Fahrzeugs ist.
• Beispiel 435 ist ein Verfahren, das Folgendes umfasst: Identifizieren eines Beispiels eines oder mehrerer Objekte aus Daten, die von einem oder mehreren Sensoren eines Fahrzeugs erfasst wurden; Durchführen einer Kategorisierung des Beispiels durch Prüfen des Beispiels anhand einer Mehrzahl von Kategorien und Zuweisen mindestens einer Kategorie der Mehrzahl von Kategorien zu dem Beispiel; Bestimmen einer Bewertung auf der Grundlage der Kategorisierung des Beispiels; Auswählen einer Datenverarbeitungsrichtlinie für das Beispiel zumindest teilweise auf der Grundlage der Bewertung; und Verarbeiten des Beispiels auf der Grundlage der bestimmten Datenverarbeitungsrichtlinie.
• Beispiel 436 umfasst den Gegenstand von Beispiel 435, wobei eine Kategorie der Mehrzahl von Kategorien eine Kategorie ist, die eine Häufigkeit der Erfassung des einen oder der mehreren Objekte angibt.
• Beispiel 437 umfasst den Gegenstand von Beispiel 436, wobei die Erkennungshäufigkeit eine Häufigkeit der Erkennung des einen oder der mehreren Objekte innerhalb eines bestimmten Kontexts angibt, der mit der Erfassung eines oder mehrerer zugrunde liegender Sensordatenströme der Instanz verbunden ist.
• Beispiel 438 umfasst den Gegenstand eines der Beispiele 435-437, wobei eine Kategorie der Mehrzahl von Kategorien eine Kategorie ist, die einen Grad der Diversität unter mehreren erkannten Objekten der Instanz angibt.
• Beispiel 439 umfasst den Gegenstand eines der Beispiele 435-438, wobei eine Kategorie der Mehrzahl von Kategorien eine Kategorie ist, die einen Rauschpegel eines oder mehrerer zugrunde liegender Datenströme für die Instanz angibt.
• Beispiel 440 umfasst den Gegenstand eines der Beispiele 435-439 und umfasst ferner:
• Bestimmen der Bewertung auf der Grundlage der Kategorisierung der Instanz und eines Kontexts der von dem einen oder den mehreren Sensoren erfassten Daten.
• Beispiel 441 umfasst den Gegenstand eines der Beispiele 435-440, wobei die ausgewählte Datenverarbeitungsrichtlinie darin besteht, die Instanz und einen oder mehrere zugrunde liegende Sensordatenströme für die Instanz zu löschen.
• Beispiel 442 umfasst den Gegenstand eines der Beispiele 435-440, wobei die ausgewählte Datenverarbeitungsrichtlinie darin besteht, die Instanz und einen oder mehrere zugrunde liegende Sensordatenströme für die Instanz zur Verwendung beim Training eines Objekterkennungsmodells zu speichern.
• Beispiel 443 umfasst den Gegenstand eines der Beispiele 435-440, wobei die ausgewählte Datenverarbeitungsrichtlinie darin besteht, synthetische Daten zu erzeugen, die mindestens ein Bild umfassen, das demselben Objekttyp entspricht wie ein erkanntes Bild der Instanz, wobei die synthetischen Daten zum Training eines Objekterkennungsmodells verwendet werden.
• Beispiel 444 umfasst den Gegenstand eines der Beispiele 435-443, ferner das Bereitstellen von Kategorisierungsergebnissen für ein Trainingsmodell für maschinelles Lernen und das Bereitstellen von Parametern des Trainingsmodells für maschinelles Lernen für ein Rechensystem eines Fahrzeugs zur Verwendung bei der Kategorisierung von Objekten, die von dem Fahrzeug erfasst werden.
• Beispiel 445 ist ein Fahrzeug mit einem Rechensystem zur Durchführung eines oder mehrerer der Verfahren der Beispiele 435-444.
• Beispiel 446 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 435-444.
• Beispiel 447 ist ein maschinenlesbares Medium, das Anweisungen umfasst, wobei die Anweisungen, wenn sie ausgeführt werden, eine Vorrichtung realisieren oder ein Verfahren implementieren, wie in einem der Beispiele 435-444 beschrieben.
• Beispiel 448 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun eine Instanz eines oder mehrerer Objekte aus Daten zu identifizieren, die von einem oder mehreren Sensoren eines Fahrzeugs erfasst wurden; eine Kategorisierung der Instanz durchzuführen, indem die Instanz mit einer Mehrzahl von Kategorien verglichen wird und der Instanz mindestens eine Kategorie der Mehrzahl von Kategorien zugewiesen wird; eine Bewertung auf der Grundlage der Kategorisierung der Instanz zu bestimmen; eine Datenverarbeitungsrichtlinie für die Instanz zumindest teilweise auf der Grundlage der Bewertung auszuwählen; und die Instanz auf der Grundlage der bestimmten Datenverarbeitungsrichtlinie zu verarbeiten.
• Beispiel 449 umfasst den Gegenstand von Beispiel 448, wobei eine Kategorie der Mehrzahl von Kategorien eine Kategorie ist, die eine Häufigkeit der Erfassung des einen oder der mehreren Objekte angibt.
• Beispiel 450 umfasst den Gegenstand von Beispiel 449, wobei die Erkennungshäufigkeit eine Häufigkeit der Erkennung des einen oder der mehreren Objekte innerhalb eines bestimmten Kontexts angibt, der mit der Erfassung eines oder mehrerer zugrunde liegender Sensordatenströme der Instanz verbunden ist.
• Beispiel 451 umfasst den Gegenstand eines der Beispiele 448-450, wobei eine Kategorie der Mehrzahl von Kategorien eine Kategorie ist, die einen Grad an Diversität unter mehreren erkannten Objekten der Instanz anzeigt.
• Beispiel 452 umfasst den Gegenstand eines der Beispiele 448-451, wobei eine Kategorie der Mehrzahl von Kategorien eine Kategorie ist, die einen Rauschpegel eines oder mehrerer zugrunde liegender Datenströme für die Instanz angibt.
• Beispiel 453 umfasst den Gegenstand eines der Beispiele 448-452, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Bewertung auf der Grundlage der Kategorisierung der Instanz und eines Kontexts der von dem einen oder mehreren Sensoren erfassten Daten zu bestimmen.
• Beispiel 454 umfasst den Gegenstand der Beispiele 448-453, wobei die ausgewählte Datenverarbeitungsrichtlinie darin besteht, die Instanz und einen oder mehrere zugrunde liegende Sensordatenströme für die Instanz zu löschen.
• Beispiel 455 umfasst den Gegenstand eines der Beispiele 448-454, wobei die ausgewählte Datenverarbeitungsrichtlinie darin besteht, die Instanz und einen oder mehrere zugrunde liegende Sensordatenströme für die Instanz zur Verwendung beim Training eines Objekterkennungsmodells zu speichern.
• Beispiel 456 umfasst den Gegenstand eines der Beispiele 448-454, wobei die ausgewählte Datenverarbeitungsrichtlinie darin besteht, synthetische Daten zu erzeugen, die mindestens ein Bild umfassen, das demselben Objekttyp entspricht wie ein erkanntes Bild der Instanz, wobei die synthetischen Daten zum Training eines Objekterkennungsmodells verwendet werden.
• Beispiel 457 umfasst den Gegenstand eines der Beispiele 448-456, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, Kategorisierungsergebnisse an ein Trainingsmodell für maschinelles Lernen zu liefern und Parameter des Trainingsmodells für maschinelles Lernen an ein Rechensystem eines Fahrzeugs zur Verwendung bei der Kategorisierung von durch das Fahrzeug erfassten Objekten bereitzustellen.
• Beispiel 458 ist ein Verfahren, das Folgendes umfasst: Identifizieren eines Kontexts, der mit Sensordaten verknüpft ist, die von einem oder mehreren Sensoren eines Fahrzeugs erfasst wurden, wobei der Kontext eine Mehrzahl von Textschlüsselwörtern umfasst; Bestimmen, dass zusätzliche Bilddaten für den Kontext erwünscht sind; und Bereitstellen der Mehrzahl von Textschlüsselwörtern des Kontexts für einen Generator für synthetische Bilder, wobei der Generator für synthetische Bilder eine Mehrzahl von Bildern auf der Grundlage der Mehrzahl von Textschlüsselwörtern des Kontexts erzeugen soll.
• Beispiel 459 umfasst den Gegenstand von Beispiel 458, wobei der Generator für synthetische Bilder ein Generative Adversarial Network ist.
• Beispiel 460 umfasst den Gegenstand eines der Beispiele 458-459, wobei die Bestimmung, dass zusätzliche Bilddaten für den Kontext erwünscht sind, die Bestimmung eines Grades der Gemeinsamkeit des Kontexts umfasst, der eine Menge verfügbarer Sensordaten anzeigt, die mit dem Kontext verbunden sind.
• Beispiel 461 umfasst den Gegenstand eines der Beispiele 458-460, wobei die Feststellung, dass zusätzliche Bilddaten für den Kontext erwünscht sind, die Analyse von Ergebnissen aus einer Datenbank umfasst, um festzustellen, ob der identifizierte Kontext realistisch ist.
• Beispiel 462 umfasst den Gegenstand von Beispiel 461, wobei die Datenbank eine Zusammenstellung von Daten umfasst, die aus einer Vielzahl von Internet-Datenquellen stammen.
• Beispiel 463 umfasst den Gegenstand eines der Beispiele 461-462, wobei die Datenbank eine Mehrzahl von Textschlüsselwörtern umfasst, die aus Bilddaten extrahiert wurden, die aus einer Mehrzahl von Internet-Datenquellen stammen.
• Beispiel 464 umfasst den Gegenstand eines der Beispiele 458-463, wobei ansprechend auf die Bestimmung eines Grades der Gemeinsamkeit des Kontexts ferner bestimmt wird, ob der Kontext realistisch ist, wobei die Bestimmung, ob der Kontext realistisch ist, unabhängig von der Bestimmung des Grades der Gemeinsamkeit des Kontexts bestimmt wird.
• Beispiel 465 umfasst den Gegenstand eines der Beispiele 458-464, wobei die Bereitstellung der Mehrzahl von Textschlüsselwörtern des Kontexts an den Generator für synthetische Bilder in Reaktion auf die Feststellung erfolgt, dass der Kontext einen geringen Grad an Gemeinsamkeit aufweist, aber dennoch realistisch ist.
• Beispiel 466 umfasst den Gegenstand eines der Beispiele 458-465, wobei die Mehrzahl der Textschlüsselwörter eine Betriebsumgebung des Fahrzeugs beschreibt.
• Beispiel 467 umfasst den Gegenstand eines der Beispiele 458-466, wobei die Sensordaten, die mit dem identifizierten Kontext verbunden sind, und die mehreren Bilder, die von dem Generator für synthetische Bilder erzeugt wurden, zu einem Datensatz hinzugefügt werden, der beim Training eines oder mehrerer Modelle für das Fahrzeug verwendet wird.
• Beispiel 468 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 458-467.
• Beispiel 469 ist ein maschinenlesbares Medium, das Anweisungen umfasst, wobei die Anweisungen, wenn sie ausgeführt werden, eine Vorrichtung realisieren oder ein Verfahren implementieren, wie in einem der Beispiele 458-467 beschrieben.
• Beispiel 470 ist ein nicht-transitorisches, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: einen Kontext zu identifizieren, der mit Sensordaten verbunden ist, die von einem oder mehreren Sensoren eines Fahrzeugs erfasst wurden, wobei der Kontext eine Mehrzahl von Textschlüsselwörtern umfasst; zu bestimmen, dass zusätzliche Bilddaten für den Kontext erwünscht sind; und die Mehrzahl von Textschlüsselwörtern des Kontexts einem Generator für synthetische Bilder zur Verfügung zu stellen, wobei der Generator für synthetische Bilder eine Mehrzahl von Bildern basierend auf der Mehrzahl von Textschlüsselwörtern des Kontexts erzeugt.
• Beispiel 471 umfasst den Gegenstand von Beispiel 470, wobei der Generator für synthetische Bilder ein Generative Adversarial Network ist.
• Beispiel 472 umfasst den Gegenstand eines der Beispiele 470-471, wobei die Bestimmung, dass zusätzliche Bilddaten für den Kontext erwünscht sind, die Bestimmung eines Grades der Gemeinsamkeit des Kontexts umfasst, der eine Menge verfügbarer Sensordaten anzeigt, die mit dem Kontext verbunden sind.
• Beispiel 473 umfasst den Gegenstand eines der Beispiele 470-472, wobei die Feststellung, dass zusätzliche Bilddaten für den Kontext erwünscht sind, die Analyse von Ergebnissen aus einer Datenbank umfasst, um festzustellen, ob der identifizierte Kontext realistisch ist.
• Beispiel 474 umfasst den Gegenstand von Beispiel 473, wobei die Datenbank eine Zusammenstellung von Daten umfasst, die aus einer Vielzahl von Internet-Datenquellen stammen.
• Beispiel 475 umfasst den Gegenstand eines der Beispiele 473-474, wobei die Datenbank eine Mehrzahl von Textschlüsselwörtern umfasst, die aus Bilddaten extrahiert wurden, die aus einer Vielzahl von Internet-Datenquellen stammen.
• Beispiel 476 umfasst den Gegenstand eines der Beispiele 470-475, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine ferner veranlassen, ansprechend auf die Bestimmung eines Grades der Gemeinsamkeit des Kontexts zu bestimmen, ob der Kontext realistisch ist, wobei die Bestimmung, ob der Kontext realistisch ist, unabhängig von der Bestimmung des Grades der Gemeinsamkeit des Kontexts bestimmt wird.
• Beispiel 477 umfasst den Gegenstand eines der Beispiele 470-476, wobei die Bereitstellung der Mehrzahl von Textschlüsselwörtern des Kontexts an den Generator für synthetische Bilder ansprechend auf die Feststellung erfolgt, dass der Kontext einen geringen Grad an Gemeinsamkeit aufweist, aber dennoch realistisch ist.
• Beispiel 478 umfasst den Gegenstand eines der Beispiele 470-477, wobei die Mehrzahl der Textschlüsselwörter eine Betriebsumgebung des Fahrzeugs beschreibt.
• Beispiel 479 umfasst den Gegenstand eines der Beispiele 470-478, wobei die Sensordaten, die mit dem identifizierten Kontext verbunden sind, und die mehreren Bilder, die von dem Generator für synthetische Bilder erzeugt wurden, zu einem Datensatz hinzugefügt werden, der beim Training eines oder mehrerer Modelle für das Fahrzeug verwendet wird.
• Beispiel 480 ist ein Verfahren, das Folgendes umfasst: Zugreifen auf einen gutartigen Datensatz, der eine Mehrzahl von Bildabtastwerten oder eine Mehrzahl von Audioabtastwerten umfasst, wobei die Abtastwerte des gutartigen Datensatzes bekannte Kennzeichnungen haben; Erzeugen eines simulierten Angriffsdatensatzes, dereine Mehrzahl von gegnerischen Abtastwerten umfasst, wobei die gegnerischen Abtastwerte durch Ausführen einer Mehrzahl von verschiedenen Angriffsmethoden auf Abtastwerte des gutartigen Datensatzes erzeugt werden; und Trainieren eines maschinellen Lernklassifikationsmodells unter Verwendung der gegnerischen Abtastwerte, der bekannten Kennzeichnungen und einer Mehrzahl von gutartigen Abtastwerten.
• Beispiel 481 umfasst den Gegenstand von Beispiel 480, wobei das trainierte maschinelle Lernklassifikationsmodell einem Fahrzeug zur Verwendung bei der Klassifikation von Abtastwerten, die von einem oder mehreren Sensoren des Fahrzeugs erfasst werden, zur Verfügung gestellt wird.
• Beispiel 482 umfasst den Gegenstand eines der Beispiele 480-481, wobei die mehreren verschiedenen Angriffsmethoden eine oder mehrere der folgenden Methoden umfassen: eine schnelle Gradientenvorzeichenmethode, eine iterative schnelle Gradientenvorzeichenmethode, eine Deep-Fool-Methode oder eine Universelle-Gegnerische-Störung-Methode.
• Beispiel 483 umfasst den Gegenstand eines der Beispiele 480-482, wobei ferner der simulierte Angriffsdatensatz erzeugt wird, indem die mehreren verschiedenen Angriffsmethoden gemäß einem Verhältnis auf der Grundlage eines erwarteten Angriffsverhältnisses durchgeführt werden.
• Beispiel 484 umfasst den Gegenstand eines der Beispiele 480-483, wobei das Erzeugen des simulierten Angriffsdatensatzes die Verwendung einer Mehrzahl unterschiedlicher Angriffsstärken für mindestens eine Angriffsmethode der Mehrzahl unterschiedlicher Angriffsmethoden umfasst.
• Beispiel 485 umfasst den Gegenstand von einem der Beispiele 480-484, ferner das Messen der Klassifizierungsgenauigkeit für eine Mehrzahl von Verhältnissen von gutartigen Abtastwerten zu gegnerischen Abtastwerten, um ein optimales Verhältnis von gutartigen Abtastwerten zu gegnerischen Abtastwerten zu bestimmen, das während des Trainings zu verwenden ist.
• Beispiel 486 umfasst den Gegenstand der Beispiele 480-485, einschließlich der Auferlegung einer Strafe während des Trainings für die Fehlklassifizierung eines gegnerischen Abtastwertes.
• Beispiel 487 umfasst den Gegenstand eines der Beispiele 480-486, wobei der gutartige Datensatz eine Sammlung von Bildabtastwerten umfasst.
• Beispiel 488 umfasst den Gegenstand eines der Beispiele 480-486, wobei der gutartige Datensatz eine Sammlung von Audioabtastwerten umfasst.
• Beispiel 489 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 480-488.
• Beispiel 490 ist ein maschinenlesbares Medium, das Anweisungen umfasst, wobei die Anweisungen, wenn sie ausgeführt werden, eine Vorrichtung realisieren oder ein Verfahren implementieren, wie es in einem der Beispiele 480-488 beschrieben wurde.
• Beispiel 491 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen auf einen gutartigen Datensatz zuzugreifen, der eine Mehrzahl von Bildabtastwerten oder eine Mehrzahl von Audioabtastwerten umfasst, wobei die Abtastwerte des gutartigen Datensatzes bekannte Kennzeichnungen haben; einen simulierten Angriffsdatensatz zu erzeugen, der eine Mehrzahl von gegnerischen Abtastwerten umfasst, wobei die gegnerischen Abtastwerte erzeugt werden, indem eine Mehrzahl von unterschiedlichen Angriffsspeichermedien auf Abtastwerten des gutartigen Datensatzes ausgeführt werden; und ein maschinelles Lernklassifizierungsmodell unter Verwendung der gegnerischen Abtastwerte, der bekannten Kennzeichnungen und einer Mehrzahl von gutartigen Abtastwerten zu trainieren.
• Beispiel 492 umfasst den Gegenstand von Beispiel 491, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, das trainierte maschinelle Lernklassifizierungsmodell einem Fahrzeug zur Verwendung bei der Klassifizierung von Abtastwerten bereitzustellen, die von einem oder mehreren Sensoren des Fahrzeugs erfasst werden.
• Beispiel 493 umfasst den Gegenstand von einem der Beispiele 491-492, wobei die Mehrzahl von verschiedenen Angriffsspeichermedien eines oder mehrere von einem schnellen Gradientenvorzeichenspeichermedium, einem iterativen schnellen Gradientenvorzeichenspeichermedium, einem Deep-Fool-Speichermedium oder einer universellen gegnerischen Störung umfassen.
• Beispiel 494 schließt den Gegenstand eines der Beispiele 491-493 ein, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, den simulierten Angriffsdatensatz zu erzeugen, indem sie die Mehrzahl verschiedener Angriffsspeichermedien gemäß einem auf einer erwarteten Angriffsquote basierenden Verhältnis ausführt.
• Beispiel 495 umfasst den Gegenstand eines der Beispiele 491-494, wobei das Erzeugen des simulierten Angriffsdatensatzes die Verwendung einer Mehrzahl unterschiedlicher Angriffsstärken für mindestens ein Angriffsspeichermedium der Mehrzahl unterschiedlicher Angriffsspeichermedien umfasst.
• Beispiel 496 umfasst den Gegenstand eines der Beispiele 491-495, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, die Klassifizierungsgenauigkeit für eine Mehrzahl von Verhältnissen von gutartigen Abtastwerten zu gegnerischen Abtastwerten zu messen, um ein optimales Verhältnis von gutartigen Abtastwerten zu gegnerischen Abtastwerten zu bestimmen, das während des Trainings zu verwenden ist.
• Beispiel 497 umfasst den Gegenstand eines der Beispiele 491-496, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine außerdem veranlassen, während des Trainings eine Strafe für die Fehlklassifizierung eines gegnerischen Abtastwertes zu verhängen.
• Beispiel 498 umfasst den Gegenstand eines der Beispiele 491-497, wobei der gutartige Datensatz eine Sammlung von Bildabtastwerten umfasst.
• Beispiel 499 umfasst den Gegenstand eines der Beispiele 491-497, wobei der gutartige Datensatz eine Sammlung von Audioabtastwerten umfasst.
• Beispiel 500 ist ein Verfahren, das Folgendes umfasst: Klassifizieren von Eingabeabtastwerte eines Fahrzeugs durch einen linearen Klassifikator; Klassifizieren der Eingabeabtastwerte des Fahrzeugs durch einen nichtlinearen Klassifikator; Erfassen einer Änderung der Genauigkeit des linearen Klassifikators; und Auslösen mindestens einer Aktion ansprechend auf die Änderung der Genauigkeit des linearen Klassifikators.
• Beispiel 501 umfasst den Gegenstand von Beispiel 500, wobei die ausgelöste mindestens eine Aktion ein Umlernen des linearen Klassifikators und des nichtlinearen Klassifikators umfasst.
• Beispiel 502 umfasst den Gegenstand eines der Beispiele 500-501, wobei die ausgelöste mindestens eine Aktion eine Erzeugung synthetischer Daten auf der Grundlage kürzlich klassifizierter Eingabeabtastwerte umfasst.
• Beispiel 503 umfasst den Gegenstand eines der Beispiele 500-502, wobei die ausgelöste mindestens eine Aktion eine Bestimmung umfasst, ob ein Angriff auf die Eingabeabtastwerte erfolgt ist.
• Beispiel 504 umfasst den Gegenstand eines der Beispiele 500-503, wobei die ausgelöste mindestens eine Aktion eine Zufallsstichprobe von kürzlich klassifizierten Eingabeabtastwerte umfasst, wobei die Zufallsstichprobe bei der Umschulung des linearen Klassifizierers und des nichtlinearen Klassifizierers verwendet werden soll, wobei die anderen Abtastwerte der kürzlich klassifizierten Eingabeabtastwerte nicht bei der Umschulung verwendet werden sollen.
• Beispiel 505 umfasst den Gegenstand eines der Beispiele 500-504, wobei das Erfassen der Änderung der Genauigkeit des linearen Klassifizierers das Erfassen umfasst, dass die Genauigkeit des linearen Klassifizierers unter einen Schwellenwert gefallen ist.
• Beispiel 506 umfasst den Gegenstand eines der Beispiele 500-505, einschließlich der Durchführung einer Objekterkennung, die zumindest teilweise auf der Klassifizierung der Eingabeabtastwerte unter Verwendung des nichtlinearen Klassifizierers basiert.
• Beispiel 507 umfasst den Gegenstand eines der Beispiele 500-506, wobei die Abtastwerte von einem oder mehreren Sensoren des Fahrzeugs gesammelt werden.
• Beispiel 508 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 500-507.
• Beispiel 509 ist ein maschinenlesbares Medium, das Anweisungen umfasst, wobei die Anweisungen, wenn sie ausgeführt werden, eine Vorrichtung realisieren oder ein Verfahren implementieren, wie in einem der Beispiele 500-507 beschrieben.
• Beispiel 510 ist ein nicht-transitorisches, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: Eingabeabtastwerte von einem Fahrzeug durch einen linearen Klassifizierer zu klassifizieren; die Abtastwerte von dem Fahrzeug durch einen nicht-linearen Klassifizierer zu klassifizieren; eine Änderung in einer Genauigkeit des linearen Klassifizierers zu erkennen; und mindestens eine Aktion in Reaktion auf die Änderung in der Genauigkeit des linearen Klassifizierers auszulösen.
• Beispiel 511 umfasst den Gegenstand von Beispiel 510, wobei die ausgelöste mindestens eine Aktion ein Umlernen des linearen Klassifikators und des nichtlinearen Klassifikators umfasst.
• Beispiel 512 umfasst den Gegenstand eines der Beispiele 510-511, wobei die ausgelöste mindestens eine Aktion eine Erzeugung synthetischer Daten auf der Grundlage kürzlich klassifizierter Eingabeabtastwerte umfasst.
• Beispiel 513 umfasst den Gegenstand eines der Beispiele 510-512, wobei die ausgelöste mindestens eine Aktion eine Bestimmung umfasst, ob ein Angriff auf die Eingabeabtastwerte erfolgt ist.
• Beispiel 514 umfasst den Gegenstand eines der Beispiele 510-513, wobei die ausgelöste mindestens eine Aktion eine Zufallsstichprobe von kürzlich klassifizierten Eingabeabtastwerte umfasst, wobei die Zufallsstichprobe bei der Umschulung des linearen Klassifizierers und des nichtlinearen Klassifizierers verwendet werden soll, wobei die anderen Abtastwerte der kürzlich klassifizierten Eingabeabtastwerte nicht bei der Umschulung verwendet werden sollen.
• Beispiel 515 umfasst den Gegenstand eines der Beispiele 510-514, wobei das Erkennen der Änderung der Genauigkeit des linearen Klassifizierers das Erkennen umfasst, dass die Genauigkeit des linearen Klassifizierers unter einen Schwellenwert gefallen ist.
• Beispiel 516 umfasst den Gegenstand eines der Beispiele 510-515, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, eine Objekterkennung durchzuführen, die zumindest teilweise auf der Klassifizierung der Eingabeabtastwerte unter Verwendung des nichtlinearen Klassifizierers beruht.
• Beispiel 517 umfasst den Gegenstand eines der Beispiele 510-516, wobei die Eingabeabtastwerte von einem oder mehreren Sensoren des Fahrzeugs gesammelt werden.
• Beispiel 518 ist ein Verfahren, das Folgendes umfasst: Erzeugen eines ersten Satzes von einem oder mehreren Steuersignalen ansprechend auf menschliche Eingaben in ein Fahrzeug; ansprechend auf die Feststellung, dass der erste Satz von einem oder mehreren Steuersignalen eine inakzeptable Beschleunigung verursachen würde: Identifizieren einer akzeptablen Beschleunigung; Umwandeln der akzeptablen Beschleunigung in einen zweiten Satz von einem oder mehreren Steuersignalen; und Bereitstellen des zweiten Satzes von einem oder mehreren Steuersignalen für ein Fahrzeugbetätigungssystem anstelle des ersten Satzes von einem oder mehreren Steuersignalen.
• Beispiel 519 umfasst den Gegenstand von Beispiel 518, ferner: Empfangen eines Bereichs von akzeptablen Beschleunigungswerten; und Identifizieren der akzeptablen Beschleunigung aus dem Bereich der akzeptablen Beschleunigungswerte.
• Beispiel 520 umfasst den Gegenstand von Beispiel 519, wobei der Bereich der zulässigen Beschleunigungswerte in Übereinstimmung mit einem mathematischen Modell zur Unfallvermeidung bestimmt wird.
• Beispiel 521 umfasst den Gegenstand eines der Beispiele 519-520, wobei der Bereich der zulässigen Beschleunigungswerte in Übereinstimmung mit einem verantwortungsbewussten Sicherheitsmodell bestimmt wird.
• Beispiel 522 umfasst den Gegenstand eines der Beispiele 518-521, wobei die Feststellung, dass das eine oder die mehreren Steuersignale eine inakzeptable Beschleunigung verursachen würden, die Umwandlung des einen oder der mehreren Steuersignale in eine erwartete Beschleunigung unter Verwendung eines Maschinelles-Lernen-Modells umfasst.
• Beispiel 523 umfasst den Gegenstand eines der Beispiele 518-522, wobei die Umwandlung der zulässigen Beschleunigung in einen zweiten Satz von einem oder mehreren Steuersignalen die Umwandlung der zulässigen Beschleunigung auf der Grundlage des mit dem Fahrzeug verbundenen Kontextes umfasst, wobei der Kontext auf der Grundlage der über einen oder mehrere Sensoren des Fahrzeugs empfangenen Eingaben bestimmt wird.
• Beispiel 524 umfasst den Gegenstand von Beispiel 523, wobei die über einen oder mehrere Sensoren des Fahrzeugs empfangene Eingabe einen oder mehrere Straßenzustände, Wetterbedingungen, Reifenzustände oder den Straßenverlauf angibt.
• Beispiel 525 umfasst den Gegenstand eines der Beispiele 518-524, wobei die Umwandlung der zulässigen Beschleunigung in einen zweiten Satz von einem oder mehreren Steuersignalen die Umwandlung der zulässigen Beschleunigung auf der Grundlage eines Gewichts des Fahrzeugs umfasst.
• Beispiel 526 umfasst den Gegenstand eines der Beispiele 518-525, wobei die Identifizierung einer zulässigen Beschleunigung die Auswahl einer zulässigen Beschleunigung aus einem Bereich zulässiger Beschleunigungen auf der Grundlage der vom Fahrer des Fahrzeugs bereitgestellten Richtlinieninformationen umfasst.
• Beispiel 527 umfasst den Gegenstand von einem der Beispiele 518-526, ferner umfassend: Erzeugen eines dritten Satzes von einem oder mehreren Steuersignalen ansprechend auf menschliche Eingaben in das Fahrzeug; und ansprechend auf die Feststellung, dass der dritte Satz von einem oder mehreren Steuersignalen eine akzeptable Beschleunigung verursachen würde, Bereitstellen des dritten Satzes von einem oder mehreren Steuersignalen unverändert an das Fahrzeugbetätigungssystem.
• Beispiel 528 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 518-527.
• Beispiel 529 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, einen ersten Satz von einem oder mehreren Steuersignalen ansprechend auf menschliche Eingaben in ein Fahrzeug zu erzeugen; ansprechend auf die Feststellung, dass der erste Satz von einem oder mehreren Steuersignalen eine unannehmbare Beschleunigung verursachen würde, eine annehmbare Beschleunigung zu identifizieren; die annehmbare Beschleunigung in einen zweiten Satz von einem oder mehreren Steuersignalen umzuwandeln; und den zweiten Satz von einem oder mehreren Steuersignalen anstelle des ersten Satzes von einem oder mehreren Steuersignalen an ein Fahrzeugbetätigungssystem zu liefern.
• Beispiel 530 umfasst den Gegenstand von Beispiel 529, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine außerdem veranlassen, einen Bereich akzeptabler Beschleunigungswerte zu empfangen und die akzeptable Beschleunigung aus dem Bereich der akzeptablen Beschleunigungswerte zu identifizieren.
• Beispiel 531 umfasst den Gegenstand von Beispiel 530, wobei der Bereich der zulässigen Beschleunigungswerte in Übereinstimmung mit einem mathematischen Modell zur Unfallvermeidung bestimmt wird.
• Beispiel 532 umfasst den Gegenstand der Beispiele 530-531, wobei der Bereich der zulässigen Beschleunigungswerte gemäß einem verantwortungsbewussten Sicherheitsmodell bestimmt wird.
• Beispiel 533 umfasst den Gegenstand eines der Beispiele 529-532, wobei die Feststellung, dass das eine oder die mehreren Steuersignale eine inakzeptable Beschleunigung verursachen würden, die Umwandlung des einen oder der mehreren Steuersignale in eine erwartete Beschleunigung unter Verwendung eines Maschinelles-Lernen-Modells umfasst.
• Beispiel 534 umfasst den Gegenstand eines der Beispiele 529-533, wobei die Umwandlung der zulässigen Beschleunigung in einen zweiten Satz von einem oder mehreren Steuersignalen die Umwandlung der zulässigen Beschleunigung auf der Grundlage des mit dem Fahrzeug verbundenen Kontextes umfasst, wobei der Kontext auf der Grundlage der über einen oder mehrere Sensoren des Fahrzeugs empfangenen Eingaben bestimmt wird.
• Beispiel 535 schließt den Gegenstand von Beispiel 534 ein, wobei die über einen oder mehrere Sensoren des Fahrzeugs empfangene Eingabe einen oder mehrere Straßenzustände, Wetterbedingungen, Reifenzustände oder die Straßenführung anzeigt.
• Beispiel 536 umfasst den Gegenstand eines der Beispiele 529-535, wobei die Umwandlung der zulässigen Beschleunigung in einen zweiten Satz von einem oder mehreren Steuersignalen die Umwandlung der zulässigen Beschleunigung auf der Grundlage eines Gewichts des Fahrzeugs umfasst.
• Beispiel 537 umfasst den Gegenstand eines der Beispiele 529-536, wobei die Identifizierung einer zulässigen Beschleunigung die Auswahl einer zulässigen Beschleunigung aus einem Bereich zulässiger Beschleunigungen auf der Grundlage der vom Fahrer des Fahrzeugs bereitgestellten Richtlinieninformationen umfasst.
• Beispiel 538 umfasst den Gegenstand eines der Beispiele 529-537, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine ferner veranlassen, einen dritten Satz von einem oder mehreren Steuersignalen ansprechend auf menschliche Eingaben in das Fahrzeug zu erzeugen; und ansprechend auf die Feststellung, dass der dritte Satz von einem oder mehreren Steuersignalen eine akzeptable Beschleunigung verursachen würde, den dritten Satz von einem oder mehreren Steuersignalen unverändert an das Fahrzeugbetätigungssystem zu liefern.
• Beispiel 539 ist ein Verfahren, das Folgendes umfasst: Bestimmen einer Signalqualitätsmetrik durch ein Rechensystem eines Fahrzeugs auf der Grundlage von Sensordaten und einem Kontext der Sensordaten; Bestimmen einer Wahrscheinlichkeit der Sicherheit in Verbindung mit einer Übergabe der Kontrolle über das Fahrzeug auf der Grundlage der Signalqualitätsmetrik; und Verhindern der Übergabe oder Einleiten der Übergabe der Kontrolle über das Fahrzeug auf der Grundlage der Wahrscheinlichkeit der Sicherheit.
• Beispiel 540 umfasst den Gegenstand von Beispiel 539, einschließlich der Verwendung eines Maschinelles-Lernen-Modells, um den Kontext der Sensordaten basierend auf den Sensordaten zu bestimmen.
• Beispiel 541 umfasst den Gegenstand eines der Beispiele 539-540, einschließlich der Verwendung eines Maschinelles-Lernen-Modells zur Bestimmung der Wahrscheinlichkeit der Sicherheit auf der Grundlage der Signalqualitätsmetrik.
• Beispiel 542 umfasst den Gegenstand eines der Beispiele 539 bis 541, einschließlich der Verwendung eines Maschinelles-Lernen-Modells zur Bestimmung der Signalqualitätsmetrik auf der Grundlage der Sensordaten und des Kontexts der Sensordaten.
• Beispiel 543 umfasst den Gegenstand eines der Beispiele 539-542, einschließlich der periodischen Bestimmung einer Sicherheitswahrscheinlichkeit im Zusammenhang mit einer Übergabe der Kontrolle über das Fahrzeug, während das Fahrzeug autonom gesteuert wird.
• Beispiel 544 umfasst den Gegenstand eines der Beispiele 539-543, einschließlich der Bestimmung der Wahrscheinlichkeit der Sicherheit im Zusammenhang mit einer Übergabe der Kontrolle über das Fahrzeug ansprechend auf eine Aufforderung eines menschlichen Fahrers, die Kontrolle über das Fahrzeug abzugeben.
• Beispiel 545 umfasst den Gegenstand eines der Beispiele 539-544, einschließlich der Bestimmung der Wahrscheinlichkeit der Sicherheit, die mit einer Übergabe der Kontrolle über das Fahrzeug verbunden ist, als Reaktion darauf, dass das Fahrzeug in einen Bereich einfährt, in dem hochauflösende Karten des Bereichs für das Fahrzeug nicht verfügbar sind.
• Beispiel 546 umfasst den Gegenstand eines der Beispiele 539-545, wobei die Signalqualitätsmetrik zumindest teilweise ein Signal-Rausch-Verhältnis der Sensordaten angibt.
• Beispiel 547 umfasst den Gegenstand eines der Beispiele 539-546, wobei die Signalqualitätsmetrik zumindest teilweise eine Auflösung der Sensordaten angibt.
• Beispiel 548 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 539-547.
• Beispiel 549 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: durch ein Rechensystem eines Fahrzeugs eine Signalqualitätsmetrik auf der Grundlage von Sensordaten und einem Kontext der Sensordaten zu bestimmen; auf der Grundlage der Signalqualitätsmetrik eine Wahrscheinlichkeit der Sicherheit zu bestimmen, die mit einer Übergabe der Kontrolle über das Fahrzeug verbunden ist; und die Übergabe zu verhindern oder die Übergabe der Kontrolle über das Fahrzeug auf der Grundlage der Wahrscheinlichkeit der Sicherheit einzuleiten.
• Beispiel 550 umfasst den Gegenstand von Beispiel 549, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, ein maschinelles Lernmodell zu verwenden, um den Kontext der Sensordaten auf der Grundlage der Sensordaten zu bestimmen.
• Beispiel 551 umfasst den Gegenstand eines der Beispiele 549-550, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, ein maschinelles Lernmodell zu verwenden, um die Wahrscheinlichkeit der Sicherheit auf der Grundlage der Signalqualitätsmetrik zu bestimmen.
• Beispiel 552 umfasst den Gegenstand eines der Beispiele 549-551, wobei die Anweisungen bei ihrer Ausführung ferner die Maschine veranlassen, ein maschinelles Lernmodell zu verwenden, um die Signalqualitätsmetrik auf der Grundlage der Sensordaten und des Kontexts der Sensordaten zu bestimmen.
• Beispiel 553 umfasst den Gegenstand eines der Beispiele 549-552, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, periodisch eine Wahrscheinlichkeit der Sicherheit zu bestimmen, die mit einer Übergabe der Kontrolle über das Fahrzeug verbunden ist, während das Fahrzeug autonom gesteuert wird.
• Beispiel 554 umfasst den Gegenstand eines der Beispiele 549-553, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine ferner veranlassen, die Wahrscheinlichkeit der Sicherheit in Verbindung mit einer Übergabe der Kontrolle über das Fahrzeug ansprechend auf eine Aufforderung eines menschlichen Fahrers, die Kontrolle über das Fahrzeug abzugeben, zu bestimmen.
• Beispiel 555 umfasst den Gegenstand eines der Beispiele 549-554, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine ferner veranlassen, die Wahrscheinlichkeit der Sicherheit zu bestimmen, die mit einer Übergabe der Kontrolle über das Fahrzeug verbunden ist, wenn das Fahrzeug in ein Gebiet einfährt, in dem hochauflösende Karten des Gebiets für das Fahrzeug nicht verfügbar sind.
• Beispiel 556 umfasst den Gegenstand eines der Beispiele 549-555, wobei die Signalqualitätsmetrik zumindest teilweise ein Signal-Rausch-Verhältnis der Sensordaten angibt.
• Beispiel 557 umfasst den Gegenstand eines der Beispiele 549-556, wobei die Signalqualitätsmetrik zumindest teilweise eine Auflösung der Sensordaten angibt.
• Beispiel 558 ist ein Verfahren, das Folgendes umfasst: Sammeln von Sensordaten von mindestens einem Sensor, der sich im Inneren eines Fahrzeugs befindet; Analysieren der Sensordaten, um einen physischen Zustand einer Person im Inneren des Fahrzeugs zu bestimmen; und Erzeugen einer Übergabeentscheidung, die zumindest teilweise auf dem physischen Zustand der Person basiert, wobei die Übergabeentscheidung anzeigt, ob die Person voraussichtlich in der Lage ist, das Fahrzeug sicher zu bedienen.
• Beispiel 559 umfasst den Gegenstand von Beispiel 558, ferner: Identifizieren von historischen Fahrdaten der Person im Fahrzeug; und Erzeugen der Übergabeentscheidung ferner auf der Grundlage der historischen Fahrdaten der Person.
• Beispiel 560 umfasst den Gegenstand von einem der Beispiele 558-559, weiterhin umfassend: Analysieren von Sensordaten, um einen Kontext zu bestimmen, der Bedingungen außerhalb des Fahrzeugs anzeigt; und Erzeugen einer Weitergabeentscheidung weiterhin basierend auf dem Kontext.
• Beispiel 561 umfasst den Gegenstand eines der Beispiele 558-560, wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf Sensordaten einschließlich Bilddaten der Person im Fahrzeug basiert.
• Beispiel 562 umfasst den Gegenstand eines der Beispiele 558-561, wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf Sensordaten einschließlich Audiodaten der Person im Fahrzeug basiert.
• Beispiel 563 umfasst den Gegenstand eines der Beispiele 558-562, wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf Sensordaten, einschließlich Temperaturdaten der Person im Fahrzeug, basiert.
• Beispiel 564 umfasst den Gegenstand eines der Beispiele 558-563, wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf Sensordaten einschließlich Druckdaten von einem Tastsensor basiert.
• Beispiel 565 umfasst den Gegenstand eines der Beispiele 558-564, wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf Daten basiert, die von einem von der Person getragenen Gerät zur Gesundheitsüberwachung empfangen werden.
• Beispiel 566 umfasst den Gegenstand von einem der Beispiele 558-565, weiterhin umfassend: Bestimmen, basierend auf den Sensordaten, einer spezifischen Aktivität, die von der Person innerhalb des Fahrzeugs ausgeführt wird; und wobei der physische Zustand der Person innerhalb des Fahrzeugs zumindest teilweise auf der bestimmten Aktivität basiert.
• Beispiel 567 umfasst den Gegenstand eines der Beispiele 558-566 und umfasst ferner: Vorverarbeitung von Audiodaten der Sensordaten, um Geräusche zu isolieren, die von der Person im Fahrzeug oder einem oder mehreren Insassen verursacht werden; und wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf den vorverarbeiteten Audiodaten basiert.
• Beispiel 568 umfasst den Gegenstand eines der Beispiele 558-567, wobei die Sensordaten eines oder mehrere der folgenden Elemente umfassen: Medien, die im Fahrzeug abgespielt werden; ein Lichtpegel im Fahrzeug; ein Maß an Interaktivität zwischen der Person und einem oder mehreren Bedienelementen des Armaturenbretts; Fensteröffnungspegel, ein Zustand eines Temperaturregelungssystems in der Kabine; oder ein Zustand eines Telefons der Person.
• Beispiel 569 umfasst den Gegenstand eines der Beispiele 558-568, wobei der physische Zustand der Person mit Hilfe eines maschinellen Lernalgorithmus unter Verwendung der Sensordaten als Eingabe durchgeführt wird.
• Beispiel 570 umfasst den Gegenstand eines der Beispiele 558-569, einschließlich der Verwendung eines Algorithmus für maschinelles Lernen, um die Weitergabeentscheidung zu generieren.
• Beispiel 571 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 558-570.
• Beispiel 572 ist ein nicht-transitorisches, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: Sensordaten von mindestens einem Sensor zu sammeln, der sich im Inneren eines Fahrzeugs befindet; die Sensordaten zu analysieren, um einen physischen Zustand einer Person im Inneren des Fahrzeugs zu bestimmen; und eine Übergabeentscheidung zu erzeugen, die zumindest teilweise auf dem physischen Zustand der Person basiert, wobei die Übergabeentscheidung anzeigt, ob von der Person erwartet wird, dass sie das Fahrzeug sicher bedienen kann.
• Beispiel 573 umfasst den Gegenstand von Beispiel 572, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine außerdem veranlassen, historische Fahrdaten der Person im Fahrzeug zu identifizieren und die Übergabeentscheidung außerdem auf der Grundlage der historischen Fahrdaten der Person zu erzeugen.
• Beispiel 574 umfasst den Gegenstand eines der Beispiele 572-573, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine außerdem dazu veranlassen: Sensordaten zu analysieren, um einen Kontext zu bestimmen, der Bedingungen außerhalb des Fahrzeugs anzeigt; und eine Weitergabeentscheidung zu erzeugen, die außerdem auf dem Kontext basiert.
• Beispiel 575 umfasst den Gegenstand eines der Beispiele 572-574, wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf Sensordaten einschließlich Bilddaten der Person im Fahrzeug basiert.
• Beispiel 576 umfasst den Gegenstand eines der Beispiele 572-575, wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf Sensordaten einschließlich Audiodaten der Person im Fahrzeug basiert.
• Beispiel 577 umfasst den Gegenstand eines der Beispiele 572-576, wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf Sensordaten, einschließlich Temperaturdaten der Person im Fahrzeug, basiert.
• Beispiel 578 umfasst den Gegenstand eines der Beispiele 572-577, wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf Sensordaten einschließlich Druckdaten von einem Tastsensor basiert.
• Beispiel 579 umfasst den Gegenstand eines der Beispiele 572-578, wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf Daten basiert, die von einem von der Person getragenen Gerät zur Gesundheitsüberwachung empfangen werden.
• Beispiel 580 umfasst den Gegenstand eines der Beispiele 572-579, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine ferner veranlassen, auf der Grundlage der Sensordaten eine spezifische Aktivität zu bestimmen, die von der Person im Fahrzeug ausgeführt wird, und wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf der bestimmten Aktivität basiert.
• Beispiel 581 umfasst den Gegenstand eines der Beispiele 572-580, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine ferner veranlassen, Audiodaten der Sensordaten vorzuverarbeiten, um Geräusche zu isolieren, die von der Person im Fahrzeug oder einem oder mehreren Insassen verursacht werden; und wobei der physische Zustand der Person im Fahrzeug zumindest teilweise auf den vorverarbeiteten Audiodaten basiert.
• Beispiel 582 umfasst den Gegenstand eines der Beispiele 572-581, wobei die Sensordaten eines oder mehrere der folgenden Elemente umfassen: Medien, die im Fahrzeug abgespielt werden; ein Lichtpegel im Fahrzeug; ein Maß an Interaktivität zwischen der Person und einem oder mehreren Bedienelementen des Armaturenbretts; Fensteröffnungspegel, ein Zustand eines Temperaturregelungssystems in der Kabine; oder ein Zustand eines Telefons der Person.
• Beispiel 583 umfasst den Gegenstand eines der Beispiele 572-582, wobei der physische Zustand der Person mit Hilfe eines maschinellen Lernalgorithmus unter Verwendung der Sensordaten als Eingabe durchgeführt wird.
• Beispiel 584 umfasst den Gegenstand eines der Beispiele 572-283, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, einen maschinellen Lernalgorithmus zu verwenden, um die Übergabeentscheidung zu erzeugen.
• Beispiel 585 ist ein Verfahren, das Folgendes umfasst: Betreiben des autonomen Fahrzeugs in einem autonomen Fahrmodus durch eine Steuereinheit eines autonomen Fahrzeugs; Empfangen einer Anforderung zur Übernahme der Steuerung des autonomen Fahrzeugs durch eine andere Einheit als die Steuereinheit; Auffordern der anfordernden Einheit zur Eingabe von Anmeldeinformationen ansprechend auf den Empfang der Anforderung zur Übernahme der Steuerung des autonomen Fahrzeugs; Empfangen einer Eingabe ansprechend auf die Aufforderung; und Zulassen der Anforderung zur Übernahme der Steuerung des autonomen Fahrzeugs ansprechend auf die Authentifizierung der anfordernden Einheit auf der Grundlage der empfangenen Eingabe.
• Beispiel 586 umfasst den Gegenstand von Beispiel 585, wobei die Aufforderung an die anfragende Einheit, sich zu legitimieren, die Aufforderung an die anfragende Einheit umfasst, ein biometrisches Merkmal zur Authentifizierung bereitzustellen.
• Beispiel 587 umfasst den Gegenstand von Beispiel 586, wobei das biometrische Merkmal einen oder mehrere Fingerabdrücke, einen Stimmenabtastwert für die Stimmerkennung und einen Gesichtsabtastwert für die Gesichtserkennung umfasst.
• Beispiel 588 umfasst den Gegenstand eines der Beispiele 585-587, wobei die anfragende Einheit eine Person im Inneren des autonomen Fahrzeugs ist.
• Beispiel 589 umfasst den Gegenstand eines der Beispiele 585-587, wobei die anfragende Einheit eine vom autonomen Fahrzeug entfernte Person ist.
• Beispiel 590 umfasst den Gegenstand von einem der Beispiele 585-587, wobei die anfragende Einheit ein oder mehrere andere autonome Fahrzeuge in der Nähe des autonomen Fahrzeugs umfasst.
• Beispiel 591 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 585-590.
• Beispiel 592 ist ein Verfahren, das Folgendes umfasst: Betreiben eines autonomen Fahrzeugs in einem manuellen Betriebsmodus, wobei das autonome Fahrzeug auf der Grundlage menschlicher Eingaben gesteuert wird; Empfangen von Sensordaten von einer Mehrzahl von Sensoren innerhalb des autonomen Fahrzeugs; Erkennen auf der Grundlage einer Analyse der Sensordaten, dass die menschlichen Eingaben unsicher sind; und Betreiben des autonomen Fahrzeugs in einem autonomen Betriebsmodus ansprechend auf das Erkennen der unsicheren menschlichen Eingaben.
• Beispiel 593 umfasst den Gegenstand von Beispiel 592, wobei die Feststellung, dass die menschliche Eingabe unsicher ist, eine oder mehrere der folgenden Feststellungen umfasst: Feststellung, dass der Mensch, der die Eingabe macht, abgelenkt ist, Feststellung, dass der Mensch, der die Eingabe macht, beeinträchtigt ist, und Feststellung, dass der Mensch, der die Eingabe macht, bewusstlos ist.
• Beispiel 594 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 592-593.
• Beispiel 595 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen,: betreiben des autonomen Fahrzeugs in einem autonomen Fahrmodus durch eine Steuereinheit eines autonomen Fahrzeugs; Empfangen einer Anforderung zur Übernahme der Steuerung des autonomen Fahrzeugs durch eine andere Einheit als die Steuereinheit; Auffordern der anfordernden Einheit zur Eingabe von Anmeldeinformationen ansprechend auf den Empfang der Anforderung zur Übernahme der Steuerung des autonomen Fahrzeugs; Empfangen einer Eingabe ansprechend auf die Aufforderung; und Zulassen der Anforderung zur Übernahme der Steuerung des autonomen Fahrzeugs ansprechend auf die Authentifizierung der anfordernden Einheit auf der Grundlage der empfangenen Eingabe.
• Beispiel 596 umfasst den Gegenstand von Beispiel 595, wobei die Aufforderung an die anfragende Einheit, sich zu legitimieren, die Aufforderung an die anfragende Einheit umfasst, ein biometrisches Merkmal zur Authentifizierung bereitzustellen.
• Beispiel 597 umfasst den Gegenstand von Beispiel 596, wobei das biometrische Merkmal einen oder mehrere Fingerabdrücke, einen Stimmenabtastwert für die Stimmerkennung und einen Gesichtsabtastwert für die Gesichtserkennung umfasst.
• Beispiel 598 umfasst den Gegenstand eines der Beispiele 595-597, wobei die anfragende Einheit eine Person im Inneren des autonomen Fahrzeugs ist.
• Beispiel 599 umfasst den Gegenstand eines der Beispiele 595-597, wobei die anfragende Einheit eine vom autonomen Fahrzeug entfernte Person ist.
• Beispiel 600 umfasst den Gegenstand von einem der Beispiele 595-597, wobei die anfragende Einheit ein oder mehrere andere autonome Fahrzeuge in der Nähe des autonomen Fahrzeugs umfasst.
• Beispiel 601 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, ein autonomes Fahrzeug in einem manuellen Betriebsmodus zu betreiben, wobei das autonome Fahrzeug auf der Grundlage menschlicher Eingaben gesteuert wird; Sensordaten von einer Mehrzahl von Sensoren innerhalb des autonomen Fahrzeugs zu empfangen; auf der Grundlage einer Analyse der Sensordaten zu erkennen, dass die menschlichen Eingaben unsicher sind; und das autonome Fahrzeug ansprechend auf die Erkennung der unsicheren menschlichen Eingaben in einem autonomen Betriebsmodus zu betreiben.
• Beispiel 602 umfasst den Gegenstand von Beispiel 601, wobei die Feststellung, dass die menschliche Eingabe unsicher ist, eine oder mehrere der folgenden Feststellungen umfasst: Feststellung, dass der Mensch, der die Eingabe macht, abgelenkt ist, Feststellung, dass der Mensch, der die Eingabe macht, beeinträchtigt ist, und Feststellung, dass der Mensch, der die Eingabe macht, bewusstlos ist.
• Beispiel 603 ist ein Verfahren, das Folgendes umfasst: Betreiben des autonomen Fahrzeugs in einer autonomen Betriebsart durch ein Steuersystem eines autonomen Fahrzeugs auf der Grundlage von Sensordaten, die von einer Mehrzahl von mit dem autonomen Fahrzeug gekoppelten Sensoren erhalten werden; Erfassen einer Übernahmeanforderung durch einen Insassen des autonomen Fahrzeugs durch das Steuersystem des autonomen Fahrzeugs; Bestimmen, ob die angeforderte Übernahme sicher ist, durch das Steuersystem des autonomen Fahrzeugs auf der Grundlage der Sensordaten; und Blockieren der angeforderten Übernahme ansprechend auf die Feststellung, dass die angeforderte Übernahme unsicher ist.
• Beispiel 604 umfasst den Gegenstand von Beispiel 603, einschließlich der Änderung der autonomen Betriebsart ansprechend auf die Feststellung, dass die Übernahme der Anforderung unsicher ist.
• Beispiel 605 umfasst den Gegenstand von Beispiel 604, ferner: Auffordern des Insassen zur Eingabe ansprechend auf die Bestimmung; und Empfangen einer Eingabe von dem Insassen ansprechend auf die Aufforderung; wobei das Modifizieren des autonomen Betriebsmodus auf der empfangenen Eingabe basiert.
• Beispiel 606 umfasst den Gegenstand von Beispiel 603, wobei die mehreren mit dem autonomen Fahrzeug gekoppelten Sensoren Innenraumsensoren im Inneren des autonomen Fahrzeugs umfassen und die Bestimmung, ob die angeforderte Übernahme sicher ist, auf Sensordaten basiert, die von den Innenraumsensoren empfangen werden.
• Beispiel 607 umfasst den Gegenstand von Beispiel 606, wobei die Innensensoren eine oder mehrere Kameras und ein Mikrofon umfassen.
• Beispiel 608 umfasst den Gegenstand eines der Beispiele 603-607, wobei die Übernahmeanforderung in Reaktion auf die Feststellung, dass die angeforderte Übernahme regulär ist, zugelassen wird.
• Beispiel 609 schließt den Gegenstand eines der Beispiele 603-607 ein, einschließlich der Blockierung der Übernahmeanforderung ansprechend auf die Feststellung, dass die angeforderte Übernahme unsicher ist.
• Beispiel 610 umfasst den Gegenstand eines der Beispiele 603-609, wobei die Bestimmung, ob die angeforderte Übernahme unsicher ist, während einer Erfassungs-/Wahrnehmungsphase einer autonomen Fahrpipeline durchgeführt wird.
• Beispiel 611 umfasst den Gegenstand eines der Beispiele 603-609, wobei die Blockierung der angeforderten Übernahme während einer Handlungs-/Kontrollphase einer autonomen Fahrpipeline durchgeführt wird.
• Beispiel 612 umfasst den Gegenstand von Beispiel 605, wobei die Änderung der autonomen Betriebsart während einer Planungsphase einer autonomen Fahrpipeline durchgeführt wird.
• Beispiel 613 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 603-612.
• Beispiel 614 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun durch ein Steuersystem eines autonomen Fahrzeugs das autonome Fahrzeug in einem autonomen Betriebsmodus auf der Grundlage von Sensordaten zu betreiben, die von einer Mehrzahl von mit dem autonomen Fahrzeug gekoppelten Sensoren erhalten werden; durch das Steuersystem des autonomen Fahrzeugs eine Übernahmeanforderung durch einen Insasse des autonomen Fahrzeugs zu erkennen; durch das Steuersystem des autonomen Fahrzeugs auf der Grundlage der Sensordaten zu bestimmen, ob die angeforderte Übernahme sicher ist; und die angeforderte Übernahme ansprechend auf eine Bestimmung, dass die angeforderte Übernahme unsicher ist, zu blockieren.
• Beispiel 615 umfasst den Gegenstand von Beispiel 614, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, den autonomen Betriebsmodus ansprechend auf die Feststellung, dass die Anforderungsübernahme unsicher ist, zu ändern.
• Beispiel 616 umfasst den Gegenstand von Beispiel 615, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine ferner veranlassen, den Insassen ansprechend auf die Bestimmung zur Eingabe aufzufordern und ansprechend auf die Aufforderung eine Eingabe von dem Insassen zu empfangen, wobei die Änderung der autonomen Betriebsart auf der empfangenen Eingabe basiert.
• Beispiel 617 umfasst den Gegenstand von Beispiel 614, wobei die Mehrzahl von Sensoren, die mit dem autonomen Fahrzeug gekoppelt sind, Innenraumsensoren im Inneren des autonomen Fahrzeugs umfassen, und die Bestimmung, ob die angeforderte Übernahme sicher ist, auf Sensordaten basiert, die von den Innenraumsensoren empfangen werden.
• Beispiel 618 umfasst den Gegenstand von Beispiel 617, wobei die Innensensoren eine oder mehrere Kameras und ein Mikrofon umfassen.
• Beispiel 619 umfasst den Gegenstand eines der Beispiele 614-618, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, die Übernahmeanforderung ansprechend auf die Feststellung, dass die angeforderte Übernahme regulär ist, zuzulassen.
• Beispiel 620 umfasst den Gegenstand eines der Beispiele 614-618, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, die Übernahmeanforderung ansprechend auf die Feststellung, dass die angeforderte Übernahme unsicher ist, zu blockieren.
• Beispiel 621 umfasst den Gegenstand eines der Beispiele 614-620, wobei die Bestimmung, ob die angeforderte Übernahme unsicher ist, während einer Erfassungs-/Wahrnehmungsphase einer autonomen Fahrpipeline durchgeführt wird.
• Beispiel 622 umfasst den Gegenstand eines der Beispiele 614-620, wobei die Blockierung der angeforderten Übernahme während einer Handlungs-/Kontrollphase einer autonomen Fahrpipeline durchgeführt wird.
• Beispiel 623 umfasst den Gegenstand von Beispiel 616, wobei die Änderung der autonomen Betriebsart während einer Planungsphase einer autonomen Fahrpipeline durchgeführt wird.
• Beispiel 624 ist ein Verfahren, das Folgendes umfasst: Überwachen mindestens eines Teilsystems eines autonomen Fahrzeugs durch ein Überwachungssystem; und Auslösen eines Wechsels eines Autonomiegrades des autonomen Fahrzeugs von einem ersten Autonomiegrad zu einem zweiten Autonomiegrad durch das Überwachungssystem, basierend auf der Überwachung des mindestens einen Teilsystems.
• Beispiel 625 umfasst den Gegenstand von Beispiel 624, wobei die Änderung des Autonomiegrades des autonomen Fahrzeugs an ein Fernüberwachungssystem übermittelt wird.
• Beispiel 626 umfasst den Gegenstand eines der Beispiele 624-625, einschließlich der Aufzeichnung eines Verlaufs des Autonomiegrades und eines Sensorstatus über die Zeit.
• Beispiel 627 umfasst den Gegenstand eines der Beispiele 624-626, wobei das mindestens eine Teilsystem ein Sensor-Teilsystem umfasst und die Änderung des Autonomiegrades zumindest teilweise auf einer Änderung des Sensor-Teilsystems beruht.
• Beispiel 628 umfasst den Gegenstand eines oder mehrerer der Beispiele 624 bis 627, wobei das mindestens eine Teilsystem ein Planungs-Teilsystem umfasst und die Änderung des Autonomiegrades zumindest teilweise auf einer Änderung des Planungs-Teilsystems beruht.
• Beispiel 628 umfasst den Gegenstand eines oder mehrerer der Beispiele 624-628, wobei das mindestens eine Teilsystem ein Ausführungs-Teilsystem umfasst und die Änderung des Autonomiegrades zumindest teilweise auf einer Änderung des Ausführungs-Teilsystems beruht.
• Beispiel 630 umfasst den Gegenstand eines oder mehrerer der Beispiele 624-629, wobei das Überwachungssystem die Funktionssicherheit des mindestens einen Teilsystems überwachen soll.
• Beispiel 631 umfasst den Gegenstand eines oder mehrerer der Beispiele 624-630, wobei das umfassende kognitive Überwachungssystem die Qualitätssicherung des mindestens einen Teilsystems überwacht.
• Beispiel 632 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 624-631.
• Beispiel 633 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, durch ein Überwachungssystem mindestens ein Teilsystem eines autonomen Fahrzeugs zu überwachen; und durch das Überwachungssystem eine Änderung eines Autonomiegrades des autonomen Fahrzeugs von einem ersten Autonomiegrad zu einem zweiten Autonomiegrad auf der Grundlage der Überwachung des mindestens einen Teilsystems einzuleiten.
• Beispiel 634 umfasst den Gegenstand von Beispiel 633, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, die Änderung des Autonomiegrades des autonomen Fahrzeugs an ein Fernüberwachungssystem zu übermitteln.
• Beispiel 635 umfasst den Gegenstand eines der Beispiele 633 bis 634, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine außerdem veranlassen, eine Historie des Autonomiegrades und einen Sensorstatus über die Zeit aufzuzeichnen.
• Beispiel 636 umfasst den Gegenstand eines der Beispiele 633-635, wobei das mindestens eine Teilsystem ein Sensor-Teilsystem umfasst und die Änderung des Autonomiegrades zumindest teilweise auf einer Änderung des Sensor-Teilsystems beruht.
• Beispiel 637 umfasst den Gegenstand eines oder mehrerer der Beispiele 633-636, wobei das mindestens eine Teilsystem ein Planungs-Teilsystem umfasst und die Änderung des Autonomiegrades zumindest teilweise auf einer Änderung des Planungs-Teilsystems beruht.
• Beispiel 638 umfasst den Gegenstand eines oder mehrerer der Beispiele 633-637, wobei das mindestens eine Teilsystem ein Ausführungs-Teilsystem umfasst und die Änderung des Autonomiegrades zumindest teilweise auf einer Änderung des Ausführungs-Teilsystems beruht.
• Beispiel 639 umfasst den Gegenstand eines oder mehrerer der Beispiele 633-638, wobei das Überwachungssystem die Funktionssicherheit des mindestens einen Teilsystems überwachen soll.
• Beispiel 640 umfasst den Gegenstand eines oder mehrerer der Beispiele 633-639, wobei das umfassende kognitive Überwachungssystem die Qualitätssicherung des mindestens einen Teilsystems überwacht.
• Beispiel 641 ist ein Verfahren, das Folgendes umfasst: Bestimmen eines Systemfehlers eines autonomen Fahrzeugs; Bestimmen, dass ein Autonomiegrad des autonomen Fahrzeugs auf einen ersten Grad reduziert werden kann, der keine Übernahme durch den Fahrer erfordert; Warnen des Fahrers, dass der Autonomiegrad auf den ersten Grad reduziert werden wird; und Reduzieren des Autonomiegrades auf den ersten Grad.
• Beispiel 642 umfasst den Gegenstand von Beispiel 641, ferner: Feststellen, dass ein zusätzlicher Systemfehler des autonomen Fahrzeugs vorliegt; Feststellen, dass der Autonomiegrad auf einen zweiten Grad reduziert werden kann; Warnen des Fahrers, dass der Autonomiegrad auf den zweiten Grad reduziert werden wird; und Reduzieren des Autonomiegrades auf den zweiten Grad.
• Beispiel 643 umfasst den Gegenstand eines oder mehrerer der Beispiele 641-642, einschließlich der Bestätigung des Eingriffs des Fahrers.
• Beispiel 644 umfasst den Gegenstand von Beispiel 643, wobei die Bestätigung des Eingriffs des Fahrers die Überwachung des Fahrers umfasst.
• Beispiel 645 schließt den Gegenstand eines oder mehrerer der Beispiele 641-644 ein und umfasst ferner: Feststellen, dass ein zusätzlicher Systemfehler des autonomen Fahrzeugs vorliegt; Feststellen, dass die Autonomie des Fahrzeugs deaktiviert werden muss; und Versuchen der Übergabe an den Fahrer in Reaktion auf die Feststellung, dass die Autonomie des Fahrzeugs deaktiviert werden muss.
• Beispiel 646 umfasst den Gegenstand von Beispiel 645, einschließlich der Feststellung, ob die Übergabe erfolgreich war.
• Beispiel 647 umfasst den Gegenstand von Beispiel 646, einschließlich der Deaktivierung der Autonomie des Fahrzeugs, wenn die Übergabe erfolgreich war.
• Beispiel 648 umfasst den Gegenstand von Beispiel 646, einschließlich der Aktivierung eines Notfallsystems, wenn die Weitergabe nicht erfolgreich war.
• Beispiel 649 umfasst den Gegenstand von Beispiel 648, wobei das Notfallsystem das autonome Fahrzeug zu einem sicheren Halt bringen soll.
• Beispiel 650 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Beispiele 641-649.
• Beispiel 651 ist ein nicht-transitorisches, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, einen Systemfehler eines autonomen Fahrzeugs zu bestimmen; zu bestimmen, dass ein Autonomiegrad des autonomen Fahrzeugs auf einen ersten Grad reduziert werden kann, das keine Übernahme durch den Fahrer erfordert; den Fahrer zu warnen, dass der Autonomiegrad auf den ersten Grad reduziert werden wird; und der Autonomiegrad auf den zweiten Grad zu reduzieren.
• Beispiel 652 schließt den Gegenstand von Beispiel 651 ein, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine außerdem veranlassen: festzustellen, dass ein zusätzlicher Systemfehler des autonomen Fahrzeugs vorliegt; festzustellen, dass der Autonomiegrad auf einen zweiten Grad reduziert werden kann; den Fahrer zu warnen, dass der Autonomiegrad auf den zweiten Grad reduziert werden wird; und den Autonomiegrad auf den zweiten Grad zu reduzieren.
• Beispiel 653 schließt den Gegenstand eines oder mehrerer der Beispiele 651-652 ein, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine außerdem veranlassen, den Eingriff des Fahrers zu bestätigen.
• Beispiel 654 umfasst den Gegenstand von Beispiel 653, wobei die Bestätigung des Eingriffs des Fahrers die Überwachung des Fahrers umfasst.
• Beispiel 655 schließt den Gegenstand eines oder mehrerer der Beispiele 651-654 ein, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine ferner veranlassen: festzustellen, dass ein zusätzlicher Systemfehler des autonomen Fahrzeugs vorliegt; festzustellen, dass die Autonomie des Fahrzeugs deaktiviert werden muss; und zu versuchen, ansprechend auf die Feststellung, dass die Autonomie des Fahrzeugs inaktiviert werden muss, an den Fahrer zu übergeben.
• Beispiel 656 schließt den Gegenstand von Beispiel 655 ein, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine außerdem veranlassen, festzustellen, ob die Weitergabe erfolgreich war.
• Beispiel 657 umfasst den Gegenstand von Beispiel 656, wobei die Anweisungen bei ihrer Ausführung die Maschine ferner veranlassen, die Autonomie des Fahrzeugs zu deaktivieren, wenn die Übergabe erfolgreich war.
• Beispiel 658 umfasst den Gegenstand von Beispiel 656, wobei die Anweisungen bei ihrer Ausführung die Maschine außerdem veranlassen, ein Notfallsystem zu aktivieren, wenn die Übergabe nicht erfolgreich war.
• Beispiel 659 umfasst den Gegenstand von Beispiel 658, wobei das Notfallsystem das autonome Fahrzeug zu einem sicheren Halt bringen soll.
• Beispiel 660 ist ein Verfahren, das Folgendes umfasst: Bereitstellen eines extrahierten Merkmals aus Bilddaten für ein Vorhersagemodell erster Klasse und für ein Vorhersagemodell zweiter Klasse; Bestimmen einer Differenz zwischen einer Ausgabe des Vorhersagemodells erster Klasse und einer Ausgabe des Vorhersagemodells zweiter Klasse; und Zuordnen einer Anomalieklasse zu dem extrahierten Merkmal auf der Grundlage der Differenz zwischen der Ausgabe des Vorhersagemodells erster Klasse und der Ausgabe des Vorhersagemodells zweiter Klasse.
• Beispiel 661 umfasst den Gegenstand von Beispiel 660, wobei das Vorhersagemodell der ersten Klasse ein Basisvorhersagemodell ist, das ein neuronales Netzwerk mit Gated Recurrent Unit (GRU) oder Long Short Term Memory networks (LSTM) umfasst.
• Beispiel 662 umfasst den Gegenstand eines der Beispiele 660-661, wobei das Vorhersagemodell der zweiten Klasse auf einem neuronalen LSTM-Netzwerk basiert.
• Beispiel 663 umfasst den Gegenstand eines der Beispiele 660-662, ferner das Zuordnen einer zweiten Anomalieklasse zu einem zweiten extrahierten Merkmal auf der Grundlage einer zweiten Differenz zwischen einer zweiten Ausgabe des Erstklassen-Vorhersagemodells und einer zweiten Ausgabe des Zweitklassen-Vorhersagemodells.
• Beispiel 664 umfasst den Gegenstand eines der Beispiele 660-663, ferner die Bestimmung einer Anomalie-Schwelle während des Trainings des Erstklassen-Vorhersagemodells und des Zweitklassen-Vorhersagemodells auf der Grundlage von Unterschieden zwischen den Ausgaben des Erstklassen-Vorhersagemodells und des Zweitklassen-Vorhersagemodells.
• Beispiel 665 umfasst den Gegenstand eines der Beispiele 660-664, einschließlich der Ausgabe einer Vorhersagekonfidenz, die mit der dem extrahierten Merkmal zugeordneten Anomalieklasse verbunden ist.
• Beispiel 666 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 660-665.
• Beispiel 667 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, ein aus Bilddaten extrahiertes Merkmal einem Vorhersagemodell erster Klasse und einem Vorhersagemodell zweiter Klasse zur Verfügung zu stellen; eine Differenz zwischen einer Ausgabe des Vorhersagemodells erster Klasse und einer Ausgabe des Vorhersagemodells zweiter Klasse zu bestimmen; und dem extrahierten Merkmal auf der Grundlage der Differenz zwischen der Ausgabe des Vorhersagemodells erster Klasse und der Ausgabe des Vorhersagemodells zweiter Klasse eine Anomalieklasse zuzuweisen.
• Beispiel 668 umfasst den Gegenstand von Beispiel 667, wobei das Vorhersagemodell der ersten Klasse ein Basisvorhersagemodell ist, das ein neuronales Netzwerk mit Gated Recurrent Unit (GRU) oder Long Short Term Memory networks (LSTM) umfasst.
• Beispiel 669 umfasst den Gegenstand eines der Beispiele 667-668, wobei das Vorhersagemodell der zweiten Klasse auf einem neuronalen LSTM-Netzwerk basiert.
• Beispiel 670 umfasst den Gegenstand eines der Beispiele 667-669, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, einem zweiten extrahierten Merkmal eine zweite Anomalieklasse zuzuweisen, die auf einer zweiten Differenz zwischen einer zweiten Ausgabe des Vorhersagemodells der ersten Klasse und einer zweiten Ausgabe des Vorhersagemodells der zweiten Klasse basiert.
• Beispiel 671 umfasst den Gegenstand eines der Beispiele 667-670, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, während des Trainings des Vorhersagemodells der ersten Klasse und des Vorhersagemodells der zweiten Klasse auf der Grundlage der Unterschiede zwischen den Ausgaben des Vorhersagemodells der ersten Klasse und des Vorhersagemodells der zweiten Klasse einen Anomalie-Schwellenwert zu bestimmen.
• Beispiel 672 umfasst den Gegenstand eines der Beispiele 667-671, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, eine Vorhersagekonfidenz auszugeben, die mit der dem extrahierten Merkmal zugewiesenen Anomalieklasse verbunden ist.
• Beispiel 673 ist ein Verfahren zur Beschränkung des Autonomiegrades eines Fahrzeugs auf einem Teil einer Straße, das Folgendes umfasst: Bestimmen einer Sicherheitsbewertung für ein Fahrzeug; Bestimmen einer Straßenbewertung für mindestens einen Teil einer Straße; Vergleichen der Straßenbewertung mit der Sicherheitsbewertung; und Bestimmen des akzeptablen Autonomiegrades des Fahrzeugs auf dem mindestens einen Teil der Straße.
• Beispiel 674 umfasst den Gegenstand von Beispiel 673, wobei das Bestimmen des akzeptablen Autonomiegrades des Fahrzeugs das Bestimmen umfasst, das autonome Fahren des Fahrzeugs zu erlauben, wenn die Sicherheitsbewertung größer oder gleich der Straßenbewertung ist.
• Beispiel 675 umfasst den Gegenstand eines oder mehrerer der Beispiele 673-674, wobei die Sicherheitsbewertung anhand mehrerer gewichteter Elemente bestimmt wird.
• Beispiel 676 umfasst den Gegenstand eines oder mehrerer der Beispiele 673-675, wobei die Straßenbewertung anhand mehrerer gewichteter Elemente bestimmt wird.
• Beispiel 677 umfasst den Gegenstand eines oder mehrerer der Beispiele 673 bis 676, wobei die Straßenbewertung dynamisch berechnet wird, um den aktuellen Zustand des mindestens einen Teils der Straße zu berücksichtigen.
• Beispiel 678 umfasst den Gegenstand eines oder mehrerer der Beispiele 673-677, wobei die Sicherheitsbewertung dynamisch berechnet wird, um den aktuellen Zustand des Fahrzeugs zu berücksichtigen.
• Beispiel 679 umfasst den Gegenstand eines oder mehrerer der Beispiele 673 bis 678, einschließlich der Anzeige der Straßenbewertung für mindestens einen Teil einer Straße auf einer Karten-Benutzeroberfläche.
• Beispiel 680 umfasst den Gegenstand eines oder mehrerer der Beispiele 673-679, wobei die Straßenbewertung unter Verwendung eines gewichteten Wertes für die Wetterbedingungen bestimmt wird.
• Beispiel 681 umfasst den Gegenstand eines oder mehrerer der Beispiele 673-680, wobei die Straßenbewertung unter Verwendung eines gewichteten Wertes für den Zustand des mindestens einen Teils der Straße bestimmt wird.
• Beispiel 682 umfasst den Gegenstand eines oder mehrerer der Beispiele 673-681, wobei die Sicherheitsbewertung anhand eines gewichteten Wertes für die Sensoren des Fahrzeugs ermittelt wird.
• Beispiel 683 umfasst den Gegenstand eines oder mehrerer der Beispiele 673-682, wobei die Sicherheitsbewertung unter Verwendung eines gewichteten Wertes für einen oder mehrere vom Fahrzeug implementierte autonome Fahralgorithmen bestimmt wird.
• Beispiel 684 umfasst den Gegenstand eines oder mehrerer der Beispiele 673-683, wobei die Berechnung der Sicherheitsbewertung die Durchführung von Tests am Fahrzeug umfasst.
• Beispiel 685 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Beispiele 673-684.
• Beispiel 686 ist ein nicht-transitorisches, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: eine Sicherheitsbewertung für ein Fahrzeug zu bestimmen; eine Straßenbewertung für mindestens einen Abschnitt einer Straße zu bestimmen; die Straßenbewertung mit der Sicherheitsbewertung zu vergleichen; und den akzeptablen Autonomiegrad des Fahrzeugs auf dem mindestens einen Abschnitt der Straße zu bestimmen.
• Beispiel 687 umfasst den Gegenstand von Beispiel 686, wobei das Bestimmen des akzeptablen Autonomiegrades des Fahrzeugs das Bestimmen umfasst, das autonome Fahren des Fahrzeugs zu erlauben, wenn die Sicherheitsbewertung größer oder gleich der Straßenbewertung ist.
• Beispiel 688 umfasst den Gegenstand eines oder mehrerer der Beispiele 686-687, wobei die Sicherheitsbewertung anhand mehrerer gewichteter Elemente bestimmt wird.
• Beispiel 689 umfasst den Gegenstand eines oder mehrerer der Beispiele 686-688, wobei die Straßenbewertung unter Verwendung mehrerer gewichteter Elemente bestimmt wird.
• Beispiel 690 umfasst den Gegenstand eines oder mehrerer der Beispiele 686-689, wobei die Straßenbewertung dynamisch berechnet wird, um den aktuellen Zustand des mindestens einen Teils der Straße zu berücksichtigen.
• Beispiel 691 umfasst den Gegenstand eines oder mehrerer der Beispiele 686-690, wobei die Sicherheitsbewertung dynamisch berechnet wird, um den aktuellen Zustand des Fahrzeugs zu berücksichtigen.
• Beispiel 692 umfasst den Gegenstand eines oder mehrerer der Beispiele 686 bis 691, wobei die Anweisungen bei ihrer Ausführung ferner die Maschine veranlassen, die Straßenbewertung für mindestens einen Teil einer Straße auf einer Kartenbenutzerschnittstelle anzuzeigen.
• Beispiel 693 umfasst den Gegenstand eines oder mehrerer der Beispiele 686-692, wobei die Straßenbewertung unter Verwendung eines gewichteten Wertes für die Wetterbedingungen bestimmt wird.
• Beispiel 694 umfasst den Gegenstand eines oder mehrerer der Beispiele 686-693, wobei die Straßenbewertung unter Verwendung eines gewichteten Wertes für den Zustand des mindestens einen Teils der Straße bestimmt wird.
• Beispiel 695 umfasst den Gegenstand eines oder mehrerer der Beispiele 686-694, wobei die Sicherheitsbewertung unter Verwendung eines gewichteten Wertes für die Sensoren des Fahrzeugs bestimmt wird.
• Beispiel 696 umfasst den Gegenstand eines oder mehrerer der Beispiele 686-695, wobei die Sicherheitsbewertung unter Verwendung eines gewichteten Wertes für einen oder mehrere vom Fahrzeug implementierte autonome Fahralgorithmen bestimmt wird.
• Beispiel 697 umfasst den Gegenstand eines oder mehrerer der Beispiele 686-696, wobei die Berechnung der Sicherheitsbewertung die Durchführung von Tests am Fahrzeug umfasst.
• Beispiel 698 ist ein Verfahren, wobei das Verfahren umfasst: empfangen eines Bildes, das von einer mit einem Fahrzeug verbundenen Bilderfassungsvorrichtung erfasst wurde; Erkennen eines Gesichts in dem erfassten Bild; Erzeugen eines Eingabebildes für ein erstes neuronales Netzwerk eines Generative Adversarial Network (GAN), wobei das Eingabebild das in dem erfassten Bild erkannte Gesicht abbildet; erzeugen eines unkenntlich gemachten Bildes, das zumindest teilweise auf der Anwendung des ersten neuronalen Netzwerks auf das Eingangsbild basiert, wobei ein Blickattribut des in dem Eingangsbild dargestellten Gesichts in dem unkenntlich gemachten Bild umfassen ist, und wobei ein oder mehrere andere Attribute des in dem Eingangsbild dargestellten Gesichts in dem unkenntlich gemachten Bild modifiziert sind.
• Beispiel 699 umfasst den Gegenstand von Beispiel 698, wobei das erste neuronale Netzwerk ein generatives Modell ist und das GAN ein zweites neuronales Netzwerk umfasst, das ein diskriminatives Modell ist.
• Beispiel 700 umfasst den Gegenstand eines der Beispiele 698-699, wobei das zweite neuronale Netzwerk ein neuronales Faltungsnetzwerk ist, um die vom ersten neuronalen Netzwerk erzeugten unkenntlich gemachten Bilder als echt oder gefälscht zu klassifizieren.
• Beispiel 701 umfasst den Gegenstand eines der Beispiele 698-700, wobei das erste neuronale Netzwerk ein inverses neuronales Netzwerk ist, das das unkenntlich gemachte Bild erzeugt.
• Beispiel 702 umfasst den Gegenstand von einem der Beispiele 698-701, ferner das Schätzen von Positionen einer oder mehrerer Gesichtskomponenten des Gesichts, die in dem erfassten Bild erkannt werden, wobei das Eingabebild zumindest teilweise auf der Grundlage des erkannten Bildes und der Positionen der einen oder mehreren Gesichtskomponenten erzeugt wird.
• Beispiel 703 umfasst den Gegenstand eines der Beispiele 698-702, wobei das eine oder die mehreren anderen Attribute, die in dem unkenntlich gemachten Bild verändert werden, Alter und Geschlecht umfassen.
• Beispiel 704 umfasst den Gegenstand eines der Beispiele 698-702, wobei das eine oder die mehreren anderen Attribute, die in dem unkenntlich gemachten Bild verändert werden, aus einer Gruppe von Attributen ausgewählt werden, die Alter, Geschlecht, Haarfarbe, Glatze, Pony, Brille, Make-up, Hautfarbe und Mundausdruck umfassen.
• Beispiel 705 umfasst den Gegenstand eines der Beispiele 698-704, wobei das erste neuronale Netzwerk das unkenntlich gemachte Bild zumindest teilweise auf der Grundlage einer Zieldomäne erzeugt, die das eine oder die mehreren anderen Attribute angibt, die in dem in dem erfassten Bild erkannten Gesicht zu ändern sind.
• Beispiel 706 umfasst den Gegenstand eines der Beispiele 705, wobei das GAN-Modell mit der Zieldomäne vorausgebildet ist, basierend darauf, dass das GAN-Modell unkenntlich gemachte Bilder aus Testbildern erzeugt und ein Gesichtserkennungsmodell nicht in der Lage ist, mindestens eine Schwellenanzahl der unkenntlich gemachten Bilder zu identifizieren.
• Beispiel 707 umfasst den Gegenstand eines der Beispiele 698-706, wobei ein Emotionsattribut in dem Gesicht, das in dem erfassten Bild erkannt wurde, in dem unkenntlich gemachten Bild umfassen ist.
• Beispiel 708 umfasst den Gegenstand von Beispiel 707, ferner das Senden des unkenntlich gemachten Bildes an ein mit dem Fahrzeug verbundenes Datenerfassungssystem, wobei das Datenerfassungssystem eine Emotion basierend auf dem Emotionsattribut in dem unkenntlich gemachten Bild erkennen soll.
• Beispiel 709 umfasst den Gegenstand eines der Beispiele 698-708, wobei ferner das unkenntlich gemachte Bild einer Computer-Vision-Anwendung des Fahrzeugs zur Verfügung gestellt wird, wobei die Computer-Vision-Anwendung einen Blick auf der Grundlage eines Blickattributs in dem unkenntlich gemachten Bild erkennen und eine Flugbahn eines in dem unkenntlich gemachten Bild dargestellten Menschen auf der Grundlage des erkannten Blicks identifizieren soll.
• Beispiel 710 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 698-709.
• Beispiel 711 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun empfangen eines Bildes, das von einer mit einem Fahrzeug verbundenen Bilderfassungsvorrichtung erfasst wurde; Erkennen eines Gesichts in dem erfassten Bild; Erzeugen eines Eingabebildes für ein erstes neuronales Netzwerk eines Generative Adversarial Network (GAN), wobei das Eingabebild das in dem erfassten Bild erkannte Gesicht darstellt; erzeugen eines unkenntlich gemachten Bildes, das zumindest teilweise auf der Anwendung des ersten neuronalen Netzwerks auf das Eingangsbild basiert, wobei ein Blickattribut des in dem Eingangsbild dargestellten Gesichts in dem unkenntlich gemachten Bild umfassen ist, und wobei ein oder mehrere andere Attribute des in dem Eingangsbild dargestellten Gesichts in dem unkenntlich gemachten Bild modifiziert sind.
• Beispiel 712 umfasst den Gegenstand von Beispiel 711, wobei das erste neuronale Netzwerk ein generatives Modell ist und das GAN ein zweites neuronales Netzwerk umfasst, das ein diskriminatives Modell ist.
• Beispiel 713 umfasst den Gegenstand eines der Beispiele 1-712, wobei das zweite neuronale Netzwerk ein neuronales Faltungsnetzwerk ist, um die vom ersten neuronalen Netzwerk erzeugten unkenntlich gemachten Bilder als echt oder gefälscht zu klassifizieren.
• Beispiel 714 umfasst den Gegenstand eines der Beispiele 711-713, wobei das erste neuronale Netzwerk ein inverses neuronales Netzwerk ist, das das unkenntlich gemachte Bild erzeugt.
• Beispiel 715 umfasst den Gegenstand eines der Beispiele 711 bis 714, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, die Positionen einer oder mehrerer Gesichtskomponenten des Gesichts zu schätzen, die in dem erfassten Bild erkannt wurden, wobei das Eingabebild zumindest teilweise auf derGrundlage des erkannten Bildes und der Positionen der einen oder mehreren Gesichtskomponenten erzeugt wird.
• Beispiel 716 umfasst den Gegenstand eines der Beispiele 711-715, wobei das eine oder die mehreren anderen Attribute, die in dem unkenntlich gemachten Bild verändert werden, Alter und Geschlecht umfassen.
• Beispiel 717 umfasst den Gegenstand eines der Beispiele 711-715, wobei das eine oder die mehreren anderen Attribute, die in dem unkenntlich gemachten Bild verändert werden, aus einer Gruppe von Attributen ausgewählt werden, die Alter, Geschlecht, Haarfarbe, Glatze, Pony, Brille, Make-up, Hautfarbe und Mundausdruck umfassen.
• Beispiel 718 umfasst den Gegenstand eines der Beispiele 711-717, wobei das erste neuronale Netzwerk das unkenntlich gemachte Bild zumindest teilweise auf der Grundlage einer Zieldomäne erzeugt, die das eine oder die mehreren anderen Attribute angibt, die in dem in dem erfassten Bild erkannten Gesicht zu ändern sind.
• Beispiel 719 umfasst den Gegenstand eines der Beispiele 718, wobei das GAN-Modell mit der Zieldomäne vorausgebildet ist, basierend darauf, dass das GAN-Modell unkenntlich gemachte Bilder aus Testbildern erzeugt und ein Gesichtserkennungsmodell nicht in der Lage ist, mindestens eine Schwellenanzahl der unkenntlich gemachten Bilder zu identifizieren.
• Beispiel 720 umfasst den Gegenstand eines der Beispiele 711-719, wobei ein Emotionsattribut in dem Gesicht, das in dem erfassten Bild erkannt wurde, in dem unkenntlich gemachten Bild umfassen ist.
• Beispiel 721 umfasst den Gegenstand von Beispiel 720, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, das unkenntlich gemachte Bild an ein mit dem Fahrzeug verbundenes Datenerfassungssystem zu senden, wobei das Datenerfassungssystem eine Emotion auf der Grundlage des Emotionsattributs in dem unkenntlich gemachten Bild erkennen soll.
• Beispiel 722 umfasst den Gegenstand eines der Beispiele 711-721, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, das unkenntlich gemachte Bild einer Computer-Vision-Anwendung des Fahrzeugs zur Verfügung zu stellen, wobei die Computer-Vision-Anwendung einen Blick auf der Grundlage eines Blickattributs in dem unkenntlich gemachten Bild erkennen und eine Flugbahn eines in dem unkenntlich gemachten Bild dargestellten Menschen auf der Grundlage des erkannten Blicks identifizieren soll.
• Beispiel 723 ist ein Verfahren, das Folgendes umfasst: empfangen eines Datensatzes, der von einem Fahrzeug gesammelte Daten umfasst, wobei ein oder mehrere Tags mit dem Datensatz assoziiert sind; Bestimmen einer ersten Richtlinie, die auf den Datensatz anzuwenden ist, basierend auf dem einen oder den mehreren Tags; Bestimmen, ob die erste Richtlinie als eine träge Richtlinie bezeichnet wird; basierend auf dem Bestimmen, dass die erste Richtlinie als eine träge Richtlinie bezeichnet ist, Markieren des Datensatzes für eine bedarfsgesteuerte Verarbeitung, ohne die erste Richtlinie auf den Datensatz anzuwenden; im Anschluss an das Markieren des Datensatzes für eine bedarfsgesteuerte Verarbeitung, Empfangen einer ersten Anforderung für den Datensatz; und Anwenden der ersten Richtlinie auf den Datensatz ansprechend auf den Empfang der ersten Anforderung für den Datensatz.
• Beispiel 724 umfasst den Gegenstand von Beispiel 723, wobei die Anwendung der ersten Richtlinie auf den Datensatz mindestens eines der folgenden Elemente umfasst: Unkenntlichmachen von einem oder mehreren Gesichtern in einem Bild in dem Datensatz, Unkenntlichmachen von einem oder mehreren Nummernschildern in einem Bild in dem Datensatz, Anonymisieren von persönlichen Identifizierungsinformationen in dem Datensatz oder Modifizieren von Standortinformationen in dem Datensatz.
• Beispiel 725 umfasst den Gegenstand eines der Beispiele 723 bis 724 und umfasst ferner: Bestimmen eines geografischen Standorts des Fahrzeugs; und Zuordnen eines Tags zu dem Datensatz, wobei das Tag Informationen umfasst, die den geografischen Standort des Fahrzeugs angeben.
• Beispiel 726 umfasst den Gegenstand eines der Beispiele 723-725, ferner: Verwendung eines Maschinelles-Lernen-Modells zur Identifizierung mindestens eines der einen oder mehreren Tags, die dem Datensatz zugeordnet werden sollen.
• Beispiel 727 umfasst den Gegenstand eines der Beispiele 723-726, wobei der Datensatz in einer Richtliniendurchsetzungs-Engine im Fahrzeug oder in einem vom Fahrzeug entfernten Cloud-Verarbeitungssystem empfangen wird.
• Beispiel 728 umfasst den Gegenstand von einem der Beispiele 723-727, ferner umfassend: Bestimmen einer zweiten Richtlinie, die auf den Datensatz anzuwenden ist, basierend auf dem einen oder den mehreren Tags; Bestimmen, ob die zweite Richtlinie als eine träge Richtlinie bezeichnet ist; und basierend auf der Bestimmung, dass die zweite Richtlinie nicht als eine träge Richtlinie bezeichnet ist, Anwenden der zweiten Richtlinie auf den Datensatz.
• Beispiel 729 umfasst den Gegenstand von Beispiel 728, wobei die Anwendung der zweiten Richtlinie auf den Datensatz das Unkenntlichmachen, Anonymisieren oder Modifizieren mindestens einiger Daten in dem Datensatz umfasst.
• Beispiel 730 umfasst den Gegenstand eines der Beispiele 723-729, das ferner Folgendes umfasst: Empfangen eines zweiten Datensatzes, der zweite vom Fahrzeug gesammelte Daten umfasst, wobei dem zweiten Datensatz ein oder mehrere zweite Tags zugeordnet sind; Bestimmen einer zweiten Richtlinie, die auf den zweiten Datensatz anzuwenden ist, auf der Grundlage des einen oder der mehreren zweiten Tags, wobei die zweite Richtlinie als eine träge Richtlinie bezeichnet wird; und auf der Grundlage der Feststellung, dass eine kontextbezogene Richtlinie auf den zweiten Datensatz anwendbar ist, Überschreiben der Bezeichnung der trägen Richtlinie und Anwenden der kontextbezogenen Richtlinie auf den zweiten Datensatz.
• Beispiel 731 umfasst den Gegenstand von Beispiel 730, wobei die kontextbezogene Richtlinie mindestens eine von der zweiten Richtlinie geforderte Aktion umfasst.
• Beispiel 732 umfasst den Gegenstand von einem der Beispiele 723-731, weiterhin umfassend: basierend auf dem Empfangen der ersten Anfrage für den Datensatz, Bestimmen eines aktuellen Standorts des Fahrzeugs; Bestimmen, ob der aktuelle Standort des Fahrzeugs mit anderen Vorschriften verbunden ist als ein früherer Standort, der mit dem Datensatz verbunden ist; basierend auf dem Bestimmen, dass der aktuelle Standort des Fahrzeugs mit anderen Vorschriften verbunden ist, Anbringen einer aktualisierten Kennzeichnung an den Datensatz, wobei die aktualisierte Kennzeichnung Informationen umfasst, die den aktuellen Standort des Fahrzeugs anzeigen; Bestimmen, dass eine neue Richtlinie auf den Datensatz anzuwenden ist, zumindest teilweise basierend auf der aktualisierten Kennzeichnung; und Anwenden der neuen Richtlinie auf den Datensatz.
• Beispiel 733 umfasst den Gegenstand von einem der Beispiele 723-732, ferner umfassend: empfangen eines dritten Datensatzes, der dritte Daten umfasst, die von dem Fahrzeug gesammelt wurden, wobei ein oder mehrere dritte Tags mit dem dritten Datensatz assoziiert sind; Bestimmen einer dritten Richtlinie, die auf den dritten Datensatz anzuwenden ist, basierend auf dem einen oder den mehreren dritten Tags; und basierend auf dem Bestimmen, dass die dritte Richtlinie nicht als eine faule Richtlinie bezeichnet ist, Anwenden der dritten Richtlinie auf den dritten Datensatz; und Markieren des dritten Datensatzes als richtlinienkonform, basierend auf der Bestimmung, dass keine auf den dritten Datensatz anzuwendende Richtlinie als eine „Lazy Policy“ bezeichnet wird, und auf der Anwendung jeder Richtlinie, die als auf den dritten Datensatz anwendbar bestimmt wurde, auf den dritten Datensatz.
• Beispiel 734 umfasst den Gegenstand von einem der Beispiele 723-733, ferner umfassend: Empfangen einer zweiten Anforderung für den Datensatz im Anschluss an den Empfang der ersten Anforderung für den Datensatz; und Anwenden einer vierten Richtlinie auf den Datensatz ansprechend auf den Empfang der zweiten Anforderung für den Datensatz, wobei das eine oder die mehreren Tags mit der vierten Richtlinie ansprechend auf eine auf die Daten in dem Datensatz anwendbare Regeländerung verbunden sind.
• Beispiel 735 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 723-734.
• Beispiel 736 ist ein nicht-transitorisches, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, Folgendes zu tun empfangen eines Datensatzes, der von einem Fahrzeug gesammelte Daten umfasst, wobei ein oder mehrere Tags mit dem Datensatz assoziiert sind; Bestimmen einer ersten Richtlinie, die auf den Datensatz anzuwenden ist, basierend auf dem einen oder den mehreren Tags; Bestimmen, ob die erste Richtlinie als eine „Lazy Policy“ bezeichnet ist; auf der Grundlage der Feststellung, dass die erste Richtlinie als eine träge Richtlinie bezeichnet ist, den Datensatz für eine bedarfsgesteuerte Verarbeitung markieren, ohne die erste Richtlinie auf den Datensatz anzuwenden; im Anschluss an die Markierung des Datensatzes für eine bedarfsgesteuerte Verarbeitung eine erste Anforderung für den Datensatz empfangen; und die erste Richtlinie auf den Datensatz ansprechend auf den Empfang der ersten Anforderung für den Datensatz anwenden.
• Beispiel 737 umfasst den Gegenstand von Beispiel 736, wobei die Anwendung der ersten Richtlinie auf den Datensatz mindestens eines der folgenden Elemente umfasst: Unkenntlichmachen von einem oder mehreren Gesichtern in einem Bild in dem Datensatz, Unkenntlichmachen von einem oder mehreren Nummernschildern in einem Bild in dem Datensatz, Anonymisieren von persönlichen Identifizierungsinformationen in dem Datensatz oder Modifizieren von Standortinformationen in dem Datensatz.
• Beispiel 738 umfasst den Gegenstand eines der Beispiele 736-737, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine ferner veranlassen, einen geografischen Standort des Fahrzeugs zu bestimmen und dem Datensatz ein Etikett zuzuordnen, wobei das Etikett Informationen umfasst, die den geografischen Standort des Fahrzeugs angeben.
• Beispiel 739 umfasst den Gegenstand eines der Beispiele 736 bis 738, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, ein maschinelles Lernmodell zu verwenden, um mindestens eines der einen oder mehreren Tags zu identifizieren, die dem Datensatz zugeordnet werden sollen.
• Beispiel 740 umfasst den Gegenstand eines der Beispiele 736 bis 739, wobei der Datensatz von einer Richtliniendurchsetzungs-Engine in einem Fahrzeug oder einem vom Fahrzeug entfernten Cloud-Verarbeitungssystem empfangen wird.
• Beispiel 741 umfasst den Gegenstand eines der Beispiele 736-740, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine ferner veranlassen, eine zweite Richtlinie zu bestimmen, die auf den Datensatz anzuwenden ist, basierend auf dem einen oder den mehreren Tags; zu bestimmen, ob die zweite Richtlinie als eine träge Richtlinie bezeichnet wird; und basierend auf der Bestimmung, dass die zweite Richtlinie nicht als eine träge Richtlinie bezeichnet wird, die zweite Richtlinie auf den Datensatz anzuwenden.
• Beispiel 742 umfasst den Gegenstand von Beispiel 741, wobei die Anwendung der zweiten Richtlinie auf den Datensatz das Unkenntlichmachen, Anonymisieren oder Modifizieren mindestens einiger Daten in dem Datensatz umfasst.
• Beispiel 743 umfasst den Gegenstand eines der Beispiele 736-742, wobei die Anweisungen bei ihrer Ausführung die Maschine ferner veranlassen, Folgendes zu tun empfangen eines zweiten Datensatzes, der zweite vom Fahrzeug gesammelte Daten umfasst, wobei dem zweiten Datensatz ein oder mehrere zweite Tags zugeordnet sind; Bestimmen einer zweiten Richtlinie, die auf den zweiten Datensatz anzuwenden ist, auf der Grundlage des einen oder der mehreren zweiten Tags, wobei die zweite Richtlinie als eine träge Richtlinie bezeichnet ist; und auf der Grundlage der Bestimmung, dass eine kontextbezogene Richtlinie auf den zweiten Datensatz anwendbar ist, Aufheben der Bezeichnung der trägen Richtlinie und Anwenden der kontextbezogenen Richtlinie auf den zweiten Datensatz.
• Beispiel 744 umfasst den Gegenstand von Beispiel 743, wobei die kontextbezogene Richtlinie mindestens eine von der zweiten Richtlinie geforderte Aktion umfasst.
• Beispiel 745 schließt den Gegenstand eines der Beispiele 736-744 ein, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine außerdem veranlassen, Folgendes zu tun auf der Grundlage des Empfangs der ersten Anforderung für den Datensatz einen aktuellen Standort des Fahrzeugs zu bestimmen; zu bestimmen, ob der aktuelle Standort des Fahrzeugs mit anderen Vorschriften verbunden ist als ein früherer Standort, der mit dem Datensatz verbunden ist; auf der Grundlage der Bestimmung, dass der aktuelle Standort des Fahrzeugs mit anderen Vorschriften verbunden ist, ein aktualisiertes Etikett an den Datensatz anzuhängen, wobei das aktualisierte Etikett Informationen umfasst, die den aktuellen Standort des Fahrzeugs angeben; zu bestimmen, dass eine neue Richtlinie auf den Datensatz anzuwenden ist, zumindest teilweise auf der Grundlage des aktualisierten Etiketts; und die neue Richtlinie auf den Datensatz anzuwenden.
• Beispiel 746 umfasst den Gegenstand eines der Beispiele 736-745, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine außerdem veranlassen, Folgendes zu tun empfangen eines dritten Datensatzes, der dritte Daten umfasst, die von dem Fahrzeug gesammelt wurden, wobei ein oder mehrere dritte Tags mit dem dritten Datensatz assoziiert sind; Bestimmen einer dritten Richtlinie, die auf den dritten Datensatz anzuwenden ist, basierend auf dem einen oder den mehreren dritten Tags; und basierend auf dem Bestimmen, dass die dritte Richtlinie nicht als eine faule Richtlinie bezeichnet ist, Anwenden der dritten Richtlinie auf den dritten Datensatz; und Markieren des dritten Datensatzes als richtlinienkonform, basierend auf der Feststellung, dass keine auf den dritten Datensatz anzuwendende Richtlinie als „Lazy Policy“ bezeichnet ist, und auf der Anwendung jeder Richtlinie, die als auf den dritten Datensatz anwendbar bestimmt wurde, auf den dritten Datensatz.
• Beispiel 747 umfasst den Gegenstand von einem der Beispiele 736-746, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen,:
  • empfangen einer zweiten Anforderung für den Datensatz nach dem Empfang der ersten Anforderung für den Datensatz; und Anwenden einer vierten Richtlinie auf den Datensatz ansprechend auf den Empfang der zweiten Anforderung für den Datensatz, wobei die eine oder die mehreren Markierungen mit der vierten Richtlinie ansprechend auf eine auf die Daten in dem Datensatz anwendbare Regeländerung verbunden sind.
• Beispiel 748 ist ein Verfahren, das Folgendes umfasst: Empfangen von Sensordaten von einem mit einem autonomen Fahrzeug gekoppelten Sensor; Anwenden einer digitalen Signatur auf die Sensordaten; Hinzufügen eines neuen Blocks zu einer blockbasierten Topologie, wobei der neue Block die Sensordaten und die digitale Signatur umfasst; Verifizieren der digitalen Signatur; und Übermitteln des Blocks an eine Logikeinheit des autonomen Fahrzeugs auf der Grundlage der verifizierten digitalen Signatur.
• Beispiel 749 umfasst den Gegenstand von Beispiel 748, wobei die blockbasierte Topologie eine erlaubnisfreie Blockchain ist.
• Beispiel 750 umfasst den Gegenstand von Beispiel 748, wobei die digitale Signatur auf einem elliptischen Kurven-Kryptographieprotokoll (ECC) basiert.
• Beispiel 751 umfasst den Gegenstand eines der Beispiele 748-750, wobei die Verifizierung des Blocks die Verifizierung eines Zeitstempels der Sensordaten unter Verwendung einer Zeitbeschränkung eines Konsensprotokolls umfasst.
• Beispiel 752 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 748-751.
• Beispiel 753 ist ein Verfahren, das Folgendes umfasst: Empfangen eines Blocks einer blockbasierten Topologie in einem ersten autonomen Fahrzeug, wobei der Block Sensordaten von einem mit einem zweiten autonomen Fahrzeug gekoppelten Sensor und eine den Sensordaten zugeordnete digitale Signatur umfasst; Verifizieren der digitalen Signatur; und Übermitteln des Blocks an eine Logikeinheit des ersten autonomen Fahrzeugs ansprechend auf die Verifizierung der digitalen Signatur.
• Beispiel 754 umfasst den Gegenstand von Beispiel 753, wobei die blockbasierte Topologie eine oder mehrere Blockchains oder einen dynamischen azyklischen Graphen (DAG) umfasst.
• Beispiel 755 umfasst den Gegenstand von Beispiel 753, wobei die blockbasierte Topologie eine Berechtigungs-Blockchain ist.
• Beispiel 756 umfasst den Gegenstand eines der Beispiele 753-755, wobei die digitale Signatur unter Verwendung eines geheimen Schlüssels verifiziert wird, der auf der Grundlage eines ephemeren öffentlichen Schlüssels erzeugt wird.
• Beispiel 757 umfasst den Gegenstand von Beispiel 756, wobei der ephemere öffentliche Schlüssel auf einem elliptischen Kurven-Diffie-Hellman-Austausch basiert.
• Beispiel 758 umfasst den Gegenstand eines der Beispiele 753-757, einschließlich der Extraktion eines oder mehrerer Smart Contracts aus dem Block.
• Beispiel 759 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 753-758.
• Beispiel 760 ist ein nicht-transitorisches, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: Sensordaten von einem mit einem autonomen Fahrzeug gekoppelten Sensor zu empfangen; eine digitale Signatur auf die Sensordaten anzuwenden; einen neuen Block zu einer blockbasierten Topologie hinzuzufügen, wobei der neue Block die Sensordaten und die digitale Signatur umfasst; die digitale Signatur zu verifizieren; und den Block an eine Logikeinheit des autonomen Fahrzeugs auf der Grundlage der verifizierten digitalen Signatur zu übermitteln.
• Beispiel 761 umfasst den Gegenstand von Beispiel 760, wobei die blockbasierte Topologie eine erlaubnisfreie Blockchain ist.
• Beispiel 762 umfasst den Gegenstand von Beispiel 761, wobei die digitale Signatur auf einem elliptischen Kurven-Kryptographieprotokoll (ECC) basiert.
• Beispiel 763 umfasst den Gegenstand eines der Beispiele 760-762, wobei die Verifizierung des Blocks die Verifizierung eines Zeitstempels der Sensordaten unter Verwendung einer Zeitbeschränkung eines Konsensprotokolls umfasst.
• Beispiel 764 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, an einem ersten autonomen Fahrzeug einen Block einer blockbasierten Topologie zu empfangen, wobei der Block Sensordaten von einem mit einem zweiten autonomen Fahrzeug gekoppelten Sensor und eine den Sensordaten zugeordnete digitale Signatur umfasst; die digitale Signatur zu verifizieren; und den Block ansprechend auf die Verifizierung der digitalen Signatur an eine Logikeinheit des ersten autonomen Fahrzeugs zu übermitteln.
• Beispiel 765 umfasst den Gegenstand von Beispiel 764, wobei die blockbasierte Topologie eine oder mehrere Blockchains oder einen dynamischen azyklischen Graphen (DAG) umfasst.
• Beispiel 766 umfasst den Gegenstand von Beispiel 764, wobei die blockbasierte Topologie eine Berechtigungs-Blockchain ist.
• Beispiel 767 umfasst den Gegenstand eines der Beispiele 764-766, wobei die digitale Signatur unter Verwendung eines geheimen Schlüssels verifiziert wird, der auf der Grundlage eines ephemeren öffentlichen Schlüssels erzeugt wird.
• Beispiel 768 umfasst den Gegenstand von Beispiel 767, wobei der ephemere öffentliche Schlüssel auf einem elliptischen Kurven-Diffie-Hellman-Austausch basiert.
• Beispiel 769 umfasst den Gegenstand eines der Beispiele 764 bis 768, wobei die Anweisungen, wenn sie ausgeführt werden, die Maschine außerdem veranlassen, einen oder mehrere Smart Contracts aus dem Block zu extrahieren.
• Beispiel 770 ist ein Verfahren, das Folgendes umfasst: Erhalten von Sensordaten, die von einer Mehrzahl von Sensoren eines Fahrzeugs abgetastet werden; Bestimmen eines Kontexts, der mit den abgetasteten Sensordaten verbunden ist; und auf der Grundlage des Kontexts Bestimmen einer oder beider Gruppen von Abtastraten für die Sensoren des Fahrzeugs oder einer Gruppe von Gewichtungen für die Sensoren, die verwendet werden sollen, um eine Fusion der Sensordaten durchzuführen.
• Beispiel 771 umfasst den Gegenstand von Beispiel 770, einschließlich der Bereitstellung des Kontexts als Ausgabe eines maschinellen Lernalgorithmus, der die abgetasteten Sensordaten als Eingabe erhält.
• Beispiel 772 umfasst den Gegenstand von Beispiel 771, wobei der maschinelle Lernalgorithmus unter Verwendung von Datensätzen als Grundwahrheit trainiert wird, wobei jeder Datensatz einen Kontext, Abtastraten für die Mehrzahl von Sensoren und ein Sicherheitsergebnis umfasst.
• Beispiel 773 umfasst den Gegenstand eines der Beispiele 770-772, ferner die Bereitstellung der Gruppe von Gewichtungen für die Sensoren unter Verwendung eines Fusions-Kontext-Wörterbuchs, das den Kontext von der Mehrzahl von Sensoren als Eingabe empfängt und die Gruppe von Gewichtungen ausgibt.
• Beispiel 774 umfasst den Gegenstand von Beispiel 773, wobei das Fusions-Kontext-Wörterbuch durch Training eines maschinellen Lernalgorithmus unter Verwendung von Kontextinformationen und Objektpositionen als Grundwahrheit bereitgestellt wird.
• Beispiel 775 umfasst den Gegenstand eines der Beispiele 770-774, wobei der Kontext verwendet wird, um die Gruppe der Abtastraten für die Sensoren des Fahrzeugs und die Gruppe der Gewichte für die Sensoren zu bestimmen, die zur Durchführung der Fusion der Sensordaten verwendet werden sollen.
• Beispiel 776 umfasst den Gegenstand eines der Beispiele 770 bis 775, einschließlich des Kombinierens von Abtastwerten aus der Mehrzahl der Sensoren auf der Grundlage der Gruppe von Gewichten.
• Beispiel 777 umfasst den Gegenstand eines der Beispiele 770-776, wobei ferner die Gruppe der Gewichte auf der Grundlage des Kontexts unter Verwendung eines Verstärkungslernmodells bestimmt wird.
• Beispiel 778 umfasst den Gegenstand von Beispiel 777, wobei das Verstärkungslernmodell unter Verwendung einer Umgebung von Sensorabtastwerten und Kontexten trainiert wird.
• Beispiel 779 umfasst den Gegenstand eines der Beispiele 777-778, wobei das Verstärkungslernmodell mit einer Belohnung trainiert wird, die auf der Genauigkeit der Objektverfolgung und der Minimierung des Stromverbrauchs basiert.
• Beispiel 780 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 770 bis 779.
• Beispiel 781 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: Sensordaten zu erhalten, die von einer Mehrzahl von Sensoren eines Fahrzeugs abgetastet werden; einen Kontext zu bestimmen, der mit den abgetasteten Sensordaten verbunden ist; und auf der Grundlage des Kontexts eine oder beide einer Gruppe von Abtastraten für die Sensoren des Fahrzeugs oder eine Gruppe von Gewichtungen für die Sensoren zu bestimmen, die verwendet werden sollen, um eine Fusion der Sensordaten durchzuführen.
• Beispiel 782 umfasst den Gegenstand von Beispiel 781, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, den Kontext als Ausgabe eines maschinellen Lernalgorithmus bereitzustellen, der die abgetasteten Sensordaten als Eingabe erhält.
• Beispiel 783 umfasst den Gegenstand von Beispiel 782, wobei der maschinelle Lernalgorithmus unter Verwendung von Datensätzen als Grundwahrheit trainiert wird, wobei jeder Datensatz einen Kontext, Abtastraten für die Mehrzahl von Sensoren und ein Sicherheitsergebnis umfasst.
• Beispiel 784 umfasst den Gegenstand eines der Beispiele 781-783, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, die Gruppe von Gewichtungen für die Sensoren unter Verwendung eines Fusions-Kontext-Wörterbuchs bereitzustellen, das den Kontext von der Mehrzahl von Sensoren als Eingabe erhält und die Gruppe von Gewichtungen ausgibt.
• Beispiel 785 umfasst den Gegenstand von Beispiel 784, wobei das Fusions-Kontext-Wörterbuch durch Training eines maschinellen Lernalgorithmus unter Verwendung von Kontextinformationen und Objektpositionen als Grundwahrheit bereitgestellt wird.
• Beispiel 786 umfasst den Gegenstand eines der Beispiele 781-785, wobei der Kontext verwendet wird, um die Gruppe der Abtastraten für die Sensoren des Fahrzeugs und die Gruppe der Gewichte für die Sensoren zu bestimmen, die zur Durchführung der Fusion der Sensordaten verwendet werden sollen.
• Beispiel 787 schließt den Gegenstand eines der Beispiele 781-786 ein, wobei die Anweisungen bei ihrer Ausführung ferner die Maschine veranlassen, Abtastwerte aus der Mehrzahl der Sensoren auf der Grundlage der Gruppe von Gewichten zu kombinieren.
• Beispiel 788 umfasst den Gegenstand eines der Beispiele 781-787, wobei die Anweisungen, wenn sie ausgeführt werden, ferner die Maschine veranlassen, die Gruppe von Gewichten auf der Grundlage des Kontexts unter Verwendung eines Verstärkungslernmodells zu bestimmen.
• Beispiel 789 umfasst den Gegenstand von Beispiel 788, wobei das Verstärkungslernmodell unter Verwendung einer Umgebung von Sensorabtastwerte und Kontexten trainiert wird.
• Beispiel 790 umfasst den Gegenstand eines der Beispiele 788-789, wobei das Verstärkungslernmodell unter Verwendung einer Belohnung trainiert wird, die auf der Objektverfolgungsgenauigkeit und der Minimierung des Stromverbrauchs basiert.
• Beispiel 791 ist ein Verfahren, das Folgendes umfasst: Empfangen von modulierten Lichtsignalen an einem autonomen Fahrzeug von einem Verkehrsfahrzeug; Abtasten der modulierten Lichtsignale; Demodulieren der abgetasteten Lichtsignale, um Positionsinformationen für das Verkehrsfahrzeug zu erhalten; und Verwenden der Positionsinformationen des Verkehrsfahrzeugs in einem Sensorfusionsprozess des Subjekts.
• Beispiel 792 umfasst den Gegenstand von Beispiel 791, wobei die modulierten Lichtsignale mit einer bestimmten Frequenz abgetastet werden.
• Beispiel 793 umfasst den Gegenstand von Beispiel 792, wobei die bestimmte Frequenz proaktiv ausgewählt wird.
• Beispiel 794 umfasst den Gegenstand von Beispiel 792, wobei die bestimmte Frequenz auf der Grundlage von Ereignissen ausgewählt wird.
• Beispiel 795 umfasst den Gegenstand von Beispiel 791, wobei die modulierten Lichtsignale ansprechend auf die Erkennung der Anwesenheit des Verkehrsfahrzeugs abgetastet werden.
• Beispiel 796 umfasst den Gegenstand von Beispiel 791, wobei die Positionsinformationen Geokoordinaten des Verkehrsfahrzeugs in einem Grad-Minuten-Sekunden-Format umfassen.
• Beispiel 797 umfasst den Gegenstand von Beispiel 791, wobei das modulierte Licht demoduliert wird, um weitere Größeninformationen für das Verkehrsfahrzeug zu erhalten, wobei die Größeninformationen eine oder mehrere Längen, Breiten oder Höhen des Verkehrsfahrzeugs umfassen.
• Beispiel 798 umfasst den Gegenstand eines der Beispiele 791-797, wobei das modulierte Licht gemäß einem Li-Fi-Protokoll übertragen wird.
• Beispiel 799 umfasst den Gegenstand eines der Beispiele 791-797, wobei die modulierten Lichtsignale gemäß On-Off Keying (OOK), Amplitude Shift Keying (ASK), Variable Pulspositionsmodulation (VPPM) oder Color-Shift Keying (CSK) moduliert werden.
• Beispiel 800 umfasst den Gegenstand eines der Beispiele 791-797, wobei das modulierte Licht eines oder mehrere der folgenden Elemente umfasst: sichtbares Licht mit einer Wellenlänge zwischen 375 nm und 780 nm, Infrarotlicht und ultraviolettes Licht.
• Beispiel 801 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 791-800.
• Beispiel 802 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, an einem autonomen Fahrzeug modulierte Lichtsignale von einem Verkehrsfahrzeug zu empfangen; die modulierten Lichtsignale abzutasten; die abgetasteten Lichtsignale zu demodulieren, um Positionsinformationen für das Verkehrsfahrzeug zu erhalten; und die Positionsinformationen des Verkehrsfahrzeugs in einem Sensorfusionsprozess des Subjekts zu verwenden.
• Beispiel 803 umfasst den Gegenstand von Beispiel 802, wobei die modulierten Lichtsignale mit einer bestimmten Frequenz abgetastet werden.
• Beispiel 804 umfasst den Gegenstand von Beispiel 803, wobei die bestimmte Frequenz proaktiv ausgewählt wird.
• Beispiel 805 umfasst den Gegenstand von Beispiel 803, wobei die bestimmte Frequenz auf der Grundlage von Ereignissen ausgewählt wird.
• Beispiel 806 umfasst den Gegenstand von Beispiel 802, wobei die modulierten Lichtsignale ansprechend auf die Erkennung der Anwesenheit des Verkehrsfahrzeugs abgetastet werden.
• Beispiel 807 umfasst den Gegenstand von Beispiel 802, wobei die Positionsinformationen Geokoordinaten des Verkehrsfahrzeugs in einem Grad-Minuten-Sekunden-Format umfassen.
• Beispiel 808 umfasst den Gegenstand von Beispiel 802, wobei das modulierte Licht demoduliert wird, um weitere Größeninformationen für das Verkehrsfahrzeug zu erhalten, wobei die Größeninformationen eine oder mehrere Längen, Breiten oder Höhen des Verkehrsfahrzeugs umfassen.
• Beispiel 809 umfasst den Gegenstand von einem der Beispiele 802-808, wobei das modulierte Licht gemäß einem Li-Fi-Protokoll übertragen wird.
• Beispiel 810 umfasst den Gegenstand eines der Beispiele 802-808, wobei die modulierten Lichtsignale gemäß On-Off Keying (OOK), Amplitude Shift Keying (ASK), Variable Pulspositionsmodulation (VPPM) oder Color-Shift Keying (CSK) moduliert werden.
• Beispiel 811 umfasst den Gegenstand eines der Beispiele 802-808, wobei das modulierte Licht eines oder mehrere der folgenden Elemente umfasst: sichtbares Licht mit einer Wellenlänge zwischen 375 nm und 780 nm, Infrarotlicht und ultraviolettes Licht.
• Beispiel 812 ist ein Verfahren, das Folgendes umfasst: Erhalten von Sensordaten von einem Sensor, der mit einem autonomen Fahrzeug gekoppelt ist; Anwenden eines Sensorabstraktionsprozesses auf die Sensordaten, um abstrahierte Szenendaten zu erzeugen, wobei der Sensorabstraktionsprozess eines oder mehrere der Folgenden umfasst: Anwenden eines Antwortnormalisierungsprozesses auf die Sensordaten; Anwenden eines Verzerrungs-Prozesses auf die Sensordaten; und Anwenden eines Filterprozesses auf die Sensordaten; und Verwenden der abstrahierten Szenendaten in einer Wahrnehmungsphase eines Steuerprozesses für das autonome Fahrzeug.
• Beispiel 813 umfasst den Gegenstand von Beispiel 812, wobei die Sensordaten erste Sensordaten von einem ersten Sensor und zweite Sensordaten von einem zweiten Sensor umfassen, wobei der erste Sensor und der zweite Sensor vom gleichen Sensortyp sind, und die Anwendung des Sensorabstraktionsprozesses einen oder mehrere der folgenden Schritte umfasst: Anwendung eines jeweiligen Antwortnormalisierungsprozesses auf die ersten Sensordaten und die zweiten Sensordaten; Anwendung eines jeweiligen Verzerrungs-Prozesses auf die ersten Sensordaten und die zweiten Sensordaten; und Anwendung eines Filterungsprozesses auf eine Kombination der ersten Sensordaten und der zweiten Sensordaten.
• Beispiel 814 umfasst den Gegenstand von Beispiel 812, wobei die Sensordaten erste Sensordaten von einem ersten Sensor und zweite Sensordaten von einem zweiten Sensor umfassen, wobei der erste Sensor und der zweite Sensor unterschiedliche Sensortypen sind, und die Anwendung des Sensorabstraktionsprozesses einen oder mehrere der folgenden Schritte umfasst: anwenden eines jeweiligen Antwortnormalisierungsprozesses auf die ersten Sensordaten und die zweiten Sensordaten; Anwenden eines jeweiligen Verzerrungs-Prozesses auf die ersten Sensordaten und die zweiten Sensordaten; und Anwenden eines jeweiligen Filterungsprozesses auf die ersten Sensordaten und die zweiten Sensordaten, um erste abstrahierte Szenendaten, die den ersten Sensordaten entsprechen, und zweite abstrahierte Szenendaten, die den zweiten Sensordaten entsprechen, zu erzeugen; und das Verfahren ferner das Anwenden eines Fusionsprozesses auf die ersten und zweiten abstrahierten Szenendaten umfasst; wobei die fusionierten ersten und zweiten abstrahierten Szenendaten in der Wahrnehmungsphase verwendet werden.
• Beispiel 815 umfasst den Gegenstand von einem der Beispiele 812-814, wobei die Anwendung eines Antwortnormalisierungsprozesses eines oder mehrere der folgenden Verfahren umfasst: Normalisierung von Pixelwerten eines Bildes, Normalisierung einer Bittiefe eines Bildes, Normalisierung eines Farbraums eines Bildes und Normalisierung eines Bereichs von Tiefen- oder Entfernungswerten in LIDAR-Daten.
• Beispiel 816 umfasst den Gegenstand eines der Beispiele 812-814, wobei die Anwendung eines Antwortnormalisierungsprozesses auf einem Modell der Sensorantwort basiert.
• Beispiel 817 umfasst den Gegenstand eines der Beispiele 812-814, wobei die Anwendung eines Verzerrungsprozesses die Durchführung einer oder mehrerer räumlicher Hochskalierungsoperationen, einer Herunterskalierungsoperation, eines Korrekturprozesses für geometrische Effekte, die mit dem Sensor verbunden sind, und eines Korrekturprozesses für die Bewegung des Sensors umfasst.
• Beispiel 818 umfasst den Gegenstand eines der Beispiele 812-814, wobei die Anwendung eines Verformungsprozesses auf Sensorkonfigurationsinformationen basiert.
• Beispiel 819 umfasst den Gegenstand eines der Beispiele 812-814, wobei die Anwendung eines Filterungsprozesses die Anwendung eines oder mehrerer Kalman-Filter, einer Variante des Kalman-Filters, eines Partikelfilters, eines Histogramm-Filters, eines Informationsfilters, eines Bayes-Filters und eines Gauß-Filters umfasst.
• Beispiel 820 umfasst den Gegenstand eines der Beispiele 812-814, wobei die Anwendung eines Filterungsprozesses auf einem oder mehreren Modellen für den Sensor und einem Szenenmodell basiert.
• Beispiel 821 umfasst den Gegenstand eines der Beispiele 812-814, wobei die Anwendung eines Filterprozesses die Bestimmung einer Gültigkeit der Sensordaten und das Verwerfen der Sensordaten ansprechend auf die Bestimmung, dass die Sensordaten ungültig sind, umfasst.
• Beispiel 822 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 812-821.
• Beispiel 823 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: Sensordaten von einem mit einem autonomen Fahrzeug gekoppelten Sensor zu erhalten; einen Sensorabstraktionsprozess auf die Sensordaten anzuwenden, um abstrahierte Szenendaten zu erzeugen, wobei der Sensorabstraktionsprozess einen oder mehrere der folgenden Punkte umfasst: anwenden eines Antwortnormalisierungsprozesses auf die Sensordaten; Anwenden eines Warp-Prozesses auf die Sensordaten; und Anwenden eines Filterungsprozesses auf die Sensordaten; und Verwenden der abstrahierten Szenendaten in einer Wahrnehmungsphase eines Steuerprozesses für das autonome Fahrzeug.
• Beispiel 824 umfasst den Gegenstand von Beispiel 823, wobei die Sensordaten erste Sensordaten von einem ersten Sensor und zweite Sensordaten von einem zweiten Sensor umfassen, wobei der erste Sensor und der zweite Sensor vom gleichen Sensortyp sind, und die Anwendung des Sensorabstraktionsprozesses einen oder mehrere der folgenden Schritte umfasst: Anwendung eines jeweiligen Antwortnormalisierungsprozesses auf die ersten Sensordaten und die zweiten Sensordaten; Anwendung eines jeweiligen Verzerrungs-Prozesses auf die ersten Sensordaten und die zweiten Sensordaten; und Anwendung eines Filterungsprozesses auf eine Kombination der ersten Sensordaten und der zweiten Sensordaten.
• Beispiel 825 umfasst den Gegenstand von Beispiel 823, wobei die Sensordaten erste Sensordaten von einem ersten Sensor und zweite Sensordaten von einem zweiten Sensor umfassen, wobei der erste Sensor und der zweite Sensor unterschiedliche Sensortypen sind, und die Anwendung des Sensorabstraktionsprozesses einen oder mehrere der folgenden Schritte umfasst: anwenden eines jeweiligen Antwortnormalisierungsprozesses auf die ersten Sensordaten und die zweiten Sensordaten; Anwenden eines jeweiligen Verzerrungs-Prozesses auf die ersten Sensordaten und die zweiten Sensordaten; und Anwenden eines jeweiligen Filterungsprozesses auf die ersten Sensordaten und die zweiten Sensordaten, um erste abstrahierte Szenendaten, die den ersten Sensordaten entsprechen, und zweite abstrahierte Szenendaten, die den zweiten Sensordaten entsprechen, zu erzeugen; und das Speichermedium ferner das Anwenden eines Fusionsprozesses auf die ersten und zweiten abstrahierten Szenendaten umfasst; wobei die fusionierten ersten und zweiten abstrahierten Szenendaten in der Wahrnehmungsphase verwendet werden.
• Beispiel 825 umfasst den Gegenstand eines der Beispiele 823-825, wobei die Anwendung eines Antwortnormalisierungsprozesses eine oder mehrere der folgenden Maßnahmen umfasst: Normalisierung von Pixelwerten eines Bildes, Normalisierung einer Bittiefe eines Bildes, Normalisierung eines Farbraums eines Bildes und Normalisierung eines Bereichs von Tiefen- oder Distanzwerten in LIDAR-Daten.
• Beispiel 827 umfasst den Gegenstand eines der Beispiele 823-825, wobei die Anwendung eines Antwortnormalisierungsprozesses auf einem Modell der Sensorantwort basiert.
• Beispiel 828 umfasst den Gegenstand eines der Beispiele 823-825, wobei die Anwendung eines Verzerrungsprozesses die Durchführung einer oder mehrerer räumlicher Hochskalierungsoperationen, einer Herunterskalierungsoperation, eines Korrekturprozesses für geometrische Effekte, die mit dem Sensor verbunden sind, und eines Korrekturprozesses für die Bewegung des Sensors umfasst.
• Beispiel 829 umfasst den Gegenstand eines der Beispiele 823-825, wobei die Anwendung eines Verzerrungsprozesses auf Sensorkonfigurationsinformationen basiert.
• Beispiel 830 umfasst den Gegenstand eines der Beispiele 823-825, wobei die Anwendung eines Filterungsprozesses die Anwendung eines oder mehrerer Kalman-Filter, einer Variante des Kalman-Filters, eines Partikelfilters, eines Histogramm-Filters, eines Informationsfilters, eines Bayes-Filters und eines Gauß-Filters umfasst.
• Beispiel 831 umfasst den Gegenstand eines der Beispiele 823-825, wobei die Anwendung eines Filterungsprozesses auf einem oder mehreren Modellen für den Sensor und einem Szenenmodell basiert.
• Beispiel 832 umfasst den Gegenstand eines der Beispiele 823-825, wobei die Anwendung eines Filterprozesses die Bestimmung einer Gültigkeit der Sensordaten und das Verwerfen der Sensordaten ansprechend auf die Bestimmung, dass die Sensordaten ungültig sind, umfasst.
• Beispiel 833 ist ein Verfahren, das Folgendes umfasst: Erfassen erster Bilddaten durch einen ersten Sensor eines Fahrzeugs, wobei die ersten Bilddaten eine erste Auflösung haben; Verwenden eines Maschinelles-Lernen-Modells, Transformieren der ersten Bilddaten in zweite Bilddaten mit einer zweiten Auflösung, wobei die zweite Auflösung höher ist als die erste Auflösung; und Durchführen von Objekterkennungsoperationen für das Fahrzeug auf der Grundlage der zweiten Bilddaten.
• Beispiel 834 umfasst den Gegenstand von Beispiel 833, wobei der erste Sensor des Fahrzeugs eine Kamera umfasst.
• Beispiel 835 umfasst den Gegenstand von Beispiel 833, wobei der erste Sensor des Fahrzeugs ein LIDAR umfasst.
• Beispiel 836 umfasst den Gegenstand eines der Beispiele 833-835, wobei das Maschinelles-Lernen-Modell unter Verwendung eines Trainingssatzes trainiert wird, der dritte Bilder, die von einem zweiten Sensor erfasst wurden, und vierte Bilder umfasst, die durch Verzerrung der dritten Bilder erzeugt wurden, um den Anschein einer geringeren Auflösung als die dritten Bilder zu erwecken.
• Beispiel 837 umfasst den Gegenstand von Beispiel 836, wobei die vierten Bilder durch Verzerrung der dritten Bilder unter Verwendung eines oder mehrerer der folgenden Punkte erzeugt werden: Anwendung eines Tiefpassfilters auf die dritten Bilder; Unterabtastung der dritten Bilder; Unterabtastung der dritten Bilder; Einspeisung von Rauschen in die dritten Bilder; oder Randomisierung der Kanäle der dritten Bilder.
• Beispiel 838 umfasst den Gegenstand eines der Beispiele 833-836, wobei das Maschinelles-Lernen-Modell unter Verwendung eines Trainingssatzes trainiert wird, der dritte Bilder umfasst, die von einem zweiten Sensor mit der ersten Auflösung erfasst wurden, und vierte Bilder, die von einem dritten Sensor mit der zweiten Auflösung erfasst wurden.
• Beispiel 839 umfasst den Gegenstand eines der Beispiele 833-838, wobei das Maschinelles-Lernen-Modell eine Faltungsneuronalnetzwerk-Architektur umfasst.
• Beispiel 840 umfasst den Gegenstand eines der Beispiele 833-839, wobei das Maschinelles-Lernen-Modell ein generatives neuronales Netz umfasst.
• Beispiel 841 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 833-840.
• Beispiel 842 ist ein Verfahren, das Folgendes umfasst: Trainieren eines Ensembles von Maschinelles-Lernen-Modellen, um eine Aufgabe eines autonomen Fahrzeugstapels durchzuführen, wobei das Ensemble ein erstes maschinelles Lernmodell, das unter Verwendung von Bilddaten mit einer ersten Auflösung trainiert wurde, und ein zweites maschinelles Lernmodell umfasst; und Trainieren eines dritten Maschinelles-Lernen-Modells, das zumindest teilweise auf einem Destillationsverlust zwischen fusionierten weichen Vorhersagezielen des Ensembles von Maschinelles-Lernen-Modellen und weichen Vorhersagezielen des dritten Maschinelles-Lernen-Modells basiert.
• Beispiel 843 umfasst den Gegenstand von Beispiel 842, ferner das Trainieren des dritten Maschinelles-Lernen-Modells auf der Grundlage eines Verlustes, der eine Differenz zwischen Grundwahrheitsetiketten und harten Vorhersagezielen des dritten Maschinelles-Lernen-Modells darstellt.
• Beispiel 844 umfasst den Gegenstand eines der Beispiele 842-843, wobei die Bilddaten mit der ersten Auflösung Daten sind, die von einem oder mehreren LIDARs erfasst wurden.
• Beispiel 845 umfasst den Gegenstand eines der Beispiele 842-843, wobei die Bilddaten mit der ersten Auflösung Daten sind, die von einer oder mehreren Kameras erfasst wurden.
• Beispiel 846 umfasst den Gegenstand eines der Beispiele 842-845, wobei das dritte maschinelle Lernmodell unter Verwendung von Bilddaten mit einer zweiten Auflösung trainiert wird, wobei die zweite Auflösung niedriger als die erste Auflösung ist.
• Beispiel 847 umfasst den Gegenstand eines der Beispiele 842-846, wobei das dritte maschinelle Lernmodell unter Verwendung von Bilddaten trainiert wird, die von einer oder mehreren Kameras erfasst wurden.
• Beispiel 848 umfasst den Gegenstand eines der Beispiele 842-846, wobei das dritte maschinelle Lernmodell unter Verwendung von Bilddaten trainiert wird, die von einem oder mehreren LIDARs erfasst wurden.
• Beispiel 849 umfasst den Gegenstand eines der Beispiele 842-848, wobei das dritte maschinelle Lernmodell eine Kombination aus einem vierten maschinellen Lernmodell, das unter Verwendung von Bilddaten trainiert wird, die von einem oder mehreren LIDARs erfasst werden, und einem fünften maschinellen Lernmodell ist, das unter Verwendung von Bilddaten trainiert wird, die von einer oder mehreren Kameras erfasst werden.
• Beispiel 850 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 842-849.
• Beispiel 851 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: erste Bilddaten durch einen ersten Sensor eines Fahrzeugs zu erfassen, wobei die ersten Bilddaten eine erste Auflösung haben; ein Maschinenlernmodell zu verwenden, das die ersten Bilddaten in zweite Bilddaten mit einer zweiten Auflösung transformiert, wobei die zweite Auflösung höher ist als die erste Auflösung; und Objekterkennungsoperationen für das Fahrzeug auf der Grundlage der zweiten Bilddaten durchzuführen.
• Beispiel 852 umfasst den Gegenstand von Beispiel 851, wobei der erste Sensor des Fahrzeugs eine Kamera umfasst.
• Beispiel 853 umfasst den Gegenstand von Beispiel 851, wobei der erste Sensor des Fahrzeugs ein LIDAR umfasst.
• Beispiel 854 umfasst den Gegenstand eines der Beispiele 851-853, wobei das Maschinelles-Lernen-Modell unter Verwendung eines Trainingssatzes trainiert wird, der dritte Bilder, die von einem zweiten Sensor erfasst wurden, und vierte Bilder umfasst, die durch Verzerrung der dritten Bilder erzeugt wurden, so dass sie eine geringere Auflösung als die dritten Bilder zu haben scheinen.
• Beispiel 855 umfasst den Gegenstand von Beispiel 854, wobei die vierten Bilder durch Verzerrung der dritten Bilder unter Verwendung eines oder mehrerer der folgenden Punkte erzeugt werden: Anwendung eines Tiefpassfilters auf die dritten Bilder; Unterabtastung der dritten Bilder; Unterabtastung der dritten Bilder; Einbringen von Rauschen in die dritten Bilder; oder Zufallsgenerierung von Kanälen der dritten Bilder.
• Beispiel 856 umfasst den Gegenstand eines der Beispiele 851-854, wobei das Maschinelles-Lernen-Modell unter Verwendung eines Trainingssatzes trainiert wird, der dritte Bilder umfasst, die von einem zweiten Sensor mit der ersten Auflösung erfasst wurden, und vierte Bilder, die von einem dritten Sensor mit der zweiten Auflösung erfasst wurden.
• Beispiel 857 umfasst den Gegenstand eines der Beispiele 851-855, wobei das Maschinelles-Lernen-Modell eine Faltungsneuronalnetzwerk-Architektur umfasst.
• Beispiel 858 umfasst den Gegenstand eines der Beispiele 851-856, wobei das Maschinelles-Lernen-Modell ein generatives neuronales Netz umfasst.
• Beispiel 859 ist ein nicht-transitorisches maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen, ein Ensemble von Maschinenlernmodellen zu trainieren, um eine Aufgabe eines autonomen Fahrzeugstapels auszuführen, wobei das Ensemble ein erstes Maschinenlernmodell, das unter Verwendung von Bilddaten mit einer ersten Auflösung trainiert wurde, und ein zweites Maschinenlernmodell umfasst; und ein drittes Maschinenlernmodell zu trainieren, das zumindest teilweise auf einem Destillationsverlust zwischen fusionierten weichen Vorhersagezielen des Ensembles von Maschinenlernmodellen und weichen Vorhersagezielen des dritten Maschinenlernmodells basiert.
• Beispiel 860 umfasst den Gegenstand von Beispiel 859, ferner das Trainieren des dritten Maschinelles-Lernen-Modells auf der Grundlage eines Verlustes, der eine Differenz zwischen Grundwahrheitsetiketten und harten Vorhersagezielen des dritten Maschinelles-Lernen-Modells darstellt.
• Beispiel 861 umfasst den Gegenstand eines der Beispiele 859-860, wobei die Bilddaten mit der ersten Auflösung Daten sind, die von einem oder mehreren LIDARs erfasst wurden.
• Beispiel 862 umfasst den Gegenstand eines der Beispiele 859-860, wobei die Bilddaten mit der ersten Auflösung Daten sind, die von einer oder mehreren Kameras erfasst wurden.
• Beispiel 863 umfasst den Gegenstand eines der Beispiele 859-862, wobei das dritte maschinelle Lernmodell unter Verwendung von Bilddaten mit einer zweiten Auflösung trainiert wird, wobei die zweite Auflösung niedriger als die erste Auflösung ist.
• Beispiel 864 umfasst den Gegenstand eines der Beispiele 859-863, wobei das dritte maschinelle Lernmodell unter Verwendung von Bilddaten trainiert wird, die von einer oder mehreren Kameras erfasst wurden.
• Beispiel 865 umfasst den Gegenstand eines der Beispiele 859-863, wobei das dritte maschinelle Lernmodell unter Verwendung von Bilddaten trainiert wird, die von einem oder mehreren LIDARs erfasst wurden.
• Beispiel 866 umfasst den Gegenstand eines der Beispiele 859-865, wobei das dritte maschinelle Lernmodell eine Kombination aus einem vierten maschinellen Lernmodell, das unter Verwendung von Bilddaten trainiert wird, die von einem oder mehreren LIDARs erfasst werden, und einem fünften maschinellen Lernmodell ist, das unter Verwendung von Bilddaten trainiert wird, die von einer oder mehreren Kameras erfasst werden.
• Beispiel 867 ist ein System mit: einen Speicher, um erfasste Daten zu speichern; ein internes Erfassungsmodul eines ersten autonomen Fahrzeugs, wobei das interne Erfassungsmodul eine Schaltung umfasst, um eine Kommunikation von durch das erste autonome Fahrzeug erfassten Daten zu einem externen Erfassungsmodul eines zweiten autonomen Fahrzeugs zu initiieren; ein externes Sensormodul des ersten autonomen Fahrzeugs, wobei das externe Sensormodul des ersten autonomen Fahrzeugs Daten von einem internen Sensormodul des zweiten autonomen Fahrzeugs empfängt; und einen kooperativen Entscheidungsträger des ersten autonomen Fahrzeugs, wobei der kooperative Entscheidungsträger eine Schaltung umfasst, um Fahraktionen basierend auf der Kommunikation mit einem kooperativen Entscheidungsträger des zweiten autonomen Fahrzeugs zu bestimmen.
• Beispiel 868 umfasst den Gegenstand von Beispiel 867, wobei das interne Erfassungsmodul des ersten autonomen Fahrzeugs mit dem externen Erfassungsmodul des zweiten autonomen Fahrzeugs unter Verwendung einer semantischen Sprache kommunizieren soll.
• Beispiel 869 umfasst den Gegenstand eines oder mehrerer der Beispiele 867-868, wobei das externe Erfassungsmodul des ersten autonomen Fahrzeugs mit dem internen Erfassungsmodul des zweiten autonomen Fahrzeugs unter Verwendung einer semantischen Sprache kommunizieren soll.
• Beispiel 870 umfasst den Gegenstand eines oder mehrerer der Beispiele 867-869, wobei der kooperative Entscheider des ersten autonomen Fahrzeugs mit dem kooperativen Entscheidermodul des zweiten autonomen Fahrzeugs unter Verwendung einer semantischen Sprache kommunizieren soll.
• Beispiel 871 umfasst den Gegenstand eines oder mehrerer der Beispiele 867-870 und umfasst darüber hinaus ein erweitertes Erfassungsmodul des ersten autonomen Fahrzeugs.
• Beispiel 872 umfasst den Gegenstand eines oder mehrerer der Beispiele 867-871, wobei die Daten, die zwischen dem kooperativen Entscheidungsträger des ersten autonomen Fahrzeugs und dem kooperativen Entscheidungsträger des zweiten autonomen Fahrzeugs übermittelt werden, Daten umfassen, die sich auf einen Aktionsplan des ersten autonomen Fahrzeugs oder des zweiten autonomen Fahrzeugs beziehen.
• Beispiel 873 umfasst den Gegenstand eines oder mehrerer der Beispiele 867-872, wobei das interne Erfassungsmodul des ersten autonomen Fahrzeugs dazu dient, die vom ersten autonomen Fahrzeug erfassten Daten zu analysieren.
• Beispiel 874 umfasst den Gegenstand eines oder mehrerer der Beispiele 867-873, ferner ein Virtual-Reality-Wahrnehmungsmodul mit einer Schaltungsanordnung zum Empfang von Daten, die von einem oder mehreren externen Agenten erfasst werden, um die Umgebung des ersten autonomen Fahrzeugs unter Verwendung der von dem einen oder den mehreren externen Agenten erfassten Daten zu betrachten.
• Beispiel 875 ist ein Verfahren, das Folgendes umfasst: Austausch von Daten von einem ersten autonomen Fahrzeug zu einem zweiten autonomen Fahrzeug unter Verwendung einer semantischen Sprache.
• Beispiel 876 umfasst den Gegenstand von Beispiel 875, wobei die Daten kritische Daten in Bezug auf eine oder mehrere Verkehrssituationen umfassen.
• Beispiel 877 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Beispiele 875-876.
• Beispiel 878 umfasst den Gegenstand von Beispiel 877, wobei das Mittel mindestens ein maschinenlesbares Medium mit Anweisungen umfasst, wobei die Anweisungen, wenn sie ausgeführt werden, ein Verfahren von einem oder mehreren der Beispiele 875-876 implementieren.
• Beispiel 879 ist ein Verfahren, das Folgendes umfasst: Erzeugen einer Positionseinstellanweisung für einen Bildsensor eines Fahrzeugs durch eine Steuereinheit, die eine Schaltung umfasst; Empfangen von Bilddaten von dem Bildsensor des Fahrzeugs an der Steuereinheit; Erfassen eines Ortes und einer Größe einer Markierung des Fahrzeugs innerhalb der Bilddaten; und Erzeugen einer zweiten Positionseinstellanweisung für den Bildsensor des Fahrzeugs durch die Steuereinheit auf der Grundlage des Ortes und der Größe der Markierung des Fahrzeugs innerhalb der Bilddaten.
• Beispiel 880 umfasst den Gegenstand von Beispiel 879, wobei die Anweisung zur Positionseinstellung einen horizontalen Drehwinkel des Bildsensors des Fahrzeugs angibt.
• Beispiel 881 umfasst den Gegenstand eines der Beispiele 879-880, wobei die Anweisung zur Positionseinstellung einen vertikalen Drehwinkel des Bildsensors des Fahrzeugs angibt.
• Beispiel 882 umfasst den Gegenstand eines der Beispiele 879-881, wobei die Anweisung zur Positionsanpassung einen Abstand der horizontalen Bewegung des Bildsensors des Fahrzeugs angibt.
• Beispiel 883 umfasst den Gegenstand eines der Beispiele 879-882, wobei die Anweisung zur Positionsanpassung einen Abstand der vertikalen Bewegung des Bildsensors des Fahrzeugs angibt.
• Beispiel 884 umfasst den Gegenstand eines der Beispiele 879-883, wobei ferner die Anweisung zur Positionseinstellung des Bildsensors in Reaktion auf einen erkannten Zustand des Fahrzeugs erzeugt wird.
• Beispiel 885 umfasst den Gegenstand eines der Beispiele 879-884, wobei die Anweisung zur Positionseinstellung Teil einer Reihe von Anweisungen zur periodischen Positionseinstellung des Bildsensors des Fahrzeugs ist.
• Beispiel 886 umfasst den Gegenstand eines der Beispiele 879-885, wobei die Markierung des Fahrzeugs an der Außenseite des Fahrzeugs angeordnet ist und eine andere Farbe als die Außenseite des Fahrzeugs hat.
• Beispiel 887 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 879-886.
• Beispiel 888 ist ein nicht-transitorisches, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: durch eine Steuereinheit, die eine Schaltung umfasst, einen Positionseinstellbefehl für einen Bildsensor eines Fahrzeugs zu erzeugen; an der Steuereinheit Bilddaten von dem Bildsensor des Fahrzeugs zu empfangen; eine Position und Größe einer Markierung des Fahrzeugs innerhalb der Bilddaten zu erfassen; und durch die Steuereinheit einen zweiten Positionseinstellbefehl für den Bildsensor des Fahrzeugs auf der Grundlage der Position und Größe der Markierung des Fahrzeugs innerhalb der Bilddaten zu erzeugen.
• Beispiel 889 umfasst den Gegenstand von Beispiel 888, wobei die Anweisung zur Positionseinstellung einen horizontalen Drehwinkel des Bildsensors des Fahrzeugs angibt.
• Beispiel 890 umfasst den Gegenstand eines der Beispiele 888-889, wobei die Anweisung zur Positionseinstellung einen Winkel der vertikalen Drehung des Bildsensors des Fahrzeugs angibt.
• Beispiel 891 umfasst den Gegenstand eines der Beispiele 888-890, wobei die Anweisung zur Positionsanpassung einen Abstand der horizontalen Bewegung des Bildsensors des Fahrzeugs angibt.
• Beispiel 892 umfasst den Gegenstand eines der Beispiele 888-891, wobei die Anweisung zur Positionseinstellung einen Abstand der vertikalen Bewegung des Bildsensors des Fahrzeugs angibt.
• Beispiel 893 umfasst den Gegenstand eines der Beispiele 888-892, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, die Positionseinstellanweisung für den Bildsensor ansprechend auf einen erkannten Zustand in Verbindung mit dem Fahrzeug zu erzeugen.
• Beispiel 894 umfasst den Gegenstand eines der Beispiele 888-893, wobei die Anweisung zur Positionseinstellung Teil einer Reihe von Anweisungen zur periodischen Positionseinstellung des Bildsensors des Fahrzeugs ist.
• Beispiel 895 umfasst den Gegenstand der Beispiele 888-894, wobei die Markierung des Fahrzeugs an der Außenseite des Fahrzeugs angeordnet ist und eine andere Farbe als die Außenseite des Fahrzeugs hat.
• Beispiel 896 ist ein Verfahren, das Folgendes umfasst: Bestimmen mindestens einer Übergabeposition eines autonomen Fahrzeugs an einen Fahrer auf einer Route; Empfangen von Informationen, die sich auf Merkmale eines Fahrers beziehen; Empfangen von Informationen, die sich auf einen aktuellen Aufmerksamkeitszustand des Fahrers beziehen; und Bestimmen des erwarteten Fahrerverhaltens während jeder der mindestens einen Übergabeposition.
• Beispiel 897 umfasst den Gegenstand von Beispiel 896, wobei die Informationen über die Merkmale des Fahrers allgemeine Informationen umfassen.
• Beispiel 898 umfasst den Gegenstand eines oder mehrerer der Beispiele 896-897, wobei die Informationen, die sich auf die Merkmale des Fahrers beziehen, fahrerspezifische Informationen umfassen.
• Beispiel 899 umfasst den Gegenstand eines oder mehrerer der Beispiele 896-898, einschließlich der Feststellung, ob der Fahrer für eine Übergabe bereit ist.
• Beispiel 900 umfasst den Gegenstand von Beispiel 899, einschließlich der Übergabe der Kontrolle des Fahrzeugs an den Fahrer ansprechend auf die Feststellung, dass der Fahrer für die Übergabe bereit ist.
• Beispiel 901 umfasst den Gegenstand von Beispiel 899, einschließlich der Berechnung einer Alternative zu einer Übergabe, wenn der Fahrer nicht auf die Übergabe vorbereitet ist.
• Beispiel 902 umfasst den Gegenstand von Beispiel 901, wobei die Alternative das Finden einer alternativen Route umfasst.
• Beispiel 903 umfasst den Gegenstand von Beispiel 901, wobei die Alternative darin besteht, das Fahrzeug zum Stillstand zu bringen.
• Beispiel 904 umfasst den Gegenstand eines oder mehrerer der Beispiele 896-903, einschließlich der Aktualisierung der Informationen, die sich auf die Merkmale des Fahrers beziehen.
• Beispiel 905 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Beispiele 896-904.
• Beispiel 906 schließt den Gegenstand von Beispiel 905 ein, wobei das Mittel mindestens ein maschinenlesbares Medium mit Anweisungen umfasst, wobei die Anweisungen, wenn sie ausgeführt werden, ein Verfahren von einem oder mehreren der Beispiele 896-904 implementieren.
• Beispiel 907 ist ein System, das Folgendes umfasst: ein Modul zur Überwachung der Aktivität von Insassen; eine personalisierte Datenbank für die Fähigkeiten von Insassen; eine allgemeine Datenbank für die Fähigkeiten von Insassen; ein Modul zur Vorhersage von Übergaben; ein Modul zur Bewertung und Optimierung der Ausführung; und ein Modul zur Handhabung von Übergaben.
• Beispiel 908 ist ein System, das Folgendes umfasst: einen Speicher; einen mit dem Speicher verbundenen Prozessor; ein Sicherheitsmodul; und ein Bewertungsmodul zur Bestimmung eines Autonomiegrades eines Fahrzeugs, die zumindest teilweise auf dem Zustand der Sensoren des Fahrzeugs basiert.
• Beispiel 909 umfasst den Gegenstand von Beispiel 908, ferner eine Anzeige für den Automatisierungsgrad, um die Bewertung des Autonomiegrades anzuzeigen.
• Beispiel 910 umfasst den Gegenstand eines oder mehrerer der Beispiele 908-909, wobei die mindestens eine Eingabe Daten umfasst, die sich auf einen oder mehrere Sensoren beziehen.
• Beispiel 911 umfasst den Gegenstand eines oder mehrerer der Beispiele 908-910, wobei die mindestens eine Eingabe Daten zu den Wetterbedingungen umfasst.
• Beispiel 912 umfasst den Gegenstand eines oder mehrerer der Beispiele 908-911, wobei die mindestens eine Eingabe Daten umfasst, die sich auf die dem Fahrzeug zur Verfügung stehende Rechenleistung beziehen.
• Beispiel 913 umfasst den Gegenstand eines oder mehrerer der Beispiele 908-912, wobei die mindestens eine Eingabe Daten umfasst, die sich auf eine Fahrzeuganpassung beziehen.
• Beispiel 914 umfasst den Gegenstand eines oder mehrerer der Beispiele 908-913, wobei die mindestens eine Eingabe Daten umfasst, die sich auf eine Benutzererfahrung beziehen.
• Beispiel 915 ist ein Verfahren, das Folgendes umfasst: Empfangen einer Mehrzahl von Eingaben, die sich auf ein Fahrzeug beziehen; Gewichten der Mehrzahl von Eingaben; Kombinieren der Mehrzahl von gewichteten Eingaben; und Verwenden der kombinierten gewichteten Eingaben, um eine Bewertung des Autonomiegrades für das Fahrzeug zu bestimmen.
• Beispiel 916 umfasst den Gegenstand von Beispiel 915, einschließlich der Anzeige des Autonomiegrades auf einer Automatisierungsgradanzeige.
• Beispiel 917 umfasst den Gegenstand eines oder mehrerer der Beispiele 915-916, einschließlich der Aktualisierung der Informationen über die Merkmale des Fahrers.
• Beispiel 918 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Beispiele 915-917.
• Beispiel 919 umfasst den Gegenstand von Beispiel 918, wobei das Mittel mindestens ein maschinenlesbares Medium mit Anweisungen umfasst, wobei die Anweisungen, wenn sie ausgeführt werden, ein beliebiges Verfahren von einem oder mehreren der Beispiele 915-917 implementieren.
• Beispiel 920 ist ein Verfahren, das Folgendes umfasst: Bestimmen, ob die Abmessungen eines Fahrzeugs geändert wurden; Ermitteln neuer Fahrzeugabmessungen; Erstellen eines neuen Fahrzeugmodells auf der Grundlage der neuen Fahrzeugabmessungen; und Anpassen eines oder mehrerer Algorithmen eines autonomen Fahrzeugstapels auf der Grundlage des neuen Fahrzeugmodells.
• Beispiel 921 umfasst den Gegenstand von Beispiel 920, wobei die Bestimmung, ob die Abmessungen eines Fahrzeugs geändert wurden, die Verwendung eines Sensors umfasst, um festzustellen, dass eine Anhängevorrichtung eingerastet ist.
• Beispiel 922 umfasst den Gegenstand eines oder mehrerer der Beispiele 920-921, wobei die Ermittlung neuer Fahrzeugabmessungen die Durchführung eines Ultraschallscans umfasst.
• Beispiel 923 umfasst den Gegenstand eines oder mehrerer der Beispiele 920-921, wobei die Ermittlung neuer Fahrzeugabmessungen das Scannen des Fahrzeugs während einer Begehung umfasst.
• Beispiel 924 umfasst den Gegenstand von Beispiel 923, wobei das Scannen während der Begehung die Verwendung eines Smartphones umfasst.
• Beispiel 925 umfasst den Gegenstand eines oder mehrerer der Beispiele 920 bis 924, einschließlich der Aufforderung an den Fahrer, die neuen Fahrzeugabmessungen anzugeben, wenn sich die Fahrzeugabmessungen geändert haben.
• Beispiel 926 umfasst den Gegenstand eines oder mehrerer der Beispiele 920-925, einschließlich der Bestimmung eines Autonomiegrades des Fahrzeugs, nachdem die Abmessungen des Fahrzeugs geändert wurden.
• Beispiel 927 umfasst den Gegenstand eines oder mehrerer der Beispiele 920 bis 926, einschließlich der Verwendung von Sensoren zur Validierung der neuen Fahrzeugabmessungen.
• Beispiel 928 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Beispiele 920-927.
• Beispiel 929 ist ein nicht-transitorisches, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von der Maschine ausgeführt werden, die Maschine veranlassen: zu bestimmen, ob die Abmessungen eines Fahrzeugs geändert wurden; neue Fahrzeugabmessungen zu erhalten; ein neues Fahrzeugmodell auf der Grundlage der neuen Fahrzeugabmessungen zu erstellen; und einen oder mehrere Algorithmen eines autonomen Fahrzeugstapels auf der Grundlage des neuen Fahrzeugmodells anzupassen.
• Beispiel 930 umfasst den Gegenstand von Beispiel 929, wobei die Bestimmung, ob die Abmessungen eines Fahrzeugs geändert wurden, die Verwendung eines Sensors umfasst, um festzustellen, dass eine Anhängevorrichtung eingerastet ist.
• Beispiel 931 umfasst den Gegenstand eines oder mehrerer der Beispiele 929-930, wobei die Ermittlung neuer Fahrzeugabmessungen die Durchführung eines Ultraschallscans umfasst.
• Beispiel 932 umfasst den Gegenstand eines oder mehrerer der Beispiele 929-930, wobei die Ermittlung neuer Fahrzeugabmessungen das Scannen des Fahrzeugs während einer Begehung umfasst.
• Beispiel 933 umfasst den Gegenstand von Beispiel 932, wobei das Scannen während der Begehung die Verwendung eines Smartphones umfasst.
• Beispiel 934 umfasst den Gegenstand eines oder mehrerer der Beispiele 929 bis 933, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, einen Fahrer nach den neuen Fahrzeugabmessungen zu fragen, wenn sich die Fahrzeugabmessungen geändert haben.
• Beispiel 935 umfasst den Gegenstand eines oder mehrerer der Beispiele 929 bis 934, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, einen Autonomiegrad des Fahrzeugs zu bestimmen, nachdem die Abmessungen des Fahrzeugs geändert wurden.
• Beispiel 936 umfasst den Gegenstand eines oder mehrerer der Beispiele 929 bis 935, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, Sensoren zur Validierung der neuen Fahrzeugabmessungen zu verwenden.
• Beispiel 937 umfasst eine Vorrichtung, die mindestens eine Schnittstelle zum Empfangen von Sensordaten von einer Mehrzahl von Sensoren eines Fahrzeugs und einen oder mehrere Prozessoren zum autonomen Steuern des Fahrens des Fahrzeugs gemäß einem Pfadplan auf der Grundlage der Sensordaten, zum Bestimmen, dass die autonome Steuerung des Fahrzeugs beendet werden sollte, zum Senden einer Übergabeanforderung an ein entferntes Rechensystem, wobei das entfernte Rechensystem einen Remote-Valet-Service bereitstellt, zum Empfangen von Fahranweisungsdaten von dem entfernten Rechensystem und zum Steuern des Fahrens des Fahrzeugs auf der Grundlage von in den Fahranweisungsdaten umfassten Anweisungen umfasst.
• Beispiel 938 umfasst das Beispiel von Beispiel 937, wobei die Fahranweisungsdaten auf der Grundlage von Eingaben eines menschlichen Benutzers am entfernten Rechensystem erzeugt werden.
• Beispiel 939 umfasst eines der Beispiele 937-938, wobei der eine oder die mehreren Prozessoren ein Anhalte-Ereignis erkennen, wobei das Fahrzeug in Verbindung mit dem Anhalte-Ereignis anhält und aufhört zu fahren, wobei die Übergabeanforderung in Reaktion auf das Anhalte-Ereignis gesendet wird.
• Beispiel 940 umfasst eines der Beispiele 937-938, wobei die Bestimmung, dass die autonome Steuerung des Fahrzeugs beendet werden sollte, die Vorhersage unter Verwendung eines bestimmten Maschinelles-Lernen-Modells umfasst, dass die Bedingungen auf einem bevorstehenden Abschnitt des Pfadplans Schwierigkeiten für das autonome Fahren während des bevorstehenden Abschnitts darstellen.
• Beispiel 941 umfasst eines der Beispiele 937-940, wobei der eine oder die mehreren Prozessoren bestimmen, dass die autonome Steuerung des Fahrzeugs aufgrund der Erkennung eines oder mehrerer beeinträchtigter Sensoren des Fahrzeugs beendet werden sollte.
• Beispiel 942 umfasst eines der Beispiele 937-941, wobei der eine oder die mehreren Prozessoren feststellen, dass keine qualifizierten Fahrgäste im Fahrzeug anwesend sind, wobei die Übergabeanforderung zumindest teilweise aufgrund der Feststellung, dass keine qualifizierten Fahrgäste anwesend sind, gesendet wird.
• Beispiel 943 umfasst eines der Beispiele 937-942, wobei der eine oder mehrere Prozessoren die Sensordaten an das entfernte Rechensystem senden, um einem Benutzer des entfernten Rechensystems eine dynamische Darstellung der Umgebung des Fahrzeugs zu präsentieren.
• Beispiel 944 umfasst die Vorrichtung aus Beispiel 943, wobei die Sensordaten Videodaten umfassen.
• Beispiel 945 umfasst eines der Beispiele 937-944, wobei der eine oder die mehreren Prozessoren eine Warnung für den Verbrauch durch die Fahrgäste des Fahrzeugs übermitteln, um anzuzeigen, dass die Kontrolle über das Fahrzeug an den Remote-Valet-Service übergeben wurde.
• Beispiel 946 umfasst die Vorrichtung aus einem der Beispiele 937-945, wobei der eine oder die mehreren Prozessoren eine Änderung der Bedingungen entlang des Streckenplans erkennen und die Kontrolle über das Fahren des Fahrzeugs von dem Remote-Valet-Service an die autonome Fahrlogik des Fahrzeugs zurückgeben.
• Beispiel 947 ist ein Verfahren, das Folgendes umfasst: autonomes Steuern des Fahrens eines Fahrzeugs gemäß einem Pfadplan auf der Grundlage von Sensordaten, die von einem Satz von Sensoren eines Fahrzeugs erzeugt werden; Bestimmen, dass die autonome Steuerung des Fahrzeugs beendet werden sollte; Senden einer Übergabeanforderung an ein entferntes Rechensystem, wobei das entfernte Rechensystem einen Remote-Valet-Service bereitstellt; Empfangen von Fahranweisungsdaten von dem entfernten Rechensystem; und Steuern des Fahrens des Fahrzeugs auf der Grundlage von Anweisungen, die in den Fahranweisungsdaten umfassen sind.
• Beispiel 948 umfasst das Verfahren von Beispiel 947, wobei die Fahranweisungsdaten auf der Grundlage von Eingaben eines menschlichen Benutzers am entfernten Rechensystem erzeugt werden.
• Beispiel 949 umfasst das Verfahren aus einem der Beispiele 947-948, das ferner das Erkennen eines Anhalte-Ereignisses umfasst, wobei das Fahrzeug in Verbindung mit dem Anhalte-Ereignis anhält und aufhört zu fahren, wobei die Übergabeanforderung in Reaktion auf das Anhalte-Ereignis gesendet wird.
• Beispiel 950 umfasst das Verfahren aus einem der Beispiele 947-948, wobei die Bestimmung, dass die autonome Steuerung des Fahrzeugs beendet werden sollte, die Vorhersage unter Verwendung eines bestimmten Maschinelles-Lernen-Modells umfasst, dass die Bedingungen auf einem bevorstehenden Abschnitt des Pfadplans Schwierigkeiten für das autonome Fahren während des bevorstehenden Abschnitts darstellen.
• Beispiel 951 umfasst das Verfahren aus einem der Beispiele 947-950, wobei bestimmt wird, dass die autonome Steuerung des Fahrzeugs aufgrund der Erkennung eines oder mehrerer beeinträchtigter Sensoren am Fahrzeug beendet werden sollte.
• Beispiel 952 umfasst das Verfahren aus einem der Beispiele 947-951, das ferner die Feststellung umfasst, dass keine qualifizierten Fahrgäste im Fahrzeug anwesend sind, wobei die Übergabeanforderung zumindest teilweise auf der Grundlage der Feststellung gesendet wird, dass keine qualifizierten Fahrgäste anwesend sind.
• Beispiel 953 umfasst das Verfahren nach einem der Beispiele 947-952, das ferner das Senden der Sensordaten an das entfernte Rechensystem umfasst, um einem Benutzer des entfernten Rechensystems eine dynamische Darstellung der Umgebung des Fahrzeugs zu präsentieren.
• Beispiel 954 umfasst das Verfahren von Beispiel 953, wobei die Sensordaten Videodaten umfassen.
• Beispiel 955 schließt eines der Beispiele 947-954 ein und umfasst ferner die Darstellung einer Warnung für den Konsum durch die Fahrgäste des Fahrzeugs, um anzuzeigen, dass die Kontrolle über das Fahrzeug an den Remote-Valet-Service übergeben wurde.
• Beispiel 956 umfasst das Verfahren nach einem der Beispiele 947-955, das ferner das Erkennen einer Änderung der Bedingungen entlang des Streckenplans und die Wiederherstellung der Kontrolle über das Fahren des Fahrzeugs vom Remote-Valet-Service zur autonomen Fahrlogik des Fahrzeugs umfasst.
• Beispiel 957 umfasst ein System, das Mittel zur autonomen Steuerung des Fahrens eines Fahrzeugs gemäß einem Pfadplan auf der Grundlage von Sensordaten, die von einem Satz von Sensoren eines Fahrzeugs erzeugt werden, umfasst; Mittel zur Bestimmung, dass die autonome Steuerung des Fahrzeugs beendet werden sollte; Mittel zum Senden einer Übergabeanforderung an ein entferntes Rechensystem, wobei das entfernte Rechensystem einen Remote-Valet-Service bereitstellt; Mittel zum Empfangen von Fahranweisungsdaten von dem entfernten Rechensystem; und Mittel zur Steuerung des Fahrens des Fahrzeugs auf der Grundlage von Anweisungen, die in den Fahranweisungsdaten umfassen sind.
• Beispiel 958 umfasst das System aus Beispiel 957, wobei die Fahranweisungsdaten auf der Grundlage von Eingaben eines menschlichen Benutzers an dem entfernten Rechensystem erzeugt werden.
• Beispiel 959 umfasst das System aus einem der Beispiele 957-958, das ferner Mittel zum Erkennen eines Anhalte-Ereignisses umfasst, wobei das Fahrzeug in Verbindung mit dem Anhalte-Ereignis anhalten und die Fahrt beenden soll, wobei die Übergabeanforderung ansprechend auf das Anhalte-Ereignis gesendet wird.
• Beispiel 960 umfasst das System aus Beispiel 957, wobei die Bestimmung, dass die autonome Steuerung des Fahrzeugs beendet werden sollte, die Vorhersage unter Verwendung eines bestimmten Maschinelles-Lernen-Modells umfasst, dass die Bedingungen auf einem bevorstehenden Abschnitt des Pfadplans Schwierigkeiten für das autonome Fahren während des bevorstehenden Abschnitts darstellen.
• Beispiel 961 umfasst ein computerlesbares Medium zum Speichern von Anweisungen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, Folgendes durchzuführen: autonomes Steuern des Fahrens eines Fahrzeugs gemäß einem Pfadplan auf der Grundlage von Sensordaten, die von einem Satz von Sensoren eines Fahrzeugs erzeugt werden; Bestimmen, dass die autonome Steuerung des Fahrzeugs beendet werden sollte; Senden einer Übergabeanforderung an ein entferntes Rechensystem, wobei das entfernte Rechensystem einen Remote-Valet-Service bereitstellt; Empfangen von Fahranweisungsdaten von dem entfernten Rechensystem; und Steuern des Fahrens des Fahrzeugs auf der Grundlage von in den Fahranweisungsdaten umfassten Anweisungen.
• Beispiel 962 umfasst ein Verfahren, das Folgendes umfasst: Bereitstellen einer Benutzerschnittstelle für einen menschlichen Benutzer an einem Computerendgerät; Empfangen einer Übergabeanforderung von einem Fahrzeug, das zum autonomen Fahren ausgebildet ist; Empfangen von Sensordaten von entfernten Sensorvorrichtungen, die eine Umgebung um das Fahrzeug herum beschreiben; Darstellen einer Darstellung der Umgebung auf der Benutzerschnittstelle auf der Grundlage der Sensordaten; Empfangen von Benutzereingaben an dem Computerendgerät ansprechend auf die Darstellung, wobei die Benutzereingaben Eingaben zum Lenken des Fahrens des Fahrzeugs in der Umgebung umfassen; und Senden von Anweisungsdaten an das Fahrzeug entsprechend den Benutzereingaben, um das Fahrzeug entsprechend den Benutzereingaben fernzusteuern.
• Beispiel 963 umfasst das Verfahren von Beispiel 962, wobei die ÜbergabeAnforderung einen Standort des Fahrzeugs identifiziert.
• Beispiel 964 umfasst das Verfahren von Beispiel 963, ferner das Bestimmen von Sensorvorrichtungen, die dem Standort entsprechen, wobei sich die Sensorvorrichtungen außerhalb des Fahrzeugs befinden; und das Zugreifen auf zusätzliche Sensordaten von den Sensorvorrichtungen, wobei die Darstellung zumindest teilweise auf der Grundlage der zusätzlichen Sensordaten dargestellt wird.
• Beispiel 965 umfasst das Verfahren aus einem der Beispiele 962-964, wobei die Sensorvorrichtungen Sensorvorrichtungen am Fahrzeug umfassen.
• Beispiel 966 umfasst das Verfahren nach einem der Beispiele 962-965, wobei die Sensorvorrichtungen vom Fahrzeug getrennte Sensorvorrichtungen umfassen.
• Beispiel 967 umfasst das Verfahren nach einem der Beispiele 962-966, das ferner den Empfang einer Aufforderung vom Fahrzeug umfasst, die Kontrolle über den Antrieb des Fahrzeugs an das Fahrzeug zurückzugeben; das Senden einer Bestätigung der Rückgabe der Kontrolle an das Fahrzeug; und das Beenden der Übertragung der Anweisungsdaten an das Fahrzeug.
• Beispiel 968 umfasst das Verfahren aus einem der Beispiele 962-966, das ferner das Erzeugen von Berichtsdaten umfasst, die die Umgebung und die Leistung des Fahrzeugs auf der Grundlage der Benutzereingaben während der Steuerung des Fahrzeugs durch den Remote-Valet-Service beschreiben, und das Senden der Berichtsdaten an ein cloudbasiertes System.
• Beispiel 969 umfasst ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 962-968.
• Beispiel 970 schließt das System von Beispiel 969 ein, wobei die Mittel ein computerlesbares Medium zum Speichern von Anweisungen umfassen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, zumindest einen Teil des Verfahrens von einem der Beispiele 962-968 durchzuführen.
• Beispiel 971 umfasst ein Verfahren, das Folgendes umfasst: Erzeugen von Sensordaten von einem Satz von Sensoren an einem Fahrzeug; Bestimmen eines Pfadplans für das Fahrzeug; autonomes Steuern des Fahrens des Fahrzeugs gemäß dem Pfadplan auf der Grundlage von einem oder mehreren Maschinelles-Lernen-Modellen und den Sensordaten; Identifizieren von Bedingungen auf einem bevorstehenden Abschnitt des Pfadplans; Bestimmen einer Gelegenheit, die Steuerung des Fahrens des Fahrzeugs auf der Grundlage der Bedingungen an einen Remote-Valet-Service zu übergeben; Senden einer Übergabeanforderung an ein entferntes Rechensystem auf der Grundlage der Gelegenheit, wobei das entfernte Rechensystem den Remote-Valet-Service bereitstellt; Empfangen von Fahranweisungsdaten von dem entfernten Rechensystem; und Automatisieren des Fahrens des Fahrzeugs in Reaktion auf Anweisungen, die in den Anweisungsdaten umfassen sind.
• Beispiel 972 umfasst das Verfahren von Beispiel 971, das ferner das Senden von Berichtsdaten an ein anderes Rechensystem umfasst, die die Übergabe und die der Übergabe entsprechenden Bedingungen identifizieren.
• Beispiel 973 umfasst das Verfahren von Beispiel 972, wobei die Berichtsdaten an eine Cloud-basierte Anwendung gesendet werden.
• Beispiel 974 umfasst das Verfahren aus einem der Beispiele 972-973, wobei die Berichtsdaten an eine straßenseitige Einheit gesendet werden.
• Beispiel 975 umfasst das Verfahren aus einem der Beispiele 971-974, wobei die Bedingungen anhand von Daten identifiziert werden, die von einem anderen Rechensystem empfangen wurden.
• Beispiel 976 umfasst das Verfahren von Beispiel 975, wobei die Bedingungen durch Anwendung eines Maschinelles-Lernen-Modells identifiziert werden und die Daten von dem anderen System als Eingabe für das Maschinelles-Lernen-Modell bereitgestellt werden.
• Beispiel 977 umfasst das Verfahren von Beispiel 976, wobei das Maschinelles-Lernen-Modell auf der Grundlage von Daten trainiert wird, die andere Fälle von entweder einer Übergabe an einen Remote-Valet-Service oder ein Anhalte-Ereignis melden.
• Beispiel 978 umfasst das Verfahren aus einem der Beispiele 971-977, wobei die Weiterreichungsanforderung gesendet wird, um ein Anhalte-Ereignis zu vermeiden.
• Beispiel 979 umfasst das Verfahren nach einem der Beispiele 971-978, wobei die Gelegenheit einer Vorhersage entspricht, dass die autonome Fahrfunktion des Fahrzeugs angesichts der Bedingungen schlecht funktionieren wird.
• Beispiel 980 umfasst das Verfahren aus einem der Beispiele 971-979, wobei die Gelegenheit zumindest teilweise auf der Grundlage von in den Sensordaten umfassten Informationen bestimmt wird.
• Beispiel 981 umfasst das Verfahren nach einem der Beispiele 971-980, das ferner Folgendes umfasst: Zugreifen auf zusätzliche Daten; Vorhersagen einer Verbesserung der Bedingungen auf einem anderen Abschnitt des Pfadplans, der dem bevorstehenden Weg folgt, auf der Grundlage der zusätzlichen Daten; und Senden von Anforderungsdaten an das entfernte Rechensystem, um anzufordern, dass die Steuerung auf der Grundlage der vorhergesagten Verbesserung der Bedingungen an das Fahrzeug zurückgegeben wird; und Wiederaufnahme der autonomen Steuerung des Fahrens des Fahrzeugs.
• Beispiel 982 umfasst das Verfahren aus einem der Beispiele 971-981, wobei die Bestimmung der Gelegenheit zur Übergabe der Kontrolle die Erfassung eines Überziehvorgangs umfasst.
• Beispiel 983 umfasst das Verfahren von Beispiel 982, ferner das Bestimmen von Bedingungen aus den Sensordaten, die mit dem Anhalte-Ereignis verbunden sind; und das Hochladen von Daten, die die Bedingungen beschreiben, zu einem entfernten Rechensystem.
• Beispiel 984 umfasst ein System mit Mitteln zur Durchführung des Verfahrens nach einem der Beispiele 971-983.
• Beispiel 985 schließt das System von Beispiel 984 ein, wobei die Mittel ein computerlesbares Medium zum Speichern von Anweisungen umfassen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, mindestens einen Teil des Verfahrens von einem der Beispiele 971-983 durchzuführen.
• Beispiel 986 ist ein Verfahren, das das Erhalten von Sensordaten von einem Sensor, der mit einem autonomen Fahrzeug gekoppelt ist, das Anwenden eines Sensorabstraktionsprozesses auf die Sensordaten, um abstrahierte Szenendaten zu erzeugen, wobei der Sensorabstraktionsprozess einen oder mehrere der folgenden Schritte umfasst: Anwenden eines Antwortnormalisierungsprozesses auf die Sensordaten; Anwenden eines Warp-Prozesses auf die Sensordaten; und Anwenden eines Filterprozesses auf die Sensordaten; und Verwenden der abstrahierten Szenendaten in einer Wahrnehmungsphase eines Steuerprozesses für das autonome Fahrzeug.
• Beispiel 987 umfasst den Gegenstand von Beispiel 986, wobei die Sensordaten erste Sensordaten von einem ersten Sensor und zweite Sensordaten von einem zweiten Sensor umfassen, wobei der erste Sensor und der zweite Sensor vom gleichen Sensortyp sind und die Anwendung des Sensorabstraktionsprozesses einen oder mehrere der folgenden Schritte umfasst: Anwendung eines jeweiligen Antwortnormalisierungsprozesses auf die ersten Sensordaten und die zweiten Sensordaten; Anwendung eines jeweiligen Verzerrungs-Prozesses auf die ersten Sensordaten und die zweiten Sensordaten; und Anwendung eines Filterungsprozesses auf eine Kombination der ersten Sensordaten und der zweiten Sensordaten.
• Beispiel 988 umfasst den Gegenstand von Beispiel 986, wobei die Sensordaten erste Sensordaten von einem ersten Sensor und zweite Sensordaten von einem zweiten Sensor umfassen, wobei der erste Sensor und der zweite Sensor unterschiedliche Sensortypen sind, und die Anwendung des Sensorabstraktionsprozesses eines oder mehrere der folgenden umfasst: anwenden eines jeweiligen Antwortnormalisierungsprozesses auf die ersten Sensordaten und die zweiten Sensordaten; Anwenden eines jeweiligen Verzerrungs-Prozesses auf die ersten Sensordaten und die zweiten Sensordaten; und Anwenden eines jeweiligen Filterungsprozesses auf die ersten Sensordaten und die zweiten Sensordaten, um erste abstrahierte Szenendaten, die den ersten Sensordaten entsprechen, und zweite abstrahierte Szenendaten, die den zweiten Sensordaten entsprechen, zu erzeugen; und das Verfahren ferner das Anwenden eines Fusionsprozesses auf die ersten und zweiten abstrahierten Szenendaten umfasst; wobei die fusionierten ersten und zweiten abstrahierten Szenendaten in der Wahrnehmungsphase verwendet werden.
• Beispiel 989 umfasst den Gegenstand eines der Beispiele N1-988, wobei die Anwendung eines Antwortnormalisierungsprozesses eines oder mehrere der folgenden Verfahren umfasst: Normalisieren von Pixelwerten eines Bildes, Normalisieren einer Bittiefe eines Bildes, Normalisieren eines Farbraums eines Bildes und Normalisieren eines Bereichs von Tiefen- oder Entfernungswerten in Lidar-Daten.
• Beispiel 990 umfasst den Gegenstand eines der Beispiele 986-988, wobei die Anwendung eines Antwortnormalisierungsprozesses auf einem Modell der Sensorantwort basiert.
• Beispiel 991 umfasst den Gegenstand eines der Beispiele 986-988, wobei die Anwendung eines Verzerrungsprozesses die Durchführung einer oder mehrerer räumlicher Hochskalierungsoperationen, einer Herunterskalierungsoperation, eines Korrekturprozesses für geometrische Effekte, die mit dem Sensor verbunden sind, und eines Korrekturprozesses für Bewegungen des Sensors umfasst.
• Beispiel 992 umfasst den Gegenstand eines der Beispiele 986-988, wobei die Anwendung eines Verformungsprozesses auf Sensorkonfigurationsinformationen basiert.
• Beispiel 993 umfasst den Gegenstand eines der Beispiele 986-988, wobei die Anwendung eines Filterprozesses die Anwendung eines oder mehrerer Kalman-Filter, einer Variante des Kalman-Filters, eines Partikelfilters, eines Histogrammfilters, eines Informationsfilters, eines Bayes-Filters und eines Gauß-Filters umfasst.
• Beispiel 994 umfasst den Gegenstand eines der Beispiele 986-988, wobei die Anwendung eines Filterungsprozesses auf einem oder mehreren Modellen für den Sensor und einem Szenenmodell basiert.
• Beispiel 995 umfasst den Gegenstand eines der Beispiele 986-988, wobei die Anwendung eines Filterprozesses die Bestimmung einer Gültigkeit der Sensordaten und das Verwerfen der Sensordaten ansprechend auf die Bestimmung, dass die Sensordaten ungültig sind, umfasst.
• Beispiel 996 ist eine Vorrichtung, die einen Speicher und eine mit dem Speicher verbundene Verarbeitungsschaltung umfasst, um eines oder mehrere der Verfahren der Beispiele 986-995 durchzuführen.
• Beispiel 997 ist ein System mit Mittel zur Durchführung eines oder mehrerer der Verfahren der Beispiele 986-995.
• Beispiel 998 ist ein Produkt, das ein oder mehrere greifbare, computerlesbare, nichttransitorische Speichermedien umfasst, die computerausführbare Anweisungen umfassen, die, wenn sie von mindestens einem Computerprozessor ausgeführt werden, den mindestens einen Computerprozessor in die Lage versetzen, Operationen der Verfahren der Beispiele 986-995 zu implementieren.
• 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/826955 [0001]

Claims (50)

1. Zumindest ein nichtflüchtiges, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen zum: Empfangen von Sensordaten von einer Mehrzahl von Sensoren, wobei die Mehrzahl von Sensoren einen ersten Satz von Sensoren und einen zweiten Satz von Sensoren umfasst und zumindest ein Abschnitt der Mehrzahl von Sensoren mit einem Fahrzeug gekoppelt ist; Automatisieren der Steuerung des Fahrzeugs unter Verwendung eines Prozessors in dem Fahrzeug basierend auf zumindest einem Abschnitt der von dem ersten Satz von Sensoren erzeugten Sensordaten; Bestimmen, unter Verwendung eines Prozessors in dem Fahrzeug, von Insassenattributen eines oder mehrerer Insassen innerhalb des autonomen Fahrzeugs aus Sensordaten, die von dem zweiten Satz von Sensoren erzeugt wurden; und Modifizieren von Fahrzeugattributen des Fahrzeugs basierend auf den Insassenattributen und den Sensordaten, die von dem ersten Satz von Sensoren erzeugt wurden.
2. Das Speichermedium nach Anspruch 1, wobei die automatische Steuerung des Fahrzeugs ein Bestimmen eines ersten Pfades des Fahrzeugs und ein Modifizieren der Fahrzeugattribute basierend auf den Insassenattributen, um den ersten Pfad in einen zweiten Pfad zu ändern und damit die anschließende automatische Steuerung des Fahrzeugs auf dem zweiten Pfad basiert, umfasst.
3. Das Speichermedium nach einem der Ansprüche 1-2, wobei die Fahrzeugattribute physikalische Attribute einer Kabine des Fahrzeugs umfassen und die Insassen sich in der Kabine befinden.
4. Das Speichermedium nach Anspruch 3, wobei die Kabine eine oder mehrere Vorrichtungen umfasst, die so ausgebildet sind, dass sie den Komfort der Insassen erleichtern, und das Modifizieren der Fahrzeugattribute ein autonomes Einstellen der einen oder der mehreren Vorrichtungen umfasst.
5. Das Speichermedium nach einem der Ansprüche 1-4, wobei das Modifizieren der Fahrzeugattribute ein Präsentieren einer Empfehlung an die Insassen unter Verwendung einer Benutzerschnittstellenvorrichtung basierend auf einem Navigationsplan, der mit der automatischen Steuerung des Fahrzeugs und den Insassenattribute zugeordnet ist, umfasst.
6. Das Speichermedium nach Anspruch 5, wobei die Empfehlung eine Empfehlung zum Ändern eines Ziels oder einer Route des Fahrzeugs basierend auf den Insassenattributen umfasst.
7. Das Speichermedium nach einem der Ansprüche 1-6, wobei die Insassenattribute Attribute umfassen, die den Komfort, die Präferenzen oder die Bedürfnisse des einen oder der mehreren Insassen innerhalb des Fahrzeugs beeinflussen.
8. Das Speichermedium nach einem der Ansprüche 1-7, wobei die automatische Steuerung des Fahrzeugs unter Verwendung eines ersten Maschinelles-Lernen-Modells bestimmt wird und die Insassenattribute unter Verwendung eines zweiten Maschinelles-Lernen-Modells bestimmt werden.
9. Das Speichermedium nach einem der Ansprüche 1-8, wobei die Fahrzeugattribute einen Fahrstil umfassen, der durch die automatische Steuerung des Fahrzeugs implementiert werden soll, und das Modifizieren der Fahrzeugattribute den Fahrstil basierend auf den Insassenattributen ändert.
10. Das Speichermedium nach einem der Ansprüche 1-9, wobei der erste und der zweite Satz von Sensoren zumindest einen gemeinsamen Sensor umfassen.
11. Das Speichermedium nach einem der Ansprüche 1-10, wobei mindestens ein Sensor des ersten und des zweiten Satzes von Sensoren fahrzeugextern ist.
12. Das Speichermedium nach einem der Ansprüche 1-11, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen zum: Bestimmen der Identität eines oder mehrerer Insassen basierend auf Sensordaten aus dem zweiten Satz von Sensoren; und Zugreifen auf Präferenzinformationen, die den Identitäten des einen oder der mehreren Insassen entsprechen, wobei die Insassenattribute die Präferenzinformationen umfassen.
13. Das Speichermedium nach einem der Ansprüche 1-12, wobei die Insassenattribute menschliche Attribute der Insassen beschreiben.
14. Das Speichermedium nach Anspruch 13, wobei die Insassen eine Mehrzahl von Insassen umfassen und die menschlichen Attribute kombinierte Attribute einer Gruppe von Insassen umfassen, die die Mehrzahl von Insassen umfasst, und die Fahrzeugattribute basierend auf den kombinierten Attributen modifiziert werden.
15. Das Speichermedium nach einem der Ansprüche 1-14, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen zum: Senden bestimmter Sensordaten, die Daten von dem ersten Satz von Sensoren oder dem zweiten Satz von Sensoren umfassen, über einen drahtlosen Kommunikationskanal an ein entferntes Rechensystem; und Empfangen von Empfehlungsdaten von dem entfernten Rechensystem basierend auf den bestimmten Sensordaten, wobei die Fahrzeugattribute basierend auf den Empfehlungsdaten modifiziert werden.
16. Ein Verfahren, umfassend: Empfangen von Sensordaten von einer Mehrzahl von Sensoren, wobei die Mehrzahl von Sensoren einen ersten Satz von Sensoren und einen zweiten Satz von Sensoren umfasst und zumindest ein Abschnitt der Mehrzahl von Sensoren mit einem Fahrzeug gekoppelt ist; Automatisieren der Steuerung des Fahrzeugs unter Verwendung eines Datenprozessors auf dem Fahrzeug basierend auf zumindest einem Abschnitt der von dem ersten Satz von Sensoren erzeugten Sensordaten; Bestimmen, unter Verwendung eines Datenprozessors auf dem Fahrzeug, von Insassenattributen eines oder mehrerer Insassen innerhalb der autonomen Fahrzeuge aus Sensordaten, die von dem zweiten Satz von Sensoren erzeugt wurden; und Modifizieren von Fahrzeugattributen des Fahrzeugs, basierend auf den Insassenattributen und den Sensordaten, die von dem ersten Satz von Sensoren erzeugt wurden.
17. Das Verfahren nach Anspruch 16, wobei die automatische Steuerung des Fahrzeugs ein Bestimmen eines ersten Pfades des Fahrzeugs umfasst, und ein Modifizieren der Fahrzeugattribute basierend auf den Insassenattributen veranlasst, dass der erste Pfad in einen zweiten Pfad geändert wird und die anschließende automatische Steuerung des Fahrzeugs auf dem zweiten Pfad basiert.
18. Das Verfahren nach einem der Ansprüche 16-17, wobei die Fahrzeugattribute physikalische Attribute einer Kabine des Fahrzeugs umfassen und sich die Insassen in der Kabine befinden.
19. Das Verfahren nach einem der Ansprüche 16-18, wobei das Modifizieren der Fahrzeugattribute ein Präsentieren einer Empfehlung an die Insassen unter Verwendung einer Präsentationsvorrichtung umfasst, die auf einem Pfad basiert, der in Verbindung mit der automatischen Steuerung des Fahrzeugs und den Insassenattribute bestimmt wird.
20. Das Verfahren nach einem der Ansprüche 16-19, wobei die Fahrzeugattribute einen Fahrstil umfassen, der durch die automatische Steuerung des Fahrzeugs implementiert werden soll, und das Modifizieren der Fahrzeugattribute veranlasst, dass der Fahrstil basierend auf den Insassenattributen geändert wird.
21. Ein System, umfassend Mittel zum Ausführen des Verfahrens gemäß einem der Ansprüche 16-20.
22. Zumindest ein nichtflüchtiges, maschinenlesbares Speichermedium mit darauf gespeicherten Anweisungen, wobei die Anweisungen, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen zum: Empfangen von ersten Sensordaten, die von einem ersten Satz von Sensoren erzeugt werden, wobei die ersten Sensordaten Attribute einer Fahrumgebung identifizieren; Empfangen von zweiten Sensordaten, die von einem zweiten Satz von Sensoren erzeugt werden, wobei die zweiten Sensordaten Attribute eines Satzes von Insassen in einem bestimmten Fahrzeug in der Fahrumgebung identifizieren; Bestimmen einer Empfehlung basierend auf den ersten Sensordaten und den zweiten Sensordaten; Senden von Empfehlungsdaten über einen drahtlosen Kommunikationskanal an ein bordeigenes Rechensystem des bestimmten Fahrzeugs, wobei die Empfehlungsdaten die Empfehlung identifizieren und von dem bordeigenen Rechensystem verbraucht werden können, um den Betrieb des bestimmten Fahrzeugs zu beeinflussen.
23. Das Speichermedium nach Anspruch 22, wobei der erste Satz von Sensoren einen oder mehrere auf dem bestimmten Fahrzeug integrierte Sensoren umfasst.
24. Das Speichermedium nach einem der Ansprüche 22-23, wobei der erste Satz von Sensoren einen oder mehrere Sensoren, die extern zu dem bestimmten Fahrzeug sind, umfasst.
25. Das Speichermedium nach Anspruch 24, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen zum: Bestimmen eines Standortes des bestimmten Fahrzeugs; Identifizieren eines oder mehrerer bestimmter Sensoren an dem Standort; und Zugreifen auf bestimmte Sensordaten von den bestimmten Sensoren, wobei die ersten Sensordaten die bestimmten Sensordaten umfassen.
26. Das Speichermedium nach Anspruch 25, wobei der erste Satz von Sensoren einen oder mehrere Sensoren umfasst, die an einem anderen Fahrzeug an dem Standort befestigt sind.
27. Das Speichermedium nach einem der Ansprüche 25-26, wobei der erste Satz von Sensoren eine Straßenrandeinheit an dem Standort umfasst.
28. Das Speichermedium nach einem der Ansprüche 22-27, wobei die Anweisungen ferner ausführbar sind, um die Maschine zu veranlassen, aus den zweiten Sensordaten ein oder mehrere Profile zu bestimmen, die dem Satz von Insassen zugeordnet sind, wobei die Empfehlung auf dem einen oder den mehreren Profilen basiert.
29. Das Speichermedium nach einem der Ansprüche 22-28, wobei die Empfehlung von dem bordeigenen Rechensystem konsumiert werden kann, um das bordeigene Rechensystem zu veranlassen, die automatische Steuerung des bestimmten Fahrzeugs basierend auf der Empfehlung zu ändern.
30. Das Speichermedium nach Anspruch 29, wobei die Änderung der automatischen Steuerung das Fahrzeug veranlasst, von einem zuvor bestimmten Pfad abzuweichen.
31. Das Speichermedium nach einem der Ansprüche 29-30, wobei die Änderung der automatischen Steuerung veranlasst, dass das Fahrzeug basierend auf der Empfehlung von einem ersten Fahrstil zu einem zweiten Fahrstil wechselt.
32. Ein Verfahren, umfassend: Empfangen von ersten Sensordaten, die von einem ersten Satz von Sensoren erzeugt werden, wobei die ersten Sensordaten Attribute einer Fahrumgebung identifizieren; Empfangen von zweiten Sensordaten, die von einem zweiten Satz von Sensoren erzeugt werden, wobei die zweiten Sensordaten Attribute eines Satzes von Insassen in einem bestimmten Fahrzeug in der Fahrumgebung identifizieren; Bestimmen einer Empfehlung basierend auf den ersten Sensordaten und den zweiten Sensordaten; und Senden von Empfehlungsdaten über einen drahtlosen Kommunikationskanal an ein bordeigenes Rechensystem des bestimmten Fahrzeugs, wobei die Empfehlungsdaten die Empfehlung identifizieren und von dem bordeigenen Rechensystem verbraucht werden können, um den Betrieb des bestimmten Fahrzeugs zu beeinflussen.
33. Ein System umfassend ein Mittel zum Ausführen des Verfahrens nach Anspruch 32.
34. Ein System, umfassend: ein bordeigenes Rechensystem für ein Fahrzeug, wobei das bordeigene Rechensystem Prozessor-Hardware umfasst, wobei die Prozessor-Hardware eine Maschinelles-Lernen-Hardware umfasst; einen Satz lokaler Sensoren; einen Satz von Aktuatoren; und ein Empfehlungssystem, das durch die Prozessor-Hardware ausführbar ist zum: Identifizieren von ersten Sensordaten, um Fahrbedingungen in einer Umgebung zu beschreiben, wobei das Fahrzeug in oder nahe der Umgebung positioniert ist, wobei das bordeigene Rechensystem die ersten Sensordaten verwendet, um die Steuerung des Fahrzeugs zu automatisieren; Identifizieren von zweiten Sensordaten, wobei zumindest ein Teil der zweiten Sensordaten durch den Satz von lokalen Sensoren erzeugt wird; Bestimmen eines oder mehrerer Insassenattribute eines Satzes von Insassen innerhalb des Fahrzeugs aus den zweiten Sensordaten; Bestimmen einer Empfehlung für das bordeigene Rechensystem basierend auf den ersten und zweiten Sensordaten; wobei das bordeigene Rechensystem ausgebildet ist, die Empfehlung zu verbrauchen, um einen oder mehrere des Satzes von Aktuatoren zu betätigen, um Bedingungen des Fahrzeugs zu ändern.
35. Das System nach Anspruch 34, wobei der eine oder die mehreren Aktuatoren Aktuatoren zur Steuerung der Lenkung, der Beschleunigung oder des Bremsens des Fahrzeugs umfassen.
36. Das System nach Anspruch 35, wobei das bordeigene Rechensystem eine Pfadplanungsmaschine umfasst zum: Bestimmen eines ersten Pfadplans für das Fahrzeug; und Erweitern des ersten Pfadplans, um einen anderen, zweiten Pfadplan für das Fahrzeug basierend auf der Empfehlung zu bilden.
37. Das System nach Anspruch 34, wobei der eine oder die mehreren Aktuatoren Aktuatoren zum Anpassen physikalischer Bedingungen in einer Kabine des Fahrzeugs umfassen, wobei die Insassen in der Kabine des Fahrzeugs fahren.
38. Das System nach Anspruch 34, wobei zumindest ein Abschnitt der ersten Sensordaten von dem Satz von lokalen Sensoren erzeugt wird.
39. Das System nach Anspruch 34, wobei das Empfehlungssystem ausgebildet ist zum: Kommunizieren über einen drahtlosen Kommunikationskanal mit einem entfernten Rechensystem; und Empfangen von Empfehlungsdaten von dem entfernten Rechensystem, wobei die Empfehlung ferner basierend auf den Empfehlungsdaten bestimmt wird.
40. Das System nach Anspruch 34, wobei ein Abschnitt der ersten Sensordaten oder der zweiten Sensordaten von fahrzeugexternen Sensoren empfangen wird.
41. Ein Verfahren, umfassend: Erhalten von Sensordaten von einem Sensor, der mit einem autonomen Fahrzeug gekoppelt ist; Anwenden eines Sensorabstraktionsprozesses auf die Sensordaten, um abstrahierte Szenendaten zu erzeugen, wobei der Sensorabstraktionsprozess ein oder mehrere umfasst von: Anwenden eines Antwortnormalisierungsprozesses auf die Sensordaten; Anwenden eines Verzerrungsprozesses auf die Sensordaten; und Anwenden eines Filterprozesses auf die Sensordaten; und Verwenden der abstrahierten Szenendaten in einer Wahrnehmungsphase eines Steuerungsprozesses für das autonome Fahrzeug.
42. Ein Verfahren, umfassend: Erfassen erster Bilddaten durch einen ersten Sensor eines Fahrzeugs, wobei die ersten Bilddaten eine erste Auflösung aufweisen; Verwenden eines Maschinelles-Lernen-Modells, Transformieren der ersten Bilddaten in zweite Bilddaten mit einer zweiten Auflösung, wobei die zweite Auflösung höher ist als die erste Auflösung; und Ausführen von Objektdetektionsoperationen für das Fahrzeug basierend auf den zweiten Bilddaten.
43. Ein Verfahren, umfassend: Betreiben, durch eine Steuerung eines autonomen Fahrzeugs, AV, des AV in einem autonomen Fahrmodus; Empfangen einer Anforderung zur Übernahme der Steuerung des AV durch eine andere Entität als die Steuerung; Auffordern der anfordernden Entität nach Zugangsdaten ansprechend auf ein Empfangen der Anforderung zur Übernahme der Steuerung des AV; Empfangen einer Eingabe ansprechend auf die Aufforderung; und Zulassen der Anforderung zur Übernahme der Steuerung des AV ansprechend auf die Authentifizierung der anfordernden Entität basierend auf der empfangenen Eingabe.
44. Ein Verfahren, umfassend: Betreiben, durch ein Steuerungssystem eines autonomen Fahrzeugs, AV, des AV in einem autonomen Betriebsmodus basierend auf Sensordaten, die von einer Mehrzahl von mit dem AV gekoppelten Sensoren erhalten werden; Detektieren einer Übernahmeanforderung durch einen Insassen des AV durch das Steuersystem des AV; Bestimmen, ob die angeforderte Übernahme sicher ist, durch das Steuersystem des AV basierend auf den Sensordaten; und Blockieren der angeforderten Übernahme ansprechend auf eine Bestimmung, dass die angeforderte Übernahme nicht sicher ist.
45. Ein Verfahren zur Begrenzung des Autonomiegrades eines Fahrzeugs auf einem Straßenabschnitt, umfassend: Bestimmen einer Sicherheitsbewertung für ein Fahrzeug; Bestimmen einer Straßenbewertung für zumindest einen Abschnitt einer Straße; Vergleichen der Straßenbewertung mit der Sicherheitsbewertung; und Bestimmen des akzeptablen Autonomiegrades des Fahrzeugs auf dem zumindest einen Abschnitt der Straße.
46. Ein Verfahren, wobei das Verfahren umfasst: Empfangen eines Bildes, das von einer einem Fahrzeug zugeordneten Bilderfassungsvorrichtung erfasst wurde; Detektieren eines Gesichts in dem erfassten Bild; Erzeugen eines Eingabebildes für ein erstes neuronales Netzwerk eines Generative Adversarial Network, GAN, wobei das Eingabebild das in dem erfassten Bild detektierte Gesicht darstellt; Erzeugen eines unkenntlich gemachten Bildes, das zumindest teilweise auf der Anwendung des ersten neuronalen Netzwerks auf das Eingabebild basiert, wobei ein Blickattribut des in dem Eingabebild dargestellten Gesichts in dem unkenntlich gemachten Bild umfasst ist, und wobei ein oder mehrere andere Attribute des in dem Eingabebild dargestellten Gesichts in dem unkenntlich gemachten Bild modifiziert sind.
47. Ein Verfahren, umfassend: Empfangen von Sensordaten von einem mit einem autonomen Fahrzeug, AV, gekoppelten Sensor, Anwenden einer digitalen Signatur auf die Sensordaten; Hinzufügen eines neuen Blocks zu einer blockbasierten Topologie, wobei der neue Block die Sensordaten und die digitale Signatur umfasst; Verifizieren der digitalen Signatur; und Kommunizieren des Blocks an eine Logikeinheit des AV basierend darauf, dass die digitale Signatur verifiziert ist.
48. Ein Verfahren, umfassend: Bestimmen zumindest eines Übergabestandortes eines autonomen Fahrzeugs an einen Fahrer auf einer Route; Empfangen von Informationen, die sich auf Charakteristika eines Fahrers beziehen; Empfangen von Informationen, die sich auf einen aktuellen Aufmerksamkeitszustand des Fahrers beziehen; und Bestimmen des erwarteten Fahrerverhaltens während jeder der zumindest einen Übergabepositionen.
49. Ein Verfahren, umfassend: Bestimmen, durch ein Rechensystem eines Fahrzeugs, einer Signalqualitätsmetrik basierend auf Sensordaten und einem Kontext der Sensordaten; basierend auf der Signalqualitätsmetrik, Bestimmen einer Sicherheitswahrscheinlichkeit, die einer Übergabe der Steuerung des Fahrzeugs zugeordnet ist; und Verhindern der Übergabe oder Einleiten der Übergabe der Steuerung des Fahrzeugs basierend auf der Sicherheitswahrscheinlichkeit.
50. Ein Verfahren, umfassend: Bestimmen eines Systemfehlers eines autonomen Fahrzeugs; Bestimmen, dass ein Autonomiegrad des autonomen Fahrzeugs auf einen ersten Grad reduziert werden kann, der keine Übernahme durch den Fahrer erfordert; Warnen des Fahrers, dass der Autonomiegrad auf den ersten Grad reduziert werden wird; und Reduzieren des Autonomiegrades auf den ersten Grad.

Images