DE102013218179A1

DE102013218179A1 - Verfahren und Vorrichtung für Remote-Treibstoffnachfüllstandüberwachung

Info

Publication number: DE102013218179A1
Application number: DE102013218179.5A
Authority: DE
Inventors: Greg P. Brown; Brian Thomas Aitken; Phillip Pierron
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2012-09-14
Filing date: 2013-09-11
Publication date: 2014-03-20
Also published as: US9783140B2; CN103661164B; US20140077936A1; CN103661164A

Abstract

Ein System beinhaltet einen Prozessor, der konfiguriert ist, um Anforderungen von einer drahtlosen Einrichtung in drahtloser Kommunikation mit dem Prozessor zu empfangen, wobei die Anforderungen einem oder mehreren Aspekten eines Betankprozesses entsprechen. Der Prozessor ist auch konfiguriert, um dem einem oder den mehreren Aspekten des Betankprozesses entsprechende Fahrzeugdaten zu erfassen und auf die Anforderungen durch Senden der Daten bezüglich des einen oder der mehreren Aspekte des Betankprozesses zu reagieren.

Description

Die Ausführungsbeispiele betreffen allgemein Verfahren und Vorrichtungen für Remote-Treibstoffnachfüllstandüberwachung.
Unabhängig davon, ob ein Kraftfahrzeug mit Elektrizität oder Benzin betrieben wird, halten die Eigentümer regelmäßig an Betankungsstellen an, um das Fahrzeug zu betanken/wieder mit Treibstoff zu füllen (Treibstoff/betanken, wie hierin verwendet, bezieht sich auf sowohl elektrischen Strom als auch Benzin sowie jegliche anderen zum Antreiben eines Fahrzeugs verwendbaren Treibstoffe). Elektrofahrzeuge benötigen zum Beispiel eine bestimmte Anzahl von Minuten, um voll aufgeladen zu werden, und der Eigentümer möchte möglicherweise während der Aufladung nicht direkt neben dem Fahrzeug stehen, um Treibstoffstände zu überwachen.
Die US-Anmeldung 2011/0057612 betrifft allgemein ein Kommunikationsteil einer Batterieladezustand-Übertragungseinrichtung einer Ladeeinrichtung, die Ladezustandsinformationen jedes extern aufzuladenden Fahrzeugs aufnimmt. Ein Stationskommunikationsteil überträgt die Ladezustandsinformationen an eine Informationsverwaltungsstationseinrichtung. Die Ladezustandsinformationen werden für die Übertragung gruppiert, sodass die Anzahl von Übertragungen, der Umfang des Kommunikationsverkehrs und die Kosten für die Kommunikation mit der Verwaltungsstationseinrichtung sowie die Betriebslast der Verwaltungsstationseinrichtung reduziert werden.
Das US-Patent 6,630,813 betrifft allgemein ein System für ein Automobil, das einen Temperatursensor, der ein Temperatursignal erzeugt, das die Temperatur außerhalb des Fahrzeugs angibt, und eine Batterie aufweist. An den Temperatursensor und die Batterie ist ein Batteriewächter gekoppelt. Der Wächter überwacht einen Ladezustand der Batterie, überwacht eine Temperatur außerhalb des Fahrzeugs und vergleicht den Ladezustand mit einem vorher bestimmten Ladezustand. Der vorher bestimmte Ladezustand ist eine Funktion der Temperatur. Der Wächter erzeugt einen Indikator, wenn der Ladezustand den vorher bestimmten Ladezustand erreicht.
In einem ersten Ausführungsbeispiel beinhaltet ein System einen Prozessor, der konfiguriert ist, um Anforderungen von einer drahtlosen Einrichtung in drahtloser Kommunikation mit dem Prozessor zu empfangen, wobei die Anforderungen einem oder mehreren Aspekten eines Betankprozesses entsprechen. Der Prozessor ist auch konfiguriert, um dem einem oder den mehreren Aspekten des Betankprozesses entsprechende Fahrzeugdaten zu erfassen und auf die Anforderungen durch Senden der Daten bezüglich des einen oder der mehreren Aspekte des Betankprozesses zu reagieren.
In einem zweiten Ausführungsbeispiel speichert ein nicht transientes computerlesbares Speichermedium Anweisungen, die, wenn sie von einem Prozessor ausgeführt werden, bewirken, dass der Prozessor das Verfahren durchführt, das Empfangen von Anforderungen von einer drahtlosen Einrichtung in drahtloser Kommunikation mit dem Prozessor beinhaltet, wobei die Anforderungen einem oder mehreren Aspekten eines Betankprozesses entsprechen. Das beispielhafte Verfahren beinhaltet auch Erfassen von dem einem oder den mehreren Aspekten des Betankprozesses entsprechenden Fahrzeugdaten. Weiter beinhaltet das beispielhafte Verfahren Reagieren auf die Anforderungen durch Senden der Daten bezüglich des einen oder der mehreren Aspekte des Betankprozesses.
In einem dritten Ausführungsbeispiel beinhaltet ein computerimplementiertes Verfahren Empfangen von Anforderungen von einer drahtlosen Einrichtung in drahtloser Kommunikation mit einem Prozessor eines Fahrzeugcomputersystems (Vehicle Computing System, VCS), wobei die Anforderungen einem oder mehreren Aspekten eines Betankprozesses entsprechen. Das beispielhafte Verfahren beinhaltet auch Erfassen von dem einem oder den mehreren Aspekten des Betankprozesses entsprechenden Fahrzeugdaten. Weiter beinhaltet das Verfahren Reagieren auf die Anforderungen durch Senden der Daten bezüglich des einen oder der mehreren Aspekte des Betankprozesses.
1 zeigt ein veranschaulichendes Beispiel für ein Fahrzeugcomputersystem;
2 zeigt ein veranschaulichendes Beispiel für ein Treibstoffstandmeldesystem;
3 zeigt ein veranschaulichendes Beispiel für ein Treibstoffstandmelde- und -steuersystem;
4 zeigt ein zweites veranschaulichendes Beispiel für ein Treibstoffstandmelde- und -steuersystem; und
die 5A und 5B zeigen veranschaulichende Beispiele für eine Treibstoffstandmeldeapplikationsausgabe.
Wie erforderlich, werden hierin ausführliche Ausführungsformen der vorliegenden Erfindung offenbart; jedoch sollte es sich verstehen, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Ausbildungen ausgeführt werden kann. Die Figuren sind nicht zwingend maßstabsgetreu; einige Features sind möglicherweise übertrieben oder minimiert, um Einzelheiten konkreter Komponenten zu zeigen. Deshalb sind spezielle Struktur- und Funktionseinzelheiten, die hierin offenbart werden, nicht als einschränkend auszulegen, sondern lediglich als Darstellungsgrundlage, um dem Fachmann zu lehren, wie die vorliegende Erfindung unterschiedlich eingesetzt werden kann.
1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Computersystem 1 (Vehicle Based Computing System, VCS) für ein Fahrzeug 31. Ein Beispiel für ein solches fahrzeugbasiertes Computersystem 1 ist das von THE FORD MOTOR COMPANY gefertigte SYNC-System. Ein Fahrzeug, in dem ein fahrzeugbasiertes Computersystem aktiviert ist, enthält möglicherweise eine im Fahrzeug befindliche grafische Front-End-Benutzeroberfläche 4. Der Benutzer kann möglicherweise auch mit der Benutzeroberfläche interagieren, falls sie zum Beispiel mit einem berührungsempfindlichen Bildschirm versehen ist. In einem anderen Ausführungsbeispiel erfolgt die Interaktion durch Drücken von Schaltflächen, ein System für gesprochene Dialoge mit automatischer Spracherkennung und Sprachsynthese.
In dem in 1 gezeigten Ausführungsbeispiel steuert ein Prozessor 3 mindestens teilweise den Betrieb des fahrzeugbasierten Computersystems. Der Prozessor, der innerhalb des Fahrzeugs bereitgestellt ist, ermöglicht eine bordseitige Verarbeitung von Befehlen und Routinen. Weiter ist der Prozessor sowohl mit einem nicht beständigen 5 als auch einem beständigen Speicher 7 verbunden. In diesem Ausführungsbeispiel ist der nicht beständige Speicher ein Random Access Memory (RAM) und der beständige Speicher ein Festplattenlaufwerk (HDD) oder ein Flash-Speicher.
Der Prozessor ist auch mit einer Anzahl unterschiedlicher Eingänge versehen, die eine Verbindung des Benutzers zum Prozessor über eine Schnittstelle ermöglichen. In diesem Ausführungsbeispiel sind ein Mikrofon 29, ein Hilfseingang 25 (für den Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24 und ein BLUETOOTH-Eingang 15 alle bereitgestellt. Ein Eingangswähler 51 ist ebenfalls bereitgestellt, um zu ermöglichen, dass ein Benutzer zwischen verschiedenen Eingängen wechselt. Der Eingang sowohl zum Mikrofon als auch zum Hilfsanschluss wird vor der Weiterleitung an den Prozessor von einem Umsetzer 27 von analog in digital umgesetzt. Wenngleich dies nicht gezeigt wird, verwenden zahlreiche der Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS kommunizieren, möglicherweise ein Fahrzeugnetz (wie unter anderem einen CAN-Bus), um Daten zu und von dem VCS (oder Komponenten davon) weiterzuleiten.
Ausgänge des Systems können unter anderem eine Sichtanzeige 4 und einen Lautsprecher 13 oder eine Stereosystemausgabe beinhalten. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal vom Prozessor 3 durch einen Digital-Analog-Umsetzer 9. Der Ausgang kann auch zu einer Remote-BLUETOOTH-Einrichtung wie einem PND 54 oder einer USB-Einrichtung wie einem Fahrzeugnavigationsgerät 60 entlang den bidirektionalen Datenströmen mit den Bezugszeichen 19 bzw. 21 gebildet werden.
In einem Ausführungsbeispiel verwendet das System 1 den BLUETOOTH-Transceiver 15, um mit dem Nomadic Device 53 eines Benutzers (z. B. Handy, Smartphone, PDA oder einer beliebigen anderen Einrichtung mit Drahtlos-Remote-Netzkonnektivität) zu kommunizieren 17. Das Nomadic Device kann dann verwendet werden, um mit einem Netz 61 außerhalb des Fahrzeugs 31 zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen ist der Mast 57 möglicherweise ein WiFi-Zugangspunkt.
Eine beispielhafte Kommunikation zwischen dem Nomadic Device und dem BLUETOOTH-Transceiver wird vom Signal 14 dargestellt.
Zum Paaren eines Nomadic Device 53 und des BLUETOOTH-Transceivers 15 kann durch eine Schaltfläche 52 oder eine ähnliche Eingabe angewiesen werden. Folglich wird die CPU angewiesen, dass der bordseitige BLUETOOTH-Transceiver mit einem BLUETOOTH-Transceiver in einem Nomadic Device gepaart wird.
Daten können zum Beispiel unter Nutzung eines Datentarifs, von Data over Voice oder von DTMF-Tönen assoziiert mit einem Nomadic Device 53 zwischen der CPU 3 und dem Netz 61 kommuniziert werden. Alternativ ist es eventuell wünschenswert, ein bordseitiges Modem 63 mit einer Antenne 18 zu integrieren, um Daten zwischen der CPU 3 und dem Netz 61 über das Sprachband zu kommunizieren 16. Das Nomadic Device 53 kann dann genutzt werden, um mit einem Netz 61 außerhalb des Fahrzeugs 31 zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann das Modem 63 eine Kommunikation 20 mit dem Mast 57 zum Kommunizieren mit dem Netz 61 aufbauen. Ein nicht einschränkendes Beispiel besteht darin, dass das Modem 63 möglicherweise ein USB-Mobilfunkmodem und die Kommunikation 20 möglicherweise eine Mobilfunkkommunikation ist.
In einem Ausführungsbeispiel ist der Prozessor mit einem Betriebssystem versehen, das eine API beinhaltet, um mit einer Modemapplikationssoftware zu kommunizieren. Die Modemapplikationssoftware greift möglicherweise auf ein eingebettetes Modul oder eine eingebettete Firmware im BLUETOOTH-Transceiver zu, um drahtlose Kommunikation mit einem Remote-BLUETOOTH-Transceiver (wie demjenigen in einem Nomadic Device) durchzuführen. Bluetooth ist eine Untermenge der Protokolle für IEEE 802 PANS (Personal Area Networks). Protokolle für IEEE 802 LANS (Local Area Networks) beinhalten WiFi und weisen eine sich erheblich mit IEEE 802 PANS deckende Funktionalität auf. Beide sind für drahtlose Kommunikation innerhalb eines Fahrzeugs geeignet. Ein anderes Kommunikationsmittel, das in diesem Bereich verwendet werden kann, sind optische Freiraumnachrichtenübertragung (wie IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
In einer anderen Ausführungsform beinhaltet ein Nomadic Device 53 ein Modem für Sprachband- oder Breitbanddatenkommunikation. In der Data-over-Voice-Ausführungsform kann eine als Frequenzmultiplexverfahren bekannte Technik implementiert werden, wenn der Eigentümer des Nomadic Device über die Einrichtung sprechen kann, während Daten transferiert werden. Zu anderen Zeiten, wenn der Eigentümer die Einrichtung gerade nicht verwendet, kann beim Datentransfer die gesamte Bandbreite (in einem Beispiel 300 Hz bis 3,4 kHz) verwendet werden. Während das Frequenzmultiplexverfahren möglicherweise bei der analogen Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet üblich ist und nach wie vor verwendet wird, wurde es weitgehend abgelöst von Hybriden wie Code Domain Multiple Access (CDMA), Time Domain Multiple Access (TDMA), Space-Domain Multiple Access (SDMA) für digitale Mobilfunkkommunikation. Diese Standards sind alle mit ITU IMT-2000 (3G) kompatibel und bieten Datenraten von bis zu 2 Mbit/s für stationäre oder umhergehende Benutzer und 385 Kbit/s für Benutzer in einem sich fortbewegenden Fahrzeug. 3G-Standards werden derzeit abgelöst von IMT-Advanced (4G), der 100 Mbit/s für Benutzer in einem Fahrzeug und 1 Gbit/s für stationäre Benutzer bietet. Falls der Benutzer über einen mit dem Nomadic Device assoziierten Datentarif verfügt, ist möglich, dass der Datentarif Breitbandübertragung zulässt und das System eine viel größere Bandbreite verwenden könnte (was den Datentransfer beschleunigt). In noch einer anderen Ausführungsform ist das Nomadic Device 53 durch eine Mobilfunkkommunikationseinrichtung (nicht gezeigt) ersetzt, die am Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform ist das ND 53 möglicherweise eine Einrichtung für ein drahtloses Local Area Network (LAN), die zum Kommunizieren über zum Beispiel (unter anderem) ein 802.11g-Netz (d. h. WiFi) oder ein WiMax-Netz fähig ist.
In einer Ausführungsform können ankommende Daten durch das Nomadic Device über Data over Voice oder einen Datentarif, durch den bordseitigen BLUETOOTH-Transceiver und in den internen Prozessor 3 des Fahrzeugs weitergeleitet werden. Im Fall bestimmter temporärer Daten können die Daten zum Beispiel im HDD oder in einem anderen Speichermedium 7 so lange gespeichert werden, bis die Daten nicht mehr benötigt werden.
Weitere Quellen, die möglicherweise eine Schnittstelle zum Fahrzeug haben, beinhalten ein Personal Navigation Device 54 zum Beispiel mit einer USB-Verbindung 56 und/oder einer Antenne 58, ein Fahrzeugnavigationsgerät 60 mit einer USB- 62 oder einer anderen Verbindung, eine bordseitige GPS-Einrichtung 24 oder ein Remote-Navigationssystem (nicht gezeigt) mit Konnektivität zu einem Netz 61. USB gehört zu einer Gruppe von Protokollen für serielle Anschlüsse. IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), Serienprotokolle 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 zwischen Einrichtungen. Die meisten Protokolle können entweder für elektrische oder für optische Kommunikation implementiert werden.
Weiter könnte die CPU mit verschiedenen anderen Hilfseinrichtungen 65 kommunizieren. Diese Einrichtungen können über eine drahtlose 67 oder eine drahtgebundene 69 Verbindung verbunden sein. Die Hilfseinrichtung 65 beinhaltet möglicherweise unter anderem Personal Media Player, drahtlose medizinische Geräte, tragbare Computer und dergleichen.
Auch oder alternativ könnte die CPU, zum Beispiel unter Verwendung eines Transceivers für WiFi (IEEE 803.11) 71, mit einem fahrzeugbasierten Drahtlosrouter 73 verbunden sein. Dadurch könnte ermöglicht werden, dass die CPU mit Remote-Netzen in der Reichweite des lokalen Routers 73 verbunden wird.
Zusätzlich dazu, dass beispielhafte Prozesse von einem in einem Fahrzeug befindlichen Fahrzeugcomputersystem ausgeführt werden, werden die beispielhaften Prozesse in bestimmten Ausführungsformen möglicherweise von einem mit einem Fahrzeugcomputersystem kommunizierenden Computersystem ausgeführt. Ein solches System beinhaltet möglicherweise unter anderem eine drahtlose Einrichtung (z. B. unter anderem ein Mobiltelefon) oder ein Remote-Computersystem (z. B. unter anderem einen Server), das durch die drahtlose Einrichtung verbunden ist. Gemeinsam können solche Systeme als fahrzeugassoziierte Computersysteme (Vehicle Associated Computing Systems, VACS) bezeichnet werden. In bestimmten Ausführungsformen führen konkrete Komponenten der VACS möglicherweise konkrete Abschnitte eines Prozesses abhängig von der konkreten Implementierung des Systems durch. Beispielhaft und unter anderem, falls ein Prozess einen Schritt des Versendens oder des Empfangens von Informationen mit einer gepaarten drahtlosen Einrichtung aufweist, ist wahrscheinlich, dass die drahtlose Einrichtung den Prozess gerade nicht durchführt, da die drahtlose Einrichtung Informationen mit sich selbst nicht „senden und empfangen“ würde. Der Durchschnittsfachmann versteht, wann es unangemessen ist, ein konkretes VACS auf eine jeweilige Lösung anzuwenden. In allen Lösungen ist vorgesehen, dass mindestens das innerhalb des Fahrzeugs selbst befindliche Fahrzeugcomputersystem (Vehicle Computing System, VCS) zum Durchführen der beispielhaften Prozesse fähig ist.
Fahrzeugbediener, die Fahrzeuge betanken, möchten möglicherweise den aktuellen Treibstoffstand eines Fahrzeugs erfahren, ohne das Fahrzeug anschalten und/oder in der Armaturenbrett-Treibstoffmessanzeige nachsehen zu müssen. In einigen Fällen möchten Kunden, die sich „grün“ verhalten möchten, möglicherweise nach dem ersten „Klicken“ (d. h. der automatischen Zapfsäulenabschaltung) das Tanken beenden. Auch wenn daraus in der Regel ein voller oder fast voller Tank resultiert, gibt es Fälle, in denen die Abschaltung erfolgen kann, wenn der Tank zu weniger als 95% voll ist.
In Fällen wie oben beschrieben findet es ein Kunde eventuell mühselig, das Fahrzeug einzuschalten, auf dem Armaturenbrett nachzusehen, den Treibstoffstand zu beurteilen und dann zu entscheiden, ob er das Fahrzeug weiter betanken will oder nicht. Falls der Kunde die Zapfpistole außerdem bereits in den Halter zurückgesteckt hat, erfordert die Option des Weitertankens möglicherweise das erneute Durchziehen einer Kreditkarte, das erneute Eingeben einer PIN usw.
Die Ausführungsbeispiele schlagen einige Systeme und Verfahren vor, mit denen es leichter ist, einen aktuellen Treibstoffstand festzustellen. Falls sich ein Kunde zudem vom Fahrzeug entfernt aufhält, ermöglichen die Applikationen, dass der Betankprozess bis zu einem gewissen Grad gesteuert werden kann.
2 zeigt ein Ausführungsbeispiel für ein Treibstoffstandmeldesystem. In diesem Ausführungsbeispiel können die Meldungen von einem Fahrzeugcomputersystem (Vehicle Computing System, VCS) an eine vom Bediener mitgeführte drahtlose Einrichtung übermittelt werden. Diese Einrichtung kann unter anderem ein Mobiltelefon, einen PDA, ein Smartphone, einen Tablet-PC usw. beinhalten. Vom VCS gemeldete Daten können von einer auf der drahtlosen Einrichtung ausgeführten Applikation (App) verarbeitet und dem Benutzer übersichtlich und lesbar präsentiert werden.
Der in 2 gezeigte Prozess wird im Fahrzeugcomputersystem ausgeführt, wenngleich der Fachmann versteht, dass mindestens einige Abschnitte dieses Prozesses auch von der drahtlosen Einrichtung oder einem cloudbasierten System abgewickelt werden könnten. In dem in 2 gezeigten Beispiel hat ein Benutzer eine Applikation auf einer tragbaren Einrichtung, die einen Treibstoffstand anfordern wird, gestartet oder führt diese Applikation gerade aus, oder in einem Alternativbeispiel weiß der Prozess im VCS, dass auf eine solche Applikation zugegriffen werden kann.
In diesem Beispiel fordert die Applikation einen Treibstoffstand vom VCS an, das die Anforderung von der Applikation empfängt 201. Weil zum Übertragen von Daten zu und von der Applikation eine bestimmte Menge Strom benötigt wird, ist möglich, dass das VCS nach dem Ausschalten des Fahrzeugs eine gewisse Zeit lang, mindestens mit eingeschränkter Leistung, mit Strom versorgt wird. Sobald die Anforderung empfangen wurde, kann das VCS (zum Beispiel unter Nutzung einer Fahrzeugbatterie) einen angemessenen Stromstand aufrechterhalten, um eventuelle weitere Aktionen zu verarbeiten, die hinsichtlich der Anforderung ausgeführt werden müssen 203.
Da sich die Anforderung in diesem Ausführungsbeispiel auf einen aktuellen Treibstoffstand bezogen hat, ruft das VCS Treibstoffstandinformationen vom jeweiligen Fahrzeugsensor und/oder vom BUS ab. Die Informationen können dann an die anfordernde Applikation/Einrichtung gesendet werden 205. In bestimmten Fällen ist es eventuell wünschenswert, einen Fahrer zu warnen, zum Beispiel bei der Annäherung an einen vorher eingestellten Treibstoffstand.
In den Beispielen unten wird die Option erörtert, dass die Betankung von der Einrichtung aus ausgestellt wird, doch in vielen aktuellen Situationen in der realen Welt ist die Technologie zum Implementieren dieser Lösung an Tankstellen bisher unter Umständen noch nicht installiert worden. Folglich bietet die Anmeldung möglicherweise eine Fähigkeit zum Einstellen der Füllhöhe, der Kosten, der fahrbaren Distanz usw. Falls ein aktueller Treibstoffstand auf diesem Stand 207 ist oder sich diesem Stand 207 annähert, kann das System an einen Fahrer eine Warnung senden 209 und den Fahrer hinsichtlich der Zapfsäulenabschaltung informieren. Dies kann zum Beispiel nützlich sein, falls ein Fahrer vom Fahrzeug entfernt ist, sich (bei kaltem Wetter) innerhalb des Fahrzeugs aufhält oder ansonsten die Treibstoffzapfsäule gerade nicht direkt ansieht. Weiter kann der Fahrer, was die fahrbare Distanz und ähnliche Variablen betrifft, beim Ansehen der Zapfsäule die wirkliche fahrbare Distanz basierend auf einem aktuellen Fahrzeugtreibstoffstand nicht einschätzen.
Falls keine Warnung gegeben wird, übermittelt das System Meldungen möglicherweise so lange weiter, bis das Fahrzeug einen vollen Treibstoffstand erreicht hat 211. Sobald der Fahrzeug-Treibstoffstand einen vollen Zustand erreicht hat 211, wird bei dem Prozess an die anfordernde Applikation möglicherweise ein „Voll“-Signal gesendet.
3 zeigt ein Ausführungsbeispiel für ein Treibstoffstandmelde- und -steuersystem. In diesem Ausführungsbeispiel wird beim im VCS ausgeführten Prozess von einer Remote-Applikation möglicherweise erneut eine Anforderung von Daten bezüglich aktueller Treibstoffstände empfangen 301. Weiter ist in dieser Ausführungsform vorgesehen, dass eine gewisse Form einer Verbindung zur Treibstoffzapfsäule besteht, die hergestellt wird, indem zum Beispiel unter anderem WiFi, Bluetooth oder ein anderes Medium für drahtlose Kommunikation verwendet wird. Diese Verbindung könnte zwischen einer drahtlosen Einrichtung und der Zapfsäule, einem Fahrzeug und der Zapfsäule oder allen drei bestehen.
In diesem Beispiel wird bei dem Prozess geprüft, ob eine solche Verbindung verfügbar ist 303. Besteht eine solche Verbindung, können dadurch diverse Features bereitgestellt werden. Zum Beispiel könnten Kostendaten und der gezapfte Treibstoff an das Fahrzeug zur Telefonübertragung oder direkt an ein Telefon übertragen werden. Ebenso könnten Befehle von einem Fahrzeug (Abschalten der Zapfsäule, langsame Zapfsäule, langsame Aufladung, Beenden der Aufladung usw.) oder einer drahtlosen Einrichtung zur drahtlosen Steuerung über die Zapfsäule weitergesendet werden (es ist zu beachten, wie zuvor angegeben, dass Zapfsäule auch synonym für Stecker bei Elektrofahrzeugen stehen kann).
Falls keine Verbindung zur Zapfsäule besteht, werden bei dem Prozess in dieser Ausführungsform wieder die Standardeinstellungen übernommen, wobei Befehle nicht an die Zapfsäule weitergeleitet oder als Option bereitgestellt werden, wie in 2 gezeigt. Falls die Verbindung verfügbar ist, wird bei dem Prozess in dieser Ausführungsform dann eine Anforderung eines Stands empfangen, auf dem das Pumpen eingestellt werden soll 305. In diesem Beispiel könnte der Stand eine spezielle Gallonenmenge oder Aufladung oder könnte allgemeiner sein (z. B. unter anderem 50%/75%/100% usw.). Zusätzlich oder alternativ könnte die Anforderung die Form einer zurücklegbaren Distanz haben – z. B. Abschalten der Zapfsäule, wenn die zurücklegbare Distanz über 100 Meilen beträgt.
Sobald die Anforderung empfangen wurde, wird bei dem Prozess erneut im Hinblick darauf geprüft, ob die Kommunikation mit der Zapfsäule immer noch hergestellt ist 307. Wie zuvor angegeben, könnte die Applikation, wenngleich die Kommunikation hier zwischen einem Fahrzeug und der Zapfsäule besteht, potenziell direkt mit der Zapfsäule kommunizieren.
Wenngleich dies hierin nicht ausführlich beschrieben wird, wird in Betracht gezogen, dass die physische Zapfsäule oder der physische Stecker mit einem Kontaktrelais in irgendeiner Form ausgestattet sein könnte, um sicherzustellen, dass drahtlos ankommende Befehle von einem Fahrzeug tatsächlich von dem Fahrzeug stammen, mit dem die Zapfsäule momentan verbunden ist. Dies könnte durch diverse Verfahren erreicht werden, die hierin nicht ausführlich beschrieben werden. Auch sind diese Verfahren auf keine physische Kommunikationsbestätigung eingeschränkt, ein Benutzer könnte zum Beispiel eine PIN oder einen anderen Code eintippen, um eine Zapfsäule mit einem Fahrzeug und/oder einer drahtlosen Einrichtung zu korrelieren.
In diesem Beispiel kann das Fahrzeugcomputersystem den Benutzer warnen 309, falls die Zapfsäule nicht verbunden und zur drahtlosen Anweisung verfügbar ist. Diese Warnung kann nützlich sein, denn sie ermöglicht, dass der Benutzer merkt, dass zum Beispiel unter Umständen kein Abschaltbefehl gegeben wurde. Sie kann auch dazu beitragen, eine zu starke Treibstoffzufuhr zu verhindern und eine schlechte Benutzererfahrung abzuwenden, wenn zu viel Treibstoff zugeführt wird.
Falls die Zapfsäule verbunden und eine Steuermöglichkeit verfügbar ist, kann bei dem Prozess an die Zapfsäule ein Befehl zum Abschalten auf einem bestimmten Stand gesendet werden 311. In Wirklichkeit ist es in dieser Ausführungsform unwahrscheinlich, dass die Zapfsäule den wirklichen Treibstoffstand des Fahrzeugs kennt. Folglich wird bei dem Prozess der Treibstoffstand überwacht 313, und wenn der jeweilige Stand erreicht ist 315, kann der Abschaltbefehl gesendet werden 317. In einer anderen Ausführungsform könnte, falls zum Beispiel eine Gesamtmenge von ausgegebenem Treibstoff oder die Gesamtkosten angefordert wurden, die Zapfsäule die Anforderung vom Fahrzeug empfangen und für die Abschaltung auf diesem Stand zuständig sein.
4 zeigt ein zweites Ausführungsbeispiel für ein Treibstoffstandmelde- und -steuersystem. Auch in diesem Ausführungsbeispiel erfolgt bei dem
Prozess eine Interaktion mit einer Zapfsäule, die durch die Verwendung des Fahrzeugcomputersystems möglicherweise eine hierfür verfügbare Steuermöglichkeit aufweist oder nicht. In diesem Beispiel empfängt der Prozess eine Anforderung von Daten bezüglich aktueller Treibstoffstände (oder zum Beispiel eine Anforderung zum Steuern eines beliebigen Aspekts des Betankens) 401.
Bei dem Prozess wird zuerst bestimmt, ob eine Steuerverbindung zur Zapfsäule verfügbar ist 403. Falls keine solche Verbindung verfügbar ist, müssen Meldungen eventuell durch das Fahrzeugcomputersystem erfolgen, und es sind eventuell keine Steuerfeatures der Applikation verfügbar. Falls keine solche Verbindung verfügbar ist, können bei dem Prozess eventuell angeforderte Daten folglich einfach an die Einrichtung gesendet werden 405.
Falls eine Möglichkeit zur Steuerung der Zapfsäule in irgendeiner Form verfügbar ist, kann bei dem Prozess bestimmt werden, ob eine Anforderung eines Treibstoffstoppstands (z. B. unter anderem Treibstoffstand, Kosten, Distanz usw.) im Rahmen der Anforderung vorliegt 407. Falls eine solche Anforderung vorliegt, werden bei dem Prozess möglicherweise entweder die Anforderung an die Zapfsäule gesendet 413 (falls sich der variable Abschaltpunkt auf einen von der Zapfsäule verfolgten Faktor bezieht) oder der Betankprozess gesteuert und eine Abschaltung am jeweiligen Punkt angefordert (falls sich der variable Abschaltpunkt auf einen vom Fahrzeug verfolgten Faktor bezieht). Gleichzeitig können Daten, die sich auf das Betanken beziehen, nach wie vor an die Einrichtung gesendet werden, damit der Benutzer sie ansehen kann 405.
Falls keine spezielle Abschaltung festgelegt ist, können bei dem Prozess ein Treibstoffstand überwacht werden 411 und die Daten, die sich auf diesen Treibstoffstand beziehen, an die Einrichtung gesendet werden 415. Da die Zapfsäule in diesem Abschnitt des Prozesses als steuerbar bestätigt wurde, können basierend auf dem Empfang und der Verarbeitung dieser Daten unterschiedliche Aktionen ausgeführt werden. Zum Beispiel könnte der Benutzer, wenn er sähe, dass ein gewünschter Treibstoffstand oder gewünschte Kosten (zum Beispiel von der Zapfsäule weitergesendet) erreicht worden sind oder bald erreicht sein werden, eine Abschaltung 417 oder Verlangsamung des Betankens anfordern, was an die Zapfsäule weitergesendet werden könnte 419. Bei diesem Prozess könnte der Benutzer den Betankprozess dann bis zu einem gewissen Grad dynamisch steuern, selbst wenn der Benutzer nicht neben der Zapfsäule stünde. Zum Beispiel könnte der Benutzer an einem kalten Wintertag im Fahrzeug sitzen und genau die Menge Treibstoff zapfen, die gewünscht wäre, ohne hierfür im Freien frieren zu müssen.
Die 5A und 5B zeigen Ausführungsbeispiele für eine Treibstoffstandmeldeapplikationsausgabe. In diesem Ausführungsbeispiel zeigt 5A einige Features, die auf einem Smartphone für ein Elektrofahrzeug verfügbar sein könnten, und 5B zeigt einige Features, die auf einem Smartphone für ein benzinbetriebenes Fahrzeug verfügbar sein könnten. Selbstverständlich könnten auch für Hybridfahrzeuge und andere in geeigneter Weise betriebene Fahrzeuge Meldesysteme bereitgestellt werden.
In diesem Beispiel zeigt das Beispieltelefon in 5A ein Display einer Applikation, die Stromstände in einem Akkumulatorenfahrzeug (Battery Electric Vehicle, BEV) oder einem Hybrid-Elektrofahrzeug (Hybrid Electric Vehicle, HEV) meldet. In der Mitte des Displays zeigt die Applikation in diesem Beispiel einen Aufladestand, der für einen Gesamtzustand der Fahrzeugaufladung repräsentativ ist 501. Dadurch kann ein Benutzer einen Gesamtaufladezustand schnell und einfach messen. Im Fall eines laufenden Ladevorgangs könnte dieses Display zum Beispiel blinken, ein Aufladesymbol anzeigen oder ein anderes geeignetes Zeichen für den laufenden Ladevorgang bereitstellen.
In diesem Beispiel wird auch ein aktuell verfügbarer Bereich gezeigt, der auf dem aktuellen Ladestand 503 basiert. Dieser Schätzbereich kann auf Fahrzeugspezifikationen basieren, oder falls das Fahrzeug lange genug gefahren worden ist, sodass eine genauere Bestimmung des Stromverbrauchs für einen konkreten Fahrer bezogen werden kann, kann der Bereich auf Informationen eines bekannten Bereichs für diesen konkreten Bediener basieren (wie zum Beispiel basierend auf einer Korrelation zwischen einem Telefon und dem Bediener definiert).
Das beispielhafte Display zeigt auch eine geschätzte Zeit bis zur vollständigen Aufladung 505. Diese kann auf von einem Aufladepunkt empfangenen Informationen basieren oder kann zum Beispiel auf einer beobachteten Aufladerate basieren, die auf vorherigen Aufladungen basiert. Ein maximaler Bereich für das Fahrzeug kann ebenfalls gezeigt werden 507, der wiederum entweder auf OEM-Spezifikationsdaten basiert oder auf beobachtetem Fahrverhalten und maximalen Bereichen basierend auf früheren vollständigen Aufladungen basiert.
Dieses Ausführungsbeispiel beruht ferner auf einer gewissen Benutzerinteraktivität. In diesem Beispiel zeigt der Bildschirm eine „Stopp“-Schaltfläche 509 an, die zu einem Befehl zum Beenden des Ladens korrelieren wird. Der Benutzer kann diesen Befehl in diesem Beispiel jederzeit auswählen, um den aktuellen Ladezyklus zu beenden, wobei angenommen wird, dass das Fahrzeug die Aufladung entweder selbst stoppen oder der Aufladepunkt remote ausgestellt werden kann.
Das Display zeigt auch eine „Festlegen“-Schaltfläche 511, die verwendet werden kann, um eine beliebige Anzahl von Ständen festzulegen, auf denen eine Aufladung beendet werden soll. In diesem Beispiel werden zwei nicht einschränkende Fälle eines Voll-Prozentwerts (75%) 513 und einer fahrbaren Distanz (173 Meilen) 515 gezeigt. Wenn der Benutzer diese Schaltfläche drückt, kann ihm die Option gegeben werden, die Art des Beendigungspunkts auszuwählen, und ihm kann die Option gegeben werden, einen Wert für den Beendigungspunkt einzugeben.
5B zeigt ein zweites Beispiel für ein Smartphone-Display, in diesem Fall für ein benzinbetriebenes Fahrzeug. In diesem Beispiel zeigt das Display wie beim Elektrofahrzeug in der Mitte des Displays 531 ein großes Zeichen für den Treibstoffgesamtstand. Auch wird wie beim Elektro-Display ein aktueller fahrbarer Bereich gezeigt 517. Die Zeit bis voll 519 kann gezeigt werden und es kann auch ein maximaler Fahrzeugbereich 521 angezeigt werden.
Dieses Feature ist ebenfalls mit einer Stopp-Schaltfläche 509 versehen. Da benzinbetriebene Fahrzeuge in der Regel keine Beendigung der Treibstoffzufuhr bewirken können, wird die Stopp-Schaltfläche in diesem Fall möglicherweise nur aktiviert, wenn die Zapfsäule auf Befehle von der Einrichtung oder vom Fahrzeugcomputersystem her reagieren kann. Eine Festlegen-Schaltfläche ist ähnlich bereitgestellt und vermittelt in diesem Fall die Optionen, einen Stopp bei einem Treibstoffstand 523 oder bei einem Dollarstand 527 festzulegen. Andere geeignete Stände können nach Bedarf und wie gewünscht ebenfalls implementiert werden.
Dieses Ausführungsbeispiel zeigt auch, dass möglicherweise eine Fahrerwarnung angezeigt wird 529. In diesem Beispiel ist eventuell die Option zum Stoppen einer Einrichtung basierend auf der Zapfsäulenverbindung nicht vorhanden, daher benachrichtigt das Display den Fahrer, dass der gewünschte Stopppunkt in 1,5 Minuten möglicherweise erreicht sein wird. Selbst wenn die Zapfsäule durch die Einrichtung oder einen Befehl vom Fahrzeug gestoppt werden könnte, kann diese Warnung dennoch nützlich sein und angezeigt werden.
Auch wenn oben beispielhafte Ausführungsformen beschrieben wurden, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Ausgestaltungen der Erfindung beschreiben. Vielmehr sind die in der Patentschrift verwendeten Begriffe beschreibende und keine einschränkenden Begriffe, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Gedanken und vom Schutzbereich der Erfindung abzuweichen. Zudem können die Features verschiedener implementierender Ausführungsformen so kombiniert werden, dass sie weitere Ausführungsformen der Erfindung 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 Patentliteratur

US 2011/0057612 [0003]
US 6630813 [0004]

Zitierte Nicht-Patentliteratur

IEEE 802 PANS [0022]
IEEE 802 LANS [0022]
IEEE 802 PANS [0022]
IEEE 1394 [0025]
IEEE 1284 [0025]
IEEE 803.11 [0027]

Claims

System, das Folgendes umfasst: einen Prozessor, der konfiguriert ist, um: Anforderungen von einer drahtlosen Einrichtung in drahtloser Kommunikation mit dem Prozessor zu empfangen, wobei die Anforderungen einem oder mehreren Aspekten eines Betankprozesses entsprechen; dem einem oder den mehreren Aspekten des Betankprozesses entsprechende Fahrzeugdaten zu erfassen; und auf die Anforderungen durch Senden der Daten bezüglich des einen oder der mehreren Aspekte des Betankprozesses zu reagieren.
System nach Anspruch 1, wobei der Treibstoff Benzin ist.
System nach Anspruch 1, wobei der Treibstoff Elektrizität ist.
System nach Anspruch 1, wobei ein Aspekt des Betankprozesses ein Treibstoffstand oder ein Ladestand ist.
System nach Anspruch 1, wobei ein Aspekt des Betankprozesses die Zeit bis voll ist.
System nach Anspruch 1, wobei ein Aspekt des Betankprozesses eine fahrbare Distanz basierend auf einem aktuellen Treibstoffstand ist.
System nach Anspruch 1, wobei der Prozessor weiter konfiguriert ist, um eine Stoppanforderung zu empfangen und darauf reagierend zur Beendigung eines Betankprozesses anzuweisen.
System nach Anspruch 1, wobei der Prozessor weiter konfiguriert ist, um einen Stoppstand zu empfangen, den Betankprozess zu überwachen, bis der Stoppstand erreicht worden ist, und zur Beendigung des Betankprozesses anzuweisen, sobald der Stoppstand erreicht worden ist.
System nach Anspruch 8, wobei der Stoppstand ein Treibstoffstand oder ein Ladestand ist.
System nach Anspruch 8, wobei der Stoppstand eine fahrbare Distanz ist.
System nach Anspruch 1, wobei der Prozessor weiter konfiguriert ist, um einen Stoppstand zu empfangen und zur Beendigung des Betankprozesses anzuweisen, sobald die Betankeinrichtung erkennt, dass ein empfangener Stoppstand erreicht worden ist.
System nach Anspruch 11, wobei der Stoppstand eine Gesamtmenge von ausgegebenem Treibstoff oder Strom ist.
System nach Anspruch 11, wobei der Stoppstand Gesamtkosten für ausgegebenen Treibstoff oder Strom ist.