DE102015118565A1

DE102015118565A1 - Verfahren und Gerät für prädiktives Fahrmodus-Lernen und -freigeben

Info

Publication number: DE102015118565A1
Application number: DE102015118565.2A
Authority: DE
Inventors: Kwaku O. Prakah-Asante; Hsin-Hsiang Yang; Finn Finn Tseng; Steven Joseph Szwabowski
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2014-10-31
Filing date: 2015-10-30
Publication date: 2016-05-04
Also published as: US9969403B2; CN105575210A; US20160121904A1; CN105575210B

Abstract

Ein System enthält einen Prozessor, der konfiguriert ist, einen Fahrzeugort zu empfangen und fahrerspezifische Fahrmoduswechsel-Daten für den Fahrzeugort abzurufen. Der Prozessor ist außerdem konfiguriert, basierend auf den abgerufenen Daten zu bestimmen, ob ein Fahrzeugfahrmoduswechsel vorher an dem Fahrzeugort und bei dem Kontext eine ausreichende Anzahl von Malen vorgekommen ist, um einen im Voraus bestimmten Schwellenwert zu überschreiten, und falls ja, einen Fahrzeugfahrmodus automatisch zu einem Fahrmodus zu wechseln, der mit dem vorherigen Fahrmoduswechsel assoziiert ist.

Description

TECHNISCHES GEBIET
Die veranschaulichenden Ausführungsformen betreffen allgemein ein Verfahren und ein Gerät für prädiktives Fahrmodus-Lernen und -Freigeben.
HINTERGRUND
Adaptive Fahrsteuersysteme stellen eine verbesserte Fahrerfahrung unter einer Vielzahl von Fahrbedingungen bereit. Jüngste Entwicklungen gestatten die automatische Auswahl von Modi wie Sport, Normal und Komfort, um sich verändernden Straßenbedingungen, Kurvenfahren und wellenförmigen Kurven zu entsprechen. Da zusätzliche Modi verfügbar werden, wie Schnee, Kies, Sand, Öko usw., wird automatische Auswahl eines Modus, der von einem Fahrer für gegenwärtige Fahrzeug-Betriebsbedingungen gewünscht wird, zunehmend schwieriger.
ZUSAMMENFASSUNG
In einer ersten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der konfiguriert ist, einen Fahrzeugort zu empfangen. Der Prozessor ist ferner konfiguriert, fahrerspezifische Fahrmoduswechsel-Daten für den Fahrzeugort abzurufen. Der Prozessor ist außerdem konfiguriert, basierend auf den abgerufenen Daten zu bestimmen, ob ein Fahrzeugfahrmoduswechsel vorher an dem Fahrzeugort ausreichend vorgekommen ist, um einen im Voraus definierten Schwellenwert zu überschreiten und einen Fahrzeugfahrmodus automatisch zu einem Fahrmodus zu wechseln, der aus dem Fahrmoduswechsel resultiert, der vorher genügend Male vorgekommen ist, um den Schwellenwert zu überschreiten.
In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren, einen Fahrzeugort zu empfangen. Das Verfahren enthält ferner, fahrerspezifische Fahrmoduswechsel-Daten für den Fahrzeugort abzurufen. Das Verfahren enthält ferner, basierend auf den abgerufenen Daten zu bestimmen, ob ein Fahrzeugfahrmoduswechsel vorher an dem Fahrzeugort ausreichend vorgekommen ist, um einen im Voraus bestimmten Schwellenwert zu überschreiten und einen Fahrzeugfahrmodus automatisch zu einem Fahrmodus zu wechseln, der aus dem Fahrmoduswechsel resultiert, der mit ausreichender Häufigkeit vorgekommen ist, um den Schwellenwert zu überschreiten.
In einer dritten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der konfiguriert ist, einen Fahrereingabe zu empfangen, die einen Fahrzeugfahrmoduswechsel angibt. Der Prozessor ist außerdem konfiguriert, einen Fahrzeugort zu empfangen und eine Instanz der Korrespondenz zwischen dem Fahrzeugfahrmoduswechsel und dem Fahrzeugort zu speichern.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 zeigt ein veranschaulichendes Fahrzeugrechnersystem;
2 zeigt ein veranschaulichendes Fahrerverhalten-Lern- und -Vorhersagesystem;
3 zeigt einen veranschaulichenden Lernprozess; und
4 zeigt einen veranschaulichenden prädiktiven Fahrmodus-Aktivierungsprozess.
AUSFÜHRLICHE BESCHREIBUNG
Ausführliche Ausführungsformen der vorliegenden Erfindung werden hierin nach Erfordernis offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen ausgeführt werden kann. Die Figuren sind nicht notwendigerweise maßstabsgetreu; einige Merkmale können überbetont oder minimiert sein, um Einzelheiten von bestimmten Komponenten zu zeigen. Daher sind hierin offenbarte spezifische strukturelle und funktionale Einzelheiten nicht als einschränkend zu interpretieren, sondern lediglich als eine repräsentative Basis, um einem Fachmann zu lehren, die vorliegende Erfindung verschiedenartig anzuwenden.
1 stellt eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Rechnersystem 1 (VCS) für ein Fahrzeug 31 dar. Ein Beispiel eines derartigen fahrzeugbasierten Rechnersystems 1 ist das System SYNC, hergestellt von THE FORD MOTOR COMPANY. Ein Fahrzeug, das mit einem fahrzeugbasierten Rechnersystem ausgestattet ist, kann eine visuelle vorgeschaltete Schnittstelle 4 enthalten, die sich in dem Fahrzeug befindet. Der Benutzer kann außerdem imstande sein, 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 Betätigung von Tasten, ein Sprache-Dialogsystem mit automatischer Spracherkennung und Sprachsynthese.
In der in 1 dargestellten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Anteil des Betriebs des fahrzeugbasierten Rechnersystems. Der Prozessor, der in dem Fahrzeug bereitgestellt ist, gestattet Verarbeitung von Befehlen und Routinen an Bord. Ferner ist der Prozessor mit sowohl dem nicht dauerhaften Speicher 5 als auch dem dauerhaften Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der flüchtige Speicher ein Direktzugriffspeicher (RAM) und ist der Festspeicher ein Festplattenlaufwerk (HDD) oder Flash-Speicher. Im Allgemeinen kann ein dauerhafter (nichtflüchtiger) Speicher sämtliche Speicherformen enthalten, die Daten beibehalten, wenn ein Rechner oder eine andere Vorrichtung ausgeschaltet ist. Diese enthalten, sind aber nicht darauf beschränkt, HDDs, CDs, DVDs, Magnetbänder, Festkörperlaufwerke, tragbare USB-Laufwerke und jede andere geeignete Form von dauerhaftem Speicher.
Der Prozessor ist außerdem mit einer Anzahl verschiedener Eingänge versehen, die dem Benutzer gestatten, an den Prozessor anzuschalten. In dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein Hilfseingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der eine berührungsempfindliche Anzeige sein kann, und ein BLUETOOTH-Eingang 15 alle bereitgestellt. Ein Eingangswahlschalter 51 ist außerdem bereitgestellt, um einem Benutzer zu gestatten, zwischen verschiedenen Eingängen zu wechseln. Eingang in sowohl den Mikrofon- als auch den Hilfsanschluss wird von einem Wandler 27 von analog zu digital umgewandelt, bevor er zum Prozessor weitergeleitet wird. Obwohl nicht dargestellt, können zahlreiche der Fahrzeugkomponenten und Hilfskomponenten in Kommunikation mit dem VCS ein Fahrzeugnetzwerk (wie, aber nicht darauf beschränkt, ein CAN-Bus) nutzen, um Daten zu und von dem VCS (oder Komponenten davon) zu leiten.
Ausgänge aus dem System können eine visuelle Anzeige 4 und einen Lautsprecher 13 oder Stereosystem-Ausgang beinhalten, sind aber nicht darauf beschränkt. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal von dem Prozessor 3 durch einen Digital-zu-Analog-Wandler 9. Ausgang kann auch zu einer entfernten BLUETOOTH-Vorrichtung wie PND 54 oder eine USB-Vorrichtung wie ein Fahrzeug-Navigationssystem 60 entlang den bei 19 bzw. 21 dargestellten bidirektionalen Datenströmen erfolgen.
In einer veranschaulichenden Ausführungsform verwendet das System 1 einen BLUETOOTH-Transceiver 15 zum Kommunizieren 17 mit dem Mobilgerät 53 (z. B. Funktelefon, Smartphone, PDA oder eine beliebige andere Vorrichtung, die über drahtlose Konnektivität mit einem entfernten Netzwerk verfügt) eines Benutzers. Das Mobilgerät kann dann zum Kommunizieren 59 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 durch zum Beispiel Kommunikation 55 mit einem Funkmast 57 verwendet werden. In einigen Ausführungsformen kann der Mast 57 ein W-LAN-Zugangspunkt sein.
Beispielhafte Kommunikation zwischen dem Mobilgerät und dem BLUETOOTH-Transceiver wird durch das Signal 14 repräsentiert.
Koppeln eines Mobilgeräts 53 und des BLUETOOTH-Transceivers 15 kann durch eine Taste 52 oder ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der BLUETOOTH-Transceiver an Bord mit einem BLUETOOTH-Transceiver in einem Mobilgerät gekoppelt wird.
Daten können zwischen der CPU 3 und dem Netzwerk 61 unter Nutzung zum Beispiel eines Datentarifs, Daten-über-Sprache oder DTMF-Tönen, die mit dem Mobilgerät 53 assoziiert sind, kommuniziert werden. Alternativ kann es wünschenswert sein, ein Modem 63 an Bord vorzusehen, das über eine Antenne 18 verfügt, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu kommunizieren 16. Das Mobilgerät 53 kann dann zum Kommunizieren 59 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 durch zum Beispiel Kommunikation 55 mit einem Funkmast 57 verwendet werden. In einigen Ausführungsformen kann das Modem 63 Kommunikation 20 mit dem Mast 57 zum Kommunizieren mit dem Netzwerk 61 herstellen. Als ein nicht einschränkendes Beispiel kann das Modem 63 ein USB-Funkmodem sein und die Kommunikation 20 kann Funkkommunikation sein.
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem versehen, das eine API zur Kommunikation mit Modem-Anwendungssoftware beinhaltet. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder eingebettete Firmware in dem BLUETOOTH-Transceiver zugreifen, um drahtlose Kommunikation mit einem entfernten BLUETOOTH-Transceiver (wie dem in einem Mobilgerät) durchzuführen. Bluetooth ist ein Teilsatz der Protokolle IEEE 802 PAN (persönliches Bereichsnetzwerk). Die Protokolle IEEE 802 LAN (lokales Bereichsnetzwerk) enthalten W-LAN und weisen eine beträchtliche Kreuzfunktionalität mit IEEE 802 PAN auf. Beide sind für drahtlose Kommunikation innerhalb eines Fahrzeugs geeignet. Ein weiteres Kommunikationsmittel, das in diesem Bereich verwendet werden kann, ist optische Freiraumkommunikation (wie IrDA) und nicht standardisierte Kunden-IR-Protokolle.
In einer anderen Ausführungsform beinhaltet das Mobilgerät 53 ein Modem für Sprachband- oder Breitband-Datenkommunikation. In der Daten-über-Sprache-Ausführungsform kann eine als Frequenzmultiplexing bekannte Technik implementiert werden, mit der der Besitzer des Mobilgeräts über das Gerät sprechen kann, während Daten übertragen werden. Zu anderen Zeiten, wenn der Benutzer das Gerät nicht verwendet, kann die Datenübertragung die gesamte Bandbreite (300 Hz bis 3,4 kHz in einem Beispiel) nutzen. Während Frequenzmultiplexing für analoge zellulare Kommunikation zwischen dem Fahrzeug und dem Internet üblich sein mag und noch verwendet wird, wurde es in großem Ausmaß durch Hybride davon wie Codemultiplexzugriff (CDMA), Zeitmultiplexzugriff (TDMA), Raummultiplexzugriff (SDMA) für digitale zellulare Kommunikation ersetzt. Dies sind alles Standards, die mit ITU IMT-2000 (3G) kompatibel sind und Datenraten bis zu 2 mbs für stationäre oder gehende Benutzer und 385 kbs für Benutzer in einem fahrenden Fahrzeug bieten. 3G-Standards werden jetzt durch IMT-Advanced (4G) ersetzt, das 100 mbs für Benutzer in einem Fahrzeug und 1 gbs für stationäre Benutzer bietet. Wenn der Benutzer über einen mit dem Mobilgerät assoziierten Datentarif verfügt, ist es möglich, dass der Datentarif Breitbandübertragung bietet, und das System könnte eine viel größere Bandbreite verwenden (wodurch die Datenübertragung beschleunigt wird). In noch einer anderen Ausführungsform ist das Mobilgerät 53 durch eine Funkkommunikationsvorrichtung (nicht dargestellt) ersetzt, das im Fahrzeug 31 installiert ist. In einer weiteren Ausführungsform kann das ND 53 eine drahtlose Lokalnetzwerk- bzw. LAN-Vorrichtung sein, die imstande ist, über zum Beispiel (und ohne Einschränkung) ein 802.11g-Netzwerk (d. h. W-LAN) oder ein WiMax-Netzwerk zu kommunizieren.
In einer Ausführungsform können eingehende Daten durch das Mobilgerät über einen Daten-über-Sprache- oder Datentarif durch den BLUETOOTH-Transceiver an Bord und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Fall von zum Beispiel bestimmten temporären Daten können die Daten in dem HDD oder einem anderen Speichermedium 7 bis zu einem Zeitpunkt, zu dem die Daten nicht mehr benötigt werden, gespeichert werden.
Weitere Quellen, die an das Fahrzeug anschalten können, beinhalten eine persönliche Navigationsvorrichtung 54, die zum Beispiel eine USB-Verbindung 56 und/oder eine Antenne 58 aufweist, eine Fahrzeugnavigationsvorrichtung 60 mit einer USB- 62 oder anderen Verbindung, eine GPS-Vorrichtung 24 an Bord oder ein entferntes Navigationssystem (nicht dargestellt), das Konnektivität zum Netzwerk 61 aufweist. USB ist eines einer Klasse von Protokollen für serielle Netzwerkanbindung. IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), serielle Protokolle der 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 Standards von Vorrichtung zu Vorrichtung. Die meisten der Protokolle können für entweder elektrische oder optische Kommunikation implementiert werden.
Ferner könnte die CPU mit einer Vielfalt anderer Hilfsvorrichtungen 65 in Kommunikation stehen. Diese Vorrichtungen können über eine drahtlose 67 oder verdrahtete 69 Verbindung angeschlossen sein. Die Hilfsvorrichtung 65 kann persönliche Medien-Abspielgeräte, drahtlose Gesundheitsvorrichtungen, tragbare Computer und dergleichen beinhalten, ist aber nicht darauf beschränkt.
Außerdem oder alternativ könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 unter Verwendung zum Beispiel eines W-LAN-Transceivers (IEEE 803.11) 71 verbunden sein. Dies könnte der CPU gestatten, Verbindung mit entfernten Netzwerken im Bereich des lokalen Routers 73 herzustellen.
Zusätzlich zu beispielhaften Prozessen, die von einem Fahrzeugrechnersystem, das sich in einem Fahrzeug befindet, ausgeführt werden, können die beispielhaften Prozesse in bestimmten Ausführungsformen von einem Rechnersystem in Kommunikation mit einem Fahrzeugrechnersystem ausgeführt werden. Ein derartiges System kann eine drahtlose Vorrichtung (z. B., und ohne Einschränkung, ein Mobiltelefon) oder ein entferntes Rechnersystem (z. B., und ohne Einschränkung, ein Server), die durch die drahtlose Vorrichtung angeschlossen ist, beinhalten, ist aber nicht darauf beschränkt. Zusammen können derartige Systeme als fahrzeugassoziierte Rechnersysteme (VACS) bezeichnet werden. In bestimmten Ausführungsformen können besondere Komponenten des VACS besondere Abschnitte eines Prozesses in Abhängigkeit von der besonderen Implementierung des Systems ausführen. Lediglich als Beispiel und nicht als Einschränkung ist es wahrscheinlich, dass, wenn ein Prozess einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, die drahtlose Vorrichtung diesen Teil des Prozesses nicht durchführt, da die drahtlose Vorrichtung keine Informationen mit sich selbst „senden und empfangen“ würde. Ein Durchschnittsfachmann im Fachgebiet wird verstehen, wann es angemessen ist, ein besonderes Rechnersystem für eine gegebene Lösung anzuwenden.
In jedem der hierin diskutierten veranschaulichenden Ausführungsform wird ein beispielhaftes, nicht einschränkendes Beispiel eines Prozesses, der von einem Rechnersystem ausführbar ist, dargestellt. In Bezug auf jeden Prozess ist es möglich, dass das Rechnersystem, das den Prozess ausführt, für den begrenzten Zweck der Ausführung des Prozesses als ein Spezialprozessor zum Ausführen des Prozesses konfiguriert wird. Alle Prozesse müssen nicht in ihrer Ganzheit ausgeführt werden und es versteht sich, dass sie Beispiele von Prozesstypen sind, die ausgeführt werden können, um Elemente der Erfindung zu erzielen. Den beispielhaften Prozessen können zusätzliche Schritte nach Wunsch hinzugefügt oder davon entfernt werden.
Die veranschaulichenden Ausführungsformen stellen beispielhafte Systeme und Verfahren zum Lernen der Fahrerauswahl zur Wahl des Fahrzeugmodus bereit. Dies stellt Vorhersage und Auswahl des Fahrmodus (z. B., ohne Einschränkung, Sport-Modus, Komfort-Modus, Schnee-Modus, Kies-Modus, Sand-Modus, Kraftstoffökonomie-Modus usw.) basierend auf vorher beobachtetem Fahrerverhalten bereit.
In einer Ausführungsform kann die vorherige Auswahl eines bestimmten Modus an bestimmten Orten für eine ausreichende Anzahl von Malen als eine Fahrerabsicht, den besonderen Modus jedes Mal, wenn dieser Ort erreicht wird, zu aktivieren, anzeigend betrachtet werden. In anderen Ausführungsformen kann der Kontext (z. B., ohne Einschränkung, Mitfahrer, Wetter usw.) verwendet werden, den Entscheidungs-/Vorhersageprozess weiter zu verfeinern.
Basierend auf vorhergesagter fahrerbasierter Modusauswahl kann das Fahrzeug automatisch einen Fahrmodus aktivieren, der wahrscheinlich vom Fahrer an einem gegebenen Ort manuell ausgewählt werden wird. Dies kann sowohl den Komfort der Modusauswahl als auch das Erlebnis des Fahrers verbessern. Wenn der Fahrer sehr beschäftigt ist (wenn ein hoher Grad der Aufmerksamkeit des Fahrers genutzt wird), kann das vorhersagende System den Modus automatisch aktivieren, wodurch der Fahrer von dem Erfordernis befreit wird, eine weitere Überlegung zu einem bereits überhäuften intellektuellen Tableau hinzuzufügen.
Die veranschaulichenden Ausführungsformen nutzen Erkennung, Auswahl und Aufzeichnung häufiger Fahrermodus-Auswahl, um bei der Vorhersage bevorstehender Modusauswahl und automatischer Freigabe vorhergesagter Modi zu unterstützen. Regionen und kontextuelle Bedingungen für spezifische Modusauswahl können im Verlauf der Zeit gelernt werden, indem Koordination-Informationen, kontextuelle Informationen und Echtzeit-Fahrermodus-Auswahl miteinander verschmolzen werden. Diese erlernten Daten können bei der automatischen Freigabe von Modi an ähnlichen Koordinaten unter ähnlichen Bedingungen in der Zukunft genutzt werden.
2 zeigt ein veranschaulichendes Fahrerverhalten-Lern- und -Vorhersagesystem. In dem in 2 dargestellten veranschaulichenden System gibt es mehrere Eingänge in das System. Diese enthalten den Fahrer 201, die GPS-Koordinaten aus der Telematikeinheit 203 und etwaige relevante Fahrzeugdaten, die für den Kontext verwendet werden 205.
Der Fahrer hat in diesem Beispiel die Fähigkeit, die Fahrmodi zu jeder gewünschten Zeit zu verändern 207. Dies kann Wechseln zu einem Modus mit verstärkter Traktion bei Straßenglätte, einem Sport-Fahrmodus für aggressives Fahrverhalten, einem Geländemodus für Geländefahren oder Kies-/Schotterstraßen usw. sein. Der Fahrer kann auswählen, welches Fahrverhalten/welcher Fahrmodus gewünscht wird oder für sich verändernde Straßen- und Wetterbedingungen angemessen ist. Für die gleichen Orte/Bedingungen können verschiedene Modusauswahlen basierend auf verschiedenen Fahrern und deren individuellen Präferenzen vorgenommen werden. Demgemäß ist es nicht immer möglich, unter Verwendung eines universellen Modus vorherzusagen, welchen Modus ein spezifischer Fahrer in einer spezifischen Situation wünschen wird. Während massenbeschaffte Daten oder eine Analyse der „bestmöglichen Vermutung“ verwendet werden können, eine Entscheidung zur Modusauswahl zu bilden, wenn begrenzte fahrerspezifische Daten für einen spezifischen Fahrer verfügbar sind, können durch Erkennen der spezifischen Präferenzen des individuellen Fahrers im Verlauf der Zeit genauere Vorhersagen für Modusfreigabe getroffen werden.
Die Eingabe des GPS-Orts gestattet die Aufzeichnung von Fahrmodus-Auswahlen in Bezug auf spezifische Straßen-/Kartenkoordinaten. Bestimmte Straßenbedingungen oder Fahrbedingungen tendieren dahin, an bestimmten Orten im Verlauf der Zeit fortzubestehen. Wenn der Fahrer einen spezifischen Fahrzeugmodus aktiviert, um mit diesen Bedingungen umzugehen, besteht die Wahrscheinlichkeit, dass unter der Annahme, dass die Bedingungen fortbestehen, der Modus zu einer späteren Zeit erneut gewünscht werden wird. Wenn die Bedingungen behoben wurden oder sich verändern, kann ein Abklingfaktor, der mit dem prädiktiven Lernen assoziiert ist, gestatten, dass die Veränderung der Modi langsam bis zu einem Punkt abklingt, an dem er nicht mehr automatisch freigegeben wird, wenn auf den Straßenabschnitt gestoßen wird.
Wenn zum Beispiel ein Fahrer einen Geländemodus aktiviert, um mit einem Straßenabschnitt umzugehen, der mit Schlaglöchern übersät ist, wird der Fahrer diesen Modus wahrscheinlich so lange aktivieren wollen, wie die Schlaglöcher fortbestehen. Wiederholtes manuelles Aktivieren des Modus an denselben GPS-Koordinaten kann als eine Grundlage für eine Vorhersage verwendet werden, dass dieser Modus für die korrespondierenden GPS-Koordinaten erwünscht wird. Wenn die Schlaglöcher repariert werden, kann der Fahrer entweder die manuelle Modusauswahl einstellen oder, falls die Schwellenwerte zur automatischen Modusauswahl erfüllt werden, Aktivierung des automatischen Moduswechsels ablehnen. Im Verlauf der Zeit wird die Freigabe des Modus bei diesen Koordinaten in Bezug auf den Schwellenwert abklingen, bis der Schwellenwert für automatische Aktivierung nicht mehr erfüllt wird. Falls die Schlaglöcher wiederauftauchen, wird Akzeptanz der automatischen Aktivierung und/oder manuellen Aktivierung die beobachteten Instanzen der Modusfreigabe erhöhen, bis der Schwellenwert wieder erreicht oder das beobachtete Niveau über dem Schwellenwert aufrechterhalten wird.
Fahrzeugdaten können auch verwendet werden, um die Entscheidung zum automatischen Aktivieren eines Fahrmodus zu unterstützen. Diese Daten, allgemein als „Kontext“ bekannt, können einen Schnappschuss der umgebenden Fahrbedingungen, der Insassenzusammensetzung usw. bereitstellen. Wenn zum Beispiel Kinder in einem Fahrzeug zugegen sind, kann ein Fahrer häufiger „konservative“ Fahrmodi aktivieren, die die Leistung im Interesse eines mehr konservativen Fahrens verringern können. Gleichermaßen können, wenn bestimmte Wetterbedingungen bestehen, automatische Aktivierung eines geeigneten Modus oder Verhinderung der Aktivierung bestimmter, die Leistung verstärkender Modi durchgeführt werden.
Unter Verwendung der verfügbaren Eingänge kann das System ein Datenrepositorium von Fahrzeugfahrmodi-Kontextkategorien 209 zusammenstellen. Dieses kann zum Beispiel Fahrmodi, die an bestimmten Orten aktiviert wurden, und/oder Fahrmodi, die bei bestimmten Kontexten aktiviert wurden, enthalten. Die Daten können auch eine Kombination von Ort + Kontext repräsentieren, so dass am Ort X der Fahrmodus N nur aktiviert wird, wenn der Kontext Y besteht. Typischerweise werden diese Daten Entscheidungen zum manuellen Aktivieren von Modi repräsentieren, die von einem oder mehreren Fahrern getroffen wurden. Die Fahreridentifikation kann auch zum Unterscheiden zwischen verschiedenen Fahrerpräferenzen an bestimmten Orten für dasselbe Fahrzeug verwendet werden. Auf diese Weise wird ein vorsichtigerer Fahrer nicht automatischen Wechseln basierend auf den Präferenzen eines aggressiveren Fahrers unterworfen, wenn er dasselbe Fahrzeug an demselben Ort fährt.
Basierend auf dem beobachteten Fahrerverhalten, das im Verlauf der Zeit aufgezeichnet wurde 209, kann das System sich mit dem Erlernen des Fahrerverhaltens beschäftigen 211. Dieses wird prädiktive Algorithmen nutzen, um zu „mutmaßen“, wann ein Fahrer typischerweise einen bestimmten Fahrmodus aktivieren würde. Für Fahrerauswahl von Fahrmodi aufgrund von Straßenbedingungen und -geometrie besteht im Allgemeinen eine hohe Wahrscheinlichkeit des Vorkommens (da diese Faktoren typischerweise fortbestehen). Modusauswahlen basierend auf zum Beispiel Straßengeometrie werden wahrscheinlich jedes Mal wiederholt, wenn der Fahrer sich am gleichen Ort im gleichen Fahrzeug befindet. Basierend auf der Häufigkeit manueller Modusauswahl können die Orte des Moduswechsels/der Modusauswahl durch einen gegebenen Fahrer oder durch alle Fahrer eines Fahrzeugs identifiziert werden (bekannte Techniken zur Fahreridentifikation können verwendet werden, um zwischen verschiedenen Fahrzeugfahrern zu unterscheiden, falls gewünscht).

Sobald die Wahrscheinlichkeit einer Modusauswahl, mindestens teilweise basierend auf beobachtetem Verhalten bestimmt, an einem gegebenen Ort einen abstimmbaren Schwellenwert übersteigt, kann dieser Ort als ein Ort für einen fahrerpersonalisierten Moduswechsel charakterisiert werden. Umgebungsinformationen können verwendet werden, um die Vorhersage weiter zu bilden, oder können in einigen Fällen als die Grundlage für automatische Modusfreigabe oder Modusverhinderung verwendet werden (z. B., ohne Einschränkung, Schnee-Modus unter Schneebedingungen an einem gegebenen Ort, Verhinderung des Sport-Modus bei nassen oder vereisten Bedingungen usw.). Die nachstehende Tabelle enthält einige beispielhafte Daten zur Modusauswahl, die als eine Grundlage zum Verständnis der veranschaulichenden Ausführungsformen verwendet werden können.

Fahrer-Modusauswahl	Ort	Wetter	Temperatur	Wahrschei nlichkeit
Kies	GPS_lat 1, GPS_long 1	-	-	L₁
Schnee	GPS_lat 2, GPS_long 2	Schnee	unter Gefrierpunkt	L₂
Sport	GPS_lat 3, GPS_long 3	Regen	~ Gefrierpunkt	0

Ein Fahrerauswahl-Lernalgorithmus kann auf Fahrten des Fahrzeugs in Echtzeit laufen und kann den Fahrermodus-Auswahlstatus aktualisieren. Wenn eine Fahrermodus-Auswahl an einem bestimmten Ort (i) vorgenommen wird, können die GPS-Koordinaten dieses Orts gespeichert werden, und eine anfängliche Wahrscheinlichkeit ist gegeben: L_i(GPS_lat, GPS_long) = p₀, i = 1, ..., n
Dabei ist n die Anzahl der erkannten Orte und ist p₀ die anfängliche Wahrscheinlichkeit des ausgewählten Fahrmodus.
Bei zukünftigen Fahrten, wenn das Fahrzeug durch den ähnlichen Bereich von GPS-Koordinaten von L_i gefahren wird und der Fahrer denselben Fahrmodus auswählt, wird die Wahrscheinlichkeit erhöht wie in: L_i+1(GPS_lat, GPS_long) = α·L_i + (1 – α)·p₀, i = 1, ..., n
Wenn der Fahrmodus nicht ausgewählt wird (oder in mindestens einem Fall automatische Auswahl des Fahrmodus umgekehrt oder abgelehnt wird), wie die Wahrscheinlichkeit: L_i+1(GPS_lat, GPS_long) = α·L_i, i = 1, ..., n
Dabei α ist ein Abklingfaktor.
In einer anderen veranschaulichenden Ausführungsform können die Wahrscheinlichkeitskonstanten für p₀ in der folgenden Form ausgewählt werden:
Dabei sind γ der Wert während der Initialisierung und α der korrespondierende Aktualisierungswert.
Immer wenn die Wahrscheinlichkeit L_i einen festgelegten abstimmbaren Empfindlichkeitsschwellenwert erreicht, basierend zum Beispiel auf der Häufigkeit der Fahrerauswahl, wird der korrespondierende Ort als ein Ort hoher Wahrscheinlichkeit für Moduswechsel angesehen. Wenn L_i dagegen unter das Schwellenwertniveau fällt, wird der Ort unter Umständen nicht mehr als ein Punkt angesehen, an dem ein Moduswechsel erfolgen sollte. Informationen von dem Fahrerauswahl-Lernsystemmodul können zu einem Modul für prädizierte personalisierte Modusauswahl 213 gesandt werden.
Das Modul für prädizierte personalisierte Modusauswahl kann frühzeitige Informationen über bevorstehende Situationen hoher Anforderung bereitstellen. Immer wenn die Wahrscheinlichkeit L_i einen festgelegten abstimmbaren Empfindlichkeitsschwellenwert erreicht, kann der korrespondierende Ort für den ausgewählten Fahrmodus festgehalten werden. Wenn das Fahrzeug dann in zukünftigen Fahrsituationen sich einem GPS-Ort nähert, der von dem Fahrerauswahl-Lernmodul identifiziert wurde, kann das Modul für prädizierten personalisierten Modus automatisch den geeigneten Modus auswählen, wodurch die Fahrzeugeinstellungen in Übereinstimmung mit dem Modus verstärkt werden. In der Praxis kann die Aktivierung eines bestimmten Modus basierend auf einer aggregierten Anzahl von Modusvorkommen oder zum Beispiel auf einem Prozentanteil von Modusvorkommen definiert werden. Wenn zum Beispiel eine Probengröße mit wenigen Daten für einen gegebenen Ort verfügbar ist, kann mindestens eine bestimmte Anzahl von aggregierten Vorkommen erforderlich sein, um einen Modus automatisch zu aktivieren. Natürlich liegt die Auswahl der Aktivierungskriterien im Ermessen des Implementierenden und diese Beispiele werden lediglich zum Zweck der Veranschaulichung bereitgestellt.
3 zeigt einen veranschaulichenden Lernprozess. Hinsichtlich der in dieser Figur beschriebenen veranschaulichenden Ausführungsformen ist zu beachten, dass ein Allzweck-Prozessor zeitweise als ein Spezialprozessor zum Zweck der Ausführung einiger oder sämtlicher der hierin gezeigten beispielhaften Verfahren aktiv wird. Bei der Ausführung von Code, der Anweisungen zum Ausführen einiger oder sämtlicher Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend bis zum Zeitpunkt des Abschlusses des Verfahrens als ein Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann Firmware, die in Übereinstimmung mit einem im Voraus konfigurierten Prozessor wirkt, zu einem angemessenen Ausmaß bewirken, dass der Prozessor als ein Spezialprozessor fungiert, bereitgestellt zum Zweck der Ausführung des Verfahrens oder einer angemessenen Abwandlung davon.
In dem in 3 dargestellten veranschaulichenden Beispiel wartet der Prozess, bis eine Fahrermodusauswahl vorgenommen wird 301. Das Fahrzeug wird im Allgemeinen in einem Grundmodus oder in einem Modus, in den das Fahrzeug zuletzt versetzt wurde, starten. Wenn ein manueller Moduswechsel vorkommt 301, wird der Prozess Fahrzeug-GPS-Koordinaten 303 und etwaige relevante Kontextdaten 305 empfangen. Der Prozess kann dann in Abhängigkeit davon, ob der Modus vorher an diesem Ort und/oder unter dem Kontext (falls vorhanden), empfangen von dem Fahrzeug, beobachtet wurde, entweder eine neue Instanz der Moduseinstellung aufzeichnen oder eine bestehende Instanz der Moduseinstellung für diesen Koordinatensatz 307 aktualisieren.
Solange der neue Modus fortbesteht 309, können Koordinatendaten und Kontextdaten des Fahrzeugs empfangen und aufgezeichnet werden, so dass die Nutzung des Modus über einen Bereich von GPS-Koordinaten aufgezeichnet wird. Sobald der Modus zurückwechselt 309, kann der Prozess die Aufzeichnung von Daten (oder das Aufzeichnen von Daten für den neuen Modus) einstellen, bis ein weiterer Moduswechsel detektiert wird. In mindestens einem Beispiel hat ein Fahrzeug einen „Grundmodus“ zum Fahren, auf den das Fahrzeug im Allgemeinen eingestellt ist. Immer wenn der gegenwärtige Modus dem Grundmodus entspricht, kann das System die Aufzeichnung von Daten überspringen, da bei Abwesenheit von Daten die Verwendung dieses Modus angenommen werden kann. Immer wenn ein Nicht-Grundmodus detektiert wird, kann das System die relevanten Daten für die Dauer der Nutzung des Nicht-Grundmodus aufzeichnen. Demgemäß könnten, wenn der Modus A der Grundmodus ist und die Modi B und C alternative Modi sind, die GPS- und Kontextdaten über den Verlauf Modus A, Modus B, Modus C, Modus A, Modus B, Modus A jeweils für Modus B, Modus C und dann wieder Modus B aufgezeichnet und die Daten für die Instanzen des Modus A ignoriert werden.
Daten, die für beobachtete Instanzen von Moduswechseln aufgezeichnet werden, können in Bezug auf den Ort in Paaren von Modus:Ort gespeichert werden oder können zum Beispiel in Bezug auf einen Satz Modus:Ort:Kontext gespeichert werden. Im Modell des Paars Modus:Ort wird die Modusnutzung als eine binäre Variable beobachtet, die an einem gegebenen Ort entweder ein oder aus ist. Zur Erzielung eines höheren Grads der Spezifizität hinsichtlich der Modusvorhersage und -freigabe kann der Kontext eingeschlossen werden. Dies kann helfen, die Kontexte zu verfeinern, bei denen ein bestimmter Modus aktiviert wird.
Unter der Annahme, dass Modus A mit dem „grundlegenden“ Fahrmodus, Modus B mit einem Sport-Fahrmodus und Modus C mit einem Fahrmodus mit erhöhter Traktion korrespondieren, kann beobachtet werden, dass Modus B an bestimmten Orten nur aktiviert wird, wenn kein unfreundliches Wetter besteht. Ferner kann beobachtet werden, dass Modus B niemals aktiviert wird, wenn Kinder (durch Sensoren des Fahrzeugs identifizierbar) in einem Fahrzeug anwesend sind. Der Modus C kann an bestimmten Orten nur bei Schnee oder Regen aktiviert werden und wird unter Umständen niemals bei gutem Wetter aktiviert.
Durch Verwendung von Kontext kann die Vorhersage für bedingtes Verhalten verbessert werden. Wenn ein Fahrer zum Beispiel fünfzig Mal durch den Ort i fährt und den Modus C in einhundert Prozent der sieben Male, bei denen Straßenglätte vorliegt, aktiviert, wird der Fahrer wahrscheinlich immer den Modus C an dem Ort aktiviert haben, wenn Straßenglätte vorliegt. Aber weil es dreiundvierzig Instanzen gab, in denen Modus C nicht aktiviert wurde, ist ein Wert Modus:Ort unter Umständen nicht über einem Schwellenwert für Modusaktivierung, weil Abklingen dahin tendieren würde, die gesamte Nutzung auf einen Punkt abzusenken, an dem es weniger als wahrscheinlich ist, dass Modus C zu einem beliebigen Zeitpunkt für den Ort i aktiviert wird. Wenn dagegen der Kontext (z. B. in diesem Fall Straßenglätte) genutzt wird, kann beobachtet werden, dass der Modus C im Kontext von Straßenglätte bei einhundert Prozent der Zeit genutzt wird. Dementsprechend kann, wenn es gegenwärtig glatt ist, der Modus C beim nächsten Mal, wenn das Fahrzeug den Ort i erreicht, freigegeben werden.
Verschiedene Typen von Kontext können in den Modusbewertungen enthalten sein, wie es für ein gegebenes Modell passend ist. Vermehren der verfügbaren Kontextvariablen wird die Genauigkeit bei ausreichender Probengröße verbessern, wird aber auch dahin tendieren, einen größeren Bereich von Ergebnissen bereitzustellen, aus denen Schlüsse gezogen werden können. Bei unzureichenden Probengrößen kann der große Bereich von Ergebnissen aussagekräftige prädiktive Entscheidungen schwierig machen. Demgemäß ist es in einem Beispiel möglich, die Daten von Modus:Ort:Kontext zu speichern, aber nur den Datenabschnitt Modus:Ort der gespeicherten Daten zu untersuchen, bis mindestens eine aussagekräftige Menge (bestimmt durch den Implementierenden) von Proben beobachtet wurden.
Sobald eine ersichtliche Korrelation von Kontext zum Modus beobachtet wird oder eine Trennung von Kontext zu Modus beobachtet wird (d. h. es scheint, dass der Kontext keinen Einfluss auf die Modusaktivierung hat), kann das System unter Nutzung des Kontexts mehr fundierte Entscheidungen fällen. Wenn zum Beispiel der Kontext S (Straßenglätte) immer während der Modusaktivierung vorliegt und niemals vorliegt, wenn der Modus nicht ausgewählt ist, kann angenommen werden, dass der Kontext M zur Bildung der Modusvorhersage nutzbar ist. Wenn dagegen der Kontext K (Kinder anwesend/Insassenzusammensetzung) während der Auswahl des Modus und der Nichtauswahl des Modus (innerhalb einer Toleranz) gleich vorliegt, kann angenommen werden, dass der Kontext K keinen Einfluss auf die Modusvorhersage hat. Wenn gewünscht, können kontextbezogene Daten aus einer Vielfalt von Instanzen der Modusaktivierung (für alle Modi oder für einen besonderen Modus, über mehrere verschiedene GPS-Koordinatenorte) verwendet werden, um Korrelationen zwischen bestimmten Kontexten und Modi zu bestimmen. Folglich kann das System, wenn nur begrenzte Proben für einen gegebenen Koordinatenort verfügbar sind, aber eine Anzahl von Orten über damit assoziierte Daten verfügt, schneller Schlüsse über die Relevanz eines bestimmten Kontexts ziehen, basierend auf beobachtetem Verhalten an mehreren Orten in Verbindung mit einem gemeinsamen Kontext (z. B. Straßenglätte).
4 zeigt einen veranschaulichenden prädiktiven Fahrmodus-Aktivierungsprozess. Hinsichtlich der in dieser Figur beschriebenen veranschaulichenden Ausführungsformen ist zu beachten, dass ein Allzweck-Prozessor zeitweise als ein Spezialprozessor zum Zweck der Ausführung einiger oder sämtlicher der hierin gezeigten beispielhaften Verfahren aktiv wird. Bei der Ausführung von Code, der Anweisungen zum Ausführen einiger oder sämtlicher Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend bis zum Zeitpunkt des Abschlusses des Verfahrens als ein Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann Firmware, die in Übereinstimmung mit einem im Voraus konfigurierten Prozessor wirkt, zu einem angemessenen Ausmaß bewirken, dass der Prozessor als ein Spezialprozessor fungiert, bereitgestellt zum Zweck der Ausführung des Verfahrens oder einer angemessenen Abwandlung davon.
In dem in 4 dargestellten veranschaulichenden Beispiel wird der Prozess versuchen, einen Fahrmodus prädiktiv zu aktivieren (wenn angemessen). Demgemäß empfängt der Prozess in diesem Beispiel die GPS-Ortsdaten 401 und die gegenwärtigen Kontextdaten 403. Der Prozess greift dann auf das Vorhersagemodul 405 zu, um zu bestimmen, ob die gegenwärtigen Ortsdaten mit der wahrscheinlichen Aktivierung eines neuen Fahrmodus 407 korrespondieren. Wenn die Daten nicht angeben, dass ein neuer Modus ausgewählt werden sollte (z. B., ohne Einschränkung, liegen unzureichende Daten vor, keine Daten über einem Schwellenwert oder die Daten geben an, dass Beibehalten eines gegenwärtigen Modus gewünscht wird), wird der Prozess mit späteren GPS- und Kontextdaten bis zu einem Zeitpunkt, an dem ein Moduswechsel vorhergesagt wird, wiederholt.
Wenn die Daten angeben, dass vergangenes Verhalten unter ähnlichen Umständen oder mindestens an einem ähnlichen Ort dahin tendiert, einen gewünschten Moduswechsel anzugeben (z. B. beobachtetes Verhalten über einem Schwellenwert), bestimmt der Prozess dann, ob die gegenwärtigen Kontextdaten für den möglichen neuen Modus 409 relevant sind. Zum Beispiel kann an einem gegebenen Ort i₁ ein einzelner Modus in neunzig Prozent der Zeit unabhängig vom Kontext ausgewählt werden. Folglich scheinen in diesem Beispiel die Kontextdaten die Modusauswahl nicht zu verändern. Aber an einem anderen Ort i₂ kann beobachtet werden, dass zwei neue Modi eine gewisse Anzahl von Malen ausgewählt werden, wobei jeder einen verschiedenen, damit hoch korrelierten Kontext aufweist. Folglich können in diesem Beispiel die Kontextdaten für die Modusauswahl relevant sein.
In einem weiteren Beispiel der Kontextrelevanz können bestimmte Fahrmodi basierend auf bestimmten Kontexten typischerweise freigegeben oder typischerweise verhindert werden (zumindest in Bezug auf automatische Aktivierung). Wenn daher die Daten angeben, dass der Modus B (Sport) oder der Modus C (verbesserte Traktion) an einem Ort i₃ beobachtet wurde und der Modus B niemals bei Straßenglätte automatisch aktiviert wird und/oder der Modus C immer automatisch bei Straßenglätte aktiviert wird, kann ein Kontext, der Straßenglätte angibt, ebenfalls als für eine endgültige Entscheidung relevant angesehen werden, unabhängig davon, ob der Kontext in der Vergangenheit in Bezug auf die Aktivierung des Modus B oder des Modus C für diesen besonderen Ort i₃ tatsächlich beobachtet wurde.
Wenn bestimmt wird, dass der Kontext keinen aussagekräftigen Einfluss auf die Modusvorhersage hat 409, wird der Prozess bestimmen, ob die Instanzen der vorher beobachteten Modusfreigabe über den Schwellenwert für automatische Aktivierung ansteigen 411. Falls nicht, wird der Prozess für einen nächsten GPS-Ort wiederholt.
Wenn das beobachtete Verhalten eine Wahrscheinlichkeit angibt, dass der Modus manuell freigegeben wird 411, kann der Prozess den vorhergesagten Modus 413 für den gegenwärtigen GPS-Ort automatisch aktivieren. Da es einen Abklingfaktor geben kann, der damit assoziiert ist, dass ein Modus manuell nicht freigegeben wird, oder da automatische Aktivierung zur Dauerhaftigkeit des Modus beitragen kann, aber der Fahrer den Modus unter Umständen nicht mehr möchte, wird dieser beispielhafte Prozess den Fahrer benachrichtigen, dass der Modus freigegeben wurde 415. In einem anderen Beispiel kann der Prozess den Fahrer mit einer einfach auswählbaren Option (z. B. durch eine Berührung oder Sprache auswählbar) zum Aktivieren des Modus versehen.
In diesem Beispiel verfügt der Fahrer über die Option, zu einem vorherigen Fahrmodus zurückzukehren, nachdem der neue Modus freigegeben wurde. Wenn der Fahrer zum vorherigen Modus zurückkehrt 417, wird der Prozess die Rückkehr als eine Instanz von Nichtauswahl des Modus behandeln und kann die Daten mit der Rückkehr aktualisieren 421. In einem Modell ist diese Aktualisierung das gleiche wie Passieren des Datenpunkts, ohne den Modus zu aktivieren, was die Anwendung eines Abklingens ist. In einem anderen Beispiel kann, da der Fahrer die Auswahl des Modus affirmativ rückgängig gemacht hat, aufgrund der Tatsache, dass durch den Fahrer aus irgendeinem Grund ausdrücklich bestimmt wurde, dass die Vorhersage falsch war, beschleunigtes Abklingen angewandt werden.
Zusätzlich zu einem geeigneten Abklingen kann der Prozess außerdem die Option für automatischen Moduswechsel vorübergehend deaktivieren 423. Dies verhindert, dass das System versucht, bei der nächsten Koordinaten-Instanz noch einmal in den nicht gewünschten Modus zu schalten. Das heißt, wenn der Fahrer den Modus B über eine Straßenstrecke von einer Meile nicht mehr wollte und die Modusvorhersage alle 0,1 Meilen erfolgt, würde der Prozess vermeiden, alle 0,1 Meilen zu versuchen, in den Modus B zu wechseln, wodurch sich der Fahrer möglicherweise gestört fühlen würde. Sobald die festgelegte Strecke kontinuierlicher Dauerhaftigkeit des Modus B (basierend auf vorher beobachtetem Verhalten) passiert wäre, könnte der Prozess die Vorhersage des automatischen Moduswechsels fortsetzen.
Zurückkehrend zu Schritt 409, könnte der Prozess in diesem Beispiel, falls der Kontext aus einem beliebigen Grund relevant ist, versuchen zu bestimmen, welche der Kontextdaten für die gegenwärtige Analyse nützlich sind 425. Das heißt, da verschiedener Kontext in verschiedenen Szenarien bedeutsam sein könnte, eine Vielfalt von Kontextdaten erfasst und dem Vorhersageprozess zu jedem Zeitpunkt bereitgestellt werden könnten, selbst wenn nur einige der Kontextdaten für eine gegebene Situation von Bedeutung sind.
Nachdem die relevanten Kontextdaten extrahiert wurden, bestimmt der Prozess, ob die Kontextdaten ein Szenarium ständiger Aktivierung 427 vorgeben. In einem Beispiel kann, wenn ein Fahrer ein Fahrzeug zuerst kauft, das Fahrzeug derart konfiguriert sein, dass bestimmte Kontexte immer in der Aktivierung bestimmter Fahrmodi resultieren. Demgemäß kann, entweder für einen besonderen Ort oder allgemein für alle Orte, das Vorkommen zum Beispiel des Kontexts Straßenglätte immer anfangs in der Aktivierung verbesserter Traktionssteuerung resultieren oder zum Beispiel immer in der Aktivierung verbesserter Traktionssteuerung an Straßenpunkten mit bekannten Charakteristika (z. B. scharfe Kurven, Begrenzungen hoher Geschwindigkeiten, beanspruchende Geometrie) resultieren. Demgemäß kann in diesem Beispiel, wenn auf einen gegenwärtiger Ort, der mit einem bekannten Charakteristikum korrespondiert, zum ersten Mal getroffen wird (oder eine begrenzte Anzahl von Malen getroffen wurde, so dass die Daten über beobachtetes Verhalten unzureichend sind, eine fundierte, für den Fahrer personalisierte Entscheidung zu fällen), ein voreingestellter Moduswechsel für diesen Ort vorhanden sein. Anders ausgedrückt, geben die bekannten Charakteristika, selbst wenn nicht genügend persönliche Fahrerdaten vorhanden sind, um einen Moduswechsel an diesem Ort vorzugeben, anfangs einen Moduswechsel vor, in diesem Beispiel in Verbindung mit dem Kontext Straßenglätte.
Obwohl der Modus automatisch geändert werden kann, kann es sein, dass der Fahrer eigentlich nicht möchte, dass der Modus an diesem Ort geändert wird, unabhängig vom Kontext. Dementsprechend kann der Prozess in diesem Beispiel, wenn der Modus basierend auf dem bestimmten Kontext (und, in diesem Beispiel, bestimmten Ort) automatisch geändert wird, den vorher diskutierten Prozess der Fahrerbenachrichtigung/Rückkehr/Aktualisierung aktivieren. Das heißt, wenn der Fahrer dem Moduswechsel zustimmt (d. h. nicht zum vorherigen Modus zurückkehrt), aktualisiert der Prozess den Moduswechsel affirmativ als spezifisches beobachtetes Verhalten des Fahrers. Wenn der Fahrer zum vorherigen Modus zurückkehrt, kann der Prozess abklingen oder anderenfalls den Moduswechsel als spezifisches beobachtetes Verhalten des Fahrers negativ aktualisieren. Auf diese Weise kann automatischer Moduswechsel basierend auf bestimmten Kontexten, wie von einem Erstausstatter (OEM) eingestellt, immer noch an die Wünsche eines bestimmten Fahrers angepasst werden.
Gleichermaßen kann es bestimmte Kontexte geben, die voreingestellt sind, einen Moduswechsel automatisch zu blockieren, wie Straßenglätte, wenn ein Sport-Modus vorhergesagt wird. Es kann sein, dass der vorher beobachtete Kontext keinen Hinweis darauf gibt, ob ein Modus basierend auf einem vorher beobachteten Kontext freigegeben wurde. Zum Beispiel war das Wetter bei allen vorher beobachteten Instanzen des Erreichens der gegenwärtigen Koordinaten gut. Während immer ein Sport-Modus ausgewählt wurde, gibt es daher nichts, das darauf hinweist, ob ein derartiger Modus ausgewählt werden würde, wenn das Wetter Straßenglätte bewirken würde. Dementsprechend kann der OEM anfängliche Blockierungskontexte für die Aktivierung bestimmter Modi spezifizieren 429.
Wie bei den Kontexten für automatische Aktivierung, können die Kontexte für automatisches Blockieren im Verlauf der Zeit basierend auf Fahrerpräferenzen zugeschnitten werden. Wenn im obigen Beispiel die automatische Aktivierung eines Sport-Modus basierend auf dem Vorkommen des Kontexts „Straßenglätte“ blockiert wird 431, kann der Fahrer benachrichtigt werden, dass der vorhergesagte Kontexttausch nicht erfolgte 433. Wenn der Fahrer den Fahrmodus manuell trotzdem zum Sport-Modus verändert 435, kann der Prozess die Straßenglätte-Ort:Modus:Kontext-Daten für diesen Ort aktualisieren 437, so dass der Sport-Modus bei ausreichenden Beobachtungen an diesem Ort nicht mehr blockiert werden wird, selbst bei Vorliegen von Straßenglätte.
Wenn der Fahrer dagegen den Modus nicht manuell zum Sport-Modus verändert, wird dies als Zustimmung zum Blockieren angesehen, was als eine Angabe verstanden wird, dass die Blockierung akzeptiert wird und dass der Fahrer entweder den grundlegenden Modus oder einen anderen kontextangemessenen Modus (falls ein anderer Modus vom Fahrer manuell eingestellt wird) bevorzugt. In diesem Fall können die Ort:Modus:Kontext-Daten für Straßenglätte und Sport-Modus an diesem Ort abklingen, so dass die Korrespondenz von Kontext, Modus und Ort in zukünftigen Instanzen unter dem Schwellenwert ist oder darunter bleibt. Akzeptanz der automatischen Blockierung bei dem gegebenen Kontext könnte zusätzlich oder alternativ positiv aktualisiert werden 439, um das Blockieren von Sport-Modi (an diesem Ort oder an einer beliebigen Anzahl von Orten) basierend auf dem Kontext „Straßenglätte“ zu bestätigen/zu verstärken.
Natürlich ist es ebenfalls möglich, bestimmte Modi bei bestimmten Bedingungen unabhängig von den Fahrerpräferenzen immer zu blockieren oder immer zu aktivieren. In diesen Fällen müsste der Fahrer einfach einen anderen Modus manuell aktivieren, falls gewünscht. Im Allgemeinen ist es durch die Verwendung von Kontext, Ortsinformationen und beobachtetem Fahrerverhalten bei den Kontexten und an den Orten jedoch möglich, Moduswechsel durch den Fahrer mit einem hohen Grad der Genauigkeit vorherzusagen, sobald ausreichende Daten erlangt wurden. Das Niveau, das sich als „ausreichende Daten“ eignet, kann basierend auf den besonderen Wünschen des Implementierenden eingestellt werden und kann so wenig wie eine einzige oder einige wenige Instanzen sein, aus denen weitere Vorhersagen entwickelt werden können.
Während vorstehend beispielhafte Ausführungsformen beschrieben werden, ist es nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Die in der Patentschrift verwendeten Wörter sind vielmehr Wörter der Beschreibung und nicht der Einschränkung, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne das Wesen und den Schutzumfang der Erfindung zu verlassen. Zusätzlich können die Merkmale der verschiedenen implementierenden Ausfü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 [0019]
IEEE 802 LAN [0019]
IEEE 802 PAN [0019]
IEEE 1394 [0022]
IEEE 1284 [0022]
IEEE 803.11 [0024]

Claims

System, umfassend: einen Prozessor, konfiguriert zum: Empfangen eines Fahrzeugorts; Abrufen fahrerspezifischer Fahrmoduswechsel-Daten für den Fahrzeugort; Bestimmen, basierend auf den abgerufenen Daten, ob ein Fahrzeugfahrmoduswechsel an dem Fahrzeugort vorher ausreichend vorgekommen ist, um einen im Voraus definierten Schwellenwert zu überschreiten; und automatisches Wechseln eines Fahrzeugfahrmodus zu einem Fahrmodus, der mit dem Fahrmoduswechsel assoziiert ist, der vorher ausreichend vorgekommen ist, um den im Voraus definierten Schwellenwert zu überschreiten.
System nach Anspruch 1, wobei der Prozessor ferner konfiguriert ist, einen Fahrzeugkontext zu empfangen, und wobei der Prozessor konfiguriert ist, zu bestimmen, ob der Fahrzeugfahrmoduswechsel vorher ausreichend an dem Fahrzeugort unter mindestens einem Aspekt des empfangenen Kontexts vorgekommen ist, um den im Voraus definierten Schwellenwert zu überschreiten.
System nach Anspruch 2, wobei der mindestens eine Aspekt des empfangenen Kontexts gegenwärtige Wetterbedingungen enthält.
System nach Anspruch 2, wobei der mindestens eine Aspekt des empfangenen Kontexts gegenwärtige Insassenzusammensetzung enthält.
System nach Anspruch 1, wobei der Schwellenwert auf einer aggregierten Anzahl von Vorkommen basiert.
System nach Anspruch 1, wobei der Schwellenwert auf einem Prozentanteil von Vorkommen in Bezug auf eine Anzahl von Malen, die das Fahrzeug an dem Fahrzeugort lokalisiert wurde, basiert.
System nach Anspruch 1, wobei der Prozessor ferner konfiguriert ist, einen Fahrzeugkontext zu empfangen, und wobei der Prozessor ferner konfiguriert ist, einen Fahrmoduswechsel zu blockieren, der anderenfalls als ein Ergebnis des Fahrmoduswechsels, der vorher ausreichend vorgekommen ist, um den Schwellenwert zu überschreiten, automatisch aktiviert werden würde, wobei das Blockieren auf mindestens einem Aspekt des empfangenen Kontexts basiert.
System nach Anspruch 7, wobei der mindestens eine Aspekt eine Wetterbedingung enthält.
Computerimplementiertes Verfahren, umfassend: Empfangen eines Fahrzeugorts; Abrufen fahrerspezifischer Fahrmoduswechsel-Daten für den Fahrzeugort; Bestimmen, basierend auf den abgerufenen Daten, ob ein Fahrzeugfahrmoduswechsel an dem Fahrzeugort vorher ausreichend vorgekommen ist, um einen im Voraus definierten Schwellenwert zu überschreiten; und automatisches Wechseln eines Fahrzeugfahrmodus zu einem Fahrmodus, der aus dem Fahrmoduswechsel resultiert, der vorher ausreichend vorgekommen ist, um den im Voraus definierten Schwellenwert zu überschreiten.
Verfahren nach Anspruch 9, ferner enthaltend, einen Fahrzeugkontext zu empfangen, und wobei das Bestimmen enthält, zu bestimmen, ob der Fahrzeugfahrmoduswechsel vorher ausreichend an dem Fahrzeugort unter mindestens einem Aspekt des empfangenen Kontexts vorgekommen ist, um den im Voraus definierten Schwellenwert zu überschreiten.
Verfahren nach Anspruch 10, wobei der mindestens eine Aspekt des empfangenen Kontexts gegenwärtige Wetterbedingungen enthält.
Verfahren nach Anspruch 10, wobei der mindestens eine Aspekt des empfangenen Kontexts gegenwärtige Insassenzusammensetzung enthält.
Verfahren nach Anspruch 9, wobei der Schwellenwert auf einer aggregierten Anzahl von Vorkommen basiert.
Verfahren nach Anspruch 9, wobei der Schwellenwert auf einem Prozentanteil von Vorkommen in Bezug auf eine Anzahl von Malen, die das Fahrzeug an dem empfangenen Fahrzeugort lokalisiert wurde, basiert.
Verfahren nach Anspruch 9, ferner enthaltend, einen Fahrzeugkontext zu empfangen und einen Fahrmoduswechsel zu blockieren, der anderenfalls als ein Ergebnis des Fahrmoduswechsels, der vorher ausreichend vorgekommen ist, um den Schwellenwert zu überschreiten, automatisch aktiviert werden würde, wobei das Blockieren auf mindestens einem Aspekt des empfangenen Kontexts basiert.
Verfahren nach Anspruch 15, wobei der mindestens eine Aspekt eine Wetterbedingung enthält.
System, umfassend: einen Prozessor, konfiguriert zum: Empfangen einer Fahrereingabe, die einen Fahrzeugfahrmoduswechsel angibt; Empfangen eines Fahrzeugorts; und Speichern einer Instanz der Korrespondenz zwischen dem Fahrzeugfahrmoduswechsel und dem Fahrzeugort.
System nach Anspruch 17, wobei der Prozessor ferner konfiguriert ist, einen Fahrzeugkontext zu empfangen und mindestens einen Aspekt des Fahrzeugkontexts in Bezug auf die Instanz der Korrespondenz zu speichern, so dass die Instanz der Korrespondenz zwischen dem mindestens einen Aspekt des Fahrzeugkontexts, dem Fahrzeugfahrmoduswechsel und dem Fahrzeugort ist.
System nach Anspruch 17, wobei der Prozessor ferner konfiguriert ist, einen Wert einer Vorkommenswahrscheinlichkeitsvariablen, der einen gegenwärtigen und vergangenen Empfang der Fahrereingabe, die einen Fahrzeugfahrmoduswechsel angibt, an dem empfangenen Fahrzeugort repräsentiert, als Teil der Speicherung der Instanz der Korrespondenz zu aktualisieren.
System nach Anspruch 19, wobei der Prozessor ferner konfiguriert ist, den Wert der Variablen, der eine Instanz keiner Korrespondenz zwischen Fahrzeugfahrmoduswechsel und Fahrzeugort angibt, abklingen zu lassen, wenn der Prozessor einen Fahrzeugort empfängt, für den ein Wert einer Vorkommenswahrscheinlichkeitsvariablen vorher aktualisiert wurde, ohne Fahrereingabe zu empfangen, die einen Fahrzeugfahrmoduswechsel angibt.