DE102018128274A1

DE102018128274A1 - Verfahren und vorrichtung zur wettermodellierung und fahrzeugunterbringung

Info

Publication number: DE102018128274A1
Application number: DE102018128274.5A
Authority: DE
Inventors: Perry Robinson MacNeille; Yimin Liu; David Charles Weber; Steven Joseph Szwabowski
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2017-11-14
Filing date: 2018-11-12
Publication date: 2019-05-16
Also published as: CN109781133A; US10423130B2; US20190146427A1

Abstract

Ein System beinhaltet einen Prozessor, der dazu konfiguriert ist, Wetterdaten zu empfangen, die eine Vielzahl von gemessenen Datenpunkten in einem Gebiet um ein Fahrzeug herum von einem entfernten Wetterserver beinhalten. Der Prozessor ist zudem dazu konfiguriert, einen Pfad von einem Fahrzeugteilsystem zu empfangen. Der Prozessor ist ferner dazu konfiguriert, die Datenpunkte und den Pfad zu kombinieren, um ein Vorhersagemodell zu bilden, das die erwarteten Wetterbedingungen entlang des Pfades zu zukünftigen Zeitpunkten wiedergibt, wobei das Modell auf vordefinierten Parametern basiert, die ein erwartetes Wetterverhalten definieren, und das Modell an ein eine Anforderung stellendes Fahrzeugteilsystem zu senden.

Description

GEBIET DER TECHNIK
Die veranschaulichenden Ausführungsformen betreffen im Allgemeinen Verfahren und Vorrichtung zur Wettermodellierung und Fahrzeugunterbringung.
ALLGEMEINER STAND DER TECHNIK
Wetter und Verkehr waren schon immer ein Verhängnis für Reisende, da sie zu Verspätungen, Routenänderungen und sogar Gefahrensituationen führen können. Ferner kann zum Beispiel ein Benutzer, der zu einem Zielort im Freien unterwegs ist, ein hohes Interesse daran haben, sicherzugehen, dass an dem Zielort angenehmes Wetter herrscht.
Wettervorhersagedienste und -modelle wurden im Laufe der Jahre verbessert, stützen sich jedoch typischerweise noch auf endliche, durch feste Positionen gesammelte Datenpunkte sowie auf Extrapolation von Wetterdaten basierend auf den an den festen Positionen gesammelten Datenpunkten. Obgleich Wetterdaten für ein Fahrzeug verfügbar und anpassbar sein können, sind sie aufgrund von intermittierenden Fahrzeug-Cloud-Verbindungen häufig nicht verfügbar. Fahrzeuge können einige Sensoren beinhalten, die das Sammeln von Daten ermöglichen, der Einbau umfangreicher Sensoren in Fahrzeuge kann jedoch die Kosten eines Fahrzeugs deutlich erhöhen, und da die gesammelten Daten genauso nützlich für andere sind wie für den Fahrer (da sich der Fahrer bereits bei dem Wetter befindet und somit davon betroffen ist), haben die Nutzer wenig Interesse daran, einen Aufschlag für Fahrzeuge mit erweiterten Sensorfähigkeiten zu bezahlen.
KURZDARSTELLUNG
In einer ersten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, Wetterdaten zu empfangen, die eine Vielzahl von gemessenen Datenpunkten in einem Gebiet um ein Fahrzeug herum von einem entfernten Wetterserver beinhalten. Der Prozessor ist zudem dazu konfiguriert, einen Pfad von einem Fahrzeugteilsystem zu empfangen. Der Prozessor ist ferner dazu konfiguriert, die Datenpunkte und den Pfad zu kombinieren, um ein Vorhersagemodell zu bilden, das die erwarteten Wetterbedingungen entlang des Pfades zu zukünftigen Zeitpunkten wiedergibt, wobei das Modell auf vordefinierten Parametern basiert, die ein erwartetes Wetterverhalten definieren, und das Modell an ein anforderndes Fahrzeugteilsystem zu senden.
In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren die Modellierung einer Vielzahl von erwarteten Werten für einen Wetteraspekt basierend auf von einem Fernserver empfangenen gemessenen Datenpunkten und auf vordefinierten Modellierungsparametern, einschließlich des Variierens der vordefinierten Parameter, um die Vielzahl von erwarteten Werten zu erzeugen. Das Verfahren beinhaltet zudem Vergleichen eines in Echtzeit gemessenen Aspektwertes mit einem modellierten erwarteten Aspektwert für jeden der Vielzahl von erwarteten Werten und Auswählen eines modifizierten Parametersatzes, der dem erwarteten Wert entspricht, welcher die geringste Differenz von dem Echtzeit-Wert aufweist.
In einer dritten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, eine Vielzahl von Wetteraspekten über einen von einem Fahrzeugteilsystem empfangenen Fahrzeugweg basierend auf von einem Fernserver empfangenen gemessenen Datenpunkten und auf vordefinierten Modellierungsparametern zu modellieren. Der Prozessor ist zudem dazu konfiguriert, fahrzeuginterne Wettermodellparameter einzustellen, während ein Fahrzeug den Pfad entlangfährt, um ein Wettermodell beizubehalten, für das periodische Echtzeit-Messungen im Vergleich zu erwarteten Werten, die von dem Wettermodell erlangt wurden, unter einer Schwellenwertabweichung liegen.
Figurenliste

1 zeigt ein veranschaulichendes Fahrzeugrechensystem;
2 zeigt einen veranschaulichenden Prozess zur Fahrzeugsensordatenfreigabe;
3 zeigt ein veranschaulichendes Fahrzeug, das eine fahrzeuginterne Modellierungs- und Erfassungsfähigkeit beinhaltet;
4 zeigt einen veranschaulichenden Prozess für eine Wettermodellaktualisierung;
5 zeigt eine andere veranschaulichende Beziehung zwischen Wettermodellierung und Wetter verwendenden Modulen; und
6 zeigt einen veranschaulichenden Prozess zum Reduzieren eines Wettermodells auf ein 2,5-dimensionales Modell.

DETAILLIERTE BESCHREIBUNG
Je nach Bedarf werden hier detaillierte Ausführungsformen offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen rein veranschaulichender Natur sind und in verschiedenen und alternativen Formen integriert sein können. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Daher sind hier offenbarte konkrete strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um dem Fachmann die vielfältige Umsetzung des beanspruchten Gegenstands zu lehren.
1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Rechensystem 1 (vehicle based computing system - VCS) für ein Fahrzeug 31. Ein Beispiel für ein derartiges fahrzeugbasiertes Rechensystem 1 ist das SYNC-System, das von THE FORD MOTOR COMPANY hergestellt wird. Ein mit einem fahrzeugbasierten Rechensystem ausgestattetes Fahrzeug kann eine visuelle Front-End-Schnittstelle 4 enthalten, die in dem Fahrzeug angeordnet ist. Der Benutzer kann zudem dazu in der Lage sein, mit der Schnittstelle zu interagieren, wenn sie beispielsweise mit einer Touchscreen-Anzeige bereitgestellt ist. In einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion durch das Betätigen von Tasten, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
In der in 1 gezeigten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeugbasierten Rechensystems. Der innerhalb des Fahrzeugs bereitgestellte Prozessor ermöglicht das fahrzeuginterne Verarbeiten von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit nichtdauerhaftem 5 als auch dauerhaftem Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform handelt es sich bei dem nichtdauerhaften Speicher um Direktzugriffsspeicher (random access memory - RAM) und bei dem dauerhaften Speicher um ein Festplattenlaufwerk (hard disk drive - HDD) oder Flash-Speicher. Im Allgemeinen kann dauerhafter (nichtflüchtiger) Speicher alle Speicherformen beinhalten, die Daten aufbewahren, wenn ein Computer oder eine andere Vorrichtung abgeschaltet wird. Diese beinhalten unter anderem HDDs, CDs, DVDs, Magnetbänder, Solid-State-Laufwerke, tragbare USB-Laufwerke und jede beliebige andere geeignete Form von dauerhaftem Speicher.
Der Prozessor ist zudem mit einer Reihe unterschiedlicher Eingänge bereitgestellt, die es dem Benutzer ermöglichen, über eine Schnittstelle mit dem Prozessor zu interagieren. In dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, der Bildschirm 4, der eine Touchscreen-Anzeige sein kann, und ein BLUETOOTH-Eingang 15 alle bereitgestellt. Eine Eingangswähleinheit 51 ist ebenfalls bereitgestellt, um es einem Benutzer zu ermöglichen, zwischen verschiedenen Eingängen zu wechseln. Eingaben sowohl an das Mikrofon als auch den Hilfsanschluss werden durch einen Wandler 27 von analog zu digital umgewandelt, bevor sie an den Prozessor weitergeleitet werden. Wenngleich nicht gezeigt, können zahlreiche Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS in Kommunikation stehen, ein Fahrzeugnetzwerk (wie etwa unter anderem einen CAN-Bus) verwenden, um Daten an das und von dem VCS (oder Komponenten davon) weiterzuleiten.
Ausgänge des Systems können unter anderem eine visuelle Anzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang beinhalten. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal von dem Prozessor 3 durch einen Digital-Analog-Wandler 9. Eine Ausgabe kann zudem an eine entfernte BLUETOOTH-Vorrichtung, wie etwa eine PND (personal navigation device - persönliche Navigationsvorrichtung) 54, oder eine USB-Vorrichtung 62, wie etwa die Fahrzeugnavigationsvorrichtung 60, entlang der bidirektionalen Datenströme, die bei 19 bzw. 21 gezeigt sind, übertragen werden.
In einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Sendeempfänger 15, um mit der Mobilvorrichtung 53 eines Benutzers zu kommunizieren 17 (z. B. einem Mobiltelefon, Smartphone, PDA oder einer beliebigen anderen Vorrichtung, die sich mit einem drahtlosen Fernnetzwerk verbinden kann). Die Mobilvorrichtung (nachstehend als ND (nomadic device) bezeichnet) 53 kann dann dazu verwendet werden, beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. In einigen Ausführungsformen kann es sich bei dem Mast 57 um einen Wi-Fi-Zugangspunkt handeln.
Eine beispielhafte Kommunikation zwischen der ND 53 und dem BLUETOOTH-Sendeempfänger 15 wird durch das Signal 14 wiedergegeben.
Das Koppeln der ND 53 mit dem BLUETOOTH-Sendeempfänger 15 kann durch eine Taste 52 oder eine ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der fahrzeuginterne BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einer Mobilvorrichtung gekoppelt wird.
Zwischen der CPU 3 und dem Netzwerk 61 können Daten beispielsweise unter Verwendung eines Datentarifs, von Daten-über-Sprache oder DTMF-Tönen kommuniziert werden, die der ND 53 zugeordnet sind. Alternativ dazu kann es wünschenswert sein, ein fahrzeuginternes Modem 63 einzubeziehen, das eine Antenne 18 aufweist, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu kommunizieren 16. Die ND 53 kann dann dazu verwendet werden, beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. In einigen Ausführungsformen kann das Modem 63 eine Kommunikation 20 mit dem Mast 57 herstellen, um mit dem Netzwerk 61 zu kommunizieren. Als nicht einschränkendes Beispiel kann es sich bei dem Modem 63 um ein USB-Mobilfünkmodem und bei der Kommunikation 20 um Mobilfunkkommunikation handeln.
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem bereitgestellt, das eine API zum Kommunizieren mit einer Modemanwendungssoftware beinhaltet. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder eine Firmware auf dem BLUETOOTH-Sendeempfänger zugreifen, um die drahtlose Kommunikation mit einem entfernten BLUETOOTH-Sendeempfänger (wie etwa demjenigen, der in einer Mobilvorrichtung anzutreffen ist) abzuschließen. Bei Bluetooth handelt es sich um eine Teilmenge der Protokolle IEEE 802 PAN (Personal Area Network). Die Protokolle IEEE 802 LAN (Local Area Network) beinhalten Wi-Fi und weisen eine beträchtliche Kreuzfunktionalität mit IEEE 802 PAN auf. Beide sind für die drahtlose Kommunikation innerhalb eines Fahrzeugs geeignet. Weitere Kommunikationsmittel, die in diesem Bereich verwendet werden können, sind optische Freiraumkommunikation (wie etwa IrDA) und nicht standardisierte Nutzer-IR-Protokolle (IR-Kommunikation in 1 nicht gezeigt).
In einer anderen Ausführungsform beinhaltet die ND 53 ein Modem zur Sprachband- oder Breitbanddatenkommunikation. In der Daten-über-Sprache-Ausführungsform kann eine Technik umgesetzt werden, die als Frequenzmultiplexverfahren bekannt ist, wenn der Besitzer der Mobilvorrichtung bei gleichzeitiger Datenübertragung über die Vorrichtung sprechen kann. Zu anderen Zeitpunkten, wenn der Besitzer die Vorrichtung nicht verwendet, kann die gesamte Bandbreite (in einem Beispiel 300 Hz bis 3,4 kHz) zur Datenübertragung verwendet werden. Während das Frequenzmultiplexverfahren bei der analogen Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet geläufig sein kann und nach wie vor verwendet wird, wurde es weitgehend durch Hybride mit Codemultiplexverfahren (Code Domain Multiple Access - CDMA), Zeitmultiplexverfahren (Time Domain Multiple Access - TDMA), Raummultiplexverfahren (Space Domain Multiple Access - SDMA) für eine digitale Mobilfunkkommunikation ersetzt. Wenn der Benutzer über einen der Mobilvorrichtung zugeordneten Datentarif verfügt, besteht die Möglichkeit, dass der Datentarif eine Breitbandübertragung ermöglicht und das System eine wesentlich größere Bandbreite verwenden könnte (was die Datenübertragungsgeschwindigkeit erhöht). In noch einer anderen Ausführungsform wird die ND 53 durch eine Mobilfünkkommunikationsvorrichtung (nicht gezeigt) ersetzt, die in dem Fahrzeug 31 verbaut ist. In noch einer weiteren Ausführungsform kann die ND 53 eine Vorrichtung eines drahtlosen lokalen Netzwerks (LAN) sein, das beispielsweise (und ohne Einschränkung) über ein 802.11g-Netzwerk (d. h. Wi-Fi) oder ein WiMax-Netzwerk kommunizieren kann.
In einer Ausführungsform können eingehende Daten über Daten-über-Sprache oder einen Datentarif durch die Mobilvorrichtung, durch den fahrzeuginternen BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs weitergeleitet werden. Im Falle bestimmter temporärer Daten können die Daten beispielsweise auf der HDD oder einem anderen Speichermedium 7 gespeichert werden, bis die Daten nicht mehr benötigt werden.
Zusätzliche Quellen, die eine Schnittstelle mit dem Fahrzeug herstellen können, beinhalten eine persönliche Navigationsvorrichtung 54, die beispielsweise einen USB-Anschluss 56 und/oder eine Antenne 58 aufweist, eine Fahrzeugnavigationsvorrichtung 60, die einen USB-Anschluss 62 oder anderen Anschluss aufweist, eine fahrzeuginterne GPS-Vorrichtung 24 oder ein entferntes Navigationssystem (nicht gezeigt), das eine Verbindung mit dem Netzwerk 61 aufweist. Bei USB handelt es sich um eines einer Klasse serieller Netzwerkprotokolle. Die seriellen Protokolle IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony) und Lynx™ (Texas Instruments)), EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Vorrichtung-zu-Vorrichtung-Standards. Die Mehrheit der Protokolle kann entweder für die elektrische oder die optische Kommunikation umgesetzt werden.
Ferner könnte die CPU mit vielfältigen anderen Hilfsvorrichtungen 65 in Kommunikation stehen. Diese Vorrichtungen können durch eine drahtlose 67 oder drahtgebundene 69 Verbindung verbunden sein. Die Hilfsvorrichtung 65 kann unter anderem persönliche Medienwiedergabevorrichtungen, drahtlose Gesundheitsvorrichtungen, tragbare Computer und dergleichen beinhalten.
Zudem oder alternativ dazu könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 verbunden sein, beispielsweise unter Verwendung eines Sendeempfängers 71 für Wi-Fi (IEEE 803.11). Dadurch könnte die CPU eine Verbindung zu Fernnetzwerken im Bereich des lokalen Routers 73 herstellen.
Zusätzlich zur Ausführung beispielhafter Prozesse durch ein Fahrzeugrechensystem, das in einem Fahrzeug angeordnet ist, können die beispielhaften Prozesse in bestimmten Ausführungsformen durch ein Rechensystem ausgeführt werden, das mit einem Fahrzeugrechensystem in Kommunikation steht. Ein derartiges System kann unter anderem eine drahtlose Vorrichtung (z. B. unter anderem ein Mobiltelefon) oder ein durch die drahtlose Vorrichtung verbundenes entferntes Rechensystem (z. B. unter anderem einen Server) beinhalten. Zusammen können derartige Systeme als dem Fahrzeug zugeordnete Rechensysteme (vehicle associated computing systems - VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS in Abhängigkeit von der konkreten Umsetzung des Systems bestimmte Teile eines Prozesses durchführen. Wenn ein Prozess beispielsweise und nicht einschränkend einen Schritt eines Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, dann ist es wahrscheinlich, dass die drahtlose Vorrichtung diesen Teil des Prozesses nicht durchführt, da die drahtlose Vorrichtung Informationen nicht sich selbst bzw. von sich selbst „senden und empfangen“ würde. Der Durchschnittsfachmann wird verstehen, wann es unangemessen ist, ein bestimmtes Rechensystem auf eine gegebene Lösung anzuwenden.
In jeder der hier erörterten veranschaulichenden Ausführungsformen wird ein beispielhaftes nicht einschränkendes Beispiel für einen Prozess gezeigt, der durch ein Rechensystem durchgeführt werden kann. In Bezug auf den jeweiligen Prozess ist es möglich, dass das Rechensystem, das den Prozess ausführt, für den beschränkten Zweck der Ausführung des Prozesses als Spezialprozessor zum Durchführen des Prozesses konfiguriert wird. Alle Prozesse müssen nicht in ihrer Gesamtheit durchgeführt werden und sind als Beispiele für Prozesstypen zu verstehen, die durchgeführt werden können, um Elemente der Erfindung zu erzielen. Zusätzliche Schritte können nach Bedarf zu den beispielhaften Prozessen hinzugefügt oder daraus entfernt werden.
In Bezug auf die veranschaulichenden Ausführungsformen, die in den Figuren beschrieben sind, die veranschaulichende Prozessabläufe zeigen, ist anzumerken, dass ein Universalprozessor vorübergehend als Spezialprozessor zum Zwecke des Ausführens einiger oder aller der beispielhaften Verfahren, die durch diese Figuren gezeigt werden, aktiviert werden kann. Wenn Code ausgeführt wird, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor erneut vorübergehend als Spezialprozessor eingesetzt werden, und zwar so lange, bis das Verfahren abgeschlossen ist. In einem anderen Beispiel kann in einem angemessenen Ausmaß Firmware, die gemäß einem vorkonfigurierten Prozessor agiert, veranlassen, dass der Prozessor als Spezialprozessor agiert, der zum Zwecke des Durchführens des Verfahrens oder einer angemessenen Variation davon bereitgestellt ist.
In den veranschaulichenden Ausführungsformen kann ein Fahrzeugsystem Wetterdaten empfangen, die ein Wettervorhersagemodell mit synoptischen, sowohl in räumlichem als auch zeitlichem Bezug modellierten Wettermerkmalen repräsentieren. Bei der herkömmlichen Wettervorhersage werden Datenpunkte an verschiedenen Positionen und Höhenlagen gesammelt und auf einer dreidimensionalen Karte dargestellt. Synoptische Merkmale können durch einen erfahrenen Meteorologen manuell in die Karte eingezeichnet werden. Nach wenigen Stunden wird der Prozess wiederholt und der Meteorologe beobachtet die Änderungen der synoptischen Merkmale. Die Rate, mit der sich die synoptischen Merkmale bewegt haben, kann verwendet werden, um vorherzusagen, wo sie sich in Zukunft befinden werden.
In der modernen Meteorologie kann dieser Modellierungsprozess automatisch in einem Computer mit makrometeorologischen Modellen erfolgen, die nicht nur die Bewegung der Merkmale berücksichtigen, sondern auch die Kräfte, welche die Bewegungen steuern. Beispielsweise würde es sich beim Auge eines Hurrikans um ein synoptisches Merkmal handeln. Ein einfaches Modell würde die Position, Stärke usw. des Merkmals über mehrere Zeitschritte darstellen und anschließend dessen zukünftige Position, Stärke usw. extrapolieren. Die Modellierung im Stand der Technik würde die Auswirkungen von synaptischen Merkmalen aufeinander, d. h. die Auswirkung des Jetstreams auf das Auge und umgekehrt, berücksichtigen. Diese Wetterdaten werden als hochdimensionales Modell (4D) ausgedrückt und können weit vor deren Bedarf in das Fahrzeug heruntergeladen werden.
In den veranschaulichenden Ausführungsformen kann der Prozessor eine Anforderung-Antwort-Schnittstelle mit anderen Fahrzeugmodulen bereitstellen, bei der eine Anforderung eine gekrümmte Linie oder eine gekrümmte Fläche in Raum und Zeit beinhaltet, für die das Wetter geschätzt wird. Die Schätzungen werden typischerweise als stochastische Variablen (Wahrscheinlichkeitsverteilungsfunktionen wie die Beta-Verteilung) ausgedrückt, welche den Genauigkeitsverlust aufgrund des Abstands zu einer festen Messposition und der Zeit seit der letzten Messung ausdrücken. Da der Kanal zur Cloud intermittierend ist, könnten aktuellere Messungen vorgenommen worden sein, jedoch geht ihre Auswirkung aufgrund der fehlenden Kommunikation mit der Cloud verloren. Darüber hinaus ergibt sich eine natürliche zeitliche Verzögerung zwischen dem Zeitpunkt, zu dem eine Messung vorgenommen wird, und dem, zu dem sie verarbeitet und dem intermittierenden Kanal zur Verfügung gestellt wird.
In den veranschaulichenden Ausführungsformen können die synaptischen Merkmale mathematisch als zeitlich variierende Flächen oder Volumen mit Attributen, wie etwa Stärke, ausgedrückt und in dieser Form über die intermittierende Verbindung an das Fahrzeug übertragen werden. Ein KI-Modul an dem Fahrzeug kann ein Modell dieser Art verarbeiten, um vorherzusagen, wie sich das Modell entwickeln und wie genau die Vorhersage sein wird. Die Wettermessungen an konkreten Punkten, Linien, Bereichen usw. können dann von dem Modell in dem Fahrzeug für die Zukunft vorhergesagt werden.
Wetterdienste können auf Wettermessungen von einer räumlich auf der ganzen Welt verteilten Vielzahl von Vorrichtungen zugreifen. Dadurch ist es ihnen möglich, Messungen in synoptische Wettermodelle zu abstrahieren, die durch mathematische vierdimensionale Modelle repräsentiert werden können. Diese Modelle sind oftmals zu komplex, um durch Fahrzeugsystemkomponenten verwendet zu werden; daher wird hier ein Verfahren beschrieben, das die synoptischen Modelle zu Wetterinformationen vereinfacht, die in Fahrzeugmerkmalen verwendet werden können. In vielen Fällen können für eine Fahrzeugsystemkomponente ein oder zwei Aspekte des Wetters wichtig sein, und die Komponente kann eine Eingabe in Form von Parametern, die diesen Aspekten zugeordnet sind, anfordern oder nutzen, z. B. Temperatur an der Position X (oder zum Zeitpunkt X) und Luftfeuchtigkeit an der Position X (oder zum Zeitpunkt X).
Synoptische Modelle können die Grundlage für gute Vorhersagen für einen wesentlichen Zeitraum bereitstellen, was zur Beseitigung der Probleme der zeitlichen Verschiebungen aufgrund von Messverzögerungen und Modellbildung und Verzögerungen aufgrund des intermittierenden Charakters der Verbindung vom Wetterserver zum Fahrzeug beiträgt. Bei den beschriebenen Modellen kann es sich um lernende Modelle handeln, die unter Verwendung von kostengünstigen Wetterdaten von einem Fahrzeugsensor trainiert werden. Zum Beispiel sind die Wettermodelle in der Lage, 10 Arten von Wetterinformationen vorherzusagen, von denen eine die Temperatur ist. Die Temperatur kann zudem an dem Fahrzeug gemessen und mit der Temperatur des Modells verglichen werden. Die Differenz zwischen dem Ergebnis des Modells und dem gemessenen Ergebnis wird als Straffunktion verwendet. Ein Untersuchungsmerkmal in dem Modell ändert Modellparameter und beobachtet die Auswirkung der Änderung auf die Straffunktion. Ein Optimierungsalgorithmus verwendet diese Beobachtungen, um die Straffunktion zu minimieren.
Gleichzeitig können die aktuell modellierten Daten verwendet werden, um die Temperatur und Luftfeuchtigkeit (um das vorstehende Systembeispiel zu verwenden) zu einem bestimmten Zeitpunkt in der Zukunft vorherzusagen. Dies kann gegebenenfalls eine Vorkonditionierung oder die Vermeidung eines Gebietes oder eine beliebige andere angemessene Maßnahme ermöglichen, die als Reaktion auf eine bestimmte vorhergesagte Bedingung oder einen bestimmten vorhergesagten Aspekt des Wetters ergriffen wird.
2 zeigt einen veranschaulichenden Prozess zum Fahrzeugsensordatenfreigabe. Dieses Beispiel zeigt (durch die Freigabe von GPS-Koordinaten), wie ein Fahrzeug Daten mit einem anderen Fahrzeug freigeben kann, um wirksam dem empfangenden Fahrzeug „virtuelle“ Sensoren bereitzustellen, die zu den fahrzeuginternen Sensoren des freigebenden Fahrzeugs äquivalent (oder nahezu äquivalent) sind. Der Grund dafür, dass die Sensoren als „nahezu“ äquivalent beschrieben werden, liegt darin, dass die Sensordaten, die freigegeben werden, an dem freigebenden Fahrzeug, nicht aber dem empfangenden Fahrzeug gesammelt werden, sodass die Daten geringfügig achsenverschoben sind. Nichtsdestotrotz ist der Empfang von Daten von einem Fahrzeug in relativer Nähe ausreichend, um dem empfangenden Fahrzeug das bereitzustellen, was es benötigt, wodurch die Kosten für den Einsatz von Sensoren in jedem Fahrzeug vermieden werden.
In dieser veranschaulichenden Ausführungsform ist ein Fahrzeug, dem Sensoren fehlen (empfangendes Fahrzeug), in der Lage, ein Signal zu detektieren 201, das von einem oder mehreren Fahrzeugen in der Nähe übertragen wird. Bei diesem Signal kann es sich um freigegebene Daten einer beliebigen Anzahl von Arten handeln, das freigebende Fahrzeug kann entweder eine Verfügbarkeit der Sensordaten und/oder die tatsächlichen Sensordaten übertragen. In diesem Beispiel detektiert der Prozess eine Übertragung von dem Fahrzeug in der Nähe und bestimmt, ob das von diesem Fahrzeug empfangene Signal 203 über einem bestimmten Schwellenwert liegt, was darauf hindeutet, dass sich das freigebende Fahrzeug innerhalb eines bestimmten Abstands von dem empfangenden Fahrzeug befindet (wobei eine höhere Signalstärke im Allgemeinen eine größere Nähe angibt). Wenn die Signalstärke angibt, dass sich das Fahrzeug nicht in unmittelbarer Nähe befindet, kann der Prozess enden 200.
In diesem Beispiel berücksichtigt der Prozess eher Signale von Fahrzeugen, die sich in relativer Nähe (zum Beispiel innerhalb von 20 Fuß) befinden, da das Fahrzeug GPS-Koordinaten freigegeben, deren Nutzen eher hinfällig ist (besonders für Navigationszwecke), wenn das empfangende Fahrzeug zu weit von dem freigebenden Fahrzeug entfernt ist. In anderen Beispielen, wie etwa der Freigabe wetterbezogener Daten, kann der Prozess Signale von Fahrzeugen berücksichtigen, die weiter entfernt sind, da es unwahrscheinlich ist, dass die Wetterdaten in einem angemessenen Umkreis (mindestens mehrere Hundert Fuß) wesentliche Abweichungen aufweisen. Somit kann der Schwellenwert für eine unmittelbare Nähe für den Sensordatenfreigabe bis zu einem gewissen Grad an die bestimmte Art oder Klasse von Daten, die zwischen den Fahrzeugen freigegeben werden, geknüpft werden.
Zudem bestimmt 205 der Prozess in diesem Beispiel, ob das Signal in der Nähe eine GPS-Freigabe beinhaltet. In diesem Beispiel überträgt das austauschende Fahrzeug ein Signal, das eine Freigabefähigkeit angibt. Die anderen lokalen Fahrzeuge können dieses Signal detektieren und freigegebene Daten einer in der Übertragung angegebenen Art anfordern. Wenn das freigebende Fahrzeug in der Lage ist, GPS-Koordinaten freizugeben, stellt in diesem Beispiel der Prozess in dem empfangenden Fahrzeug dementsprechend eine Verbindung zu dem freigebenden Fahrzeug her 209. Andernfalls schließt das empfangende Fahrzeug (das in diesem Beispiel nach GPS-Koordinaten sucht) die ID des freigebenden Fahrzeugs aus 207, sodass es die Übertragung des freigebenden Fahrzeugs zu einem späteren Zeitpunkt (unter der Annahme, dass das freigebende Fahrzeug weiterhin eine gewisse Verfügbarkeit freigegebener Daten überträgt) nicht berücksichtigen muss, wenn die beiden Fahrzeug weiterhin in unmittelbarer Nähe zueinander fahren. Für einige Signale, die einen begrenzten Übertragungsbereich aufweisen, kann der Ausschlussprozess 207 die gleichen Koordinaten wie das empfangende Fahrzeug (305 in 3) für die übertragenen Wettersignale annehmen, oder wenn das empfangende Fahrzeug keinen Positionssensor (z. B. GPS, Koppelnavigationssystem usw.) aufweist, können die Koordinaten des übertragenden Objekts direkt verwendet werden. Somit kann der Bereich des Signals verwendet werden, um zu bestimmen, ob bei einer Entscheidung der Vergleich 213 ausgeschlossen 207 und somit umgangen und zur Bestimmung der Nähe 215 übergegangen werden soll.
Sobald sich das empfangende Fahrzeug mit dem freigebenden Fahrzeug verbunden hat, empfängt 211 der Prozess am empfangenden Fahrzeug GPS-Koordinaten von dem freigebenden Fahrzeug. In anderen Beispielen, in denen die Sensordaten in der Übertragung beinhaltet sind, kann das empfangende Fahrzeug die relevanten Daten einfach extrahieren. In diesem Beispiel vergleicht 213 dann der Prozess die empfangenen Koordinaten mit geschätzten, sogenannten „berechneten“ Koordinaten, die basierend auf einer zuvor identifizierten Fahrzeugposition und Fahreigenschaften (z. B. Geschwindigkeit und Richtung) seit diesem Zeitpunkt vermutet wurden.
Da das freigebende Fahrzeug über genaue Koordinaten verfügt und sich in unmittelbarer Nähe zu dem empfangenden Fahrzeug befindet, kann der Prozess die empfangenen Koordinaten als die „korrekten“ Koordinaten des Fahrzeugs, plus oder minus einer gewissen Fehlerkorrektur, ansehen. Der Prozess bestimmt 215, ob die empfangenen Koordinaten (numerisch) nahe den berechneten Koordinaten liegen. Wenn dies nicht der Fall ist, das heißt, wenn die „wahre“ Position zeigt, dass die berechnete Position schlecht geschätzt wurde, kann der Prozess den Server benachrichtigen 217, dass das Berechnungsmodell falsch lag, und kann ein aktualisiertes Modell von dem Server anfordern 219. Das Modell wird möglicherweise nicht unmittelbar aktualisiert, der Server kann jedoch den beobachteten Fehler verwenden, um das Modell zu verbessern, und kann dem anfordernden Fahrzeug ein verbessertes Modell ausgeben, sobald ausreichend Daten durch den Server empfangen wurden, um das Modell zu verbessern. Das Fahrzeug verwendet 221 die empfangenen Koordinaten, um Navigationen oder andere koordinatenbezogene Maßnahmen durchzuführen.
Während das Vorhergehende in Bezug auf das Freigeben von GPS-Daten beschrieben wurde, können Sensordaten einer beliebigen Art in einer ähnlichen Weise freigegeben werden. Gleichermaßen können Modelle, welche die den freigegebenen Daten entsprechende Daten vorhersagen, basierend auf empfangenen Versionen der vorhergesagten Daten in einer ähnlichen Weise aktualisiert werden. Hinsichtlich der hier erörterten Wettervorhersagen kann zum Beispiel das Freigeben ein Freigeben bestimmter Sensordaten beinhalten, die ein Element des Wettermodells (z. B. Temperatur, Luftfeuchtigkeit, Luftdruck usw.) repräsentieren, und die Rückmeldung an den Server kann dazu beitragen, das Wettermodell zu korrigieren, um die Daten genauer wiederzugeben. Wenn auch nur eine Teilmenge von Fahrzeugen zur Freigabe fähige Sensoren aufweist, könnte eine größere Anzahl von Fahrzeugen verfügbar sein, um Daten über die Freigabe regelmäßig zu übermitteln. Ferner können Fahrzeuge mit verschiedenen zur Freigabe fähigen Sensoren ausgestattet sein, sodass eine beliebige Stichprobe von Fahrzeugen Fahrzeuge mit verschiedenartigen Sensoren beinhalten kann, wobei diese Fahrzeuge (nicht spezifisch oder notwendigerweise die Sensoren selbst) in der Lage sind, die direkt gesammelten Informationen von diesen Sensoren freizugeben.
3 zeigt ein veranschaulichendes Fahrzeug, das eine fahrzeuginterne Modellierungs- und Erfassungsfähigkeit beinhaltet. In diesem Beispiel kann das Fahrzeug 300 zu einer periodischen Verbindung mit einem Wetterserver 301 in der Lage sein. Der Wettervorhersageserver kann auf ein fahrzeuginternes meteorologisches Modell mit synoptischen Wetterinformationen antworten, der Kanal/die Verbindung ist jedoch möglicherweise nicht immer verfügbar. Eine Anforderung von einem Fahrzeug kann einen oder mehrere Zeit- und Positionsparameter für eine aktuelle Position und/oder aktuelle Punkte entlang einer Route zusammen mit geschätzten Ankunftszeiten an diesen Punkten beinhalten. Eine Antwort von dem Vorhersageserver kann synaptische Daten innerhalb der angeforderten Gebietsschemata und während der angeforderten Zeiten beinhalten. Dies würde Vorhersagedaten für einen beliebigen Zeitpunkt in der Zukunft beinhalten.
Das Fahrzeug beinhaltet ein fahrzeuginternes meteorologisches Modell 303, das (für das Fahrzeug und möglicherweise für andere empfangende Fahrzeuge) lokale Antworten auf spezifische Anforderungen für Vorhersageinformationen bereitstellen kann. Das meteorologische Modell kann Wetter als ein System abbilden, kann jedoch in der Lage sein, aus diesem System Parameter und Parameterwerte für bestimmte Positionen als Reaktion auf spezifische Anforderungen der elektronischen Steuereinheit (electronic control unit - ECU) (oder andere fahrzeuginterne Anforderungen) zu extrahieren und bereitzustellen. Wenn zum Beispiel ein adaptives Modul für Heizung, Lüftung und Klima (HLK) versuchen würde, die Kabinentemperatur gleichbleibend zu halten, könnte somit dieses Modul prognostizierte Temperaturmodelle für die nächsten fünfzehn Minuten oder Meilen einer Route wissen wollen. Da die Wetterdaten sowohl räumlich als auch zeitlich modelliert sind, könnte jede der beiden Anforderungen durch das Modell erfüllt werden.
Die HLK-ECU kann Daten über einen Pfad auf einer Erdoberfläche anfordern, und der Pfad wird durch das Modell mit geschätzten Ankunftszeiten an einem beliebigen gegebenen Ort parametrisiert. Die Antwort von dem Modell könnte eine Spline-Gleichung (z. B. eine kubische Gleichung) beinhalten, die zum Beispiel prognostizierte Werte über eine Zeit repräsentiert, während das Fahrzeug die Positionen bis zu einem letztendlichen Zielort passiert. Oder die Antwort könnte diskrete Werte beinhalten, die basierend auf dem Spline extrahiert wurden, für den Fall, dass die ECU nicht in der Lage war, den Spline als Antwort zu empfangen. Die ECU (ein Beispiel für einen Informationsnutzer 309) kann die Daten verwenden, um adaptiv an sich ändernde Wettermuster eingestellt zu werden, und in diesem Fall die Kabinentemperatur möglichst gleichbleibend zu halten (oder zum Beispiel eine Kabine oder ein Fenster vorzukonditionieren, um Kondensation oder Vereisung zu vermeiden).
Bei dem Pfad, entlang dessen Daten bereitgestellt werden, muss es sich nicht um den Pfad handeln, auf dem das Fahrzeug 300 fährt. Zum Beispiel könnte eine drahtlose Kommunikationsvorrichtung ihr Kanalmodell basierend auf Wetterbedingungen auf einem Pfad zwischen dem Fahrzeug und der Vorrichtung, mit der es kommuniziert, modifizieren. Da sich das Fahrzeug 300 bewegt (und sich das entfernte Fahrzeug potentiell bewegt), kann das Kommunikationsmodul Wetterinformationen auf einer räumlich und zeitlich parametrisierten gekrümmten Fläche anfordern. Gleichermaßen könnte ein Navigationsmodul das Wetter entlang mehrerer Pfade auswerten wollen, auf denen die Fahrtzeit durch das Wetter selbst beeinflusst wird. In diesem Fall können die Wetterparameter praktischerweise durch eine gekrümmte Fläche ausgedrückt werden, um die nichtlineare Kostenberechnung auf jeder Route zu vereinfachen.
Das Fahrzeug beinhaltet zudem einen virtuellen Wettersensor 307. Dieser „Sensor“ empfängt Daten von dem meteorologischen Modell und präsentiert die Daten einem Insassen 309 und/oder einem anderen Fahrzeugsystem 309. Dieser Sensor kann zudem dem meteorologischen Modell Navigations-(Pfad-)Daten bereitstellen (damit das Modell weiß, welche Daten zu extrapolieren sind). Dieses Modell empfängt aktuelle Positions- und Zeitdaten von dem Positions- und Zeitsensor 305, der zudem dem meteorologischen Modell Positions- und Zeitdaten bereitstellt. Ein/e Kartenserver/-datenbank 311 kann zwei- oder dreidimensionale Kartendaten zur Verwendung bei der Modellierung von Wetter bereitstellen, welche dreidimensionale räumliche Wettermodelle, die in vier Dimensionen (über eine Zeit über einem 3D-Pfad) modelliert wurden, beinhalten können. Tatsächliche 313 fahrzeuginterne Sensoren können Wetteraspekte detektieren, die an diesem bestimmten Fahrzeug detektiert werden können (und/oder von anderen Fahrzeugen empfangen werden, obwohl der Empfang ebenfalls durch den virtuellen Wettersensor erfolgen kann). Prinzipiell kann das Nahbereichskommunikationsmodul, das in der Lage ist, Informationen von Fahrzeugen und Infrastrukturvorrichtungen in der Nähe zu sammeln, zudem als ein Sensor angesehen werden.
Wie zuvor angemerkt, können Fahrzeuginsassen und fahrzeuginterne Systeme einige Nutzer 309 der Wetterdaten oder fahrzeuginternen ECUs sein. Die ECUs können als veranschaulichendes Beispiel Navigationssysteme (um Wetter herum lotsend), Fahrzeugnotfallsysteme, Fahrzeugbenachrichtungssysteme; HLK, Antriebsstrangsteuerungen, Concierge-Services, automatische Aufhängungssteuerung usw. beinhalten. Andere Nutzer können unter anderem Ersthelfer (für das Wetter vor Ort bei einem Unfall) und andere in der Nähe befindliche Fahrzeuge beinhalten.
In einem veranschaulichenden Beispiel kann der Wetterserver synoptische Wetterinformationen bereitstellen, die durch das meteorologische Modell in Wetterinformationen entlang eines Pfades umgewandelt werden. Das meteorologische Modell kann diese Informationen (mit einem gewissen Genauigkeitsverlust) bereitstellen, während die Verbindung zum Wetterserver unterbrochen ist, basierend auf der fortgesetzten Modellierung, die den von dem Wetterserver bereitgestellten Parametern und den Spline-Daten folgt.
Eine Front (ein Beispiel für ein synoptisches Merkmal) ist eine Fläche, die auf eine Erdoberfläche modelliert werden kann, und die Frontfläche bewegt sich im Laufe der Zeit auch. Eine mathematische Fläche, wie etwa eine vierdimensionale Spline-Kurve, kann die Fläche in drei räumlichen Dimensionen und im Laufe der Zeit beschreiben. Eine Fehlerfunktion, die in drei Dimensionen variiert, kann die sich im Laufe der Zeit erhöhende Fehlerschranke beschreiben. Andere synoptische Objekte können in einer ähnlichen Weise in dem Wettervorhersageserver beschrieben und an das meteorologische Modell in dem Fahrzeug durch Senden der Spline-Parameter übertragen werden.
Der Pfad durch den Raum, der in der Anforderung von dem virtuellen Wettersensor an das meteorologische Modell gesendet wird, kann mit kubischen Splines, die bezüglich der Zeit, t, parametrisiert sind, definiert werden. Beide Enden des Kommunikationskanals einigen sich auf Gleichungen für geografischen Längengrad, geografischen Breitengrad und Höhenlage. Die Übertragung des Pfades ist dann eine Frage des Sendens aller Koeffizienten A, B, C und D. Zusätzlich dazu können für die Koeffizienten einige Einschränkungen gelten, um zu gewährleisten, dass die Enden sich treffen und die Anstiege stetig sind, die Länge des Pfads korrekt ist usw.
Eine Verwendung des Verfahrens besteht darin, die Wetterbedingungen, die das Fahrzeug wahrscheinlich während der Fahrt entlang einer Route vorfinden wird, vorauszusehen. Der Pfad ist bezüglich der Zeit parametrisiert, jedoch wird eine Vermutung in dem virtuellen Wettersensor angestellt, dass das Fahrzeug eine bestimmte Position zu einem bestimmten Zeitpunkt erreicht (d. h., die voraussichtliche Geschwindigkeit des Fahrzeugs ist eine Eingabe in den Pfad. Wenn das Fahrzeug mit einer anderen Geschwindigkeit fährt, oder wenn der Fahrer einen Fahrtpfad ändert, kann der virtuelle Sensor fordern, dass ein neuer Pfad, der die Geschwindigkeitsänderung wiedergibt, durch das meteorologische Modell berechnet wird).
Repräsentative und veranschaulichende Spline-Berechnungen können wie folgt sein: $S p l i n e_{n} (t) = {L \ddot{a} n g e n g r a d_{n} (t), B r e i t e n g r a d_{n} (t), H \ddot{o} h e n l a g e_{n} (t)}$
$L \ddot{a} n g e n g r a d_{n} (t) = A_{m, n} t^{3} + B_{m, n} t^{2} + C_{m, n} t + D_{m, n}$
$B r e i t e n g r a d_{n} (t) = A_{l, n} t^{3} + B_{l, n} t^{2} + C_{l, n} t + D_{l, n}$
$H \ddot{o} h e n l a g e_{n} (t) = A_{a, n} t^{3} + B_{a, n} t^{2} + C_{a, n} t + D_{a, n}$
Das Vorhergehende kann einen Pfad durch den Raum repräsentieren, der von dem virtuellen Sensor an das meteorologische Modell gesendet wird. Das meteorologische Modell kann mit einem Spline antworten, der einen Wetterparameter im Laufe der Zeit (vermutlich entlang des von dem virtuellen Sensor empfangenen Pfades) zeigt. Zum Beispiel: $L u f t d r u c k_{n} (t) = A_{b, n} t^{3} + B_{b, n} t^{2} + C_{b, n} t + D_{b, n}$
4 zeigt einen veranschaulichenden Prozess für eine Wettermodellaktualisierung des meteorologischen Modells 303. Da Livedaten einen tatsächlichen Wert wiedergeben können, der sich von einem prognostizierten Wert unterscheidet, können die Livedaten verwendet werden, um das Prognosemodell derart zu verbessern, dass zukünftige Prognosen hoffentlich genauer sind.
In diesem Beispiel fordert 401 der Prozess in dem meteorologischen Modell eine aktualisierte Version von Daten von dem fahrzeugexternen Wettermodell 301 an und es erfolgt eine Überprüfung, um zu sehen, ob es sich bei der Version um eine neue Version handelt und sie verfügbar ist 403. Wenn die fahrzeugexternen Serverdaten nicht verfügbar sind, kann der Prozess zur Nutzung eines zuvor erlangten fahrzeuginternen Modells übergehen. In diesem Fall kann es sich bei den „erlangten Daten“ einfach um die prognostizierten Daten für einen aktuellen Punkt in Raum und Zeit handeln, an dem reale Daten gesammelt werden.
Wenn der Prozess in der Lage ist, neue Daten von dem entfernten Wettermodell zu erlangen 405, kann der Prozess das aktualisierte Fernservermodell dem fahrzeuginternen meteorologischen Modell bereitstellen 407. Da sich Wettermuster rasch ändern können, trägt ein periodisches Erlangen 405 von aktualisierten Daten von dem Fernserver dazu bei, das fahrzeuginterne Vorhersagemodell aktuell zu halten. Während ein Wettermuster gewissermaßen vorhersagbar für einen Zeitraum andauern kann, kann es sich auch unerwartet auflösen. Wie aus diesem Prozess zu erkennen ist, kann der Prozess, wenn ein fahrzeuginternes Modell wesentlich von realen Daten abzuweichen scheint 423, einfach versuchen, einen aktualisierten Datensatz von dem Fernserver zu erlangen.
Egal, ob der Prozess neue Daten von dem Server verwenden kann oder nicht, ist der fahrzeuginterne Prozess in der Lage, der Modellierung zugeordnete Parameter adaptiv einzustellen, um eine minimierte Straffunktion zu erzeugen. Die Straffunktion basiert auf der Differenz zwischen realen (gemessenen) und vorhergesagten Daten und das System kann ununterbrochen fahrzeuginterne Parameter anpassen, um die Funktion zu minimieren. Wenn die „Aktualisierung“ ausprobiert wird, kann das Modell eine Vielzahl von Sätzen von variierten Parametern modellieren, was mehrere vorhergesagte Datensätze für einen aktuellen messbaren Datenpunkt oder aktuell messbare Datenpunkte zur Folge haben kann (z. B. sagt Satz A vorher - Temperatur 35 Grad, Luftfeuchtigkeit 67 Prozent, Luftdruck 29 Hg, sagt Satz B vorher - Temperatur 33 Grad, Luftfeuchtigkeit 69 Prozent, Luftdruck 30 Hg usw.). Egal für welche Datenelemente, die fahrzeugintern messbar sind (oder als Messungen von einem in der Nähe befindlichen Fahrzeug erlangt werden können), kann der Prozess reale Datenpunkte sammeln 409 und diese mit den verschiedenen vorhergesagten Datenpunkten vergleichen, um eine Straffunktion zu minimieren. Die niedrigste sich daraus ergebende Straffunktion kann definieren 411, welche Parametermodifikationen gegenwärtig zu verwenden sind, das heißt, welche Parametermodifikationen die wahrsten Ergebnisse am genauesten bereitzustellen scheinen.
Wenn die Straffunktion niedrig genug ist 413, kann der Prozess die definierten Parameter verwenden 417 und die Datenelementmodellierung vorantreiben. Wenn die Straffunktion nicht niedrig genug ist, kann der Prozess die ausgewählten Parameter als Ausgangswert einstellen 415 und einen neuen Satz von Parametermodifikationen ausprobieren, der hoffentlich die Straffunktion bis zu einem annehmbaren Punkt einschränkt.
Während der Prozess Wetterelementwerte mit einem gegebenen Satz von Parametermodifikationen modelliert, kann der Prozess zudem weiterhin reale Daten sammeln 419. Die Daten können an diskreten Punkten, oder wann immer sie verfügbar sind, gesammelt werden, und wenn das Fahrzeuge nur wenige oder keine fahrzeuginternen Sensoren aufweist, sich jedoch für Datenpunkte auf vorbeifahrende Fahrzeuge stützt, ist „wann immer verfügbar“ möglicherweise der bessere Ansatz. Die gesammelten Daten werden mit prognostizierten Daten zu dem Zeitpunkt und der Position des Sammelns verglichen 421 (die gesammelten Daten können mit einem Zeit- und Positionsstempel versehen sein, sodass der Prozess weiter ausgeführt werden kann, ohne dass das Fahrzeug tatsächlich anhalten muss, außer wenn ein Element wie „Windgeschwindigkeit und -richtung“, das durch die Fahrzeugbewegung beeinflusst wird, gesammelt wird). Wenn der Vergleich eine übermäßige Strafe 423 zur Folge hat, kann der Prozess eine weitere Aktualisierung anfordern.
Eine übermäßige Strafe kann die Folge einer raschen Änderung des Wettermusters in einer unerwarteten Weise sein, und somit können neue Daten ein besseres Modell bereitstellen. Auch wenn keine neuen Daten verfügbar sind, kann die Anforderung eine Parametermodifikationsaktualisierung von der Modellierung bei 407 zur Folge haben, sodass ein besserer Satz von modifizierten Parametern erlangt werden kann, um die Vorhersagen angesichts des sich ändernden Wettermusters genauer zu halten. Bei der übermäßigen Strafe kann es sich um eine große Straffunktion, die wenigen Messungen zugeordnet ist, zunehmende Straffunktionen bei aufeinanderfolgenden Messungen, Gesamtstrafen über einem Schwellenwert oder eine beliebige andere geeignete Basis handeln, die nahelegt, dass das aktuelle Modell möglicherweise bezüglich der Genauigkeit abweicht.
5 zeigt eine andere veranschaulichende Beziehung zwischen Wettermodellierung und Wetter verwendenden Modulen. In diesem Beispiel erzeugt ein entfernter Cloud-basierter Prozess 501 synaptische Modelle und sendet diese an einen fahrzeuginternen Speicher 505. Unglücklicherweise kommt es zu einer Verzögerung zwischen dem Zeitpunkt, zu dem diese Modelle zur Verfügung stehen und dem, zu dem sie erzeugt werden; und darüber hinaus ist die Verbindung 503 typischerweise intermittierend. Das Wetter ändert sich ständig und dennoch kann das Modell auf alten und weniger relevanten Daten basieren.
Der fahrzeuginterne Speicher ist mit einem lokalen synaptischen Modell 509 verbunden und dieses Modell ist mit dem Speicher durch einen hochwertigen Dienstkanal 507 verbunden. Das lokale Modell empfängt Daten von fahrzeuginternen Sensoren 511 und verwendet diese Daten gemeinsam mit dem Cloud-basierten synaptischen Modell 501, um das lokale synaptische Modell 509 zu aktualisieren und beizubehalten. Wenn von einem Fahrzeugmodul 515 eine Anforderung kommt, dient der Prozess dazu, die Dimensionalität 513 des lokalen 4D-Modells zu reduzieren. Diese Ausgabe (typischerweise eine 2,5-dimensionale Ausgabe) wird an das anfordernde Modul 517 gesendet.
6 zeigt einen veranschaulichenden Prozess zum Reduzieren eines Wettermodells auf ein 2,5-dimensionales Modell 503. Der fahrzeuginterne Modellierungsprozess kann ununterbrochen das vierdimensionale Modell aktualisieren und das Modell entlang der Kanäle von Interesse glätten, wenn von Fahrzeugmodulen Anforderungen empfangen werden. Hierbei handelt es sich um die Wartezeit 601. Wenn der Prozess von einem anderen Fahrzeugmodul eine Anforderung empfängt 603, handelt es sich dabei um eine Anforderung für spezifische synaptische Daten für ein bezüglich Raum und Zeit definiertes spezifisches Volumen.
Der Prozess empfängt 605 das synaptische Modell in dessen zuletzt aktualisierter Form von einem lokalen Speicher und initialisiert 607 auf das Modell bezogene freie Zeit- und Raum-Parameter. Diese Parameter definieren die Positionen, entlang derer die Glättung stattfindet, sowie die erwarteten Ankunftszeiten, sodass das vorhergesagte Wetter mit dem Zeitpunkt korreliert, zu dem das Fahrzeug tatsächlich an einer Position ankommen soll. Diese Parameter ermöglichen dem Prozess, eine Raum-Zeit-Position in synaptischen Modellkoordinaten zu berechnen 609, die den freien Parametern entsprechen. Der Prozess kann zudem den wahrscheinlichen Einfluss des synaptischen Merkmals auf die Position in Bezug auf Raum und Zeit bestimmen 611.
Der Prozess berechnet 613 weiterhin die Wahrscheinlichkeitsverteilung der angeforderten meteorologischen Werte (z. B. Temperatur, Luftdruck usw.) an der Raum-Zeit-Position. Anschließend erhöht der Prozess die freien Raum- und Zeit-Parameter, wodurch eine neue Position zu einem neuen Zeitpunkt definiert wird. Wenn der gesamte, durch die Anforderung definierte freie Parameterraum abgetastet 617 wurde, kann der Prozess Parameter (wie etwa eine Spline-Kurve), welche die prognostizierten meteorologischen Werte über den durch die Anforderung definierten Bereich von Raum und Zeit definieren, zurücksetzen 619.
In diesem Beispiel kann das verbrauchende (anfordernde) Modul ein mathematisches Modell mit einer festgelegten Dimensionalität und einem Bereich für die freien Parameter enthalten. Wenn es sich bei der Antwort um eine Spline-Kurve handelt, erfolgt diese über den freien Parameterraum, der freie Parameter für eine Verteilungsfunktion berechnet. Zum Beispiel könnte es sich bei der Antwort um zwei Spline-Kurven im freien Raum-Zeit-Parameterraum handeln, wobei eine für den α-Parameter einer Beta-Verteilung und eine Kurve für den β-Parameter der Beta-Verteilung steht. Somit gibt es für einen beliebigen Punkt in dem freien Raum-Zeit-Parameterbereich ein sich ergebendes (α, β), das zum Berechnen der Beta-Verteilung für diesen Punkt verwendet werden kann.
Durch die Verwendung der veranschaulichenden Ausführungsformen kann ein Fahrzeug periodisch aktualisierte Wettermuster von einem Fernserver empfangen und diese Daten verwenden, um vorhergesagte Wetterparameter entlang eines gegebenen Pfades zu modellieren. Das Modell ist in der Lage, sich an sich ändernde Bedingungen anzupassen, und kann als Reaktion darauf Daten ändern und/oder aktualisierte Daten anfordern, wenn das Wetter von den Prognosen abweicht. Durch die gemeinsame Nutzung von Sensoren braucht das Fahrzeug oftmals keine vollständige Palette von fahrzeuginternen Sensoren, um genug reale Daten zum Anpassen des Modells zu sammeln.
Obgleich vorstehend beispielhafte Ausführungsformen beschrieben sind, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Beschreibung verwendeten Ausdrücke beschreibende und keine einschränkenden Ausdrücke und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Geist und Umfang der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener umsetzender Ausführungsformen auf logische Weise kombiniert werden, um situationsgerechte Variationen von hier beschriebenen Ausführungsformen zu bilden.
Gemäß der vorliegenden Erfindung ist ein System mit einem Prozessor bereitgestellt, der dazu konfiguriert ist: von einem entfernten Wetterserver Wetterdaten zu empfangen, die eine Vielzahl von gemessenen Datenpunkten in einem Gebiet um ein Fahrzeug herum beinhalten; einen Pfad von einem Fahrzeugteilsystem zu empfangen; die Datenpunkte und den Pfad zu kombinieren, um ein Vorhersagemodell zu bilden, das die erwarteten Wetterbedingungen entlang des Pfades zu zukünftigen Zeitpunkten wiedergibt, wobei das Modell auf vordefinierten Parametern basiert, die ein erwartetes Wetterverhalten definieren; und das Modell an ein anforderndes Fahrzeugteilsystem zu senden.
Gemäß einer Ausführungsform ist der Prozessor dazu konfiguriert, das Vorhersagemodell in Form eines kubischen Splines, der den geografischen Breitengrad, den geografischen Längengrad, die Höhenlage und den Zeitpunkt repräsentiert, zu bilden. Gemäß einer Ausführungsform repräsentiert der kubische Spline einen Aspekt des Wetters.
Gemäß einer Ausführungsform beinhaltet der Aspekt des Wetters Temperatur.
Gemäß einer Ausführungsform beinhaltet der Aspekt des Wetters Luftdruck.
Gemäß einer Ausführungsform beinhaltet der Aspekt des Wetters Sichtbarkeit.
Gemäß einer Ausführungsform beinhaltet der Aspekt des Wetters Luftfeuchtigkeit.
Gemäß einer Ausführungsform beinhaltet der Aspekt des Wetters einen geschätzten Straßenreibungskoeffizienten.
Gemäß einer Ausführungsform beinhaltet der Aspekt des Wetters Niederschlag.
Gemäß einer Ausführungsform beinhaltet der Aspekt des Wetters Windgeschwindigkeit und -richtung.
Gemäß einer Ausführungsform ist der Prozessor ferner dazu konfiguriert: einen Echtzeit-Wert eines oder mehrerer Aspekte der erwarteten Wetterbedingungen zu erlangen; den Echtzeit-Wert mit einem von dem Modell abgeleiteten erwarteten Wert zu vergleichen; eine Straffunktion basierend auf einer Abweichung zwischen dem Echtzeit-Wert und dem erwarteten Wert zuzuweisen; und die vordefinierten Parameter einzustellen, um den erwarteten Wert einzustellen, bis die sich aus dem Vergleich ergebende Straffunktion unter einem vordefinierten Schwellenwert liegt.
Gemäß einer Ausführungsform ist der Prozessor dazu konfiguriert, den Echtzeit-Wert von einem fahrzeuginternen Sensor zu erlangen.
Gemäß einer Ausführungsform ist der Prozessor dazu konfiguriert, den Echtzeit-Wert drahtlos von einem Fahrzeug in unmittelbarer Nähe zu erlangen.
Gemäß einer Ausführungsform ist der Prozessor dazu konfiguriert, vor dem drahtlosen Erlangen des Echtzeit-Wertes zu bestimmen, ob sich das Fahrzeug in unmittelbarer Nähe innerhalb einer vordefinierten unmittelbaren Nähe befindet, was durch eine empfange Signalstärke bestimmt wird.
Gemäß einer Ausführungsform variiert die vordefinierte unmittelbare Nähe basierend auf einem Aspekt des Wetters, auf den sich der Echtzeit-Wert bezieht.
Gemäß der vorliegenden Erfindung ist ein computerimplementiertes Verfahren bereitgestellt, das Folgendes aufweist: Modellieren einer Vielzahl von erwarteten Werten für einen Wetteraspekt basierend auf von einem Fernserver empfangenen gemessenen Datenpunkten und vordefinierten Modellierungsparametern, einschließlich des Variierens der vordefinierten Parameter, um die Vielzahl von erwarteten Werten zu erzeugen; Vergleichen eines in Echtzeit gemessenen Aspektwertes mit einem modellierten erwarteten Aspektwert für jeden der Vielzahl von erwarteten Werten; und Auswählen eines modifizierten Parametersatzes, der dem erwarteten Wert entspricht, welcher die geringste Differenz von dem Echtzeit-Wert aufweist.
Gemäß einer Ausführungsform ist das Verfahren ferner gekennzeichnet durch Verwenden des ausgewählten Parametersatzes, um das Wetter entlang des Fahrzeugpfades zu modellieren; und Bereitstellen des modellierten Wetters entlang des Fahrzeugpfades an ein anforderndes Fahrzeugteil system.
Gemäß einer Ausführungsform ist das Verfahren ferner gekennzeichnet durch: Sammeln von Echtzeit-Aspektwerten, während das Fahrzeug den Fahrzeugpfad entlangfährt; Vergleichen der gesammelten Echtzeit-Aspektwerte mit erwarteten Werten von dem modellierten Wetter entlang des Fahrzeugpfades; und Wiederholen der Schritte des Modellierens, des Vergleichens des in Echtzeit gemessenen Aspektwertes mit dem modellierten erwarteten Aspektwert für jeden der Vielzahl von erwarteten Werten und des Auswählens als Reaktion auf eine Abweichung über einem Schwellenwert zwischen den gesammelten Echtzeit-Aspektwerten und den sich aus dem modellierten Wetter entlang des Fahrzeugpfades ergebenden erwarteten Werten.
Gemäß einer Ausführungsform wird der Echtzeit-Wert drahtlos von einem Fahrzeug in unmittelbarer Nähe gesammelt, und ferner beinhaltet das Verfahren Bestimmen vor dem drahtlosen Erlangen des Echtzeit-Wertes, ob sich das Fahrzeug in unmittelbarer Nähe innerhalb einer vordefinierten unmittelbaren Nähe befindet, was durch eine empfange Signalstärke oder durch spezielle Koordinaten bestimmt wird, wobei die vordefinierte unmittelbare Nähe basierend auf einem Aspekt des Wetters, auf den sich der Echtzeit-Wert bezieht, variiert.
Gemäß der vorliegenden Erfindung ist ein System mit einem Prozessor bereitgestellt, der dazu konfiguriert ist: eine Vielzahl von Wetteraspekten über einen von einem Fahrzeugteilsystem empfangenen Fahrzeugpfad basierend auf von einem Fernserver empfangenen Datenpunkten und vordefinierten Modellierungsparametern zu modellieren; fahrzeuginterne Wettermodellparameter einzustellen, während ein Fahrzeug den Pfad entlangfährt, um ein Wettermodell beizubehalten, für das periodische Echtzeit-Messungen im Vergleich zu von dem Wettermodell erlangten erwarteten Werten unter einer Schwellenwertabweichung liegen.

Claims

System, umfassend: einen Prozessor, der zu Folgendem konfiguriert ist: Empfangen von Wetterdaten, die eine Vielzahl von gemessenen Datenpunkten in einem Gebiet um ein Fahrzeug herum von einem entfernten Wetterserver beinhalten; Empfangen eines Pfades von einem Fahrzeugteilsystem; Kombinieren der Datenpunkte und des Pfades, um ein Vorhersagemodell zu bilden, das die erwarteten Wetterbedingungen entlang des Pfades zu zukünftigen Zeitpunkten wiedergibt, wobei das Modell auf vordefinierten Parametern basiert, die ein erwartetes Wetterverhalten definieren; und Senden des Modells an ein anforderndes Fahrzeugteilsystem.
System nach Anspruch 1, wobei der Prozessor dazu konfiguriert ist, das Vorhersagemodell in Form eines kubischen Splines, der den geografischen Breitengrad, den geografischen Längengrad, die Höhenlage und den Zeitpunkt repräsentiert, zu bilden.
System nach Anspruch 2, wobei der kubische Spline einen Aspekt des Wetters repräsentiert.
System nach Anspruch 3, wobei der Aspekt des Wetters Temperatur beinhaltet.
System nach Anspruch 3, wobei der Aspekt des Wetters Luftdruck beinhaltet.
System nach Anspruch 3, wobei der Aspekt des Wetters Luftfeuchtigkeit beinhaltet.
System nach Anspruch 3, wobei der Aspekt des Wetters Niederschlag beinhaltet.
System nach Anspruch 1, wobei der Prozessor ferner konfiguriert ist zum: Erlangen eines Echtzeit-Wertes eines oder mehrerer Aspekte der erwarteten Wetterbedingungen; Vergleichen des Echtzeit-Wertes mit einem von dem Modell abgeleiteten erwarteten Wert; Zuweisen einer Straffunktion basierend auf einer Abweichung zwischen dem Echtzeit-Wert und dem erwarteten Wert; und Einstellen der vordefinierten Parameter, um den erwarteten Wert einzustellen, bis die sich aus dem Vergleich ergebende Straffunktion unter einem vordefinierten Schwellenwert liegt.
System nach Anspruch 8, wobei der Prozessor dazu konfiguriert ist, den Echtzeit-Wert von einem fahrzeuginternen Sensor zu erlangen.
System nach Anspruch 8, wobei der Prozessor dazu konfiguriert ist, den Echtzeit-Wert drahtlos von einem Fahrzeug in unmittelbarer Nähe zu erlangen.
System nach Anspruch 10, wobei der Prozessor dazu konfiguriert ist, vor dem drahtlosen Erlangen des Echtzeit-Wertes zu bestimmen, ob sich das Fahrzeug in unmittelbarer Nähe innerhalb einer vordefinierten unmittelbaren Nähe befindet, was durch eine empfange Signalstärke bestimmt wird.
System nach Anspruch 10, wobei die vordefinierte unmittelbare Nähe basierend auf einem Aspekt des Wetters, auf den sich der Echtzeit-Wert bezieht, variiert.
Computerimplementiertes Verfahren, umfassend: Modellieren einer Vielzahl von erwarteten Werten für einen Wetteraspekt basierend auf von einem Fernserver empfangenen gemessenen Datenpunkten und vordefinierten Modellierungsparametern, einschließlich des Variierens der vordefinierten Parameter, um die Vielzahl von erwarteten Werten zu erzeugen; Vergleichen eines in Echtzeit gemessenen Aspektwertes mit einem modellierten erwarteten Aspektwert für jeden der Vielzahl von erwarteten Werten; und Auswählen eines modifizierten Parametersatzes, der dem erwarteten Wert entspricht, welcher die geringste Differenz von dem Echtzeit-Wert aufweist.
Verfahren nach Anspruch 13, ferner umfassend: Verwenden des ausgewählten Parametersatzes, um das Wetter entlang des Fahrzeugpfades zu modellieren; und Bereitstellen des modellierten Wetters entlang des Fahrzeugpfades an ein anforderndes Fahrzeugteil system.
Verfahren nach Anspruch 14, ferner umfassend: Sammeln von Echtzeit-Aspektwerten, während das Fahrzeug den Fahrzeugpfad entlangfährt; Vergleichen der gesammelten Echtzeit-Aspektwerte mit erwarteten Werten von dem modellierten Wetter entlang des Fahrzeugpfades; und Wiederholen der Schritte des Modellierens, des Vergleichens des in Echtzeit gemessenen Aspektwertes mit dem modellierten erwarteten Aspektwert für jeden der Vielzahl von erwarteten Werten und des Auswählens als Reaktion auf eine Abweichung über einem Schwellenwert zwischen den gesammelten Echtzeit-Aspektwerten und den sich aus dem modellierten Wetter entlang des Fahrzeugpfades ergebenden erwarteten Werten.