DE102016102618A1

DE102016102618A1 - Verfahren und Vorrichtung für voraussagende Fahrzeug-Vorkonditionierung

Info

Publication number: DE102016102618A1
Application number: DE102016102618.2A
Authority: DE
Inventors: Fling Finn Tseng; Hsin-Hsiang Yang; Aed M. Dudar; Dimitar Petrov Filev; Johannes Geir Kristinsson
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2015-02-20
Filing date: 2016-02-15
Publication date: 2016-08-25
Also published as: US10343633B2; US20160244010A1; CN105905052A; CN105905052B

Abstract

Ein System beinhaltet einen Prozessor, der dafür ausgelegt ist, auf einen Zeitplan von Fahrzeugstartzeiten zuzugreifen. Der Prozessor ist auch dafür ausgelegt, eine geplante Schlüssel-An-Zeit auszuwählen, wenn eine aktuelle Zeit innerhalb einer abstimmbaren Nähe zu der geplanten Schlüssel-An-Zeit liegt. Ferner ist der Prozessor dafür ausgelegt, zu bestimmen, ob eine gegenwärtige fahrzeugbezogene Temperatur Fahrzeug-Vorkonditionierung rechtfertigt und das Fahrzeug vorzukonditionieren, bis voreingestellte Vorkonditionierungseinstellungen erreicht sind.

Description

TECHNISCHES GEBIET
Die veranschaulichenden Ausführungsformen betreffen allgemein ein Verfahren und eine Vorrichtung für voraussagende Fahrzeug-Vorkonditionierung.
HINTERGRUND
Das Fahrererlebnis ist für Automobil-Erstausrüster (Automobil-OEM) sehr wichtig. Das Erlebnis, das ein Fahrer mit einem Fahrzeug hat, kann künftige Verkäufe, positive Mundpropaganda und ganz allgemein die Reputation des OEM beeinflussen. Dementsprechend sind die OEMs ständig auf der Ausschau nach Wegen, das Im-Fahrzeug-Erlebnis zu verbessern.
Da Fahrzeuge zur Verwendung in einer Vielfalt von Klimata gekauft werden, können von verschiedenen Fahrern unterschiedliche Auswahlen getroffen werden, basierend auf einem anfänglichen Komfortniveau wenn in ein Fahrzeug eingestiegen wird. Das heißt, dass Fahrer in einem heißen Klima mit jeder Menge Sonne dunkle Sitze meiden, die sich leicht aufheizen können. In einem kalten Klima können Ledersitze gemieden werden, da Leder dazu neigt, sich bei erstem Kontakt kälter als Stoff anzufühlen.
Viele dieser Auswahlen, und viel anfängliche Unbequemlichkeit, könnten abgemildert oder beseitigt werden, wenn das Fahrzeug komfortabel gemacht würde, bevor der Fahrer in das Fahrzeug einsteigt. Zusätzlich könnte auch die Batterieeffizienz verbessert werden, wenn sich das Fahrzeug im Vorfeld der Nutzung aufwärmen oder abkühlen könnte.
KURZFASSUNG
In einer ersten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der dafür ausgelegt ist, auf einen Zeitplan von Fahrzeugstartzeiten zuzugreifen. Der Prozessor ist auch dafür ausgelegt, eine geplante Schlüssel-An-Zeit auszuwählen, wenn eine aktuelle Zeit innerhalb einer abstimmbaren Nähe zu der geplanten Schlüssel-An-Zeit liegt. Ferner ist der Prozessor dafür ausgelegt, zu bestimmen, ob eine gegenwärtige fahrzeugbezogene Temperatur Fahrzeug-Vorkonditionierung rechtfertigt und das Fahrzeug vorzukonditionieren bis voreingestellte Vorkonditionierungseinstellungen erreicht sind.
In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren das Analysieren eines Zeitintervalls, um zu bestimmen, ob ein Schlüssel-An-Ereignis aufgetreten ist. Das Verfahren beinhaltet auch das Aktualisieren einer Aufzeichnung von Schlüssel-An-Ereignissen mit dem Auftreten/Nichtauftreten eines Schlüssel-An-Ereignisses, um eine Wahrscheinlichkeit eines Schlüssel-An während des Zeitintervalls zu erstellen. Das Verfahren beinhaltet ferner das Zusammenstellen eines Zeitplans einer Vielzahl von vorhergesagten Schlüssel-An-Zeitintervallen, basierend auf vorhergesagter Wahrscheinlichkeit eines Schlüssel-An, während jedes aus der Vielzahl von vorhergesagten Schlüssel-An-Zeitintervallen, und das Benachrichtigen eines Fahrers über jegliche bestimmte Abweichungen zwischen dem zusammengestellten Zeitplan und einem vom Fahrer eingegebenen Zeitplan von geplanten Schlüssel-An-Ereignissen.
In einer dritten veranschaulichenden Ausführungsform speichert ein nichtvergängliches computerlesbares Speichermedium Anweisungen, die, wenn ausgeführt, einen Prozessor veranlassen, ein Verfahren durchzuführen, das das Analysieren eines Zeitintervalls beinhaltet, um zu bestimmen, ob ein Schlüssel-An-Ereignis aufgetreten ist. Das Verfahren beinhaltet auch das Aktualisieren einer Aufzeichnung von Schlüssel-An-Ereignissen mit dem Auftreten/Nichtauftreten eines Schlüssel-An-Ereignisses, um eine Wahrscheinlichkeit eines Schlüssel-An während des Zeitintervalls zu erstellen. Das Verfahren beinhaltet ferner das Zusammenstellen eines Zeitplans einer Vielzahl von vorhergesagten Schlüssel-An-Zeitintervallen, basierend auf vorhergesagter Wahrscheinlichkeit eines Schlüssel-An, während jedes aus der Vielzahl von vorhergesagten Schlüssel-An-Zeitintervallen, und das Benachrichtigen eines Fahrers über jegliche bestimmte Abweichungen zwischen dem zusammengestellten Zeitplan und einem vom Fahrer eingegebenen Zeitplan von geplanten Schlüssel-An-Ereignissen.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein veranschaulichendes Fahrzeugcomputersystem;
2 zeigt ein veranschaulichendes Beispiel für Schlüssel-An-Timing-Lernen;
3 zeigt eine veranschaulichende Aktualisierung für Schlüssel-An-Timing;
4 zeigt einen veranschaulichenden Prozess zum Vorhersagen eines kommenden Schlüssel-Ans;
5A und 5B zeigen einen veranschaulichenden Vorkonditionierungsprozess; und
6 zeigt einen veranschaulichenden Zeitplanaktualisierungsprozess.
DETAILLIERTE BESCHREIBUNG
Wie erforderlich, werden hier detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen rein beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen ausgestaltet werden kann. Die Figuren sind nicht notwendigerweise maßstabsgetreu; einige Merkmale können übertrieben oder minimiert sein, um Details besonderer Komponenten zu zeigen. Spezielle strukturelle und funktionale Details, die hier offenbart werden, sollen daher nicht als einschränkend interpretiert werden, sondern lediglich als eine repräsentative Basis, um einen Fachmann zu lehren, wie die vorliegende Erfindung auf verschiedene Weisen auszuüben ist.
1 stellt eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Computersystem 1 (VCS, Vehicle based Computing System) für ein Fahrzeug 31 dar. Ein Beispiel für solch ein fahrzeugbasiertes Computersystem 1 ist das von der FORD MOTOR COMPANY hergestellte SYNC-System. Ein mit einem fahrzeugbasierten Computersystem aktiviertes Fahrzeug umfasst möglicherweise eine visuelle Frontend-Schnittstelle 4, die sich im Fahrzeug befindet. Der Nutzer ist möglicherweise außerdem in der Lage, mit der Schnittstelle zu interagieren, wenn sie zum Beispiel mit einem berührungsempfindlichen Bildschirm versehen ist. In einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion durch das Drücken von Tasten, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
In der in 1 gezeigten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 wenigstens einen Teil des Betriebs des fahrzeugbasierten Computersystems. Der Prozessor, der innerhalb des Fahrzeugs bereitgestellt ist, gestattet Bord-Verarbeitung von Befehlen und Routinen. Weiterhin ist der Prozessor sowohl mit nichtpersistentem 5 als auch mit persistentem Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der nichtpersistente Speicher Direktzugriffsspeicher (RAM) und der persistente Speicher ist ein Festplattenlaufwerk (HDD) oder Flash-Speicher. Im Allgemeinen kann persistenter (nichtflüchtiger) Speicher alle Arten von Speicher enthalten, die Daten behalten, wenn ein Computer oder eine andere Vorrichtung heruntergefahren wird. Zu diesen zählen, unter anderem, HDDs, CDs, DVDs, Magnetbänder, Solid-State-Drives, tragbare USB-Laufwerke und andere geeignete Arten von persistentem Speicher.
Der Prozessor ist außerdem mit einer Anzahl von unterschiedlichen Eingängen versehen, die es dem Nutzer ermöglichen, mit dem Prozessor in Verbindung zu treten. In dieser veranschaulichenden Ausführungsform werden ein Mikrofon 29, ein Zusatzeingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der möglicherweise eine Touchscreen-Anzeige ist, und ein BLUETOOTH-Eingang 15 bereitgestellt. Es ist auch ein Eingangswähler 51 vorgesehen, der es einem Nutzer ermöglicht, zwischen verschiedenen Eingängen zu wechseln. Eingaben sowohl in das Mikrofon als auch in den Zusatzverbinder werden durch einen Wandler 27 von analog nach digital gewandelt, bevor sie an den Prozessor weitergeleitet werden. Obwohl dies nicht gezeigt wird, verwenden möglicherweise zahlreiche der Fahrzeugkomponenten und Zusatzkomponenten in Kommunikation mit dem VCS ein Fahrzeugnetz (wie zum Beispiel, aber nicht darauf beschränkt, einen CAN-Bus), um Daten zum und aus dem VCS (oder Komponenten davon) weiterzuleiten.
Zu Ausgängen des Systems können, unter anderem, eine visuelle Anzeige 4 und ein Lautsprecher 13 oder ein Stereo-Systemausgang zählen. Der Lautsprecher ist mit einem Verstärker 11 verbunden und nimmt sein Signal von dem Prozessor 3 durch einen Digital-Analog-Wandler 9 auf. Ausgaben können auch zu einer entfernten BLUETOOTH-Vorrichtung, wie etwa zu einem PND 54 oder einer USB-Vorrichtung, wie etwa der Fahrzeug-Navigationsvorrichtung 60, entlang den bei 19 bzw. 21 gezeigten bidirektionalen Datenströmen erfolgen.
In einer veranschaulichenden Ausführungsform verwendet das System 1 den Bluetooth-Transceiver 15, um mit einer nomadischen Vorrichtung 53 des Nutzers zu kommunizieren 17 (z. B. einem Mobiltelefon, Smartphone, PDA oder irgendeiner anderen Vorrichtung, die drahtlose Konnektivität zu entfernten Netzwerken aufweist). Die nomadische Vorrichtung kann dann verwendet werden, um mit einem Netz 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59, zum Beispiel durch Kommunikation 55 mit einem Mobilfunkturm 57. In einigen Ausführungsformen kann der Turm 57 ein WiFi-Zugangspunkt sein.
Beispielhafte Kommunikation zwischen der nomadischen Vorrichtung und dem BLUETOOTH-Transceiver wird durch das Signal 14 dargestellt.
Das Paaren einer nomadischen Vorrichtung 53 und des BLUETOOTH-Transceivers 15 kann durch eine Taste 52 oder eine ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der Bord-BLUETOOTH-Transceiver mit einem BLUETOOTH-Transceiver in einer nomadischen Vorrichtung gepaart wird.
Daten werden möglicherweise zwischen der CPU 3 und dem Netz 61 zum Beispiel unter Verwendung eines mit der nomadischen Vorrichtung 53 assoziierten Datentarifs, Data Over Voice oder von DTMF-Tönen kommuniziert. Alternativ kann es wünschenswert sein, ein Bord-Modem 63 mit einer Antenne 18 einzubauen, um Daten zwischen der CPU 3 und dem Netz 61 über das Sprachband zu kommunizieren 16. Die nomadische Vorrichtung 53 kann dann verwendet werden, um mit einem Netz 61 außerhalb des Fahrzeugs 31 zum Beispiel durch Kommunikation 55 mit einem Mobilfunkturm 57 zu kommunizieren 59. In einigen Ausführungsformen kann das Modem 63 Kommunikation 20 mit dem Turm 57 zum Kommunizieren mit dem Netz 61 herstellen. Als ein nicht einschränkendes Beispiel ist das Modem 63 möglicherweise ein Mobilfunk-USB-Modem und die Kommunikation 20 ist möglicherweise eine Mobilfunk-Kommunikation.
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem versehen, das eine API zum Kommunizieren mit Modem-Anwendungssoftware beinhaltet. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder eine eingebettete Firmware auf dem BLUETOOTH-Transceiver zugreifen, um drahtlose Kommunikation mit einem entfernten BLUETOOTH-Transceiver (wie zum Beispiel einem, der in einer nomadischen Vorrichtung vorzufinden ist) herzustellen. Bluetooth ist eine Untermenge der IEEE 802 PAN(Personal Area Network)-Protokolle. IEEE 802 LAN(Local Area Network)-Protokolle beinhalten WiFi und weisen beträchtliche übergreifende Funktionalitäten mit IEEE 802 PAN auf. Beide sind zur drahtlosen Kommunikation innerhalb eines Fahrzeugs geeignet. Andere Kommunikationsmittel, die auf diesem Gebiet verwendet werden können, sind optische Freiraumkommunikation (wie zum Beispiel IrDA, Infrared Data Association) und nicht standardisierte IR(Infrarot)-Protokolle im Bereich der Unterhaltungselektronik.
In einer anderen Ausführungsform umfasst die nomadische Vorrichtung 53 ein Modem für Sprachband- oder Breitband-Datenkommunikation. In der Ausführungsform Data Over Voice wird möglicherweise eine als Frequenzmultiplexen bekannte Technik umgesetzt, wenn der Besitzer der nomadischen Vorrichtung über die Vorrichtung sprechen kann, während Daten übertragen werden. Zu anderen Zeitpunkten, wenn der Besitzer die Vorrichtung nicht verwendet, kann die Datenübertragung die gesamte Bandbreite verwenden (in einem Beispiel 300 Hz bis 3,4 kHz). Während Frequenzmultiplexen möglicherweise für analoge zellulare Kommunikation zwischen dem Fahrzeug und dem Internet üblich ist und immer noch verwendet wird, ist es für digitale zellulare Kommunikation weitgehend durch Mischformen aus Codemultiplexverfahren (CDMA, Code Division Multiple Access), Zeitmultiplexverfahren (TDMA, Time Division Multiple Access), Raummultiplexverfahren (SDMA, Space Domain Multiple Access) ersetzt worden. All diese sind Standards entsprechend ITU IMT-2000 (3G) und bieten Datenraten bis zu 2 Mbps für stationäre oder gehende Nutzer und 385 kbps für Nutzer in einem sich bewegenden Fahrzeug. 3G-Standards werden jetzt durch IMT-Advanced (4G) ersetzt, das 100 Mbps für Nutzer in einem Fahrzeug und 1 Gbps für stationäre Nutzer bietet. Falls der Nutzer über einen mit der nomadischen Vorrichtung verknüpften Datentarif verfügt, ist es möglich, dass der Datentarif Breitband-Übertragung gestattet und dass das System eine viel größere Bandbreite verwenden könnte (was die Datenübertragung beschleunigt). In noch einer anderen Ausführungsform ist die nomadische Vorrichtung 53 durch eine Mobilfunk-Kommunikationsvorrichtung (nicht dargestellt) ersetzt, die im Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform ist die ND (Nomadic Device, nomadische Vorrichtung) 53 möglicherweise eine drahtlose Local Area Network(LAN)-Vorrichtung, die zur Kommunikation zum Beispiel (und ohne Beschränkung) über ein 802.11g-Netzwerk (d.h. WiFi) oder ein WiMax-Netzwerk in der Lage ist.
In einer Ausführungsform können eingehende Daten durch die nomadische Vorrichtung über Data Over Voice oder Datentarif, durch den Bord-BLUETOOTH-Transceiver und in den internen Prozessor 3 des Fahrzeugs weitergegeben werden. Im Falle bestimmter temporärer Daten können die Daten zum Beispiel bis zu einem Zeitpunkt, zu dem die Daten nicht mehr benötigt werden, auf dem HDD oder anderen Speichermedien 7 gespeichert werden.
Zu zusätzlichen Quellen, die möglicherweise mit dem Fahrzeug in Verbindung stehen, zählen eine persönliche Navigationsvorrichtung 54, die zum Beispiel eine USB-Verbindung 56 und/oder eine Antenne 58 aufweist, eine Fahrzeug-Navigationsvorrichtung 60, die eine USB-Verbindung 62 oder eine andere Verbindung aufweist, eine Bord-GPS-Vorrichtung 24 oder ein entferntes Navigationssystem (nicht dargestellt), das Konnektivität zum Netz 61 aufweist. USB ist eines aus einer Klasse von seriellen Netzwerkprotokollen. IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), EIA (Electronics Industry Association) serielle Protokolle, IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der Standards für serielle Kommunikation von Vorrichtung zu Vorrichtung. Die meisten der Protokolle können entweder für elektrische oder optische Kommunikation implementiert werden.
Ferner könnte die CPU mit einer Vielzahl anderer Hilfsvorrichtungen 65 in Kommunikation stehen. Diese Vorrichtungen können über eine drahtlose 67 oder eine drahtgebundene 69 Verbindung verbunden werden. Die Hilfsvorrichtungen 65 können Personal Media Player, drahtlose medizinische Vorrichtungen, tragbare Computer und dergleichen beinhalten, ohne darauf beschränkt zu sein.
Ebenso oder alternativ könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 zum Beispiel unter Verwendung eines WiFi-Transceivers (IEEE 803.11) 71 verbunden werden. Dies könnte es der CPU gestatten, sich mit in Reichweite des lokalen Routers 73 befindlichen entfernten Netzen zu verbinden.
Zusätzlich dazu, dass beispielhafte Prozesse von einem Fahrzeugcomputersystem, das sich in einem Fahrzeug befindet, ausgeführt werden, können die beispielhaften Prozesse in gewissen Ausführungsformen von einem Computersystem ausgeführt werden, das in Kommunikation mit einem Fahrzeugcomputersystem steht. Solch ein System kann, ohne darauf beschränkt zu sein, eine drahtlose Vorrichtung (z. B. und ohne Beschränkung ein Mobiltelefon) oder ein entferntes Computersystem (z. B. und ohne Beschränkung einen Server) umfassen, die durch die drahtlose Vorrichtung verbunden sind. Gemeinschaftlich können solche Systeme als fahrzeugassoziierte Computersysteme (VACS, Vehicle Associated Computing Systems) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS abhängig von der jeweiligen Implementierung des Systems bestimmte Teile eines Prozesses durchführen. Beispielhaft und ohne Beschränkung ist es, falls ein Prozess einen Schritt aufweist, in dem er Informationen an eine bzw. von einer gekoppelten drahtlosen Vorrichtung sendet oder empfängt, dann wahrscheinlich, dass die drahtlose Vorrichtung diesen Teil des Prozesses nicht durchführt, weil die drahtlose Vorrichtung Informationen nicht an sich selbst "senden" und nicht von sich selbst "empfangen" würde. Ein Durchschnittsfachmann weiß, wann es ungeeignet ist, ein bestimmtes Computersystem auf eine gegebene Lösung anzuwenden.
In jeder der hier erörterten veranschaulichenden Ausführungsformen wird ein beispielhaftes, nicht beschränkendes Beispiel für einen Prozess, der von einem Computersystem durchführbar ist, gezeigt. Bezüglich jedes Prozesses ist es dem Computersystem, das den Prozess ausführt, möglich, für den begrenzten Zweck des Ausführens des Prozesses, als ein Sonderzweck-Prozessor konfiguriert zu werden, um den Prozess durchzuführen. Nicht alle Prozesse müssen in ihrer Gesamtheit durchgeführt werden und sind als Beispiele von Typen von Prozessen, die durchgeführt werden können, um Elemente der Erfindung zu erreichen, zu verstehen. Zusätzliche Schritte können auf Wunsch hinzugefügt oder aus den beispielhaften Prozessen entfernt werden.
Moderne Fahrzeuge sind mit Telematiksystemen ausgestattet, die Kommunikation zwischen dem Fahrzeug und entfernten Systemen ermöglichen. Manche Beispiele dieser Kommunikationsfähigkeit sind mit Bezug auf die obige 1 gezeigt. Andere Typen von Fernkommunikation werden ebenfalls ständig zu Telematiksystem hinzugefügt. Mit zunehmender Fähigkeit der Systeme zur Kreuzkommunikation ist es zum Beispiel für Heimsysteme möglich, zu Fahrzeugsystemen zu sprechen, um weitere gemeinsame Informationsnutzung zu fördern.
In den veranschaulichenden Beispielen verfügt ein Benutzer möglicherweise über einen Kalender oder andere Plananzeiger, die geplante Startzeiten für Fahrzeugnutzung repräsentieren. Falls ein Benutzer zum Beispiel von Montag bis Freitag um 7 Uhr morgens zur Arbeit geht und um 6 Uhr abends die Arbeit verlässt, dann kann der Kalender diese Zeiten angeben. Andere Zeiten können zum Beispiel das Fahren eines Kindes zu Terminen, zur Schule usw. beinhalten. Jegliches sich normalerweise wiederholende Ereignis kann in dem Kalender verfolgt werden sowie einmalige Ereignisse, die lediglich ein- oder zweimal auftreten.
Dieser Kalender könnte in einer mobilen Anwendung oder auf einer Webseite ausgefüllt werden, und auf die in dem Kalender wiedergegebenen Informationen könnte von dem Fahrzeug aus zugegriffen werden (aus der Ferne oder zu dem Fahrzeug übertragen). Diese Informationen könnten als eine Grundlage zum Bestimmen verwendet werden, wann ein Fahrzeugstart wahrscheinlich auftreten würde.
In anderen Beispielen mag ein Benutzer möglicherweise keinen Kalender ausfüllen wollen oder nicht wissen, wie man einen Kalender ausfüllt. In solchen Fällen kann ein Fahrzeug versuchen, basierend auf vorhergesagten Startzeiten, die von beobachtetem Verhalten abgeleitet werden, vorherzusagen, ob ein Benutzer das Fahrzeug benutzen wird oder nicht. Das Fahrzeug kann, basierend auf beobachtetem Verhalten, ein Modell eines zeitlichen Benutzerverhaltens erstellen und kann somit mit einigem Grad an Erfolg vorhersagen, ob ein Benutzer in Fahrzeugnutzung eintreten wird oder nicht.
Sobald der Prozess weiß (anhand eines Kalenders oder basierend auf beobachtetem Verhalten), ob ein Fahrzeug benutzt werden wird oder nicht, kann der Prozess in das Vorkonditionieren des Fahrzeugs eintreten. Dies könnte so einfach sein wie das Einstellen des Fahrzeuginnern auf eine gewünschte Temperatur oder könnte das Aufwärmen/Abkühlen der Batterie, Aufwärmen/Abkühlen der Sitze, Öffnen der Fenster, Enteisen einer Windschutzscheibe usw. beinhalten. Dies kann sowohl das Fahrererlebnis verbessern und kann, bezüglich der Batterie, helfen, die Batterieeffizienz und Ladungausnutzung zu verbessern.
2 zeigt ein veranschaulichendes Beispiel für Schlüssel-An-Timing-Lernen. Bezüglich den in dieser Figur beschriebenen veranschaulichenden Ausführungsformen sei angemerkt, dass ein Allzweckprozessor zum Zwecke des Ausführens einiger oder aller der hier gezeigten Beispielverfahren zeitweilig als ein Sonderzweck-Prozessor befähigt werden kann. Wenn Code, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, ausgeführt wird, kann der Prozessor zeitweilig als ein Sonderzweck-Prozessor umgewidmet werden, bis zum Zeitpunkt, zu dem das Verfahren abgeschlossen ist. In einem weiteren Beispiel kann, soweit angebracht, Firmware, die gemäß einem vorkonfigurierten Prozessor handelt, den Prozessor veranlassen, als ein Sonderzweck-Prozessor zu handeln, der für den Zweck des Durchführens des Verfahrens oder einer beliebigen sinnvollen Variante davon bereitgestellt ist.
In dem veranschaulichen, vereinfachenden in 2 gezeigten Beispiel evaluiert das Fahrzeug oder ein fahrzeugbezogenes System (z.B. eine mobile Vorrichtung, die mit dem Fahrzeug, einem Fernserver usw. kommuniziert) ein einzelnes oder eine Folge von Zeitintervall(en) 201. Zum Beispiel könnte diese Evaluation uneingeschränkt jeden Tag zu irgendeiner festen Zeit oder wenn Rechenleistung verfügbar wäre usw. vorgenommen werden. Der Prozess könnte auch fortlaufend sein und im Tagesverlauf aktualisiert werden.
Der Prozess bestimmt für ein gegebenes Zeitintervall, ob ein Fahrzeug während des Intervalls Schlüssel-An geschaltet wurde 203. In diesem Beispiel wird ein Tag in eine Folge von Zeitintervallen unterteilt und jegliches Schlüssel-An während des Zeitintervalls "addiert" zu der Wahrscheinlichkeit von zukünftigen Schlüssel-An während dieses Zeitintervalls. Da es eine lange Zeit dauern würde, das Verhaltensmuster eines einzelnen Benutzers für exakte Zeiten zu lernen, und da Leute im Allgemeinen zu einer ungefähren Zeit (d.h., dass eine Abfahrt um 7 Uhr morgens an einem Tag 6:58 Uhr morgens und 7:02 Uhr morgens am nächsten Tag sein kann) aufbrechen, kann es genauer und angenehmer sein, projizierte Abfahrtzeiten basierend auf Zeitfenstern zu bestimmen. Auch können Wahrscheinlichkeitswerte für eine gegebene Zeitdauer durch das Verfolgen von Informationen, die angeben, dass kein Schlüssel-An verarbeitet wurde, verringert werden.
Für jedes Intervall wird, falls das Fahrzeug Schlüssel-An geschaltet wurde, eine positive Aktualisierung (die eine erhöhte zukünftige Wahrscheinlichkeit für Schlüssel-An angibt) bereitgestellt 205. Falls das Fahrzeug nicht Schlüssel-An geschaltet wurde, wird eine negative Aktualisierung (die eine verringerte zukünftige Wahrscheinlichkeit für Schlüssel-An zu dieser Zeit angibt) bereitgestellt 207. Obwohl dies ein ziemlich einfaches Modell ist, demonstriert es einen Weg, auf dem die Wahrscheinlichkeit einer Abfahrt während eines gegebenen Zeitfensters bestimmt und modifiziert werden kann. Zur selben Zeit, zu der das Schlüssel-An-Intervall positiv aktualisiert wird, können andere Intervalle zwischen dem momentanen Schlüssel-An-Intervall und einem letzten Schlüssel-An-Intervall eine negative Aktualisierung aufweisen, die kein Schlüssel-An während dieser Intervalle angeben.
3 zeigt eine veranschaulichende Datenaktualisierung für Schlüssel-An-Timing. Bezüglich den in dieser Figur beschriebenen veranschaulichenden Ausführungsformen sei angemerkt, dass ein Allzweckprozessor zum Zwecke des Ausführens einiger oder aller der hier gezeigten Beispielverfahren zeitweilig als ein Sonderzweck-Prozessor befähigt werden kann. Wenn Code, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, ausgeführt wird, kann der Prozessor zeitweilig als ein Sonderzweck-Prozessor umgewidmet werden, bis zum Zeitpunkt, zu dem das Verfahren abgeschlossen ist. In einem weiteren Beispiel kann, soweit angebracht, Firmware, die gemäß einem vorkonfigurierten Prozessor handelt, den Prozessor veranlassen, als ein Sonderzweck-Prozessor zu handeln, der für den Zweck des Durchführens des Verfahrens oder einer beliebigen sinnvollen Variante davon bereitgestellt ist.
Dieses Beispiel zeigt eine Aktualisierung, die, zusammen mit einem wie in 2 beispielhaft ausgeführten Lernprozess für eine positive oder negative Aktualisierung verwendet werden könnte. In diesem Beispiel würde der Prozess ein Schlüssel-An-Zeitintervall (positiv oder negativ) aktualisieren 301. Falls ein Fahrzeug um 7:07 Uhr morgens gestartet wurde, so kann das Zeitintervall 7:00–7:15 Uhr morgens positiv aktualisiert werden. Gleichzeitig kann ein Wochentag positiv oder negativ aktualisiert werden. Zusätzlich zum Wissen gewöhnlicher Startzeiten basiert menschliches Verhalten häufig auf einem Zeitplan, der sich in gewöhnlichen Aktionen an ähnlichen Wochentagen in verschiedenen Wochen widerspiegelt. Folglich kann es nützlich sein, nicht nur zu wissen, zu welcher Zeit das Fahrzeug gestartet wurde, sondern auch an welchem Tag das Fahrzeug gestartet wurde. Folglich würden für eine Person, die sich von Montag–Freitag um 7 Uhr morgens auf den Weg zu Arbeit macht, aber am Samstag erst zu Mittag ein Fahrzeug verwendet, um dann zum Fitnesszentrum und am Sonntag um 10:30 Uhr morgens zur Kirche zu gehen, Vorhersagen für einen Start um 7 Uhr morgens nicht an einem Samstag oder Sonntag verwendet werden und die Vorhersagen für Mittag und 10:30 würden jeweils für Samstag und Sonntag entwickelt. Demgemäß könnte ein Wochenaktualisierungstag 303 verarbeitet werden.
In diesem Beispiel kann auch ein Schlüssel-An-Ort aktualisiert werden 305. In manchen Fällen kann sich eine Schlüssel-An-Zeit auf einen Fahrzeugstandort beziehen. Falls sich zum Beispiel ein Fahrzeug an einem Bürostandort befindet, kann es häufig eine Schlüssel-An-Zeit von 5:30 Uhr nachmittags (wenn der Benutzer abfährt) geben. Falls sich dasselbe Fahrzeug aber an einem Heimstandort befindet, gibt es möglicherweise niemals eine solche Schlüssel-An-Zeit (da der Benutzer bereits zuhause ist). Somit können Schlüssel-An-Vorhersagen, falls gewünscht, ortsabhängig sein, was die Genauigkeit verbessern kann. Dies kann auch abfallende Vorhersagen für einen Bürostandort vermeiden, falls der Benutzer zum Beispiel für zwei Wochen im Urlaub ist, und das Fahrzeug zuhause gelassen wurde.
Das System kann nicht nur lernen wann, sondern auch wo Schlüssel-Ans auftreten, und, falls es eine Abweichung beim Schlüssel-An-Auftreten zwischen Orten gibt, können die Daten für eine verfeinerte Vorhersagefähigkeit separiert werden. Falls eine Person zum Beispiel während zwei Nächten pro Woche bei einem(einer) Lebensgefährten(in) schläft, kann das Schlüssel-An unabhängig vom Aufenthaltsort des Benutzers weiterhin um 7 Uhr morgens auftreten. Somit können die Startzeiten nicht auf dem Ort basierend herausgebrochen werden, da Schlüssel-Ans um 7 Uhr morgens sowohl zuhause als auch am Standort des(der) Lebensgefährten(in) auftreten. Andererseits können die Startzeiten auf dem Ort basierend herausgebrochen werden, falls der Benutzer sein Heim um 7 Uhr morgens und das des(der) Lebensgefährten(in) um 6:30 Uhr verlässt (vielleicht aufgrund des Ortes). Dies würde das Vorhersagen eines Fahrzeugstarts um 6:30 Uhr vermeiden, wenn sich der Benutzer zuhause befände, und einen Fahrzeugstart um 7:00 Uhr morgens (obwohl sich der Benutzer wohl bereits im Fahrzeug befände) vorhersagen, wenn der Benutzer sich am alternativen Schlafort befände. Durch Verwenden einer Tiefpassfilterprozedur müssen tatsächliche Schlüssel-An-Zeiten nicht für jedes Ereignis gespeichert werden. Eine gelernte Schlüssel-An-Karte kann die Informationen bereitstellen, die auf der Basis von detektierten und nicht detektierten Ereignissen aktualisiert werden.
4 zeigt einen veranschaulichenden Prozess zum Vorhersagen eines kommenden Schlüssel-Ans. Bezüglich den in dieser Figur beschriebenen veranschaulichenden Ausführungsformen sei angemerkt, dass ein Allzweckprozessor zum Zwecke des Ausführens einiger oder aller der hier gezeigten Beispielverfahren zeitweilig als ein Sonderzweck-Prozessor befähigt werden kann. Wenn Code, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, ausgeführt wird, kann der Prozessor zeitweilig als ein Sonderzweck-Prozessor umgewidmet werden, bis zum Zeitpunkt, zu dem das Verfahren abgeschlossen ist. In einem weiteren Beispiel kann, soweit angebracht, Firmware, die gemäß einem vorkonfigurierten Prozessor handelt, den Prozessor veranlassen, als ein Sonderzweck-Prozessor zu handeln, der für den Zweck des Durchführens des Verfahrens oder einer beliebigen sinnvollen Variante davon bereitgestellt ist.
In diesem veranschaulichenden Beispiel versucht der Prozess zu bestimmen, ob ein Fahrzeug jeden Moment gestartet wird. Dieser Prozess könnte auf einer entfernten Vorrichtung oder intern in einem Fahrzeug ablaufen, falls das Fahrzeug zum Beispiel über ausreichend Energie verfügt, um einen solchen Prozess kontinuierlich laufen zu lassen. Wenn er auf einer externen Vorrichtung läuft, könnte der Prozess, falls ein Schlüssel-An vorhergesagt wäre, mit dem Fahrzeug kommunizieren, um eine Vorkonditionierung anzuweisen.
In diesem Beispiel untersucht der Prozess ein gegebenes Zeitfenster für einen Tag und ein Zeitintervall 401. In diesem Beispiel wird ebenfalls ein Fahrzeugstandort erhalten (oder ein Standort einer entfernten Vorrichtung, falls der Prozess zum Beispiel auf einer mobilen Vorrichtung läuft). Auf eine Wahrscheinlichkeitsmatrix oder eine andere vorhersagende Algorithmus-Datenquelle wird für eine/einen vorgegebene/n Zeit/Tag/Ort zugegriffen 403. Diese Daten basieren auf früher beobachtetem Verhalten für den Tag, das Zeitintervall und/oder den Ort.
In diesem Beispiel schaut der Prozess nach, ob es eine Varianz zwischen Daten für die gegebenen Orte gibt 405. Das bedeutet, dass es mehr als einen für ein gegebenes Zeitintervall bereitgestellten Schlüssel-An-Datensatz gibt, die, basierend auf unterschiedlichen Orten, unterschiedliche Wahrscheinlichkeiten für Schlüssel-An repräsentieren. Falls dem so ist, lädt der Prozess, basierend auf dem aktuellen Standort, den passenden Datensatz 407. Es könnte auch einen Rückgriff auf den wahrscheinlichsten/unwahrscheinlichsten Satz geben, falls ein aktueller Fahrzeugort keinem mit den verschiedenen Datensätzen assoziierten Ort entspricht (d.h. dass sich das Fahrzeug an einem zuvor noch nicht beobachteten Ort befindet).
Der Prozess prüft dann, um zu bestimmen, ob die Wahrscheinlichkeit eines Fahrzeug-Schlüssel-An über einer gegebenen abstimmbaren Schwelle liegt 409. Wenn nur wenig Daten verfügbar sind, kann die Schwelle zum Beispiel auf eine niedrige Wahrscheinlichkeit gesetzt werden, da begrenzte Daten dazu tendieren können, die meisten Wahrscheinlichkeiten nahe zu 0 zu bringen. Mit sich entwickelnden Daten kann sich die Wahrscheinlichkeit ändern. Die Wahrscheinlichkeit kann auch dynamisch bezüglich einer Temperaturabweichung von einer Grundlinientemperatur angepasst werden (z.B. unter anderem einer vom Benutzer bevorzugten Fahrzeugtemperatur). Das bedeutet, dass, falls die Innen-/Außentemperatur nahe an einer bevorzugten Temperatur liegt, die Wahrscheinlichkeit, viel Vorkonditionierung zu benötigen gering ist, weswegen die Schwelle für eine Vorhersage hoch sein kann, da es selbst dann, wenn das System falsch liegt, wenig Einfluss auf den Benutzer gibt. Andererseits kann die Schwelle tiefer liegen, falls die Temperatur zum Beispiel 70 Grad unter der bevorzugten Temperatur liegt, so dass im Interesse des Aufnehmens aller Fälle, wenn der Benutzer das Fahrzeug wahrscheinlich nutzen wird, mehr Falsch-Positive auftreten können, so dass kein sehr kaltes oder sehr heißes Fahrzeug erlebt wird. In anderen Beispielen ist die Schwelle vom Benutzer oder dem OEM/Händler abstimmbar.
Falls die Wahrscheinlichkeit größer als die Schwelle ist 409, sagt das System voraus, dass das Fahrzeug innerhalb des untersuchten Zeitblocks verwendet werden wird und der Prozess gibt eine Wahrscheinlichkeit eines Schlüssel-An aus 413. Dies könnte an einen Anfrageprozess zurückgegeben werden oder eine Anwendung, die auf einer von dem Fahrzeug entfernten Vorrichtung läuft, könnte ein kommendes Schlüssel-An vorhersagen und mit dem Fahrzeug kommunizieren, um eine benötigte/gewünschte Vorkonditionierung vorherzusagen. Falls die Wahrscheinlichkeit geringer als die Schwelle ist, kann der Prozess eine Wahrscheinlichkeit für ein Kein-Schlüssel-An zurückgeben 411 und diesen Wert an einen Anfrageprozess zurückgeben oder zum Beispiel entscheiden, nicht mit dem Fahrzeug zu kommunizieren.
5A und 5B zeigen einen veranschaulichenden Vorkonditionierungsprozess. Bezüglich den in dieser Figur beschriebenen veranschaulichenden Ausführungsformen sei angemerkt, dass ein Allzweckprozessor zum Zwecke des Ausführens einiger oder aller der hier gezeigten Beispielverfahren zeitweilig als ein Sonderzweck-Prozessor befähigt werden kann. Wenn Code, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, ausgeführt wird, kann der Prozessor zeitweilig als ein Sonderzweck-Prozessor umgewidmet werden, bis zum Zeitpunkt, zu dem das Verfahren abgeschlossen ist. In einem weiteren Beispiel kann, soweit angebracht, Firmware, die gemäß einem vorkonfigurierten Prozessor handelt, den Prozessor veranlassen, als ein Sonderzweck-Prozessor zu handeln, der für den Zweck des Durchführens des Verfahrens oder einer beliebigen sinnvollen Variante davon bereitgestellt ist.
In diesem veranschaulichenden Beispiel wird ein uneingeschränkter Prozess zum Vorkonditionieren eines Fahrzeugs gezeigt. Der Prozess beginnt in diesem Beispiel zunächst mit dem Evaluieren potentieller Vorkonditionierungsbedürfnisse 501. Ein Benutzerzeitplan, der durch Benutzereingaben oder durch eine Reihe von Benutzerbeobachtungen erstellt wurde, die in einen Zeitplan codiert wurden, wird geladen 503. Der Benutzerzeitplan wird typischerweise bekannte oder gewöhnlich vorhergesagte Schlüssel-An-Zeiten angeben und kann periodisch manuell oder automatisch aktualisiert werden.
Wenn das Fahrzeug vorkonditioniert wird, können eine oder mehrere Vorkonditionierungseinstellungen für den Benutzer erstellt werden. Diese können feste Einstellungen (und/oder vom Fahrer definiert) sein oder können auf der Grundlage von Innen-/Außentemperaturen, Tageszeit, Wetter usw. variieren. Zum Beispiel wünscht der Benutzer im Sommer (oder wenn die Außentemperatur oberhalb von 80 Grad Fahrenheit liegt) möglicherweise, dass das Fahrzeug auf 68 Grad Fahrenheit abgekühlt wird. Im Winter (oder wenn die Außentemperatur unter dem Gefrierpunkt liegt) wünscht der Benutzer möglicherweise, dass das Fahrzeug auf 74 Grad Fahrenheit aufgeheizt wird. Wenn sich die Außentemperatur außerhalb eines optimalen Batteriebetriebsbereichs befindet, kann die Batterie geheizt oder gekühlt werden, um eine effiziente Nutzung zu fördern. Falls das Wetter passend ist (d.h. kein Niederschlag) und die Einstellungen es zulassen, können die Fahrzeugfenster leicht geöffnet werden, um Heiz-/Kühlunterstützung von äußeren Faktoren zuzulassen. Falls das Fahrzeug zum Beispiel in der prallen Sonne steht und die Innentemperatur 130 Grad Fahrenheit beträgt, kann es erheblich länger dauern, das Fahrzeug zu kühlen, es sei denn, dass die Fenster geöffnet werden können, um die heiße Innenluft auszutreiben. Dies kann zum Beispiel akzeptabel sein, wenn ein Fahrzeug in einer Einfahrt eines Eigners steht.
Falls der Zeitplan kein kommendes Schlüssel-An angibt (für ein einzelnes oder eine Reihe von beobachteten Zeitintervallen) 505, kann der Prozess einen Vorhersageprozess laden, wie etwa den in 4 gezeigten. Falls der Vorhersageprozess vorhersagt, dass ein Schlüssel-An wahrscheinlich über einer abstimmbaren Schwelle liegt 509, wird der Prozess fortfahren. Ansonsten wird der Prozess verlassen. Falls der Schlüssel-An auf einer Fahrereingabe in den Zeitplan basiert, kann die Wahrscheinlichkeit als zu 100% wahrscheinlich angesehen werden, ansonsten kann die Wahrscheinlichkeit auf angesammeltem Verhalten basieren (z.B. unter anderem den vergangenen X Auftritten des spezifizierten Zeitintervalls, Schlüssel-An ist Y-mal aufgetreten).
Falls es ein geplantes oder hochwahrscheinlich kommendes Schlüssel-An-Ereignis gibt, stellt der Prozess auch, in diesem Beispiel durch Sicherstellen, dass das Fahrzeug geparkt ist, sicher, dass das Fahrzeug gegenwärtig nicht in Verwendung ist 511. Falls das Fahrzeug verwendet wird, wird der Prozess verlassen, da Vorkonditionieren gegenstandslos ist, während sich das Fahrzeug in Verwendung befindet. Falls das Fahrzeug nicht verwendet wird, wird der Prozess nachschauen, ob das Fahrzeug eingesteckt ist 513. Falls das Fahrzeug keine einzusteckende elektrische Verbindung aufweisen sollte, kann zum Beispiel eine alternative Prüfung auf einen gewissen Schwellenkraftstoffpegel vorgenommen werden.
Falls das Fahrzeug nicht eingesteckt ist, kann der Benutzer dennoch ein Vorkonditionieren wünschen. In anderen Beispielen kann das Vorkonditionieren im Hinblick auf sich ändernde Batterietemperatur zu einer effizienteren Batterienutzung führen, weswegen eine Prüfung im Hinblick auf die Einstellungen für Batteriebedingungen durchgeführt werden könnte. Andere Einstellungen beziehen sich auf andere Vorkonditionierungs-Benutzerpräferenzen 515. Es kann der Fall sein, dass ein Benutzer die Einstellungen so eingestellt hat, einen nichteingesteckten Zustand zu ignorieren 517, was bedeutet, dass der Benutzer Vorkonditionieren wünscht, selbst wenn das Fahrzeug nicht eingesteckt ist. Dieselbe Einstellung könnte für einen Schwellenpegel von Kraftstoff vorgenommen werden. Falls die Ignorieren-der-nichteingesteckt/Kraftstoffpegel-Einstellung eingestellt ist, schaut der Prozess möglicherweise nach, ob der Energie-/Kraftstoffpegel über einer kritischen Schwelle liegt 519.
Die kritische Schwelle und die "akzeptable" Schwelle können bezüglich Kraftstoff und Energie variieren. Ein Benutzer kann zum Beispiel selbst dann eine Vorkonditionierung wünschen, wenn die Energie unter 50% liegt und das Fahrzeug nicht eingesteckt ist oder der Kraftstoff unter 50% steht. Falls aber Kraftstoff/Energie zum Beispiel unter 20% sind, kann dies als kritisches Niveau eingestuft werden, und eine Vorkonditionierung wird somit nicht auftreten. Dies schützt den Benutzer davor, von außen zu einem aufgewärmten/gekühlten Fahrzeug kommen, das zum tatsächlichen Fahren untüchtig ist.
In diesem Beispiel wird ebenfalls das Wetter überprüft 521. Dies könnte so einfach sein, wie das Aufnehmen einer Außen- oder Innentemperatur oder könnte außerdem das Erhalten einer Vorhersage für kommendes Wetter involvieren. Da das Vorkonditionieren weitestgehend mit dem Vorbereiten des Fahrzeugs zum Fahren befasst ist, ist das/die unmittelbare lokale Wetter/Temperatur in dieser Situation von größtem Nutzen. Da das Innere und nicht das Äußere des Fahrzeugs vorkonditioniert wird, prüft der Prozess in den meisten Fällen ferner die Innentemperatur im Gegensatz zur Außentemperatur, um zu bestimmen, ob Vorkonditionierung nötig ist. In Fällen wie etwa einem Enteisungsfall kann der Prozess die Außentemperatur als eine Grundlage zum Einsetzen eines Enteisungsmechanismus verwenden. In anderen Beispielen kann die Außentemperatur als die Grundlage zum Einsetzen der Vorkonditionierung verwendet werden.
Falls die Faktoren für Vorkonditionierung erfüllt sind 523, kann der Prozess nachschauen, ob eine Zustimmung des Fahrers nötig ist, um in eine Vorkonditionierung einzutreten 527. In manchen Fällen möchte der Fahrer möglicherweise jegliche Vorkonditionierungsversuche genehmigen/ablehnen. Oder, falls die Vorkonditionierung zum Beispiel auf einem geplanten Ereignis beruht, kann sie ohne Genehmigung des Fahrers weitermachen, wohingegen eine Genehmigung des Fahrers für vorhergesagte Fahrzeugnutzungen gewünscht sein kann, da diese wahrscheinlicher Falsch-Positive hervorrufen.
Falls eine Genehmigung des Fahrers, auf Grundlage von welchen auch immer gemachten Genehmigungseinstellungen, für das Vorkonditionieren notwendig ist, kann der Prozess den Fahrer warnen 527. Falls der Prozess zum Beispiel auf einer mobilen Vorrichtung ausgeführt wird (und möglicherweise mit einem Fahrzeug kommuniziert, um zum Beispiel eine Innentemperatur usw. zu bestimmen), kann der Prozess den Fahrer unter Verwendung der mobilen Vorrichtung warnen, bevor eine Vorkonditionierung angewiesen wird. Falls der Prozess auf einem Fernserver oder in dem Fahrzeug ausgeführt wird, kann der Prozess den Fahrer über die mobile Vorrichtung oder sonstige ausgewählte Warnmittel warnen. Falls keine Vorkonditionierung benötigt wird oder genehmigt ist 529, kann der Prozess fortfahren. Ein Fahrer kann das Fahrzeug für automatisches Vorkonditionieren konfigurieren oder das Fahrzeug anweisen, von einem Fahrer Bestätigung zu ersuchen, bevor gewisse oder sämtliche Vorkonditionierung auftritt. Falls ein Fahrzeug zum Beispiel eine eingeschränkte Vorkonditionierung benötigt (d.h. die Innentemperatur ist der gewünschten Temperatur sehr nahe), kann der Prozess eine Bestätigung benötigen, andererseits aber, falls die Innentemperatur über eine Schwelle ansteigt oder unter diese fällt, automatisch eine Vorkonditionierung einsetzen (falls Schlüssel-An unmittelbar bevorsteht).
Sobald Vorkonditionierung genehmigt wurde oder, falls eine Genehmigung nicht notwendig ist, kann der Prozess das Vorkonditionieren beginnen (oder dessen Initialisierung anweisen) 531. Typischerweise wird der Prozess eine gewisse abstimmbare Zeitspanne vor einer projizierten Fahrzeugstartzeit beginnen. Dies kann, basierend auf Benutzereinstellungen, variieren oder kann zum Beispiel darauf basierend variieren, wie signifikant ein Grad von Vorkonditionierung benötigt wird (d.h., dass eine kleine Temperaturänderung eine Vorkonditionierung von fünfzehn zwei bis drei Minuten benötigen kann, wohingegen eine große Änderung zehn bis 15 Minuten benötigen kann). Da die Effizienz von Heiz- und Kühlsystemen mit der Zeit nachlassen kann, könnte der Prozess, wenn gewünscht, verfolgen, wie lange es dauert, von einer Temperatur zu einer anderen zu wechseln, und die Zeitdauer auf der projizierten Zeit basieren, um die Temperatur von der momentanen Temperatur auf die gewünschte zu ändern.
Falls die projizierte Startzeit noch nicht erreicht ist 533, kann der Prozess prüfen, ob das Fahrzeug gestartet wurde 535. Falls das Fahrzeug gestartet wurde, kann eine Aktualisierung an jeglichem Vorhersageprozess oder einer Datenaufzeichnung vorgenommen werden, die angibt, dass das Fahrzeug in einem gegebenen Intervall gestartet wurde 537. Ansonsten fährt die Konditionierung fort.
Falls die projizierte Zeit zum Starten gekommen ist (oder eine abstimmbare Schwelle jenseits der projizierten Startzeit gekommen ist) 533, kann der Prozess den Fahrer benachrichtigen, dass das Fahrzeug vorkonditioniert wird, das Fahrzeug aber noch nicht gestartet wurde 539. Dies gibt dem Fahrer eine Gelegenheit, den Vorkonditionierungsprozess abzubrechen 541, falls sich zum Beispiel die Reisepläne geändert haben. Falls der Fahrer wählt, den Prozess abzubrechen, kann das System eine auf den Fahrzeugstart bezogene Vorhersage negativ aktualisieren oder eine Fahrzeugdatenablage (für eine spätere Analyse verwendbar) negativ aktualisieren 545. Andererseits kann der Prozess, falls der Fahrer wählt, das Vorkonditionieren weiterzuführen, die Startzeit auf eine neue projizierte Startzeit anpassen (durch Erhöhen der Zeit um eine feste Größe, Empfangen einer neuen projizierten Startzeit vom Fahrer usw.) 543 und das Vorkonditionieren weiterführen.
6 zeigt einen veranschaulichenden Planaktualisierungsprozess. Bezüglich den in dieser Figur beschriebenen veranschaulichenden Ausführungsformen sei angemerkt, dass ein Allzweckprozessor zum Zwecke des Ausführens einiger oder aller der hier gezeigten Beispielverfahren zeitweilig als ein Sonderzweck-Prozessor befähigt werden kann. Wenn Code, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, ausgeführt wird, kann der Prozessor zeitweilig als ein Sonderzweck-Prozessor umgewidmet werden, bis zum Zeitpunkt, zu dem das Verfahren abgeschlossen ist. In einem weiteren Beispiel kann, soweit angebracht, Firmware, die gemäß einem vorkonfigurierten Prozessor handelt, den Prozessor veranlassen, als ein Sonderzweck-Prozessor zu handeln, der für den Zweck des Durchführens des Verfahrens oder einiger sinnvoller Varianten davon bereitgestellt ist.
In diesem veranschaulichenden Beispiel können Aktualisierungen an einem Fahrerzeitplan vorgenommen werden, so dass mit der Zeit beobachtete Diskrepanzen bezüglich projizierten gegenüber tatsächlichen Startzeiten oder zum Beispiel Planstartzeiten, die niemals wirklich auftreten, in dem/aus dem Zeitplan geändert/entfernt werden können.
In diesem Beispiel stellt der Prozess einen Vorhersage-Zeitplan zusammen 601, der darauf basiert, wann das Fahrzeug zu starten vorhergesagt ist, basierend auf dem beobachteten Verhalten. Dieser Zeitplan wird auf der Grundlage des beobachteten Verhaltens des Fahrers erzeugt und unterscheidet sich von dem existierenden, erstellten tatsächlichen Zeitplan. Der erstellte Zeitplan von geplanten Startzeiten kann ebenfalls zu dieser Zeit geladen werden 603.
Für ein anfängliches Zeitintervall (und für nachfolgende Zeitintervalle) kann der Prozess das vorhergesagte Schlüssel-An mit einem geplanten Schlüssel-An vergleichen, um zu sehen, ob die geplanten Daten (ja oder nein zu Schlüssel-An) mit den vorhergesagten Daten übereinstimmen 607. Für jeden Fall, bei dem sich die beiden Zeitpläne unterscheiden, kann der Prozess das Zeitintervall kennzeichnen 609. Dies fährt fort, durch Bewegung durch nächste Intervalle 613, bis kein zu berücksichtigendes Intervall verbleibt 611.
An diesem Punkt in dem Prozess, wenn alle passenden Intervalle berücksichtigt wurden, bestimmt der Prozess, ob die Anzahl gekennzeichneter Fälle auf dem festen Kalender eine Schwelle überschreitet 615. Falls automatisches Kalenderaktualisieren aktiviert ist, kann dieser Schritt übersprungen werden, ansonsten hilft der Schritt, einen Benutzer davor zu schützen, belästigt zu werden, wenn es nur eine einzige oder wenige einfache Diskrepanzen gibt. Falls es eine Schwellenanzahl von Diskrepanzen gibt, benachrichtigt der Prozess in diesem Beispiel der Benutzer/Fahrer 617. Automatisches Aktualisieren kann ebenfalls den Benachrichtigungsschritt überspringen und einfach den festen Kalender auf der Grundlage von Vorhersagen mit einem hohen Erfolgsgrad modifizieren. In diesem Beispiel kann der Fahrer wählen, den festen Kalender automatisch aktualisiert zu bekommen 619, um die neuen, von den Kennzeichen angezeigten Zeiten aufzunehmen (und ungenaue aktuell geplante Zeiten zu entfernen) 621 oder der Fahrer kann sich stattdessen in eine Dienstanwendung einloggen oder auf eine solche zugreifen, die manuelles Bearbeiten des Zeitplans erlaubt.
Obgleich oben beispielhafte Ausführungsformen beschrieben werden, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Stattdessen dienen die in der Patentschrift verwendeten Ausdrücke der Beschreibung und nicht der Einschränkung, und es versteht sich, dass verschiedene Änderungen durchgeführt werden können, ohne vom Gedanken und Schutzbereich der Erfindung abzuweichen. Darüber hinaus können die Merkmale verschiedener Implementierungsausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
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 Nicht-Patentliteratur

IEEE 802 PAN(Personal Area Network)-Protokolle [0023]
IEEE 802 LAN(Local Area Network)-Protokolle [0023]
IEEE 802 PAN [0023]
802.11g-Netzwerk [0024]
IEEE 1394 [0026]
IEEE 1284 [0026]
IEEE 803.11 [0028]

Claims

System, das Folgendes umfasst: einen Prozessor, der ausgelegt ist zum: Zugreifen auf einen Zeitplan von wahrscheinlichen Fahrzeugstartzeiten; Auswählen einer geplanten Schlüssel-An-Zeit aus dem Zeitplan, die eine Auftrittswahrscheinlichkeit, basierend auf beobachteter Fahrzeugnutzung, oberhalb einer abstimmbaren Schwelle aufweist, wenn eine aktuelle Zeit innerhalb einer abstimmbaren Nähe zu der geplanten Schlüssel-An-Zeit liegt; und Bestimmen, ob eine gegenwärtige fahrzeugbezogene Temperatur Fahrzeug-Vorkonditionierung rechtfertigt; und Vorkonditionieren des Fahrzeugs bis voreingestellte Vorkonditionierungseinstellungen erreicht sind.
System nach Anspruch 1, wobei die fahrzeugbezogene Temperatur eine Fahrzeug-Innentemperatur beinhaltet.
System nach Anspruch 1, wobei die fahrzeugbezogene Temperatur eine Fahrzeug-Außentemperatur beinhaltet.
System nach Anspruch 1, wobei das Vorkonditionieren Heizen oder Kühlen des Fahrzeuginnern beinhaltet.
System nach Anspruch 1, wobei das Vorkonditionieren das Einsetzen einer Fahrzeugfensterenteisung beinhaltet.
System nach Anspruch 1, wobei das Vorkonditionieren Heizen oder Kühlen einer Fahrzeugbatterie beinhaltet.
System nach Anspruch 1, wobei der Prozessor weiterhin ausgelegt ist zum: Benachrichtigen eines Benutzers, eine Genehmigung anzufordern, mit dem Vorkonditionieren fortzufahren, falls eine projizierte Schlüssel-An-Zeit vergangen ist.
System nach Anspruch 7, wobei der Prozessor weiterhin ausgelegt ist zum: Einstellen einer neuen Schlüssel-An-Zeit, falls ein Fahrer fortgesetztes Vorkonditionieren anweist.
System nach Anspruch 1, wobei der Zeitplan Fahrzeugstartzeiten beinhaltet, die auf Fahrereingaben in einen Zeitplan basieren, die so behandelt werden, als hätten sie eine 100%-ige Auftrittswahrscheinlichkeit.
Computerimplementiertes Verfahren, das Folgendes umfasst: Analysieren eines Zeitintervalls, um zu bestimmen, ob ein Schlüssel-An-Ereignis aufgetreten ist; Aktualisieren einer Aufzeichnung von Schlüssel-An-Ereignissen mit einem Schlüssel-An-Ereignis-Auftreten/Nichtauftreten, um eine Schlüssel-An-Wahrscheinlichkeit während des Zeitintervalls zu erstellen; Zusammenstellen eines Zeitplans einer Vielzahl von vorhergesagten Schlüssel-An-Zeitintervallen, der auf vorhergesagten Schlüssel-An-Wahrscheinlichkeiten während jedes vorhergesagten Schlüssel-An-Zeitintervalls basiert; und Benachrichtigen eines Fahrers über jegliche bestimmte Abweichungen zwischen dem zusammengestellten Zeitplan und einem Fahrereingaben-Schlüssel-An-Ereigniszeitplan.
Verfahren nach Anspruch 10, wobei der zusammengestellte Zeitplan Schlüssel-An-Ereignisse beinhaltet, die eine Auftrittswahrscheinlichkeit größer als eine abstimmbare Schwelle aufweisen.
Verfahren nach Anspruch 10, das ferner Folgendes umfasst: Empfangen von Anweisungen, den vom Fahrer eingegeben Zeitplan zu aktualisieren; und Aktualisieren des vom Fahrer eingegebenen Zeitplans, basierend auf dem zusammengestellten Zeitplan.
Verfahren nach Anspruch 12, wobei das Aktualisieren des vom Fahrer eingegebenen Zeitplans das Hinzufügen vorhergesagter Schlüssel-An-Ereignisse, die eine Wahrscheinlichkeit über einer abstimmbaren Schwelle aufweisen, beinhaltet.
Verfahren nach Anspruch 12, wobei das Aktualisieren des vom Fahrer eingegebenen Zeitplans das Entfernen von vom Fahrer eingegebenen Schlüssel-An-Ereignissen, die eine Entsprechung mit Schlüssel-An-Ereignissen in dem zusammengestellten Zeitplan aufweisen, die eine Wahrscheinlichkeit unter einer abstimmbaren Schwelle aufweisen, beinhaltet.
Nichtvergängliches computerlesbares Speichermedium, das Anweisungen speichert, die, wenn ausgeführt, einen Prozessor veranlassen, ein Verfahren durchzuführen, wobei das Verfahren Folgendes umfasst: Analysieren eines Zeitintervalls, um zu bestimmen, ob ein Schlüssel-An-Ereignis aufgetreten ist; Aktualisieren einer Aufzeichnung von Schlüssel-An-Ereignissen mit einem Schlüssel-An-Ereignis-Auftreten/Nichtauftreten, um eine Schlüssel-An-Wahrscheinlichkeit während des Zeitintervalls zu erstellen; Zusammenstellen eines Zeitplans einer Vielzahl von vorhergesagten Schlüssel-An-Zeitintervallen, der auf vorhergesagten Schlüssel-An-Wahrscheinlichkeiten während jedes vorhergesagten Schlüssel-An-Zeitintervalls basiert; und Benachrichtigen eines Fahrers über jegliche bestimmte Abweichungen zwischen dem zusammengestellten Zeitplan und einem Fahrereingaben-Schlüssel-An-Ereigniszeitplan.
Computerlesbares Speichermedium nach Anspruch 15, wobei das Aktualisieren in täglichen Intervallen auftritt.
Computerlesbares Speichermedium nach Anspruch 15, wobei der zusammengestellte Zeitplan Schlüssel-An-Ereignisse beinhaltet, die eine Auftrittswahrscheinlichkeit größer als eine abstimmbare Schwelle aufweisen.
Computerlesbares Speichermedium nach Anspruch 15, das ferner Folgendes umfasst: Empfangen von Anweisungen, den vom Fahrer eingegeben Zeitplan zu aktualisieren; und Aktualisieren des vom Fahrer eingegebenen Zeitplans, basierend auf dem zusammengestellten Zeitplan.
Computerlesbares Speichermedium nach Anspruch 18, wobei das Aktualisieren des vom Fahrer eingegebenen Zeitplans das Hinzufügen vorhergesagter Schlüssel-An-Ereignisse, die eine Wahrscheinlichkeit über einer abstimmbaren Schwelle aufweisen, beinhaltet.
Computerlesbares Speichermedium nach Anspruch 18, wobei das Aktualisieren des vom Fahrer eingegebenen Zeitplans das Entfernen von vom Fahrer eingegebenen Schlüssel-An-Ereignissen, die eine Entsprechung mit Schlüssel-An-Ereignissen in dem zusammengestellten Zeitplan aufweisen, die eine Wahrscheinlichkeit unter einer abstimmbaren Schwelle aufweisen, beinhaltet.