DE102018117708A1

DE102018117708A1 - Implementierungsentscheidung zum bereitstellen einer adas-funktionsaktualisierung für ein fahrzeug

Info

Publication number: DE102018117708A1
Application number: DE102018117708.9A
Authority: DE
Inventors: Chung-Wei Lin; Shinichi Shiraishi
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2017-07-25
Filing date: 2018-07-23
Publication date: 2019-01-31
Also published as: US20190034197A1; JP6677276B2; US10248410B2; JP2019026250A

Abstract

Die Offenbarung umfasst Ausführungsbeispiele zum Implementieren einer Funktionsaktualisierung für ein fortgeschrittenes Fahrerassistenzsystem („ein ADAS-System“) eines Fahrzeugs. In manchen Ausführungsbeispielen umfasst das Verfahren, dass das Fahrzeug eine dedizierte Nahbereichskommunikationsmitteilung („eine DSRC-Mitteilung“) auf einem 5,9 Gigahertzband empfängt. Die DSRC-Mitteilung umfasst digitale Daten, die eine Fahrsituation von einem oder mehreren anderen Fahrzeugen in Relation zu dem Fahrzeug beschreiben. Das Verfahren umfasst ein Bestimmen, basierend auf der Fahrsituation, die durch die digitalen Daten beschrieben wird, die Funktionsaktualisierung für das ADAS-System durch Rekonfigurieren eines feldprogrammierbaren Gate-Arrays („ein FPGA“) des Fahrzeugs, das betriebsfähig ist, um eine Operation des ADAS-Systems zu steuern, zu implementieren. Das Verfahren umfasst ein Rekonfigurieren des FPGAs des Fahrzeugs, um die Funktionsaktualisierung zu implementieren, sodass das FPGA die Operation des ADAS-Systems auf solch eine Weise steuert, die der Funktionsaktualisierung entspricht.

Description

HINTERGRUND
Die Spezifikation betrifft ein Bereitstellen einer Implementierungsentscheidung, wie eine Aktualisierung für ein fortgeschrittenes Fahrerassistenzsystem eines Fahrzeugs zu implementieren ist.
Fahrzeugsteuerungssysteme werden zunehmend populär. Ein Beispiel eines Fahrzeugsteuerungssystems ist ein fortgeschrittenes Fahrerassistenzsystem („Advanced Driver Assistance System“) („ADAS-System“ bei Einzahl, „ADAS-Systeme“ bei Mehrzahl).
Ein ordnungsgemäßes Funktionieren von ADAS-Systemen hängt von der Verfügbarkeit von Funktionsaktualisierungen ab, die die Funktionalität, die durch die ADAS-Systeme bereitgestellt wird, modifizieren.
KURZFASSUNG
Moderne Fahrzeuge sind mit einem Satz von ADAS-Systemen ausgestattet. Der Satz von ADAS-Systemen umfasst eines oder mehrere ADAS-Systeme. Das eine oder die mehreren ADAS-Systeme erfordern eine periodische Aktualisierung, um die Funktionalität, die diese bereitstellen, zu modifizieren oder zu verbessern.
Aktualisierungen, die die Funktionalität eines ADAS-Systems modifizieren oder verbessern, werden als eine „Funktionsaktualisierung“ bezeichnet. Es gibt zwei mögliche Optionen zum Implementieren einer Funktionsaktualisierung: (1) eine Verwendung von Software zum Implementieren der Funktionsaktualisierung; und (2) eine Verwendung von einem oder mehreren feldprogrammierbaren Gate-Arrays („field-programmable gate arrays“) („FPGA“ bei Einzahl, „FPGAs“ bei Mehrzahl), um die Funktionsaktualisierung zu implementieren.
In den meisten Fällen ist eine Implementierung von Funktionsaktualisierungen unter Verwendung von FPGAs schneller als eine Implementierung von solchen Aktualisierungen nur via Software. Jedoch ist eine Implementierung von solchen Aktualisierungen über FPGA allgemein auch teurer und nimmt eine längere Zeit in Anspruch. Momentan gibt es keine Lösung, die einem Fahrzeug bei der Bestimmung hilft, ob Funktionsaktualisierungen für ein ADAS-System eines Fahrzeugs über Softwareaktualisierungen oder über FPGA zu implementieren sind. Das hierin beschriebene Aktualisierungssystem löst dieses Problem. Auf diese Weise verbessert das Aktualisierungssystem das Leistungsverhalten eines Fahrzeugs durch Bestimmen, ob ADAS-Funktionsaktualisierungen für das Fahrzeug durch eines oder mehrere der folgenden Verfahren implementiert werden: (1) Implementieren von Softwareaktualisierungen für eines oder mehrere ADAS-Systeme des Fahrzeugs, auf solch eine Weise, dass die durch das eine oder die mehreren ADAS-Systeme bereitgestellte Funktionalität gemäß der Funktionsaktualisierung modifiziert wird [nachstehend als „Implementieren der Funktionsaktualisierung über Software“ oder „Implementierung der Funktionsaktualisierung über Software“ bezeichnet]; oder (2) Modifizieren von einem oder mehreren FPGAs des Fahrzeugs, auf solch eine Weise, dass die durch das eine oder die mehreren ADAS-Systeme bereitgestellte Funktionalität gemäß der Funktionsaktualisierung modifiziert wird [nachstehend als „Implementieren der Funktionsaktualisierung über FPGA“ oder „Implementierung der Funktionsaktualisierung über FPGA“ bezeichnet].
Wie hierin verwendet, ist eine „Implementierungsentscheidung“ eine Entscheidung darüber, ob eine Funktionsaktualisierung für ein ADAS-System eines Fahrzeugs über Software oder über FPGA implementiert wird.
Das hierin beschriebene Aktualisierungssystem stellt zahlreiche Vorteile bereit. Zum Beispiel bestimmt das Aktualisierungssystem basierend auf Echtzeitdaten, die die momentane Situation des Fahrzeugs beschreiben, ob es besser ist, die Funktionsaktualisierung über Software oder FPGA zu implementieren. Keine andere Technologie stellt diese Funktionalität bereit. Unsere Nachforschung gibt an, dass das Aktualisierungssystem Kosten reduzieren und eine Fahrzeugsicherheit erhöhen wird, durch Implementieren der Funktionsaktualisierung der ADAS-Systeme auf die am schnellsten und günstigste mögliche Weise, während ebenso sowohl Systembeschränkungen als auch Beschränkungen der realen Welt, die momentan durch das Fahrzeug zu der Zeit, wenn die Implementierungsentscheidung durch das Aktualisierungssystem vorgenommen wird, erfahren werden, erfüllt werden.
In manchen Ausführungsbeispielen ist das Aktualisierungssystem ein Element eines Fahrzeugs. In manchen Ausführungsbeispielen ist das Aktualisierungssystem ein Element eines Servers. In manchen Ausführungsbeispielen umfassen das Fahrzeug und der Server jeweils deren eigene Instanz des Aktualisierungssystems und die Funktionalität des Aktualisierungssystems ist zwischen dem Fahrzeug und dem Server verteilt. In 1A zum Beispiel ist das Aktualisierungssystem als ein Element des Fahrzeugs und des Servers dargestellt, und ist das Aktualisierungssystem selbst mit einer gestrichelten Linie dargestellt, um anzugeben, dass das Aktualisierungssystem ein Element des Fahrzeugs, des Servers, oder sowohl des Fahrzeugs und des Servers sein kann.
In manchen Ausführungsbeispielen ist das Fahrzeug, das das Aktualisierungssystem umfasst, ein mit DSRC ausgestattetes Fahrzeug. Ein mit DSRC ausgestattetes Fahrzeug kann ein Fahrzeug umfassen, das eines oder mehrere der folgenden Elemente umfasst: einen DSRD-Senderempfänger und irgendeine Software oder Hardware, die notwendig ist, um eine DSRC-Mitteilung zu kodieren und zu übertragen; einen DSRC-Empfänger und irgendeine Software oder Hardware, die notwendig ist, um eine DSRC-Mitteilung zu empfangen und zu dekodieren; und ein DSRC-konformes globales Positionierungssystem (eine „DSRC-konforme GPS-Einheit“).
Eine DSRC-Mitteilung ist eine drahtlose Mitteilung, die speziell dazu konfiguriert ist, durch sehr mobile Einrichtungen, wie etwa Fahrzeuge, gesendet und empfangen zu werden, und ist mit einem oder mehreren der folgenden DSRC-Standards inklusive irgendwelchen Ableitungen oder Gabelungen von diesen konform: EN 12253:2004 dedizierte Nahbereichskommunikationphysikalische Schicht unter Verwendung von Mikrowellen bei 5,8 GHz (Review); EN 12795:2002 Dedizierte Nahbereichskommunikation (DSRC)-DSRC-Datenverbindungsschicht: Medienzugriffs- und Logikverbindungssteuerung (Review); EN 12834:2002 Dedizierte Nahbereichskommunikation - Anwendungsschicht (Review); und EN 13372:2004 Dedizierte Nahbereichskommunikation (DSRC) - DSRC-Profile für RTTT-Anwendungen (Review); EN ISO 14906:2004 Elektronische Gebührensammlung - Anwendungsschnittstelle.
In den Vereinigten Staaten, Europa und Asien werden DSRC-Mitteilungen bei 5,9 Gigahertz („GHz“) übertragen. In den Vereinigten Staaten werden DSRC-Mitteilungen 75 MHz eines Spektrums in dem 5,9 GHz Band zugewiesen. In Europa und Asien werden DSRC-Mitteilungen 30 MHz eines Spektrums in dem 5,9 GHz Band zugewiesen. Eine drahtlose Mitteilung ist deshalb keine DSRC-Mitteilung, solange diese nicht in dem 5,9 GHz Band arbeitet. Eine drahtlose Mitteilung ist ebenso keine DSRC-Mitteilung, solange diese nicht durch einen DSRC-Sender eines DSRC-Funks übertragen wird.
Dementsprechend ist eine DSRC-Mitteilung keine der Folgenden: eine WiFi-Mitteilung; eine 3G-Mitteilung; eine 4G-Mitteilung; eine LTE-Mitteilung; eine Millimeterwellenkommunikationsmitteilung; eine Bluetooth-Mitteilung; eine Satellitenkommunikation; und eine Nahbereichsfunkmitteilung, die von einem Schlüsselanhänger bei 315 Megahertz (MHz) oder 433.92 MHz übertragen oder rundgesendet wird. Zum Beispiel in den Vereinigten Staaten umfassen Schlüsselanhänger für ferngesteuerte schlüssellose Systeme einen Nahbereichsfunksender, der bei 315 MHz arbeitet, und Übertragungen oder Rundsendungen von diesem Nahbereichsfunksender sind keine DSRC-Mitteilungen, da zum Beispiel solche Übertragungen oder Rundsendungen nicht mit irgendeinem DSRC-Standard konform sind, nicht durch einen DSRC-Sender eines DSRC-Funks übertragen werden, und nicht bei 5,9 GHz übertragen werden. In einem anderen Beispiel umfassen in Europa und Asien Schlüsselanhänger für ferngesteuerte schlüssellose Systeme einen Nahbereichsfunksender, der bei 433.92 MHz arbeitet, und Übertragungen oder Rundsendungen von diesem Nahbereichsfunksender sind keine DSRC-Mitteilungen aus den gleichen Gründen wie denen, die vorstehend für die ferngesteuerten schlüssellosen Systemen in den Vereinigten Staaten beschrieben wurden.
In manchen Ausführungsbeispielen umfasst das mit DSRC ausgestattete Fahrzeug keine herkömmliche globale Positionierungssystemeinheit („GPS-Einheit“), und umfasst stattdessen eine DSRC-konforme GPS-Einheit. Eine herkömmliche GPS-Einheit stellt Positionsinformationen bereit, die eine Position der herkömmlichen GPS-Einheit mit einer Genauigkeit von plus oder minus 10 Metern der aktuellen Position der herkömmlichen GPS-Einheit beschreiben. Zum Vergleich stellt eine DSRC-konforme GPS-Einheit GPS-Daten bereit, die eine Position der DSRC-konformen GPS-Einheit mit einer Genauigkeit von plus oder minus 1,5 Metern der aktuellen Position der DSRC-konformen GPS-Einheit beschreiben. Dieser Grad einer Genauigkeit wird als „Spurlevelgenauigkeit“ bezeichnet, da eine Spur einer Straße allgemein etwa 3 Meter breit ist, und eine Genauigkeit von plus oder minus 1,5 Metern ausreichend ist, um zu identifizieren, auf welcher Spur das Fahrzeug fährt, auch wenn das Fahrzeug auf einer Straße mit einer Vielzahl von Spuren, in denen Verkehr in die gleiche Richtung fließt, fährt.
In manchen Ausführungsbeispielen kommuniziert das Fahrzeug, das das Aktualisierungssystem umfasst, drahtlos mit anderen mit DSRC ausgestatteten Einrichtungen über DSRC. Diese anderen mit DSRC ausgestatteten Einrichtungen können zum Beispiel ein unterschiedliches mit DSRCausgestattetes Fahrzeug, eine straßenseitige Einheit („RSU“ bei Einzahl, „RSUs“ bei Mehrzahl) oder manch andere Kommunikationseinrichtungen, die mit DSRC ausgestattet sind, sein. Zum Beispiel kann eine straßenseitige Einheit („RSU“) oder irgendeine andere Kommunikationseinrichtung mit DSRC ausgestattet sein, wenn diese eines oder mehrere der folgenden Elemente umfasst: einen DSRC-Senderempfänger und irgendeine Software oder Hardware, die notwendig ist, um eine DSRC-Mitteilung zu kodieren und zu übertragen; und einen DSRC-Empfänger und irgendeine Software oder Hardware, die notwendig ist, um eine DSRC-Mitteilung zu empfangen und zu dekodieren.
Die hierin beschriebenen Ausführungsbeispiele können digitale Daten drahtlos an das Fahrzeug, das das Aktualisierungssystem umfasst, über eine drahtlose Mitteilung, wie etwa eine DSRC-Mitteilung, oder eine Basissicherheitsmitteilung („BSM-Mitteilung“, BSM: „basic safety massage“) drahtlos übertragen. Diese drahtlosen Mitteilungen umfassen BSM-Daten, wie etwa die, die in 4A und 4B dargestellt sind, oder manch andere digitale Daten, die Informationen beschreiben, die ähnlich zu Informationen sind, die durch die BSM-Daten beschrieben werden. Das hierin beschriebene Aktualisierungssystem verwendet diese BSM-Daten (oder manche anderen ähnlichen Daten, die über DSRC übertragen werden), um zu bestimmen, ob die Funktionsaktualisierung über Software oder FPGA zu implementieren ist. Diese BSM-Daten stellen Echtzeitdaten, die die momentane Fahrsituation beschreiben oder einen Kontext, in dem die Funktionsaktualisierung implementiert werden wird, bereit, was zum Beispiel vorteilhaft ist, um sicherzustellen, dass die Funktionsaktualisierung auf eine sichere und effiziente Weise implementiert wird.
Ein System von einem oder mehreren Computern kann konfiguriert sein, um bestimmte Operationen oder Aktionen durchzuführen, dadurch, dass Software, Firmware, Hardware oder eine Kombination von diesen auf dem System installiert ist, die im Betrieb das System veranlassen, die Aktionen durchzuführen. Eines oder mehrere Computerprogramme können konfiguriert sein, um bestimmte Operationen oder Aktionen durchzuführen, dadurch, dass diese Anweisungen umfassen, die, wenn diese durch eine Datenverarbeitungsvorrichtung ausgeführt werden, die Vorrichtung veranlassen, die Aktionen durchzuführen. Ein allgemeiner Aspekt umfasst ein Verfahren, das eine Funktionsaktualisierung für ein ADAS-System eines Fahrzeugs implementiert, wobei das Verfahren umfasst: Empfangen einer DSRC-Mitteilung auf einem 5,9 GHz Band, wobei die DSRC-Mitteilung digitale Daten umfasst, die eine Fahrsituation von einem oder mehreren anderen Fahrzeugen in Relation zu dem Fahrzeug beschreiben; Bestimmen, basierend auf der Fahrsituation, die durch die digitalen Daten beschrieben ist, die Funktionsaktualisierung für das ADAS-System durch Rekonfigurieren eines FPGA des Fahrzeugs zu implementieren, das betriebsfähig ist, um eine Operation des ADAS-Systems zu steuern; und Rekonfigurieren des FPGA des Fahrzeugs, um die Funktionsaktualisierung zu implementieren, sodass das FPGA die Operation des ADAS-Systems steuert, auf eine Weise, die der Funktionsaktualisierung entspricht. Andere Ausführungsbeispiele dieses Aspekts umfassen entsprechende Computersysteme, eine Vorrichtung, und Computerprogramme, die auf einem oder mehreren Computerspeichereinrichtungen aufgezeichnet sind, die jeweils dazu konfiguriert sind, die Aktionen der Verfahren durchzuführen.
Implementierungen können eines oder mehrere der folgenden Merkmale umfassen. Das Verfahren, bei dem die DSRC-Mitteilung eine BSM-Mitteilung ist und die digitalen Daten BSM-Daten sind. Das Verfahren, bei dem die DSRC-Mitteilung an das Fahrzeug durch eine straßenseitige bzw. fahrbahnseitige Einheit („RSU“, roadside unit) übertragen wird. Das Verfahren, bei dem die digitalen Daten einen geographischen Ort von einem oder mehreren anderen Fahrzeugen mit einer Genauigkeit von plus oder minus 1,5 Metern relativ zu einem tatsächlichen geographischen Ort des einen oder der mehreren anderen Fahrzeuge beschreiben. Das Verfahren, bei dem das FPGA ein Element einer elektronischen Steuerungseinheit des Fahrzeugs ist. Das Verfahren, bei dem das FPGA basierend auf Aktualisierungsdaten, die beschreiben, wie das FPGA zu rekonfigurieren ist, um die Funktionsaktualisierung zu implementieren, rekonfiguriert wird. Das Verfahren, bei dem die Funktionsaktualisierung eine durch das ADAS-System bereitgestellte Funktionalität modifiziert. Implementierungen der beschriebenen Techniken können Hardware, ein Verfahren oder einen Prozess, Computersoftware auf einem computerzugreifbaren Medium umfassen.
Ein allgemeiner Aspekt umfasst ein System mit einem Fahrzeug, wobei das Fahrzeug aufweist: ein ADAS-System; einen DSRC-Empfänger; ein FPGA; und ein fahrzeugseitiges Fahrzeugcomputersystem, das mit dem ADAS-System, dem DSRC-Empfänger und dem FPGA kommunikativ gekoppelt ist, wobei das fahrzeugseitige Fahrzeugcomputersystem einen nichtflüchtigen Speicher umfasst, der Computercodes speichert, der, wenn dieser durch das fahrzeugseitige Fahrzeugcomputersystem ausgeführt wird, das fahrzeugseitige Fahrzeugcomputersystem veranlasst: durch den DSRC-Empfänger eine DSRC-Mitteilung auf einem 5,9 GHz Band zu empfangen, wobei die DSRC-Mitteilung digitale Daten umfasst, die eine Fahrsituation von einem oder mehreren Fahrzeugen in Relation zu dem Fahrzeug beschreibt; basierend auf der Fahrsituation, die durch die digitalen Daten beschrieben ist, zu bestimmen, eine Funktionsaktualisierung für das ADAS-System durch Rekonfigurieren des FPGA zu implementieren, das betriebsfähig ist, um eine Operation des ADAS-Systems zu steuern; und das FPGA zu rekonfigurieren, um die Funktionsaktualisierung zu implementieren, sodass das FPGA die Operation des ADAS-Systems auf eine Weise, die der Funktionsaktualisierung entspricht, steuert. Weitere Ausführungsbeispiele dieses Aspektes umfassen entsprechende Computersysteme, eine Vorrichtung und Computerprogramme, die auf einem oder mehreren Computerspeichereinrichtungen aufgezeichnet sind, die jeweils dazu konfiguriert sind, die Aktionen der Verfahren durchzuführen.
Implementierungen können eines oder mehrere der folgenden Merkmale umfassen. Das System, bei dem die DSRC-Mitteilung eine BSM-Mitteilung ist, und die digitalen Daten BSM-Daten sind. Das System, bei dem die DSRC-Mitteilung an das Fahrzeug durch eine RSU übertragen wird. Das System, bei dem die digitalen Daten einen geographischen Ort von einem oder mehreren anderen Fahrzeugen mit einer Genauigkeit von plus oder minus 1,5 Metern relativ zu einem tatsächlichen graphischen Ort des einen oder der mehreren anderen Fahrzeuge beschreiben. Das System, bei dem das FPGA ein Element einer elektronischen Steuerungseinheit des Fahrzeugs ist. Das System, bei dem das FPGA basierend auf Aktualisierungsdaten rekonfiguriert wird, die beschreiben, wie das FPGA zu rekonfigurieren ist, um die Funktionsaktualisierung zu implementieren. Das System, bei dem die Funktionsaktualisierung eine durch das ADAS-System bereitgestellte Funktionalität modifiziert. Implementierungen der verschiedenen Techniken können Hardware, ein Verfahren oder ein Prozess, oder Computersoftware auf einem computerzugreifbaren Medium umfassen.
Ein allgemeiner Aspekt umfasst ein Computerprogrammprodukt mit einem nichtflüchtigen Speicher eines fahrzeugseitigen Fahrzeugcomputersystems eines Fahrzeugs, der computerausführbaren Code speichert, der, wenn dieser durch einen Prozessor ausgeführt wird, den Prozessor veranlasst: eine DSRC-Mitteilung auf einem 5,9 GHz Band zu empfangen, wobei die DSRC-Mitteilung digitale Daten umfasst, die eine Fahrsituation von einem oder mehreren anderen Fahrzeugen in Relation zu dem Fahrzeug beschreiben; basierend auf der Fahrsituation, die durch die digitalen Daten beschrieben ist, zu bestimmen, eine Funktionsaktualisierung für ein ADAS-System des Fahrzeugs durch Rekonfigurieren eines FPGA des Fahrzeugs zu implementieren, das betriebsfähig ist, um eine Operation des ADAS-Systems zu steuern; und das FPGA des Fahrzeugs zu rekonfigurieren, um die Funktionsaktualisierung zu implementieren, sodass das FPGA die Operation des ADAS-Systems auf eine Weise, die der Funktionsaktualisierung entspricht, steuert. Andere Ausführungsbeispiele dieses Aspekts umfassen entsprechende Computersysteme, eine Vorrichtung und Computerprogramme, die auf einem oder mehreren Computerspeichereinrichtungen aufgezeichnet sind, die jeweils dazu konfiguriert sind, die Aktionen der Verfahren durchzuführen.
Implementierungen können eines oder mehrere der folgenden Merkmale umfassen. Das Computerprogrammprodukt, bei dem die DSRC-Mitteilung eine BSM-Mitteilung ist, und die digitalen Daten BSM-Daten sind. Das Computerprogrammprodukt, bei dem die DSRC-Mitteilung an das Fahrzeug durch eine RSU übertragen wird. Das Computerprogrammprodukt, bei dem die digitalen Daten einen geographischen Ort des einen oder der mehreren anderen Fahrzeuge mit einer Genauigkeit von plus oder minus 1,5 Metern relativ zu einem tatsächlichen geographischen Ort des einen oder der mehreren anderen Fahrzeuge beschreiben. Das Computerprogrammprodukt, bei dem das FPGA ein Element einer elektronischen Steuerungseinheit des Fahrzeugs ist. Das Computerprogrammprodukt, bei dem das FPGA basierend auf Aktualisierungsdaten rekonfiguriert wird, die beschreiben, wie das FPGA zu rekonfigurieren ist, um die Funktionsaktualisierung zu implementieren. Implementierungen der beschriebenen Techniken können Hardware, ein Verfahren oder einen Prozess, oder Computersoftware auf einem computerzugreifbaren Medium umfassen.
Figurenliste
Diese Offenbarung ist als Beispiel und nicht als Beschränkung in den Figuren der anhängigen Zeichnungen dargestellt, in denen gleiche Bezugszeichen verwendet werden, um ähnliche Elemente zu bezeichnen.

1A ist ein Blockdiagramm, das eine Operationsumgebung für ein Aktualisierungssystem gemäß manchen Ausführungsbeispielen darstellt.
1B ist ein Blockdiagramm, das Systemdaten gemäß manchen Ausführungsbeispielen darstellt.
1C ist ein Blockdiagramm, das Funktionsbeschränkungsdaten bzw. funktionale Beschränkungsdaten gemäß manchen Ausführungsbeispielen darstellt.
1D ist ein Blockdiagramm, das Ressourcenbeschränkungsdaten gemäß manchen Ausführungsbeispielen darstellt.
1E ist ein Blockdiagramm, das Schätzzeitdaten gemäß manchen Ausführungsbeispielen darstellt.
1F ist ein Blockdiagramm, das Schätzverbrauchsdaten gemäß manchen Ausführungsbeispielen darstellt.
1G ist ein Blockdiagramm, das Entscheidungsdaten gemäß manchen Ausführungsbeispielen darstellt.
1H ist ein Blockdiagramm, das Analysedaten gemäß manchen Ausführungsbeispielen darstellt.
1I ist ein Blockdiagramm, das eine Fahrbahnumgebung gemäß manchen Ausführungsbeispielen darstellt.
2 ist ein Blockdiagramm, das ein Beispiel eines Computersystems mit einem Aktualisierungssystem gemäß manchen Ausführungsbeispielen darstellt.
3A bis 3C sind Ablaufdiagramme eines Beispiels eines Verfahrens zum Vornehmen einer Implementierungsentscheidung gemäß manchen Ausführungsbeispielen.
4A ist ein Blockdiagramm, das ein Beispiel von BSM-Daten gemäß manchen Ausführungsbeispielen darstellt.
4B ist ein Blockdiagramm, das ein Beispiel von BSM-Daten gemäß manchen Ausführungsbeispielen darstellt.

DETAILLIERTE BESCHREIBUNG
Ein Fahrzeug umfasst ein ADAS-System und ein Aktualisierungssystem. Funktionsaktualisierungen werden für das ADAS-System periodisch implementiert, um die durch das ADAS-System bereitgestellte Funktionalität zu modifizieren. Hierin sind Ausführungsbeispiele eines Aktualisierungssystems beschrieben, das bestimmt, ob die Funktionsaktualisierung unter Verwendung von entweder einer Softwareaktualisierung für das ADAS-System oder durch Rekonfigurieren eines FPGA des Fahrzeugs, das die Operation des ADAS-Systems steuert, zu implementieren ist.
Beispiele von drahtlosen Mitteilungen
Fahrzeuge sind zunehmend mit DSRC ausgestattet. Ein Fahrzeug, das mit DSRC ausgestattet ist, kann als „mit DSRC ausgestattet“ bezeichnet werden. Ein mit DSRC ausgestattetes Fahrzeug kann eine DSRC-Antenne und irgendeine Hardware oder Software umfassen, die notwendig ist, um DSRC-Mitteilungen zu senden und zu empfangen, DSRC-Mitteilungen zu erzeugen und DSRC-Mitteilungen zu lesen. Ein mit DSRC ausgestattetes Fahrzeug kann zum Beispiel irgendeine Hardware oder Software umfassen, die notwendig ist, um eine DSRC-Mitteilung zu empfangen, Daten, die in der DSRC-Mitteilung enthalten sind, abzurufen, und die Daten, die in der DSRC-Mitteilung enthalten sind, zu lesen.
Die eine oder mehreren drahtlosen Mitteilungen können eine DSRC-Mitteilung umfassen. Es gibt viele Arten von DSRC-Mitteilungen. Eine Art einer DSRC-Mitteilung ist als BSM bekannt. Ein mit DSRC ausgestattetes Fahrzeug führt eine Rundsendung eines BSM in einem regelmäßigen Intervall durch. Das Intervall kann durch den Benutzer einstellbar sein.
Eine BSM umfasst BSM-Daten. Die BSM-Daten beschreiben Merkmale des Fahrzeugs, das ursprünglich die BSM übertragen hat. Fahrzeuge, die mit DSRC ausgestattet sind, können BSMs mit einer einstellbaren Rate bzw. Häufigkeit rundsenden. In manchen Ausführungsbeispielen kann die Rate bzw. Häufigkeit einmal alle 0,1 Sekunden sein. Die BSM umfasst BSM-Daten, die unter anderem eines oder mehrere der Folgenden beschreiben: (1) den Pfadverlauf des Fahrzeugs, das die BSM überträgt; (2) die Geschwindigkeit des Fahrzeugs, das die BSM überträgt; und (3) die GPS-Daten (manchmal als „globale Positionierungssystemdaten“ oder „GPS-Daten“ beschrieben), die einen Ort des Fahrzeugs, das die BSM überträgt, beschreiben. 4A und 4B, die nachstehend beschrieben sind, stellen Beispiele von BSM-Daten gemäß manchen Ausführungsbeispielen dar.
In manchen Ausführungsbeispielen können mit DSRC ausgestattete Fahrzeuge andere mit DSRC ausgestattete Fahrzeuge/Einrichtungen entlang der Straße bezüglich Informationen, die deren momentanen und zukünftigen Bedingungen beschreiben, inklusive deren Pfadverlauf, zukünftigen Pfad und Fernsensordaten, die diese empfangen oder erzeugt haben könnten, sondieren. Diese Informationen werden als „DSRC-Sondierungsdaten“ bzw. „DSRC probe data“ beschrieben. Die DSRC-Sondierungsdaten können irgendwelche Daten umfassen, die über eine DSRC-Sondierung oder als Antwort auf eine DSRC-Sondierung empfangen werden.
Eine DSRC-Mitteilung kann DSRC-basierte Daten umfassen. Die DSRC-basierten Daten können BSM-Daten oder DSRC-Sondierungsdaten umfassen. In manchen Ausführungsbeispielen können die DSRC-basierten Daten, die in einer DSRC-Mitteilung enthalten sind, BSM-Daten oder DSRC-Sondierungsdaten umfassen, die von einer Vielzahl von mit DSRCausgestatteten Fahrzeugen (oder anderen mit DSRC ausgestatteten Einrichtungen) empfangen werden. Diese BSM-Daten oder DSRC-Sondierungsdaten können eine Kennung von deren Quelle und den Ort der Quelle oder irgendwelche Verkehrsereignisse, die durch die BSM-Daten oder die DSRC-Sondierungsdaten beschrieben sind, umfassen.
In manchen Ausführungsbeispielen werden die DSRC-fähigen Fahrzeuge eine DSRC-konforme GPS-Einheit umfassen. Die BSM-Daten oder DSRC-Sondierungsdaten können spezifizieren, auf welcher Spur ein Fahrzeug fährt, sowie dessen Fahrtgeschwindigkeit und Pfadverlauf. Die BSM-Daten oder DSRC-Sondierungsdaten können weiterhin eines oder mehrere der Folgenden spezifizieren: eine Geschwindigkeit des Fahrzeugs zu einer oder mehreren unterschiedlichen Zeiten oder an einem oder mehreren unterschiedlichen Orten; eine Richtung des Fahrzeugs zu einer oder mehreren unterschiedlichen Zeiten oder an einem oder mehreren unterschiedlichen Orten; und eine Beschleunigung des Fahrzeugs zu einer oder mehreren unterschiedlichen Zeiten oder an einem oder mehreren unterschiedlichen Orten.
Eine andere Art einer drahtlosen Mitteilung ist eine Full-Duplex-Drahtlosmitteilung, die in der US-Patentanmeldung 14/471,387 , eingereicht am 28. August 2014 mit dem Titel „Full-Duplex Coordination System“ beschrieben ist, deren Gesamtheit hierin durch Bezugnahme miteingeschlossen ist.
Beispiele einer Spurlevelgenauigkeit
Fahrzeuge werden zunehmend derart hergestellt, dass sie ein GPS-basiertes Navigationssystem umfassen. Ein GPS-basiertes Navigationssystem kann Navigationsrouten an einen Fahrer bereitstellen, die auf GPS-Daten und einem Wissen über Warteschlangenlängen entlang Fahrbahnen basieren.
Eine Spurlevelgenauigkeit kann bedeuten, dass der Ort eines Fahrzeugs so genau beschrieben ist, dass die Fahrspur des Fahrzeugs genau bestimmt werden kann. Ein herkömmliches GPS-System ist nicht dazu in der Lage, den Ort eines Fahrzeugs mit einer Spurlevelgenauigkeit zu bestimmen. Eine typische Spur einer Straße ist ungefähr 3 Meter breit. Jedoch könnte ein herkömmliches GPS-System nur eine Genauigkeit von plus oder minus 10 Metern relativ zu dem tatsächlichen Ort des Fahrzeugs aufweisen.
Eine DSRC-konforme GPS-Einheit stellt GPS-Daten bereit, die den Ort eines Fahrzeugs mit einer Spurlevelgenauigkeit beschreiben. Eine DSRC-konforme GPS-Einheit kann Hardware umfassen, die drahtlos mit einem GPS-Satelliten kommuniziert, um GPS-Daten, die einen Ort eines Fahrzeugs mit einer Genauigkeit, die mit dem DSRC-Standard konform ist, beschreiben, abzurufen. Der DSRC-Standard erfordert, dass die GPS-Daten präzise genug sind, um abzuleiten, ob zwei Fahrzeuge auf der gleichen Spur sind. Die Spur kann eine Spur einer Straße bzw. Fahrbahn sein. Die DSRC-konforme GPS-Einheit kann betriebsfähig sein, um ihre zweidimensionale Position innerhalb von 1,5 Metern von ihrer tatsächlichen Position zu 68 % der Zeit unter einem freien Himmel zu identifizieren, zu überwachen und zu verfolgen. Da Spuren einer Straße typischerweise nicht weniger als 3 Meter breit sind, kann das Aktualisierungssystem, das hierin beschrieben ist, wann immer der zweidimensionale Fehler der GPS-Daten weniger als 1,5 Meter ist, die GPS-Daten, die durch die DSRC-konforme GPS-Einheit bereitgestellt sind, analysieren und bestimmen, auf welcher Spur der Straße das Fahrzeug fährt, basierend auf den relativen Positionen der Fahrzeuge auf der Straße.
ADAS-System
Beispiele eines ADAS-Systems umfassen eines oder mehrere der folgenden Elemente eines Fahrzeugs: ein System einer adaptiven Geschwindigkeitsregelung (ACC-System, ACC: „adaptive cruise control“); ein adaptives Fernlichtsystem; ein adaptives Lichtsteuerungssystem; ein automatisches Parksystem; ein automotives Nachtsichtsystem; einen Totwinkelmonitor; ein Kollisionsvermeidungssystem; ein Querwindstabilisationssystem; ein Fahrermüdigkeitserfassungssystem; ein Fahrerüberwachungssystem; ein Notfallfahrerassistenzsystem; ein Vorwärtskollisionswarnsystem; ein Kreuzungsassistenzsystem; ein intelligentes Geschwindigkeitsanpassungssystem; ein Spurabweichungswarnsystem; ein Fußgängerschutzsystem; ein Verkehrszeichenerkennungssystem; einen Abbiegeassistenten; und ein Falschfahrwarnsystem.
Das ADAS-System kann ebenso Software oder Hardware umfassen, die in dem Fahrzeug enthalten ist, die das Fahrzeug zu einen autonomen Fahrzeug oder zu einem semiautonomen Fahrzeug macht.
In manchen Ausführungsbeispielen wird eine Funktionsaktualisierung für eines oder mehrere ADAS-Systeme des Fahrzeugs über eine Softwareaktualisierung implementiert. In anderen Ausführungsbeispielen umfasst das eine oder die mehreren ADAS-Systeme eine oder mehrere FPGAs, oder ist mit diesen kommunikativ gekoppelt, deren Konfiguration die Operationen von einem oder mehreren der ADAS-Systeme steuert oder zumindest teilweise steuert, sodass die Funktionsaktualisierung durch Rekonfigurieren der einen oder den mehreren FPGAs implementiert werden kann.
Mitteilung
In manchen Ausführungsbeispielen kann das Aktualisierungssystem eine Mitteilung bzw. Benachrichtigung an einen Fahrer des Fahrzeugs bereitstellen, um diesen zu informieren, ob die Funktionsaktualisierung unter Verwendung einer Softwareaktualisierung für das ADAS-System oder durch Rekonfigurieren des FPGA des Fahrzeugs implementiert wird. Die Mitteilung, die dem Fahrer des Fahrzeugs bereitgestellt wird, kann eine visuelle Mitteilung, wie etwa eine graphische Benutzerschnittstelle („GUI“), eine Audiomitteilung, wie etwa ein Ton, der durch einen oder mehrere Lautsprecher erzeugt wird, oder eine Kombination einer visuellen Mitteilung und einer Audiomitteilung, die gleichzeitig oder zeitgleich bereitgestellt werden, sein.
Die visuelle Mitteilung kann durch eine Head-up-Anzeigeeinheit oder ein elektronisches Anzeigebild bereitgestellt werden. Die Head-up-Anzeigeeinheit kann eine dreidimensionale Head-up-Anzeigeeinheit umfassen, wie die, die in der US-Patentanmeldung Nr. 15/080,433 beschrieben ist, eingereicht am 24. März 2016 mit dem Titel „Wireless Data Sharing Between a Mobile Client Device and a Three-Dimensional Heads-Up Display Unit“, deren Gesamtheit hierin durch Bezugnahme miteingeschlossen ist.
Das elektronische Anzeigefeld kann ein Element einer Haupteinheit oder eines Infotainmentsystems sein, das in dem Fahrzeug installiert ist.
Die Audiomitteilung kann durch einen oder mehrere Lautsprecher, die durch die Haupteinheit, das Infotainmentsystem oder das Navigationssystem des Fahrzeugs betrieben werden, bereitgestellt werden.
Beispielübersicht
Bezugnehmend auf 1A ist eine Operationsumgebung 100 für ein Aktualisierungssystem 199 dargestellt. Die Operationsumgebung 100 kann eines oder mehrere der folgenden Elemente umfassen: ein Fahrzeug 123; ein entferntes Fahrzeug 124; eine straßenseitige Einheit 104 („RSU 104“); und einen Server 103. Diese Elemente der Operationsumgebung 100 können mit einem Netzwerk 105 kommunikativ gekoppelt sein.
In manchen Ausführungsbeispielen kann der Server 103 ein Element der RSU 104 sein. In manchen Ausführungsbeispielen kann der Server 103 ein von der RSU separates Element sein. Zum Beispiel kann der Server 103 ein Server oder manch andere prozessorbasierte Rechnereinrichtung sein, die betriebsfähig ist, um Mitteilungen über das Netzwerk 105 zu senden und zu empfangen. Die RSU 104 und der Server 103 werden nachstehend detaillierter beschrieben.
Das Netzwerk 105 kann von einer herkömmlichen Art sein, drahtgebunden oder drahtlos, und kann zahlreiche unterschiedliche Konfigurationen aufweisen, inklusive einer Sternkonfiguration, einer Token-Ring-Konfiguration oder anderen Konfigurationen. Des Weiteren kann das Netzwerk 105 ein Nahbereichsnetzwerk (LAN), ein Weitbereichsnetzwerk (WAN) (z. B. das Internet) oder andere zwischenverbundene Datenpfade umfassen, über die mehrere Einrichtungen und/oder Entitäten kommunizieren können. In manchen Ausführungsbeispielen kann das Netzwerk 105 ein Peer-zu-Peer-Netzwerk umfassen. Das Netzwerk 105 kann ebenso mit Abschnitten eines Telekommunikationsnetzwerks zum Senden von Daten in einer Vielzahl von unterschiedlichen Kommunikationsprotokollen gekoppelt sein oder dieses umfassen. In manchen Ausführungsbeispielen umfasst das Netzwerk 105 ein Bluetooth®-Kommunikationsnetzwerk oder ein zellulares Kommunikationsnetzwerk zum Senden und Empfangen von Daten inklusive eines Kurzmitteilungsdienstes (SMS), eines Multimediamitteilungsdienstes (MMS), Hypertext-Transfer-Protokoll (HTTP), einer direkten Datenverbindung, einem drahtlosen Anwendungsprotokoll (WAP), Email, DSRC, einer Full-Duplex-Drahtloskommunikation und so weiter. Das Netzwerk 105 kann ebenso ein mobiles Datennetzwerk umfassen, das 3G, 4G, LTE, VoLTE oder irgendein anderes mobiles bzw. zellulares Datennetzwerk oder eine Kombination von mobilen Datennetzwerken umfassen kann. Weiterhin kann das Netzwerk 105 eines oder mehrere IEEE 802.11 Drahtlosnetzwerke umfassen.
In manchen Ausführungsbeispielen können einer oder mehrere des Fahrzeugs 123, des entfernten Fahrzeugs 124, der RSU 104 und des Servers 103 mit DSRC ausgestattet sein. Das Netzwerk 105 kann einen oder mehrere Kommunikationskanäle umfassen, die unter dem Fahrzeug 123 und einer oder mehreren anderen drahtlosen Kommunikationseinrichtungen (zum Beispiel einem oder mehreren entfernten Fahrzeugen 124, RSUs 104, Server 103, usw.) geteilt sind. Der Kommunikationskanal kann DSRC, eine Full-Duplex-Drahtloskommunikation oder irgendein anderes drahtloses Kommunikationsprotokoll umfassen. Zum Beispiel kann das Netzwerk 105 verwendet werden, um eine DSRC-Mitteilung, eine DSRC-Sondierung oder BSM inklusive BSM-Daten 195 (oder ähnlichen Daten) an das Fahrzeug 123 zu übertragen.
Das Fahrzeug 123 und das entfernte Fahrzeug 124 können die gleichen oder ähnliche Elemente umfassen. Das Fahrzeug 123 und das entfernte Fahrzeug 124 können eine Verbindung oder Verknüpfung teilen. Zum Beispiel können das Fahrzeug 123 und das entfernte Fahrzeug 124 einen gemeinsamen Hersteller teilen (zum Beispiel Toyota), und die hierin beschriebene Funktionalität könnte nur Fahrzeugen bereitgestellt sein, die diesen gemeinsamen Hersteller aufweisen.
Das Fahrzeug 123 kann ein Auto, einen Lastwagen, ein Sports-Utility-Vehicle, einen Bus, einen Sattelzug, eine Drohne oder irgendein anderes fahrbahnbasiertes Beförderungsmittel umfassen. In manchen Ausführungsbeispielen kann das Fahrzeug 123 ein autonomes Fahrzeug oder ein semiautonomes Fahrzeug umfassen. Zum Beispiel kann das Fahrzeug 123 ein ADAS-System umfassen, das eines oder mehrere ADAS-Systeme umfasst, die eine ausreichende ADAS-Funktionalität bereitstellen, um das Fahrzeug 123 zu einem autonomen Fahrzeug zu machen.
Das Fahrzeug 123 umfasst eines oder mehrere der folgenden Elemente: einen Sensorsatz 182; einen Prozessor 125A; einen Speicher 127A; eine Kommunikationseinheit 145A; eine DSRC-konforme GPS-Einheit 170; ein ADAS-System 180; eine elektronische Steuerungseinheit 183 („ECU 183“); ein FPGA 184; und ein Aktualisierungssystem 199. Diese Elemente des Fahrzeugs 123 können miteinander über einen Bus 120A kommunikativ gekoppelt sein.
In manchen Ausführungsbeispielen ist das Aktualisierungssystem 199 ein Element des Fahrzeugs 123. In manchen Ausführungsbeispielen ist das Aktualisierungssystem 199 ein Element eines Servers 103. In manchen Ausführungsbeispielen umfassen das Fahrzeug 123 und der Server 103 jeweils deren eigene Instanz des Aktualisierungssystems 199 und ist die Funktionalität des Aktualisierungssystems 199 zwischen dem Fahrzeug 123 und dem Server 103 verteilt. Zum Beispiel ist das Aktualisierungssystem 199 in 1A mit einer gestrichelten Linie dargestellt, um anzugeben, dass das Aktualisierungssystem 199 ein Element des Fahrzeugs 123, des Servers 103 oder sowohl des Fahrzeugs 123 und des Servers 103 sein kann.
In manchen Ausführungsbeispielen können der Prozessor 125A und der Speicher 127A Elemente eines fahrzeugseitigen Fahrzeugcomputersystems (nicht dargestellt) sein. Das fahrzeugseitige Fahrzeugcomputersystem kann betriebsfähig sein, um die Operation des Aktualisierungssystems 199 zu veranlassen oder zu steuern. Das fahrzeugseitige Fahrzeugcomputersystem kann betriebsfähig sein, um auf Daten, die auf dem Speicher 127A gespeichert sind, zuzugreifen und diese auszuführen, um die hierin beschriebene Funktionalität für das Aktualisierungssystem 199 oder deren Elemente bereitzustellen. In manchen Ausführungsbeispielen sind der Prozessor 125A und der Speicher 127A Elemente der ECU 183.
Der Sensorsatz 182 kann einen oder mehrere Sensoren umfassen, die betriebsfähig sind, um die physikalische Umgebung außerhalb des Fahrzeugs 123 zu messen. Zum Beispiel kann der Sensorsatz 182 eine oder mehrere physikalische Charakteristika der physikalischen Umgebung, die in der Nähe des Fahrzeugs 123 ist, aufzeichnen.
In manchen Ausführungsbeispielen kann der Sensorsatz 182 einen oder mehrere der folgenden Fahrzeugsensoren umfassen: eine Kamera; einen LIDAR-Sensor; einen Laserhöhenmesser; einen Navigationssensor (zum Beispiel einen Sensor eines globalen Positionierungssystems der DSRC-konformen GPS-Einheit 170); einen Infrarotdetektor; einen Bewegungsdetektor; ein Thermostat; einen Tondetektor; einen Kohlenmonoxidsensor; einen Kohlendioxidsensor; einen Sauerstoffsensor; einen Luftmassensensor; einen Maschinenkühlmitteltemperatursensor; einen Drosselklappenpositionssensor; einen Kurbelwellenpositionssensor; einen Automobilmaschinensensor; einen Ventilzeitgeber; ein Luftkraftstoffverhältnismessgerät; ein Totwinkelmessgerät; einen Randsteinfühler; einen Defektdetektor; einen Hall-Effekt-Sensor; einen Krümmerabsolutdrucksensor; einen Parksensor; eine Radarpistole; einen Geschwindigkeitsmesser; einen Geschwindigkeitssensor; einen Reifendrucküberwachungssensor; einen Drehmomentsensor; einen Getriebeflüssigkeitstemperatursensor; einen Turbinendrehzahlsensor (TSS); einen variablen Reluktanzsensor bzw. Sensor einer variablen Reluktanz bzw. einen Induktionsgeber; einen Fahrzeuggeschwindigkeitssensor (VSS); einen Wassersensor; einen Raddrehzahlsensor; und irgendeine andere Art des automotiven Sensors.
Der Sensorsatz 182 kann betriebsfähig sein, um Daten (optional nachstehend als „Sensordaten“ bezeichnet) aufzuzeichnen, die einen oder mehrere Orte des Fahrzeugs 123 zu einer oder mehreren unterschiedlichen Zeiten beschreiben; diese Daten können zeitgestempelt sein, um die Zeit anzugeben, wann das Fahrzeug 123 an diesem bestimmten Ort war.
Der Prozessor 125A umfasst eine arithmetische Logikeinheit, einen Mikroprozessor, einen Allzweckcontroller oder manch anderes Prozessorfeld, um Berechnungen durchzuführen und elektronische Anzeigesignale an eine Anzeigeeinrichtung bereitzustellen. Der Prozessor 125A verarbeitet Datensignale und kann verschiedene Berechnungsarchitekturen umfassen, inklusive einer „Complex Instruction Set Computer (CISC)“-Architektur, einer „Reduced Instruction Set Computer (RISC)“-Architektur oder einer Architektur, die eine Kombination von Anweisungssätzen implementiert. Obwohl 1A einen einzelnen Prozessor 125A umfasst, können mehrere Prozessoren umfasst sein. Andere Prozessoren, Betriebssysteme, Sensoren, Anzeigen und physikalische Konfigurationen können ebenso möglich sein.
Der Speicher 127A speichert Anweisungen oder Daten, die durch den Prozessor 125A ausgeführt werden können. Die Anweisungen oder Daten können einen Code zum Durchführen der hierin beschriebenen Techniken umfassen. Der Speicher 127A kann eine Einrichtung eines dynamischen Direktzugriffspeichers (DRAM), eine Einrichtung eines statischen Direktzugriffspeichers (SRAM), ein Flash-Speicher oder manch andere Speichereinrichtung sein. In manchen Ausführungsbeispielen umfasst der Speicher 127A ebenso einen nichtflüchtigen Speicher oder eine ähnliche permanente Speichereinrichtung und Medien inklusive eines Festplattenlaufwerks, eines Diskettenlaufwerks, einer CD-ROM-Einrichtung, einer DVD-ROM-Einrichtung, einer DVD-RAM-Einrichtung, einer DVD-RW-Einrichtung, einer Flash-Speichereinrichtung, oder manch anderer Massenspeichereinrichtung zum Speichern von Informationen auf einer permanenten Basis.
Wie in 1A dargestellt ist, speichert in manchen Ausführungsbeispielen der Speicher 127A eines oder mehrere der folgenden Elemente: Systemdaten 190; Aktualisierungsdaten 191; Entscheidungsdaten 192; Analysedaten 193; und ADAS-Daten 194.
Die Systemdaten 190 sind digitale Daten, die eine oder mehrere Variablen oder Faktoren beschreiben, die beeinflussen, ob eine Funktionsaktualisierung für das ADAS-System 180 durch entweder Bereitstellen einer Softwareaktualisierung für die ADAS-Daten 194 oder durch Rekonfigurieren des FPGA 184 implementiert werden sollte. In manchen Ausführungsbeispielen umfassen die Systemdaten 190 BSM-Daten 195, die von einem oder mehreren des entfernten Fahrzeugs 124 und der RSU 104 empfangen werden. Die Systemdaten 190 werden nachstehend detailliert mit Bezug auf 1B, 1C, 1D, 1E und 1F beschrieben.
Die Aktualisierungsdaten 191 sind digitale Daten, die beschreiben, wie die Funktionsaktualisierung für das ADAS-System 180 zu implementieren ist. In manchen Ausführungsbeispielen ist der Inhalt der Aktualisierungsdaten 191 basierend auf der Implementierungsentscheidung variabel.
Wenn zum Beispiel die Implementierungsentscheidung ist, die Funktionsaktualisierung unter Verwendung einer Softwareaktualisierung für das ADAS-System 180 zu implementieren, dann sind die Aktualisierungsdaten 191 digitale Daten, die eine ausführbare Datei beschreiben, die die Funktionsaktualisierung implementiert, wenn diese in dem Speicher 127A installiert wird oder durch den Prozessor 125A ausgeführt wird.
In einem anderen Beispiel, wenn die Implementierungsentscheidung ist, die Funktionsaktualisierung durch Rekonfigurieren des FPGA 184 zu implementieren, dann sind die Aktualisierungsdaten 191 digitale Daten, die beschreiben, wie das FPGA 184 zu rekonfigurieren ist, um die Funktionsaktualisierung zu implementieren (das heißt, um die Operation des ADAS-Systems 180 zu modifizieren, sodass die Operation des ADAS-Systems 180 mit der Funktionsaktualisierung für das ADAS-System 180 konsistent ist).
Die Entscheidungsdaten 192 sind digitale Daten, die ein Rahmenwerk oder Protokoll zum Vergleichen von Elementen der Systemdaten 190 miteinander bereitstellen, sodass das Aktualisierungssystem 199 bestimmen kann, ob eine Funktionsaktualisierung, die durch die Aktualisierungsdaten 191 beschrieben ist, unter Verwendung von entweder einer Softwareaktualisierung für die ADAS-Daten 194 oder einer Rekonfiguration des FPGA 184 zu implementieren ist. In manchen Ausführungsbeispielen gibt das Aktualisierungssystem 199 einen Satz von binären Variablen aus, als Reaktion auf eine Analyse der Systemdaten 190 unter Verwendung der Entscheidungsdaten 192. Der Satz von binären Variablen wird dann in eine Datenstruktur, die durch die Analysedaten 193 beschrieben ist, als ein Unterschritt des Aktualisierungssystems 199, das die Implementierungsentscheidung vornimmt, eingegeben. Die Entscheidungsdaten 192 werden nachstehend mit Bezug auf 1G detailliert beschrieben.
Die Analysedaten 194 sind digitale Daten, die eine Datenstruktur zum Analysieren der Systemdaten 190 beschreiben. In manchen Ausführungsbeispielen beschreiben die Analysedaten 194 eine Datenstruktur zum Analysieren des Satzes von binären Variablen, die durch das Aktualisierungssystem 199 nach einem Analysieren der Systemdaten 190 unter Verwendung der Entscheidungsdaten 192 ausgegeben werden. In manchen Ausführungsbeispielen sind die Analysedaten 194 eine Tabelle, wie etwa die eine, die in 1H dargestellt ist. Die Analysedaten 194 werden nachstehend mit Bezug auf 1H detaillierter beschrieben.
Die ADAS-Daten 194 sind digitale Daten, die den Code und Routinen beschreiben, die, wenn diese durch den Prozessor 125A ausgeführt werden, das ADAS-System 180 veranlassen, deren Funktionalität bereitzustellen.
Zum Beispiel sind die ADAS-Daten 194 Software für das ADAS-System 180, die, wenn diese durch den Prozessor 125A ausgeführt wird, das ADAS-System 180 veranlasst, deren Funktionalität bereitzustellen.
Die Kommunikationseinheit 145A überträgt und empfängt Daten an und von einem Netzwerk 105 und zu einem anderen Kommunikationskanal. In manchen Ausführungsbeispielen umfasst die Kommunikationseinheit 145A einen DSRC-Senderempfänger, einen DSRC-Empfänger und andere Hardware oder Software, die notwendig ist, um das Fahrzeug 123 zu einer DSRC-fähigen Einrichtung zu machen. In manchen Ausführungsbeispielen umfasst eines oder mehrere des entfernten Fahrzeugs 124 und der RSU 104 eine Kommunikationseinheit 145A und eine DSRC-konforme GPS-Einheit 170, sodass diese Elemente der Operationsumgebung 100 mit DSRCausgestattete Einrichtungen sind.
In manchen Ausführungsbeispielen umfasst die Kommunikationseinheit 145A einen Anschluss für eine direkte physische Verbindung zu dem Netzwerk 105 oder zu einem anderen Kommunikationskanal. Zum Beispiel umfasst die Kommunikationseinheit 145A einen USB-, SD-, CAT-5-, oder einen ähnlichen Anschluss für eine drahtgebundene Kommunikation mit dem Netzwerk 105. In manchen Ausführungsbeispielen umfasst die Kommunikationseinheit 145A einen drahtlosen Senderempfänger zum Austauschen von Daten mit dem Netzwerk 105 oder einem anderen Kommunikationskanal und der Verwendung von einem oder mehreren drahtlosen Kommunikationsverfahren, inklusive: IEEE 802.11; IEEE 802.16, Bluetooth®; EN ISO 14906:2004 Elektronische Gebührensammlung, Anwendungsschnittstelle, EN 11253:2004 Dedizierte Nahbereichskommunikation - physikalische Schicht unter Verwendung von Mikrowellen bei 5,8 GHz (Review); EN 12795:2002 Dedizierte Nahbereichskommunikation (DSRC) - DSRC-Daten-Verbindungsschicht: Medienzugriffs- und Logikverbindungssteuerung (Review); EN 12834:2002 Dedizierte Nahbereichskommunikation - Anwendungsschicht (Review); EN 13372:2004 Dedizierte Nahbereichskommunikation (DSRC) - DSRC-Profile für RTTT-Anwendungen (Review); das Kommunikationsverfahren, das in der US-Patentanmeldung 14/471,387 , eingereicht am 28. August 2014 mit dem Titel „Full-Duplex Coordination System“ beschrieben ist, oder einem anderen geeigneten Drahtloskommunikationsverfahren.
In manchen Ausführungsbeispielen umfasst die Kommunikationseinheit 145A ein Full-Duplex-Koordinationssystem, das in der US-Patentanmeldung 14/471,387 , eingereicht am 28. August 2014 mit dem Titel „Full-Duplex Coordination System“ beschrieben ist.
In manchen Ausführungsbeispielen umfasst die Kommunikationseinheit 145A einen zellularen Kommunikationssenderempfänger zum Senden und Empfangen von Daten über ein zellulares Kommunikationsnetzwerk inklusive einem Kurzmitteilungsdienst (SMS), einem Multimediamitteilungsdienst (MMS), einem Hypertext Transfer Protokoll (HTTP), einer direkten Datenverbindung, WAP, E-Mail oder einer anderen geeigneten Art von elektronischer Kommunikation. In manchen Ausführungsbeispielen umfasst die Kommunikationseinheit 145A einen drahtgebundenen Anschluss und einen drahtlosen Senderempfänger. Die Kommunikationseinheit 145A stellt ebenso andere konventionelle Verbindungen zu dem Netzwerk 105 zum Verteilen von Daten oder Mediendateien unter Verwendung von Standardnetzwerkprotokollen inklusive TCP/IP, HTTP, HTTPS und SMTP, Millimeterwellen, DSRC, usw. bereit.
Die DSRC-konforme GPS-Einheit 170 kann Hardware umfassen, die mit einem GPS-Satelliten drahtlos kommuniziert, um GPS-Daten abzurufen, die einen Ort des Fahrzeugs 123 beschreiben. In manchen Ausführungsbeispielen ist eine DSRC-konforme GPS-Einheit 170 betriebsfähig, um GPS-Daten bereitzustellen, die den Ort des Fahrzeugs 123 mit einem Grad einer Genauigkeit einer Spurebene bzw. eines Spurlevels beschreibt. Der DSRC-Standard erfordert, dass GPS-Daten präzise genug sind, um abzuleiten, ob zwei Fahrzeuge (wie etwa das Fahrzeug 123 und ein anderes Fahrzeug auf der gleichen Straße wie das Fahrzeug 123) auf der gleichen Spur sind. Die DSRC-konforme GPS-Einheit 170 kann betriebsfähig sein, um ihre zweidimensionale Position innerhalb von 1,5 Metern ihrer aktuellen Position zu 68 % der Zeit unter einem freien Himmel zu identifizieren, zu überwachen und zu verfolgen. Da Spuren einer Straße üblicherweise nicht weniger als 3 Meter breit sind, kann das Aktualisierungssystem 199, wann immer der zweidimensionale Fehler der GPS-Daten weniger als 1,5 Meter beträgt, die GPS-Daten, die durch die DSRC-konforme GPS-Einheit 170 bereitgestellt sind, analysieren und bestimmen, auf welcher Spur der Straße das Fahrzeug 123 fährt, basierend auf den relativen Positionen der Fahrzeuge auf der Straße. Ähnlich umfasst das entfernte Fahrzeug 124 eine DSRC-konforme GPS-Einheit 170, die GPS-Daten bereitstellt, die als ein Element der BSM-Daten 195 enthalten sind und den geographischen Ort des entfernten Fahrzeugs 124 mit dem gleichen Grad einer Präzision beschreiben.
Zum Vergleich ist eine GPS-Einheit, die nicht mit dem DSRC-Standard konform ist, weit weniger genau als die DSRC-konforme GPS-Einheit 170 und nicht dazu in der Lage, eine Spurlevelgenauigkeit zuverlässig bereitzustellen, wie die DSRC-konforme GPS-Einheit 170. Zum Beispiel kann eine nicht-DSRC-konforme GPS-Einheit eine Genauigkeit in der Größenordnung von 10 Metern aufweisen, was nicht ausreichend präzise ist, um den Präzisionsgrad eines Spurlevels bereitzustellen, das durch die DSRC-konforme GPS-Einheit 170 bereitgestellt wird. Zum Beispiel, da eine Spur so eng wie 3 Meter breit sein kann, kann der DSRC-Standard erfordern, dass eine DSRC-konforme GPS-Einheit 170 eine Genauigkeit in der Größenordnung von 1,5 Metern aufweist, was signifikant präziser ist, als eine nicht-DSRC-konforme GPS-Einheit, wie vorstehend beschrieben. Als ein Ergebnis könnte eine nicht-DSRC-konforme GPS-Einheit nicht dazu in der Lage sein, GPS-Daten bereitzustellen, die genau genug sind, um dem Aktualisierungssystem 199 zu ermöglichen, zu bestimmen, wie nahe andere Fahrzeuge (wie etwa das entfernte Fahrzeug 124) dem Fahrzeug 123 sind, was die Fähigkeit des Aktualisierungssystems 199, den Kontext des Fahrzeugs 123 genau zu verstehen, wenn eine Funktionsaktualisierung implementiert wird, beeinträchtigt. Wenn diese Kontextinformationen nicht vorhanden sind, beeinträchtigt dies negativ die Fähigkeit des Aktualisierungssystems 199, die bestmögliche Implementierungsentscheidung vorzunehmen, da eine Entscheidung, ob eine Softwareaktualisierung oder eine FPGA-Rekonfiguration für die Implementierung der Funktionsaktualisierung ausgewählt wird, teilweise basierend auf solchen Informationen bestimmt wird. Die Funktionalität und die Präzision der GPS-Daten, die durch die DSRC-konforme GPS-Einheit 170 bereitgestellt werden, sind deshalb aus diesem beispielhaften Grund vorteilhaft.
Das ADAS-System 180 kann eines oder mehrere fortgeschrittene Fahrerassistenzsysteme umfassen. Beispiele eines ADAS-Systems 180 umfassen eines oder mehrere der folgenden Elemente des Fahrzeugs 123: ein ACC-System; ein adaptives Fernlichtsystem; ein adaptives Lichtsteuerungssystem; ein automatisches Parksystem; ein automotives Nachtsichtsystem; einen Totwinkelmonitor; ein Kollisionsvermeidungssystem; ein Querwindstabilisierungssystem; ein Fahrermüdigkeitserfassungssystem; ein Fahrerüberwachungssystem; ein Notfallfahrerassistenzsystem; ein Vorwärtskollisionswarnsystem; ein Kreuzungsassistenzsystem; ein intelligentes Geschwindigkeitsanpassungssystem; ein Spurabweichungswarnsystem; ein Fußgängerschutzsystem; ein Verkehrszeichenerkennungssystem, einen Abbiegeassistent; und ein Falschfahrwarnsystem.
In manchen Ausführungsbeispielen umfasst das ADAS-System 180 irgendeine Hardware oder Software, die eine oder mehrere Operationen des Fahrzeugs 123 steuern, sodass das Fahrzeug 123 „autonom“ oder „semiautonom“ ist.
Die ECU 183 ist eine herkömmliche elektronische Steuerungseinheit. In manchen Ausführungsbeispielen ist die ECU 183 ein Element eines fahrzeugseitigen Fahrzeugcomputers des Fahrzeugs 123. In manchen Ausführungsbeispielen ist die ECU 183 ein Element einer fahrzeugseitigen Einheit bz7w. On-Board-Einheit des Fahrzeugs 123. In manchen Ausführungsbeispielen ist die ECU 183 betriebsfähig, um die Operation des ADAS-Systems 180 zu steuern. Zum Beispiel ist die ECU 183 die prozessorbasierte Rechnereinrichtung des Fahrzeugs 123, die die Operationen des ADAS-Systems 180 steuert. In manchen Ausführungsbeispielen führt die ECU 183 die ADAS-Daten 184 aus, um die Funktionalität des ADAS-Systems 180 bereitzustellen.
Das FPGA 184 ist ein herkömmliches feldprogrammierbares Gate-Array. In manchen Ausführungsbeispielen ist das FPGA 184 ein Element des ADAS-Systems 180. In manchen Ausführungsbeispielen ist das ADAS-System 180 ein Element des FPGA 184.
In manchen Ausführungsbeispielen ist das FPGA 184 ein Hardware-FPGA, das dazu konfiguriert ist, die Funktionalität des ADAS-Systems 180 bereitzustellen. Zum Beispiel ist das FPGA 184 betriebsfähig, sodass eine Ausführung des FPGA 184 manche oder alle der Funktionalität des ADAS-Systems 180 (nachstehend „ADAS-Funktionalität“) bereitstellt. In manchen Ausführungsbeispielen modifiziert eine Modifizierung der Konfiguration des FPGA 184 die ADAS-Funktionalität, die durch das FPGA 184 bereitgestellt ist. Zum Beispiel ist in manchen Ausführungsbeispielen das FPGA 184 betriebsfähig, sodass ein Rekonfigurieren des FPGA 184 basierend auf den Aktualisierungsdaten 191 das FPGA 184 veranlasst, eine modifizierte ADAS-Funktionalität bereitzustellen, die mit der Funktionsaktualisierung, die durch die Aktualisierungsdaten 191 beschrieben ist, konsistent ist.
In manchen Ausführungsbeispielen ist das FPGA 184 ein Element der ECU 183. In manchen Ausführungsbeispielen ist die ECU 183 eine prozessorbasierte Rechnereinrichtung, die den Code und Routinen des Aktualisierungssystems 199 des Fahrzeugs 123 ausführt.
In manchen Ausführungsbeispielen umfasst das Aktualisierungssystem 199 einen Code oder Routinen, die betriebsfähig sind, wenn diese durch den Prozessor 125A ausgeführt werden, um den Prozessor 125A zu veranlassen, die Systemdaten zu sammeln und die Implementierungsentscheidung für eine Funktionsaktualisierung basierend auf einem oder mehreren der Systemdaten 190, der Entscheidungsdaten 192 und der Analysedaten 193 vorzunehmen.
In manchen Ausführungsbeispielen umfasst das Aktualisierungssystem 199 einen Code oder Routinen, die betriebsfähig sind, wenn diese durch den Prozessor 125A ausgeführt werden, um den Prozessor 125A zu veranlassen, eine drahtlose Mittelung zu erzeugen und an das Netzwerk 105 zu übertragen, die digitale Daten umfasst, wie etwa die Systemdaten 190; der Server 103 empfängt die drahtlose Mitteilung und nimmt die Implementierungsentscheidung für die Funktionsaktualisierung basierend auf einen oder mehreren der Systemdaten 190, der Entscheidungsdaten 192 und der Analysedaten 193 vor; der Server 103 stellt dann die Aktualisierungsdaten 191 dem Aktualisierungssystem 199 des Fahrzeugs 123 über das Netzwerk 105 bereit.
In manchen Ausführungsbeispielen umfasst das Aktualisierungssystem 199 einen Code oder Routinen, die betriebsfähig sind, um, wenn diese durch den Prozessor 125A ausgeführt werden, den Prozessor 125A zu veranlassen, einen oder mehrere Schritte des Verfahrens 300, das nachstehend mit Bezug auf 3A bis 3C beschrieben ist, auszuführen.
In manchen Ausführungsbeispielen kann das Aktualisierungssystem 199 unter Verwendung einer Hardware inklusive eines FPGA oder einer anwendungsspezifischen integrierten Schaltung („ASIC“) implementiert werden. In manchen anderen Ausführungsbeispielen kann das Aktualisierungssystem 199 unter Verwendung einer Kombination von Hardware und Software implementiert werden. Das Aktualisierungssystem 199 kann in einer Kombination der Einrichtungen (zum Beispiel Server oder anderen Einrichtungen) oder in einer der Einrichtungen gespeichert werden.
Das Aktualisierungssystem 199 wird nachstehend mit Bezug auf 1B bis 1H, 2 und 3A bis 3C detaillierter beschrieben.
Obwohl es in 1A nicht dargestellt ist, kann das Fahrzeug 123 in manchen Ausführungsbeispielen ein Full-Duplex-Koordinationssystem umfassen, das in der US-Patentanmeldung 14/471,387 , eingereicht am 28. August 2014 mit dem Titel „Full-Duplex Coordination System“ beschrieben ist.
In manchen Ausführungsbeispielen kann das Full-Duplex-Koordinationssystem des Fahrzeugs 123 eine Full-Duplex-Drahtlosmitteilung empfangen, die irgendwelche der digitalen Daten, die auf dem Speicher 127A gespeichert sind, umfasst.
Der Server 103 ist eine prozessorbasierte Rechnereinrichtung. Zum Beispiel kann die Rechnereinrichtung einen eigenständigen Hardwareserver umfassen. In manchen Ausführungsbeispielen ist der Server 103 mit dem Netzwerk 105 kommunikativ gekoppelt. Der Server 103 kann Netzwerkkommunikationsfähigkeiten umfassen.
Der Server 103 umfasst eines oder mehrere der folgenden Elemente: einen Prozessor 125B; einen Speicher 127B; eine Kommunikationseinheit 145B; und ein Aktualisierungssystem 199. Diese Elemente des Servers 103 sind miteinander über einen Bus 120B kommunikativ gekoppelt.
Die folgenden Elemente des Servers 103 sind ähnlich zu den vorstehend beschriebenen für das Fahrzeug 123, sodass deren Beschreibung hier nicht wiederholt wird: der Prozessor 125B; der Speicher 127B; die Kommunikationseinheit 145B; und das Aktualisierungssystem 199. Der Speicher 127B des Servers 103 kann digitale Daten speichern, die ähnlich zu den digitalen Daten sind, die in dem Speicher 127A des Fahrzeugs 123 gespeichert sind.
Der Server 103 kann betriebsfähig sein, um drahtlose Mitteilungen über das Netzwerk 105 zu senden und zu empfangen. Zum Beispiel veranlasst das Aktualisierungssystem 199 des Fahrzeugs 123 die Kommunikationseinheit 145A des Fahrzeugs, eine drahtlose Mitteilung an den Server 103 über das Netzwerk 105 zu senden. Die drahtlose Mitteilung umfasst eine Anforderung für die Aktualisierungsdaten 191 sowie die Systemdaten 190. Die Kommunikationseinheit 145B des Servers 103 empfängt die drahtlose Mitteilung von dem Netzwerk 105 und stellt die drahtlose Mitteilung inklusive der Anforderung und der Systemdaten 190 dem Aktualisierungssystem 199 des Servers 103 bereit. Das Aktualisierungssystem 199 des Servers 103 nimmt die Implementierungsentscheidung basierend zumindest teilweise auf den Systemdaten 190 vor, erzeugt die Aktualisierungsdaten 191 basierend auf der Implementierungsentscheidung und veranlasst die Kommunikationseinheit 145B des Servers 103, die Aktualisierungsdaten 191 dem Fahrzeug 123 über das Netzwerk 105 bereitzustellen.
Das entfernte Fahrzeug 124 kann Elemente umfassen, die ähnlich dem Fahrzeug 123 sind, sodass deren Beschreibung hier nicht wiederholt wird. Wie dargestellt ist, ist das entfernte Fahrzeug 124 eine mit DSRC ausgestattete Einrichtung, die eine DSRC-konforme GPS-Einheit 170 und eine Kommunikationseinheit 145 mit einem DSRC-Sender und einem DSRC-Empfänger umfasst, die betriebsfähig sind, um DSRC-Mitteilungen (zum Beispiel BSM-Mitteilungen), die die BSM-Daten 195 oder Daten ähnlich zu den BSM-Daten 195 umfassen, zu senden und zu empfangen. Die BSM-Daten 195 werden nachstehend mit Bezug auf 4A und 4B detaillierter beschrieben.
Die RSU 104 kann einen nichtflüchtigen Speicher umfassen, der BSM-Daten 195 speichert. Die RSU 104 kann ebenso eine Kommunikationseinheit 145A umfassen (nicht dargestellt). Die RSU 104 kann ebenso einen Sensorsatz 182 umfassen, der die Sensordaten aufzeichnet. Als Alternative zum Aufzeichnen der Sensordaten direkt unter Verwendung des eigenen Sensorsatzes 182 kann die RSU 104 Sensordaten, die durch einen Sensorsatz des entfernten Fahrzeugs 124 aufgezeichnet sind, an das Fahrzeug 123 als ein Element einer BSM-Mitteilung oder irgendeiner anderen DSRC-Mitteilung weiterleiten. Wenn zum Beispiel das Fahrzeug 123 außerhalb des Kommunikationsbereichs des entfernten Fahrzeugs 124 ist, dann kann die RSU 104 eine drahtlose Mitteilung inklusive der BSM-Daten 195 an das Fahrzeug 123 weiterleiten.
Bezugnehmend nun auf 1B ist ein Blockdiagramm dargestellt, das Systemdaten 190 gemäß manchen Ausführungsbeispielen darstellt. Wie dargestellt ist, umfassen die Systemdaten 190 eine oder mehrere der folgenden Arten von digitalen Daten: Dateigrößendaten 140; FPGA-Größendaten 141; Dateizeitdaten 142; FPGA-Zeitdaten 143; BSM-Daten 195 von einem oder mehreren des entfernten Fahrzeugs 124 und der RSU 104; funktionale Beschränkungsdaten bzw. Funktionsbeschränkungsdaten 144; Ressourcenbeschränkungsdaten 146; Schätzzeitdaten bzw. Daten eines geschätzten Zeit 147; und Schätzverbrauchsdaten bzw. Daten eines geschätzten Verbrauchs 148.
Die Dateigrößendaten 140 sind digitale Daten, die eine Größe der ausführbaren Datei beschreiben, die verwendet werden würde, um die Funktionsaktualisierung über eine Softwareaktualisierung zu implementieren. Wenn zum Beispiel die Implementierungsentscheidung ist, dass die Funktionsaktualisierung über eine Softwareaktualisierung implementiert wird, dann beschreiben die Dateigrößendaten 140 die Dateigröße der ausführbaren Datei, die in dem Fahrzeug 123 installiert ist, um die Funktionsaktualisierung zu implementieren; die ausführbare Datei selbst wird in diesem Ausführungsbeispiel durch die Aktualisierungsdaten 191 beschrieben.
Die FPGA-Größendaten 141 sind digitale Daten, die eine Größe (oder einen Bereich) des FPGA 184 beschreiben, das rekonfiguriert werden würde, um die Funktionsaktualisierung als eine FPGA-Rekonfiguration zu implementieren. Zum Beispiel weist das FPGA 184 einen bestimmten Bereich auf, und, wenn die Implementierungsentscheidung ist, dass die Funktionsaktualisierung über eine FPGA-Rekonfiguration implementiert wird, dann beschreiben die FPGA-Größendaten 141 eine Größe oder einen Bereich des FPGA 184, das rekonfiguriert wird, um die Funktionsaktualisierung zu implementieren; in diesem Ausführungsbeispiel sind die Aktualisierungsdaten 191 ein Bitstrom, der beschreibt, wie das FPGA 184 zu rekonfigurieren ist.
Die Dateizeitdaten 142 sind digitale Daten, die einen normierten Zeitbetrag beschreiben, der notwendig ist, um die ausführbare Datei zu installieren, oder die ausführbare Datei vollständig auszuführen, die verwendet wird, um die Funktionsaktualisierung als eine Softwareaktualisierung zu implementieren. Wenn zum Beispiel die Implementierungsentscheidung ist, dass die Funktionsaktualisierung über eine Softwareaktualisierung implementiert wird, dann beschreiben die Dateizeitdaten 142 einen normierten Zeitbetrag, der nötig ist, um die ausführbare Datei (zum Beispiel die ausführbare Datei zu installieren) auf einer standardisierten Softwareplattform, die die gleiche sein könnte oder nicht, wie die Softwareplattform, die auf dem Fahrzeug 123 vorhanden ist, vollständig auszuführen.
Die FPGA-Zeitdaten 143 sind digitale Daten, die einen normierten Zeitbetrag beschreiben, der notwendig ist, um zu rekonfigurieren oder die ausführbare Datei vollständig auszuführen. Wenn zum Beispiel die Implementierungsentscheidung ist, dass die Funktionsaktualisierung über eine FPGA-Rekonfiguration implementiert wird, dann beschreiben die FPGA-Zeitdaten 143 einen normierten Zeitbetrag, der notwendig ist, um das FPGA auf einer standardisierten Softwareplattform, die die gleiche sein kann oder nicht, wie die Softwareplattform, die auf dem Fahrzeug 123 vorhanden ist, vollständig zu rekonfigurieren.
Die BSM-Daten 195 werden nachstehend detaillierter mit Bezug auf 4A und 4B beschrieben. Die Systemdaten 190 können irgendwelche oder alle Informationen, die in den BSM-Daten 195 enthalten sind, umfassen.
In manchen Ausführungsbeispielen umfassen die Systemdaten 190 die folgenden Elemente der BSM-Daten 195, die in einem Teil I von einer oder mehreren BSM-Mitteilungen enthalten sind, die von einem oder mehreren entfernten Fahrzeugen 124 empfangen werden: einen Breitengrad für eines oder mehrere entfernte Fahrzeuge 124; einen Längengrad für eines oder mehrere entfernte Fahrzeuge 124; eine Höhe für eines oder mehrere entfernten Fahrzeuge 124; eine Positionsgenauigkeit für eines oder mehrere entfernte Fahrzeuge 124; eine Übertragungseinstellung für eines oder mehrere entfernte Fahrzeuge 124; eine momentane Geschwindigkeit für eines oder mehrere entfernte Fahrzeuge 124; eine momentane Richtung für eines oder mehrere entfernte Fahrzeuge 124; einen momentaner Lenkwinkel für eines oder mehrere Fahrzeuge 124; eine momentane Beschleunigung für eines oder mehrere entfernte Fahrzeuge 124; einen momentaner Status der Bremssysteme für eines oder mehrere entfernte Fahrzeuge 124; und eine Fahrzeuggröße für eines oder mehrere entfernte Fahrzeuge 124.
In manchen Ausführungsbeispielen umfassen die Systemdaten 190 die folgenden Elemente der BSM-Daten 195, die in einem Teil II von einer oder mehreren BSM-Mitteilungen enthalten sind, die von einem oder mehreren entfernten Fahrzeugen 124 empfangen werden: einen oder mehrere Ereignismarker, die eines oder mehrere nahegelegene Fahrbahnereignisse beschreiben, die zum Bestimmen einer Ausführungsfrist (T_E') zum Vollenden bzw. Beenden der Funktionsaktualisierung relevant sind; Pfadverlaufsdaten, die einen oder mehrere vergangene Orte von einem oder mehreren entfernten Fahrzeugen 124 beschreiben; und Pfadvorhersagedaten, die einen oder mehrere beabsichtigte zukünftige Pfade für eines oder mehrere entfernte Fahrzeuge 124 beschreiben.
Die funktionalen Beschränkungsdaten bzw. Funktionsbeschränkungsdaten 144 werden nachstehend mit Bezug auf 1C beschrieben. Die Ressourcenbeschränkungsdaten 146 werden nachstehend mit Bezug auf 1D beschrieben. Die Schätzzeitdaten bzw. Daten einer geschätzten Zeit 147 werden nachstehend mit Bezug auf 1E beschrieben. Die Schätzverbrauchsdaten bzw. Daten eines geschätzten Verbrauchs 148 werden nachstehend mit Bezug auf 1F beschrieben.
Bezugnehmend auf 1C ist ein Blockdiagramm dargestellt, das die funktionalen Beschränkungsdaten 144 gemäß manchen Ausführungsbeispielen darstellt.
Die Aktualisierungsfrist 150 sind digitale Daten, die eine weiche Frist zum Vervollständigen bzw. Vollenden der Funktionsaktualisierung beschreiben. In manchen Ausführungsbeispielen, wenn die weiche Frist nicht eingehalten wird, dann wird die Funktionsaktualisierung immer noch durch das Aktualisierungssystem 199 implementiert und das Aktualisierungssystem 199 veranlasst eine elektronische Anzeige, eine HUD oder 3D-HUD des Fahrzeugs 123, eine Warnmitteilung für den Fahrer des Fahrzeugs 123 anzuzeigen, die visuell angibt, dass die Funktionsaktualisierung später als erwartet vollendet wird.
Die Aktualisierungsfrist 150 kann durch die Variable T_U' dargestellt werden, der ein Wert zugewiesen wird (zum Beispiel eine Zeit für die weiche Frist), die durch die Aktualisierungsfrist 150 beschrieben ist.
Die Ausführungsfrist 151 sind digitale Daten, die eine harte Frist zum Vollenden der Funktionsaktualisierung beschreiben. In manchen Ausführungsbeispielen, wenn die harte Frist nicht eingehalten wird, dann wird die Funktionsaktualisierung durch das Aktualisierungssystem 199 nicht implementiert und das Aktualisierungssystem 199 veranlasst eine elektronische Anzeige, eine HUD oder 3D-HUD des Fahrzeugs 123, eine Warnmitteilung für den Fahrer des Fahrzeugs 123 anzuzeigen, die visuell angibt, dass die Funktionsaktualisierung vorliegend vollendet wird.
In manchen Ausführungsbeispielen wird die Ausführungsfrist 151 durch das Aktualisierungssystem 199 basierend auf den Fahrbedingungen, die durch das Fahrzeug 123 erfahren werden, bestimmt. Die Fahrbedingungen werden durch die BSM-Daten 195 beschrieben, die von einer oder mehreren anderen mit DSRC ausgestatteten Einrichtungen, wie etwa dem entfernten Fahrzeug 124 oder der RSU 104 empfangen werden. Zum Beispiel umfasst das Aktualisierungssystem 199 einen Code und Routinen, die betriebsfähig sind, wenn diese durch den Prozessor des Fahrzeugs 123 ausgeführt werden, um den Prozessor zu veranlassen, die BSM-Daten 195 zu analysieren und die Ausführungsfrist 151 zu bestimmen. Wenn die BSM-Daten 195 zum Beispiel digitale Daten umfassen, die angeben, dass ein Ort eines Ereignismarkers durch das Fahrzeug 123 in X Sekunden erreicht wird, dann bestimmt das Aktualisierungssystem 199, dass die Ausführungsfrist 151 gleich X - Y Sekunden ist, wobei Y < X ist. In manchen Ausführungsbeispielen erhöhen mehrere Ereignismarker, die von mehreren anderen mit DSRC ausgestatteten Einrichtungen empfangen werden, die Genauigkeit für die Ausführungsfrist 151 oder erhöhen die Konfidenz bzw. Zuverlässigkeit des Aktualisierungssystems 199 bei der Ausführungsfrist 151.
Die Ausführungsfrist 151 kann durch die Variable T_E' dargestellt werden, der ein Wert zugewiesen wird (zum Beispiel eine Zeit für die harte Frist), der durch die Ausführungsfrist 151 beschrieben ist.
Bezugnehmend nun auf 1D ist ein Blockdiagramm dargestellt, das Ressourcenbeschränkungsdaten 146 gemäß manchen Ausführungsbeispielen darstellt.
Der FPGA-Maximalleistungsverbrauch 152 sind digitale Daten, die einen maximal erlaubten Leistungsverbrauch für das FPGA 184 beschreiben. In manchen Ausführungsbeispielen setzt der FPGA-Maximalleistungsverbrauch 152 eine Grenze, wie schnell das FPGA 184 rekonfiguriert werden kann, da das FPGA 184 schneller rekonfiguriert werden kann, wenn es erlaubt ist, dass mehr Leistung verbraucht wird. In manchen Ausführungsbeispielen setzt der FPGA-Maximalleistungsverbrauch 152 eine Grenze dahingehend, ob eine Implementierungsentscheidung diejenige sein kann, die Funktionsaktualisierung über FPGA 184 zu implementieren, da dies verursachen kann, dass die Operation des FPGA 184 den maximal erlaubten Leistungsverbrauch für das FPGA 184 überschreitet, was angibt, dass die Implementierungsentscheidung sein sollte, die Funktionsaktualisierung als eine Softwareaktualisierung zu implementieren.
Der FPGA-Maximalleistungsverbrauch 152 kann durch die Variable P_EF' dargestellt werden, der ein Wert zugewiesen wird (zum Beispiel ein Betrag von Watt oder einer anderen Einheit einer Leistung), der durch den FPGA-Maximalleistungsverbrauch 152 beschrieben wird.
Der FPGA-Maximalbereich 153 sind digitale Daten, die einen maximal erlaubten Bereich beschreiben, der zur Rekonfiguration verfügbar ist, wenn das FPGA 184 rekonfiguriert wird, um die Funktionsaktualisierung zu implementieren. In manchen Ausführungsbeispielen setzt der FPGA-Maximalbereich 153 eine Grenze dahingehend, ob eine Implementierungsentscheidung diejenige sein kann, die Funktionsaktualisierung über FPGA 184 zu implementieren, da dies eine Rekonfiguration eines größeren Bereichs des FPGA 184 erfordern könnte, als durch den FPGA-Maximalbereich 153 erlaubt ist, was angibt, dass die Implementierungsentscheidung diejenige sein sollte, die Funktionsaktualisierung als eine Softwareaktualisierung zu implementieren.
Der FPGA-Maximalbereich 153 kann durch die Variable A_EF' dargestellt werden, der ein Wert zugewiesen wird (zum Beispiel ein Bereich), der durch den FPGA-Maximalbereich 153 beschrieben wird.
Bezugnehmend nun auf 1E ist ein Blockdiagramm dargestellt, das die Schätzzeitdaten 147 gemäß manchen Ausführungsbeispielen darstellt.
Die Schätzserverentscheidungszeit 154 sind digitale Daten, die eine Schätzung des Zeitbetrags beschreiben, die für das Aktualisierungssystem 199 des Servers 103 notwendig ist, um die Implementierungsentscheidung vorzunehmen.
Die Schätzserverentscheidungszeit 154 kann durch die Variable T_DO dargestellt werden, der ein Wert zugewiesen wird (zum Beispiel ein Zeitbetrag), der durch die Schätzserverentscheidungszeit 154 beschrieben wird.
Die Schätzfahrzeugentscheidungszeit 155 sind digitale Daten, die eine Schätzung eines Zeitbetrags beschreiben, der für das Aktualisierungssystem 199 des Fahrzeugs 123 notwendig ist, um die Implementierungsentscheidung vorzunehmen.
Die Schätzfahrzeugentscheidungszeit 155 wird durch die Variable T_DE dargestellt, der ein Wert zugewiesen wird (zum Beispiel ein Zeitbetrag), der durch die Schätzfahrzeugentscheidungszeit 155 beschrieben wird.
Die geschätzte Zeit zur Aktualisierung über Software 156 sind digitale Daten, die eine Schätzung des Zeitbetrags beschreiben, die notwendig sein wird, um eine oder mehrere der folgenden Aufgaben zu vollenden: Herunterladen der Aktualisierungsdaten 191 auf das Fahrzeug 123 von dem Server 103 über das Netzwerk 105, wenn die Funktionsaktualisierung über eine Softwareaktualisierung implementiert wird; und die ausführbare Datei, die durch die Aktualisierungsdaten 191 beschrieben wird, vollständig zu installieren, sodass die ausführbare Datei in dem Fahrzeug 123 installiert ist (das heißt, in den ADAS-Daten 194 installiert ist).
Zum Beispiel beschreibt die geschätzte Zeit zur Aktualisierung über Software 156 einen Zeitbetrag zum Herunterladen der Aktualisierungsdaten 192 von dem Server 103 auf das Fahrzeug 123 über das Netzwerk 105. In manchen Ausführungsbeispielen ist die geschätzte Zeit zur Aktualisierung über die Software 156 digitale Daten, die eine Größe der Softwareinstallation (zum Beispiel die Größe der ausführbaren Datei) über die bzw. entsprechend der Geschwindigkeit der Softwareinstallation (zum Beispiel wie schnell die ausführbare Datei vollständig ausgeführt werden kann) beschreiben.
Die geschätzte Zeit zur Aktualisierung über Software156 kann durch die Variable T_US dargestellt werden, der einen Wert zugewiesen wird (zum Beispiel einen Zeitbetrag), der durch die geschätzte Zeit zur Aktualisierung über Software 156 beschrieben wird.
Die geschätzte Zeit zur Aktualisierung über FPGA 157 sind digitale Daten, die eine Schätzung des Zeitbetrags beschreiben, der notwendig sein wird, um eine oder mehrere der folgenden Aufgaben zu vollenden: einen Bitstrom inklusive der Aktualisierungsdaten 191 an das Fahrzeug 123 von dem Server 103 über das Netzwerk 105 zu übertragen, wenn die Funktionsaktualisierung durch Rekonfigurieren des FPGA 184 implementiert wird; und das FPGA 184 basierend auf den Aktualisierungsdaten 191 zu rekonfigurieren, sodass die Funktionsaktualisierung in dem Fahrzeug 123 installiert wird.
Die geschätzte Zeit zur Aktualisierung über FPGA 157 kann durch die Variable T_UF dargestellt werden, der einen Wert zugewiesen wird (zum Beispiel einen Zeitbetrag), der durch die geschätzte Zeit zur Aktualisierung über FPGA 157 beschrieben wird. In manchen Ausführungsbeispielen beschreibt die geschätzte Zeit zur Aktualisierung über FPGA 157 eine Größe der FPGA-Konfiguration über eine bzw. entsprechend einer Geschwindigkeit der FPGA-Konfiguration. In manchen Ausführungsbeispielen ist die folgende Bedingung allgemein, aber nicht immer wahr: T_UF > T_US.
Die geschätzte Ausführungszeit für Software 158 sind digitale Daten, die eine Schätzung des Zeitbetrags beschreiben, der zum Ausführen der Funktionsaktualisierung notwendig sein wird, nachdem diese in dem Fahrzeug 123 installiert ist. Zum Beispiel beschreibt die geschätzte Ausführungszeit für Software 158 den Zeitbetrag, der notwendig ist, um die ADAS-Daten 194 vollständig auszuführen, nachdem die ausführbare Datei, die durch die Aktualisierungsdaten 191 beschrieben ist, in den ADAS-Daten 194 installiert ist (oder die ADAS-Daten 194 ersetzt). In manchen Ausführungsbeispielen ist die geschätzte Ausführungszeit für Software 158 eine normierte Ausführungszeit für die ausführbare Datei multipliziert mit einer Skalierung. In manchen Ausführungsbeispielen ist die Skalierung variabel, in Abhängigkeit der Art der Hardware, auf der die Funktionsaktualisierung innerhalb des Fahrzeugs 123 eingesetzt wird.
Die geschätzte Ausführungszeit für Software 158 kann durch die Variable T_ES dargestellt werden, der ein Wert zugewiesen wird (zum Beispiel ein Zeitbetrag), der durch die geschätzte Ausführungszeit für Software 158 beschrieben wird.
Die geschätzte Ausführungszeit für FPGA 159 sind digitale Daten, die eine Schätzung des Zeitbetrags beschreiben, der zum Ausführen der Funktionsaktualisierung notwendig sein wird, nachdem das FPGA 184 basierend auf den Aktualisierungsdaten 191 (welche über einen Bitstrom geliefert werden können) rekonfiguriert ist. Zum Beispiel beschreibt die geschätzte Ausführungszeit für FPGA 159 den Zeitbetrag, der notwendig ist, um das rekonfigurierte FPGA 159 vollständig auszuführen, nachdem die Funktionsaktualisierung implementiert wird. In manchen Ausführungsbeispielen ist die geschätzte Ausführungszeit für FPGA 159 eine normierte Ausführungszeit für das rekonfigurierte FPGA 184 multipliziert mit einer Skalierung. In manchen Ausführungsbeispielen ist die Skalierung in Abhängigkeit von unterschiedlichen Eigenschaften des FPGA 184 variabel.
Die geschätzte Ausführungszeit für FPGA 159 kann durch die Variable T_EF dargestellt werden, der einem Wert zugewiesen wird (zum Beispiel ein Zeitbetrag), der durch die geschätzte Ausführungszeit für FPGA 159 beschrieben wird. In manchen Ausführungsbeispielen ist die folgende Bedingung allgemein, aber nicht immer wahr: T_EF < T_ES.
Bezugnehmend nun auf 1F ist ein Blockdiagramm dargestellt, das Schätzverbrauchsdaten 148 gemäß manchen Ausführungsbeispielen darstellt.
Der geschätzte Leistungsverbrauch für FPGA 160 sind digitale Daten, die eine Schätzung des Betrags einer Leistung beschreiben, die notwendig ist, um das FPGA 184 auszuführen, nachdem dieses basierend auf den Aktualisierungsdaten 191 rekonfiguriert ist.
Der geschätzte Leistungsverbrauch für FPGA 160 kann durch die Variable P_EF dargestellt werden, der einen Wert zugewiesen wird (zum Beispiel Betrag einer Leistung), der durch den geschätzten Leistungsverbrauch für FPGA 160 beschrieben wird.
Der geschätzte Bereich für FPGA 161 sind digitale Daten, die eine Schätzung des Betrags eines Bereichs des FPGA 184 beschreiben, der rekonfiguriert werden muss, um die Funktionsaktualisierung, die durch die Aktualisierungsdaten 191 beschrieben ist, zu implementieren.
Der geschätzte Bereich für FPGA 161 kann durch die Variable A_EF dargestellt werden, der einen Wert zugewiesen wird (zum Beispiel ein Bereich), der durch den geschätzten Bereich für FPGA 161 beschrieben wird.
Bezugnehmend nun auf 1G ist ein Blockdiagramm dargestellt, das Entscheidungsdaten 192 gemäß manchen Ausführungsbeispielen darstellt. In manchen Ausführungsbeispielen sind die Entscheidungsdaten 192 digitale Daten, die Variablen und Werte, die diesen Variablen zugewiesen sind, beschreiben, basierend auf den relativen Werten der unterschiedlichen Elemente der Systemdaten 190, die in 1G dargestellt sind.
Bezugnehmend nun auf 1H ist ein Blockdiagramm dargestellt, das Analysedaten 193 gemäß manchen Ausführungsbeispielen darstellt. In manchen Ausführungsbeispielen sind die Analysedaten 193 digitale Daten, die die möglichen Implementierungsentscheidungen beschreiben, die durch das Aktualisierungssystem 199 basierend auf den Variablen und den Werten, die mit Bezug auf die Entscheidungsdaten 192 und die Systemdaten 190 zugewiesen sind, vorgenommen werden. In manchen Ausführungsbeispielen wird die tatsächliche Implementierungsentscheidung, die durch das Aktualisierungssystem 199 vorgenommen wird, immer durch die Analysedaten 193 in Abhängigkeit der Anwendung der Entscheidungsdaten 192 auf die Systemdaten 190 beschrieben.
Bezugnehmend nun auf 1I ist ein Blockdiagramm dargestellt, das eine Fahrbahnumgebung 166 gemäß manchen Ausführungsbeispielen darstellt.
Bezugnehmend nun auf 2 ist ein Blockdiagramm dargestellt, das ein Beispiel eines Computersystems 200 inklusive eines Aktualisierungssystems 199 gemäß manchen Ausführungsbeispielen darstellt.
In manchen Ausführungsbeispielen kann das Computersystem 200 ein Spezialzweckcomputersystem umfassen, das dazu programmiert ist, um einen oder mehrere Schritte eines Verfahrens 300, das nachstehend mit Bezug auf 3A bis 3C beschrieben ist, durchzuführen.
In manchen Ausführungsbeispielen kann das Computersystem 200 ein Element von einer oder mehreren der folgenden Einrichtungen sein: des Fahrzeugs 123; des Servers 103; der RSU 104; und des entfernten Fahrzeugs 124.
In manchen Ausführungsbeispielen kann das Computersystem 200 ein fahrzeugseitiger Fahrzeugcomputer einer Einrichtung, wie etwa einer oder mehreren der folgenden sein: des Fahrzeugs 123; des Servers 103, der RSU 104 und des entfernten Fahrzeugs 124.
In manchen Ausführungsbeispielen kann das Computersystem 200 eine Maschinensteuerungseinheit, eine Haupteinheit oder manch andere prozessorbasierte Rechnereinrichtung des Fahrzeug 123 oder des entfernten Fahrzeugs 124 umfassen.
Das Computersystem 200 kann eines oder mehrere der folgenden Elemente gemäß manchen Beispielen umfassen: das Aktualisierungssystem 199; den Prozessor 125; die Kommunikationseinheit 145; den Sensorsatz 182; die DSRC-konforme GPS-Einheit 170; das ADAS-System 180; den Speicher 127; die ECU 183; und das FPGA 184. Die Komponenten des Computersystems 200 sind durch einen Bus 220 kommunikativ gekoppelt.
In dem dargestellten Ausführungsbeispiel ist der Prozessor 125 mit dem Bus 220 über eine Signalleitung 238 kommunikativ gekoppelt. Die Kommunikationseinheit 145 ist mit dem Bus 220 über eine Signalleitung 246 kommunikativ gekoppelt. Der Sensorsatz 182 ist mit dem Bus 220 über eine Signalleitung 248 kommunikativ gekoppelt. Die DSRC-konforme GPS-Einheit 170 ist mit dem Bus 220 über eine Signalleitung 249 kommunikativ gekoppelt. Das ADAS-System 180 ist mit dem Bus 220 über eine Signalleitung 239 kommunikativ gekoppelt. Der Speicher 127 ist mit dem Bus 220 über eine Signalleitung 244 kommunikativ gekoppelt. Die ECU 183 ist mit dem Bus 220 über eine Signalleitung 241 kommunikativ gekoppelt. Das FPGA 184 ist mit dem Bus 220 über eine Signalleitung 243 kommunikativ gekoppelt.
Die folgenden Elemente des Computersystems 200 wurden vorstehend mit Bezug auf 1A beschrieben, sodass deren Beschreibungen hier nicht wiederholt werden: das Aktualisierungssystem 199; der Prozessor 125 (dessen Beschreibung die gleiche ist, wie die des Prozessors 125A); die Kommunikationseinheit 145 (deren Beschreibung die gleiche ist, wie die der Kommunikationseinheit 145A); der Sensorsatz 182; die DSRC-konforme GPS-Einheit 170; das ADAS-System 180; der Speicher 127 (dessen Beschreibung die gleiche ist, wie die des Speichers 127A); der ECU 183; und das FPGA 184.
Der Speicher 127 speichert irgendwelche oder alle der Daten, die vorstehend mit Bezug auf 1A bis 1I und nachstehend mit Bezug auf 3A bis 3C, 4A und 4B beschrieben sind.
In dem dargestellten Ausführungsbeispiel, das in 2 gezeigt ist, umfasst das Aktualisierungssystem 199 ein Kommunikationsmodul 202, das mit dem Bus 220 kommunikativ gekoppelt ist. In manchen Ausführungsbeispielen können Komponenten des Aktualisierungssystems 199 in einem einzelnen Server oder einer Einrichtung gespeichert sein. In manch anderen Ausführungsbeispielen können Komponenten des Aktualisierungssystems 199 über mehrere Server oder Einrichtungen verteilt und gespeichert sein. Zum Beispiel können manche der Komponenten des Aktualisierungssystems 199 über den Server 103 und das Fahrzeug 123 verteilt sein.
Das Kommunikationsmodul 202 kann Software sein, inklusive Routinen zum Handhaben von Kommunikationen zwischen dem Aktualisierungssystem 199 und anderen Komponenten des Computersystems 200. In manchen Ausführungsbeispielen kann das Kommunikationsmodul 202 ein Satz von Anweisungen sein, der durch den Prozessor 125 ausführbar ist, um die nachstehend beschriebene Funktionalität zum Handhaben von Kommunikationen zwischen dem Aktualisierungssystem 199 und anderen Komponenten des Computersystems 200 bereitzustellen.
Das Kommunikationsmodul 202 sendet und empfängt Daten über die Kommunikationseinheit 145 an die und von einem oder mehreren Elementen der Operationsumgebung 100 oder des Ablaufprozesses 111. Zum Beispiel empfängt oder überträgt das Kommunikationsmodul 202 über die Kommunikationseinheit 145 manche oder alle der Daten, die vorstehend mit Bezug auf 1A bis 1I, 3A bis 3C und 4A und 4B beschrieben sind.
In manchen Ausführungsbeispielen empfängt das Kommunikationsmodul 202 Daten von Komponenten des Aktualisierungssystems 199 und speichert die Daten in dem Speicher 127. Zum Beispiel empfängt das Kommunikationsmodul 202 eine BSM-Mitteilung inklusive der BSM-Daten 195 und speichert die BSM-Daten 195 in dem Speicher 127.
In manchen Ausführungsbeispielen kann das Kommunikationsmodul 202 Kommunikationen zwischen Komponenten des Aktualisierungssystems 199 handhaben. Zum Beispiel kann das Kommunikationsmodul 202 Daten von dem Speicher 127 abrufen, die dann durch das Aktualisierungssystem 199 analysiert oder verarbeitet werden, wie nachstehend mit Bezug auf 3A bis 3C beschrieben ist.
In manchen Ausführungsbeispielen kann das Kommunikationsmodul 202 in dem Speicher 127 des Computersystems 200 gespeichert sein und kann durch den Prozessor 125 zugreifbar und ausführbar sein. Das Kommunikationsmodul 202 kann zur Kooperation und Kommunikation mit dem Prozessor 125A und anderen Komponenten des Computersystems 200 über die Signalleitung 222 angepasst sein.
Bezugnehmend nun auf 3A bis 3C ist ein Ablaufdiagramm eines Beispiels eines Verfahrens 300 zum Vornehmen einer Implementierungsentscheidung gemäß manchen Ausführungsbeispielen dargestellt. Einer oder mehrere der Schritte, die hierin für das Verfahren 300 beschrieben sind, können durch eines oder mehrere Aktualisierungssysteme ausgeführt werden.
In Schritt 301 wird eine Funktionsaktualisierung für eines oder mehrere ADAS-Systeme des ADAS-Systemsatzes eingestellt.
In Schritt 303 werden Systemdaten zum Vornehmen einer Implementierungsentscheidung gesammelt oder angehäuft. Eine Implementierungsentscheidung ist eine Analyse der Systemdaten (siehe zum Beispiel 1B) angesichts der Entscheidungsdaten (siehe zum Beispiel 1G) und der Analysedaten (siehe zum Beispiel 1H), um zu bestimmen, ob die Funktionsaktualisierung über eine Softwareaktualisierung oder eine Rekonfiguration eines FPGA implementiert wird.
In Schritt 305 wird eine Bestimmung dahingehend vorgenommen, ob die Implementierungsentscheidung durch das Fahrzeug oder den Server vorgenommen wird. Wenn zum Beispiel T_DO ≥ T_DE, dann nimmt das Fahrzeug die Implementierungsentscheidung vor und das Verfahren 300 geht über zu Schritt 307 von 3B. Ansonsten nimmt der Server die Implementierungsentscheidung vor und das Verfahren 300 geht über zu Schritt 306 von 3C.
Nun wird auf 3B Bezug genommen. In Schritt 307 nimmt das Aktualisierungssystem des Fahrzeugs die Implementierungsentscheidung vor, basierend auf: (1) den Systemdaten; (2) den Entscheidungsdaten; und (3) den Analysedaten. Wenn die Implementierungsentscheidung diejenige ist, die Funktionsaktualisierung über eine Softwareaktualisierung vorzunehmen, geht das Verfahren 300 über zu Schritt 309. Wenn die Implementierungsentscheidung diejenige ist, die Funktionsaktualisierung durch eine Rekonfiguration des FPGA vorzunehmen, dann geht das Verfahren 300 über zu Schritt 313. Wenn die Implementierungsentscheidung diejenige ist, dass die Funktionsaktualisierung nicht praktikabel bzw. nicht ausführbar ist, geht das Verfahren 300 über zu Schritt 317.
In Schritt 309 veranlasst das Aktualisierungssystem des Fahrzeugs die Kommunikationseinheit des Fahrzeugs dazu, eine Anforderung für Aktualisierungsdaten an den Server über das Netzwerk zu übertragen. Die Aktualisierungsdaten beschreiben eine ausführbare Datei, die betriebsfähig ist, wenn diese durch den Prozessor des Fahrzeugs ausgeführt wird, um die Funktionsaktualisierung zu implementieren.
In Schritt 311 wird eine drahtlose Mitteilung inklusive der Aktualisierungsdaten durch die Kommunikationseinheit des Fahrzeugs empfangen und die ausführbare Datei, die durch die Aktualisierungsdaten beschrieben ist, wird ausgeführt, um die Funktionsaktualisierung zu installieren.
In Schritt 313 veranlasst das Aktualisierungssystem des Fahrzeugs die Kommunikationseinheit des Fahrzeugs dazu, eine drahtlose Mitteilung an den Server über das Netzwerk zu übertragen, die Aktualisierungsdaten anfordert, die in manchen Ausführungsbeispielen über einen Datenstrom bereitgestellt werden, die beschreiben, wie das FPGA zu rekonfigurieren ist, um die Funktionsaktualisierung zu implementieren.
In Schritt 315 wird der Bitstrom durch die Kommunikationseinheit des Fahrzeugs empfangen und wird das FPGA durch das Aktualisierungssystem basierend auf den Aktualisierungsdaten, die in dem Bitstrom enthalten sind, rekonfiguriert.
In Schritt 317 veranlasst das Aktualisierungssystem eine elektronische Anzeige, eine HUD oder 3D-HUD des Fahrzeugs, eine Fehlermitteilung auszugeben.
Nun wird auf 3C Bezug genommen. In Schritt 321 nimmt das Aktualisierungssystem des Servers die Implementierungsentscheidung vor, basierend auf: (1) den Systemdaten; (2) den Entscheidungsdaten; und (3) den Analysedaten. Wenn die Implementierungsentscheidung diejenige ist, die Funktionsaktualisierung über eine Softwareaktualisierung vorzunehmen, dann geht das Verfahren 300 über zu Schritt 323. Wenn die Implementierungsentscheidung diejenige ist, die Funktionsaktualisierung durch Rekonfiguration des FPGA vorzunehmen, dann geht das Verfahren 300 über zu Schritt 325. Wenn die Implementierungsentscheidung diejenige ist, dass die Funktionsaktualisierung nicht praktikabel bzw. nicht ausführbar ist, dann geht das Verfahren 300 über zu Schritt 327.
In Schritt 323 veranlasst das Aktualisierungssystem des Servers die Kommunikationseinheit des Servers dazu, an das Fahrzeug über das Netzwerk Aktualisierungsdaten zu übertragen, die eine ausführbare Datei beschreiben, die betriebsfähig ist, wenn diese durch den Prozessor des Fahrzeugs ausgeführt wird, um die Funktionsaktualisierung zu implementieren.
In Schritt 325 veranlasst das Aktualisierungssystem des Servers die Kommunikationseinheit des Servers dazu, einen Bitstrom mit der Kommunikationseinheit des Fahrzeugs herzustellen, und dann über den Bitstrom die Aktualisierungsdaten an die Kommunikationseinheit des Fahrzeugs zu übertragen.
In Schritt 327 veranlasst das Aktualisierungssystem des Servers die Kommunikationseinheit des Servers dazu, über das Netzwerk ein elektronisches Signal (oder eine elektronische Mitteilung) an die Kommunikationseinheit des Fahrzeugs zu übertragen, die die elektronische Anzeige des Fahrzeugs veranlasst, eine Fehlermitteilung anzuzeigen.
Bezugnehmend nun auf 4A ist ein Blockdiagramm dargestellt, das ein Beispiel der BSM-Daten 195 gemäß manchen Ausführungsbeispielen darstellt.
Das regelmäßige Intervall zum Übertragen von BSMs kann durch den Benutzer konfigurierbar sein. In manchen Ausführungsbeispielen kann eine Standardeinstellung für dieses Intervall ein Übertragen der BSM alle 0,10 Sekunden oder im Wesentlichen alle 0,10 Sekunden sein.
Eine BSM wird über das 5,9 GHz DSRC-Band rundgesendet. Der DSRC-Bereich kann im Wesentlichen 1000 Meter sein. In manchen Ausführungsbeispielen kann der DSRC-Bereich einen Bereich von im Wesentlichen 100 Metern bis im Wesentlichen 1000 Metern umfassen.
Bezugnehmend nun auf 4B ist ein Blockdiagramm dargestellt, das ein Beispiel von BSM-Daten 195 gemäß manchen Ausführungsbeispielen darstellt.
Eine BSM kann zwei Teile umfassen. Diese zwei Teile können unterschiedliche BSM-Daten 195 umfassen, wie in 4B dargestellt ist.
Teil 1 der BSM-Daten 195 kann eines oder mehrere der Folgenden beschreiben: eine Fahrzeugposition; eine Fahrzeugrichtung; eine Fahrzeuggeschwindigkeit; eine Fahrzeugbeschleunigung; einen Fahrzeuglenkradwinkel und eine Fahrzeuggröße.
Ein Teil 2 der BSM-Daten 195 kann einen variablen Satz von Datenelementen umfassen, die von einer Liste von optionalen Elementen ausgewählt werden. Manche der BSM-Daten 195, die in dem Teil 2 der BSM enthalten sind, werden basierend auf Ereignisauslösern ausgewählt, zum Beispiel kann eine Aktivierung eines Antiblockiersystems („ABS“) BSM-Daten 195 auslösen, die für das ABS-System des Fahrzeugs relevant sind.
In manchen Ausführungsbeispielen werden manche der Elemente von Teil 2 weniger oft übertragen, um eine Bandbreite einzusparen.
In manchen Ausführungsbeispielen umfassen die BSM-Daten 195, die in einer BSM enthalten sind, momentane Schnappschüsse eines Fahrzeugs, das entlang einem Fahrbahnsystem fährt.
In der vorstehenden Beschreibung wurden zum Zweck der Erklärung zahlreiche spezifische Details dargelegt, um ein volles Verständnis der Spezifikation bereitzustellen. Es wird jedoch durch den Fachmann anerkannt, dass die Offenbarung ohne diese spezifischen Details praktiziert werden kann. In manchen Fällen sind Strukturen und Einrichtungen in Blockdiagrammform gezeigt, um eine Unklarheit der Beschreibung zu vermeiden. Zum Beispiel können die vorliegenden Ausführungsbeispiele, die vorstehend beschrieben sind, hauptsächlich mit Bezug auf Benutzerschnittstellen und bestimmte Hardware beschrieben werden. Jedoch können die vorliegenden Ausführungsbeispiele auf irgendeine Art eines Computersystems, das Daten und Anweisungen empfangen kann, und irgendeine periphere Einrichtung, die Dienste bereitstellt, angewendet werden.
Eine Bezugnahme in der Spezifikation auf „manche Ausführungsbeispiele“ oder „manche Fälle“ bedeutet, dass ein bestimmtes Merkmal, Struktur oder Charakteristik, die in Verbindung mit Ausführungsbeispielen oder Fällen beschrieben ist, in zumindest einem Ausführungsbeispiel der Erfindung enthalten sein kann. Das Erscheinen des Ausdrucks „in manchen Ausführungsbeispielen“ an verschiedenen Stellen in der Spezifikation betrifft nicht notweniger Weise die gleichen Ausführungsbeispiele.
Manche Abschnitte der detaillierten Beschreibungen, die folgen, sind hinsichtlich des Algorithmus und symbolischen Darstellungen von Operationen bezüglich Datenbits innerhalb eines Computerspeichers präsentiert. Diese algorithmischen Beschreibungen und Darstellungen sind die Mittel, die durch den Fachmann in dem Bereich der Datenverarbeitung verwendet werden, um die Substanz ihrer Arbeit den anderen Fachmännern darzulegen. Ein Algorithmus wird hier und im Allgemeinen als eine in sich stimmige Abfolge von Schritten betrachtet, die zu einem gewünschten Ergebnis führt. Die Schritte sind die, die eine physikalische Manipulation von physikalischen Größen erfordert. Üblicherweise, obwohl es nicht notwendig ist, nehmen diese Größen die Form von elektrischen oder magnetischen Signalen an, die dazu in der Lage sind, gespeichert, übertragen, kombiniert, verglichen und anderweitig manipuliert zu werden. Es hat sich zeitweise als komfortabel erwiesen, prinzipiell aus Gründen der üblichen Verwendung, auf diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Ausdrücke, Zahlen oder Ähnliches zu verweisen.
Es sollte jedoch berücksichtigt werden, dass all diese und ähnliche Ausdrücke mit geeigneten physikalischen Größen zu verknüpfen sind und lediglich angenehme Bezeichnungen sind, die auf diese Größen angewendet werden. Solange es nicht anderweitig dargelegt ist, wie von der folgenden Diskussion offensichtlich ist, wird anerkannt, dass in der gesamten Beschreibung Diskussionen unter Verwendung der Ausdrücke, die „Verarbeiten“ oder „Rechnen“ oder „Berechnen“ oder „Bestimmen“ oder „Anzeigen“ oder Ähnliches umfassen, auf die Aktion und Prozesse eines Computersystems oder einer ähnlichen elektronischen Rechnereinrichtung Bezug nehmen, die Daten manipuliert und transformiert, die als physikalische (elektronische) Größen innerhalb des Computersystemregisters und -speichers dargestellt sind, in andere Daten, die auf ähnliche Weise als physikalische Größen innerhalb des Computersystemspeichers oder -registers dargestellt sind, oder andere solche Informationsspeicher, Übertragung oder Anzeigeeinrichtungen.
Die vorliegenden Ausführungsbeispiele der Spezifikation können sich ebenso auf eine Vorrichtung zum Durchführen der Operationen hierin beziehen. Diese Vorrichtung kann für den erforderlichen Zweck speziell konstruiert sein oder kann ein Allzweckcomputer sein, der selektiv aktiviert und durch ein Computerprogramm, das in dem Computer gespeichert ist, rekonfiguriert wird. Solch ein Computerprogramm kann in einem computerlesbaren Speichermedium aufgezeichnet werden, das umfasst, aber nicht beschränkt ist auf, irgendeine Art einer Platte, inklusive Disketten, optischen Disketten, CD-ROMs und magnetischen Platten, Festwertspeichern (ROMs), Direktzugriffspeichern (RAMs), EPROMs, EEPROMs, magnetische oder optische Karten, Flashspeicher inklusive USB-Sticks mit einem nichtflüchtigen Speicher, oder irgendeine andere Art von Medien, die zum Speichern von elektronischen Anweisungen geeignet sind, die jeweils mit einem Computersystembus gekoppelt sind.
Die Spezifikation kann die Form von manchen ganzheitlichen Hardwareausführungsbeispielen, manchen ganzheitlichen Softwareausführungsbeispielen oder manchen Ausführungsbeispielen, die sowohl Hardware als auch Softwareelemente umfassen, annehmen. In solchen bevorzugten Ausführungsbeispielen wird die Spezifikation in Software implementiert, die zum Beispiel umfasst aber nicht beschränkt ist auf, Firmware, Betriebssoftware (resident software), Microcode usw.
Des Weiteren kann die Beschreibung die Form eines Computerprogrammprodukts annehmen, das von einem computerverwendbaren oder computerlesbaren Medium zugreifbar ist, das einen Programmcode bereitstellt zur Verwendung durch oder in Verbindung mit einem Computer oder irgendeinem Anweisungsausführungssystem. Zum Zweck dieser Beschreibung kann ein computerverwendbares oder computerlesbares Medium irgendeine Vorrichtung sein, die das Programm speichern, kommunizieren, propagieren oder transportieren kann, zur Verwendung durch oder in Verbindung mit dem Anweisungsausführungssystem, der Vorrichtung oder Einrichtung.
Ein Datenverarbeitungssystem, das zum Speichern oder Ausführen von Programmcode geeignet ist, wird zumindest einem Prozessor, der direkt oder indirekt mit Speicherelementen durch einen Systembus verbunden ist, umfassen. Die Speicherelemente können einen lokalen Speicher umfassen, der während einer tatsächlichen Ausführung des Programmcodes eingesetzt wird, einen Massenspeicher und Cache-Speicher, die eine vorübergehende Speicherung von zumindest gewissen Programmcodes bereitstellen, um die Anzahl zu reduzieren, wie oft der Code von dem Massenspeicher während der Ausführung abgerufen werden muss.
Eingabe-/Ausgabeeinrichtungen oder I/O-Einrichtungen (inklusive aber nicht beschränkend auf Tastaturen, Anzeigen, Zeigereinrichtungen usw.) können mit dem System entweder direkt oder unter Verwendung von I/O-Steuerungen gekoppelt sein.
Netzwerkadapter können ebenso mit dem System gekoppelt sein, um dem Datenverarbeitungssystem zu ermöglichen, mit anderen Datenverarbeitungssystemen oder entfernten Druckern oder Speichereinrichtungen durch dazwischenliegende private oder öffentliche Netzwerke gekoppelt zu werden. Modems, ein Kabelmodem und Ethernetkarten sind nur ein paar der momentan verfügbaren Arten von Netzwerkadaptern.
Schließlich sind die hierin präsentierten Algorithmen und Anzeigen nicht inhärent auf irgendeinen bestimmten Computer oder irgendeine Vorrichtung bezogen. Verschiedene Mehrzwecksysteme können mit Programmen gemäß den hierin beschriebenen Lehren verwendet werden, oder es kann sich als vorteilhaft erweisen, spezialisierte Vorrichtungen zum Durchführen der erforderlichen Verfahrensschritte zu konstruieren. Die erforderliche Struktur für eine Vielzahl dieser Systeme wird von der nachstehenden bzw. vorstehenden Beschreibung in Erscheinung treten. Zusätzlich ist die Spezifikation nicht mit Bezug auf irgendeine bestimmte Programmiersprache beschrieben. Es ist anzuerkennen, dass eine Vielzahl von Programmiersprachen verwendet werden kann, um die Lehren der hierin beschriebenen Spezifikation zu implementieren.
Die vorgehende Beschreibung von Ausführungsbeispielen der Spezifikation wurde zum Zweck der Darstellung und Beschreibung präsentiert. Diese ist nicht dazu gedacht, erschöpfend zu sein oder die Spezifikation auf die präzise offenbarte Form zu beschränken. Viele Modifikationen und Variationen sind im Lichte der vorstehenden Lehre möglich. Es ist gedacht, dass der Umfang der Offenbarung nicht durch die detaillierte Beschreibung beschränkt ist, sondern durch die Ansprüche dieser Anmeldung. Wie durch den Fachmann verstanden wird, kann die Spezifikation auf andere spezifische Formen verkörpert werden, ohne sich vom Geist oder essentiellen Charakteristika von dieser zu entfernen. Auf ähnliche Weise sind die bestimmte Namensgebung und Aufteilung der Module, Routinen, Merkmale, Attribute, Methoden und andere Aspekte nicht zwingend oder signifikant, und die Mechanismen, die die Spezifikation oder deren Merkmale implementieren, können unterschiedliche Namen, Aufteilungen oder Formate aufweisen. Des Weiteren, wie für den Fachmann offensichtlich ist, können die Module, Routinen, Merkmale, Attribute, Methoden und andere Aspekte der Offenbarung als Software, Hardware, Firmware oder irgendeine Kombination von diesen dreien implementiert werden. Ebenso, wo auch immer eine Komponente, wie zum Beispiel ein Modul der Spezifikation als Software implementiert ist, kann die Komponente als ein eigenständiges Programm, als ein Teil eines größeren Programms, als eine Vielzahl von separaten Programmen, als eine statische oder dynamisch verlinkte Bibliothek, als ein Kernel-ladbares Modul, als ein Einrichtungstreiber, oder auf irgendeine andere bekannte Weise, die dem Fachmann für Computerprogrammierung jetzt oder in der Zukunft bekannt ist, verkörpert werden. Zusätzlich ist die Offenbarung in keiner Weise auf ein Ausführungsbeispiel in irgendeiner spezifischen Programmiersprache beschränkt, oder auf irgendein spezifisches Betriebssystem oder eine spezifische Umgebung. Dementsprechend ist die Offenbarung dazu gedacht, den Umfang der Spezifikation darzustellen und nicht zu beschränken, welcher in den folgenden Ansprüchen dargelegt ist.
Die Offenbarung umfasst Ausführungsbeispiele zum Implementieren einer Funktionsaktualisierung für ein fortgeschrittenes Fahrerassistenzsystem („ein ADAS-System“) eines Fahrzeugs. In manchen Ausführungsbeispielen umfasst das Verfahren, dass das Fahrzeug eine dedizierte Nahbereichskommunikationsmitteilung („eine DSRC-Mitteilung“) auf einem 5,9 Gigahertzband empfängt. Die DSRC-Mitteilung umfasst digitale Daten, die eine Fahrsituation von einem oder mehreren anderen Fahrzeugen in Relation zu dem Fahrzeug beschreiben. Das Verfahren umfasst ein Bestimmen, basierend auf der Fahrsituation, die durch die digitalen Daten beschrieben wird, die Funktionsaktualisierung für das ADAS-System durch Rekonfigurieren eines feldprogrammierbaren Gate-Arrays („ein FPGA“) des Fahrzeugs, das betriebsfähig ist, um eine Operation des ADAS-Systems zu steuern, zu implementieren. Das Verfahren umfasst ein Rekonfigurieren des FPGAs des Fahrzeugs, um die Funktionsaktualisierung zu implementieren, sodass das FPGA die Operation des ADAS-Systems auf solch eine Weise steuert, die der Funktionsaktualisierung entspricht.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 14471387 [0031, 0066, 0067, 0082]
US 15080433 [0039]

Claims

Verfahren, das eine Funktionsaktualisierung für ein fortgeschrittenes Fahrerassistenzsystem („ein ADAS-System“) eines Fahrzeugs implementiert, wobei das Verfahren aufweist: Empfangen einer dedizierten Nahbereichskommunikationsmitteilung („einer DSRC-Mitteilung“) auf einem 5,9 Gigahertz-Band, wobei die DSRC-Mitteilung digitale Daten umfasst, die eine Fahrsituation von einem oder mehreren anderen Fahrzeugen in Relation zu dem Fahrzeug beschreiben; Bestimmen, basierend auf der Fahrsituation, die durch die digitalen Daten beschrieben wird, die Funktionsaktualisierung für das ADAS-System durch Rekonfigurieren eines feldprogrammierbaren Gate-Arrays („eines FPGA“) des Fahrzeugs, das betriebsfähig ist, um eine Operation des ADAS-Systems zu steuern, zu implementieren; und Rekonfigurieren des FPGA des Fahrzeugs um die Funktionsaktualisierung zu implementieren, sodass das FPGA die Operation des ADAS-Systems auf eine Weise steuert, die der Funktionsaktualisierung entspricht.
Verfahren gemäß Anspruch 1, wobei die DSRC-Mitteilung eine Basissicherheitsmitteilung („eine BSM-Mitteilung“) ist und die digitalen Daten BSM-Daten sind.
Verfahren gemäß Anspruch 1 oder 2, wobei die DSRC-Mitteilung an das Fahrzeug durch eine straßenseitige Einheit („eine RSU“) übertragen wird.
Verfahren gemäß einem der Ansprüche 1 bis 3, wobei die digitalen Daten einen geografischen Ort des einen oder der mehreren anderen Fahrzeuge mit einer Genauigkeit von plus oder minus 1,5 Metern relativ zu einem tatsächlichen geografischen Ort des einen oder der mehreren anderen Fahrzeuge beschreiben.
Verfahren gemäß einem der Ansprüche 1 bis 4, wobei das FPGA ein Element einer elektronischen Steuerungseinheit des Fahrzeugs ist.
Verfahren gemäß einem der Ansprüche 1 bis 5, wobei das FPGA basierend auf Aktualisierungsdaten rekonfiguriert wird, die beschreiben, wie das FPGA zu rekonfigurieren ist, um die Funktionsaktualisierung zu implementieren.
Verfahren gemäß einem der Ansprüche 1 bis 6, wobei die Funktionsaktualisierung eine durch das ADAS-System bereitgestellte Funktionalität modifiziert.
System, das ein Fahrzeug umfasst, wobei das Fahrzeug aufweist: ein fortgeschrittenes Fahrerassistenzsystem („ein ADAS-System“); einen dedizierten Nahbereichskommunikationsempfänger („einen DSRC-Empfänger“); ein feldprogrammierbares Gate-Array („ein FPGA“); und ein fahrzeugseitiges Fahrzeugcomputersystem, das mit dem ADAS-System, dem DSRC-Empfänger und dem FPGA kommunikativ gekoppelt ist, wobei das fahrzeugseitige Fahrzeugcomputersystem einen nichtflüchtigen Speicher umfasst, der Computercode speichert, der, wenn dieser durch das fahrzeugseitige Fahrzeugcomputersystem ausgeführt wird, das fahrzeugseitige Fahrzeugcomputersystem veranlasst, um: durch den DSRC-Empfänger eine dedizierte Nahbereichskommunikationsmitteilung („eine DSRC-Mitteilung“) auf einem 5,9 Gigahertz-Band zu empfangen, wobei die DSRC-Mitteilung digitale Daten umfasst, die eine Fahrsituation von einem oder mehreren anderen Fahrzeugen in Relation zu dem Fahrzeug beschreiben; basierend auf der Fahrsituation, die durch die digitalen Daten beschrieben wird, zu bestimmen, eine Funktionsaktualisierung für das ADAS-System durch Rekonfigurieren des FPGA, das betriebsfähig ist, um eine Operation des ADAS-Systems zu steuern, zu implementieren; und das FPGA zu rekonfigurieren, um die Funktionsaktualisierung zu implementieren, sodass das FPGA die Operation des ADAS-Systems auf eine Weise steuert, die der Funktionsaktualisierung entspricht.
System gemäß Anspruch 8, wobei die DSRC-Mitteilung eine Basissicherheitsmitteilung („eine BSM-Mitteilung“) ist und die digitalen Daten BSM-Daten sind.
System gemäß Anspruch 8 oder 9, wobei die DSRC-Mitteilung an das Fahrzeug durch eine straßenseitige Einheit („eine RSU“) übertragen wird.
System gemäß einem der Ansprüche 8 bis 10, wobei die digitalen Daten einen geografischen Ort des einen oder der mehreren anderen Fahrzeuge mit einer Genauigkeit von plus oder minus 1,5 Metern relativ zu einem tatsächlichen geografischen Ort des einen oder der mehreren anderen Fahrzeuge beschreiben.
System gemäß einem der Ansprüche 8 bis 11, wobei das FPGA ein Element einer elektronischen Steuerungseinheit des Fahrzeugs ist.
System gemäß einem der Ansprüche 8 bis 12, wobei das FPGA basierend auf Aktualisierungsdaten rekonfiguriert wird, die beschreiben, wie das FPGA zu rekonfigurieren ist, um die Funktionsaktualisierung zu implementieren.
System gemäß einem der Ansprüche 8 bis 13, wobei die Funktionsaktualisierung eine durch das ADAS-System bereitgestellte Funktionalität modifiziert.
Computerprogrammprodukt mit einem nichtflüchtigen Speicher eines fahrzeugseitigen Fahrzeugcomputersystems eines Fahrzeugs, der computerausführbaren Code speichert, der, wenn dieser durch den Prozessor ausgeführt wird, den Prozessor veranlasst, um: durch den DSRC-Empfänger eine dedizierte Nahbereichskommunikationsmitteilung („eine DSRC-Mitteilung“) auf einem 5,9 Gigahertz-Band zu empfangen, wobei die DSRC-Mitteilung digitale Daten umfasst, die eine Fahrsituation von einem oder mehreren anderen Fahrzeugen in Relation zu dem Fahrzeug beschreiben; basierend auf der Fahrsituation, die durch die digitalen Daten beschrieben wird, zu bestimmen, eine Funktionsaktualisierung für das ADAS-System durch Rekonfigurieren des FPGA, das betriebsfähig ist, um eine Operation des ADAS-Systems zu steuern, zu implementieren; und das FPGA zu rekonfigurieren, um die Funktionsaktualisierung zu implementieren, sodass das FPGA die Operation des ADAS-Systems auf eine Weise steuert, die der Funktionsaktualisierung entspricht.
Computerprogrammprodukt gemäß Anspruch 15, wobei die DSRC-Mitteilung eine Basissicherheitsmitteilung („eine BSM-Mitteilung“) ist und die digitalen Daten BSM-Daten sind.
Computerprogrammprodukt gemäß Anspruch 15 oder 16, wobei die DSRC-Mitteilung an das Fahrzeug durch eine straßenseitige Einheit („eine RSU“) übertragen wird.
Computerprogrammprodukt gemäß einem der Ansprüche 15 bis 17, wobei die digitalen Daten einen geografischen Ort des einen oder der mehreren anderen Fahrzeuge mit einer Genauigkeit von plus oder minus 1,5 Metern relativ zu einem tatsächlichen geografischen Ort des einen oder der mehreren anderen Fahrzeuge beschreiben.
Computerprogrammprodukt gemäß einem der Ansprüche 15 bis 18, wobei das FPGA ein Element einer elektronischen Steuerungseinheit des Fahrzeugs ist.
Computerprogrammprodukt gemäß einem der Ansprüche 15 bis 19, wobei das FPGA basierend auf Aktualisierungsdaten rekonfiguriert wird, die beschreiben, wie das FPGA zu rekonfigurieren ist, um die Funktionsaktualisierung zu implementieren.