DE102020130668A1

DE102020130668A1 - Synchronisieren von erfassungssystemen

Info

Publication number: DE102020130668A1
Application number: DE102020130668.7A
Authority: DE
Inventors: Abraham Mezaael; Jeffrey Scott Blair; Christian Krozal
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2019-11-20
Filing date: 2020-11-19
Publication date: 2021-05-20
Also published as: CN112825202A; US11423708B2; US20210150828A1

Abstract

Die vorliegende Offenbarung stellt Synchronisieren von Erfassungssystemen bereit. Ein System beinhaltet einen Prozessor und einen Speicher, wobei der Speicher Anweisungen speichert, die durch den Prozessor ausgeführt werden können, um eine erste Nachricht von einem Fahrzeug zu empfangen, die ein Ereignis in dem Fahrzeug angibt; Fahrzeugdaten zu identifizieren, um das Ereignis in dem Fahrzeug zu bestätigen oder zu widerlegen; eine Anwendungsprogrammierschnittstelle (application programming interface - API) in dem Fahrzeug zu identifizieren, um auf zumindest einige der Fahrzeugdaten zuzugreifen; und eine zweite Nachricht an das Fahrzeug zu übertragen, die eine Abfrage der Fahrzeugdaten gemäß der API beinhaltet.

Description

TECHNISCHES GEBIET
Die Offenbarung betrifft im Allgemeinen den Betrieb und Komponenten von Fahrzeugen.
ALLGEMEINER STAND DER TECHNIK
Daten über Ereignisse in einem Fahrzeug, z. B. einen Zustand oder eine Aktion in einer Komponente in dem Fahrzeug, sind möglicherweise nicht immer genau oder vollständig, wie in einem Fahrzeugnetzwerk bereitgestellt. Ein Datenwert, wie etwa ein Fehlercode oder dergleichen, kann angeben, dass das Ereignis, z. B. ein Fehler oder eine andere Bedingung einer Fahrzeugkomponente, aufgetreten ist.
KURZDARSTELLUNG
Ein System umfasst einen Computer, der einen Prozessor und einen Speicher beinhaltet, wobei der Speicher Anweisungen speichert, die durch den Prozessor ausgeführt werden können, um eine erste Nachricht von einem Fahrzeug zu empfangen, die ein Ereignis in dem Fahrzeug angibt; Fahrzeugdaten zu identifizieren, um das Ereignis in dem Fahrzeug zu bestätigen oder zu widerlegen; eine Anwendungsprogrammierschnittstelle (application programming interface - API) in dem Fahrzeug zu identifizieren, um auf zumindest einige der Fahrzeugdaten zuzugreifen; und eine zweite Nachricht an das Fahrzeug zu übertragen, die eine Abfrage der Fahrzeugdaten gemäß der API beinhaltet.
Die Anweisungen können ferner Anweisungen beinhalten, um die Fahrzeugdaten als Reaktion auf die Abfrage zu empfangen und das Ereignis in dem Fahrzeug auf Grundlage der Fahrzeugdaten zu bestätigen oder zu widerlegen. Die Anweisungen können ferner Anweisungen beinhalten, um das Ereignis auf Grundlage von Umgebungsdaten, die von einer Datenquelle außerhalb des Fahrzeugs abgerufen werden, zu bestätigen oder zu widerlegen. Die Datenquelle außerhalb des Fahrzeugs kann ein stationäres Infrastrukturelement sein und die Umgebungsdaten können auf Sensordaten des Infrastrukturelements basieren. Die Anweisungen können ferner Anweisungen beinhalten, um auf Grundlage des Bestätigens oder Widerlegens des Ereignisses in dem Fahrzeug eine Aktion für das Fahrzeug anzugeben. Die Aktion kann das Navigieren des Fahrzeugs zu einem angegebenen Standort beinhalten. Die Aktion kann das Deaktivieren eines Betriebs einer Fahrzeugkomponente beinhalten. Die Nachricht kann Fahrzeugsensordaten beinhalten. Die Nachricht kann eine Steuerung in dem Fahrzeug angeben, die dem Ereignis ausgesetzt ist. Die Nachricht kann einen Fahrzeugladezustand beinhalten, wobei die Anweisungen ferner Anweisungen beinhalten, um die API zu identifizieren und die Abfrage zumindest teilweise auf Grundlage des Fahrzeugladezustands zu bestimmen.
Die API kann auf Grundlage des Identifizierens einer Steuerung in dem Fahrzeug, die Daten bereitstellt, die das Ereignis anzeigen, identifiziert werden und die Abfrage fordert zumindest einige der Fahrzeugdaten von der Steuerung über die API an. Die API kann eine erste API sein, wobei die Anweisungen ferner Anweisungen beinhalten, um eine zweite API in dem Fahrzeug zu identifizieren, um auf eine Auswahl der Fahrzeugdaten zuzugreifen, auf die über die erste API nicht zugegriffen werden kann.
Die Abfrage kann angeben, dass das Fahrzeug Sensordaten von mindestens einem von einem zweiten Fahrzeug und einem Infrastrukturelement erhalten soll. Die Abfrage kann Fahrzeugsensordaten anfordern. Die Anweisungen können ferner Anweisungen beinhalten, um die Anfrage teilweise auf Grundlage eines Standorts des Fahrzeugs zu bestimmen. Die Abfrage kann einen oder mehrere Schritte beinhalten, um zu bestimmen, ob ein Fahrzeugnetzwerk gehackt oder gespooft wurde.
Die erste Nachricht kann bei einer Benutzereingabe initiiert werden, die das Ereignis angibt. Die erste Nachricht kann einen Fahrzeugstandort beinhalten, und die Abfrage beinhaltet einen oder mehrere Schritte, um zu bestimmen, ob der Fahrzeugstandort genau ist.
Die Anweisungen können ferner Anweisungen beinhalten, um die Abfrage zumindest teilweise auf Grundlage einer Ausgabe von einem Programm zum maschinellen Lernen zu identifizieren. Die Anweisungen können ferner Anweisungen beinhalten, um die Abfrage auf Grundlage einer Marke und eines Modells des Fahrzeugs zu identifizieren.
Figurenliste

1 ist ein Blockdiagramm, das ein beispielhaftes System veranschaulicht.
2 ist ein Diagramm eines beispielhaften tiefen neuronalen Netzes (deep neural network - DNN).
3 ist ein Ablaufdiagramm eines beispielhaften Vorgangs für einen Server, um eine Nachricht von einem Fahrzeug zu verarbeiten.
4 ist ein Ablaufdiagramm eines beispielhaften Vorgangs für einen Fahrzeugcomputer, um ein Ereignis an einen Server zu melden und eine Abfrage von diesem zu verarbeiten.

DETAILLIERTE BESCHREIBUNG
1 ist ein Blockdiagramm eines beispielhaften Systems 100 zum dynamischen Verwalten der Erfassung und/oder Diagnose von Fahrzeuganomalien.
Ein Fahrzeug 105 ist typischerweise (aber nicht notwendigerweise) ein Landfahrzeug, wie etwa ein Auto, ein Lastwagen usw. Zusätzlich oder alternativ kann ein Fahrzeug 105 ein Fahrrad, ein Motorrad usw. beinhalten. Ein Fahrzeug 105 beinhaltet einen Fahrzeugcomputer 110, Sensoren 115, Aktoren 120 zum Betätigen verschiedener Fahrzeugkomponenten 125 und ein Fahrzeugkommunikationsmodul 130. Das Kommunikationsmodul 130 ermöglicht es dem Fahrzeugcomputer 110, mit einem oder mehreren Infrastrukturelementen 140 und einem Server 170 zu kommunizieren, z. B. über ein Nachrichten- oder Übertragungsprotokoll, wie etwa Dedicated Short Range Communications (DSRC), Mobilfunk, und/oder ein anderes Protokoll, das die Kommunikation von Fahrzeug zu Fahrzeug, von Fahrzeug zu Infrastruktur, von Fahrzeug zu Cloud oder dergleichen und/oder über ein Paketnetzwerk 135 unterstützen kann.
Ein Fahrzeugcomputer 110 beinhaltet einen Prozessor und einen Speicher, wie sie bekannt sind. Der Speicher beinhaltet eine oder mehrere Formen von computerlesbaren Medien und speichert Anweisungen, die durch den Computer 110 zum Durchführen verschiedener Vorgänge, einschließlich der in dieser Schrift offenbarten, ausführbar sind.
Der Computer 110 kann ein Fahrzeug 105 in einem autonomen, einem halbautonomen oder einem nicht autonomen (oder manuellen) Modus betreiben. Für die Zwecke dieser Offenbarung ist ein autonomer Modus als ein Modus definiert, in dem jedes von Antrieb, Bremsen und Lenken des Fahrzeugs 105 durch den Computer 110 gesteuert wird; in einem teilautonomen Modus steuert der Computer 110 eines oder zwei von Antrieb, Bremsen und Lenken des Fahrzeugs 105; in einem nichtautonomen Modus steuert ein menschlicher Fahrzeugführer jedes von Antrieb, Bremsen und Lenken des Fahrzeugs 105.
Der Computer 110 kann eine Programmierung beinhalten, um eines oder mehrere von Bremsen, Antrieb (z. B. Steuerung der Beschleunigung des Fahrzeugs durch Steuern von einem oder mehreren von einem Verbrennungsmotor, Elektromotor, Hybridmotor usw.), Lenken, Klimasteuerung, Innen- und/oder Außenbeleuchtung usw. des Fahrzeugs 105 zu betreiben, sowie um zu bestimmen, ob und wann der Computer 110 derartige Vorgänge anstelle eines menschlichen Bedieners steuern soll. Des Weiteren kann der Computer 110 dazu programmiert sein, zu bestimmen, ob und wann ein menschlicher Fahrzeugführer derartige Vorgänge steuern soll.
Der Computer 110 kann mehr als einen Prozessor beinhalten oder kommunikativ daran gekoppelt sein, z. B. über ein Netzwerk des Fahrzeugs 105, wie etwa einen Kommunikationsbus, wie nachstehend ausführlicher beschrieben, die z. B. in elektronischen Steuereinheiten (electronic controller units - ECUs) oder dergleichen enthalten sind, die in dem Fahrzeug zum Überwachen und/oder Steuern verschiedener Fahrzeugkomponenten 125, z. B. einer Antriebsstrangsteuerung, einer Bremssteuerung, einer Lenkungssteuerung usw., enthalten sind. Der Computer 110 ist im Allgemeinen zur Kommunikation auf einem Fahrzeugkommunikationsnetzwerk, das einen Bus in dem Fahrzeug beinhalten kann, wie etwa ein Controller Area Network (CAN) oder dergleichen, und/oder anderen drahtgebundenen und/oder drahtlosen Mechanismen angeordnet.
Über das Netzwerk des Fahrzeugs 105 kann der Computer 110 Nachrichten an verschiedene Vorrichtungen in dem Fahrzeug übertragen und/oder Nachrichten (z. B. CAN-Nachrichten) von den verschiedenen Vorrichtungen, z. B. Sensoren 115, einem Aktor 120, einer Mensch-Maschine-Schnittstelle (human machine interface - HMI) usw., empfangen. Alternativ oder zusätzlich kann in Fällen, in denen der Computer 110 tatsächlich eine Vielzahl von Vorrichtungen umfasst, das Kommunikationsnetzwerk des Fahrzeugs 105 für Kommunikation zwischen Vorrichtungen verwendet werden, die in dieser Offenbarung als der Computer 110 dargestellt sind. Ferner können, wie nachstehend erwähnt, verschiedene Steuerungen und/oder Sensoren 115 dem Computer 110 Daten über das Fahrzeugkommunikationsnetzwerk b erei tstell en.
Die Sensoren 115 des Fahrzeugs 105 können vielfältige Vorrichtungen beinhalten, die dem Computer 110 bekanntermaßen Daten bereitstellen. Zum Beispiel können die Sensoren 115 (einen) Light-Detection-and-Ranging-Sensor(en) (LIDAR-Sensor(en)) 115 usw. beinhalten, die auf einer Oberseite des Fahrzeugs 105, hinter einer Windschutzscheibe des Fahrzeugs 105, um das Fahrzeug 105 herum usw. angeordnet sind, die relative Standorte, Größen und Formen von Objekten bereitstellen, die das Fahrzeug 105 umgeben. Als ein anderes Beispiel können ein oder mehrere Radarsensoren 115, die an Stoßfängern des Fahrzeugs 105 befestigt sind, Daten bereitstellen, um Standorte der Objekte, von zweiten Fahrzeugen 105 usw. in Bezug auf den Standort des Fahrzeugs 105 bereitzustellen. Die Sensoren 115 können ferner alternativ oder zusätzlich beispielsweise (einen) Kamerasensor(en) 115 beinhalten, z. B. Frontkamera, Seitenkamera usw., die Bilder von einem das Fahrzeug 105 umgebenden Bereich bereitstellen. Im Zusammenhang mit dieser Offenbarung ist ein Objekt ein physischer, d. h. materieller, Gegenstand, der durch physikalische Phänomene (z. B. Licht oder andere elektromagnetische Wellen oder Schall usw.), die durch Sensoren 115 erfasst werden können, dargestellt werden kann. Somit fallen die Fahrzeuge 105 sowie andere Gegenstände, einschließlich der nachstehend erörterten, unter die Definition von „Objekt“ in dieser Schrift.
Die Aktoren 120 des Fahrzeugs 105 sind über Schaltungen, Chips oder andere elektronische und/oder mechanische Komponenten umgesetzt, die verschiedene Fahrzeugteilsysteme gemäß zweckmäßigen Steuersignalen betätigen können, wie es bekannt ist. Die Aktoren 120 können verwendet werden, um Steuerelemente 125, einschließlich Bremsung, Beschleunigung und Lenkung, eines Fahrzeugs 105 zu steuern.
In Zusammenhang mit der vorliegenden Offenbarung handelt es sich bei einer Fahrzeugkomponente 125 um eine oder mehrere Hardwarekomponenten, die angepasst sind, um eine(n) mechanische(n) oder elektromechanische(n) Funktion oder Vorgang durchzuführen - wie etwa Bewegen des Fahrzeugs 105, Abbremsen oder Anhalten des Fahrzeugs 101, Lenken des Fahrzeugs 105 usw. Nicht einschränkende Beispiele für Komponenten 125 schließen Folgendes ein: eine Antriebskomponente (die z. B. eine Brennkraftmaschine und/oder einen Elektromotor usw. beinhaltet), eine Getriebekomponente, eine Lenkkomponente (die z. B. eines oder mehrere von einem Lenkrad, einer Lenkzahnstange usw. beinhalten kann), eine Bremskomponente (wie nachfolgend beschrieben), eine Einparkhilfekomponente, eine Komponente zur adaptiven Geschwindigkeitsregelung, eine Komponente zum adaptiven Lenken, einen beweglichen Sitz usw.
Eine oder mehrere Steuerungen 126 sind typischerweise in dem Fahrzeug 105 bereitgestellt, um jeweilige Komponenten 125 zu überwachen und/oder zu steuern. Eine Steuerung 126 ist eine Rechenvorrichtung, die einen Prozessor und einen Speicher beinhaltet und typischerweise für drahtgebundene oder drahtlose Kommunikation über einen Fahrzeugkommunikationsbus oder ein anderes Netzwerk des Fahrzeugs 105 verbunden ist. Die Steuerungen 126 können Daten von den Sensoren 115 empfangen und/oder Daten über das Netzwerk des Fahrzeugs 105, z. B. dem Computer 110, bereitstellen. Die Steuerungen 126 können zudem Aktoren 120 Anweisungen oder Befehle bereitstellen, wodurch Komponenten 120 gesteuert werden, z. B. Steuern von Beschleunigung, Bremsung, Lenkung usw. Zum Beispiel wird ein Motorsteuermodul (engine control module - ECM) verwendet, um einen Motor zu steuern und/oder zu überwachen, wird ein Getriebesteuermodul (transmission control module - TCM) verwendet, um ein Getriebe zu steuern und/oder zu überwachen, kann ein Bremssteuermodul (brake control module - BCM) verwendet werden, um die Fahrzeugbremsen zu steuern, usw. Ferner können, wenn Steuerungen immer ausgefeilter werden, verschiedene Funktionen kombiniert oder in eine einzige Steuerung integriert werden. Zum Beispiel kann ein Antriebsstrangsteuermodul (powertrain control module - PCM) verwendet werden, um den Motor und das Getriebe zu steuern. Gleichermaßen kann ein Fahrzeugsteuermodul (vehicle control module - VCM) verwendet werden, um den Motor, das Getriebe, die aktive Aufhängung, die Servolenkung, das ABS und dergleichen zu steuern.
Zusätzlich kann der Computer 110 zur Kommunikation über ein(e) Fahrzeug-zu-FahrzeugKommunikationsmodul oder -Schnittstelle 130 mit Vorrichtungen außerhalb des Fahrzeugs 105 konfiguriert sein, z. B. durch drahtlose Kommunikation (Mobilfunk und/oder DSRC usw.) von Fahrzeug zu Fahrzeug (V2V) oder von Fahrzeug zu Infrastruktur (V2X) mit einem anderen Fahrzeug, mit einem Infrastrukturelement 140 (typischerweise über direkte Funkfrequenzkommunikation) und/oder einem entfernten Server 170 (typischerweise über das Netzwerk 135). Das Modul 130 könnte einen oder mehrere Mechanismen beinhalten, durch welche die Computer 110 der Fahrzeuge 105 kommunizieren können, einschließlich einer beliebigen gewünschten Kombination aus drahtlosen (z. B. Mobilfunk-, Drahtlos-, Satelliten-, Mikrowellen- und Hochfrequenz-)Kommunikationsmechanismen und einer beliebigen gewünschten Netzwerktopologie (oder Netzwerktopologien, wenn eine Vielzahl von Kommunikationsmechanismen genutzt wird). Eine beispielhafte Kommunikation, die über das Modul 130 bereitgestellt wird, kann Mobilfunk, Bluetooth, IEEE 802.11, Dedicated Short Range Communications (DSRC), Mobilfunk-V2X (CV2X) und dergleichen beinhalten.
Das Netzwerk 135 stellt einen oder mehrere Mechanismen dar, durch die ein Fahrzeugcomputer 110 mit einem Infrastrukturelement 140 und/oder einem zentralen Server 170 kommunizieren kann. Dementsprechend kann das Netzwerk 135 eines oder mehrere von unterschiedlichen drahtgebundenen oder drahtlosen Kommunikationsmechanismen sein, die eine beliebige gewünschte Kombination aus drahtgebundenen (z. B. Kabel und Glasfaser) und/oder drahtlosen (z. B. Mobilfunk-, Drahtlos-, Satelliten-, Mikrowellen- und Hochfrequenz-)Kommunikationsmechanismen und eine beliebige gewünschte Netzwerktopologie (oder Netzwerktopologien, wenn eine Vielzahl von Kommunikationsmechanismen verwendet wird) beinhalten. Zu beispielhaften Kommunikationsnetzwerken gehören drahtlose Kommunikationsnetzwerke (z. B. unter Verwendung von Bluetooth®, Bluetooth® Low Energy (BLE), IEEE 802.11, Fahrzeug-zu-Fahrzeug (V2V) wie etwa dedizierte Nahbereichskommunikation (DRSC) usw.), lokale Netzwerke (local area networks - LAN) und/oder Weitverkehrsnetzwerke (WAN), einschließlich des Internets, die Datenkommunikationsdienste bereitstellen.
Ein Infrastrukturelement 140 beinhaltet eine physische Struktur wie etwa einen Mast oder eine andere Tragstruktur (z. B. einen Pfahl, einen Kasten, der an einem Brückenträger, einem Mobilfunkmast, einer Straßenschildhalterung usw. montierbar ist), an oder in der sich Infrastruktursensoren 145 befinden sowie ein Infrastruktur-Kommunikationsmodul 150 und ein Computer 155 untergebracht, montiert, gelagert und/oder enthalten und angetrieben sein können usw. Ein Infrastrukturelement 140 ist zur Vereinfachung der Veranschaulichung in 1 gezeigt, aber das System 100 könnte und würde wahrscheinlich dutzende, hunderte oder tausende von Elementen 140 beinhalten.
Ein Infrastrukturelement 140 ist typischerweise stationär, d. h. an einem bestimmten physischen Standort befestigt und nicht dazu in der Lage, sich von dort wegzubewegen. Die Infrastruktursensoren 145 können einen oder mehrere Sensoren beinhalten, wie sie etwa vorstehend für die Sensoren 115 des Fahrzeugs 105 beschrieben sind, z. B. LIDAR, Radar, Kameras, Ultraschallsensoren usw. Die Infrastruktursensoren 145 sind befestigt oder ortsfest. Das heißt, jeder Sensor 145 ist so an dem Infrastrukturelement montiert, dass er ein im Wesentlichen unbewegtes und sich nicht änderndes Sichtfeld aufweist.
Die Sensoren 145 stellen somit ein Sichtfeld bereit, das in einer Reihe von vorteilhaften Aspekten im Gegensatz zu den Sensoren 115 des Fahrzeugs 105 steht. Erstens können, da die Sensoren 145 ein im Wesentlichen konstantes Sichtfeld aufweisen, Bestimmungen des Standorts des Fahrzeugs 105 und der Objekte mit weniger und einfacheren Verarbeitungsressourcen erzielt werden als in dem Fall, dass die Bewegung der Sensoren 145 ebenfalls berücksichtigt werden müsste. Ferner beinhalten die Sensoren 145 eine Außenperspektive des Fahrzeugs 105 und können gelegentlich Merkmale und Eigenschaften von Objekten erfassen, die sich nicht in dem Sichtfeld/den Sichtfeldern der Sensoren 115 des Fahrzeugs 105 befinden, und/oder können z. B. in Bezug auf den Standort des Fahrzeugs 105 und/oder eine Bewegung in Bezug auf andere Objekte eine genauere Erfassung bereitstellen. Weiterhin können die Sensoren 145 über eine drahtgebundene Verbindung mit dem Computer 155 des Elements 140 kommunizieren, wohingegen die Fahrzeuge 105 typischerweise mit den Elementen 140 und/oder einem Server 170 nur drahtlos kommunizieren können oder nur zu sehr begrenzten Zeiten, wenn eine drahtgebundene Verbindung verfügbar ist. Eine drahtgebundene Kommunikation ist zuverlässiger und kann schneller sein als eine drahtlose Kommunikation, wie etwa Fahrzeug-zu-Infrastruktur-Kommunikation oder dergleichen.
Das Kommunikationsmodul 150 und der Computer 155 haben typischerweise Merkmale mit dem Fahrzeugcomputer 110 und dem Fahrzeugkommunikationsmodul 130 gemeinsam und werden deshalb nicht näher beschrieben, um Redundanz zu vermeiden. Wenngleich dies zur übersichtlicheren Veranschaulichung nicht gezeigt ist, beinhaltet das Infrastrukturelement 140 außerdem eine Leistungsquelle, wie etwa eine Batterie, Solarzellen und/oder eine Verbindung mit einem Stromnetz.
BEISPIELHAFTE VORGÄNGE
Der Computer 110 kann eine Programmierung beinhalten, um Nachrichten zu senden und zu empfangen. Eine „Nachricht“ ist im Zusammenhang mit dieser Offenbarung ein Datensatz, der von einem ersten Computer an einen zweiten Computer übertragen wird. Bekanntlich können die Computer zum Kodieren und Serialisieren programmiert sein, d. h. zum Umwandeln von Daten, wie etwa Daten, die Objekte beschreiben, in eine Bitfolge, sodass die Daten in einer Nachricht eingeschlossen werden können, die Pakete umfasst, welche die serialisierten Daten (oder in jedem von einer Vielzahl von Paketen einen Abschnitt davon) als Nutzlast beinhalten, wobei die Nachricht zu oder von dem/den Fahrzeug(en) und/oder der/den Infrastruktur(en), d. h. Sendern und Empfängern, übertragen wird. Ein Sender oder ein Empfänger kann jeweils ein Computer, z. B. in einem Fahrzeug oder einem Infrastrukturelement sein (z. B. über ein Kommunikationsmodul). Ferner kann das System eine Vielzahl von Sendern und/oder eine Vielzahl von Empfängern beinhalten. Beispielsweise könnte, wie nachfolgend weiter erörtert, ein Empfänger eine Vielzahl von Nachrichten zu einem Objekt von jeweiligen Sendern empfangen.
Somit kann ein Fahrzeug 105, d. h. über den Computer 110, eine Nachricht an einen entfernten Server 170 senden, d. h. über das Netzwerk 135. Die Nachricht von dem Fahrzeug 105 kann ein Ereignis in dem Fahrzeug 10 angeben. Ein „Ereignis“ bedeutet im vorliegenden Zusammenhang, dass der Computer 110 einen Ereigniscode, Fehlercode oder Diagnosefehlercode (diagnostic trouble code - DTC) oder dergleichen (in dieser Schrift allgemein als Ereigniscode bezeichnet) anhand von Daten identifiziert hat, die von einer Steuerung 126 über das Netzwerk des Fahrzeugs 105 bereitgestellt werden; Angeben des Ereignisses bedeutet in diesem Zusammenhang Bereitstellen des Ereigniscodes. Beispielhafte Ereigniscodes, um nur einige zu nennen, beinhalten einen Code, der angibt, dass eine Fahrzeugleuchte funktionsunfähig ist, einen Code, der anzeigt, dass ein Reifendruck über oder unter einem empfohlenen Bereich liegt, einen Code, der anzeigt, dass eine Motortemperatur über einem empfohlenen Bereich liegt, einen Code, der den Verschleiß einer Komponente 125 (z. B. der Bremsbeläge) angibt, einen Code, der anzeigt, dass ein Kraftstoff- oder Leistungsniveau unter einem Schwellenwert für den weiteren Betrieb liegt, usw.
Ein Computer 110 des Fahrzeugs 105 könnte dazu programmiert sein, die Nachricht beim Erfassen des Ereignisses und/oder beim Empfangen einer Benutzereingabe, die das Ereignis angibt, zu senden. Zum Beispiel könnte der Computer 110 dazu programmiert sein, eine Nachricht beim Identifizieren eines oder mehrerer Ereignisse, die über ein Fahrzeugnetzwerk, wie etwa einen CAN-Bus, gemeldet werden, zu senden. Alternativ oder zusätzlich könnte ein Benutzer eine Eingabe, z. B. über eine Mensch-Maschine-Schnittstelle in dem Fahrzeug, wie etwa einen Touchscreen, ein Mikrofon usw., bereitstellen, die ein Ereignis, z. B. eine Kollision, angibt.
Ferner beinhaltet die Nachricht typischerweise Identifizierungsdaten für das Fahrzeug 105, von dem die Nachricht gesendet wird, z. B. eine Fahrzeugidentifikationsnummer (FIN) oder dergleichen und/oder eine Marke, ein Modell, ein Modelljahr und andere Informationen, die für das Bestätigen eines Ereignisses relevant sind, wie etwa die Antriebskonfiguration (Zweirad-, Allrad-, Vierradantrieb, Größe der Brennkraftmaschine (internal combustion (IC) engine - IC-Maschine), ob der Antrieb ein hybrider Elektro/IC-, einer reiner IC-, ein vollelektrischer Antrieb ist, usw.). Beispielsweise kann eine FIN bekanntermaßen decodiert werden, um ein Land der Fahrzeugherstellung, einen Hersteller, eine Marke, ein Modell, ein Modelljahr, einen Karosseriestil, einen Motortyp, eine Getriebeart und/oder andere Daten zu identifizieren.
Eine Nachricht von einem Fahrzeug 105 an einen Server 170 kann zusätzlich Zustandsdaten des Fahrzeugs 105 beinhalten, d. h. Daten, die einen Zustand oder eine Bedingung des Fahrzeugs 105, eine Umgebung um das Fahrzeug 105 und/oder eine oder mehrere Komponenten 125 in dem Fahrzeug 105 beschreiben. Die Zustandsdaten des Fahrzeugs 105 können Daten von einem oder mehreren Sensoren 115, eine Kennung oder Kennungen für eine Komponente und/oder Steuerung 126, die einem Ereignis zugeordnet ist oder dieses meldet, und/oder andere Daten, die den Betrieb und/oder den Zustand des Fahrzeugs 105 betreffen, beinhalten. Beispiele für Daten von Sensoren 115 und/oder Steuerungen 126 des Fahrzeugs 105, die bereitgestellt werden könnten, beinhalten Daten, die einen Ladezustand (oder Ladestand) einer Batterie des Fahrzeugs 105, einen Standort des Fahrzeugs 105 (z. B. gemäß Geokoordinaten oder dergleichen), eine Geschwindigkeit des Fahrzeugs 105, eine Umgebungstemperatur (d. h. eine Temperatur in einer Umgebung außerhalb und um das Fahrzeug 105), das Vorhandensein oder Nichtvorhandensein von Niederschlag, ob ein Antiblockiersystem (ABS) aktiviert wurde usw., angeben
Daten von den Sensoren 115 und/oder Steuerungen 126 des Fahrzeugs 105 können mit einem oder mehreren in dem Server 170 gespeicherten Auslöseparametern verglichen werden. Ein Auslöseparameter ist ein Wert oder Wertebereich, der, wenn er mit Daten abgeglichen wird, die in einer Nachricht von einem Fahrzeug 105 zusammen mit einem vorgegebenen Ereigniscode gemeldet werden, den Server 170 dazu veranlassen kann, das Fahrzeug 105 abzufragen, d. h. eine Abfrage über eine API der Steuerung 126 für weitere Daten, die für den Ereigniscode relevant sind, bereitzustellen. Verschiedene Beispiele für Auslöseparameter sind in dieser Schrift beschrieben. Beispielsweise könnte der Server 170 z. B. durch Abfragen einer Lookup-Tabelle oder dergleichen bestimmen, dass ein von einem Sensor 115 und/oder einer Steuerung 126 gemessener Wert, z. B. ein ungültiger Zeitstempel für eine Nachricht über den Kommunikationsbus des Fahrzeugs 105, ein ungültiger Kilometerstand (z. B. ein Messwert, der kleiner als ein vorheriger Messwert ist), ein unrealistischer GPS-Standort (z. B. mehr als eine Entfernung von einem vorherigen Standort, die das Fahrzeug 105 realistischerweise hätte zurücklegen können) usw. In einem anderen Beispiel könnte der Server 170 bestimmen, dass ein Auslöseparameter, möglicherweise angezeigt hat, dass ein Netzwerk des Fahrzeugs 105 gehackt wurde und/oder Daten des Fahrzeugs 105 gespooft werden, z. B. wenn ein Ereigniscode unbekannt ist oder einen unbekannten Diagnosestatus angibt, wenn Daten außerhalb eines als typisch festgelegten Bereichs schwanken, usw. In einem anderen Beispiel könnte der Server 170 bestimmen, dass ein Ereigniscode einem Messwert in dem Fahrzeug zugeordnet ist, der sich auf eine Regulierung und/oder Überwachung bezieht, z. B. Fahrzeugemissionen, Fahrerablenkung (z. B. die Zeitdauer, für die der Blick des Fahrers die Straße verlassen kann, die Zeitdauer, für die die Hände des Fahrers vom Lenkrad weg sein können usw.). In einem anderen Beispiel könnte ein Ereigniscode, der das Ersetzen von Teilen oder Komponenten (z. B. Ersetzen einer Steuerung 126, eines neuen Schlüsseltransponders usw.) anzeigt, ein Auslöseparameter sein. In noch einem anderen Beispiel könnte ein Auslöseparameter durch eine Benutzereingabe angegeben werden, z. B. durch einen Techniker, der ein von einem Benutzer angegebenes Service-Problem diagnostizieren möchte, z. B. könnte die Angabe, dass ein Fahrzeug stehenbleibt oder nicht dazu imstande ist, eine bestimmte Geschwindigkeit zu erreichen, die Grundlage dafür sein, dass ein Techniker einen Auslöseparameter eingibt, um zusätzliche Diagnoseinformationen von einer Motorsteuermodul-(engine control module - ECM-)Steuerung 126 und/oder von einer Kraftstoffsystemsteuerung 126 zu empfangen, um Daten über einen Anteil von Wasser im Kraftstoff usw. bereitzustellen. Ein weiteres Beispiel für eine Benutzereingabe, die einen Auslöseparameter vorgibt, könnte darin bestehen ein Vorhandensein oder Nichtvorhandensein einer Fähigkeit oder Funktionalität in einer Steuerung 126 zu bestimmen, z. B. ob eine ECM-Steuerung 126 bestimmte Daten bereitstellen kann. Ein weiteres Beispiel für eine Benutzereingabe, die einen Auslöseparameter angibt, könnte darin bestehen, die Genauigkeit von Daten zu bestimmen, die von dem Fahrzeug 105 empfangen und auf einer Benutzervorrichtung angezeigt werden, z. B. niedriger Kraftstoffstand, Kraftstoffeffizienz, GPS-Standort, Reifendruck, verbleibende Öllebensdauer, Ladezustand und Ladeleistung von Elektrofahrzeugen usw.
Der Server 170 kann dazu programmiert sein, nachdem die Nachricht, die das Ereignis angibt, empfangen wurde, Fahrzeugdaten zu identifizieren, um das Ereignis in dem Fahrzeug zu bestätigen oder zu widerlegen, und dann eine Anwendungsprogrammierschnittstelle (application programming interface - API) in dem Fahrzeug zu identifizieren, um auf zumindest einige der Fahrzeugdaten zuzugreifen. Beispielsweise kann die API auf Grundlage des Identifizierens einer Steuerung 126 in dem Fahrzeug 105, die Daten bereitstellt, die das Ereignis anzeigen, identifiziert werden, und die Abfrage, die gemäß der API an die Steuerung 126 gerichtet wird, könnte zumindest einige der Daten des Fahrzeugs 105 von der Steuerung 126 über die API anfordern.

Das heißt, der Server 170 kann dazu programmiert sein, eine Dateneinheit oder Daten zu identifizieren, die, wenn sie einen vorgegebenen Wert aufweisen, oder innerhalb eines vorgegebenen Wertebereichs (d. h. über und/oder unter (einem) Schwellenwert(en)) liegen, das Vorhandensein des in der Nachricht von dem Computer 110 des Fahrzeugs 105 angegebenen Ereignisses bestätigen oder widerlegen. Beispielsweise könnte der Server 170 (oder ein enthaltener oder verbundener Datenspeicher) eine Tabelle oder einen anderen Datensatz speichern, die/der für eine bestimmte Fahrzeugmarke, ein bestimmtes Modell, ein bestimmtes Modelljahr und einen bestimmten Motortyp und für einen bestimmten Ereigniscode, den das Fahrzeug bereitstellen könnte, eine Dateneinheit oder Daten des Fahrzeugs angibt, um die Gültigkeit des Ereignisses zu bestätigen oder zu widerlegen (z. B., dass ein gemeldeter Fehler wahrscheinlich vorliegt oder nicht vorliegt). Der Server 170 könnte ferner eine Kennung für eine Steuerung 126, von der die Fahrzeugdaten abgefragt werden können, um die Gültigkeit des Ereignisses zu bestätigen oder zu widerlegen, sowie eine Abfrage über eine API, die von der Steuerung 126 bereitgestellt wird, um die Dateneinheit oder die Daten zu erhalten, speichern. Beispielsweise könnte der Server 170 eine Tabelle wie folgt speichern:

Bereich	Erklärung
Fahrzeugkennung	Kombination aus einer oder mehreren identifizierenden Eigenschaften, um das Fahrzeug ausreichend zu identifizieren, um einen Ereigniscode zu interpretieren, z. B. Marke, Modell, Modelljahr, Motortyp, Karosseriestil, Getriebetyp usw.
Ereigniscode	Ereigniscode für das Fahrzeug, das durch die Fahrzeugkennung identifiziert wird (z. B. Fehlercode, DTC oder dergleichen).
Auslöseparameter	Ein oder mehrere Werte oder Wertebereiche in Daten, die von einem Fahrzeug 105 bereitgestellt werden, um eine Abfrage an das Fahrzeug auf Grundlage des Ereigniscodes auszulösen.
Abfrage	Daten, die auf Grundlage der Fahrzeugkennung und des Ereigniscodes von dem Fahrzeug 105 angefordert werden sollen, einschließlich einer abzufragenden Steuerung 126 und eines Funktionsaufrufs oder von Funktionsaufrufen oder dergleichen an eine API, die von der Steuerung 126 bereitgestellt werden, um die angeforderten Daten zurückzugeben.

Die Abfrage kann Daten von dem Fahrzeug 105 anfordern. Eine Abfrage kann Daten, die ein CAN-Signal beinhalten, auf Grundlage dessen anfordern, was als Datenkennung (oder data identifier - „DID“) bekannt ist. Bestimmte Datenkennungen für CAN-Signale, die auf dem CAN-Bus eines bestimmten Fahrzeugs 105 verfügbar sind, können anhand der FIN für das Fahrzeug 105 bestimmt werden, z. B. durch eine Lookup-Tabelle oder dergleichen, die spezifische CAN-Signale und Programmcode speichert, um das/die CAN-Signal(e) von einem Fahrzeug 105 und/oder einer bestimmte API einer Steuerung 126 für eine Marke, ein Modell, ein Modelljahr des Fahrzeugs 105 usw. abzurufen. Somit beinhaltet eine erforderliche vorherige Bedingung für das Senden einer Abfrage an ein Fahrzeug 105 typischerweise das Bestimmen, dass das Fahrzeug 105, z. B. eine oder mehrere Steuerungen 126 in dem Fahrzeug 105, die Anforderungsdaten, z. B. ein vorgegebenes CAN-Signal, über den Kommunikationsbus des Fahrzeugs 105 bereitstellt.
Eine Abfrage könnte beispielsweise anfordern, dass ein Fahrzeug 105 Daten des Sensors 115 bereitstellt, z. B. könnte eine Innenkamera Daten bereitstellen, um zu zeigen, ob eine Fahrzeugleuchte aktiviert wurde, könnte eine Außenkamera zeigen, ob ein Fahrzeug 105 mit einem anderen Objekt kollidiert ist, usw. In einem anderen Beispiel, in dem die Nachricht von dem Fahrzeug 105 an den Server 170 einen Ladezustand des Fahrzeugs angegeben und/oder ein Ereignis mit niedriger Ladung gemeldet hat, könnte die Abfrage anfordern, dass das Fahrzeug 105, z. B. über eine API einer Leistungssteuerung 126, eine Ladungsmenge in den Batteriekomponenten 125 des Fahrzeugs 105 bestätigt und/oder einen Zeitpunkt, zu dem die Batterie zuletzt vollständig geladen wurde, und andere Daten, die für das Bestimmen der Batterieladung relevant sind, bereitstellt, einschließlich z. B. einer seit der letzten vollständigen Ladung zurückgelegten Strecke, einer Umgebungstemperatur, eines Betriebs der Klimaanlage usw.
Weiterhin kann die Abfrage beispielsweise angeben, dass das Fahrzeug 105 Sensordaten von mindestens einem von einem zweiten Fahrzeug und/oder einem Infrastrukturelement 140 erhalten soll. Ein Fahrzeug 105 kann beispielsweise zu V2X- oder V2V-Kommunikation wie vorstehend beschrieben in der Lage sein und könnte dadurch Daten von einem anderen Fahrzeug und/oder einem Infrastrukturelement 140 anfordern. Beispielsweise könnten andere Fahrzeugsensoren 115 und/oder Infrastruktursensoren 145 das Host-Fahrzeug 105 in ihrem Sichtfeld haben. Derartige Sensoren 115, 145 könnten Daten bereitstellen, um ein Ereignis zu bestätigen oder zu widerlegen, z. B. Bilder eines Fahrzeugs 105, um zu zeigen, ob ein Reifen platt war, ein Fenster offen oder zerbrochen oder gesprungen war usw. Ein Host-Fahrzeug 105 könnte dem Server 170 Bilddaten oder andere Daten der Sensoren 115, 145 als Reaktion auf eine Abfrage bereitstellen.
Der Server 170 kann ferner dazu programmiert sein, beim Identifizieren einer Abfrage auf Grundlage der Fahrzeugkennung und des Ereigniscodes und möglicherweise zudem auf Grundlage eines oder mehrerer Auslöseparameter eine zweite Nachricht, die eine Abfrage für die Fahrzeugdaten gemäß der API beinhaltet, an das Fahrzeug zu übertragen.
Der Server 170 kann ferner dazu programmiert sein, dann Fahrzeugdaten als Reaktion auf die Abfrage zu empfangen und das Ereignis in dem Fahrzeug auf Grundlage der Fahrzeugdaten zu bestätigen oder zu widerlegen. Ein Ereignis bestätigen bedeutet bestimmen, dass ein Datenelement oder mehrere Daten, die von einem Fahrzeug 170 als Reaktion auf eine Meldung eines Ereignisses abgerufen wurden, Werte aufweisen, von denen bestimmt wurde, dass sie bedeuten, dass das Ereignis aufgetreten ist. Ein Ereignis widerlegen bedeutet bestimmen, dass ein oder mehrere Datenelemente, die von einem Fahrzeug 170 als Reaktion auf eine Meldung eines Ereignisses abgerufen wurden, Werte aufweisen, von denen bestimmt wurde, dass sie bedeuten, dass das Ereignis nicht aufgetreten ist.
Beispielsweise könnte der Server 170 eine Lookup-Tabelle oder dergleichen speichern (oder Zugriff darauf haben), die für ein Ereignis, das von einem Fahrzeug 105 gemeldet werden könnte, einen Satz von einem oder mehreren Datenelementen, z. B. einem oder mehreren CAN-Signalen, die von dem Fahrzeug 105 angefordert werden sollen, das das Ereignis meldet, angibt. Der Server 170 könnte (und würde wahrscheinlich) derartige Daten für jedes einer Vielzahl von Ereignissen, die ein Fahrzeug 105, z. B. gemäß einer FIN oder dergleichen, melden könnte, zusammen mit den zugehörigen Daten, die von dem Fahrzeug 105 bei der Meldung des Ereignisses abgefragt werden sollen, speichern. Beispielsweise könnte ein gemeldetes Ereignis ein GPS-Standort sein, der mehr als eine festgelegte Entfernung von einem zuvor gemeldeten Standort innerhalb eines festgelegten Zeitraums ist. Der Server 170 könnte einen Satz von CAN-Signalen speichern, die dann von dem Fahrzeug 105, z. B. über eine Steuerung 126, abgefragt werden sollen. In einem anderen Beispiel könnte ein Ereignis eine Meldung über Daten-Spoofing oder -Hacking sein. Beispielsweise könnte ein Computer 110 des Fahrzeugs 105 dazu programmiert sein, beim Bestimmen, dass ein Kilometerzählerwert des Fahrzeugs 105 abgenommen hat oder dass sich die Werte des Sensors 115 unregelmäßig ändern (z. B. dass eine Kamera oder ein Radar die Ausrichtung verliert oder die Richtung ändert) ein Hacking-Ereignis zu melden. Beim Empfangen einer Meldung über ein derartiges Hacking-Ereignis könnte der Server 170 das Fahrzeug 105 nach CAN-Signaldaten abfragen, die z. B. angeben, ob ein Händlerwerkzeug, das in der Lage ist, den Wert des Kilometerzählers und/oder Sensors 115 zu ändern, mit dem Fahrzeug verbunden war, ob ein CAN-Signal einen Rücksetzwert eines Kilometerzählers und/oder Sensors 115 beinhaltet usw.
Der Server 170 könnte ferner dazu programmiert sein, dann ein Ereignis auf Grundlage von Daten, die als Reaktion auf eine derartige Abfrage bereitgestellt werden, zu bestätigen oder zu widerlegen. Beispielsweise könnten dem Server Regeln zum Auswerten von Datenwerten bereitgestellt werden, um ein Ereignis zu bestätigen oder zu widerlegen. In Fortsetzung eines vorstehenden Beispiels wird angenommen, dass ein Fahrzeugstandort ein Ereignis ist. Der Server 170 könnte dazu programmiert sein, das Ereignis zu bestätigen, wenn alle von einer Entfernung von einem vorherigen Standort, einer Geschwindigkeit des Fahrzeugs und einer vergangenen Zeit seit einem vorherigen Messwert jeweilige Werte in einem Bereich, für den der Server 170 programmiert ist, das Ereignis zu bestätigen, (oder in einem Bereich, der in einer von dem Server 170 abgerufenen Tabelle oder dergleichen gespeichert ist) aufweisen. Wenn andererseits nur einige, aber nicht alle der abgefragten Daten mit dem Ereignis übereinstimmen, könnte der Server 170 dazu programmiert sein, das Ereignis zu widerlegen. In noch anderen Beispielen könnte der Server 170 dazu programmiert sein, ein Ereignis auf Grundlage dessen zu bestätigen oder zu widerlegen, dass einige, aber nicht alle abgefragten Datenwerte mit dem Ereignis übereinstimmen, z. B. könnte maschinelles Lernen oder dergleichen verwendet werden, um einen Satz von Daten zu trainieren, die mit der Bestätigung oder Widerlegung eines Ereignisses übereinstimmen.
Der Server 170 könnte ferner alternativ oder zusätzlich dazu programmiert sein, zu bestimmen, dass ein Ereignis nicht bestätigt oder widerlegt werden kann, und/oder das Fahrzeug 105 nach weiteren Daten abzufragen, um zu bestimmen, ob das Ereignis bestätigt oder widerlegt werden kann.
Der Server 170 kann dazu programmiert sein, ein Ereignis in einem Fahrzeug 105 auf Grundlage von Umgebungsdaten, die von einer Datenquelle außerhalb des Fahrzeugs abgerufen werden, zusätzlich zu den von dem Fahrzeug 105 empfangenen Fahrzeugdaten zu bestätigen oder zu widerlegen. Zum Beispiel kann die Datenquelle außerhalb des Fahrzeugs 105 ein stationäres Infrastrukturelement 140 in der Nähe des Fahrzeugs 105 sein. Ein Infrastrukturelement 140 befindet sich in der Nähe eines Fahrzeugs 105, wenn es sich innerhalb einer vorgegebenen Entfernung des Fahrzeugs 105 befindet (z. B. wenn sich Geokoordinaten für ein Fahrzeug 105 innerhalb eines vorgegebenen Radius, z. B. eines Kilometers, von Geokoordinaten für ein Infrastrukturelement 140 davon befinden) und/oder das Fahrzeug 105 innerhalb des Sichtfelds/der Sichtfelder des Sensors 145 hat und/oder Fahrzeug-zu-Infrastruktur-Kommunikation mit dem Fahrzeug 105 aufgebaut hat. Umgebungsdaten können auf Daten des Sensors 145 des Infrastrukturelements 140 und/oder Daten von einem Fahrzeug 105 basieren, wie vorstehend beschrieben.
Der Server 170 kann alternativ oder zusätzlich dazu programmiert sein, eine Abfrage zu bestimmen und/oder ein Ereignis in einem Fahrzeug 105 auf Grundlage eines Standorts des Fahrzeugs 105 zu bestätigen oder zu widerlegen. Wie vorstehend angemerkt kann die erste Nachricht einen Fahrzeugstandort beinhalten. In einem Beispiel kann die Abfrage eine Anforderung von Daten beinhalten, um zu bestimmen, ob der gemeldete Fahrzeugstandort genau ist.
Der Server 170 kann ferner dazu programmiert sein, auf Grundlage des Bestätigens oder Widerlegens des Ereignisses in dem Fahrzeug eine Aktion für das Fahrzeug anzugeben. Der Server 170 könnte eine Tabelle oder dergleichen speichern, die für ein wie vorstehend beschrieben identifiziertes Fahrzeug 105 und für ein bestätigtes Ereignis eine Aktion angibt, die der Computer 110 des Fahrzeugs 105 ergreifen soll, um z. B. eine Komponente oder Komponenten 125 zu betätigen, um das Fahrzeug 105 zu einem angegebenen Standort zu navigieren, das Fahrzeug 105 anzuhalten usw. Beispielsweise könnte ein bestätigtes Ereignis ein niedriger Reifendruck sein, woraufhin der Server 170 dazu programmiert sein könnte, das Fahrzeug 105 anzuweisen, zu einem angegebenen Standort zu navigieren, wie etwa einem Standort einer Serviceeinrichtung, und/oder sich an einen Straßenrand oder einen anderen sicheren Parkstandort für einen Service zu bewegen. Andererseits könnte der Server 170 beim Bestimmen eines widerlegten Ereignisses dazu programmiert sein, das Fahrzeug 105 anzuweisen, das Ereignis zu ignorieren und den Betrieb fortzusetzen, als ob das Ereignis nicht gemeldet würde. In einem anderen Beispiel könnte die Aktion das Begrenzen oder Deaktivieren eines Betriebs einer Fahrzeugkomponente beinhalten. Beispielsweise könnte der Server 170 beim Bestimmen, dass ein niedriger Fahrzeugreifendruck bestätigt wird, den Fahrzeugcomputer 110 anweisen, die Geschwindigkeit des Fahrzeugs 105 zu begrenzen, z. B. auf 40 Kilometer pro Stunde oder eine andere Geschwindigkeit, die auf Grundlage eines Anteils, um den der Reifendruck unter einem für den normalen Betrieb festgelegten Bereich lag, variiert werden könnte.
Alternativ oder zusätzlich könnte ein Fahrzeugcomputer 110 dazu programmiert sein, z. B. wie vorstehend beschrieben, eine Aktion für den Fall anzugeben, dass ein Fahrzeug 105 eine Benachrichtigung von dem Server 170 empfängt, dass ein Ereignis in dem Fahrzeug 105 bestätigt oder widerlegt wird.
Zusätzlich zum Identifizieren einer abzufragenden API in dem Fahrzeug 105, wie vorstehend beschrieben, könnte der Server 170 dazu programmiert sein, mindestens eine zweite API zu identifizieren. Typischerweise besteht der Grund zum Identifizieren der zweiten API darin, Daten zu erhalten, die nicht über die erste API verfügbar sind, die aber nützlich sind, um das Ereignis in einer Nachricht von einem Fahrzeug 105 zu bestätigen oder zu widerlegen. Beispielsweise könnte der Server 170 auf Grundlage eines angegebenen Ereignisses dazu programmiert sein, Unterabfragen für jeweilige Steuerungen 126 des Fahrzeugs 105, die jeweils ihre eigenen jeweiligen APIs aufweisen, in eine Abfrage einzuschließen. Dementsprechend könnte der Server 170 in einer Tabelle oder dergleichen, wie vorstehend beschrieben, eine Vielzahl von Unterabfragen für jeweilige Steuerungen 126 speichern, die bei einer Nachricht von einem Fahrzeug 105, die ein bestimmtes Ereignis angibt, bereitgestellt werden sollen.
In einem Beispiel könnte der Server 170 dazu programmiert sein, die Abfrage zumindest teilweise auf Grundlage einer Ausgabe von einem Programm zum maschinellen Lernen zu bestimmen. 2 ist ein Diagramm eines beispielhaften tiefen neuronalen Netzes (DNN) 200, das trainiert werden könnte, um eine Abfrage zumindest teilweise zu bestimmen. Bei dem DNN 200 kann es sich beispielsweise um ein Softwareprogramm handeln, das in den Speicher geladen und durch einen Prozessor, der in einem Server 170 enthalten ist, ausgeführt werden kann. Das DNN 200 kann n Eingabeknoten 205 beinhalten, die jeweils einen Satz von Eingaben i annehmen (d. h. jeder Satz von Eingaben i kann eine oder mehrere Eingaben x beinhalten). Das neuronale Netz 200 kann m Ausgabeknoten (wobei m und n dieselbe Zahl sein können, es typischerweise aber nicht sind) beinhalten, die Sätze von Ausgaben 0₁... 0_m bereitstellen. Das DNN 200 beinhaltet eine Vielzahl von Schichten, einschließlich einer Anzahl k an versteckten Schichten, wobei jede Schicht einen oder mehrere Knoten 205 beinhaltet. Die Knoten 205 werden manchmal als künstliche Neuronen 205 bezeichnet, da sie dazu ausgestaltet sind, biologische, z. B. menschliche, Neuronen zu emulieren. Der Neuronenblock 210 veranschaulicht Eingaben in ein beispielhaftes künstliches Neuron 205i und Verarbeitung darin. Ein Satz von Eingaben x₁ ... x_r in jedes Neuron 205 wird jeweils mit jeweiligen Gewichtungen w_i1 ... w_ir multipliziert, wobei die gewichteten Eingaben dann in der Eingabefunktion ∑ summiert werden, um, womöglich durch eine Verzerrung b_i eingestellt, die Nettoeingabe a_i bereitzustellen, die dann der Aktivierungsfunktion f bereitgestellt wird, die wiederum die Ausgabe y_i des Neurons 205i bereitstellt. Bei der Aktivierungsfunktion f kann es sich um eine Vielfalt von geeigneten Funktionen handeln, die typischerweise auf Grundlage von empirischen Analysen ausgewählt werden. Wie durch die Pfeile in 2 veranschaulicht können die Ausgaben des Neurons 205 dann zur Aufnahme in einen Satz von Eingaben für ein oder mehrere Neuronen 205 in einer nächsten Schicht bereitgestellt werden.
Das DNN 200 kann dazu trainiert werden, Daten, z. B. Daten, die ein Ereignis in einem Fahrzeug 105 angeben, und/oder andere Daten, wie etwa Daten eines Sensors 115 von dem Fahrzeug 105, als Eingabe anzunehmen und einen oder mehrere Parameter für eine Abfrage an das Fahrzeug 105 auszugeben. Beispielsweise könnte das DNN 200 dazu trainiert werden, eine Angabe einer abzufragenden Steuerung 126 und/oder API der Steuerung 126 (oder mehrerer Steuerungen 126 und/oder APIs) auszugeben und/oder spezifische Daten, die von einer Steuerung 126 angefordert werden sollen, auszugeben. Beispielsweise können verschiedene Datenwerte in einem Fahrzeug 105 mit einem Ereignis, wie etwa einer Manipulation eines Kilometerzählers oder einem anderen Spoofing oder Hacking, konsistent oder inkonsistent sein. Einige davon können intuitiv verstanden werden, z. B. plötzliche Verlangsamung eines Fahrzeugs 105, wohingegen viele andere Datenwerte nicht so verstanden werden können, dass sie mit dem Ereignis korrelieren und damit korrelieren können oder nicht. Ein DNN 200 könnte dazu trainiert werden, derartige andere Datenwerte zu identifizieren.
Das heißt, das DNN 200 kann mit Ground-Truth-Daten trainiert werden, d. h. Daten über eine(n) reale(n) Bedingung oder Zustand. Die Gewichtungen w können zum Beispiel durch Verwenden einer Gauß-Verteilung initialisiert werden und eine Verzerrung b für jeden Knoten 205 kann auf null gesetzt werden. Das Trainieren des DNN 200 kann das Aktualisieren von Gewichtungen und Verzerrungen über herkömmliche Techniken wie etwa Rückpropagierung mit Optimierungen beinhalten. Beispielhafte Anfangs- und Endparameter (d. h. nach dem Training) (wobei Parameter in diesem Kontext Gewichtungen w und Verzerrung b sind) für einen Knoten 205 waren in einem Beispiel wie folgt:

Parameter Anfangswert Endwert

w₁ 0,902 -0149438

w₂ -0,446 -0,0103792

w₃ 1,152 0,00850074

w_r 0,649 0,00349599

b_i 0 0,00241366
Ein Satz von Gewichtungen w für einen Knoten 205 ist zusammen ein Gewichtungsvektor für den Knoten 205. Gewichtungsvektoren für jeweilige Knoten 205 in einer gleichen Schicht des DNN 200 können kombiniert werden, um eine Gewichtungsmatrix für die Schicht zu bilden. Verzerrungswerte b für jeweilige Knoten 205 in einer gleichen Schicht des DNN 200 können kombiniert werden, um einen Verzerrungsvektor für die Schicht zu bilden. Die Gewichtungsmatrix für jede Schicht und der Verzerrungsvektor für jede Schicht können dann in dem trainierten DNN 200 verwendet werden.
Im vorliegenden Zusammenhang könnten die Ground-Truth-Daten, die zum Trainieren des DNN 200 verwendet werden, Daten beinhalten, die in einem Netzwerk des Fahrzeugs 105 und/oder von Steuerungen 126 des Fahrzeugs 105 zu einem Zeitpunkt und/oder in der Nähe eines Ereignisses verfügbar sind. Beispielsweise könnten Daten von verschiedenen Sensoren 115 zu einem Zeitpunkt und/oder in der Nähe eines platten Reifens, z. B. von Beschleunigungsmessern, die an Aufhängungsteilen des Fahrzeugs 105, z. B. Spindel, Stoßdämpfer, montiert sind, von einer Lenksteuerung 126, die ein Lenkradwinkel angibt, von einer Motorsteuerung 126, die eine Motordrehzahl, ein Motordrehmoment usw. angibt, von einer Getriebesteuerung 126, die einen Zustand eines Getriebes des Fahrzeugs 105 usw. angibt, gesammelt werden. Die Daten 115 können dann zum Trainieren des DNN 200 markiert werden, d. h. Tags können angegeben werden, die das Ereignis und verschiedene Daten identifizieren, wie etwa wie gerade beschrieben, die zu einem Zeitpunkt des Ereignisses gemeldet werden. Das DNN 200 kann dann dazu trainiert werden, Datenwerte auszugeben, die mit dem Ereignis korrelieren, und eine Abfrage an ein Fahrzeug 105 kann dann angegeben werden, um derartige Datenwerte zu erhalten, um das Bestätigen oder Widerlegen des Ereignisses, wie in einer Nachricht des Fahrzeugs 105 an den Server 170 gemeldet, zu unterstützen.
Der Server 170 könnte auch dazu programmiert sein, ein Programm zum maschinellen Lernen, wie etwa ein DNN 200, zu verwenden, um ein Ereignis zu bestätigen oder zu widerlegen. Beispielsweise könnte ähnlich wie das Training eines DNN 200 oben, um zumindest einen Teil einer Abfrage zu bestimmen, ein DNN 200 auf Grundlage von Ground-Truth-Daten trainiert werden, die angeben, dass ein Ereignis aufgetreten ist, um Datenwerte in einem Fahrzeug 105 zu erkennen, die z. B. als Reaktion auf eine Abfrage zurückgegeben werden und anzeigen, dass ein Ereignis aufgetreten ist oder nicht aufgetreten ist, d. h. bestätigt oder widerlegt ist.
In einem anderen Beispiel kann eine Abfrage einen oder mehrere Schritte beinhalten, um zu bestimmen, ob ein Fahrzeugnetzwerk gehackt oder gespooft wurde. Ein Ereignis könnte in einer Nachricht des Fahrzeugs 105 angegeben werden, wobei die Nachricht gespooft ist, d. h. als von dem Fahrzeug 105 stammend dargestellt wird, dies aber tatsächlich nicht ist. Gleichermaßen könnte ein Ereignis in einer Nachricht des Fahrzeugs 105 angegeben werden, wobei die Nachricht oder der Computer 110, der die Nachricht sendet, gehackt wurde, d. h. ein Eindringling hat die Kontrolle über den Computer 110 erlangt, um zu bewirken, dass er ungenaue und/oder unvollständige Daten bereitstellt. Um zu bestimmen, ob die Nachricht gehackt oder gespooft ist, könnte der Server 170 dazu programmiert sein, mit einer Abfrage an das Fahrzeug 105 zu antworten, die eine Verifizierung der Nachricht anfordert, z. B. das Einschließen eines privaten Schlüssels zur Authentifizierung. Alternativ oder zusätzlich könnte der Server 170 dazu programmiert sein, eine Anforderung, dass das Fahrzeug 105 das Ereignis erneut bestätigt, in die Abfrage einzuschließen.
VORGÄNGE
3 ist ein Ablaufdiagramm eines beispielhaften Vorgangs 300 zum Verarbeiten einer Nachricht von einem Fahrzeug 105. Der Vorgang 300 beginnt in einem Block 305, in dem der Server 170 eine Nachricht von einem Fahrzeug 105 empfängt, die ein Ereignis angibt, typischerweise über ein Netzwerk 135, wie vorstehend beschrieben.
Dann bestimmt der Server 170 in einem Entscheidungsblock 310, ob er eine Abfrage an das Fahrzeug 105 als Reaktion auf das Ereignis lokalisieren oder erzeugen kann. Falls nicht, endet der Vorgang 300 im Anschluss an Block 310. Andernfalls geht der Vorgang 300 zu einem Block 315 über.
In dem Block 315 wird die Abfrage, z.B. ein Satz von Anweisungen und/oder eine Anforderung von Daten, wie vorstehend beschrieben, z. B. für eine oder mehrere APIs einer oder mehrerer Steuerungen 126 des Fahrzeugs 105, an das Fahrzeug 105 gesendet, z. B. einen Computer 110, typischerweise über ein Netzwerk 135, wie vorstehend beschrieben.
Als nächstes bestimmt der Server 170 in einem Entscheidungsblock 320, ob er eine Antwort von dem Fahrzeug 105 auf die in Block 315 gesendete Abfrage empfangen hat. Typischerweise ist der Server 170 dazu programmiert, zu bestimmen, dass er keine Antwort von dem Fahrzeug 105 empfangen hat, wenn eine Antwort nicht innerhalb eines angegebenen Zeitüberschreitungszeitraums, z. B. 15 Sekunden, 30 Sekunden, eine Minute usw., empfangen wird. Wenn die Antwort nicht empfangen wird kann der Vorgang 300 im Anschluss an Block 320 enden. Andernfalls geht der Vorgang 300 zu einem Block 325 über.
In dem Block 325 führt der Server 170 eine Programmierung, wie etwa wie vorstehend beschrieben, aus, um die Antwort auf die von dem Fahrzeug 105 empfangene Abfrage zu analysieren. Das heißt, der Server 170 sagt vorher, ob das in der in dem Block 305 empfangenen Nachricht angegebene Ereignis bestätigt oder widerlegt wird.
Als nächstes bestimmt der Server 170 in einem Block 330 eine Aktion als Reaktion auf die Bestimmung in dem Block 325, dass das Ereignis bestätigt oder nicht bestätigt ist, und überträgt diese an das Fahrzeug 105. In diesem Zusammenhang beinhaltet eine „Aktion“ die Betätigung einer oder mehrerer Komponenten 125 des Fahrzeugs 105. Zum Beispiel könnte die Aktion das Bewegen des Fahrzeugs 105 zu einem angegebenen Standort beinhalten, da das Ereignis bestätigt wurde, z. B. Bewegen des Fahrzeugs 105 zu einem straßenseitigen oder sicheren Parkbereich, da ein Ereignis mit niedrigem Reifendruck bestätigt wird. In einem Beispiel könnte eine Aktion das Deaktivieren oder Verhindern der Betätigung einer oder mehrerer Komponenten des Fahrzeugs 105 beinhalten, z. B. Ausschalten eines Fahrzeugs 105, Anhalten der Bewegung des Fahrzeugs 105 usw., z. B. weil ein potenziell deaktivierendes Ereignis bestätigt wird. In einem weiteren Beispiel, in dem ein Ereignis widerlegt wird, könnte die Aktion das Betreiben des Fahrzeugs 105 auf Grundlage dessen, dass das Ereignis nicht eingetreten ist, beinhalten, z. B. auf Grundlage dessen, dass der Reifendruck innerhalb eines normalen Bereichs liegt usw.
Im Anschluss an Block 330 endet der Vorgang 300.
4 ist ein Ablaufdiagramm eines beispielhaften Vorgangs 400 für einen Computer 110 eines Fahrzeugs 105, um ein Ereignis an einen Server 170 zu melden und eine Abfrage von diesem zu verarbeiten. Der Vorgang 400 beginnt in einem Block 405, in dem der Computer 110 eine Nachricht, z. B. über das Netzwerk 135, an den Server 170 sendet, die ein Ereignis meldet, z. B. auf Grundlage eines Auslöseparameters, wie vorstehend beschrieben.
Als Nächstes empfängt der Computer 110 in einem Block 410 eine Abfrage von dem Server 170 als Reaktion auf die Nachricht des Blocks 405.
Als nächstes versucht der Computer 110 in einem Block 415, die Abfrage auszuführen. Wenn sie nicht erfolgreich ist, z. B. weil die Abfrage eine Anforderung für eine Steuerung 126 angibt, die nicht in dem Fahrzeug 105 vorhanden ist, weil die angegebene Steuerung 126 nicht auf die Abfrage reagiert usw., endet der Vorgang 400 im Anschluss an Block 415. Andernfalls geht der Vorgang 400 zu einem Block 420 über.
In dem Block 420 sendet der Computer 110 die Antwort auf die Abfrage, z. B. über das Netzwerk 135, an den Server 170.
Als Nächstes bestimmt der Computer 110 in einem Entscheidungsblock 425, ob eine Antwort von dem Server 170, z. B. innerhalb eines festgelegten Zeitüberschreitungszeitraums, z. B. 10 Sekunden, 30 Sekunden, 60 Sekunden usw., empfangen wurde. Wenn keine weitere Antwort von dem Server 170 empfangen wurde, dann endet der Vorgang 400 im Anschluss an Block 425. Anderenfalls geht der Vorgang 400 zu einem Block 430 über.
In dem Block 430 bestimmt der Computer 110, ob eine Aktion von dem Server 170 angegeben wurde, und wenn ja, führt er die Aktion aus. Beispielsweise könnte der Computer 110, wie vorstehend beschrieben, Aktoren 120 anweisen, eine oder mehrere Komponenten 125 zu betätigen und/oder die Betätigung einer oder mehrerer Komponenten 125 könnte deaktiviert oder verhindert werden. Im Anschluss an Block 430 endet der Vorgang 400.
SCHLUSSFOLGERUNG
Im in dieser Schrift verwendeten Sinne bedeutet der Ausdruck „im Wesentlichen“, dass eine Form, eine Struktur, ein Maß, eine Menge, eine Zeit usw. aufgrund von Mängeln bei Materialien, Bearbeitung, Herstellung, Datenübertragung, Berechnungszeit usw. von einem bzw. einer genauen beschriebenen Geometrie, Abstand, Maß, Menge, Zeit usw. abweichen kann.
„Auf Grundlage von/basierend auf schließt „ganz oder teilweise auf‟ Grundlage von/basierend auf‟ ein. Wenn in dieser Schrift eine erste Sache als „auf Grundlage von/basierend auf‟ der zweiten Sache beschrieben und/oder beansprucht ist, dann ist die erste Sache aus der zweiten Sache abgeleitet oder daraus berechnet und/oder aus einem Algorithmus, einem Vorgang oder einer Programmfunktion ausgegeben, der/die einen Teil des oder die gesamte zweite Sache als Eingabe akzeptiert und einen Teil der oder die gesamte erste Sache ausgibt.
Im Allgemeinen können die beschriebenen Rechensysteme und/oder -vorrichtungen ein beliebiges aus einer Reihe von Computerbetriebssystemen einsetzen, einschließlich unter anderem Versionen und/oder Varianten der Sync®-Anwendung von Ford, AppLink/Smart Device Link Middleware, der Betriebssysteme Microsoft Automotive®, Microsoft Windows®, Unix (z. B. das Betriebssystem Solaris®, vertrieben durch die Oracle Corporation in Redwood Shores, Kalifornien), AIX UNIX, vertrieben durch International Business Machines in Armonk, New York, Linux, Mac OSX und iOS, vertrieben durch die Apple Inc. in Cupertino, Kalifornien, BlackBerry OS, vertrieben durch die Blackberry, Ltd. in Waterloo, Kanada, und Android, entwickelt von der Google, Inc. und der Open Handset Alliance, oder der Plattform QNX® CAR für Infotainment, angeboten von QNX Software Systems. Beispiele für Rechenvorrichtungen beinhalten unter anderem einen Fahrzeugbordcomputer, einen Computerarbeitsplatz, einen Server, einen Desktop-, Notebook-, Laptop- oder Handheld-Computer oder ein anderes Rechensystem und/oder eine andere Rechenvorrichtung.
Computer und Rechenvorrichtungen beinhalten im Allgemeinen computerausführbare Anweisungen, wobei die Anweisungen durch eine oder mehrere Rechenvorrichtungen ausgeführt werden können, wie etwa durch die vorstehend aufgeführten. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung einer Vielfalt von Programmiersprachen und/oder -technologien erstellt werden, einschließlich unter anderem und entweder für sich oder in Kombination Java™, C, C++, Matlab, Simulink, Stateflow, Visual Basic, Java Script, Perl, HTML usw. Einige dieser Anwendungen können auf einer virtuellen Maschine zusammengestellt und ausgeführt werden, wie etwa der Java Virtual Machine, der Dalvik Virtual Machine oder dergleichen. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wodurch er einen oder mehrere Vorgänge durchführt, einschließlich eines oder mehrerer der in dieser Schrift beschriebenen Vorgänge. Derartige Anweisungen und andere Daten können unter Verwendung einer Vielfalt an computerlesbaren Medien gespeichert und übertragen werden. Eine Datei in einer Rechenvorrichtung ist im Allgemeinen eine Sammlung von Daten, die auf einem computerlesbaren Medium, wie etwa einem Speichermedium, einem Direktzugriffsspeicher usw., gespeichert sind.
Ein Speicher kann ein computerlesbares Medium (auch als prozessorlesbares Medium bezeichnet) beinhalten, das ein beliebiges nicht transitorisches (z. B. materielles) Medium beinhaltet, das am Bereitstellen von Daten (z. B. Anweisungen) beteiligt ist, die durch einen Computer (z. B. durch einen Prozessor eines Computers) gelesen werden können. Ein derartiges Medium kann viele Formen annehmen, einschließlich unter anderem nichtflüchtiger Medien und flüchtiger Medien. Nicht flüchtige Medien können beispielsweise optische und magnetische Platten und andere dauerhafte Speicher beinhalten. Flüchtige Medien können zum Beispiel einen dynamischen Direktzugriffsspeicher (dynamic random access memory - DRAM) einschließen, der typischerweise einen Hauptspeicher darstellt. Derartige Anweisungen können durch ein oder mehrere Übertragungsmedien übertragen werden, darunter Koaxialkabel, Kupferdraht und Glasfaser, einschließlich der Drähte, aus denen ein Systembus besteht, der an einen Prozessor einer ECU gekoppelt ist. Gängige Formen computerlesbarer Medien beinhalten zum Beispiel eine Diskette, eine Folienspeicherplatte, eine Festplatte, ein Magnetband, ein beliebiges anderes magnetisches Medium, eine CD-ROM, eine DVD, ein beliebiges anderes optisches Medium, Lochkarten, Lochstreifen, ein beliebiges anderes physisches Medium mit Lochmustern, einen RAM, einen PROM, einen EPROM, einen FLASH-EEPROM, einen beliebigen anderen Speicherchip oder eine beliebige andere Speicherkassette oder ein beliebiges anderes Medium, das von einem Computer ausgelesen werden kann.
Datenbanken, Datendepots oder andere Datenspeicher, die in dieser Schrift beschrieben sind, können verschiedene Arten von Mechanismen zum Speichern von, Zugreifen auf und Abrufen von verschiedene(n) Arten von Daten beinhalten, einschließlich einer hierarchischen Datenbank, eines Satzes von Dateien in einem Dateisystem, einer Anwendungsdatenbank in einem anwendereigenen Format, eines relationalen Datenbankverwaltungssystems (relational database management system - RDBMS) usw. Jeder derartige Datenspeicher ist im Allgemeinen in einer Rechenvorrichtung enthalten, die ein Computerbetriebssystem einsetzt, wie etwa eines der vorstehend erwähnten, und es wird auf eine oder mehrere von vielfältigen Weisen über ein Netzwerk darauf zugegriffen. Auf ein Dateisystem kann von einem Computerbetriebssystem zugegriffen werden und es kann in verschiedenen Formaten gespeicherte Dateien beinhalten. Ein RDBMS setzt im Allgemeinen die Structured Query Language (SQL) zusätzlich zu einer Sprache zum Erzeugen, Speichern, Editieren und Ausführen gespeicherter Prozeduren ein, wie etwa die vorstehend erwähnte PL/SQL-Sprache.
In einigen Beispielen können Systemelemente als computerlesbare Anweisungen (z. B. Software) auf einer oder mehreren Rechenvorrichtungen (z. B. Servern, PCs usw.) umgesetzt sein, die auf computerlesbaren Medien gespeichert sind (z. B. Platten, Speicher usw.), die den Rechenvorrichtungen zugeordnet sind. Ein Computerprogrammprodukt kann derartige auf computerlesbaren Medien gespeicherte Anweisungen zum Ausführen der in dieser Schrift beschriebenen Funktionen umfassen.
Hinsichtlich der in dieser Schrift beschriebenen Medien, Vorgänge, Systeme, Verfahren, Heuristiken usw. versteht es sich, dass die Schritte derartiger Vorgänge usw. zwar als gemäß einer bestimmten Reihenfolge erfolgend beschrieben worden sind, derartige Vorgänge jedoch so umgesetzt werden können, dass die beschriebenen Schritte in einer Reihenfolge durchgeführt werden, die von der hier beschriebenen Reihenfolge abweicht. Es versteht sich ferner, dass gewisse Schritte gleichzeitig durchgeführt, andere Schritte hinzugefügt oder gewisse in dieser Schrift beschriebene Schritte weggelassen werden können. Anders ausgedrückt dienen die Beschreibungen von Vorgängen in dieser Schrift dem Zwecke der Veranschaulichung bestimmter Ausführungsformen und sollten keinesfalls dahingehend ausgelegt werden, dass sie die Patentansprüche einschränken.
Dementsprechend versteht es sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Viele Ausführungsformen und Anwendungen, bei denen es sich nicht um die bereitgestellten Beispiele handelt, werden dem Fachmann beim Lesen der vorstehenden Beschreibung ersichtlich. Der Umfang der Erfindung sollte nicht unter Bezugnahme auf die vorstehende Beschreibung festgelegt werden, sondern stattdessen unter Bezugnahme auf die beigefügten Ansprüche in Zusammenhang mit dem vollständigen Umfang von Äquivalenten, zu denen solche Ansprüche berechtigen. Es wird erwartet und ist beabsichtigt, dass es zukünftige Entwicklungen im in dieser Schrift erörterten Stand der Technik geben wird und dass die offenbarten Systeme und Verfahren in derartige zukünftige Ausführungsformen aufgenommen werden. Insgesamt versteht es sich, dass die Erfindung modifiziert und variiert werden kann und ausschließlich durch die folgenden Patentansprüche eingeschränkt ist.
Alle in den Patentansprüchen verwendeten Ausdrücke sollen ihre klare und gewöhnliche Bedeutung aufweisen, wie sie von einem Fachmann verstanden wird, sofern hierin nicht ausdrücklich das Gegenteil angegeben wird. Insbesondere ist die Verwendung der Singularartikel, wie etwa „ein“, „eine“, „der“, „die“, „das“ usw., dahingehend auszulegen, dass ein oder mehrere der aufgeführten Elemente genannt werden, sofern ein Anspruch nicht eine ausdrückliche gegenteilige Einschränkung enthält.
Gemäß der vorliegenden Erfindung ist ein System bereitgestellt, das einen Computer aufweist, der einen Prozessor und einen Speicher beinhaltet, wobei der Speicher Anweisungen speichert, die durch den Prozessor zu Folgendem ausgeführt werden können: Empfangen einer ersten Nachricht von einem Fahrzeug, die ein Ereignis in dem Fahrzeug angibt; identifizieren von Fahrzeugdaten, um das Ereignis in dem Fahrzeug zu bestätigen oder zu widerlegen; identifizieren einer Anwendungsprogrammierschnittstelle (application programming interface - API) in dem Fahrzeug, um auf zumindest einige der Fahrzeugdaten zuzugreifen; und Übertragen einer zweiten Nachricht an das Fahrzeug, die eine Abfrage der Fahrzeugdaten gemäß der API beinhaltet.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die Anweisungen ferner Anweisungen beinhalten, um die Fahrzeugdaten als Reaktion auf die Abfrage zu empfangen und das Ereignis in dem Fahrzeug auf Grundlage der Fahrzeugdaten zu bestätigen oder zu widerlegen.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die Anweisungen ferner Anweisungen beinhalten, um das Ereignis auf Grundlage von Umgebungsdaten, die von einer Datenquelle außerhalb des Fahrzeugs abgerufen werden, zu bestätigen oder zu widerlegen.
Gemäß einer Ausführungsform ist die Datenquelle außerhalb des Fahrzeugs ein stationäres Infrastrukturelement und die Umgebungsdaten basieren auf Sensordaten des Infrastrukturel ements.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die Anweisungen ferner Anweisungen beinhalten, um eine Aktion für das Fahrzeug auf Grundlage des Bestätigens oder Widerlegens des Ereignisses in dem Fahrzeug anzugeben.
Gemäß einer Ausführungsform beinhaltet die Aktion das Navigieren des Fahrzeugs zu einem angegebenen Standort.
Gemäß einer Ausführungsform kann die Aktion das Deaktivieren eines Betriebs einer Fahrzeugkomponente beinhalten.
Gemäß einer Ausführungsform beinhaltet die Nachricht Fahrzeugsensordaten.
Gemäß einer Ausführungsform gibt die Nachricht eine Steuerung in dem Fahrzeug an, die dem Ereignis ausgesetzt ist.
Gemäß einer Ausführungsform wird die API auf Grundlage des Identifizierens einer Steuerung in dem Fahrzeug, die Daten bereitstellt, die das Ereignis anzeigen, identifiziert und fordert die Abfrage zumindest einige der Fahrzeugdaten von der Steuerung über die API an.
Gemäß einer Ausführungsform gibt die Abfrage an, dass das Fahrzeug Sensordaten von mindestens einem von einem zweiten Fahrzeug und einem Infrastrukturelement erhalten soll.
Gemäß einer Ausführungsform fordert die Abfrage Fahrzeugsensordaten an.
Gemäß einer Ausführungsform wird die erste Nachricht bei einer Benutzereingabe initiiert, die das Ereignis angibt.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die Anweisungen ferner Anweisungen beinhalten, um die Abfrage teilweise auf Grundlage eines Standorts des Fahrzeugs zu bestimmen.
Gemäß einer Ausführungsform beinhaltet die erste Nachricht einen Fahrzeugstandort und beinhaltet die Abfrage einen oder mehrere Schritte, um zu bestimmen, ob der Fahrzeugstandort genau ist.
Gemäß einer Ausführungsform ist die API eine erste API, wobei die Anweisungen ferner Anweisungen beinhalten, um eine zweite API in dem Fahrzeug zu identifizieren, um auf eine Auswahl der Fahrzeugdaten zuzugreifen, auf die über die erste API nicht zugegriffen werden kann.
Gemäß einer Ausführungsform beinhaltet die Nachricht einen Fahrzeugladezustand, wobei die Anweisungen ferner Anweisungen beinhalten, um die API zu identifizieren und die Abfrage zumindest teilweise auf Grundlage des Fahrzeugladezustands zu bestimmen.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die Anweisungen ferner Anweisungen beinhalten, um die Abfrage zumindest teilweise auf Grundlage einer Ausgabe von einem Programm zum maschinellen Lernen zu identifizieren.
Gemäß einer Ausführungsform ist die Erfindung ferner dadurch gekennzeichnet, dass die Anweisungen ferner Anweisungen beinhalten, um die Abfrage auf Grundlage einer Marke und eines Modells des Fahrzeugs zu bestimmen.
Gemäß einer Ausführungsform beinhaltet die Abfrage einen oder mehrere Schritte, um zu bestimmen, ob ein Fahrzeugnetzwerk gehackt oder gespooft wurde.

Claims

System, umfassend einen Computer, der einen Prozessor und einen Speicher beinhaltet, wobei der Speicher Anweisungen speichert, die durch den Prozessor zu Folgendem ausgeführt werden können: Empfangen einer ersten Nachricht von einem Fahrzeug, die ein Ereignis in dem Fahrzeug angibt; Identifizieren von Fahrzeugdaten, um das Ereignis in dem Fahrzeug zu bestätigen oder zu widerlegen; Identifizieren einer Anwendungsprogrammierschnittstelle (application programming interface - API) in dem Fahrzeug, um auf zumindest einige der Fahrzeugdaten zuzugreifen; und Übertragen einer zweiten Nachricht an das Fahrzeug, die eine Abfrage der Fahrzeugdaten gemäß der API beinhaltet.
System nach Anspruch 1, wobei die Anweisungen ferner Anweisungen beinhalten, um die Fahrzeugdaten als Reaktion auf die Abfrage zu empfangen und das Ereignis in dem Fahrzeug auf Grundlage der Fahrzeugdaten zu bestätigen oder zu widerlegen.
System nach Anspruch 2, wobei die Anweisungen ferner Anweisungen beinhalten, um das Ereignis auf Grundlage von Umgebungsdaten, die von einer Datenquelle außerhalb des Fahrzeugs abgerufen werden, zu bestätigen oder zu widerlegen.
System nach Anspruch 2, wobei die Datenquelle außerhalb des Fahrzeugs ein stationäres Infrastrukturelement ist und die Umgebungsdaten auf Sensordaten des Infrastrukturelements basieren.
System nach Anspruch 2, wobei die Anweisungen ferner Anweisungen beinhalten, um auf Grundlage des Bestätigens oder Widerlegens des Ereignisses in dem Fahrzeug eine Aktion für das Fahrzeug anzugeben.
System nach Anspruch 5, wobei die Aktion das Navigieren des Fahrzeugs zu einem angegebenen Standort und/oder das Deaktivieren eines Betriebs einer Fahrzeugkomponente beinhaltet.
System nach Anspruch 1, wobei die Nachricht eine Steuerung in dem Fahrzeug angibt, die dem Ereignis ausgesetzt ist.
System nach Anspruch 1, wobei die API auf Grundlage des Identifizierens einer Steuerung in dem Fahrzeug, die Daten bereitstellt, die das Ereignis anzeigen, identifiziert wird, und die Abfrage zumindest einige der Fahrzeugdaten von der Steuerung über die API anfordert.
System nach Anspruch 1, wobei die Abfrage angibt, dass das Fahrzeug Sensordaten von mindestens einem von einem zweiten Fahrzeug und einem Infrastrukturelement erhalten und/oder Fahrzeugsensordaten bereitstellen soll.
System nach Anspruch 1, wobei die erste Nachricht bei einer Benutzereingabe initiiert wird, die das Ereignis angibt.
System nach Anspruch 1, wobei die Anweisungen ferner Anweisungen beinhalten, um die Anfrage teilweise auf Grundlage eines Standorts des Fahrzeugs zu bestimmen.
System nach Anspruch 1, wobei die erste Nachricht einen Fahrzeugstandort beinhaltet und die Abfrage einen oder mehrere Schritte beinhaltet, um zu bestimmen, ob der Fahrzeugstandort genau ist.
System nach Anspruch 1, wobei die API eine erste API ist, wobei die Anweisungen ferner Anweisungen beinhalten, um eine zweite API in dem Fahrzeug zu identifizieren, um auf eine Auswahl der Fahrzeugdaten zuzugreifen, auf die über die erste API nicht zugegriffen werden kann.
System nach Anspruch 1, wobei die Nachricht einen Fahrzeugladezustand beinhaltet, wobei die Anweisungen ferner Anweisungen beinhalten, um die API zu identifizieren und die Abfrage zumindest teilweise auf Grundlage des Fahrzeugladezustands zu bestimmen.
System nach Anspruch 1, wobei die Abfrage einen oder mehrere Schritte beinhaltet, um zu bestimmen, ob ein Fahrzeugnetzwerk gehackt oder gespooft wurde.