DE102020104236A1 - Fahrzeugbetrieb als Reaktion auf ein Notfallereignis - Google Patents

Fahrzeugbetrieb als Reaktion auf ein Notfallereignis Download PDF

Info

Publication number
DE102020104236A1
DE102020104236A1 DE102020104236.1A DE102020104236A DE102020104236A1 DE 102020104236 A1 DE102020104236 A1 DE 102020104236A1 DE 102020104236 A DE102020104236 A DE 102020104236A DE 102020104236 A1 DE102020104236 A1 DE 102020104236A1
Authority
DE
Germany
Prior art keywords
vehicle
data
test
response
vehicles
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102020104236.1A
Other languages
English (en)
Inventor
Dexter C. Lowe
MaryAnn Adams
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
GM Global Technology Operations LLC
General Motors LLC
Original Assignee
GM Global Technology Operations LLC
General Motors LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by GM Global Technology Operations LLC, General Motors LLC filed Critical GM Global Technology Operations LLC
Publication of DE102020104236A1 publication Critical patent/DE102020104236A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W60/00—Drive control systems specially adapted for autonomous road vehicles
    • B60W60/001—Planning or execution of driving tasks
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
    • G08B25/005—Alarm destination chosen according to a hierarchy of available destinations, e.g. if hospital does not answer send to police station
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W40/00—Estimation or calculation of non-directly measurable driving parameters for road vehicle drive control systems not related to the control of a particular sub unit, e.g. by using mathematical models
    • B60W40/02—Estimation or calculation of non-directly measurable driving parameters for road vehicle drive control systems not related to the control of a particular sub unit, e.g. by using mathematical models related to ambient conditions
    • B60W40/04—Traffic conditions
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/08—Interaction between the driver and the control system
    • B60W50/14—Means for informing the driver, warning the driver or prompting a driver intervention
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W60/00—Drive control systems specially adapted for autonomous road vehicles
    • B60W60/001—Planning or execution of driving tasks
    • B60W60/0015—Planning or execution of driving tasks specially adapted for safety
    • B60W60/0016—Planning or execution of driving tasks specially adapted for safety of the vehicle or its occupants
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W60/00—Drive control systems specially adapted for autonomous road vehicles
    • B60W60/005—Handover processes
    • B60W60/0053—Handover processes from vehicle to occupant
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B21/00—Alarms responsive to a single specified undesired or abnormal condition and not otherwise provided for
    • G08B21/02—Alarms for ensuring the safety of persons
    • G08B21/10—Alarms for ensuring the safety of persons responsive to calamitous events, e.g. tornados or earthquakes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/08—Interaction between the driver and the control system
    • B60W50/14—Means for informing the driver, warning the driver or prompting a driver intervention
    • B60W2050/143—Alarm means
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Abstract

Ein System und Verfahren zum Veranlassen einer Fahrzeugreaktionsaktion, die an einem oder mehreren betroffenen Fahrzeugen als Reaktion auf ein Notfallereignis ausgeführt werden soll. das Verfahren beinhaltet: Identifizieren des/der Testfahrzeuge(s) als Reaktion auf eine Notfallereignisanzeige, wobei das/die Testfahrzeug(e) auf Basis einer Nähe zwischen einem Notfallereignisort und dem/den Fahrzeug(en) oder einer Route des/der Fahrzeuge(s) ausgewählt werden; Senden einer Datenanfrage an das/die Testfahrzeug(e); Empfangen einer Datenantwort von dem/den Testfahrzeug(en) am entfernten Server, wobei die Testdaten auf Bordsensordaten basieren, die von einem oder mehreren Fahrzeugbordsensoren erhalten werden; und Senden einer Fahrzeugreaktionsaktionsnachricht an das/die betroffene(n) Fahrzeug(e), wobei die Fahrzeugreaktionsaktionsnachricht die vom betroffenen Fahrzeug auszuführende(n) Fahrzeugreaktionsaktion(en) spezifiziert, und wobei mindestens eine der einen oder mehreren Fahrzeugreaktionsaktionen auf Basis der Testdaten bestimmt wird.

Description

  • Einleitung
  • Die vorliegende Erfindung bezieht sich auf das Sammeln von Fahrzeugdaten als Reaktion auf einen identifizierten Notfall oder eine Krise sowie auf das Bereitstellen einer Reaktionshandlung für Fahrzeuge, die von dem identifizierten Notfall oder der Krise betroffen oder beeinträchtigt oder potentiell betroffen oder beeinträchtigt sind.
  • Fahrzeuge verfügen über Hard- und Software, die in der Lage ist, verschiedene Informationen zu erhalten und zu verarbeiten, einschließlich Informationen, die von Fahrzeugbordsensoren gewonnen werden. Diese Fahrzeugbordsensoren können Sensordaten über die Umgebung des Fahrzeugs erfassen. In einigen Fällen kann eine Fahrzeugroute durch einen Notfall oder eine Krise beeinträchtigt werden, wie z.B. durch einen Waldbrand oder andere Brände/Explosionen, eingestürzte oder unpassierbare Brücken oder andere Straßen, überflutete Straßen usw. Diese Notfälle oder Krisen werden hier als „Notfallereignisse“ bezeichnet.
  • Beschreibung
  • Gemäß einem Aspekt der Erfindung ist ein Verfahren vorgesehen zum Veranlassen einer Fahrzeugreaktionsaktion, die an einem oder mehreren betroffenen Fahrzeugen als Reaktion auf ein Notfallereignis durchgeführt werden soll. Das Verfahren beinhaltet: Identifizieren eines oder mehrerer Testfahrzeuge als Reaktion auf eine Notfallereignisanzeige, wobei das eine oder die mehreren Testfahrzeuge auf Basis einer Nähe zwischen einem Notfallereignisort des Notfallereignisses und dem einen oder den mehreren Fahrzeugen oder einer Route des einen oder der mehreren Fahrzeuge ausgewählt wird; Senden einer Datenanfrage an das eine oder die mehreren Testfahrzeuge, wobei die Datenanfrage dem einen oder den mehreren Testfahrzeugen anzeigt, Testdaten an einen entfernten Server zu senden; Empfangen einer Datenantwort von dem einen oder den mehreren Testfahrzeugen am entfernten Server, wobei die Datenantwort die Testdaten enthält und wobei die Testdaten auf Bordsensordaten basieren, die von einem oder mehreren Fahrzeugbordsensoren erhalten werden; und Senden einer Fahrzeugreaktionsaktionsnachricht an jedes des einen oder der mehreren betroffenen Fahrzeuge, wobei die Fahrzeugreaktionsaktionsnachricht eine oder mehrere Fahrzeugreaktionsaktionen spezifiziert, die von dem betroffenen Fahrzeug, an das die Fahrzeugreaktionsaktionsnachricht gesendet wird, auszuführen sind, wobei mindestens eine der einen oder mehreren Fahrzeugreaktionsaktionen auf Basis der Testdaten bestimmt wird.
  • Gemäß verschiedenen Ausführungsformen kann dieses Verfahren ferner eines der folgenden Merkmale oder eine technisch machbare Kombination einiger oder aller dieser Merkmale enthalten:
    • - Empfangen der Notfallereignisanzeige, wobei die Notfallereignisanzeige den Notfallereignisort und einen Notfallereignistyp umfasst;
    • - die Datenanfrage wird auf Basis des Notfallereignistyps generiert;
    • - die Fahrzeugreaktionsaktion wird auf Basis des Notfallereignistyps und/oder der Testdaten bestimmt;
    • - die Fahrzeugreaktionsaktion wird auf Basis von Informationen über die physikalischen Fahrzeugeigenschaften bestimmt, die in einer Datenbank einer entfernten Einrichtung gespeichert sind;
    • - ein oder mehrere betroffene Fahrzeuge werden ausgewählt basierend auf einer Nähe zum Notfallereignisort, ob eine geplante Fahrzeugroute durch den Notfallereignisort führt und/oder ob das Fahrzeug am, innerhalb oder in der Nähe des Notfallereignisortes steht;
    • - die Datenanfrage spezifiziert einen Testdatentyp, eine Testdatenquelle und/oder einen Testdatenort;
    • - die Testdatenquelle spezifiziert einen bestimmten Fahrzeugbordsensor, der zur Sammlung der Testdaten verwendet werden soll;
    • - mindestens eine der Fahrzeugreaktionsaktionen, die in der an ein erstes betroffenes Fahrzeug gesendeten Fahrzeugreaktionsaktionsnachricht spezifiziert ist, wird auf Basis von Informationen über die physikalischen Fahrzeugeigenschaften des ersten betroffenen Fahrzeugs bestimmt;
    • - die mindestens eine Fahrzeugreaktionsaktion wird auf Basis der Testdaten bestimmt, die von einem ersten des einen oder der mehreren Testfahrzeuge empfangen werden, wobei die Informationen über die physikalischen Fahrzeugeigenschaft des ersten Testfahrzeugs die gleichen sind wie die Informationen über die physikalische Fahrzeugeigenschaft des ersten betroffenen Fahrzeugs oder diesen entsprechen;
    • - die Testdaten von mindestens einer der Datenantworten eines ersten Testfahrzeugs des einen oder der mehreren Testfahrzeuge umfassen Fahrzeug-zu-Fahrzeug (V2V)-Daten, die von dem ersten Testfahrzeug unter Verwendung einer drahtlosen Kurzstreckenkommunikationsschaltung (SRWC) erhalten werden; und/oder
    • - das regelmäßige Senden von Aktualisierungen der Notfallereignisdaten an eines oder mehrere der Testfahrzeuge und/oder des/der betroffenen Fahrzeugs/Fahrzeuge als Reaktion auf den Empfang aktualisierter Notfallereignisdaten durch den entfernten Server.
  • Gemäß einem weiteren Aspekt der Erfindung ist ein Verfahren vorgesehen, das es ermöglicht, als Reaktion auf einen Notfall eine Fahrzeugreaktionsaktion an einem oder mehreren betroffenen Fahrzeugen durchzuführen. Die Verfahren beinhaltet: Empfangen einer Datenanfrage von einer Backend-Einrichtung an einem ersten Fahrzeug, wobei die Datenanfrage dem einen oder mehreren Testfahrzeugen anzeigt, Testdaten an die Backend-Einrichtung zu senden, und wobei die Datenanfrage an der Backend-Einrichtung als Reaktion auf eine Notfallereignisanzeige erzeugt wird; Erhalten von Bordsensordaten von einem oder mehreren Fahrzeugbordsensoren des Fahrzeugs; Erzeugen einer Datenantwort am Fahrzeug auf Basis der Bordsensordaten, wobei die Datenantwort die Testdaten enthält, und wobei die Testdaten die Bordsensordaten oder Daten auf Basis der Bordsensordaten enthalten; und Senden der Datenantwort an die Backend-Einrichtung, wobei mindestens einige der Testdaten der Datenantwort von der Backend-Einrichtung verwendet werden, um eine oder mehrere Fahrzeugreaktionsaktionsnachrichten zu erzeugen, die jeweils eine oder mehrere Fahrzeugreaktionsaktionen spezifizieren, die von einem oder mehreren betroffenen Fahrzeugen, an die die Fahrzeugreaktionsaktionsnachricht gesendet wird, auszuführen sind.
  • Gemäß verschiedenen Ausführungsformen kann dieses Verfahren ferner eines der folgenden Merkmale oder eine technisch machbare Kombination einiger oder aller dieser Merkmale enthalten:
    • - das Verfahren wird durch das erste Fahrzeug durchgeführt, und wobei das erste Fahrzeug ein Testfahrzeug ist;
    • - die Fahrzeugbordsensoren umfassen einen Umgebungssensor, der Informationen über den Zustand der Fahrzeugumgebung erfasst;
    • - der Umgebungssensor ist ein Wassersensor, eine Lidareinheit, eine Radareinheit oder eine Kamera;
    • - das erste Fahrzeug ist eines von dem einen oder mehreren betroffenen Fahrzeugen, wobei das Verfahren ferner die folgenden Schritte umfasst: Empfangen einer ersten der Fahrzeugreaktionsaktionsnachrichten von der Backend-Einrichtung; und Ausführen der in der ersten Fahrzeugreaktionsaktionsnachricht spezifizierten Fahrzeugreaktionsaktion;
    • - die erste Fahrzeugreaktionsaktionsnachricht wird auf Basis der Testdaten erzeugt, die in der Datenantwort enthalten sind, die in der Backend-Einrichtung vom ersten Fahrzeug empfangen wird;
    • - die erste Fahrzeugreaktionsaktionsnachricht wird auf Basis von Testdaten erzeugt, die in einer anderen Datenantwort enthalten sind, die an der Backend-Einrichtung von einem anderen Testfahrzeug empfangen wurde, und/oder
    • - das erste Fahrzeug ist ein autonomes Fahrzeug (AV), wobei das erste Fahrzeug auf Basis von Notfallereignisinformationen, die von der Backend-Einrichtung empfangen werden, bestimmt, ob die AV-Fahrfunktionalität fortgesetzt werden soll.
  • Figurenliste
  • Im Folgenden werden eine oder mehrere Ausführungsformen der Erfindung in Verbindung mit den beigefügten Zeichnungen beschrieben, wobei gleiche Bezeichnungen gleiche Elemente bezeichnen, und wobei
    • 1 ein Blockdiagramm ist, das eine Ausführungsform eines Kommunikationssystems darstellt, das in der Lage ist, die hier beschriebene Verfahren zu nutzen;
    • 2 ein Flussdiagramm einer Ausführungsform eines Verfahrens ist, mit dem als Reaktion auf ein Notfallereignis eine Fahrzeugreaktionsaktion an einem oder mehreren betroffenen Fahrzeugen durchgeführt wird;
    • 3 ein Flussdiagramm einer Ausführungsform eines Verfahrens ist, mit dem als Reaktion auf Notfallereignis eine Fahrzeugreaktionsaktion an einem oder mehreren betroffenen Fahrzeugen durchgeführt wird; und
    • 4 ein Flussdiagramm einer Ausführungsform zur Durchführung Fahrzeugreaktionsaktion für ein autonomes Fahrzeug ist, das mit dem Verfahren von 2 und/oder dem Verfahren von 3 verwendet werden kann.
  • Ausführliche Beschreibung
  • Das nachfolgend beschriebene System und Verfahren ermöglicht eine Fahrzeugreaktionsaktion als Reaktion auf ein Notfallereignis. Das hierin beschriebene System und Verfahren kann gemäß verschiedenen Ausführungsformen verwendet werden, um ein oder mehrere Testfahrzeuge als Reaktion auf ein identifiziertes Notfallereignis zu identifizieren, Testdaten von dem einen oder den mehreren Testfahrzeugen zu erhalten, ein oder mehrere betroffene Fahrzeuge zu identifizieren, die von dem Notfallereignis betroffen (oder potentiell betroffen) sind, und eine des Fahrzeugreaktionsaktion zu veranlassen, die von dem/den betroffenen Fahrzeug(en) durchgeführt wird. In einer Ausführungsform kann die Fahrzeugreaktionsaktion das Präsentieren einer Warnung oder einer anderen Benachrichtigung an einen Fahrzeugnutzer am Fahrzeug und/oder kann das Umleiten des Fahrzeugs um das Notfallereignis herum oder weg von diesem umfassen. Und in einer Ausführungsform kann die Fahrzeugreaktionsaktion die Ausführung der autonomen Fahrzeugfunktionalität (AV) umfassen, die auf Basis der Testdaten und/oder anderer Informationen, die über das Notfallereignis gesammelt wurden, angepasst wird.
  • Unter Bezugnahme auf 1 wird eine Betriebsumgebung gezeigt, die ein Kommunikationssystem 10 umfasst und mit der das hierin beschriebene Verfahren implementiert werden kann. Das Kommunikationssystem 10 umfasst im Allgemeinen ein Fahrzeug 12, eine Konstellation von Satelliten des globalen Satellitennavigationssystems (GNSS) 68, ein oder mehrere drahtlose Trägersysteme 70, ein Landkommunikationsnetzwerk (im Folgenden als „Landnetzwerk“ bezeichnet) 76, einen entfernten Server 78, eine Serviceeinrichtung für gesicherte Fahrzeuge 80 und ein drahtloses Handgerät (HWD) 90. Es sollte verstanden werden, dass das offenbarte Verfahren mit einer beliebigen Anzahl von verschiedenen Systemen verwendet werden kann und nicht speziell auf die hier gezeigte Betriebsumgebung beschränkt ist. Auch die Architektur, der Aufbau, die Einrichtung und der allgemeine Betrieb des Systems 10 und seiner einzelnen Komponenten sind in der Technik allgemein bekannt. Die folgenden Absätze geben daher lediglich einen kurzen Überblick über ein solches Kommunikationssystem 10; andere, hier nicht gezeigte Systeme könnten jedoch ebenfalls die offenbarten Verfahren anwenden.
  • Das drahtlose Trägersystem 70 kann jedes geeignete Mobiltelefonsystem sein. Das drahtlose Trägersystem 70 wird so dargestellt, dass es einen Mobilfunkmast 72 enthält; das drahtlose Trägersystem 70 kann jedoch eine oder mehrere der folgenden Komponenten enthalten (z. B. je nach Mobilfunktechnologie): Mobilfunkmasten, Basis-Sende-/Empfangsstationen, Mobilfunkschaltzentralen, Basisstations-Steuerungen, entwickelte Knoten (z. B, eNodeBs), Mobility Management Entities (MMEs), Serving- und PGN-Gateways usw. sowie alle anderen Netzwerkkomponenten, die zur Verbindung des Mobilfunk-Trägersystems 70 mit dem Landnetzwerk 76 oder zur Verbindung des Mobilfunk-Trägersystems mit den Endgeräten (UEs, z. B. Telematikeinheit 36 des Fahrzeugs 12, HWD 90) erforderlich sind. Das Mobilfunk-Trägersystem 70 kann jede geeignete Kommunikationstechnologie implementieren, einschließlich GSM/GPRS-Technologie, CDMA- oder CDMA2000-Technologie, LTE-Technologie usw. Im Allgemeinen sind die drahtlosen Trägersysteme 70, ihre Komponenten, die Anordnung der Komponenten, die Interaktion zwischen den Komponenten usw. in der Technik allgemein bekannt.
  • Neben der Verwendung des drahtlosen Trägersystems 70 kann ein anderes drahtloses Trägersystem in Form von Satellitenkommunikation verwendet werden, um eine uni- oder bidirektionale Kommunikation mit dem Fahrzeug zu ermöglichen. Dies kann über einen oder mehrere Kommunikationssatelliten (nicht abgebildet) und eine Uplink-Sendestation (nicht abgebildet) erfolgen. Eine unidirektionale Kommunikation kann z.B. ein Satellitenfunkdienst sein, bei dem Programminhalt (Nachrichten, Musik usw.) von der Uplink-Sendestation empfangen, für das Hochladen verpackt und dann an den Satelliten gesendet werden, der das Programm an die Teilnehmer sendet. Bidirektionale Kommunikation kann z.B. ein Satellitentelefondienst sein, der einen oder mehrere Kommunikationssatelliten zur Weiterleitung der Telefonkommunikation zwischen dem Fahrzeug 12 und der Uplink-Sendestation nutzt. Diese Satellitentelefonie kann bei Bedarf zusätzlich oder anstelle des drahtlosen Trägersystems 70 eingesetzt werden.
  • Das Landnetzwerk 76 kann ein herkömmliches landgestütztes Telekommunikationsnetzwerk sein, das an ein oder mehrere Festnetztelefone angeschlossen ist und das drahtlose Trägersystem 70 mit dem entfernten Server 78 und/oder der Fahrzeug-Backend-Serviceeinrichtung 80 verbindet. So kann das Landnetzwerk 76 beispielsweise ein öffentliches Telefonnetz (PSTN) umfassen, wie es für die Bereitstellung von Festnetztelefonie, paketvermittelter Datenkommunikation und der Internet-Infrastruktur verwendet wird. Ein oder mehrere Segmente des Landnetzwerks 76 können durch die Verwendung eines standardmäßigen drahtgebundenen Netzwerks, eines Glasfaser- oder anderen optischen Netzwerks, eines Kabelnetzwerks, von Stromleitungen, anderen drahtlosen Netzwerken wie drahtlosen lokalen Netzwerken (WLAN) oder Netzwerken, die einen drahtlosen Breitbandzugang (BWA) bieten, oder einer beliebigen Kombination davon realisiert werden.
  • Der/Die entfernte(n) Server (oder Computer) 78 (zusammenfassend als der „Entfernte Server“ bezeichnet) (nur einer abgebildet) kann eine beliebige Anzahl von Servern oder Computern umfassen, die über ein privates oder öffentliches Netzwerk wie das Internet zugänglich sind. In einer Ausführungsform kann jeder dieser entfernten Server 78 für einen oder mehrere Zwecke verwendet werden, z. B. für die Bereitstellung einer Fahrzeugnutzer-Computeranwendung, die es einem Benutzer ermöglicht, auf Fahrzeuginformationen zuzugreifen und/oder bestimmte Fahrzeugfunktionen zu steuern. In einer Ausführung kann der entfernte Server 78 eine Fahrzeug-Anwendung 92 unterstützen (z.B. als Server für), die vom HWD 90 ausgeführt wird. Zusätzlich oder alternativ können solche zugreifbaren entfernte Server 78 z. B. sein: ein Servicecenter-Computer, auf den Diagnoseinformationen und andere Fahrzeugdaten vom Fahrzeug hochgeladen werden können; ein Client-Computer, der vom Fahrzeugbesitzer oder einem anderen Teilnehmer für Zwecke wie den Zugriff auf oder den Empfang von Fahrzeugdaten oder zur Einrichtung oder Konfiguration von Teilnehmerpräferenzen oder zur Steuerung von Fahrzeugfunktionen verwendet wird; oder ein Drittanbieter-Archiv, zu oder von dem Fahrzeugdaten oder andere Informationen bereitgestellt werden, sei es durch Kommunikation mit dem Fahrzeug 12, der Backend-Einrichtung 80 oder beidem.
  • In einer Ausführungsform stellt der entfernte Server 78 einen oder mehrere entfernte Server dar, die Informationen an andere Systeme, Geräte oder Netzwerke, wie z.B. die Backend-Einrichtung 80, liefern. Jeder dieser Server 78 kann Daten über eine Anwendungsprogrammierschnittstelle (API) bereitstellen, z. B. solche, die über das Internet oder eine andere Fernnetzverbindung verbunden werden können. Beispielsweise kann ein entfernter Wetterserver 78 zur Bereitstellung von Wetterinformationen, ein entfernter Verkehrsserver 78 zur Bereitstellung von Verkehrsinformationen (z. B. einschließlich der aktuellen Verkehrsbedingungen, der Zeitsteuerung von Verkehrssignalen oder anderer Informationen), ein entfernter Straßenserver 78 zur Bereitstellung von Informationen über verschiedene Straßen (z. B. Straßenkarteninformationen) und/oder ein entfernter Notfallsystemserver 78 zur Bereitstellung von Informationen über Notfallereignisse verwendet werden. Andere solche entfernten Server 78 sind möglich, da diese vorgenannten Server lediglich beispielhaft zur Verfügung gestellt werden.
  • Fahrzeug-Backend-Serviceeinrichtung (oder kurz „Backend-Einrichtung“) 80 ist eine dezentrale Einrichtung und befindet sich an einem physischen Ort, der vom Fahrzeug entfernt liegt 12. Die Backend-Einrichtung 80 kann so ausgelegt werden, dass die Fahrzeugelektronik 20 durch die Verwendung eines oder mehrerer elektronischer Server 82 mit einer Reihe verschiedener System-Backend-Funktionen ausgestattet werden kann. In einer Ausführung kann die Backend-Einrichtung 80 das untenstehende Verfahren 200 durchführen (2). Die Fahrzeug-Backend-Serviceeinrichtung 80 umfasst Fahrzeug-Backend-Serviceserver 82 und Datenbanken 84, die auf mehreren Speichergeräten gespeichert werden können. Die Fahrzeug-Backend-Serviceeinrichtung 80 kann eine oder alle diese verschiedenen Komponenten umfassen, und zumindest in einigen Ausführungsformen sind die verschiedenen Komponenten über ein drahtgebundenes oder drahtloses lokales Netzwerk miteinander gekoppelt. Die Backend-Einrichtung 80 kann Daten über ein oder mehrere an das Landnetzwerke 76 angeschlossene Modems empfangen und senden. Datenübertragungen können auch über drahtlose Systeme wie IEEE 802.11x, GPRS und dergleichen durchgeführt werden. Fachleute werden erkennen, dass, obwohl nur eine Backend-Einrichtung 80 und ein entfernter Server 78 in der abgebildeten Ausführungsform dargestellt sind, zahlreiche Backend-Einrichtungen 80 und/oder entfernte Server 78 verwendet werden können. Darüber hinaus können mehrere Backend-Einrichtungen 80 und/oder entfernte Server 78 geografisch verteilt sein und jeweils Informationen und Dienste miteinander koordinieren, wie die Fachleute erkennen werden.
  • Bei den Servern 82 kann es sich um Computer oder andere Computergeräte handeln, die mindestens einen Prozessor enthalten und die über Speicher verfügen. Bei den Prozessoren kann es sich um jede Art von Gerät handeln, das elektronische Befehle verarbeiten kann, einschließlich Mikroprozessoren, Mikrocontroller, Host-Prozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Die Prozessoren können dedizierte Prozessoren sein, die nur für Server 82 verwendet werden, oder sie können mit anderen Systemen geteilt werden. Der mindestens eine Prozessor kann verschiedene Arten von digital gespeicherten Befehlen ausführen, wie z. B. Software oder Firmware, die es den Servern ermöglichen, eine Vielzahl von Diensten zu erbringen, wie z. B. die Durchführung eines oder mehrerer Verfahrensschritte, wie unten beschrieben. Diese Software kann in einem computerlesbaren Speicher gespeichert werden, der ein geeignetes nichtflüchtiges, computerlesbares Medium enthalten oder ein solches sein kann. Der Speicher kann beispielsweise aus einer Reihe verschiedener Arten von RAM (random-access memory, einschließlich verschiedener Arten von dynamischem RAM (DRAM) und statischem RAM (SRAM)), ROM (Nur-Lese-Speicher), Solid-State-Laufwerken (SSDs) (einschließlich anderer Solid-State-Speicher wie z. B. Solid-State-Hybrid-Laufwerke (SSHDs)), Festplattenlaufwerken (HDDs) und magnetischen oder optischen Laufwerken aufgebaut sein. Für die Netzwerkkommunikation (z. B. Intra-Netzwerkkommunikation, Inter-Netzwerkkommunikation einschließlich Internetverbindungen) können die Server eine oder mehrere Netzwerkkarten (NICs) (einschließlich drahtloser NICs (WNICs)) enthalten, die für den Datentransport zu und von den Computern verwendet werden können. Diese NICs können es einem oder mehreren Servern 82 ermöglichen, sich miteinander, mit Datenbanken 84 oder anderen Netzwerkgeräten, einschließlich Routern, Modems und/oder Switches, zu verbinden. In einer bestimmten Ausführungsform können die NICs (einschließlich WNICs) von Server 82 den Aufbau von SRWC-Verbindungen ermöglichen und/oder Ethernet (IEEE 802.3)-Anschlüsse enthalten, an die Ethernet-Kabel angeschlossen werden können, die eine Datenverbindung zwischen zwei oder mehreren Geräten ermöglichen. Die Backend-Einrichtung 80 kann eine Reihe von Routern, Modems, Switches oder anderen Netzwerkgeräten umfassen, die zur Bereitstellung von Netzwerkfähigkeiten verwendet werden können, wie z.B. die Verbindung mit dem Landnetzwerk 76 und/oder dem Mobilfunk-Trägersystem 70.
  • Die Datenbanken 84 können auf einer Vielzahl von Speichern gespeichert werden, wie z.B. einem stromversorgten temporären Speicher oder jedem geeigneten nichtflüchtigen, computerlesbaren Medium. Der Speicher kann beispielsweise aus einer Reihe verschiedener Arten von RAM (random-access memory, einschließlich verschiedener Arten von dynamischem RAM (DRAM) und statischem RAM (SRAM)), ROM (Nur-Lese-Speicher), Solid-State-Laufwerken (SSDs) (einschließlich anderer Solid-State-Speicher wie z. B. Solid-State-Hybrid-Laufwerke (SSHDs)), Festplattenlaufwerken (HDDs) und/oder magnetischen oder optischen Laufwerken aufgebaut sein. Eine oder mehrere Datenbanken 84 in der Backend-Einrichtung 80 können verschiedene Informationen speichern und Informationen zur Überwachung der Fahrzeugstandorte enthalten, die die Standorte (z. B. geografische Standorte) verschiedener Fahrzeuge zu unterschiedlichen Zeiten umfassen können, um den Standort dieser Fahrzeuge zu verfolgen und/oder zu überwachen. In den Datenbanken 84 können auch Informationen über Notfallereignisse gespeichert werden, wie z. B. alle oder einige der in dem/den nachstehenden Verfahren verwendeten Informationen, einschließlich z. B. Informationen über Fahrzeugeigenschaften und/oder Testdaten, die von mehreren Fahrzeugen (z. B. für eine Fahrzeugflotte) erhalten wurden. Die Fahrzeugeigenschaftsinformationen sind Informationen, die bestimmte Merkmale eines bestimmten Fahrzeugs spezifizieren, wie z. B. Informationen über das Fahrzeugmodell (z. B. die Marke, das Modell, das Modelljahr usw. des Fahrzeugs) und Informationen über die physikalischen Eigenschaften des Fahrzeugs (z. B. der Unterbodenfreiraum, die Fähigkeiten des Antriebsstrangs (z. B. Vierradantrieb, Allradantrieb, Zweiradantrieb, Drehmoment- oder Leistungsabgabe), Traktionsinformationen, Rad-/Reifengröße, Fahrzeughöhe, Fahrzeuggewicht, Fahrzeugbreite). Die Testdaten umfassen Bordsensordaten, die von einem oder mehreren Testfahrzeugen erfasst werden, d. h. von Fahrzeugen, die in der Nähe (z. B. innerhalb eines vorgegebenen Abstands) oder an einem identifizierten Notfallort oder auf dem Weg zu einem identifizierten Notfallort liegen. Die Testdaten können auch andere Informationen oder Daten neben den Bordsensordaten enthalten, einschließlich GNSS-Daten, Informationen, die von einem Fahrzeugnutzer (z. B. über eine Eingabe des Fahrzeugnutzers) erhalten wurden, usw.
  • Das drahtlose Handgerät (HWD) 90 ist ein mobiles Gerät und ein Gerät für die drahtlose Kommunikation mit kurzer Reichweite (SRWC) (d. h. ein SRWC-fähiges Gerät (z. B. Bluetooth™, Wi-Fi™)) und kann Folgendes umfassen: Hardware, Software und/oder Firmware, die die Mobilfunktelekommunikation und SRWC sowie andere Anwendungen für mobile Geräte, wie z. B. eine Fahrzeug-Benutzer-Computeranwendung 92, ermöglichen. Die Hardware des HWD 90 kann umfassen: einen Prozessor und einen Speicher für die Speicherung der Software, Firmware, etc. Das HWD-Prozessor und -Speicher können verschiedene Softwareanwendungen ermöglichen, die vom Benutzer (oder Hersteller) vorinstalliert sind oder installiert werden können. In einer Ausführungsform enthält das HWD 90 eine Fahrzeugnutzeranwendung 92, die es einem Fahrzeugnutzer ermöglicht, mit dem Fahrzeug 12 zu kommunizieren (z.B. Eingabe von Routen- oder Fahrtparametern) und/oder verschiedene Aspekte oder Funktionen des Fahrzeugs zu steuern, von denen einige oben aufgeführt sind. Zusätzlich können eine oder mehrere Anwendungen dem Benutzer die Verbindung mit der Backend-Einrichtung 80 oder Call-Center-Beratern ermöglichen.
  • In einigen Ausführungsformen ist das HWD 90 ein persönliches SRWC-Gerät. Wie hier verwendet, ist ein persönliches SRWC-Gerät ein mobiles SRWC-fähiges Gerät, das von einem Benutzer tragbar ist und bei dem die Tragbarkeit des Geräts zumindest teilweise vom Benutzer abhängt, wie z. B. ein tragbares Gerät (z. B. eine Smartwatch), ein implantierbares Gerät oder ein handgehaltenes Gerät (z. B. ein Smartphone, ein Tablet, ein Laptop). Wie hier verwendet, ist ein SRWC (Short Range Wireless Communications)-Gerät ein SRWC-fähiges Gerät. In einer bestimmten Ausführungsform kann das HWD 90 ein persönliches Mobilfunk-SRWC-Gerät sein, das einen Mobilfunk-Chipsatz und/oder Mobilfunk-Verbindungsfähigkeiten sowie SRWC-Fähigkeiten beinhaltet. Mit Hilfe eines Mobilfunk-Chipsatzes kann das HWD 90 beispielsweise mit verschiedenen entfernten Geräten, darunter der entfernte Server 78 und die Server 82 der Backend-Einrichtung 80, über das drahtlose Trägersystem 70 und/oder das Landnetzwerk 76 verbunden werden.
  • Die Fahrzeugnutzeranwendung 92 ist eine Anwendung, die es dem Benutzer ermöglicht, Informationen über das Fahrzeug 12 anzuzeigen. In einigen Ausführungsformen ermöglicht es die Fahrzeugnutzeranwendung 92 dem Benutzer, Befehle an das Fahrzeug zu senden, wie z. B. das ferngesteuerte Starten des Fahrzeugmotors (oder eines anderen primären Antriebssystems), das Ver- und Entriegeln von Fahrzeugtüren usw. Die Fahrzeugnutzeranwendung 92 kann dem Benutzer auch ermöglichen, Statusinformationen zum Fahrzeug anzuzeigen, wie z.B. den Status einer oder mehrerer Straßen, die in der Nähe oder entlang einer geplanten Route des Fahrzeugs 12 liegen.
  • Das Fahrzeug 12 ist in der abgebildeten Ausführungsform als ein PKW dargestellt, aber es sollte verstanden werden, dass jedes andere Fahrzeug, einschließlich Motorräder, LKWs, Geländefahrzeuge (SUVs), Freizeitfahrzeuge (RVs), Wasserfahrzeuge, unbemannte Luftfahrzeuge (UAVs), Passagierflugzeuge, andere Flugzeuge usw., ebenfalls verwendet werden kann. Ein Teil der Fahrzeugelektronik 20 ist allgemein in 1 dargestellt und umfasst einen Empfänger 22 für das globale Satellitennavigationssystem (GNSS), ein Aufbausteuermodul oder -einheit (BCM) 24, ein Motorsteuermodul oder -einheit (ECM) 26, einen Bordcomputer 30, eine Telematikeinheit 36, Fahrzeugbordsensoren 42-48 und Fahrzeug-Benutzerschnittstellen 50-56. Einige oder alle verschiedenen Fahrzeugelektroniken können zur Kommunikation miteinander über einen oder mehrere Kommunikationsbusse, wie z.B. Kommunikationsbus 40, verbunden werden. Der Kommunikationsbus 40 versorgt die Fahrzeugelektronik 20 mit Netzwerkverbindungen über ein oder mehrere Netzwerkprotokolle. Beispiele für geeignete Netzwerkverbindungen sind ein Controller Area Network (CAN), ein medienorientierter Systemtransfer (MOST), ein lokales Verbindungsnetzwerk (LIN), ein lokales Netzwerk (LAN) und andere geeignete Verbindungen wie Ethernet oder andere, die den bekannten ISO-, SAE- und IEEE-Normen und Spezifikationen entsprechen, um nur einige zu nennen. In anderen Ausführungsformen kann jeder der VSMs über ein drahtloses Netzwerk kommunizieren und geeignete Hardware, wie z.B. SRWC (Short Range Wireless Communications) -Schaltungen, enthalten.
  • Das Fahrzeug 12 kann zahlreiche Fahrzeugsystemmodule (VSMs) als Teil der Fahrzeugelektronik 20 enthalten, wie z.B. den GNSS-Empfänger 22, das BCM 24, das ECM 26, den Bordcomputer 30, die Telematikeinheit 36, die Fahrzeugbordsensoren 42-48 und die Fahrzeug-Benutzerschnittstellen 50-56, die im Folgenden detailliert beschrieben werden. Das Fahrzeug 12 kann auch andere VSMs in Form von elektronischen Hardwarekomponenten enthalten, die im gesamten Fahrzeug angeordnet sind und die Eingaben von einem oder mehreren Sensoren empfangen und die erfassten Eingaben zur Durchführung von Diagnose-, Überwachungs-, Steuer- , Berichts- und/oder anderen Funktionen nutzen können. Jeder der VSMs kann über den Kommunikationsbus 40 mit den anderen VSMs verbunden werden. Die Software oder Firmware eines oder mehrerer VSMs kann regelmäßig oder gelegentlich aktualisiert werden, und in einigen Ausführungsformen können solche Fahrzeugaktualisierungen über die Luft (OTA) erfolgen, die z. B. vom entfernten Server 78 oder der Backend-Einrichtung 80 über das Landnetzwerk 76, das Mobilfunk-Trägersystem 70 und die Telematikeinheit 36 empfangen werden. Wie von Fachleuten erkannt wird, sind die oben genannten VSMs lediglich Beispiele für einige der Module, die in Fahrzeug 12 eingesetzt werden können, da auch zahlreiche andere möglich sind.
  • Der GNSS (Global Navigation Satellite System)-Empfänger 22 empfängt Funksignale von einer Konstellation von GNSS-Satelliten 68. Der GNSS-Empfänger 22 kann so konfiguriert werden, dass er bestimmten Vorschriften oder Gesetzen einer bestimmten Region (z. B. eines Landes) entspricht und/oder gemäß diesen arbeitet. Der GNSS-Empfänger 22 kann für die Verwendung mit verschiedenen GNSS-Implementierungen konfiguriert werden, einschließlich des globalen Positionierungssystems (GPS) für die Vereinigten Staaten, des BeiDou-Navigationssatellitensystems (BDS) für China, des globalen Navigationssatellitensystems (GLONASS) für Russland, Galileo für die Europäische Union und verschiedener anderer Navigationssatellitensysteme. Zum Beispiel kann der GNSS-Empfänger 22 ein GPS-Empfänger sein, der GPS-Signale von einer Konstellation von GPS-Satelliten 68 empfängt. Und in einem anderen Beispiel kann der GNSS-Empfänger 22 ein BDS-Empfänger sein, der eine Vielzahl von GNSS- (oder BDS-) Signalen von einer Konstellation von GNSS- (oder BDS-) Satelliten 68 empfängt. Der GNSS-Empfänger 22 kann mindestens einen Prozessor und Speicher enthalten, einschließlich eines nicht flüchtigen computerlesbaren Speichers, in dem Anweisungen (Software) gespeichert werden, auf die der Prozessor zur Durchführung der vom Empfänger 22 durchgeführten Verarbeitung zugreifen kann. In einer Ausführungsform kann der Fahrzeugstandort über den GNSS-Empfänger 22 ermittelt und an einen entfernten Server, wie z.B. die Server 82 an der Backend-Einrichtung 80 und/oder den entfernten Server 78, berichtet werden.
  • Der GNSS-Empfänger 22 kann mindestens einen Prozessor und Speicher enthalten, einschließlich eines nicht flüchtigen computerlesbaren Speichers, in dem Anweisungen (Software) gespeichert werden, auf die der Prozessor zur Durchführung der vom GNSS-Empfänger 22 durchgeführten Verarbeitung zugreifen kann. Der GNSS-Empfänger 22 kann einen Fahrzeugstandort ermitteln, der in Form von geographischen Koordinaten (z.B. Breitengrad, Längengrad, Elevation) dargestellt werden kann. Der Fahrzeugstandort (und andere Informationen, wie z.B. GNSS-Zeitdaten) können an die Backend-Einrichtung 80 gesendet und/oder periodisch berichtet werden, die den Fahrzeugstandort speichern kann.
  • Das Aufbausteuermodul (BCM) 24 kann zur Steuerung verschiedener VSMs des Fahrzeugs verwendet werden und Informationen über die VSM, einschließlich seines/ihrer aktuellen Zustands/Zustände sowie Bordsensordaten, erhalten. Das BCM 24 ist in der beispielhaften Ausführungsform von 1 als elektrisch an den Kommunikationsbus 40 angekoppelt dargestellt. In einigen Ausführungsformen kann das BCM 24 in ein Center-Stack-Modul (CSM), eine Infotainment-Einheit, den Bordcomputer 30 oder andere VSM integriert sein oder Teil davon sein. Oder das BCM kann ein separates Gerät sein, das über den Kommunikationsbus 40 mit anderen VSMs verbunden ist. Das BCM 24 kann einen Prozessor und/oder Speicher enthalten, der ähnlich wie der Prozessor 32 und der Speicher 34 des Bordcomputers 30 sein kann, wie unten beschrieben. Das BCM 24 kann mit dem Bordcomputer 30 und/oder einem oder mehreren Fahrzeugsystemmodulen (VSMs), wie z. B. dem Motorsteuerungsmodul (ECM) 26 und/oder der Telematikeinheit 36, kommunizieren. Die im Speicher gespeicherte und vom Prozessor ausführbare Software ermöglicht es dem BCM 24, eine oder mehrere Fahrzeugfunktionen oder - operationen zu steuern, z. B. die Steuerung der Zentralverriegelung, der Klimaanlage, der Außenspiegel, die Steuerung des Fahrzeugprimärantriebs (z. B. Motor, Primärantriebssystem) und/oder die Steuerung verschiedener anderer Fahrzeugmodule.
  • Das Motorsteuermodul (ECM) 26 kann verschiedene Aspekte des Motorbetriebs wie z.B. die Kraftstoffzündung und den Zündzeitpunkt steuern. Das ECM 26 ist an den Kommunikationsbus 40 angeschlossen und kann Betriebsanweisungen (oder Fahrzeugbefehle) vom BCM 24 oder anderen Fahrzeugsystemmodulen, wie z.B. dem Bordcomputer 30 oder anderen VSMs, empfangen. In einem Szenario kann das ECM 26 vom BCM 24 (oder einem anderen VSM) den Befehl erhalten, das Fahrzeug in einen Einschaltzustand des Primärantriebs zu versetzen (von einem Ausschaltzustand des Primärantriebs), d.h. die Zündung des Fahrzeugs oder eines anderen Primärantriebssystems (z.B. eines batteriebetriebenen Motors) einzuleiten. Zumindest in einigen Ausführungsformen, wenn es sich bei dem Fahrzeug um ein Hybrid- oder Elektrofahrzeug handelt, kann anstelle (oder zusätzlich zu) dem ECM 26 ein Primärantriebssteuermodul verwendet werden, und dieses Primärantriebssteuermodul kann verwendet werden, um Statusinformationen über den Primärantrieb (einschließlich Informationen über den/die Elektromotor(en) und die Batterie) zu erhalten. Ein Primärantriebeinschaltzustand bezieht sich auf einen Zustand, in dem das primäre Antriebssystem des Fahrzeugs ausgeschaltet ist, z. B. wenn der Verbrennungsmotor nicht läuft oder im Leerlauf ist, wenn ein Fahrzeugschlüssel nicht in die Stellung START oder EIN (oder Hilfsstellung) gedreht ist oder wenn das Leistungssteuerungssystem für einen oder mehrere Elektromotoren eines Elektrofahrzeugs ausgeschaltet oder nicht aktiviert ist. Ein Primärantriebseinschaltzustand ist ein Zustand, der kein Primärantriebsauschaltzustand ist.
  • Zusätzlich können das BCM 24 und/oder das ECM 26 Informationen über den Fahrzeugzustand oder bestimmte Fahrzeugkomponenten oder -systeme, einschließlich der hierin beschriebenen VSMs, bereitstellen. Beispielsweise können das BCM 24 und/oder das ECM 26 den Bordcomputer 30 und/oder die Telematikeinheit 36 mit Informationen versorgen, die anzeigen, ob sich das Fahrzeug in einem Primärantriebseinschaltzustand oder in einem Primärantriebsauschaltzustand befindet, mit Batterieinformationen von einem Fahrzeugbatteriesystem, mit Bilddaten (oder anderen Bordsensordaten) von Kamera(s) 46, mit Wassersensordaten von Wassersensor 42, mit Elektronikstabilitätskontrolldaten vom Elektronikstabilitätskontrollsensor 44, mit Lidar-/Radarinformationen von DAR-Sensor(en) 48 usw. Die Informationen können auf Anfrage des Gerätes/Computers, automatisch bei Erfüllung bestimmter Bedingungen, auf Anfrage eines anderen VSM oder periodisch (z. B. in festgelegten Zeitabständen) an den Bordcomputer 30 und/oder die Telematikeinheit 36 (oder einen anderen Fahrzeugvomputer/Steuerung) gesendet werden. Das BCM 24 bzw. das ECM 26 kann auch zur Erkennung des Vorliegens eines vorgegebenen Fahrzeugbetriebszustandes verwendet werden, was z.B. durch den Vergleich des vorgegebenen Fahrzeugbetriebszustandes (bzw. der dazugehörigen Informationen) mit aktuellen Fahrzeugbetriebszuständen (bzw. vorliegenden Fahrzeuginformationen) erfolgen kann. Das BCM 24 bzw. das ECM 26 kann dann den Bordcomputer 30 bzw. die Telematikeinheit 36 aufwecken oder anderweitig über dieses Ereignis informieren. In anderen Ausführungsformen kann der Bordcomputer 30 und/oder die Telematikeinheit 36 diese Erkennungsfunktion auf Basis der vom BCM 24 und/oder ECM 26 erhaltenen Informationen übernehmen.
  • Der Bordcomputer 30 enthält einen Prozessor 32 und Speicher 34. Der Prozessor 32 kann für die Ausführung verschiedener Computerbefehle verwendet werden, einschließlich derer, die im Speicher 34 gespeichert werden können. Der Bordcomputer 30 wird als von anderen VSMs getrennt dargestellt; zumindest in einigen Ausführungsformen kann der Bordcomputer 30 jedoch Teil eines anderen VSM der Fahrzeugelektronik 20 sein oder in diesen integriert sein, wie z.B. die Sensoren 42-48, das BCM 24, eine Infotainment-Einheit, ein Center-Stack-Modul (CSM), die Telematikeinheit 36 usw. In mindestens einer Ausführungsform führt der Bordcomputer 30 einen oder mehrere Schritte der unten beschriebenen Verfahren aus.
  • Der Prozessor 32 ist als Teil des Bordcomputers 30 enthalten und kann jede Art von Gerät sein, das elektronische Befehle verarbeiten kann, einschließlich Mikroprozessoren, Mikrocontroller, Host-Prozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Es kann ein dedizierter Prozessor sein, der nur für den Bordcomputer 30 verwendet wird, oder er kann mit anderen Fahrzeugsystemen geteilt werden. Der Prozessor 32 führt verschiedene Arten von digital gespeicherten Befehlen aus, wie z.B. im Speicher 34 gespeicherte Software- oder Firmwareprogramme, die dem Bordcomputer 30 eine Vielzahl von Diensten ermöglichen. So kann der Prozessor 32 Programme ausführen oder Daten verarbeiten, um zumindest einen Teil der unten beschriebenen Verfahren 300 (3) durchzuführen. Bei dem Speicher 34 kann es sich um einen temporären, mit Strom versorgten Speicher, ein beliebiges nicht flüchtiges, computerlesbares Medium oder einen anderen Speichertyp handeln. Der Speicher kann beispielsweise aus einer Reihe verschiedener Arten von RAM (random-access memory, einschließlich verschiedener Arten von dynamischem RAM (DRAM) und statischem RAM (SRAM)), ROM (Nur-Lese-Speicher), Solid-State-Laufwerken (SSDs) (einschließlich anderer Solid-State-Speicher wie z. B. Solid-State-Hybrid-Laufwerke (SSHDs)), Festplattenlaufwerken (HDDs) und magnetischen oder optischen Laufwerken aufgebaut sein. Ähnliche Komponenten wie der Prozessor 32 und/oder der Speicher 34 können in den GNSS-Empfänger 22, das BCM 24, das ECM 26, die Telematikeinheit 36, die Fahrzeugbordsensoren 42-48 und/oder verschiedene andere VSMs eingebaut werden, die typischerweise solche Verarbeitungs-/Speicherfähigkeiten aufweisen. Außerdem kann der Bordcomputer 30 in einigen Ausführungsformen mit anderen VSMs integriert werden und in solchen Ausführungsformen einen oder mehrere Prozessoren und/oder Speicher mit dem/den anderen VSMs gemeinsam nutzen.
  • Die Telematikeinheit 36 ist in der Lage, mit Hilfe eines Mobilfunk-Chipsatzes Daten über die Kommunikation im Mobilfunknetz zu übertragen. In mindestens einer Ausführung umfasst die Telematikeinheit 36 einen Mobilfunk-Chipsatz, einen Prozessor, einen Speicher und eine oder mehrere Antennen 38. In einer Ausführungsform kann die Telematikeinheit 36 ein eigenständiges Modul sein oder in anderen Ausführungsformen kann die Telematikeinheit 36 als Teil eines oder mehrerer anderer Fahrzeugsystemmodule, wie z. B. eines Center-Stack-Moduls (CSM), des Bordcomputers 30, des GNSS-Empfängers 22, des BCM 24, des ECM 26, einer Kopfeinheit, einer Infotainment-Einheit und/oder eines Gateway-Moduls, eingebaut oder einbezogen werden. So kann z.B. der GNSS-Empfänger 22 in die Telematikeinheit 36 integriert werden, so dass z.B. der GNSS-Empfänger 22 und die Telematikeinheit 36 direkt miteinander verbunden sind und nicht über den Kommunikationsbus 40. Die Telematikeinheit 36 kann sowohl als OEM-Einbaugerät (eingebettet) als auch als Nachrüstgerät, das in das Fahrzeug eingebaut wird, realisiert werden. In einigen Ausführungsformen kann die Telematikeinheit 36 auch die Funktionalität der drahtlosen Nahbereichskommunikation (SRWC) enthalten und eine SRWC-Schaltung beinhalten. In einer solchen Ausführung kann die Telematikeinheit 36 eine SRWC-Verbindung mit dem HWD 90 herstellen, so dass Nachrichten zwischen dem Fahrzeug 12 und dem HWD 90 kommuniziert werden können. Die Kommunikation zwischen dem Fahrzeug 12 und dem HWD 90 kann z.B. durch die Fahrzeugnutzeranwendung 92 oder eine andere Anwendung erleichtert werden.
  • Wie bereits erwähnt, enthält die Telematikeinheit 36 einen Mobilfunk-Chipsatz, der es dem Gerät ermöglicht, über ein oder mehrere Mobilfunk-Protokolle zu kommunizieren, wie sie z.B. vom drahtlosen Trägersystem 70 verwendet werden. In einem solchen Fall ist die Telematikeinheit ein Benutzergerät (UE), das an das drahtlose Trägersystem 70 angeschlossen werden kann und die Mobilfunkkommunikation durchführt, wodurch die Fahrzeugelektronik mit der Backend-Einrichtung 80 und/oder dem entfernten Server 78 verbunden werden kann. Die Telematikeinheit 36 kann ein Subscriber Identity Module (SIM) enthalten, das für die Ermöglichung der Mobilfunkkommunikation mit dem Mobilfunk-Trägersystem 70 eingesetzt werden kann.
  • Die Telematikeinheit 36 kann es ermöglichen, dass das Fahrzeug 12 über paketvermittelte Datenkommunikation mit einem oder mehreren entfernten Netzwerken (z. B. einem oder mehreren Netzwerken in der Backend-Einrichtung 80 oder dem entfernten Server 78) in Verbindung steht. Diese paketvermittelte Datenkommunikation kann über einen nicht fahrzeuggebundenen drahtlosen Zugangspunkt erfolgen, der über einen Router oder ein Modem an ein Landnetzwerk angeschlossen ist. Bei Verwendung für paketvermittelte Datenkommunikation wie TCP/IP kann das Telematikgerät 36 mit einer statischen IP-Adresse konfiguriert werden oder so eingestellt werden, dass es automatisch eine zugewiesene IP-Adresse von einem anderen Gerät im Netzwerk, wie z. B. einem Router oder einem Netzwerkadressenserver, erhält.
  • Die paketvermittelte Datenkommunikation kann auch über ein Mobilfunknetz erfolgen, das für die Telematikeinheit 36 zugänglich sein kann. In einer solchen Ausführungsform können Funkübertragungen zum Aufbau eines Kommunikationskanals, wie z. B. eines Sprach- und/oder Datenkanals, mit dem drahtlosen Trägersystem 70 verwendet werden, so dass Sprach- und/oder Datenübertragungen über den Kanal gesendet und empfangen werden können. Die Daten können entweder über eine Datenverbindung, z.B. über eine Paketdatenübertragung über einen Datenkanal, oder über einen Sprachkanal mit den bekannten Techniken gesendet werden. Für kombinierte Dienste, die sowohl Sprach- als auch Datenkommunikation beinhalten, kann das System einen einzigen Anruf über einen Sprachkanal nutzen und je nach Bedarf zwischen Sprach- und Datenübertragung über den Sprachkanal umschalten, und dies kann mit den in der Technik bekannten Techniken erfolgen.
  • Das Fahrzeug 12 verfügt über verschiedene Fahrzeugsensoren 42-48, darunter einen Wassersensor 42, einen Elektrostabilitätskontrollsensor 44, eine Kamera 46 und einen Detection and Ranging (DAR)-Sensor 48. In vielen Ausführungsvarianten umfasst das Fahrzeug 12 auch andere Fahrzeugbordsensoren, die in der abgebildeten Ausführungsform nicht gezeigt und/oder explizit beschrieben sind. Im Allgemeinen können die fahrzeugeigenen Sensoren Informationen (oder Bordsensordaten) über den Betriebszustand des Fahrzeugs (den „Fahrzeugbetriebszustand“) und/oder die Umgebung des Fahrzeugs (den „Fahrzeugumgebungszustand“) erhalten. Die Sensorinformationen können an andere VSMs, wie z.B. das BCM 24, den Bordcomputer 30 und/oder die Telematikeinheit 36 gesendet werden. In einigen Ausführungsformen können die Daten des Bordsensors auch mit Metadaten gesendet werden, die Daten zur Identifizierung des Sensors (oder des Sensortyps), der die Bordsensordaten erfasst hat, einen Zeitstempel (oder einen anderen Zeitindikator), einen Fahrzeugstandort (an dem sich das Fahrzeug bei der Erfassung der Bordsensordaten befand) und/oder andere Daten umfassen können, die sich auf die Daten des Bordsensors beziehen, die aber nicht die Daten des Bordsensors selbst ausmachen. Der „Fahrzeugbetriebszustand“ oder „Fahrzeugbetriebsbedingungen“ bezieht sich auf einen Zustand des Fahrzeugs, der den Betrieb des Fahrzeugs betrifft und den Betrieb des Primärantriebs (z. B. eines Fahrzeugmotors, von Fahrzeugantriebsmotoren) und/oder den Betrieb verschiedener VSMs oder Komponenten des Fahrzeugs umfassen kann. Zusätzlich kann der Fahrzeugbetriebszustand (oder -bedingungen) den Fahrzeugzustand in Bezug auf mechanische Operationen des Fahrzeugs oder elektrische Zustände des Fahrzeugs umfassen (z.B. ein Zustand, der durch Sensorinformationen informiert wird, die anzeigen, dass eine Fahrzeugtür geöffnet ist). Der „Fahrzeugumgebungszustand“ bezieht sich auf einen Fahrzeugzustand, der den Außenbereich des Fahrzeugs betrifft. Der Fahrzeugumgebungszustand kann Verkehrsbedingungen (z.B. die Verkehrsmenge auf einer bestimmten Fahrbahn), Straßenzustand (z.B. Eis oder Schnee auf den Fahrbahnen), Fahrbahnmerkmale (z.B. Fahrbahngeometrie, Verkehrssignale, Fahrspurinformationen), Fahrzeugposition und andere Fahrzeuginformationen (z.B. Informationen, die von anderen Fahrzeugen in der Nähe gesammelt werden, z.B. über V2V-Kommunikation) umfassen. Das Fahrzeug 12 kann einen oder mehrere Umgebungssensoren enthalten, die als Fahrzeugbordsensoren Informationen über den Umgebungszustand des Fahrzeugs erfassen.
  • Der Wassersensor 42 ist ein Umgebungssensor, der am Fahrzeug 12 installiert ist und Informationen über stehendes oder fließendes Wasser auf einer Fahrbahn (oder einem anderen nahegelegenen Bereich) erfassen kann. Mit dem Wassersensor 42 kann die Tiefe des Wassers (oder anderer Flüssigkeiten oder Niederschläge) entlang einer Fahrbahn (oder eines anderen nahegelegenen Bereichs) erkannt oder anderweitig bestimmt werden. Es können verschiedene Arten von Sensoren eingesetzt werden, wie z.B. Radar-Sensoren, Ultraschall- oder Sonar-Sensoren, etc. Der Wassersensor 42 kann Wassersensordaten erfassen, die dann über die Telematikeinheit 36 der Backend-Einrichtung 80 zur Verfügung gestellt werden können.
  • Die Bewegungssensoren 44 können verwendet werden, um Bewegungs- oder Trägheitsinformationen über das Fahrzeug zu erhalten, wie z.B. Fahrzeuggeschwindigkeit, Beschleunigung, Gierbewegung (und Gierrate), Nickbewegung, Drehbewegung und verschiedene andere Eigenschaften des Fahrzeugs, die seine Bewegung betreffen, wie sie lokal durch die Verwendung von Fahrzeugbordsensoren gemessen werden. Die Bewegungssensoren 44 können an verschiedenen Stellen am Fahrzeug montiert werden, z.B. innerhalb einer Fahrzeuginnenkabine, an einem vorderen oder hinteren Stoßfänger des Fahrzeugs und/oder an der Motorhaube des Fahrzeugs 12. Die Bewegungssensoren 44 können direkt oder über den Kommunikationsbus 40 mit verschiedenen anderen elektronischen Fahrzeuggeräten gekoppelt werden. Bewegungssensordaten können erfasst und an die anderen VSMs, einschließlich des BCM 24, des Bordcomputers 30 und/oder der Telematikeinheit 36, gesendet werden.
  • In einer Ausführungsform können die Bewegungssensoren 44 Raddrehzahlsensoren enthalten, die als Fahrzeugbordsensor in das Fahrzeug eingebaut sein können. Die Raddrehzahlsensoren sind jeweils an ein Rad des Fahrzeugs 12 gekoppelt und können eine Drehzahl des jeweiligen Rades ermitteln. Aus den Drehzahlen verschiedener Raddrehzahlsensoren kann dann eine lineare oder transversale Fahrzeuggeschwindigkeit erhalten werden. Zusätzlich können in einigen Ausführungsformen die Raddrehzahlsensoren zur Bestimmung der Beschleunigung des Fahrzeugs und/oder des Ausmaßes des Radschlupfes verwendet werden. Diese Radschlupfdaten (und/oder andere Bordsensordaten) können zur Erfassung von Informationen über die Traktion der Straße verwendet werden und können z.B. zur Anzeige von Glätte oder anderen glatten Verhältnissen verwendet werden. In einigen Ausführungsformen können Raddrehzahlsensoren als Fahrzeuggeschwindigkeitssensoren (VSS) bezeichnet werden und Teil eines Antiblockiersystems (ABS) des Fahrzeugs und/oder eines Elektrostabilitätskontrollprogramms sein. Das Elektrostabilitätskontrollprogramm kann in einem Computerprogramm oder einer Anwendung ausgeführt sein, das bzw. die auf einem nichtflüchtigen, computerlesbaren Speicher (wie z. B. dem Speicher des BCM 24 oder eines anderen VSM) gespeichert werden kann. Das Elektrostabilitätskontrollprogramms kann mit einem Prozessor des BCM oder einem anderen VSM (z.B. dem Prozessor 32 des Bordcomputers 30) ausgeführt werden und kann verschiedene Sensormesswerte oder Daten von einer Vielzahl von Fahrzeugsensoren verwenden, einschließlich der Bordsensordaten von den Fahrzeugsensoren 42-48.
  • Zusätzlich oder alternativ können die Bewegungssensoren 44 einen oder mehrere Trägheitssensoren enthalten, die als Fahrzeugbordsensoren in das Fahrzeug eingebaut sein können. Mit dem/den Trägheitssensor(en) können Sensorinformationen über die Beschleunigung und die Richtung der Beschleunigung des Fahrzeugs gewonnen werden. Die Trägheitssensoren können mikroelektromechanische Systeme (MEMS) oder Beschleunigungssensoren sein, die Trägheitsinformationen erhalten. Die Trägheitssensoren können zur Erkennung von Kollisionen auf der Basis einer Erkennung einer relativ hohen Verzögerung eingesetzt werden. Wenn eine Kollision erkannt wird, können Informationen von den Trägheitssensoren, die zur Erkennung der Kollision verwendet werden, sowie andere von den Trägheitssensoren gewonnene Informationen an das BCM 24, den Bordcomputer 30, die Telematikeinheit 36 oder andere VSM der Fahrzeugelektronik gesendet werden. Zusätzlich kann der Trägheitssensor zur Erkennung von hohen Beschleunigungs- oder Bremsniveaus eingesetzt werden. In einer Ausführungsform kann das Fahrzeug 12 eine Vielzahl von Trägheitssensoren enthalten, die im gesamten Fahrzeug angeordnet sind. Und in einigen Ausführungsformen kann jeder der Trägheitssensoren ein mehrachsiger Beschleunigungsmesser sein, der Beschleunigung oder Trägheitskraft entlang mehrerer Achsen messen kann. Die mehreren Achsen können jeweils senkrecht oder rechtwinklig zueinander stehen und zusätzlich kann eine der Achsen in Richtung von der Vorderseite zum Heck des Fahrzeugs verlaufen 12. Andere Ausführungen können einachsige Beschleunigungsmesser oder eine Kombination aus ein- und mehrachsigen Beschleunigungsmessern verwenden. Andere Arten von Sensoren können verwendet werden, einschließlich anderer Beschleunigungsmesser, Gyroskopsensoren und/oder anderer Trägheitssensoren, die bekannt sind oder in der Technik bekannt werden können.
  • Die Bewegungssensoren 44 können einen oder mehrere Gierratensensoren enthalten, die als Fahrzeugbordsensoren in das Fahrzeug eingebaut sein können. Der (die) Gierratensensor(en) kann (können) Informationen über die Winkelgeschwindigkeit des Fahrzeugs in Bezug auf eine vertikale Achse des Fahrzeugs erhalten. Die Giergeschwindigkeitssensoren können gyroskopische Mechanismen enthalten, die die Giergeschwindigkeit und/oder den Schräglaufwinkel bestimmen können. Es können verschiedene Arten von Giergeschwindigkeitssensoren verwendet werden, darunter mikromechanische Giergeschwindigkeitssensoren und piezoelektrische Giergeschwindigkei tssensoren.
  • Die Bewegungssensoren 44 können auch einen Lenkradwinkelsensor umfassen, der als Fahrzeugbordsensor in das Fahrzeug eingebaut sein kann. Der Lenkradwinkelsensor ist mit einem Lenkrad des Fahrzeugs 12 oder einer Komponente des Lenkrads gekoppelt, einschließlich derer, die Teil der Lenksäule sind. Der Lenkradwinkelsensor kann den Drehwinkel eines Lenkrades erfassen, der mit dem Winkel eines oder mehrerer Fahrzeugräder in Bezug auf eine von hinten nach vorne verlaufende Längsachse des Fahrzeugs korrespondieren kann 12. Die Sensordaten und/oder die Messwerte des Lenkradwinkelsensors können im Elektrostabilitätskontrollprogramm verwendet werden, das auf einem Prozessor des BCM 24 oder einem anderen Prozessor der Fahrzeugelektronik 20 ausgeführt werden kann.
  • Fahrzeugkamera(s) 46 ist/sind Umweltsensor(en), der/die an Fahrzeug 12 montiert ist/sind, und diese ist/sind jede geeignete Digitalkamera, die in der Industrie bekannt ist oder verwendet wird. Gemäß einem nicht einschränkenden Beispiel umfasst das Fahrzeug 12 eine Sammlung von CMOS-Kameras oder Bildsensoren 46, die sich um das Fahrzeug herum befinden, einschließlich einer Reihe von nach vom gerichteten CMOS-Kameras, die digitale Bilder liefern, die anschließend zu einer 2D- oder 3D-Darstellung der Straße und der Umgebung vor und/oder seitlich des Fahrzeugs zusammengefügt werden können. Die Fahrzeugkamera(s) 46 kann (können) Fahrzeugvideodaten an eine oder mehrere Komponenten der Fahrzeugelektronik 20, einschließlich des BCM 24, des Bordcomputers 30 und/oder der Telematikeinheit 36, liefern. Abhängig von der jeweiligen Anwendung können die Fahrzeugkamera(s) 46 sein: eine Standbildkamera, eine Videokamera und/oder eine andere Art von Bilderzeugungsgerät; eine SW- und/oder Farbkamera; eine nach vorne, nach hinten und/oder 360° ausgerichtete Kamera; Teil eines Mono- und/oder Stereosystems; eine analoge und/oder digitale Kamera; eine Kurz-, Mittel- und/oder Langstreckenkamera; und eine Kamera mit weitem und/oder engem FOV (Öffnungswinkel), um nur einige Möglichkeiten zu nennen. In einem Beispiel gibt jede Fahrzeugkamera 46 Fahrzeugvideorohdaten aus, während in anderen Beispielen jede Fahrzeugkamera 46 Bildverarbeitungsressourcen enthält und eine Vorverarbeitung der aufgenommenen Bilder vor der Ausgabe als Fahrzeugvideodaten durchführt.
  • Der/die Detection and Ranging (DAR)-Sensor(en) 48 ist/sind Umweltsensoren, die ein oder mehrere Lidargeräte und/oder Radargeräte umfassen, von denen jedes ein VSM der Fahrzeugelektronik 20 ist, der einen Sender und einen Empfänger enthält. Der/die DAR-Sensor(en) 48 kann/können an der Vorderseite des Fahrzeugs 12 montiert (oder eingebaut) sein. In einer solchen Ausführungsform kann/können der/die DAR-Sensor(en) 48 einem Bereich vor dem Fahrzeug 12 so gegenüberstehen, dass das Sichtfeld des/der DAR-Sensor(en) 48 diesen Bereich einschließt. Der/die DAR-Sensor(en) 48 kann/können in der Mitte der vorderen Stoßstange des Fahrzeugs 12, seitlich der vorderen Stoßstange des Fahrzeugs 12, an den Seiten des Fahrzeugs 12, an der Rückseite des Fahrzeugs 12 (z.B. einer hinteren Stoßstange) usw. positioniert sein. Zusätzlich oder alternativ können ein oder mehrere DAR-Sensor(en) an anderen Bereichen um das Fahrzeug herum positioniert werden, z. B. seitlich am Fahrzeug, hinten am Fahrzeug, oben auf dem Fahrzeug usw. Wie bereits erwähnt, kann/können der/die DAR-Sensor(en) eine oder mehrere einsetzbare Lidar-Einheiten enthalten, die nicht sichtbare Lichtwellen zur Objekterkennung aussenden können. Jede Lidar-Einheit arbeitet, um räumliche oder andere physikalische Informationen über ein oder mehrere Objekte im Sichtfeld der Lidar-Einheit zu erhalten, indem sie Lichtwellen aussendet und die reflektierten Lichtwellen empfängt. In vielen Ausführungsformen sendet jede Lidar-Einheit eine Vielzahl von Lichtpulsen (z.B. Laserlichtpulse) aus und empfängt die reflektierten Lichtpulse mit einem Lidar-Empfänger. Darüber hinaus können die von der/den Lidar-Einheit(en) erfassten Lidar-Daten in einem Pixel-Array (oder einer anderen ähnlichen visuellen Darstellung) dargestellt werden. Die Lidar-Einheit(en) können statische Lidar-Bilder und/oder Lidar-Bild- oder Videoströme aufnehmen. Der/die DAR-Sensor(en) 48 kann/können auch ein oder mehrere Radargeräte enthalten, die jeweils mit Hilfe von Funkwellen räumliche oder andere physikalische Informationen über ein oder mehrere Objekte im Sichtfeld des Radargerätes erhalten können. Das Radargerät kann eine separate Empfangsantenne enthalten, oder das Radargerät kann eine einzige Antenne für den Empfang und die Übertragung von Funksignalen enthalten. Und in anderen Ausführungsformen kann die Radareinheit eine Vielzahl von Sendeantennen, eine Vielzahl von Empfangsantennen oder eine Kombination davon enthalten, um die Techniken Multiple Input Multiple Output (MIMO), Single Input Multiple Output (SIMO) oder Multiple Input Single Output (MISO) zu implementieren.
  • Zusätzlich kann das Fahrzeug 12 andere, oben nicht erwähnte Sensoren enthalten, einschließlich Parksensoren, Spurwechsel- und/oder Totwinkel-Sensoren, Spurassistenzsensoren, Entfernungsmesser (d.h. Sensoren, die zur Erkennung der Entfernung zwischen dem Fahrzeug und einem anderen Objekt, z.B. durch den Einsatz von Radar oder Lidar, verwendet werden), Sicherheits- oder Diebstahlssensoren, Reifendrucksensoren, Flüssigkeitsstandsensoren (z.B., einen Kraftstoff- oder Treibstofffüllstandsensor, einen Scheibenwischerflüssigkeitsstandsensor), Bremsbelagverschleißsensoren, Regen- oder Niederschlagssensoren (z. B. Infrarotlichtsensor(en), der/die auf die Windschutzscheibe (oder ein anderes Fenster des Fahrzeugs 12) gerichtet ist/sind, um Regen oder anderen Niederschlag auf Basis der Menge des reflektierten Lichts zu erkennen) und Innen- oder Außentemperatursensoren.
  • Die Fahrzeugelektronik 20 umfasst auch eine Reihe von Fahrzeug-Benutzerschnittstellen, die den Fahrzeuginsassen die Möglichkeit bieten, Informationen bereitzustellen und/oder zu empfangen, einschließlich der optischen Anzeige 50, der Drucktaste(n) 52, des Mikrofons (der Mikrofone) 54 und des Audiosystems 56. Der Begriff „Fahrzeug-Benutzerschnittstelle“ umfasst im weitesten Sinne jede geeignete Form von elektronischen Geräten, einschließlich Hardware- und Softwarekomponenten, die sich im Fahrzeug befinden und es dem Fahrzeugnutzer ermöglichen, mit oder über eine Komponente des Fahrzeugs zu kommunizieren. Die Drucktaste(n) 52 ermöglichen die manuelle Eingabe des Benutzers in die Telematikeinheit 36, um andere Daten, Reaktionen oder Steuereingaben zu ermöglichen. Ein oder mehrere der Drucktaster 52 können jedoch an einen oder mehrere andere VSMs und/oder den Kommunikationsbus 40 angeschlossen werden. Das Audiosystem 56 stellt die Audioausgabe für einen Fahrzeuginsassen bereit und kann als dediziertes, eigenständiges System oder als Teil des primären Fahrzeugaudiosystems verwendet werden. Entsprechend der hier gezeigten Ausführungsform ist das Audiosystem 56 sowohl an den Kommunikationsbus 40 als auch an einen Entertainmentbus (nicht abgebildet) gekoppelt und kann AM-, FM- und Satellitenradio, CD, DVD und andere Multimediafunktionen bereitstellen. Diese Funktionalität kann in Verbindung mit oder unabhängig von einem Infotainment-Modul bereitgestellt werden. Das/die Mikrofon(e) 54 stellen einen Audioeingang zur Fahrzeugelektronik 20 bereit, um dem Fahrer oder anderen Insassen die Möglichkeit zu geben, Sprachbefehle zu geben und/oder Freisprechanrufe über das drahtlose Trägersystem 70 durchzuführen. Zu diesem Zweck kann es an eine automatische Sprachverarbeitungseinheit an Bord angeschlossen werden, die die in der Technik bekannte Mensch-Maschine-Schnittstellentechnologie (HMI) nutzt. Die visuelle Anzeige oder der Touchscreen 50 kann ein Grafikdisplay sein und bietet eine Vielzahl von Ein- und Ausgabefunktionen. Die Anzeige 50 kann ein Touchscreen auf der Instrumententafel, ein von der Windschutzscheibe reflektiertes Heads-up-Display oder ein Projektor sein, der Grafiken zur Betrachtung durch einen Fahrzeuginsassen projizieren kann. Die Fahrzeug-Benutzerschnittstellen können verwendet werden, um Benachrichtigungen und/oder Warnungen an die Fahrzeugnutzer zu übermitteln und/oder um Eingaben oder andere Daten von den Fahrzeugnutzern zu erhalten. Verschiedene andere Mensch-Maschine-Schnittstellen zur Bereitstellung von Eingaben von einem Menschen zum Fahrzeug wie die Schnittstellen von 1 sind lediglich ein Beispiel für eine bestimmte Implementierung.
  • Unter Bezugnahme auf 2 wird ein Verfahren 200 gezeigt, um als Reaktion auf einen Notfall an einem oder mehreren betroffenen Fahrzeugen eine Fahrzeugreaktionsaktion zu veranlassen. In einer Ausführungsform wird das Verfahren 200 (oder beliebige Schritte davon) von der Backend-Einrichtung 80 durchgeführt. Zusätzlich oder alternativ können einer oder mehrere der Schritte des Verfahrens 200 von anderen Geräten oder Systemen, wie z.B. dem/den entfernten Server(n) 78, durchgeführt werden. Obwohl die Schritte des Verfahrens 200 als in einer bestimmten Reihenfolge durchgeführt beschrieben werden, wird hiermit in Betracht gezogen, dass die Schritte des Verfahrens 200 in jeder geeigneten Reihenfolge durchgeführt werden können, wie es von den Fachleuten erkannt wird.
  • Das Verfahren 200 beginnt mit Schritt 210, wobei eine Notfallereignisanzeige empfangen wird. Die Notfallereignisanzeige ist ein Hinweis darauf, dass ein Notfallereignis eingetreten ist, vor dem Eintreten steht oder noch andauert. Die Notfallereignisanzeige kann an der Backend-Einrichtung 80 empfangen werden. In mindestens einer Ausführungsform wird die Notfallereignisanzeige von einem Notfall-/Krisenüberwachungsteam erzeugt oder bereitgestellt, das mehrere Mitarbeiter umfassen kann, die Notfälle und/oder Krisen überwachen, z. B. durch die Überwachung von Nachrichtenausgaben und/oder anderen Berichterstattungsdiensten. In solchen Fällen kann ein Mitarbeiter Eingaben in ein Computernetzwerk oder -system (z.B. in der Backend-Einrichtung 80) machen, um die Notfallereignisanzeige zu ermöglichen. In anderen Ausführungsformen kann die Notfallereignisanzeige automatisch oder programmgesteuert generiert werden, wenn bestimmte vordefinierte Bedingungen erfüllt sind, wie z.B. bestimmte Wetterbedingungen, die extreme Werte erreichen (z.B. ein Eissturm mit sehr starker Eisbildung) und/oder wenn Informationen von einem oder mehreren Fahrzeugen gemeldet wurden (z.B. durch die Analyse von Bordsensordaten, wie Kamera- oder Lidar/Radardaten). In einer Ausführungsform wird diese automatisch generierte Notfallereignisanzeige auf Basis von Informationen generiert, die von einem oder mehreren Servern empfangen werden, die von der Backend-Einrichtung 80 entfernt sind, wie z. B. dem/den entfernten Server(n) 78.
  • In einer Ausführungsform kann die Notfallereignisanzeige mit einem Notfallereignisort und einem Notfallereignistyp einhergehen (oder diesen enthalten). Der Notfallereignisort ist eine Information, die einen Ort oder eine Region angibt, die von dem Notfallereignis betroffen ist. In einer Ausführungsform kann der Notfallereignisort eine Vielzahl von geographischen Koordinaten enthalten, die ein Begrenzungspolygon (oder Gebiet) definieren. In einer anderen Ausführungsform kann der Notfallereignisort eine einzelne geographische Koordinate umfassen, die von einem Bereich (oder Radius) begleitet wird. In einer anderen Ausführungsform können gegebenenfalls Bezirke (z. B. Oakland County of Michigan) oder andere vordefinierte geografische Gebiete oder Grenzen als Notfallereignisort verwendet werden. Auch andere Arten von Informationen können als Notfallereignisort und/oder zur Definition des betroffenen Ortes oder der betroffenen Region verwendet werden. Der Notfallereignistyp gibt die Art oder Klassifizierung des Notfallereignisses an, das z.B. ein Waldbrand oder ein anderer Brand/Explosion, eingestürzte oder nicht passierbare Brücken oder andere Straßen, überflutete Straßen usw. sein kann. Beispiele für Notfallereignistypen können ein wetterbedingtes Notfallereignis und ein infrastrukturbedingtes Notfallereignis (z.B. eine eingestürzte Brücke) sein. Darüber hinaus können diese Notfallereignistypen weiter in Untertypen unterteilt werden, wie z.B. ein eisbezogenes Notfallereignis, ein hochwasserbezogenes Notfallereignis, ein Tornado-Notfallereignis, ein Hurrikan-Notfallereignis, ein schneebedingtes Notfallereignis, ein Notfallereignis wegen unpassierbarer Straßen usw. Die Notfallereignistypen und der/die Notfallereignisort(e) können z.B. in den Datenbanken 84 gespeichert werden. Das Verfahren 200 fährt dann mit Schritt 220 fort.---
  • In Schritt 220 werden ein oder mehrere Testfahrzeuge anhand ihrer Beziehung zum Notfallereignisort identifiziert. Die Testfahrzeuge sind Fahrzeuge, die als Fahrzeuge diejenigen identifiziert werden, die sich in der Nähe oder an einem Notfallereignisort (z. B. dem Notfallereignisort) befinden und/oder auf dem Weg zu oder durch einen Notfallereignisort sind. Die Testfahrzeuge können auf Basis von Fahrzeugstandortdaten identifiziert werden, die auf einem entfernten Server gespeichert sind, wie z.B. den Servern 82 in der Backend-Einrichtung 80 oder dem/den entfernten Server(n) 78. Die Fahrzeugstandortdaten (einschließlich des aktuellen Fahrzeugstandortes und der Fahrzeugrouteninformationen (z.B. Abfahrtsort, Zielort, ein oder mehrere Fahrbahnsegmente dazwischen)) für eine Fahrzeugflotte (z.B. die Fahrzeuge eines bestimmten OEM) können kontinuierlich von jedem der Fahrzeuge an den entfernten Server gesendet und in einer Datenbank gespeichert werden. Nach Schritt 220 können dann das/die Testfahrzeug(e) basierend auf ihrer Nähe zum Notfallereignisort und/oder einer Route, auf der das Fahrzeug fährt, identifiziert werden. Diese Fahrzeugrouteninformationen können auch auf dem entfernten Server, z.B. in einer Datenbank, gespeichert werden. In einer Ausführungsform liefert das HWD 90 die Routeninformationen der Fahrzeuge an die Backend-Einrichtung 80. Das Verfahren 200 fährt dann mit Schritt 230 fort.
  • In Schritt 230 wird eine Datenanfrage an jedes der identifizierten Testfahrzeuge gesendet. Die Datenanfrage ist eine Anfrage, Testdaten von dem Fahrzeug zu erhalten, an das die Datenanfrage gesendet wird. Die Datenanfrage kann alle Informationen enthalten, die ausreichen, um vom Fahrzeug, an das sie gesendet wird, eine Datenantwort zu erhalten. In einigen Ausführungsformen kann die Datenanfrage bestimmte Datenanfrageparameter spezifizieren, d. h. Parameter, die einen bestimmten Datentyp oder eine bestimmte Art von Daten (z. B. eine bestimmte Art von Daten) (oder Testdatentyp), eine bestimmte Datenquelle (z. B. einen bestimmten Sensor) (oder Testdatenquelle) und/oder eine Testdatenposition angeben oder anderweitig darauf hinweisen. Die Testdatenposition ist ein Ort, auf den sich die Testdaten beziehen. Zum Beispiel kann eine bestimmte Fahrspur eines bestimmten Fahrbahnabschnitts durch die Testdatenposition identifiziert und dann vom Fahrzeug verwendet werden, um Testdaten zu erhalten, die sich auf diesen identifizierten Fahrbahnabschnitt beziehen. Die besondere Art oder der besondere Typ von Daten (als „Testdatentyp“ bezeichnet) spezifiziert eine Art oder einen Typ von Testdaten, die werden, wie z.B. Wassersensordaten (die z.B. bei einem hochwasserbedingten Notfallereignis nützlich sein können). Die jeweilige Datenquelle (als „Testdatenquelle“ bezeichnet) gibt eine bestimmte Quelle an, aus der die Testdaten zunächst gewonnen oder erfasst werden, wie z.B. ein oder mehrere bestimmte Sensoren oder Sensorgruppen des Fahrzeugs (z.B. die Lidareinheiten, die linksgerichtete Kamera, das vorwärtsgerichtete Radar). In einer Ausführungsform kann die Datenanfrage auf das jeweilige Fahrzeug zugeschnitten werden, die z.B. basierend auf der Art der Fahrzeugbordsensoren kann. In einer Ausführungsform wird/werden die Datenanfrage(n) über das Landnetzwerk 76 und das drahtlose Trägersystem 70 gesendet und dann an der Telematikeinheit 36 des Fahrzeugs 12 empfangen. Das Verfahren 200 fährt dann mit Schritt 240 fort.
  • In Schritt 240 wird eine Datenantwort von einem oder mehreren der identifizierten Fahrzeuge empfangen, an die die Datenanfragen gesendet wurden. Die Datenantwort beinhaltet Testdaten, die vom Testfahrzeug gewonnen werden. Als Antwort auf die Datenanfrage kann das Fahrzeug 12 die angeforderten Testdaten erhalten, die die Erfassung von Bordsensordaten von einem oder mehreren Fahrzeugbordsensoren (z. B. Sensoren 42-48) und/oder den Abruf von Daten aus dem Speicher (z. B. Speicher des BCM 24, Speicher 34 des Bordcomputers 30) umfassen können. Das Fahrzeug kann dann die Testdaten verpacken und die Testdaten an den entfernten Server, der die Datenanfrage gesendet hat, oder an ein anderes entferntes Gerät oder einen anderen Server, die in der Datenanfrage benannt oder lokal im Fahrzeug gespeichert werden können, zurücksenden. In einer Ausführungsform werden die Datenantwort(en) über das Landnetzwerk 76 und das drahtlose Trägersystem 70 gesendet und in der Backend-Einrichtung 80 oder einem anderen entfernten Server empfangen. Das Verfahren 200 fährt dann mit Schritt 250 fort.
  • In Schritt 250 werden ein oder mehrere betroffene Fahrzeuge auf Basis der Testdaten und/oder der Notfallereignisanzeige identifiziert. Die betroffenen Fahrzeuge sind diejenigen Fahrzeuge, die sich in der Nähe oder an einem bestimmten Notfallort (z. B. dem Notfallereignisort), auf dem Weg zu oder durch einen bestimmten Notfallort und/oder in der Nähe oder an einem bestimmten Notfallort befinden. Der Fahrzeugstandort einer Fahrzeugflotte kann mit den gleichen Techniken bestimmt werden, die oben in Bezug auf die Testfahrzeuge diskutiert wurden. Bei einigen Ausführungsformen können die Testfahrzeuge und die betroffenen Fahrzeuge als dieselben Fahrzeuge bestimmt werden, und in einer Ausführungsform kann mit einer einzigen Bestimmung bestimmt werden, welche Fahrzeuge als Test-/betroffene Fahrzeuge gelten. Zumindest in einigen Ausführungsformen und gemäß zumindest einigen Szenarien umfassen die betroffenen Fahrzeuge auch Fahrzeuge, die keine Testfahrzeuge sind, und die Testfahrzeuge umfassen auch Fahrzeuge, die keine betroffenen Fahrzeuge sind, obwohl es gewisse Überschneidungen geben kann.
  • Wie bereits erwähnt, können die betroffenen Fahrzeuge in einer Ausführungsform anhand ihres Standortes oder der Nähe zum Notfallereignisort identifiziert werden. Zusätzlich können zumindest in einigen Ausführungsformen die Fahrzeuge anhand einer geplanten Route für das Fahrzeug identifiziert werden, die in den Fahrzeugrouteninformationen spezifiziert werden kann. Wenn die geplante Route beispielsweise Abschnitte einer Fahrbahn umfasst, die sich am oder innerhalb des Notfallereignisortes befinden, kann das Fahrzeug als ein betroffenes Fahrzeug identifiziert werden. Zusätzlich kann in einigen Ausführungsformen ein Fahrzeug mit einem ausgewiesenen Wohnsitz assoziiert werden, und wenn festgestellt wird, dass sich der ausgewiesene Wohnsitz am oder innerhalb des Notfallereignisortes befindet, kann das zugehörige Fahrzeug als betroffenes Fahrzeug identifiziert werden. Jede Kombination dieser (oder anderer) verschiedenen Arten der Identifizierung, ob ein Fahrzeug ein betroffenes Fahrzeug ist, kann ebenfalls verwendet werden. Das Verfahren 200 fährt dann mit Schritt 260 fort.
  • In Schritt 260 wird eine Fahrzeugreaktionsaktionsnachricht an das/die betroffene(n) Fahrzeug(e) gesendet. Die Fahrzeugreaktionsaktionsnachricht ist eine Nachricht, die das Fahrzeug veranlasst oder anweist, eine Fahrzeugreaktionsaktion durchzuführen. Die Fahrzeugreaktionsaktion kann aus einer Vielzahl von Fahrzeugaktionen aufgebaut sein, z. B. die Übermittlung einer Benachrichtigung (z. B. Warnung) an den Fahrzeugnutzer, die Ausführung oder Einstellung bestimmter Fahrzeugfunktionen (z. B. die Bereitstellung von Informationen an ein Elektrostabilitätskontrollmodul in Erwartung glatter Straßen), die Ausführung oder Einstellung der einer autonomen Fahrzeugs (AV)-Funktionalität, die Umleitung des Fahrzeugs (z. B. die Bestimmung einer anderen Route, die den Notfallereignisort umgeht) usw.
  • In einer Ausführungsform kann die Fahrzeugreaktionsaktion auf das jeweils betroffene Fahrzeug zugeschnitten werden, an das die Fahrzeugreaktionsaktionsnachricht gesendet werden soll. Beispielsweise kann die Fahrzeugreaktionsaktion auf Basis bestimmter Eigenschaften des betroffenen Fahrzeugs bestimmt werden, wie z. B. Informationen über die physikalischen Eigenschaften des betroffenen Fahrzeugs. Wie bereits erwähnt, können die Informationen über die physikalischen Eigenschaften des Fahrzeugs für eine Vielzahl (oder Flotte) von Fahrzeugen in Datenbanken (oder anderen Datenbank(en) oder im Speicher eines anderen entfernten Servers) gespeichert werden. In einer Ausführungsform werden ein oder mehrere betroffene Fahrzeuge anhand ihres Standortes identifiziert und dann können Informationen über physikalische Eigenschaften des Fahrzeugs für jedes des einen oder der mehreren betroffenen Fahrzeuge aus der/den Datenbank(en) abgerufen oder abgefragt werden. Dann können die Informationen über die physikalischen Eigenschaften des Fahrzeugs verwendet werden, um eine bestimmte Fahrzeugreaktionsaktion zu bestimmen, die auf dieses Fahrzeug zugeschnitten ist. Wenn es sich bei dem Notfallereignistyp beispielsweise um einen hochwasserbedingten Notfallereignistyp handelt, dann können von den Testfahrzeugen Wassersensordaten erfasst werden (siehe Schritte 230-240). Aus den Wassersensordaten kann ein minimaler Unterbodenfreiraum ermittelt werden, der für die Durchfahrt von Fahrzeugen als geeignet angesehen wird. Der minimale Unterbodenfreiraum ist ein Beispiel für eine physikalische Fahrzeugeigenschaft, die als Teil der Informationen über das physikalische Fahrzeugeigenschaft gespeichert werden kann. So kann anhand der Daten der physikalischen Fahrzeugeigenschaften ermittelt werden, welche der betroffenen Fahrzeuge einen Unterbodenfreiraum haben, der gleich oder größer als der minimale Unterbodenfreiraum ist. Bei betroffenen Fahrzeugen, deren Unterbodenfreiraum kleiner als der minimale Unterbodenfreiraum ist, kann die Fahrzeugreaktionsaktionsnachricht Anweisungen oder eine Anfrage zur Umleitung des betroffenen Fahrzeugs weg vom und/oder um den Ort des Notfallereignisses herum enthalten. Bei betroffenen Fahrzeugen, deren Unterbodenfreiraum gleich oder größer als der minimale Unterbodenfreiraum ist, können die Fahrzeugreaktionsaktionsnachrichten das Fahrzeug veranlassen, eine Warnung oder andere Benachrichtigung an die Fahrzeugnutzer bereitzustellen. Diese Warnung oder andere Benachrichtigung ist ein Beispiel für eine Fahrzeugreaktionsaktion.
  • In einigen Ausführungsformen kann die Vielzahl (oder Flotte) von Fahrzeugen mit den Testfahrzeugen verglichen werden. So kann z.B. in einer Ausführungsform ein erstes Fahrzeug eines ersten Modells/Modelljahrs als Testfahrzeug bestimmt werden, das während des Notfallereignisses kürzlich den Notfallereignisort durchfahren hat. Dieses Testfahrzeug (oder das erste Fahrzeug) kann dann Testdaten an den entfernten Server übertragen, die den Testfahrzeugstandort (d. h. den Standort des Testfahrzeugs) und andere Informationen, wie z. B. die Bordsensordaten und/oder andere Betriebsinformationen, enthalten können. Der entfernte Server kann dann ein oder mehrere betroffene Fahrzeuge (das zweite Fahrzeug/die zweiten Fahrzeuge) identifizieren, die zum gleichen Modell/Modelljahr wie das Testfahrzeug (oder das erste Fahrzeug) gehören, und auf Basis der von diesem Fahrzeug empfangenen Testdaten (und/oder anderer Testdaten oder anderer Informationen) können eine oder mehrere Fahrzeugreaktionsaktionen für das/die betroffene(n) Fahrzeug(e) (das/die zweite(n) Fahrzeug(e)) bestimmt werden. In anderen Ausführungsformen können andere Fahrzeugmodellinformationen oder andere Eigenschaften der Testfahrzeuge/betroffenen Fahrzeuge verwendet werden, um geeignete Fahrzeugreaktionsaktionen zu identifizieren oder zu bestimmen. Darüber hinaus kann zumindest in einigen Ausführungsformen die Bestimmung einer Fahrzeugreaktionsaktion auch auf anderen Notfallereignisinformationen basieren, wie z. B. der Notfallereignisart, Wetterinformationen, Verkehrsinformationen, Kantensensordaten (d. h. Sensordaten, die von einem oder mehreren Kantensensoren entlang einer oder mehrerer Fahrbahnen empfangen werden), Daten von Notfallsystemen, Fahrbahneigenschaften des Notfallereignisortes usw. Das Verfahren 200 endet dann.
  • Unter Bezugnahme auf 3 wird ein Verfahren 300 gezeigt, um als Reaktion auf einen Notfall eine Fahrzeugreaktionsaktion an einem oder mehreren betroffenen Fahrzeugen zu veranlassen. In einer Ausführungsform wird das Verfahren 300 (oder beliebige Schritte davon) vom Bordcomputer 30 ausgeführt. Zusätzlich oder alternativ können ein oder mehrere Schritte des Verfahrens 300 von anderen VSMs der Fahrzeugelektronik 20 durchgeführt werden. Obwohl die Schritte des Verfahrens 300 als in einer bestimmten Reihenfolge durchgeführt beschrieben werden, wird hiermit in Betracht gezogen, dass die Schritte des Verfahrens 300 in jeder geeigneten Reihenfolge durchgeführt werden können, wie es von den Fachleuten erkannt wird.
  • Das Verfahren 300 beginnt mit Schritt 310, wobei eine Datenanfrage von einem entfernten Server empfangen wird. Die Datenanfrage wird oben in Bezug auf Schritt 230 des Verfahrens 200 diskutiert. Wie bereits erwähnt, wird die Datenanfrage in einer Ausführungsform an der Telematikeinheit 36 des Fahrzeugs 12 empfangen. Sobald die Datenanfrage am Fahrzeug empfangen wird, kann das Fahrzeug die in der Datenanfrage enthaltenen Informationen speichern und/oder die Datenanfrage verarbeiten, um die Testdaten zu bestimmen, die gesammelt und/oder an den entfernten Server gesendet werden sollen. Das Verfahren 300 fährt dann mit Schritt 320 fort.
  • In Schritt 320 werden die Testdaten als Reaktion auf die Datenanfrage erhalten. Wie oben erwähnt, kann die Datenanfrage eine Testdatenquelle, einen Testdatentyp und/oder eine Testdatenposition angeben. In einigen Ausführungsformen können die Testdaten aus dem Abruf von Daten oder anderen Informationen aus einem Speichergerät erhalten werden, das als Teil der Fahrzeugelektronik 20 enthalten ist, wie z.B. dem Speicher 34 des Bordcomputers 30 oder dem Speicher des BCM 24. Zusätzlich oder alternativ kann das Fahrzeug mit Hilfe von Fahrzeugsensoren (z.B. Fahrzeugbordsensoren 42-48) Bordsensordaten erfassen, die zumindest als Teil der Testdaten umfasst sein können.
  • In einigen Ausführungsformen kann das Fahrzeug eine drahtlose Nahbereichskommunikationsschaltung (SRWC) verwenden, um mit einem oder mehreren Fahrzeugen in der Nähe oder anderen drahtlosen Geräten zu kommunizieren, um Testdaten zu sammeln. In einer Ausführungsform kann das Fahrzeug beispielsweise eine Fahrzeug-zu-Fahrzeug-Kommunikation (V2V) mit anderen Fahrzeugen oder Geräten in der Nähe durchführen, um die Testdaten von diesen anderen Fahrzeugen oder Geräten zu erhalten. Diese Testdaten der anderen Fahrzeuge können Fahrzeugbordsensordaten enthalten, die von den anderen Fahrzeugen in der Nähe gesammelt werden, und/oder können Sensordaten (oder andere Daten) von einem oder mehreren Kantenrechnersystemen (z. B. von Straßenseiteneinheiten und/oder zugehörigen Sensoren) enthalten. Das Verfahren 300 fährt dann mit Schritt 330 fort.
  • In Schritt 330 wird die Datenanfrage an einen entfernten Server gesendet. Dieser entfernte Server kann derselbe entfernte Server sein, der die Datenanfrage gesendet hat, oder ein anderer Server, wie oben beschrieben. In einer Ausführungsform wird die Datenantwort von der Telematikeinheit 36 über das drahtlose Trägersystem 70 und das Landnetzwerk 76 an den entfernten Server gesendet. Das Verfahren 300 fährt dann mit Schritt 340 fort.
  • In Schritt 340 empfängt das Fahrzeug von einem entfernten Server eine Fahrzeugreaktionsaktionsnachricht. Zumindest in einigen Ausführungsformen kann dieser entfernte Server der gleiche entfernte Server (oder von der gleichen Backend-Einrichtung oder dem gleichen entfernten Serversystem) sein wie der oben in Schritt 310 und/oder 330 beschriebene entfernte Server. Die Fahrzeugreaktionsaktionsnachricht und die Fahrzeugreaktionsaktion werden oben in Bezug auf Schritt 260 des Verfahrens 200 diskutiert (2). Daten oder andere Informationen, die in der Fahrzeugreaktionsaktionsnachricht enthalten sind (oder anderweitig durch Fahrzeugreaktionsaktionsnachricht angezeigt werden), können an ein oder mehrere VSMs des Fahrzeugs, wie z. B. das BCM 24, der Bordcomputer 30, die Fahrzeugbordsensoren 42-48, die Fahrzeug-Benutzerschnittstellen 50-56 und/oder das HWD 90 (über eine SRWC-Verbindung mit dem Fahrzeug 12) gesendet werden. Das Verfahren 300 fährt dann mit Schritt 350 fort.
  • In Schritt 350 wird die durch die Fahrzeugreaktionsaktionsnachricht angezeigte Fahrzeugreaktionsaktion ausgeführt. Die Fahrzeugreaktionsaktion kann auf verschiedene Wege durchgeführt werden, die von der jeweiligen durchzuführenden Fahrzeugreaktionsaktion abhängen kann. In einer Ausführungsform ist die Fahrzeugreaktionsaktion eine Benachrichtigungsaktion, bei der ein oder mehrere Fahrzeugnutzer benachrichtigt werden. Die Benachrichtigung kann z.B. über eine oder mehrere der Fahrzeug-Benutzerschnittstellen 50-56 des Fahrzeuges erfolgen. In einer anderen Ausführungsform kann die Benachrichtigung (oder Informationen, die den Inhalt oder die Art der Benachrichtigung angeben) an das HWD 90 gesendet werden und das HWD 90 kann dann dem Benutzer eine Benachrichtigung z.B. über ein Display oder über Lautsprecher geben. In einer Ausführungsform ist die Benachrichtigungsaktion eine Übersteuerungs-Warnungsaktion, die das Anhalten oder Verhindern einer Ausgabe von einer oder mehreren Fahrzeug-Benutzerschnittstellen (z. B. Fahrzeug-Benutzerschnittstellen 50-52 und 56) sowie die Bereitstellung einer Warnung oder einer anderen Benachrichtigung unter Verwendung einer oder mehrerer dieser Fahrzeug-Benutzerschnittstellen umfasst. Wenn beispielsweise das Radio oder andere Medien über das Audiosystem 56 abgespielt werden, kann als Reaktion auf den Empfang der Fahrzeugreaktionsaktionsnachricht das Radio oder andere Medien gestoppt (d. h. nicht über das Audiosystem 56 ausgegeben) werden und die Warnung oder andere Benachrichtigung kann (wie durch die Fahrzeugreaktionsaktionsnachricht angezeigt) über das Audiosystem 56 und/oder die Anzeige 50 angezeigt werden.
  • In einer anderen Ausführungsform ist die Fahrzeugreaktionsaktion eine Fahrzeugaktion, die eine Änderung des Fahrzeugbetriebs bewirkt, wie z.B. eine Änderung der Fahrleistung des Fahrzeugs. So kann das Elektrostabilitätskontrollsystem durch die Fahrzeugreaktionsaktion in einen bestimmten Modus geschaltet werden oder bestimmte Betriebsparameter einstellen. Ein weiteres Beispiel für den Fall, dass es sich bei dem Fahrzeug um ein autonomes Fahrzeug handelt (z. B. ein halbautonomes Fahrzeug, ein vollständig autonomes Fahrzeug), kann die Fahrzeugaktion eine oder mehrere Funktionen oder Aktionen des autonomen Fahrzeugs (AV) steuern oder anpassen, wie z. B. die Umleitung des Fahrzeugs weg vom Notfallereignisort und/oder das Fahren auf einer bestimmten Fahrspur, die durch die Fahrzeugreaktionsaktionsnachricht spezifiziert werden kann. In anderen Ausführungsformen kann die Fahrzeugreaktionsaktion (lediglich) Parameter angeben, die bei der Ausführung bestimmter Fahrzeugfunktionen, wie z.B. bestimmter AV-Funktionen oder Aktionen, verwendet werden sollen. Das Verfahren 300 endet dann.
  • Unter Bezugnahme auf 4 wird ein Verfahren 400 zur Durchführung einer Fahrzeugreaktionsaktion für ein autonomes Fahrzeug gezeigt, das mit dem Verfahren 200 ( 2) und/oder dem Verfahren 300 (3) verwendet werden kann. Ein autonomes Fahrzeug (AV) ist ein Fahrzeug, das zumindest teilautonom ist, einschließlich vollständig autonomer Fahrzeuge. In der einen Ausführungsform kann das Verfahren 400 für jedes betroffene autonome Fahrzeug oder in einer anderen Ausführungsform kann das Verfahren 400 für jedes betroffene hochautonome Fahrzeug (d.h. jene Fahrzeuge, die über einem Level 3 gemäß SAE International's Standard J3016 liegen) durchgeführt werden. Obwohl die Schritte des Verfahrens 400 als in einer bestimmten Reihenfolge durchgeführt beschrieben werden, wird hiermit in Betracht gezogen, dass die Schritte des Verfahrens 400 in jeder geeigneten Reihenfolge durchgeführt werden können, wie es von den Fachleuten erkannt wird.
  • Das Verfahren 400 beginnt mit Schritt 410, wobei eine oder mehrere erweiterte autonome Funktionen aktiviert werden. Die erweiterten autonomen Funktionen können eine oder mehrere AV-Fahrfunktionen umfassen, die auf Basis von Informationen über Notfallereignisse angepasst werden, und in mindestens einer Ausführungsform können diese erweiterten autonomen Funktionen in der Fahrzeugreaktionsaktionsnachricht angegeben und/oder als Reaktion auf die Fahrzeugreaktionsaktionsnachricht ausgeführt oder aktiviert werden. In einer anderen Ausführungsform können eine oder mehrere erweiterte autonome Funktionen bestimmt werden, die auf Basis von Informationen, die in einer anderen Nachricht von einem entfernten Server enthalten sind, aktiviert oder ausgeführt werden. Eine verbesserte autonome Funktion kann z.B. eine verbesserte AV-Fahrfunktion sein, die so angepasst ist, dass sie AV-Funktionalität bietet, die auf den Antrieb des Fahrzeugs über rutschige Fahrbahnen zugeschnitten ist. In einer Ausführungsform kann die erweiterte AV-Fahrfunktion auf Basis von Informationen aktiviert werden, die als Teil der Fahrzeugreaktionsaktionsnachricht enthalten sind. Das Verfahren 400 fährt dann mit Schritt 420 fort.
  • In Schritt 420 kann festgelegt werden, ob die AV-Fahrfunktionalität weitergeführt werden soll. In einer Ausführungsform kann festgestellt werden, ob es zu gefährlich oder riskant ist, mit der AV-Fahrfunktionalität fortzufahren. Diese Bestimmung kann lokal am Fahrzeug erfolgen oder an einem entfernten Server vorgenommen und dem Fahrzeug mitgeteilt werden, z. B. als Teil der Fahrzeugreaktionsaktionsnachricht. In einer Ausführungsform kann das Fahrzeug anhand von Bordsensordaten beurteilen, ob die Fahrbahnbedingungen zu gefährlich oder riskant sind, um die AV-Fahrfunktionalität weiter auszuführen oder ob die AV-Fahrfunktion anderweitig fortgesetzt werden soll. Wenn festgestellt wird, dass die AV-Fahrfunktionalität nicht fortgesetzt werden soll, fährt das Verfahren 400 mit Schritt 430 fort. Andernfalls fährt das Verfahren 400 dann mit Schritt 440 fort.
  • In Schritt 430 wird die AV-Fahrfunktionalität deaktiviert. Dies kann das Umschalten der Steuerung vom Fahrzeug von einer AV-Steuereinheit auf manuelle Fahreingaben, wie z.B. Lenkrad, Bremspedal und Gas-/Drosselklappenpedal, beinhalten. Es kann auch eine Benachrichtigung an den Fahrzeugführer erfolgen, die ihn darüber informiert, dass das Fahrzeug auf manuelle Steuerung umgeschaltet wird. In einer Ausführungsform kann das Fahrzeug die AV-Fahrfunktionalität nutzen, um das Fahrzeug zum Anhalten zu bringen, damit ein sicherer Übergang von der AV-Fahrfunktionalität zum manuellen Fahren möglich ist. Das Verfahren 400 fährt dann mit Schritt 450 fort.
  • In Schritt 440 wird dem betroffenen Fahrzeug eine Notfallereignisinformation und/oder der Zugang zu einem Berater zur Verfügung gestellt. In einer Ausführungsform kann die Notfallereignisinformation von einem entfernten Server bereitgestellt werden und eine Warnung oder andere Benachrichtigung, wie die oben beschriebenen, enthalten. Zusätzlich oder alternativ kann der Zugang zu einem Berater (z.B. eine Person, die sich in einem Backend-Büro befindet) bereitgestellt werden, der in Form eines Freisprechanrufes erfolgen kann. In anderen Ausführungsformen kann dem Fahrzeug während der Durchführung der AV-Fahrfunktionalität der Zugang zu einem Berater und/oder der Notfallereignisinformation zur Verfügung gestellt werden. Das Verfahren 400 fährt dann mit Schritt 450 fort.
  • In Schritt 450 erhält das Fahrzeug eine Anzeige, dass das Notfallereignis beendet ist. In einer Ausführungsform kann diese Angabe als Teil einer Nachricht von einem entfernten Server, wie z.B. einem der Server 82 der Backend-Einrichtung 80, empfangen werden. In einer Ausführungsform kann das Fahrzeug eine Route wieder aufnehmen, die zuvor aufgrund des Notfallereignisses geändert wurde. Zum Beispiel kann eine Route des Fahrzeugs als Teil der Fahrzeugreaktionsaktion geändert werden. Erhält das Fahrzeug jedoch einen Hinweis, dass das Notfallereignis vor dem Ende der Route beendet wurde, kann die ursprüngliche Route nach dem Ende des Notfallereignisses wieder aufgenommen werden. Als Reaktion auf diesen Hinweis des Endes des Notfallereignisses können auch andere Fahrzeugfunktionalitäten ausgeführt werden. Das Verfahren 400 endet dann.
  • In einer Ausführungsform kann das Verfahren 200 und/oder das Verfahren 300 so modifiziert werden, dass die Testfahrzeuge kontinuierlich Testdaten erhalten und an die Backend-Einrichtung zurücksenden. Die Testfahrzeuge können dann die Erfassung und das Senden der Testdaten an die Backend-Einrichtung beenden, wenn das Fahrzeug einen Hinweis erhält, dass das Notfallereignis beendet ist, oder wenn der entfernte Server einen Hinweis liefert, das Senden der Testdaten zu stoppen.
  • In einer Ausführungsform kann das Verfahren 200 und/oder das Verfahren 300 so modifiziert werden, dass ein entfernter Server (z.B. einer der in den Schritten 210-260 beschriebenen) kontinuierlich Notfallereignisdaten oder andere Informationen an die Testfahrzeuge und/oder die betroffenen Fahrzeuge senden kann. Einige oder alle dieser Notfallereignisdaten können einem Fahrzeugnutzer über eine oder mehrere Fahrzeug-Benutzerschnittstellen präsentiert oder vom Fahrzeug zur Durchführung der Fahrzeugfunktionalität genutzt werden. Außerdem können in einigen Ausführungsformen Aktualisierungen der Notfallereignisdaten regelmäßig gesendet oder als Reaktion darauf gesendet werden, dass der entfernte Server aktualisierte Notfallereignisdaten erhält. Diese Notfallereignisdaten und/oder die aktualisierten Notfallereignisdaten können einen oder mehrere Notfallereignisorte, einen Notfallereignistyp und/oder andere Informationen über das Notfallereignis enthalten. In einer Ausführungsform können die aktualisierten Notfallereignisdaten auf Basis von Testdaten, die von einem oder mehreren Testfahrzeugen gesammelt wurden, bestimmt werden. In einer Ausführungsform können die Aktualisierungen der Notfallereignisdaten auf ein bestimmtes Fahrzeug zugeschnitten werden und/oder können Routenaktualisierungen für dieses Fahrzeug (oder eine Reihe von Fahrzeugen) enthalten.
  • In einer Ausführungsform kann das Verfahren 200 und/oder das Verfahren 300 so modifiziert werden, dass das Fahrzeug den Fahrzeugstandort melden kann, wenn das Fahrzeug gefangen oder anderweitig nicht beweglich/fahrbar von einem Notfallort entfernt ist. Beispielsweise kann der/die Wassersensor(en) 42 eine Funktion zur Hochwassererkennung implementieren, bei der der/die Wassersensor(en) 42 das Vorhandensein von Wasser über einer bestimmten Schwellenhöhe erkennen und das Fahrzeug in diesem Fall seinen Standort bestimmen kann (z. B. mit Hilfe des GNSS-Empfängers 22) und dann diesen Fahrzeugstandort (und/oder andere Informationen, wie z. B. die Bordsensordaten) an einen entfernten Server oder eine Backend-Einrichtung melden.
  • In einer Ausführungsform kann das Verfahren 200 und/oder das Verfahren 300 so modifiziert werden, dass das Fahrzeug live (d.h. in Echtzeit, kontinuierlich gestreamt) Bordsensordaten (oder andere Betriebsinformationen) an einen entfernten Server und/oder Berater liefern kann. Beispielsweise kann ein Kamerastream kontinuierlich auf den entfernten Server gestreamt werden, um von einem Berater über eine grafische Benutzerschnittstelle (GUI) einer Backend-Berater-Computeranwendung betrachtet zu werden. Auch andere Fahrzeugdaten können dem Berater präsentiert werden.
  • In einer Ausführungsform kann die Fahrzeugreaktionsaktionsnachricht eine oder mehrere (z. B. mehrere) Fahrzeugreaktionsaktionen anzeigen, spezifizieren oder enthalten, die von dem/den betroffenen Fahrzeug(en) ausgeführt werden sollen. Außerdem wird in einer Ausführungsform mindestens eine Fahrzeugreaktionsaktion auf Basis der Testdaten bestimmt, die von mindestens einem der ein oder mehreren Testfahrzeuge empfangen werden. Ebenfalls in einigen Ausführungsformen, wenn die Informationen über die physikalischen Eigenschaften des ersten Testfahrzeugs mit den Informationen über die physikalischen Eigenschaften des einen oder mehrerer betroffener Fahrzeuge übereinstimmen (oder mit diesen korrespondieren), kann die Reaktionsaktion auf Basis der vom ersten Testfahrzeug erhaltenen Daten bestimmt werden. Wenn z.B. das erste Testfahrzeug einen Notfallereignisort (z.B. eine überflutete Fahrbahn) erfolgreich durchfahren hat und das erste Testfahrzeug die gleiche (d.h. die gleiche oder als gleich klassifizierte, z.B. innerhalb eines Wertebereichs) Unterbodenfreiraumhöhe (ein Beispiel Informationen über die physikalischen Fahrzeugeigenschaften) aufweist, dann kann festgestellt werden, dass das eine oder mehrere betroffene Fahrzeuge mit gleicher Unterbodenfreiraumhöhe für die Durchfahrt durch den Notfallereignisort geeignet sein können.
  • In einer Ausführungsform kann das Verfahren 200, das Verfahren 300, das Verfahren 400 und/oder der/die Schritt(e) oder Teile davon in einem oder mehreren Computerprogrammen (oder „Anwendungen“ oder „Skripte“) implementiert werden, die in einem oder mehreren computerlesbaren Datenträgern ausgeführt sind und Befehle enthalten, die von einem oder mehreren Prozessoren des einen oder der mehreren Computer eines oder mehrerer Systeme nutzbar (z.B. ausführbar) sind. Das/die Computerprogramm(e) kann/können ein oder mehrere Softwareprogramme umfassen, die aus Programmbefehlen im Quellcode, Objektcode, ausführbarem Code oder anderen Formaten aufgebaut sind. In einer Ausführungsform kann jedes oder mehrere der Computerprogramme ein oder mehrere Firmwareprogramme und/oder Hardwarebeschreibungssprachdateien (HDL) enthalten. Darüber hinaus kann/können das/die Computerprogramm(e) jeweils mit beliebigen programmbezogenen Daten verknüpft werden, und in einigen Ausführungsformen können die Computerprogramme mit den programmbezogenen Daten gepackt werden. Die programmbezogenen Daten können Datenstrukturen, Nachschlagetabellen, Konfigurationsdateien, Zertifikate oder andere relevante Daten in einem anderen geeigneten Format enthalten. Die Programmanweisungen können Programmmodule, Routinen, Programme, Funktionen, Prozeduren, Verfahren, Objekte, Komponenten und/oder dergleichen enthalten. Das/die Computerprogramm(e) kann/können auf einem oder mehreren Computern ausgeführt werden, z.B. auf mehreren Computern, die miteinander kommunizieren.
  • Das/die Computerprogramm(e) kann/können auf computerlesbaren Medien (z. B. Speicher des Fahrzeugs 12 (z. B. Speicher 34), anderer Fahrzeugspeicher, Speicher des entfernten Servers 78, Speicher der Backend-Einrichtung 80, eine Kombination davon) ausgeführt sein, die nicht flüchtig sein können und ein oder mehrere Speichergeräte, Herstellungsgegenstände oder dergleichen umfassen können. Zu den beispielhaften computerlesbaren Medien gehören Computersystemspeicher, z. B. RAM (Random Access Memory), ROM (Read Only Memory); Halbleiterspeicher, z. B. EPROM (löschbares, programmierbares ROM), EEPROM (elektrisch löschbares, programmierbares ROM), Flash-Speicher; magnetische oder optische Platten oder Bänder und/oder dergleichen. Das computerlesbare Medium kann auch Verbindungen von Computer-zu-Computer-Verbindungen umfassen, z. B. wenn Daten über ein Netzwerk oder eine andere Kommunikationsverbindung (entweder kabelgebunden, drahtlos oder eine Kombination davon) übertragen oder bereitgestellt werden. Eine beliebige Kombination(en) der oben genannten Beispiele ist ebenfalls im Umfang der computerlesbaren Medien enthalten. Es ist daher zu verstehen, dass das Verfahren zumindest teilweise von jedem elektronischen Artikel und/oder Gerät durchgeführt werden kann, das in der Lage ist, Anweisungen auszuführen, die einem oder mehreren Schritten der offenbarten Verfahren entsprechen.
  • Es ist zu verstehen, dass es sich bei den vorstehenden Ausführungen um die Beschreibung einer oder mehrerer Ausführungsformen der Erfindung handelt. Die Erfindung ist nicht auf die hierin offenbarte(n) besondere(n) Ausführungsform(en) beschränkt, sondern wird ausschließlich durch die nachstehenden Ansprüche definiert. Darüber hinaus beziehen sich die in der vorstehenden Beschreibung enthaltenen Aussagen auf bestimmte Ausführungsformen und sind nicht als Einschränkung des Erfindungsumfangs oder der Definition der in den Ansprüchen verwendeten Begriffe zu verstehen, es sei denn, ein Begriff oder eine Formulierung ist oben ausdrücklich definiert. Verschiedene andere Ausführungsformen und verschiedene Änderungen und Modifikationen der offenbarten Ausführungsform(en) werden für die Fachleute ersichtlich werden. Alle anderen Ausführungsformen, Änderungen und Modifikationen sind vom Umfang der beigefügten Ansprüche umfasst.
  • Wie in dieser Spezifikation und in den Ansprüchen verwendet, sind die Begriffe „z.B.“, „zum Beispiel“, „beispielsweise“, „wie etwa“ und „wie“ und die Verben „umfassen“, „haben“, „einschließlich“ und ihre anderen Verbformen, wenn sie in Verbindung mit einer Auflistung von einem oder mehreren Bestandteilen oder anderen Gegenständen verwendet werden, jeweils als nicht abschließend auszulegen, was bedeutet, dass die Auflistung nicht als Ausschluss anderer, zusätzlicher Bestandteile oder Gegenstände zu betrachten ist. Andere Begriffe sind im weitesten Sinne auszulegen, es sei denn, sie werden in einem Zusammenhang verwendet, der eine andere Auslegung erfordert. Darüber hinaus ist der Begriff „und/oder“ als inklusives ODER zu verstehen. Daher ist beispielsweise der Ausdruck „A, B und/oder C“ so auszulegen, dass er alle folgenden Aspekte umfasst: „A“; „B“; „C“; „A und B“; „A und C“; „B und C“; und „A, B und C“.

Claims (10)

  1. Verfahren zum Veranlassen einer Fahrzeugreaktionsaktion, die an einem oder mehreren betroffenen Fahrzeugen als Reaktion auf ein Notfallereignis ausgeführt wird, wobei das Verfahren die folgenden Schritte umfasst: Identifizieren eines oder mehrerer Testfahrzeuge als Reaktion auf eine Notfallereignisanzeige, wobei das eine oder die mehreren Testfahrzeuge auf Basis einer Nähe zwischen einem Notfallereignisort des Notfallereignisses und dem einen oder den mehreren Fahrzeugen oder einer Route des einen oder der mehreren Fahrzeuge ausgewählt werden; Senden einer Datenanfrage an das eine oder die mehreren Testfahrzeuge, wobei die Datenanfrage dem einen oder den mehreren Testfahrzeugen anzeigt, Testdaten an einen entfernten Server zu senden, Empfangen einer Datenantwort von dem einen oder den mehreren Testfahrzeugen am entfernten Server, wobei die Datenantwort die Testdaten enthält und wobei die Testdaten auf Bordsensordaten basieren, die von einem oder mehreren Fahrzeugbordsensoren erhalten werden; und Senden einer Fahrzeugreaktionsaktionsnachricht an jedes des einen oder der mehreren betroffenen Fahrzeuge, wobei die Fahrzeugreaktionsaktionsnachricht eine oder mehrere Fahrzeugreaktionsaktionen spezifiziert, die von dem betroffenen Fahrzeug, an das die Fahrzeugreaktionsaktionsnachricht gesendet wird, ausgeführt werden sollen, wobei mindestens eine der einen oder mehreren Fahrzeugreaktionsaktionen auf Basis der Testdaten bestimmt wird.
  2. Verfahren nach Anspruch 1, ferner umfassend den Schritt des Empfangens der Notfallereignisanzeige, wobei die Notfallereignisanzeige den Notfallereignisort und einen Notfallereignistyp umfasst.
  3. Verfahren nach Anspruch 2, wobei die Datenanfrage auf Basis des Notfallereignistyps erzeugt wird, wobei die Fahrzeugreaktionsaktion auf Basis des Notfallereignistyps und/oder der Testdaten bestimmt wird, und wobei optional die Fahrzeugreaktionsaktion auf Basis einer Information über eine physikalische Eigenschaft des Fahrzeugs bestimmt wird, die in einer Datenbank einer entfernten Einrichtung gespeichert ist.
  4. Verfahren nach Anspruch 1, wobei das eine oder die mehreren betroffenen Fahrzeuge auf Basis einer Nähe zum Notfallereignisort ausgewählt werden, wenn eine geplante Route des Fahrzeugs durch den Notfallereignisort verläuft und/oder wenn das Fahrzeug am, innerhalb oder in der Nähe des Notfallereignisortes steht.
  5. Verfahren nach Anspruch 1, wobei die Datenanfrage einen Testdatentyp, eine Testdatenquelle und/oder einen Testdatenort spezifiziert, und wobei die Testdatenquelle optional einen bestimmten Fahrzeugbordsensor spezifiziert, der zur Erfassung der Testdaten verwendet werden soll.
  6. Verfahren nach Anspruch 1, wobei mindestens eine der Fahrzeugreaktionsaktionen, die in der an ein erstes betroffenes Fahrzeug gesendeten Fahrzeugreaktionsaktionsnachricht spezifiziert ist, auf Basis von Information über die physikalische Fahrzeugeigenschaft bestimmt wird.
  7. Verfahren nach Anspruch 6, wobei die mindestens eine Fahrzeugreaktionsaktionen auf Basis der Testdaten bestimmt wird, die von einem ersten des einen oder der mehreren Testfahrzeuge empfangen werden, wobei die Information über die physikalische Fahrzeugeigenschaft des ersten Testfahrzeugs die gleiche ist wie die Information über die physikalische Fahrzeugeigenschaft des ersten betroffenen Fahrzeugs oder mit dieser korrespondiert.
  8. Verfahren nach Anspruch 1, wobei die Testdaten mindestens einer der Datenantworten von einem ersten Testfahrzeug des einen oder der mehreren Testfahrzeuge Fahrzeug-zu-Fahrzeug (V2V)-Daten enthalten, die von dem ersten Testfahrzeug unter Verwendung einer drahtlosen Kurzstreckenkommunikations (SRWC)-Schaltung erhalten werden.
  9. Verfahren nach Anspruch 1, ferner umfassend das regelmäßige Senden von Aktualisierungen der Notfallereignisdaten an eines oder mehrere der Testfahrzeuge und/oder das/die betroffene(n) Fahrzeug(e) als Reaktion darauf, dass der entfernte Server aktualisierte Notfallereignisdaten empfängt.
  10. Verfahren zum Veranlassen einer Fahrzeugreaktionsaktion, die an einem oder mehreren betroffenen Fahrzeugen als Reaktion auf ein Notfallereignis ausgeführt wird, wobei das Verfahren die folgenden Schritte umfasst: Empfangen einer Datenanfrage von einer Backend-Einrichtung an einem ersten Fahrzeug, wobei die Datenanfrage dem einen oder mehreren Testfahrzeugen anzeigt, Testdaten an die Backend-Einrichtung zu senden, und wobei die Datenanfrage an der Backend-Einrichtung als Reaktion auf eine Notfallereignisanzeige erzeugt wird; Erhalten von Bordsensordaten von einem oder mehreren Fahrzeugbordsensoren des Fahrzeugs; Erzeugen einer Datenantwort am Fahrzeug auf Basis der Bordsensordaten, wobei die Datenantwort die Testdaten enthält und wobei die Testdaten die Bordsensordaten oder Daten auf Basis der Bordsensordaten enthalten; und Senden der Datenantwort an die Backend-Einrichtung, wobei mindestens einige der Testdaten der Datenantwort von der Backend-Einrichtung verwendet werden, um eine oder mehrere Fahrzeugreaktionsaktionsnachrichten zu erzeugen, die jeweils eine oder mehrere Fahrzeugreaktionsaktionen spezifizieren, die von einem oder mehreren betroffenen Fahrzeugen, an die die Fahrzeugreaktionsaktionsnachricht gesendet wird, auszuführen sind.
DE102020104236.1A 2019-03-15 2020-02-18 Fahrzeugbetrieb als Reaktion auf ein Notfallereignis Withdrawn DE102020104236A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/354,877 2019-03-15
US16/354,877 US20200294385A1 (en) 2019-03-15 2019-03-15 Vehicle operation in response to an emergency event

Publications (1)

Publication Number Publication Date
DE102020104236A1 true DE102020104236A1 (de) 2020-09-17

Family

ID=72289552

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020104236.1A Withdrawn DE102020104236A1 (de) 2019-03-15 2020-02-18 Fahrzeugbetrieb als Reaktion auf ein Notfallereignis

Country Status (3)

Country Link
US (1) US20200294385A1 (de)
CN (1) CN111762197A (de)
DE (1) DE102020104236A1 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10553122B1 (en) * 2016-03-22 2020-02-04 Amazon Technologies, Inc. Unmanned aerial vehicle data collection for routing
US11787346B2 (en) * 2018-04-20 2023-10-17 Axon Enterprise, Inc. Systems and methods for a housing equipment for a security vehicle
US11527147B2 (en) * 2019-08-09 2022-12-13 TeamOfDefenders LLC Devices, systems, and methods for monitoring controlled spaces for transitory uses
US11675371B2 (en) * 2020-04-08 2023-06-13 Pony Ai Inc. System and method for fleet management
US11882510B2 (en) * 2020-07-31 2024-01-23 Public Transportation Safety Int'l Corp. Vehicle and system for conflict de-escalation
EP4233029A1 (de) * 2020-10-20 2023-08-30 Polaris Industries Inc. Systeme und verfahren zur erkennung gefährlicher zustände eines fahrzeugs
CN113038426B (zh) * 2021-02-27 2022-07-22 吉林大学 车联网安全检测系统以及方法
MX2022008716A (es) * 2021-07-20 2023-01-23 Polaris Inc Control de vehiculo automatico.
WO2022104295A1 (en) * 2021-12-29 2022-05-19 Innopeak Technology, Inc. Object detection using fusion of vision, location, and/or other signals
US20230410564A1 (en) * 2022-05-27 2023-12-21 Calamp Corp. Technologies for switching between communication modes in a telematics device

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6804602B2 (en) * 2002-04-02 2004-10-12 Lockheed Martin Corporation Incident-aware vehicular sensors for intelligent transportation systems
US9628565B2 (en) * 2014-07-23 2017-04-18 Here Global B.V. Highly assisted driving platform
US9566903B1 (en) * 2015-07-22 2017-02-14 GM Global Technology Operations LLC Multi-vehicle user-assistance systems and methods
US9507346B1 (en) * 2015-11-04 2016-11-29 Zoox, Inc. Teleoperation system and method for trajectory modification of autonomous vehicles
US10048700B1 (en) * 2015-12-01 2018-08-14 Amazon Technologies, Inc. Generating state information for autonomous vehicles
US10043386B2 (en) * 2016-07-19 2018-08-07 Denso International America, Inc. Vehicle communication system
US10901423B2 (en) * 2017-09-01 2021-01-26 International Business Machines Corporation Generating driving behavior models
JP6988387B2 (ja) * 2017-11-09 2022-01-05 トヨタ自動車株式会社 情報提供システム
US11592833B2 (en) * 2018-05-04 2023-02-28 Direct Current Capital LLC Method for updating a localization map for a fleet of autonomous vehicles
US20190378355A1 (en) * 2018-06-12 2019-12-12 GM Global Technology Operations LLC Remote vehicle electronics configuration
US20190051188A1 (en) * 2018-09-27 2019-02-14 Intel Corporation Technologies for on-demand ad hoc cooperation for autonomous vehicles in emergency situations

Also Published As

Publication number Publication date
CN111762197A (zh) 2020-10-13
US20200294385A1 (en) 2020-09-17

Similar Documents

Publication Publication Date Title
DE102020104236A1 (de) Fahrzeugbetrieb als Reaktion auf ein Notfallereignis
DE102019115652B4 (de) Fahrzeugroutensteuerung auf basis von vom benutzer bereitgestellten fahrteinschränkungen
DE102019103819A1 (de) Überwachen der versorgungsqualität am fahrzeug
EP2223504B1 (de) Übertragung von fahrzeuginformationen
DE102019107797B4 (de) FAHRZEUGPROGNOSEN UND ABHILFEMAßNAHMEN
DE102016124107A1 (de) Systeme und verfahren zum freigeben oder sperren von autonomem fahren
DE102019105307A1 (de) Dynamische merkmalsverfügbarkeitsabbildung für ein fahrzeug
DE102017130936A1 (de) Expertenmodus für Fahrzeuge
EP3830522B1 (de) Verfahren zur schätzung der lokalisierungsgüte bei der eigenlokalisierung eines fahrzeuges, vorrichtung für die durchführung des verfahrens, fahrzeug sowie computerprogramm
DE102017123687A1 (de) Dynamisches aktualisieren der routenauswahl für halb-autonomes fahren
DE102014204694A1 (de) Verfahren, systeme und eine vorrichtung zur gemeinsamen nutzung von information innerhalb einer gruppe von fahrzeugen
DE112020000110T5 (de) Nutzung von in fahrzeugen erfassten fahrgastaufmerksamkeitsdaten fürlokalisierungs- und standortbezogene dienste
DE102019113707A1 (de) Fernkonfiguration einer fahrzeugelektronik
DE102019120461A1 (de) Verfahren und system zur bewertung einer fehlerhaften bedrohungserfassung
DE102019112407A1 (de) Spurwechselzeitsteuerungsindikator
DE102014114825A1 (de) Verfahren, Systeme und Vorrichtung zum Bestimmen, ob eines der in Benachrichtigungspräferenzen spezifizierten Fahrzeugereignisse aufgetreten ist
DE102019115897A1 (de) Fahrerüberwachungssystem und verfahren zum betreiben desselben
DE102020101140A1 (de) Verfahren und system zum bestimmen einer aktion eines autonomen fahrzeugs (av) basierend auf fahrzeug- und edge-sensordaten
DE112012004771T5 (de) Verfahren und System zur Fahrzeugdatensammlung hinsichtlich Verkehr
WO2008061890A1 (de) Verfahren zur drahtlosen kommunikation zwischen fahrzeugen
DE102019105306A1 (de) Gnss-höhenkorrektur
DE102019115033A1 (de) Benutzerdefinierte kraftfahrzeugbenachrichtigung
DE102020103033A1 (de) Konfiguration von fahrzeug-entertainment basierend auf der fahreraufmerksamkeit
DE102018121593A1 (de) Türschliesssystem
DE102018128286A1 (de) Fahrzeugführung basierend auf dem räumlichen modell des standorts

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee