DE102015118295A1

DE102015118295A1 - Fahrerzentriertes Lernen

Info

Publication number: DE102015118295A1
Application number: DE102015118295.5A
Authority: DE
Inventors: Kwaku O. Prakah-Asante; Hsin-Hsiang Yang
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2014-10-28
Filing date: 2015-10-27
Publication date: 2016-04-28
Also published as: CN105539331A; US20160114805A1; US10272923B2

Abstract

Ein Fahrzeugsystem beinhaltet ein Remote-Gerät mit einem Prozessor, der dazu programmiert ist, Fahrerdaten in Echtzeit während des Betriebs eines ersten Fahrzeugs zu empfangen. Der Prozessor verarbeitet die Fahrerdaten, um ein Fahrerverhalten zu bestimmen. Ein Befehlssignal wird erzeugt, um einem zweiten Fahrzeug zu befehlen, mindestens einen Parameter gemäß dem Fahrerverhalten zu aktualisieren.

Description

HINTERGRUND
Viele Fahrzeugcharakteristika können angepasst oder angeglichen werden, um den Bedürfnissen oder Präferenzen eines Insassen zu entsprechen. Beim erstmaligen Einsteigen in ein bestimmtes Fahrzeug beispielsweise wird ein Fahrer den Sitz und die Spiegel nach seiner Vorliebe justieren. Der Fahrer kann auch neue Radiosendervoreinstellungen speichern, die Klimaanlageneinstellungen justieren, die Navigationspräferenzen aktualisieren, die Infotainment-Anzeige ändern, die Innenraumbeleuchtungsfarben ändern usw. Auf der Fahrzeugseite können Fahrzeuguntersysteme adaptive Algorithmen nutzen, um die Präferenzen und Verhaltensweisen des Fahrers zu „lernen“ und die Fahrzeugsteuerbefehle entsprechend zu justieren. Derartige Anpassungen und Angleichungen steigern das Fahrvergnügen des Insassen in Bezug auf das Fahrzeug. Einige Fahrzeuge versuchen, sich an Anpassungen eines bestimmten Fahrers zu „erinnern“, und werden diese Anpassungen jedes Mal anwenden, wenn der Fahrer in das Fahrzeug einsteigt.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 stellt ein beispielhaftes Fahrzeug dar, das Parameter auf der Basis von Daten anwendet, die von einem Remote-Gerät empfangen wurden.
2 zeigt Blockdiagramme eines beispielhaften Remote-Geräts in Kommunikation mit einem Fahrzeug.
3 stellt Blockdiagramme eines anderen beispielhaften Remote-Geräts in Kommunikation mit einem Fahrzeug dar.
4 ist ein Ablaufdiagramm eines beispielhaften Vorgangs, der auf dem Remote-Gerät umgesetzt werden kann, um das Fahrzeug mit Parametern auszustatten.
5 ist ein Ablaufdiagramm eines beispielhaften Vorgangs, der auf dem Fahrzeug umgesetzt werden kann, um Parameter von dem Remote-Gerät zu empfangen.
AUSFÜHRLICHE BESCHREIBUNG
Bei gemeinsam genutzten Fahrzeugen – das heißt, Fahrzeuge, die von mehreren Fahrern verwendet werden – kann es für das Fahrzeug schwierig sein zu unterscheiden, wer zu einer bestimmten Zeit fährt. Da unterschiedliche Fahrer unterschiedliche Präferenzen haben, weiß das Fahrzeug möglicherweise nicht, welche angepassten Einstellungen anzuwenden sind. Anstelle des Anwendens angepasster Einstellungen verwenden gemeinsam genutzte Fahrzeuge, wie Mietwagen, Flottenfahrzeuge, Fahrzeuge, die Teil von Carsharing-Programmen sind, und sogar Familienfahrzeuge mit mehreren Fahrern, Standardeinstellungen. Ein Beispiel einer Standardeinstellung kann die „zuletzt verwendete“ Einstellung beinhalten. Folglich müssen Fahrer, die oft gemeinsam genutzte Fahrzeuge verwenden, ständig die Fahrzeugeinstellungen auf die Präferenzen des Fahrers ändern.
Eine Methode zum Bereitstellen von angepassten Einstellungen in gemeinsam genutzten Fahrzeugen bezieht ein Fahrzeugsystem ein, das Signale von einem Remote-Gerät empfängt. Das Remote-Gerät wird von seinem Besitzer getragen, wenn der Besitzer ein Host-Fahrzeug (z. B. ein „erstes Fahrzeug“) betreibt. Das Remote-Gerät beinhaltet einen Prozessor, der dazu programmiert ist, Fahrerdaten in Echtzeit zu empfangen. Der Prozessor verarbeitet die Fahrerdaten, um das typische Fahrverhalten oder die Präferenzen eines Fahrers zu bestimmen. Wenn der Besitzer das Remote-Gerät in ein anderes Fahrzeug (z. B. ein „zweites Fahrzeug“) nimmt, wird ein Befehlssignal erzeugt, um einem zweiten Fahrzeug zu befehlen, mindestens einen Parameter gemäß den Fahrerdaten zu aktualisieren. Der Parameter kann z. B. die Präferenzen eines Fahrers beinhalten. Mit einem derartigen System wird ein beliebiges Fahrzeug, das mit dem Remote-Gerät kommunizieren kann, die Präferenzen des Fahrers anwenden, was das Erlebnis des Fahrens eines gemeinsam genutzten Fahrzeugs für den Fahrer angenehmer macht.
Die gezeigten Elemente können viele verschiedene Formen annehmen und mehrere und/oder alternierende Komponenten und Einrichtungen beinhalten. Die dargestellten beispielhaften Komponenten sollen nicht einschränkend sein. In der Tat können zusätzliche oder alternative Komponenten und/oder Umsetzungen verwendet werden.
Wie in 1 dargestellt, ist das Host-Fahrzeug 100 dazu konfiguriert, bestimmte Betriebsparameter auf der Basis von Signalen, die von einem Remote-Gerät 105 empfangen werden, zu aktualisieren. Die Betriebsparameter können dazu verwendet werden, die Art und Weise zu definieren, in der bestimmte Fahrzeuguntersysteme arbeiten. Betriebsparameter können beispielsweise die Getriebeschaltlogik definieren. Einige Betriebsparameter können bewirken, dass das Host-Fahrzeug 100 in einem „Sport“-Modus zu arbeiten, während andere Betriebsparameter bewirken können, dass das Host-Fahrzeug 100 in einem „Kraftstoffeffizienz“-Modus arbeitet. Andere Betriebspräferenzen können sich auf einen autonomen Fahrzeugbetrieb beziehen. Einige Betriebsparameter können definieren, wie nah das Host-Fahrzeug 100 einem „vorderen Fahrzeug“ während eines autonomen Betriebs folgt. In einigen möglichen Ansätzen können die Betriebsparameter sich auf Insassenpräferenzen beziehen, wie Radiosendervoreinstellungen, Klimaanlageneinstellungen, Navigationspräferenzen, Infotainment-Anzeigepräferenzen, Innenraumbeleuchtungsfarbpräferenz usw.
Das Host-Fahrzeug 100 kann Fahrerdaten während des Betriebs erfassen. Fahrerdaten können sich auf die Präferenzen des Fahrers beziehen oder können auf dem Verhalten des Fahrers beim Betreiben des Host-Fahrzeugs 100 basieren. Fahrerdaten können beispielsweise darauf basieren, z. B. wie aggressiv der Fahrer die Spuren wechselt, wie nah der Fahrer einem vorderen Fahrzeug folgt, wie aggressiv der Fahrer das Host-Fahrzeug 100 beschleunigt oder abbremst oder dergleichen. Das Host-Fahrzeug 100 kann die Fahrerdaten zumindest vorübergehend in einem Bord-Speichergerät 130 speichern. Obgleich es als eine Limousine dargestellt ist, kann das Host-Fahrzeug 100 einen beliebigen Personen- oder Nutzkraftwagen beinhalten, wie ein Auto, einen Lastkraftwagen, einen Geländewagen, ein Crossover-Fahrzeug, einen Lieferwagen, einen Kleinbus, ein Taxi, einen Bus usw. In einigen möglichen Ansätzen ist das Host-Fahrzeug 100 ein autonomes Fahrzeug, das dazu konfiguriert ist, in einem autonomen (z. B. fahrerlosen) Modus, einem teilautonomen Modus und/oder einem nicht autonomen Modus zu arbeiten.
Das Remote-Gerät 105 kann ein Datenverarbeitungsgerät beinhalten, das dazu konfiguriert ist, sich mit dem Host-Fahrzeug 100 drahtgebunden oder drahtlos zu verbinden (Paarung) und die Fahrerdaten in Echtzeit von dem Host-Fahrzeug 100 zu empfangen. Das Remote-Gerät 105 kann die Fahrerdaten verarbeiten, um das Verhalten, die Präferenzen oder beides eines Fahrers zu bestimmen. Alternativ dazu kann das Host-Fahrzeug 100 die Fahrerdaten verarbeiten und das Remote-Gerät 105 kann die verarbeiteten Fahrerdaten speichern, die das Verhalten oder die Präferenzen des Fahrers darstellen.
In einem möglichen Ansatz kann das Remote-Gerät 105 ein tragbares Gerät sein, das von dem Fahrer in das Host-Fahrzeug 100 getragen wird. Das Remote-Gerät 105 kann beispielsweise ein Mobilfunkgerät beinhalten, wie ein Mobiltelefon oder einen Tablet-Computer. Alternativ dazu kann das Remote-Gerät 105 einen Remote-Server, wie einen Cloud-basierten Server, in drahtloser Kommunikation mit dem Host-Fahrzeug 100 beinhalten. Der Remote-Server kann die Fahrerdaten verarbeiten und Parameter auf der Basis der Fahrerdaten an das Host-Fahrzeug 100 oder ein beliebiges anderes Fahrzeug, das mit dem Remote-Gerät 105 gepaart ist, übertragen.
2 zeigt Blockdiagramme eines beispielhaften Remote-Geräts 105 und eines beispielhaften Fahrzeugs 100. Wie dargestellt, beinhaltet das Remote-Gerät 105 ein Speichergerät 110 und einen Prozessor 115. Das Host-Fahrzeug 100 beinhaltet ein Fahrzeugsteuersystem 120. Das Remote-Gerät 105 und das Fahrzeugsteuersystem 120 sind dazu konfiguriert, über eine Kommunikationsschnittstelle 125 zu kommunizieren. Das Remote-Gerät 105 und das Fahrzeugsteuersystem 120 können dazu konfiguriert sein, sich mittels der Kommunikationsschnittstelle 125 miteinander zu verbinden (Paarung). Die Kommunikationsschnittstelle 125 kann dazu konfiguriert sein, dem Remote-Gerät 105 und dem Fahrzeugsteuersystem 120 zu ermöglichen, durch ein drahtgebundenes oder drahtloses Kommunikationsprotokoll zu kommunizieren. Die Kommunikationsschnittstelle 125 kann beispielsweise die Übertragung von Fahrerdaten, die das Fahrerverhalten, die Betriebsparameter usw. beinhalten oder darstellen können, von dem Host-Fahrzeug 100 an das Remote-Gerät 105 sowie von dem Remote-Gerät 105 an das Host-Fahrzeug 100 erleichtern.
Das Speichergerät 110 kann dazu programmiert sein, Daten wie Fahrerdaten, zu speichern, die während des Betriebs des Host-Fahrzeugs 100 oder anderer Fahrzeuge, die von dem Besitzer des Remote-Geräts 105 gefahren werden, gesammelt werden. Das Speichergerät 110 kann dazu programmiert sein, die Fahrerdaten, das Fahrerverhalten, die Betriebsparameter oder beliebige andere Informationen zu speichern. Darüber hinaus können die Daten, die in dem Speichergerät 110 gespeichert sind, für den Prozessor 115 zugänglich sein und können über die Kommunikationsschnittstelle 125 an das Host-Fahrzeug 100 kommuniziert werden.
Der Prozessor 115 kann dazu programmiert sein, Fahrerdaten in Echtzeit von dem Fahrzeugsteuersystem 120 über die Kommunikationsschnittstelle 125 zu empfangen. In einem möglichen Ansatz kann der Prozessor 115 die Fahrerdaten verarbeiten. Der Prozessor 115 kann weiterhin dazu programmiert sein, die Fahrerdaten mit einem oder mehreren Betriebsparametern zu assoziieren. Wie oben erörtert, können Betriebsparameter die Getriebeschaltlogik definieren, was bewirkt, dass das Host-Fahrzeug 100 in einem „Sport“-Modus, einem „Kraftstoffeffizienz“-Modus oder dergleichen arbeitet. Andere Betriebsparameter können sich auf einen autonomen Fahrzeugbetrieb beziehen, z. B. wie nah das Host-Fahrzeug 100 einem „vorderen Fahrzeug“ folgt. In einigen möglichen Ansätzen können die Betriebsparameter sich auf Insassenpräferenzen beziehen, wie Radiosendervoreinstellungen, Klimaanlageneinstellungen, Navigationspräferenzen, Infotainment-Anzeigepräferenzen, Innenraumbeleuchtungsfarbpräferenz usw.
In einigen Fällen können die Fahrergewohnheiten in Echtzeit von einem ersten Fahrzeug gesammelt werden. Das heißt, die Fahrerdaten können von dem ersten Fahrzeug an den Prozessor 115 mittels der Kommunikationsschnittstelle 125 übertragen werden. Wenn der Fahrer aus dem ersten Fahrzeug aussteigt und das Remote-Gerät 105 in ein anderes Fahrzeug (das als ein „zweites Fahrzeug“ bezeichnet wird) mitnimmt, kann der Prozessor 115 ein Befehlssignal erzeugen und unter Verwendung der Kommunikationsschnittstelle 125 an das zweite Fahrzeug ausgeben. Alternativ dazu, wenn das Remote-Gerät 105 einen Remote-Server beinhaltet, kann der Fahrer eine Benutzereingabe bereitstellen, die das Fahrzeugsteuersystem 120 des zweiten Fahrzeugs anweist, auf die Fahrerdaten von dem Remote-Server zuzugreifen. Als Reaktion darauf kann der Remote-Server das Befehlssignal übertragen. Obgleich es von dem Remote-Gerät 105, das sich in dem zweiten Fahrzeug befindet, oder von dem Remote-Server empfangen wurde, kann das Befehlssignal bewirken, dass das Fahrzeugsteuersystem 120 des zweiten Fahrzeugs Betriebsparameter gemäß den Fahrerdaten, die in dem Speichergerät 110 gespeichert sind, aktualisiert.
In einigen Fällen kann das Remote-Gerät 105 dazu programmiert sein, das Steuersignal an das zweite Fahrzeug als Reaktion auf eine Abfrage zu übertragen. Das Fahrzeugsteuersystem 120 des zweiten Fahrzeugs kann beispielsweise bei Paarung mit dem Remote-Gerät 105 eine Abfrage an den Prozessor 115 übertragen. Die Abfrage kann anfordern, dass der Prozessor 115 einen oder mehrere Betriebsparameter, die in dem Speichergerät 110 gespeichert sind, sendet. Der Prozessor 115 kann das Steuersignal als Reaktion auf die Abfrage erzeugen und übertragen.
3 stellt Blockdiagramme eines anderen beispielhaften Remote-Geräts 105 in Kommunikation mit einem Fahrzeug dar. In 3 ist der Prozessor 115 anstelle des Remote-Geräts 105 in das Host-Fahrzeug 100 eingebunden. In diesem beispielhaften Ansatz kann der Prozessor 115 dazu programmiert sein, das Remote-Gerät 105 nach den Fahrerdaten abzufragen. Das Remote-Gerät 105 kann die Fahrerdaten als Reaktion auf die Abfrage übertragen. Der Prozessor 115 kann dazu programmiert sein, nach Empfang der Fahrerdaten die Fahrerdaten zu verarbeiten und ein Befehlssignal zu erzeugen, das dem Fahrzeugsteuersystem 120 des Host-Fahrzeugs 100 befiehlt, mindestens einen Parameter gemäß den Fahrerdaten zu aktualisieren. Der Prozessor 115 kann die Fahrerdaten mittels der Kommunikationsschnittstelle 125 empfangen. Wie bei der in 2 gezeigten Kommunikationsschnittstelle 125 kann die Kommunikationsschnittstelle 125 von 3 dazu konfiguriert sein, die Kommunikation zwischen dem Host-Fahrzeug 100 und dem Remote-Gerät 105 unter Verwendung einer beliebigen Reihe von drahtgebundenen oder drahtlosen Kommunikationsprotokollen zu erleichtern.
4 ist ein Ablaufdiagramm eines beispielhaften Vorgangs 400, der auf dem Remote-Gerät 105 umgesetzt werden kann, um das Host-Fahrzeug 100 mit Parametern auszustatten.
In Block 405 kann das Remote-Gerät 105 Fahrerdaten in Echtzeit während des Betriebs eines ersten Fahrzeugs, eines zweiten Fahrzeugs oder eines beliebigen anderen Host-Fahrzeugs 100 empfangen. Das erste Fahrzeug kann die Fahrerdaten erfassen und die Fahrerdaten an das Remote-Gerät 105 mittels der Kommunikationsschnittstelle 125 übertragen. Die Fahrerdaten können sich auf die Präferenzen des Fahrers beziehen oder können auf dem Verhalten eines Fahrers basieren – das heißt, wie der Fahrer das erste Fahrzeug betreibt. Fahrerdaten können beispielsweise darauf basieren, z. B. wie aggressiv der Fahrer die Spuren wechselt, wie nah der Fahrer einem vorderen Fahrzeug folgt, wie aggressiv der Fahrer das Host-Fahrzeug 100 beschleunigt oder abbremst oder dergleichen. In einigen möglichen Umsetzungen können die Fahrerdaten von dem ersten Fahrzeug zu dem Remote-Gerät 105 drahtgebunden oder drahtlos kommuniziert werden.
In Block 410 kann das Remote-Gerät 105 die empfangenen Fahrerdaten in einem Speichergerät 110 speichern. Die Fahrerdaten können in einer Datenbank gespeichert werden, so dass sie von z. B. dem Remote-Gerät 105 abgerufen und an das Host-Fahrzeug 100 kommuniziert werden können.
In Block 415 kann das Remote-Gerät 105 die Fahrerdaten verarbeiten. Die Fahrerdaten können verarbeitet werden, so dass das Remote-Gerät 105 das Verhalten eines Fahrers, die Präferenzen zum Betreiben des Host-Fahrzeugs 100 und die bevorzugten Betriebsparameter des Fahrers usw. bestimmen kann. Das Verhalten, die Präferenzen und die bevorzugten Betriebsparameter des Fahrers können in dem Speichergerät 110 gespeichert und für andere Komponenten des Remote-Geräts 105, des Host-Fahrzeugs 100 oder beide zugänglich gemacht werden.
In Block 420 kann das Remote-Gerät 105 ein Befehlssignal erzeugen und das Befehlssignal an ein zweites Fahrzeug mittels der Kommunikationsschnittstelle 125 ausgeben. Das Befehlssignal kann dem zweiten Fahrzeug befehlen, mindestens einen Parameter gemäß der Fahrerdaten zu aktualisieren, die von vorherigen Host-Fahrzeugen 100 sowie von dem zweiten Fahrzeug gesammelt wurden. In einigen möglichen Ansätzen kann das Befehlssignal drahtlos an das zweite Fahrzeug entweder automatisch von dem Remote-Gerät 105 oder als Reaktion auf eine Abfrage von dem zweiten Fahrzeug übertragen werden. Das Remote-Gerät 105 kann beispielsweise das Befehlssignal bei Paarung mit der Kommunikationsschnittstelle 125 des zweiten Fahrzeugs automatisch übertragen. Alternativ dazu kann das zweite Fahrzeug das Remote-Gerät 105 nach den Fahrerdaten abfragen und das Remote-Gerät 105 kann die Abfrage empfangen, das Befehlssignal erzeugen und das Befehlssignal mit den Fahrerdaten als Reaktion auf die Abfrage übertragen.
Der Vorgang 400 kann mit Block 405 nach Block 420 fortfahren. Der Vorgang 400 kann weiter ausgeführt werden, bis das zweite Fahrzeug abgeschaltet wird oder bis das Remote-Gerät 105 nicht mehr mit dem zweiten Fahrzeug kommuniziert.
5 ist ein Ablaufdiagramm eines beispielhaften Vorgangs 500, der auf dem Host-Fahrzeug 100 umgesetzt werden kann, um Parameter von einem gepaarten Remote-Gerät 105 zu empfangen. Der Vorgang 500 kann ausgeführt werden, so lange das Host-Fahrzeug 100 und das Remote-Gerät 105 durch z. B. die Kommunikationsschnittstelle 125 gepaart sind.
In Block 505 kann das Host-Fahrzeug 100 das Remote-Gerät 105 nach Fahrerdaten abfragen. Die Fahrerdaten, wie oben erörtert, können von dem Remote-Gerät 105 in Echtzeit gesammelt worden sein, als der Besitzer das Host-Fahrzeug 100 oder andere Fahrzeuge fuhr. Die Abfrage kann eine Anforderung von dem Host-Fahrzeug 100 beinhalten, um Fahrerdaten bereitzustellen, die in dem Speichergerät 110 des Remote-Geräts 105 gespeichert sind.
In Block 510 kann das Host-Fahrzeug 100 die Fahrerdaten empfangen und verarbeiten. Die Fahrerdaten können mittels der Kommunikationsschnittstelle 125 empfangen werden. Wie oben erörtert, kann die Kommunikationsschnittstelle 125 dazu konfiguriert sein, die Fahrerdaten drahtlos von dem Remote-Gerät 105 zu empfangen. Die Fahrerdaten können verarbeitet werden, so dass das Host-Fahrzeug 100 das Verhalten eines Fahrers, die Präferenzen zum Betreiben des Host-Fahrzeugs 100 und die bevorzugten Betriebsparameter des Fahrers usw. bestimmen kann. Das Verhalten, die Präferenzen und die bevorzugten Betriebsparameter des Fahrers können vorübergehend in einem Speichergerät 130 des Host-Fahrzeugs 100 gespeichert und für andere Komponenten des Remote-Geräts 105, des Host-Fahrzeugs 100 oder beide zugänglich gemacht werden.
In Block 515 kann das Host-Fahrzeug 100 ein Befehlssignal erzeugen, das einem System, das mit einem zweiten Fahrzeug assoziiert ist, befiehlt, mindestens einen Parameter gemäß den Fahrerdaten zu aktualisieren, die in Block 505 empfangen und in Block 510 verarbeitet wurden.
In Block 520 kann das Host-Fahrzeug 100 zusätzliche Fahrerdaten erzeugen und die zusätzlichen Fahrerdaten in Echtzeit an das Remote-Gerät 105 senden. Darüber hinaus kann das Host-Fahrzeug 100 damit fortfahren, die Systemparameter gemäß etwaigen neuen Fahrerdaten zu aktualisieren, die erzeugt werden, während der Fahrer das Host-Fahrzeug 100 betreibt.
In Block 525 kann das Host-Fahrzeug 100 bestimmen, ob der Besitzer des Remote-Geräts 105 das Host-Fahrzeug 100 verlassen hat. Die Bestimmung kann darauf basieren, ob ein Motor des Host-Fahrzeugs 100 abgeschaltet wurde oder ob das Host-Fahrzeug 100 nicht mehr in Kommunikation mit dem Remote-Gerät 105 ist. Wenn das Host-Fahrzeug 100 bestimmt, dass der Besitzer des Remote-Geräts 105 ausgestiegen ist, kann der Vorgang 500 mit Block 530 fortfahren. Andernfalls kann der Vorgang 500 zu Block 520 zurückkehren.
In Block 530 kann das Host-Fahrzeug 100 Fahrerdaten von dem Speichergerät 130 des Host-Fahrzeugs 100 verwerfen. So speichert das Host-Fahrzeug 100 keine Informationen zu einem bestimmten Fahrer, außer wenn das Remote-Gerät 105, das mit dem Fahrer assoziiert ist, sich in dem Host-Fahrzeug 100 befindet. Da die Fahrerdaten verworfen werden, wird das Host-Fahrzeug 100 des Weiteren die Fahrerdaten einer Person nicht verwenden, wenn eine andere Person das Host-Fahrzeug 100 betreibt.
Der Vorgang 500 kann nach Block 530 enden.
Im Allgemeinen können die beschriebenen Datenverarbeitungssysteme und/oder -vorrichtungen ein beliebiges einer Reihe von Computerbetriebssystemen einsetzen, einschließlich, jedoch in keinerlei Weise darauf beschränkt, Versionen und/oder Varianten des Ford Sync^®-Betriebssystems, des Microsoft Windows^®-Betriebssystems, des Unix-Betriebssystems (z. B. des Solaris^®-Betriebssystems, das von der Oracle Corporation in Redwood Shores, Kalifornien, USA, vertrieben wird), des AIX-UNIX-Betriebssystems, das von International Business Machines in Armonk, New York, USA, vertrieben wird, des Linux-Betriebssystems, der Betriebssysteme MAC OSX und iOS, die von der Apple Inc. in Cupertino, Kalifornien, USA, vertrieben werden, des Blackberry OS, das von Blackberry, Ltd. in Waterloo, Kanada, vertrieben wird, und des Android-Betriebssystems, das von Google, Inc. und der Open Handset Alliance entwickelt wurde. Zu Beispielen von Datenverarbeitungsvorrichtungen zählen, ohne Einschränkung, ein Fahrzeugbordcomputer, ein Arbeitsplatzrechner, ein Server, ein Desktop-Computer, ein Notebook, ein Laptop oder ein tragbarer Computer oder ein beliebiges anderes Datenverarbeitungssystem und/oder eine beliebige andere Datenverarbeitungsvorrichtung.
Datenverarbeitungsvorrichtungen beinhalten im Allgemeinen computerausführbare Anweisungen, wobei die Anweisungen durch eine oder mehrere Datenverarbeitungsvorrichtungen ausführbar sind, wie den oben aufgeführten. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung einer Vielfalt von Programmiersprachen und/oder -technologien erstellt wurden, einschließlich, ohne Einschränkung, und entweder allein oder in Kombination, Java^TM, C, C++, Visual Basic, Java Script, Perl usw. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen z. B. von einem Speicher, einem computerlesbaren Medium usw. und führt diese Anweisungen aus, wodurch ein oder mehrere Vorgänge, einschließlich eines oder mehrerer der hierin beschriebenen Vorgänge, durchgeführt werden. Derartige Anweisungen und andere Daten können unter Verwendung einer Vielfalt von computerlesbaren Medien gespeichert und übertragen werden.
Ein computerlesbares Medium (das auch als ein prozessorlesbares Medium bezeichnet wird) beinhaltet ein beliebiges nicht vergängliches (z. B. greifbares) Medium, das am Bereitstellen von Daten (z. B. Anweisungen) beteiligt ist, die von einem Computer (z. B. von einem Prozessor eines Computers) gelesen werden können. Ein derartiges Medium kann viele Formen annehmen, einschließlich, jedoch nicht darauf beschränkt, nichtflüchtiger und flüchtiger Medien. Zu nichtflüchtigen Medien können beispielsweise optische oder Magnetplatten und ein anderer permanenter Speicher zählen. Zu flüchtigen Medien kann beispielsweise ein dynamischer Direktzugriffsspeicher (dynamic random access memory, DRAM) zählen, der in der Regel einen Hauptspeicher bildet. Derartige Anweisungen können von einem oder mehreren Übertragungsmedien übertragen werden, einschließlich Koaxialkabeln, Kupferdraht und Glasfasern, einschließlich der Drähte, die einen Systembus umfassen, der mit einem Prozessor eines Computers gekoppelt ist. Zu üblichen Formen von computerlesbaren Datenträgern zählen beispielsweise eine Floppy-Disk, eine Diskette, eine Festplatte, ein Magnetband, ein beliebiger anderer magnetischer Datenträger, eine CD-ROM, eine DVD, ein beliebiger anderer optischer Datenträger, Lochkarten, Papierband, ein beliebiger anderer physischer Datenträger mit Lochmustern, ein RAM, ein PROM, ein EPROM, ein FLASH-EEPROM, ein beliebiger anderer Speicherchip oder eine beliebige andere Speicherpatrone oder ein beliebiger anderer Datenträger, von dem ein Computer lesen kann.
Zu Datenbanken, Datenbehältern oder anderen Datenspeichern, die hierin beschrieben sind, können verschiedene Arten von Mechanismen zum Speichern und Abrufen verschiedener Arten von Daten sowie Zugreifen auf diese zählen, einschließlich einer hierarchischen Datenbank, eines Satzes von Dateien in einem Dateisystem, einer Anwendungsdatenbank in einem gesetzlich geschützten Format, eines relationalen Datenbankverwaltungssystems (relational database management system, RDBMS) usw. Jeder derartige Datenspeicher ist allgemein in einer Datenverarbeitungsvorrichtung enthalten, die ein Computerbetriebssystem einsetzt, wie eines der oben erwähnten, und auf ihn wird mittels eines Netzes auf eine beliebige oder beliebige mehrere einer Vielfalt von Methoden zugegriffen. Auf ein Dateisystem kann durch ein Computerbetriebssystem zugegriffen werden und es kann Dateien enthalten, die in verschiedenen Formaten gespeichert sind. Eine RDBMS setzt allgemein neben einer Sprache zum Erstellen, Speichern, Bearbeiten und Ausführen gespeicherter Vorgänge, wie die oben erwähnte PL/SQL-Sprache, die Structured Query Language (SQL) ein.
In einigen Beispielen können Systemelemente als computerlesbare Anweisungen (z. B. Software) auf einer oder mehreren Datenverarbeitungsvorrichtungen (z. B. Servern, Personalcomputern usw.) umgesetzt werden, die auf damit assoziierten computerlesbaren Medien (z. B. Platten, Speichern usw.) gespeichert sind. Ein Computerprogrammprodukt kann derartige Anweisungen, die auf computerlesbaren Medien gespeichert sind, zum Ausführen der hierin beschriebenen Funktionen umfassen.
In Bezug auf die hierin beschriebenen Vorgänge, Systeme, Verfahren, Heuristik usw. versteht es sich, dass, obwohl die Schritte derartiger Vorgänge usw. als gemäß einer bestimmten geordneten Abfolge erfolgend beschrieben wurden, derartige Vorgänge mit den beschriebenen Schritten ausgeübt werden könnten, die in einer Reihenfolge durchgeführt werden, die sich von der hierin beschriebenen Reihenfolge unterscheidet. Es versteht sich weiterhin, dass bestimmte Schritte gleichzeitig durchgeführt werden könnten, dass andere Schritte hinzugefügt werden könnten oder dass bestimmte hierin beschriebene Schritte weggelassen werden könnten. Anders ausgedrückt, die Beschreibungen von Vorgängen hierin sind zum Zwecke der Veranschaulichung bestimmter Ausführungsformen bereitgestellt und sollten keinesfalls als die Ansprüche einschränkend aufgefasst werden.
Dementsprechend versteht es sich, dass die obige Beschreibung veranschaulichend und nicht einschränkend sein soll. Viele Ausführungsformen und Anwendungen, die sich von den bereitgestellten Beispielen unterscheiden, würden beim Lesen der obigen Beschreibung offensichtlich werden. Der Schutzumfang sollte nicht unter Bezugnahme auf die obige Beschreibung bestimmt werden, sondern sollte stattdessen unter Bezugnahme auf die angefügten Ansprüche bestimmt werden, zusammen mit dem vollen Umfang von Äquivalenten, auf die derartige Ansprüche Anspruch haben. Es ist antizipiert und beabsichtigt, dass künftige Entwicklungen in den hierin erörterten Technologien erfolgen werden und dass die offenbarten Systeme und Verfahren in derartige künftige Ausführungsformen eingebunden werden. Zusammenfassend versteht es sich, dass die Anmeldung zur Modifizierung und Abänderung geeignet ist.
Alle in den Ansprüchen verwendeten Begriffe sind so beabsichtigt, dass ihnen ihre gewöhnlichen Bedeutungen verliehen sind, wie sie von den Fachmännern für die hierin beschriebenen Technologien verstanden werden, sofern kein ausdrücklicher Hinweis auf das Gegenteil hierin gemacht wird. Insbesondere sollte die Verwendung der Artikel in der Einzahl, wie „ein/eine“, „der/die/das“ usw. so gelesen werden, dass ein oder mehrere der angegebenen Elemente vorgetragen werden, sofern nicht ein Anspruch eine gegenteilige ausdrückliche Einschränkung vorträgt.
Die Zusammenfassung wird bereitgestellt, um dem Leser zu ermöglichen, die Art der technischen Offenbarung schnell zu ermitteln. Sie wird unter der Voraussetzung vorgelegt, dass sie nicht dazu verwendet wird, den Schutzumfang oder die Bedeutung der Ansprüche zu deuten oder einzuschränken. Darüber hinaus ist in der vorstehenden ausführlichen Beschreibung zu erkennen, dass verschiedene Merkmale in verschiedenen Ausführungsformen zum Zwecke der Rationalisierung der Offenbarung zusammengruppiert sind. Diese Offenbarungsmethode ist nicht als eine Absicht widerspiegelnd zu deuten, dass die beanspruchten Ausführungsformen mehr Merkmale erfordern, als in jedem Anspruch ausdrücklich vorgetragen sind. Wie die folgenden Ansprüche widerspiegeln, liegt der erfinderische Gegenstand vielmehr in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform. Die folgenden Ansprüche sind folglich hierdurch in die ausführliche Beschreibung eingebunden, wobei jeder Anspruch als ein separat beanspruchter Gegenstand für sich allein steht.

Claims

Fahrzeugsystem, das Folgendes umfasst: ein Remote-Gerät mit einem Prozessor, der dazu programmiert ist, Fahrerdaten in Echtzeit während des Betriebs eines ersten Fahrzeugs zu empfangen, die Fahrerdaten zu verarbeiten und ein Befehlssignal zu erzeugen, das einem System, das mit einem zweiten Fahrzeug assoziiert ist, befiehlt, mindestens einen Parameter gemäß den Fahrerdaten zu aktualisieren.
Fahrzeugsystem nach Anspruch 1, wobei das Remote-Gerät weiterhin eine Kommunikationsschnittstelle beinhaltet, die dazu konfiguriert ist, Fahrerdaten von dem ersten Fahrzeug zu empfangen und das Befehlssignal an das zweite Fahrzeug zu übertragen.
Fahrzeugsystem nach Anspruch 2, wobei die Kommunikationsschnittstelle dazu konfiguriert ist, die Fahrerdaten drahtlos zu empfangen und das Befehlssignal drahtlos an das zweite Fahrzeug zu übertragen.
Fahrzeugsystem nach Anspruch 2, wobei die Kommunikationsschnittstelle dazu konfiguriert ist, Fahrerdaten von dem ersten Fahrzeug drahtlos zu empfangen und die Fahrerdaten an den Prozessor zu übertragen.
Fahrzeugsystem nach Anspruch 1, wobei das Remote-Gerät ein Mobilfunkgerät beinhaltet, das dazu programmiert ist, die Fahrerdaten zu speichern.
Fahrzeugsystem nach Anspruch 1, wobei das Remote-Gerät einen Remote-Server beinhaltet, der dazu programmiert ist, die Fahrerdaten zu speichern.
Fahrzeugsystem nach Anspruch 1, wobei der Prozessor dazu programmiert ist, eine Abfrage von dem zweiten Fahrzeug nach dem Parameter zu empfangen, und wobei der Prozessor dazu programmiert ist, das Befehlssignal als Reaktion auf die Abfrage zu erzeugen.
Fahrzeugsystem, das Folgendes umfasst: einen Prozessor, der dazu programmiert ist, ein Remote-Gerät nach Fahrerdaten abzufragen, die von einem ersten Fahrzeug gesammelt wurden, die Fahrerdaten zu verarbeiten und ein Befehlssignal zu erzeugen, das einem System, das mit einem zweiten Fahrzeug assoziiert ist, befiehlt, mindestens einen Parameter gemäß den Fahrerdaten zu aktualisieren.
Fahrzeugsystem nach Anspruch 8, das weiterhin eine Kommunikationsschnittstelle umfasst, die dazu konfiguriert ist, das Befehlssignal von dem Remote-Gerät zu empfangen.
Fahrzeugsystem nach Anspruch 9, wobei die Kommunikationsschnittstelle dazu konfiguriert ist, die Fahrerdaten drahtlos von dem Remote-Gerät zu empfangen.
Fahrzeugsystem nach Anspruch 8, wobei das Remote-Gerät ein Mobilfunkgerät beinhaltet, das dazu programmiert ist, die Fahrerdaten zu speichern.
Fahrzeugsystem nach Anspruch 8, wobei das Remote-Gerät einen Remote-Server beinhaltet, der dazu programmiert ist, die Fahrerdaten zu speichern.
Fahrzeugsystem nach Anspruch 8, wobei das Remote-Gerät dazu programmiert ist, die Fahrerdaten als Reaktion auf die Abfrage an den Prozessor zu übertragen.
Verfahren, das Folgendes umfasst: Empfangen von Fahrerdaten in Echtzeit während des Betriebs eines ersten Fahrzeugs; Verarbeiten der Fahrerdaten und Erzeugen eines Befehlssignals, das einem zweiten Fahrzeug befiehlt, mindestens einen Parameter gemäß den Fahrerdaten zu aktualisieren.
Verfahren nach Anspruch 14, wobei die Fahrerdaten drahtlos von dem ersten Fahrzeug empfangen werden.
Verfahren nach Anspruch 14, wobei das Befehlssignal drahtlos an das zweite Fahrzeug übertragen wird.
Verfahren nach Anspruch 14, das weiterhin das Speichern der Fahrerdaten in einem Speichergerät, das von dem ersten Fahrzeug und dem zweiten Fahrzeug entfernt ist, umfasst.
Verfahren nach Anspruch 14, das weiterhin das Empfangen einer Abfrage von dem zweiten Fahrzeug nach den Fahrerdaten umfasst.
Verfahren nach Anspruch 18, das weiterhin das Erzeugen des Befehlssignals als Reaktion auf die Abfrage umfasst.
Verfahren nach Anspruch 14, das weiterhin Folgendes umfasst: Bestimmen, ob ein Fahrer das zweite Fahrzeug verlassen hat; und Verwerfen von Fahrerdaten von einem Speichergerät, das mit dem zweiten Fahrzeug assoziiert ist.