DE102015208709A1 - Verfahren und vorrichtung zum zeitlichen planen des fahrzeugstarts - Google Patents

Verfahren und vorrichtung zum zeitlichen planen des fahrzeugstarts Download PDF

Info

Publication number
DE102015208709A1
DE102015208709A1 DE102015208709.3A DE102015208709A DE102015208709A1 DE 102015208709 A1 DE102015208709 A1 DE 102015208709A1 DE 102015208709 A DE102015208709 A DE 102015208709A DE 102015208709 A1 DE102015208709 A1 DE 102015208709A1
Authority
DE
Germany
Prior art keywords
vehicle
schedule
user
processor
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE102015208709.3A
Other languages
English (en)
Inventor
Brian Petersen
Joseph Paul Rork
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ford Global Technologies LLC
Original Assignee
Ford Global Technologies LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ford Global Technologies LLC filed Critical Ford Global Technologies LLC
Publication of DE102015208709A1 publication Critical patent/DE102015208709A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60H—ARRANGEMENTS OF HEATING, COOLING, VENTILATING OR OTHER AIR-TREATING DEVICES SPECIALLY ADAPTED FOR PASSENGER OR GOODS SPACES OF VEHICLES
    • B60H1/00—Heating, cooling or ventilating [HVAC] devices
    • B60H1/00642—Control systems or circuits; Control members or indication devices for heating, cooling or ventilating devices
    • B60H1/0065—Control members, e.g. levers or knobs
    • B60H1/00657—Remote control devices
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60H—ARRANGEMENTS OF HEATING, COOLING, VENTILATING OR OTHER AIR-TREATING DEVICES SPECIALLY ADAPTED FOR PASSENGER OR GOODS SPACES OF VEHICLES
    • B60H1/00—Heating, cooling or ventilating [HVAC] devices
    • B60H1/00642—Control systems or circuits; Control members or indication devices for heating, cooling or ventilating devices
    • B60H1/00735—Control systems or circuits characterised by their input, i.e. by the detection, measurement or calculation of particular conditions, e.g. signal treatment, dynamic models
    • B60H1/00764—Control systems or circuits characterised by their input, i.e. by the detection, measurement or calculation of particular conditions, e.g. signal treatment, dynamic models the input being a vehicle driving condition, e.g. speed
    • B60H1/00778—Control systems or circuits characterised by their input, i.e. by the detection, measurement or calculation of particular conditions, e.g. signal treatment, dynamic models the input being a vehicle driving condition, e.g. speed the input being a stationary vehicle position, e.g. parking or stopping
    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
    • F02D—CONTROLLING COMBUSTION ENGINES
    • F02D29/00—Controlling engines, such controlling being peculiar to the devices driven thereby, the devices being other than parts or accessories essential to engine operation, e.g. controlling of engines by signals external thereto
    • F02D29/02—Controlling engines, such controlling being peculiar to the devices driven thereby, the devices being other than parts or accessories essential to engine operation, e.g. controlling of engines by signals external thereto peculiar to engines driving vehicles; peculiar to engines driving variable pitch propellers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F02—COMBUSTION ENGINES; HOT-GAS OR COMBUSTION-PRODUCT ENGINE PLANTS
    • F02N—STARTING OF COMBUSTION ENGINES; STARTING AIDS FOR SUCH ENGINES, NOT OTHERWISE PROVIDED FOR
    • F02N2300/00—Control related aspects of engine starting
    • F02N2300/20—Control related aspects of engine starting characterised by the control method

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Mechanical Engineering (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • Economics (AREA)
  • Thermal Sciences (AREA)
  • General Business, Economics & Management (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Marketing (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • General Engineering & Computer Science (AREA)
  • Chemical & Material Sciences (AREA)
  • Combustion & Propulsion (AREA)
  • Information Transfer Between Computers (AREA)
  • Traffic Control Systems (AREA)

Abstract

Ein erfindungsgemäßes System weist einen Prozessor auf, der dafür ausgelegt ist, Fahrzeugstartzeiten zu protokollieren. Der Prozessor ist auch dafür ausgelegt zu bestimmen, ob Zeitabweichungen oberhalb eines Zeitschwellenwerts zwischen protokollierten Fahrzeugstartzeiten und geplanten Startzeiten vorhanden sind.

Description

  • Die veranschaulichenden Ausführungsformen betreffen allgemein ein Verfahren und eine Vorrichtung zum zeitlichen Planen des Fahrzeugstarts.
  • Viele Fahrzeuge sind mit Fernstartfähigkeiten vorgerüstet. Bei diesen Fahrzeugen wird der Benutzer eine Funktion auf einem Schlüsselanhänger aktivieren, und ein Fahrzeug wird durch Aktivieren des Motors reagieren. Einige Fernstartfunktionen können das automatische Einstellen einer Fahrzeugtemperatur und das Aktivieren bestimmter Klimafunktionen des Fahrzeugs umfassen. Es kann auch automatisches Verriegeln von Fahrzeugtüren bereitgestellt werden, so dass ein gestartetes Fahrzeug nicht weggefahren werden kann. Wenngleich dies bequem ist, können Benutzer vielleicht vergessen, das Fahrzeug an gewissen Morgen zu starten, selbst wenn das Fernstarten des Fahrzeugs typischerweise ein Bestandteil einer morgendlichen Routine ist.
  • US-Patentschrift 7,542,827 betrifft allgemein ein Verfahren zum zeitlichen Planen des Fernstartens eines Motors eines Fahrzeugs. Das Fahrzeug weist eine Fernstartvorrichtung und ein Steuergerät auf, das mit einer Kommunikationsvorrichtung und der Fernstartvorrichtung gekoppelt ist. Die Fernstartvorrichtung spricht auf Befehle vom Steuergerät an. Das Verfahren weist einen ersten Schritt zum Definieren eines Zeitplans für Startzeiten auf. Ein nächster Schritt weist das Eingeben des Zeitplans in das Steuergerät auf. Ein nächster Schritt weist das Steuern einer Operation der Fernstartvorrichtung gemäß dem Zeitplan auf.
  • US-Patentschrift 8,489,085 betrifft allgemein ein System und Verfahren für einen Fernstarter eines Fahrzeugs mit einem weiterentwickelten dynamischen Zeitplanungssystem. Das System und Verfahren verwenden ein Mobiltelefon, das sich mit standardmäßiger Zeitplanungssoftware verbindet und mit dem Internet kommunizieren kann, um Echtzeitdaten zu erfassen, und über ein drahtloses Telekommunikationsnetz mit einem Fahrzeug kommunizieren kann, um Fahrzeugfernstart- und andere Befehle zu senden; ein elektronisches Zeitplanungssystem, das vom Mobiltelefon verwendet wird oder worauf das Mobiltelefon zugreifen kann; ein GPS-Lokalisierungsmodul, das auf dem Mobiltelefon und/oder Fahrzeug beruht, zum Bestimmen des Standorts des Fahrzeugs und des Mobiltelefons zu einem bestimmten Zeitpunkt; einen Satz codierter Anweisungen, die Echtzeitdaten aus dem Internet aktiv abfragen und das elektronische Zeitplanungssystem abfragen, um die Zeit und den Ort eines geplanten Treffens zu bestimmen, indem sie verschiedene Fahrzeugbetriebsparameter, wie etwa die Entfernung des Mobiltelefons von einem Fahrzeug, verschiedene Umweltparameter, wie etwa die Entfernung von einem Fahrzeug zu einem Treffpunkt, die Fahrzeit, die erforderlich ist, um pünktlich abzufahren und am geplanten Treffen teilzunehmen, bewerten, und indem sie den Benutzer entweder auffordern, ein Fernstart-Befehlssignal an das Fahrzeug aktiv zu senden oder das Fernstart-Befehlssignal automatisch zu senden.
  • In einer ersten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren das Protokollieren von Fahrzeugstartinformationen. Das Verfahren beinhaltet auch das Bestimmen, über einen Computer, ob zeitliche Übereinstimmungen zwischen Fällen protokollierter Fahrzeugstartinformationen vorhanden sind. Ferner beinhaltet das Verfahren das Empfehlen des automatischen Fahrzeugstarts auf der Basis einer Schwellenwertzahl zeitlicher Übereinstimmungen. Das Verfahren beinhaltet auch das Formulieren empfohlener Startzeiten auf der Basis von Fällen protokollierter Fahrzeugstartinformationen mit zeitlichen Übereinstimmungen. Das Verfahren beinhaltet zusätzlich, einem Fahrzeugnutzer einen Zeitplan einschließlich empfohlener Startzeiten anzubieten und automatische Fahrzeugstarts zu planen, nachdem der Fahrzeugnutzer den angebotenen Zeitplan akzeptiert hat.
  • In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren das Protokollieren von Fahrzeugstartinformationen. Das Verfahren beinhaltet auch das Bestimmen über einen Computer, ob zeitliche Übereinstimmungen zwischen Fällen protokollierter Fahrzeugstartinformationen vorhanden sind. Das Verfahren beinhaltet ferner das Empfehlen des automatischen Fahrzeugstarts auf der Basis einer Schwellenwertzahl zeitlicher Übereinstimmungen. Das Verfahren beinhaltet ferner das Formulieren empfohlener Startzeiten auf der Basis von Fällen protokollierter Fahrzeugstartinformationen mit zeitlichen Übereinstimmungen. Das Verfahren beinhaltet ebenfalls, einem Fahrzeugnutzer einen Zeitplan einschließlich empfohlener Startzeiten anzubieten und automatische Fahrzeugstarts zu planen, nachdem der Fahrzeugnutzer den vorgestellten Zeitplan akzeptiert hat.
  • In einer dritten veranschaulichenden Ausführungsform weist ein System einen Prozessor auf, der dafür ausgelegt ist, Fahrzeugstartzeiten zu protokollieren. Der Prozessor ist auch dafür ausgelegt zu bestimmen, ob Zeitabweichungen oberhalb eines Zeitschwellenwerts zwischen protokollierten Fahrzeugstartzeiten und geplanten Startzeiten vorhanden sind. Ferner ist der Prozessor dafür ausgelegt, auf der Basis einer Schwellenwertzahl von Zeitabweichungen oberhalb eines Zeitschwellenwerts, eine Änderung der geplanten Startzeiten zu empfehlen. Der Prozessor ist auch dafür ausgelegt, neue empfohlene Startzeiten auf der Basis von Fällen protokollierter Fahrzeugstartinformationen mit zeitlichen Übereinstimmungen zu formulieren. Der Prozessor ist zusätzlich dafür ausgelegt, einem Fahrzeugnutzer einen neuen Zeitplan einschließlich neuer empfohlener Startzeiten anzubieten und automatische Fahrzeugstarts erneut zu planen, nachdem der Fahrzeugnutzer den vorgestellten Zeitplan akzeptiert hat.
  • 1 zeigt ein veranschaulichendes Fahrzeug-Computersystem;
  • 2 zeigt einen veranschaulichenden fahrzeugseitigen Prozess, um zeitliches Planen eines Fahrzeugstarts zu empfehlen;
  • 3 zeigt einen veranschaulichenden serverseitigen Prozess, um zeitliches Planen eines Fahrzeugstarts zu empfehlen;
  • 4 zeigt einen veranschaulichenden fahrzeugseitigen Prozess, um das Ändern eines Zeitplans zu empfehlen; und
  • 5 zeigt einen veranschaulichenden serverseitigen Prozess, um das Ändern eines Zeitplans zu empfehlen.
  • Wie erforderlich werden hier ausführliche Ausführungsformen der vorliegenden Erfindung offenbart; es ist jedoch einzusehen, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, welche in verschiedenen und alternativen Formen ausgeführt werden kann. Die Figuren sind nicht notwendigerweise maßstabsgetreu; einige Merkmale können übertrieben oder verkleinert dargestellt sein, um Einzelheiten bestimmter Komponenten zu zeigen. Daher sind spezifische, hier offenbarte strukturelle und funktionale Einzelheiten nicht als einschränkend zu verstehen, sondern lediglich als repräsentative Grundlage, die dem Fachmann auf diesem Gebiet der Technik Anleitung bieten, um die vorliegende Erfindung auf vielfältige Weise einzusetzen.
  • 1 stellt eine beispielhafte Blocktopologie für ein fahrzeuginternes Computersystem 1 (VCS, Vehicle Based Computing System) für ein Fahrzeug 31 dar. Ein Beispiel eines derartigen fahrzeuginternen Computersystems 1 ist das von THE FORD MOTOR COMPANY hergestellte SYNC-System. Ein Fahrzeug, das mit einem fahrzeuginternen Computersystem ausgestattet ist, kann eine visuelle Frontend-Schnittstelle 4 aufweisen, die im Fahrzeug angeordnet ist. Der Benutzer kann auch mit der Schnittstelle interagieren, wenn sie bereitgestellt wird, beispielsweise mit einem berührungsempfindlichen Bildschirm. In einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion durch Tastendruck, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
  • In der veranschaulichenden Ausführungsform 1, die in 1 dargestellt ist, steuert ein Prozessor 3 wenigstens einen Teil des Betriebs des fahrzeuginternen Computersystems. Indem der Prozessor innerhalb des Fahrzeugs bereitgestellt wird, erlaubt er die bordinterne Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit einem nichtpersistenten 5 als auch mit einem persistenten Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der nichtpersistente Speicher ein Speicher mit wahlfreiem Zugriff (Random Access Memory, RAM) und der persistente Speicher ist ein Festplattenlaufwerk (Hard Disk Drive, HDD) oder ein Flash-Speicher. Im Allgemeinen kann der persistente (nichtflüchtige) Speicher alle Speicherformen aufweisen, die Daten beibehalten, wenn ein Computer oder eine andere Vorrichtung abgeschaltet ist. Dazu gehören HDDs, CDs, DVDs, Magnetbänder, Festkörperlaufwerke, tragbare USB-Laufwerke und jede andere geeignete Form persistenten Speichers, sind jedoch nicht darauf beschränkt.
  • Der Prozessor ist außerdem mit einer Anzahl verschiedener Eingänge ausgestattet, die dem Benutzer die Kommunikation mit dem Prozessor ermöglichen. In dieser veranschaulichenden Ausführungsform werden ein Mikrofon 29, ein Zusatzgeräte-Eingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der ein berührungsempfindlicher Bildschirm sein kann, und ein BLUETOOTH-Eingang 15 bereitgestellt. Ein Eingangswahlschalter 51 wird ebenfalls bereitgestellt, um einem Benutzer zu ermöglichen, zwischen verschiedenen Eingängen zu wechseln. Eingaben über das Mikrofon und den Zusatzgeräte-Anschluss werden durch einen Wandler 27 von analog zu digital umgesetzt, bevor sie an den Prozessor weitergegeben werden. Auch wenn dies hier nicht dargestellt ist, können zahlreiche Fahrzeugkomponenten und Zusatzkomponenten, die mit dem VCS in Kommunikationsverbindung stehen, ein Fahrzeugnetz (beispielsweise, jedoch nicht beschränkt auf einen CAN-Bus (Controller Area Network)) verwenden, um Daten an das und vom VCS (oder Komponenten davon) weiterzuleiten.
  • Ausgänge zum System können eine visuelle Anzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang umfassen, sind jedoch nicht hierauf beschränkt. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal vom Prozessor 3 über einen Digital/Analog-Wandler 9. Die Ausgabe kann auch an eine entfernte BLUETOOTH-Vorrichtung wie eine PND 54 oder eine USB-Vorrichtung wie eine Fahrzeugnavigationsvorrichtung 60 entlang den bidirektionalen Datenströmen erfolgen, die bei 19 bzw. 21 gezeigt werden.
  • In einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Sendeempfänger 15, um mit einer ortsungebundenen Vorrichtung, einer sog. „Nomadic Device“ 53, des Benutzers (z. B. Mobiltelefon, Smartphone, persönlichem digitalen Assistent (PDA, Personal Digital Assistant) oder jeder beliebigen anderen Vorrichtung mit drahtloser Netzfernanbindung) zu kommunizieren 17. Die ortsungebundene Vorrichtung kann dann verwendet werden, um mit einem Netz 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59, beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57. In einigen Ausführungsformen kann der Mast 57 ein Wi-Fi-Zugangspunkt sein.
  • Eine beispielhafte Kommunikation zwischen der ortsungebundenen Vorrichtung und dem BLUETOOTH-Sendeempfänger wird durch das Signal 14 dargestellt.
  • Eine Kopplung einer ortsungebundenen Vorrichtung 53 und des BLUETOOTH-Sendeempfängers 15 kann über eine Taste 52 oder eine ähnliche Eingabe veranlasst werden. Dementsprechend wird die CPU (Central Processing Unit, zentrale Verarbeitungseinheit) angewiesen, dass der bordeigene BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einer ortsungebundenen Vorrichtung gekoppelt wird.
  • Daten können zwischen CPU 3 und Netz 61 übertragen werden, beispielsweise mit einem Datentarif, Daten über Sprache oder MFV-Tönen (DTMF, Dual-Tone Multi-Frequency), die mit der ortsungebundenen Vorrichtung 53 verknüpft sind. Alternativ kann es wünschenswert sein, ein bordeigenes Modem 63 einzuschließen, das eine Antenne 18 besitzt, um Daten zwischen CPU 3 und Netz 61 über das Sprachband zu übertragen 16. Die ortsungebundene Vorrichtung 53 kann dann verwendet werden, um mit einem Netz 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59, beispielsweise durch Kommunikation 55 mit einem Mobilfunkmast 57. In einigen Ausführungsformen kann das Modem 63 eine Kommunikationsverbindung 20 mit dem Mast 57 herstellen, um mit dem Netz 61 zu kommunizieren. Als nicht einschränkendes Beispiel kann das Modem 63 ein USB-Mobilfunkmodem sein, und die Kommunikation 20 kann eine Mobilfunkkommunikation sein.
  • In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem ausgestattet, das eine API für die Kommunikation mit Modemanwendungssoftware aufweist. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder eine eingebettete Firmware in dem BLUETOOTH-Sendeempfänger zugreifen, um die drahtlose Kommunikationsverbindung mit einem entfernten BLUETOOTH-Sendeempfänger (wie er beispielsweise in einer ortsungebundenen Vorrichtung zu finden ist) herzustellen. Bluetooth ist ein Teilbereich der IEEE 802 PAN(Personal Area Network, Persönliches Netz)-Protokolle. IEEE 802 LAN(Local Area Network, Lokales Netz)-Protokolle beinhalten Wi-Fi und weisen erhebliche Kreuzfunktionalitäten mit IEEE 802 PAN auf. Beide eignen sich für die drahtlose Kommunikation in einem Fahrzeug. Weitere Kommunikationsmittel, die in diesem Bereich eingesetzt werden können, sind die optische Freiraumkommunikation (etwa Infrarot-Datenassoziation (IrDA, Infrared Data Association)) und nichtstandardisierte Infrarot (IR) Fernbedienungsprotokolle.
  • In einer anderen Ausführungsform weist die ortsungebundene Vorrichtung 53 ein Modem für Sprachband- oder Breitband-Datenkommunikation auf. In der Daten-über-Sprache-Ausführungsform kann ein Verfahren namens Frequenzmultiplex (Frequency Division Multiplexing) implementiert sein, wenn der Besitzer der ortsungebundenen Vorrichtung über die Vorrichtung sprechen kann, während gleichzeitig Daten übertragen werden. Zu anderen Zeiten, wenn der Besitzer die Vorrichtung gerade nicht nutzt, kann die Datenübertragung die gesamte Bandbreite (300 Hz bis 3,4 kHz in einem Beispiel) belegen. Wenngleich das Frequenzmultiplexverfahren für die analoge Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet gängig sein mag und auch weiterhin verwendet wird, ist es in weiten Bereichen durch Hybride mit Codemultiplex-(Code Domain Multiple Access, CDMA), Zeitmultiplex-(Time Domain Multiple Access, TDMA), Raummultiplex-(Space-Domain Multiple Access, SDMA) Verfahren für die digitale Mobilfunkkommunikation ersetzt worden. Dies sind alles ITU IMT-2000(3G)-konforme Standards, und sie bieten Datenraten von bis zu 2 Mbit/s für stationäre oder umhergehende Benutzer bzw. 385 kbit/s für Benutzer in einem fahrenden Fahrzeug. 3G-Standards werden heute zunehmend durch IMT-Advanced (4G) ersetzt, das Benutzern in einem Fahrzeug 100 Mbit/s und stationären Benutzern 1 Gbit/s bietet. Wenn der Benutzer über einen Datentarif zu der ortsungebundenen Vorrichtung verfügt, kann der Datentarif Breitbandübertragung erlauben, und das System könnte eine erheblich größere Bandbreite nutzen (und damit die Datenübertragung beschleunigen). In noch einer weiteren Ausführungsform wird die ortsungebundene Vorrichtung 53 durch eine (nicht gezeigte) Mobilfunkkommunikationsvorrichtung ersetzt, die im Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform kann die ND 53 (Nomadic Device – ortsungebundene Vorrichtung) eine drahtlose Vorrichtung eines lokalen Netzes (LAN, Local Area Network) sein, die beispielsweise (und ohne Einschränkung) über ein 802.11g-Netz (d. h. Wi-Fi) oder ein WiMax-Netz kommunizieren kann.
  • In einer Ausführungsform können ankommende Daten durch die ortsungebundene Vorrichtung per Daten-über-Sprache oder Datentarif über den bordeigenen BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs weitergeleitet werden. Im Fall bestimmter temporärer Daten beispielsweise können die Daten auf dem HDD oder einem anderen Speichermedium 7 so lange gespeichert werden, bis die betreffenden Daten nicht mehr benötigt werden.
  • Zusätzliche Quellen, die mit dem Fahrzeug kommunizieren können, umfassen eine persönliche Navigationsvorrichtung 54 zum Beispiel mit einem USB-Anschluss 56 und/oder einer Antenne 58, eine Fahrzeug-Navigationsvorrichtung 60 mit einem USB-62 oder einem anderen Anschluss, eine bordeigene GPS-Vorrichtung 24 oder ein (nicht gezeigtes) entferntes Navigationssystem, das an das Netz 61 angebunden ist. USB ist eines aus einer Klasse serieller Netzprotokolle. IEEE 1394 (FirewireTM (Apple), i.LINKTM (Sony) und LynxTM (Texas Instruments), die seriellen EIA(Electronics Industry Association)-Protokolle, IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Gerüst der seriellen Standards für die Vorrichtung-zu-Vorrichtung-Kommunikation. Die meisten der Protokolle können sowohl für die elektrische als auch für die optische Kommunikation implementiert werden.
  • Ferner könnte die CPU mit einer Vielzahl von anderen Zusatzgeräten 65 in Kommunikationsverbindung stehen. Diese Geräte können über einen drahtlosen 67 oder einen drahtgebundenen 69 Anschluss angeschlossen sein. Zusatzgeräte 65 können persönliche Medienwiedergabegeräte, drahtlose medizinische Geräte, tragbare Computer und dergleichen sein, sind jedoch nicht auf diese beschränkt.
  • Ebenso oder alternativ könnte die CPU mit einem fahrzeuginternen Drahtlos-Router 73 verbunden sein, beispielsweise mithilfe eines Wi-Fi-Sendeempfängers 71 (IEEE 803.11). Dies könnte es der CPU erlauben, sich mit entfernten Netzen in Reichweite des lokalen Routers 73 zu verbinden.
  • Zusätzlich zur Ausführung beispielhafter Prozesse durch ein fahrzeuginternes Computersystem in einem Fahrzeug können in bestimmten Ausführungsformen die beispielhaften Prozesse von einem Computersystem ausgeführt werden, das mit einem fahrzeuginternen Computersystem in Kommunikationsverbindung steht. Ein derartiges System kann eine drahtlose Vorrichtung (z. B., jedoch ohne Einschränkung, ein Mobiltelefon) oder ein entferntes Computersystem (z. B., jedoch ohne Einschränkung, einen Server) aufweisen, die/das über die drahtlose Vorrichtung angeschlossen ist, ist jedoch nicht hierauf beschränkt. Zusammenfassend können derartige Systeme als fahrzeugassoziierte Computersysteme (Vehicle Associated Computer Systems, VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS bestimmte Teile eines Prozesses abhängig von der jeweiligen Implementierung des Systems ausführen. Wenn beispielsweise, jedoch ohne Einschränkung, ein Prozess einen Schritt umfasst, Informationen an eine gekoppelte drahtlose Vorrichtung zu senden oder von dieser zu empfangen, dann ist es wahrscheinlich, dass die drahtlose Vorrichtung den Prozess nicht ausführt, da die drahtlose Vorrichtung schwerlich Informationen in Kommunikation mit sich selbst „sendet und empfängt“. Ein Durchschnittsfachmann auf diesem Gebiet der Technik wird verstehen, wann es unangemessen ist, ein bestimmtes VACS in einer gegebenen Lösung einzusetzen. Bei allen Lösungen wird davon ausgegangen, dass wenigstens das fahrzeuginterne Computersystem (VCS), das im Fahrzeug selbst angeordnet ist, die beispielhaften Prozesse durchführen kann.
  • In jeder der hierin erörterten veranschaulichenden Ausführungsformen wird ein beispielhaftes nicht einschränkendes Beispiel eines Prozesses gezeigt, der durch ein Computersystem ausführbar ist. Mit Bezug auf jeden Prozess kann das Computersystem, welches den Prozess ausführt, für den eingeschränkten Zweck der Ausführung des Prozesses als ein Spezialprozessor ausgelegt sein, um den Prozess auszuführen. Alle Prozesse müssen nicht in ihrer Gesamtheit ausgeführt werden und verstehen sich als Beispiele von Prozessarten, die ausgeführt werden können, um Elemente der Erfindung zu erreichen. Zusätzliche Schritte können den beispielhaften Prozessen wie gewünscht hinzugefügt oder aus ihnen herausgenommen werden.
  • Die veranschaulichenden Ausführungsformen gehen davon aus, dass ein System zum zeitlichen Planen eines Fernstarts eines Fahrzeugs bereits vorhanden ist. Wie im Stand der Technik zu erkennen, können mehrere Vorrichtungen außerhalb des Fahrzeugs programmiert werden, um mit einem Fahrzeug zu kommunizieren und den Fernstart zeitlich zu planen. Andere Beispiele möglicher Fernstartplanung weisen Zeitpläne auf, die in einem Fahrzeugspeicher selbst gespeichert sind, oder das Speichern eines Zeitplans in der Datenwolke (Cloud), der dem Fahrzeug mitgeteilt wird.
  • Diese Zeitpläne werden typischerweise von einem Benutzer erstellt. Falls Jim weiß, dass er das Fahrzeug Montag bis Freitag um 6 Uhr morgens brauchen wird, dann kann er eine Internet- oder Fahrzeugschnittstelle verwenden, um einen Zeitplan zu erzeugen, mit dem das Fahrzeug um 5 Uhr 50 an den vorgegebenen Tagen gestartet wird. Leider kann es sein, dass Jim nicht bekannt ist, dass sein Fahrzeug eine derartige Funktion besitzt, und dass er dementsprechend stattdessen jeden Tag um 5 Uhr 50 eine Fernstartoption benutzt.
  • In den veranschaulichenden Ausführungsformen wird vorgeschlagen, dass ein System „bemerken“ wird, wann ein Fahrzeug gestartet wird, und auf der Basis einer bestimmten Anzahl an übereinstimmenden Startereignissen zu einer übereinstimmenden Zeit wird der Prozess einem Benutzer zum Beispiel über eine Fahrzeugschnittstelle empfehlen, dass ein Zeitplan erstellt werden sollte. Dadurch wird der Benutzer einerseits darauf aufmerksam gemacht, dass die Funktion vorhanden ist, und andererseits wird ihm auch gleichzeitig ein Zeitplan auf der Basis übereinstimmender Fernstartzeiten bereitgestellt.
  • In den veranschaulichenden Ausführungsformen kann ein System außerdem eine Änderung der Startzeiten erkennen, wenn der Benutzer das Fahrzeug zu anderen Zeiten als typischerweise geplant startet. Ferner wird der Prozess vorhandene Zeitpläne prüfen und kann geeigneterweise Änderungen für diese Zeitpläne auf der Basis der beobachteten Nutzung des Fahrzeugs durch den Benutzer vorschlagen.
  • 2 zeigt einen veranschaulichenden fahrzeugseitigen Prozess, um zeitliches Planen eines Fahrzeugstarts zu empfehlen. Hinsichtlich der in dieser Figur beschriebenen veranschaulichenden Ausführungsformen wird angemerkt, dass ein Universalprozessor vorübergehend als ein Spezialprozessor für den Zweck aktiviert werden kann, einige oder alle der hierin gezeigten beispielhaften Verfahren auszuführen. Wenn Code ausgeführt wird, der Anweisungen zum Ausführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend bis zu jenem Zeitpunkt, an dem das Verfahren abgeschlossen ist, zu einem Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann, in geeignetem Maß, Firmware, die in Übereinstimmung mit einem vorkonfigurierten Prozessor funktioniert, bewirken, dass der Prozessor als ein Spezialprozessor funktioniert, der für den Zweck bereitgestellt wird, das Verfahren oder eine sinnvolle Variation davon auszuführen.
  • In diesem veranschaulichenden Beispiel überträgt der Prozess Startdaten an die Datenwolke, zur Analyse in der Datenwolke. In anderen Beispielen können allerdings in der Datenwolke basierte Prozesse direkt im Fahrzeug ausgeführt werden, und Analysen und Empfehlungen können im fahrzeugeigenen Computersystem erzeugt werden.
  • Wie in 2 gezeigt, wird der Prozess angestoßen, wenn ein Fahrzeugstartvorgang erkannt wird 201. Dies kann ein Startvorgang unter Verwendung eines Fahrzeugsystems sein oder es kann ein Startvorgang unter Verwendung einer Fernstartfunktion sein. Sobald die Startdaten erkannt wurden, speichert der Prozess die Startdaten in einem lokalen Speicher 203. Diese Daten kann das Fahrzeug direkt verwenden, falls der Analyseprozess bordintern ausgeführt wird, oder die Daten können zur Analyse an die Datenwolke gesendet werden 205.
  • In diesem Prozess sendet das lokale System die Daten zur Analyse an die Datenwolke 205. Das System wartet dann auf eine Antwort vom entfernten System 207. Während der Prozess abläuft und auf eine Antwort wartet, ist es möglich, dass der Prozess nach einer Wartezeit endet, wenn zu viel Zeit verstreicht. Wird eine Antwort empfangen 207, kann der Prozess auch eine Benachrichtigung empfangen, dass ein Zeitplan für Auto-Starts vorgeschlagen wird 209. Wird kein derartiger Hinweis empfangen, kann der Prozess enden.
  • Wenn der Prozess die Benachrichtigung empfängt, dass der Auto-Start vorgeschlagen wird, kann der Prozess Daten empfangen, die sich auf die Zeitplanung eines Auto-Starts beziehen 211. Diese Daten können empfohlene Startzeiten und empfohlene Wochentage für die entsprechenden Startzeiten aufweisen, ohne darauf beschränkt zu sein.
  • Der Prozess prüft, ob der Benutzer die Zeitplanempfehlungen gesperrt hat 213. Wenn die Empfehlungen gesperrt wurden, endet der Prozess. Wurden die Empfehlungen nicht gesperrt, kann der Prozess dem Benutzer einen Vorschlag anbieten, dass die Auto-Start-Funktion aktiviert werden sollte 215. Dieses Angebot kann zum Beispiel über eine Fahrzeugschnittstelle erfolgen oder könnte zum Beispiel auf einer Benutzervorrichtung erfolgen, die zusammen mit einer fahrzeugverbundenen Anwendung funktioniert. Es können alle geeigneten Mittel, die Empfehlung anzubieten, verwendet werden.
  • Wenn der Benutzer den empfohlenen Startzeitplan akzeptiert, kann der Prozess eine Startzeit planen 219. In diesem Beispiel wird die Startzeit im Fahrzeug geplant, und ein niedriger Energiepegel kann verwendet werden, um einen Zeitgeber laufen zu lassen, der verwendet werden kann, um den Startvorgang auszulösen. In einem anderen Beispiel kann die Startzeit per Fernzugriff geplant werden, und ein niedriger Energiepegel kann verwendet werden, um eine Kommunikationsvorrichtung aktiv zu halten, die mit dem entfernten Server kommunizieren kann, um Startanweisungen zu empfangen.
  • Sobald der Zeitplan im Fahrzeug aktualisiert wurde, kann der Prozess auch die Datenwolke mit dem neuen Zeitplan aktualisieren 225, so dass die Datenwolke aktuelle Fahrzeugzeitpläne verfolgen kann. Akzeptiert der Benutzer den empfohlenen Zeitplan nicht, kann dem Benutzer auch eine Option angeboten werden, den Empfehlungsprozess 221 zu sperren. Wenn der Prozess nicht gesperrt ist, kann das System die Datenwolke benachrichtigen, dass keine Sperrung vorliegt und dass kein Zeitplan akzeptiert wurde. Wenn der Prozess gesperrt würde, kann ein Sperrparameter 223 lokal eingestellt werden, und die Datenwolke kann mit dem Sperrparameter aktualisiert werden. In diesem Beispiel prüft der lokale Prozess, ob eine Sperrung vorliegt, aber in einem weiteren Beispiel kann die Datenwolke eine eventuelle Sperrung prüfen, bevor irgendeine Analyse oder Empfehlung zum Verarbeiten der Fahrzeugdaten durchgeführt wird (weil diese nicht notwendig ist, wenn die Empfehlungen sowieso gesperrt sind).
  • 3 zeigt einen veranschaulichenden serverseitigen Prozess, um eine Zeitplanung eines Fahrzeugstarts zu empfehlen. Hinsichtlich der in dieser Figur beschriebenen veranschaulichenden Ausführungsformen wird angemerkt, dass ein Universalprozessor vorübergehend als ein Spezialprozessor für den Zweck aktiviert werden kann, einige oder alle der hierin gezeigten beispielhaften Verfahren auszuführen. Wenn Code ausgeführt wird, der Anweisungen zum Ausführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend bis zu jenem Zeitpunkt, an dem das Verfahren abgeschlossen ist, zu einem Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann, in geeignetem Maß, Firmware, die in Übereinstimmung mit einem vorkonfigurierten Prozessor funktioniert, bewirken, dass der Prozessor als ein Spezialprozessor funktioniert, der für den Zweck bereitgestellt wird, das Verfahren oder eine sinnvolle Variation davon auszuführen.
  • In diesem veranschaulichenden Beispiel verbindet sich der entfernte Server, der sich in der Datenwolke befindet, mit einem bestimmten Fahrzeug 301. Der entfernte Server wird zum Beispiel Startdaten vom Fahrzeug empfangen 303. Diese Daten können einer entfernten Datenbank mit Datensätzen hinzugefügt werden, die für dieses bestimmte Fahrzeug 305 vorgesehen sind. Zusätzlich zu den Startdaten kann der Prozess auch das Fahrzeug identifizierende Informationen empfangen, die es dem entfernten Server ermöglichen, das Fahrzeug, dem die Datensätze entsprechen, zu identifizieren.
  • Der Fernprozess kann auch Einstellparameter für die Zeitplanung laden 307. Diese Parameter können von einem einzelnen Benutzer eingestellt werden oder können durch einen Erstausrüster (Original Equipment Manufacturer, OEM) eingestellt werden. Dadurch, dass der OEM Parameter einstellen kann, können Benutzer, denen die Existenz des Systems überhaupt nicht bekannt ist, von den hier beschriebenen Prozessen profitieren, ohne überhaupt erst die Fahrzeugparameter einstellen zu müssen.
  • Die Parameter können unter anderem eine Schwellenwertzahl spezifizieren, wie oft ein Startvorgang beobachtet werden sollte, bevor eine Empfehlung erzeugt wird. In einem anderen Beispiel können die Parameter eine Schwellenwertabweichung zwischen Startzeiten spezifizieren, in der alle Zeiten als „dieselbe“ Zeit betrachtet werden. Diese Abweichung könnte zum Beispiel auf 10 Minuten eingestellt werden, so dass alle Startvorgänge innerhalb von 10 Minuten voneinander als Basis für eine Empfehlung berücksichtigt werden. Diese Parameter könnten ebenfalls spezifizieren, wie die genaue Startzeit bestimmt wird, zum Beispiel indem ein Mittel oder eine mittlere Zeit für die beobachteten Startzeiten errechnet wird. Es können beliebige andere geeignete Parameter verwendet werden, die sich zum Beobachten von Startzeiten und Bereitstellen von Empfehlungen eignen.
  • Die beobachteten Startzeiten können mit den geladenen Parametern verglichen werden 309, um zu bestimmen, ob eine Übereinstimmung festgestellt wurde, die den eingestellten Kriterien entspricht 311. Wenn eine geeignete Übereinstimmung festgestellt wird, kann der Prozess einen Startzeitplan für den Benutzer auf der Basis der Kriterien erzeugen 313. Der Startzeitplan kann auf einigen oder allen beobachteten Startzeiten und/oder auf tatsächlichen Zeiten aufbauen, zu denen das Fahrzeug genutzt wurde. Wenn das Fahrzeug zum Beispiel jeden Tag zwischen 5 Uhr 40 und 5 Uhr 55 gestartet und jeden Tag um 6 Uhr genutzt wird, kann der Prozess die Startzeit auf die übereinstimmende Nutzungszeit stützen anstatt auf abweichende. In anderen Fällen können die Startzeiten die den tatsächlichen Startzeiten basieren.
  • Der so erstellte Startzeitplan kann dem Fahrzeug gesendet werden 315, um dem Benutzer angeboten und vom Fahrzeugsystem übernommen zu werden. Der Prozess kann danach auf eine Antwort vom Fahrzeug warten 317. So wie beim Warten im Fahrzeug, kann der Prozess nach einer Wartezeit enden, wenn keine Antwort empfangen wird. Wenn dagegen eine Antwort empfangen wird, kann der Prozess auch eine Aktualisierung einschließlich beispielsweise des Zeitplans vom Fahrzeug empfangen 319. Der Prozess kann dann ebenfalls den entfernten Speicher mit den empfangenen Informationen aktualisieren, wodurch dem entfernten Speicher ermöglicht wird, den für das Fahrzeug eingestellten Zeitplan zu verfolgen.
  • 4 zeigt einen veranschaulichenden fahrzeugseitigen Prozess, um das Ändern eines Zeitplans zu empfehlen. Hinsichtlich der in dieser Figur beschriebenen veranschaulichenden Ausführungsformen wird angemerkt, dass ein Universalprozessor vorübergehend als ein Spezialprozessor für den Zweck aktiviert werden kann, einige oder alle der hierin gezeigten beispielhaften Verfahren auszuführen. Wenn Code ausgeführt wird, der Anweisungen zum Ausführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend bis zu jenem Zeitpunkt, an dem das Verfahren abgeschlossen ist, zu einem Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann, in geeignetem Maß, Firmware, die gemäß einem vorkonfigurierten Prozessor funktioniert, bewirken, dass der Prozessor als ein Spezialprozessor funktioniert, der für den Zweck bereitgestellt wird, das Verfahren oder eine sinnvolle Variation davon auszuführen.
  • In diesem veranschaulichenden Beispiel wird der Prozess eine vorgeschlagene Anpassung für einen bereits erstellten Zeitplan bereitstellen. Änderungen an einem Zeitplan eines Benutzers können in einer beobachteten Fahrzeugnutzung resultieren, die von der Nutzung abweicht, auf welcher der Startzeitplan beruhte. Diese Änderungen können zu einem empfohlenen Zeitplan führen, der auf der Basis des abweichenden neuen Zeitplans zum neuen Zeitplan geändert wird.
  • In diesem Beispiel kann der fahrzeugeigene Prozess, nachdem die Fahrzeugstartdaten an den entfernten Server gesendet wurden, bestimmen, ob eine Änderung zu empfehlen ist 209. Wird die Änderung nicht empfohlen, kann der Prozess auch bestimmen, ob eine Änderung im Zeitplan zu empfehlen ist. Falls der Zeitplan bereits eingerichtet war und die aktuellen Nutzungen vom empfohlenen, so eingerichteten Zeitplan abwichen, kann der Prozess daraus folgernd eine Änderung eines aktuellen Zeitplans empfehlen 401.
  • Falls dies so ist, kann der Prozess die empfohlenen Änderungen am aktuellen Zeitplan vom entfernten Server empfangen 403. Wie im vorstehenden Prozess können sämtliche Bestimmungen ebenfalls durch einen lokalen Prozess statt im entfernten Server erfolgen.
  • Sobald der geänderte Zeitplan empfangen wurde, kann der Prozess einen aktuellen Zeitplan laden, der im Fahrzeug eingerichtet ist 405. Dies kann so erfolgen, dass der neue Zeitplan mit dem vorliegenden Zeitplan im Fahrzeug verglichen werden kann, um zum Beispiel zu bestimmen, ob der Benutzer den neuen Zeitplan bereits im Fahrzeug eingerichtet hat und der entfernte Server das Fahrzeug einfach nicht kannte. Solange ein Unterschied in den Zeitplänen vorliegt 407, kann der Prozess fortgesetzt werden, andernfalls kann der Prozess enden. Wie zuvor kann der Prozess prüfen, ob der Benutzer Änderungen am Zeitplan gesperrt hat 409. Hat der Benutzer Änderungen gesperrt, kann der Prozess enden.
  • Wenn der Änderungsvorschlag nicht gesperrt ist, kann der Prozess neue vorgeschlagene Startzeiten und aktuelle Zeiten (falls gewünscht) anbieten 411. Durch Anbieten sowohl neuer als auch aktueller Zeiten kann der Prozess dem Benutzer zeigen, wie der aktuelle Zeitplan aussieht und wie der neue Zeitplan aussehen wird. Wenn der Benutzer die Änderungen akzeptiert 413, kann der Prozess einen neuen Zeitplan im Fahrzeug einrichten 415. Wenn der Benutzer den Zeitplan zurückweist 413, kann der Prozess eine Option bereitstellen, den Zeitplan zu sperren.
  • Wenn sich der Benutzer entscheidet, den Zeitplan zu sperren 421, kann der Prozess einen Sperrparameter einstellen 419. Auf jeden Fall kann der Server mit den vom Benutzer ausgewählten Änderungen aktualisiert werden 417. Selbst wenn der Zeitplan nicht ausgewählt und die Sperrung nicht eingestellt wird, kann der Server immer noch mit den unveränderten Parametern eingestellt werden.
  • 5 zeigt einen veranschaulichenden serverseitigen Prozess, um das Ändern eines Zeitplans zu empfehlen. Hinsichtlich der in dieser Figur beschriebenen veranschaulichenden Ausführungsformen wird angemerkt, dass ein Universalprozessor vorübergehend als ein Spezialprozessor für den Zweck aktiviert werden kann, einige oder alle der hierin gezeigten beispielhaften Verfahren auszuführen. Wenn Code ausgeführt wird, der Anweisungen zum Ausführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend bis zu jenem Zeitpunkt, an dem das Verfahren abgeschlossen ist, zu einem Spezialprozessor umfunktioniert werden. In einem anderen Beispiel kann, in geeignetem Maß, Firmware, die in Übereinstimmung mit einem vorkonfigurierten Prozessor funktioniert, bewirken, dass der Prozessor als ein Spezialprozessor funktioniert, der für den Zweck bereitgestellt wird, das Verfahren oder eine sinnvolle Variation davon auszuführen.
  • In diesem veranschaulichenden Beispiel wird der entfernte Prozess auch bestimmen, ob eine Änderung eines aktuellen Zeitplans implementiert werden soll. Nachdem die Startdaten vom Fahrzeug empfangen wurden, prüft der Prozess, ob eine nahe bei der aktuellen Startzeit liegende Zeit eingestellt ist 501. Die Definition „naheliegend“ kann hier zum Beispiel von 45 Minuten bis zu einer Stunde betragen, das bedeutet eine große Spanne möglicher Zeitplanänderungen. Da in diesem Beispiel eine eingestellte naheliegende Zeit zu einer Überprüfung zwecks Änderung des Zeitplans führen wird, kann die Definition einer naheliegenden Zeit weit gefasst sein.
  • In anderen Beispielen können andere Überprüfungen anstatt dieser Überprüfung erfolgen, wie etwa eine Überprüfung, ob das Fahrzeug tatsächlich zu einer erwarteten Zeit verwendet wurde (und dieser Start nur zusätzlich zu dem normalen Start erfolgte). Es können auch andere geeignete Überprüfungen erfolgen, um zu bestimmen, ob bereits ein Zeitplan vorhanden ist und ob der Zeitplan zu den tatsächlich beobachteten Nutzungen passt oder nicht.
  • Wenn die aktuelle Nutzung eine Abweichung von der geplanten Nutzung zu sein scheint, kann der Prozess auf der Basis der geeigneten Tests Parameter zur Nutzung laden, um nach geeigneten Daten zur Änderung eines Zeitplans suchen. Diese Parameter können unter anderem Abweichungen definieren wie etwa Abweichungen von vorhergesehenen und tatsächlichen Nutzungszeiten, Abweichungen von Nutzungstagen und wie oft eine Abweichung beobachtet werden sollte, bevor eine Änderung vorgenommen werden sollte.
  • Die neuen beobachteten und unterschiedlichen Zeiten können mit den aktuellen vorhergesehenen Zeiten verglichen werden 505, um herauszufinden, ob den Parametern für eine Änderung entsprochen wird 507. Wird den Parametern entsprochen, kann der Prozess einen neuen Zeitplan erzeugen 509. Der neue Zeitplan, der eine Abänderung des aktuellen Zeitplans sein kann, wird danach an das Fahrzeug gesendet 511.
  • Der Prozess wartet dann auf eine Antwort vom Fahrzeug 513. Wenn keine Antwort vom Fahrzeug empfangen wird, kann der Prozess weiter warten. Andernfalls empfängt der Prozess eine Antwort vom Fahrzeug und empfängt alle Aktualisierungen, die vom Fahrzeug gesendet werden 515. Die an das Fahrzeug gesendeten Aktualisierungen können dann verwendet werden, um einen entfernten Zeitplan in Übereinstimmung mit den empfangenen Aktualisierungen zu aktualisieren.
  • Obwohl vorstehend beispielhafte Ausführungsformen beschrieben werden, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in dieser Spezifikation verwendeten Ausdrücke lediglich Ausdrücke beschreibender Art und beinhalten keinerlei Einschränkung. Es ist einzusehen, dass verschiedene Änderungen vorgenommen werden können, ohne das Wesen und den Schutzbereich der Erfindung zu verlassen. Zusätzlich können die Merkmale von verschiedenen Implementierungsausführungen 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 Patentliteratur
    • US 7542827 [0003]
    • US 8489085 [0004]
  • Zitierte Nicht-Patentliteratur
    • IEEE 802 PAN [0022]
    • IEEE 802 LAN [0022]
    • IEEE 1394 [0025]
    • IEEE 1284 [0025]
    • IEEE 803.11 [0027]

Claims (7)

  1. System, das umfasst: einen Prozessor, der dafür ausgelegt ist: Fahrzeugstartzeiten zu protokollieren; zu bestimmen, ob zeitliche Übereinstimmungen zwischen Fällen protokollierter Fahrzeugstartzeiten vorhanden sind; auf der Basis einer Schwellenwertzahl zeitlicher Übereinstimmungen einen automatischen Fahrzeugstart zu empfehlen; empfohlene Startzeiten auf der Basis von Fällen protokollierter Fahrzeugstartzeiten mit zeitlichen Übereinstimmungen zu formulieren; einem Fahrzeugnutzer einen Zeitplan einschließlich empfohlener Startzeiten anzubieten; und automatische Fahrzeugstarts zu planen, nachdem der Fahrzeugnutzer den angebotenen Zeitplan akzeptiert hat.
  2. System nach Anspruch 1, wobei die Übereinstimmungen durch Parameter einschließlich wenigstens eines Parameters definiert werden, der die maximalen Unterschiede zwischen protokollierten Fahrzeugstartzeiten definiert.
  3. System nach Anspruch 2, wobei die Parameter wenigstens die Schwellenwertzahl zeitlicher Übereinstimmungen aufweisen.
  4. System nach Anspruch 3, wobei die Parameter durch einen Erstausrüster definiert sind.
  5. System nach Anspruch 3, wobei die Parameter benutzerdefiniert sind.
  6. System nach Anspruch 1, wobei der Prozessor dafür ausgelegt ist, das Anbieten des Zeitplans über eine Fahrzeugschnittstelle anzuordnen.
  7. System nach Anspruch 1, wobei die Startinformationen Fernstartinformationen aufweisen.
DE102015208709.3A 2014-05-14 2015-05-11 Verfahren und vorrichtung zum zeitlichen planen des fahrzeugstarts Pending DE102015208709A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/277,145 US10328873B2 (en) 2014-05-14 2014-05-14 Method and apparatus for scheduling vehicle startup
US14/277,145 2014-05-14

Publications (1)

Publication Number Publication Date
DE102015208709A1 true DE102015208709A1 (de) 2015-11-19

Family

ID=54361893

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102015208709.3A Pending DE102015208709A1 (de) 2014-05-14 2015-05-11 Verfahren und vorrichtung zum zeitlichen planen des fahrzeugstarts

Country Status (3)

Country Link
US (1) US10328873B2 (de)
CN (1) CN105094796B (de)
DE (1) DE102015208709A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2735117C2 (ru) * 2017-05-17 2020-10-28 Дир Энд Компани Система и способ запуска рабочего транспортного средства с циклической работой двигателя

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9834235B2 (en) * 2014-10-28 2017-12-05 Electro-Motive Diesel, Inc. System for remotely overriding locomotive controls
US10539110B2 (en) * 2017-02-20 2020-01-21 Ford Global Technologies, Llc Vehicle battery reporting and auto-charge
KR20180099187A (ko) * 2017-02-28 2018-09-05 주식회사 가린시스템 차량용 공조기 제어 시스템 및 방법
JP2018178852A (ja) * 2017-04-12 2018-11-15 トヨタ自動車株式会社 リモート始動システム、センタサーバ
US11623657B2 (en) 2019-10-16 2023-04-11 Nuro, Inc. Remote startup of autonomous vehicles
US11438837B2 (en) 2019-10-31 2022-09-06 Itron, Inc. Downlink event allocation in a network
US11363532B2 (en) 2019-10-31 2022-06-14 Itron, Inc. Downlink event allocation in a network

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7542827B2 (en) 2004-10-12 2009-06-02 Temic Automotive Of North America, Inc. Scheduling remote starting of vehicle
US8489085B2 (en) 2010-04-14 2013-07-16 Dei Headquarters, Inc. Remote vehicle start system with advance dynamic scheduling system

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5894912A (en) 1997-04-17 1999-04-20 Steven L. Dobben Trust Wheelchair braking device
US6028372A (en) * 1998-02-18 2000-02-22 Designtech International, Inc. Daily start operation for remote vehicle starters
US6351703B1 (en) * 2000-06-06 2002-02-26 Detroit Diesel Corporation Engine control with programmable automatic starting
CN101533329A (zh) * 2008-03-10 2009-09-16 中兴通讯股份有限公司 具备自动执行操作功能的终端设备及执行用户操作的方法
CN101964148B (zh) * 2009-07-24 2013-06-19 日立(中国)研究开发有限公司 道路交通信息记录服务器和gps用户终端
US8543318B2 (en) 2010-06-01 2013-09-24 GM Global Technology Operations LLC Controlled engine shutdown system for a stop-start system and a hybrid electric vehicle
EP2460864B1 (de) 2010-11-29 2013-07-03 Nitto Europe N.V Dienophilmodifizierte Fettsäurezusammensetzung und Klebstoff
US9104537B1 (en) * 2011-04-22 2015-08-11 Angel A. Penilla Methods and systems for generating setting recommendation to user accounts for registered vehicles via cloud systems and remotely applying settings
US9215274B2 (en) * 2011-04-22 2015-12-15 Angel A. Penilla Methods and systems for generating recommendations to make settings at vehicles via cloud systems
US9181895B2 (en) 2012-03-01 2015-11-10 Johnson Controls Technology Company Start-stop retrofit systems and methods
US8779947B2 (en) * 2012-04-05 2014-07-15 GM Global Technology Operations LLC Vehicle-related messaging methods and systems
CN103359052B (zh) 2012-04-06 2016-03-30 比亚迪股份有限公司 车辆、车用智能钥匙装置、车辆遥控驾驶系统及方法
CN103770742B (zh) * 2012-10-26 2015-09-02 广州汽车集团股份有限公司 一种远程控制车辆的方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7542827B2 (en) 2004-10-12 2009-06-02 Temic Automotive Of North America, Inc. Scheduling remote starting of vehicle
US8489085B2 (en) 2010-04-14 2013-07-16 Dei Headquarters, Inc. Remote vehicle start system with advance dynamic scheduling system

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
IEEE 1284
IEEE 1394
IEEE 802 LAN
IEEE 802 PAN
IEEE 803.11

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2735117C2 (ru) * 2017-05-17 2020-10-28 Дир Энд Компани Система и способ запуска рабочего транспортного средства с циклической работой двигателя

Also Published As

Publication number Publication date
CN105094796B (zh) 2019-11-19
US10328873B2 (en) 2019-06-25
US20150330318A1 (en) 2015-11-19
CN105094796A (zh) 2015-11-25

Similar Documents

Publication Publication Date Title
DE102015208709A1 (de) Verfahren und vorrichtung zum zeitlichen planen des fahrzeugstarts
DE102015201448A1 (de) Verfahren und Gerät für bleibende übertragbare persönlich anpassbare Fahrzeugeinstellungen
DE102015201447A1 (de) Verfahren und Vorrichtung für Biometrische Fahrzeugaktivierung
DE102014204222A1 (de) Verfahren und vorrichtung für die umprogrammierung mehrerer fahrzeugsoftwaremodule
DE102016106057A1 (de) Systeme und verfahren für mobiltelefon-schlüsselanhängermanagement
DE102015116703A1 (de) Verfahren und Systeme zur Aktualisierung eines Fahrzeugdatenverarbeitungssystems
DE102015206639A1 (de) Fahrzeuginterne Wohnhaus-Automation-Integration
DE112017004311T5 (de) Bordeigene Aktualisierungsvorrichtung und bordeigenes Aktualisierungssystem
DE102017117294A1 (de) Verfahren und vorrichtung zur verwendung eines digitalen temporären fahrzeugschlüssels
DE102015119826A1 (de) Verfahren und Systeme für ein Fahrzeugcomputersystem zur Kommunikation mit einem Gerät
DE102015206255A1 (de) Fernprogrammiertes schlüsselloses fahrzeugzugangssystem
DE102014225061A1 (de) Gemeinsame Nutzung eines Schlüssels für ein Fahrzeug
DE102015219463A1 (de) System und verfahren, um valet-anweisungen für ein selbstfahrendes fahrzeug bereitzustellen
DE102017101438A1 (de) Verfahren und Einrichtung zum sicheren Verarbeiten von Kraftstofflieferanforderungen
DE102013216055A1 (de) Verfahren und Vorrichtungen für Fahrzeugrechensystem-Softwareaktualisierungen
DE102015214891A1 (de) Elektronisches Schlüsselsystem zum Verwalten eines elektronischen Fahrzeugschlüssels
DE102015107189A1 (de) Modulschnittstelle für Fahrzeugaktualisierungen
DE102016105400A1 (de) Verfahren und systeme zur konfiguration eines fahrzeugmerkmals
DE102014204225A1 (de) Schlüsselanhänger-sicherheitskopie auf ein mobiltelefon
DE102018103209A1 (de) Verfahren und vorrichtung zur handhabung der übereinstimmung von mehrzyklischen fahrzeugsoftwareaktualisierungen
DE102014204882A1 (de) System für einen biometrischen Zugang zu einem Fahrzeug und Personalisierung
DE102014217407A1 (de) Verfahren und Einrichtung für ein Borddiagnose-Schnittstellenwerkzeug
DE102018129088A1 (de) Verfahren und vorrichtung zur drahtlosen valet-schlüsselkonfiguration und -übersendung
DE102019106885A1 (de) Verfahren und Einrichtung zur selektiven Fahrmodusaktivierung
DE102015209680A1 (de) Fahrzeugintegration eines smartgerätes

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: PATERIS THEOBALD ELBEL & PARTNER, PATENTANWAEL, DE

Representative=s name: PATERIS THEOBALD ELBEL FISCHER, PATENTANWAELTE, DE

R084 Declaration of willingness to licence