DE102013221045A1

DE102013221045A1 - Verfahren und Vorrichtung für die Fahrzeugzustandssteuerung

Info

Publication number: DE102013221045A1
Application number: DE201310221045
Authority: DE
Inventors: David Perner
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2012-10-22
Filing date: 2013-10-17
Publication date: 2014-04-24
Also published as: US9125028B2; CN103781034A; US20140114499A1

Abstract

Ein System enthält einen Prozessor, der konfiguriert ist, von einer entfernten Vorrichtung eine Textnachricht zu empfangen, die eine Anweisung für ein Fahrzeugsystem enthält. Der Prozessor ist außerdem konfiguriert, ein spezifisches Fahrzeug zu bestimmen, das der entfernten Vorrichtung zugeordnet ist. Ferner ist der Prozessor konfiguriert, die Anweisung als eine Textnachricht an ein Telephon zu senden, das für das spezifische Fahrzeug bereitgestellt ist, das der entfernten Vorrichtung zugeordnet ist. Der Prozessor ist außerdem konfiguriert, die Bestätigung von dem Fahrzeug zu empfangen, dass die Anweisung verarbeitet worden ist, und einen Bestätigungstext an die entfernte Vorrichtung zu senden.

Description

Die veranschaulichenden Ausführungsformen beziehen sich im Allgemeinen auf Verfahren und Vorrichtungen für die Fahrzeugzustandssteuerung.
Die Fernsteuerung der Fahrzeugoptionen ist lange ein Merkmal gewesen, das durch die Fahrzeuganwender gewünscht wird. Schlüsselanhänger stellen eine Gelegenheit dar, Türen zu entriegeln, Kofferräume zu öffnen und sogar die Fahrzeuge fernzustarten. In vielen Fällen begrenzt jedoch die Anzahl der Tasten an einem Schlüsselanhänger die Funktionalität. Weil eine große Vorrichtung erforderlich sein würde, um eine Anzahl von Tasten bereitzustellen, ist eine typische Fernsteuerung auf einige häufige Merkmale begrenzt.
Die Verfügbarkeit von Zellentelephonen mit interaktiven Anzeigen hat neue Wege zum Erweitern der Steuerung von Fahrzeugen bereitgestellt. Es sind Schnittstellen vorgeschlagen worden, die es einem Anwender erlauben, eine Berührungsschirm-Anzeige zu verwenden, um eine Anzahl von Fahrzeugeinstellungen durch die Verwendung einer Anwendung, die in einem Telephon ausgeführt wird, das mit einem Fahrzeug kommuniziert, fernzusteuern. Leider besitzt nicht jeder ein Telephon, das zu einer derartigen Wechselwirkung imstande ist, wobei aber sogar relativ stark vereinfachte Telephone im Allgemeinen weit leistungsfähiger als ein typischer Schlüsselanhänger sind.
Die US-Patentanmeldung 2008/0287151 bezieht sich im Allgemeinen auf ein System, das die Kommunikation zwischen einer drahtlosen Mobilkommunikationsvorrichtung, wie z. B. einem Zellentelephon, und einer Vermögens-Überwachungsvorrichtung unter Verwendung eines Textnachrichtenprotokolls, wie z. B. des Kurznachrichtendienstes (SMS), ermöglicht. In die drahtlose Mobilvorrichtung wird eine Befehlstextnachricht eingegeben, die eine Seriennummer der Vermögens-Überwachungsvorrichtung, eine PIN und einen Befehl für die Überwachungsvorrichtung enthält. Die Befehlstextnachricht wird über ein drahtloses Kommunikationsnetz übertragen und zu einem Diensteanbieter weitergeleitet. Nach der Validierung der Seriennummer und der PIN überträgt der Diensteanbieter einen Befehl über das drahtlose Kommunikationsnetz an die drahtlose Vermögens-Überwachungsvorrichtung. Die drahtlose Vermögens-Überwachungsvorrichtung empfängt den Befehl und führt basierend darauf eine Handlung aus. Falls der Befehl z. B. ein LOCATE-Befehl ist, überträgt die drahtlose Überwachungsvorrichtung ihren aktuellen Ort, wie z. B. in Breiten-/Längenkoordinaten. Die drahtlose Vermögens-Überwachungsvorrichtung überträgt außerdem eine Antwort, die eine abgeschlossene Handlung angibt oder angibt, dass die Handlung aus irgendeinem Grund nicht ausgeführt wurde. Der Diensteanbieter empfängt die Antwort von der Überwachungseinheit, parst die Antwort und konstruiert eine Berichtstextnachricht, die an die Mobilkommunikationsvorrichtung des Anwenders übertragen wird. Die Berichtstextnachricht wird dann auf der Mobilkommunikationsvorrichtung angezeigt.
In einer ersten veranschaulichenden Ausführungsformen enthält ein System einen Prozessor, der konfiguriert ist, von einer entfernten Vorrichtung eine Textnachricht zu empfangen, die eine Anweisung für ein Fahrzeugsystem enthält. Der Prozessor ist außerdem konfiguriert, ein spezifisches Fahrzeug zu bestimmen, das der entfernten Vorrichtung zugeordnet ist. Ferner ist der Prozessor konfiguriert, die Anweisung als eine Textnachricht an ein Telephon zu senden, das für das spezifische Fahrzeug bereitgestellt ist, das der entfernten Vorrichtung zugeordnet ist. Der Prozessor ist außerdem konfiguriert, die Bestätigung von dem Fahrzeug zu empfangen, dass die Anweisung verarbeitet worden ist, und einen Bestätigungstext an die entfernte Vorrichtung zu senden.
In einer zweiten veranschaulichenden Ausführungsform enthält ein System einen Prozessor, der konfiguriert ist, von einem entfernten Server eine Textnachricht zu empfangen, die eine Anweisung für ein Fahrzeugsystem enthält. Der Prozessor ist außerdem konfiguriert, auf ein in der Textnachricht spezifiziertes Fahrzeugsystem zuzugreifen. Der Prozessor ist ferner konfiguriert, eine Handlung bezüglich des Fahrzeugsystems auszuführen, wie es in der Textnachricht spezifiziert ist. Der Prozessor ist außerdem konfiguriert, dem entfernten Server mit einer Bestätigung der Handlung zu antworten.
In einer dritten veranschaulichenden Ausführungsform enthält ein computerimplementiertes Verfahren das Empfangen einer Textnachricht an einem Fahrzeugcomputersystem (VCS) von einem entfernten Server, die eine Anweisung für ein Fahrzeugsystem enthält. Das Verfahren enthält außerdem das Zugreifen auf ein in der Textnachricht spezifiziertes Fahrzeugsystem über das VCS. Das Verfahren enthält ferner das Ausführen einer Handlung bezüglich des Fahrzeugsystems, wie es in der Textnachricht spezifiziert ist. Das Verfahren enthält außerdem, dem entfernten Server mit einer Bestätigung der Handlung zu antworten.
1 zeigt ein veranschaulichendes Beispiel eines Fahrzeugcomputersystems;
2 zeigt ein veranschaulichendes Beispiel eines Prozesses zum Zuordnen eines Telephons zu einem Fahrzeug in einem entfernten Konto;
3 zeigt ein veranschaulichendes Beispiel eines Abfrageprozesses;
4 zeigt ein veranschaulichendes Beispiel eines Einstellungsprozesses; und
5 zeigt ein veranschaulichendes Beispiel eines Einstelloptions-Zustellungsprozesses.
Wie erforderlich werden die ausführlichen Ausführungsformen der vorliegenden Erfindung hier offenbart; es ist jedoch selbstverständlich, dass die offenbarten Ausführungsformen für die Erfindung lediglich beispielhaft sind, die in verschiedenen und alternativen Formen verkörpert sein kann. Die Figuren sind nicht notwendigerweise maßstabsgerecht; wobei einige Merkmale übertrieben oder minimiert sein können, um die Einzelheiten spezieller Komponenten zu zeigen. Deshalb sind die hier offenbarten spezifischen strukturellen und funktionalen Einzelheiten nicht als einschränkend zu interpretieren, sondern lediglich als eine repräsentative Grundlage, um einem Fachmann auf dem Gebiet zu lehren, die vorliegende Erfindung verschieden zu verwenden.
1 veranschaulicht eine Beispiel-Blocktopologie für ein fahrzeugbasiertes Computersystem 1 (VCS) für ein Fahrzeug 31. Ein Beispiel eines derartigen fahrzeugbasierten Computersystems 1 ist das durch THE FORD MOTOR COMPANY hergestellte SYNC-System. Ein mit einem fahrzeugbasierten Computersystem befähigtes Fahrzeug kann eine visuelle "Frontend"-Schnittstelle 4 enthalten, die sich in dem Fahrzeug befindet. Der Anwender kann außerdem imstande sein, mit der Schnittstelle in Wechselwirkung zu treten, falls sie z. B. mit einem berührungsempfindlichen Schirm versehen ist. In einer weiteren veranschaulichenden Ausführungsform findet die Wechselwirkung durch das Drücken von Tasten und ein natürlichsprachliches System mit automatischer Spracherkennung und Sprachsynthese statt.
In der in 1 gezeigten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 wenigstens einen Teil des Betriebs des fahrzeugbasierten Computersystems. Der Prozessor, der innerhalb des Fahrzeugs bereitgestellt ist, erlaubt die bordinterne Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit einem nicht permanenten Speicher 5 als auch mit einem permanenten Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der nicht permanente Speicher ein Schreib-Lese-Speicher (RAM), während der permanente Speicher ein Festplattenlaufwerk (HDD) oder ein Flash-Speicher ist.
Der Prozessor ist außerdem mit einer Anzahl verschiedener Eingänge versehen, die es dem Anwender erlauben, mit dem Prozessor eine Schnittstelle zu bilden. In dieser veranschaulichenden Ausführungsform sind ein Mikrophon 29, ein Hilfseingang 25 (für den Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Schirm 4, der eine Berührungsschirm-Anzeige sein kann, und ein BLUETOOTH-Eingang 15 bereitgestellt. Es ist außerdem eine Eingangswähleinrichtung 51 bereitgestellt, um es einem Anwender zu erlauben, zwischen verschiedenen Eingängen zu wechseln. Eine Eingabe sowohl in das Mikrophon als auch in den Hilfsverbinder wird durch einen Umsetzer 27 von analog in digital umgesetzt, bevor sie zu dem Prozessor weitergeleitet wird. Obwohl dies nicht gezeigt ist, können zahlreiche Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS in Verbindung stehen, ein Fahrzeugnetz (wie z. B. einen CAN-Bus, aber nicht eingeschränkt darauf) verwenden, um Daten zu dem und von dem VCS (oder dessen Komponenten) zu leiten.
Die Ausgänge aus dem System können eine visuelle Anzeige 4 und einen Lautsprecher 13 oder einen Stereosystem-Ausgang enthalten, sind aber nicht darauf eingeschränkt. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal durch einen Digital-Analog-Umsetzer 9 von dem Prozessor 3. Die Ausgabe kann außerdem zu einer entfernten BLUETOOTH-Vorrichtung, wie z. B. einer PND 54, oder einer USB-Vorrichtung, wie z. B. einer Fahrzeugnavigationsvorrichtung 60, entlang der bidirektionalen Datenströme, die bei 19 bzw. 21 gezeigt sind, ausgeführt werden.
In einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Sender/Empfänger 15, um mit einer nomadischen Vorrichtung 53 (z. B. einem Zellentelephon, einem Smartphone, einem PDA oder irgendeiner anderen Vorrichtung, die eine Verbindbarkeit mit einem drahtlosen entfernten Netz besitzt) zu kommunizieren 17. Die nomadische Vorrichtung kann dann verwendet werden, um z. B. durch eine Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netz 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. In einigen Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
Die beispielhafte Kommunikation zwischen der nomadischen Vorrichtung und dem BLUETOOTH-Sender/Empfänger ist durch das Signal 14 dargestellt.
Die Paarbildung einer nomadischen Vorrichtung 53 und des BLUETOOTH-Senders/Empfängers 15 kann durch eine Taste 52 oder einen ähnlichen Eingang angewiesen werden. Dementsprechend wird die CPU angewiesen, dass aus dem bordinternen BLUETOOTH Sender/Empfänger und einem BLUETOOTH-Sender/Empfänger in einer nomadischen Vorrichtung ein Paar gebildet wird.
Zwischen der CPU 3 und dem Netz 61 können z. B. unter Verwendung eines Datentarifs, von Daten über Sprache oder DTMF-Tönen, die der nomadischen Vorrichtung 53 zugeordnet sind, Daten übertragen werden. Alternativ kann es erwünscht sein, dass ein bordinternes Modem 63 mit einer Antenne 18 enthalten ist, um Daten zwischen der CPU 3 und dem Netz 61 über das Sprachband zu übertragen 16. Die nomadische Vorrichtung 53 kann dann verwendet werden, um z. B. durch die Kommunikation 55 mit einem Mobilfunkmast 57 mit einem Netz 61 außerhalb des Fahrzeugs 31 zu kommunizieren. In einigen Ausführungsformen kann das Modem 63 eine Kommunikation 20 mit dem Mast 57 herstellen, um mit dem Netz 61 zu kommunizieren. Als ein nicht einschränkendes Beispiel kann das Modem 63 ein USB-Zellenmodem sein und kann die Kommunikation 20 eine Zellenkommunikation sein.
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem versehen, dass eine API enthält, um mit einer Modem-Anwendungssoftware zu kommunizieren. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder eingebettete Firmware in dem BLUETOOTH-Sender/Empfänger zugreifen, um die drahtlose Kommunikation mit einem entfernten BLUETOOTH-Empfänger (wie z. B. dem, der in einer nomadischen Vorrichtung zu finden ist) abzuschließen. Bluetooth ist eine Teilmenge der IEEE 802 PAN-Protokolle (Protokolle für persönliche Netze). Die IEEE 802 LAN-Protokolle (Protokolle für lokale Netze) enthalten WiFi und besitzen eine beträchtliche Kreuzfunktionalität mit dem IEEE 802 PAN. Beide sind für die drahtlose Kommunikation innerhalb eines Fahrzeugs geeignet. Weitere Kommunikationsmittel, die in diesem Bereich verwendet werden können, sind die optische Freiraumkommunikation (wie z. B. IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
In einer weiteren Ausführungsform enthält die nomadische Vorrichtung 53 ein Modem für die Sprachband- oder die Breitband-Datenkommunikation. In der Daten-über-Sprache-Ausführungsform kann eine Technik, die als Frequenzmultiplex bekannt ist, implementiert sein, wobei der Eigentümer der nomadischen Vorrichtung über die Vorrichtung sprechen kann, während Daten übertragen werden. Zu anderen Zeiten, wenn der Eigentümer die Vorrichtung nicht verwendet, kann die Datenübertragung die gesamte Bandbreite (300 Hz bis 3,4 kHz in einem Beispiel) verwenden. Während das Frequenzmultiplex für die analoge Zellenkommunikation zwischen dem Fahrzeug und dem Internet üblich sein kann und immer noch verwendet wird, ist sie größtenteils durch Hybride des Codemultiplex (CDMA), des Zeitmultiplex (TDMA) und des Raummultiplex (SDMA) für die digitale Zellenkommunikation ersetzt worden. Diese sind alle ITU IMT-2000-(3G-)konforme Standards und bieten Datenraten bis zu 2 Mbit/s für stationäre oder gehende Anwender und 385 kbit/s für Anwender in einem sich bewegenden Fahrzeug. Die 3G-Standards werden nun durch den IMT-Advanced (4G) ersetzt, der 100 Mbit/s für Anwender in einem Fahrzeug und 1 Gbit/s für stationäre Anwender bietet. Falls der Anwender einen Datentarif besitzt, der der nomadischen Vorrichtung zugeordnet ist, ist es möglich, dass der Datentarif die Breitbandübertragung erlaubt und das System eine viel breitere Bandbreite verwenden könnte (die die Datenübertragung beschleunigt). In einer noch weiteren Ausführungsform ist die nomadische Vorrichtung 53 durch eine (nicht gezeigte) Zellenkommunikationsvorrichtung ersetzt, die in dem Fahrzeug 31 installiert ist. In einer noch weiteren Ausführungsform kann die ND 53 eine Vorrichtung eines drahtlosen lokalen Netzes (LAN) sein, die z. B. (und ohne Einschränkung) zur Kommunikation über ein 802.11g-Netz (d. h. WiFi) oder ein WiMax-Netz imstande ist.
In einer Ausführungsform können die ankommenden Daten über Daten-über-Sprache oder einen Datentarif durch die nomadische Vorrichtung, durch einen bordeigenen BLUETOOTH-Sender/Empfänger und in den internen Prozessor 3 des Fahrzeugs geleitet werden. In dem Fall bestimmter temporärer Daten können die Daten z. B. in der HDD oder anderen Speichermedien 7 bis zu einem derartigen Zeitpunkt gespeichert sein, zu dem die Daten nicht länger benötigt werden.
Zusätzliche Quellen, die mit dem Fahrzeug eine Schnittstelle bilden können, enthalten eine persönliche Navigationsvorrichtung 54, die z. B. eine USB-Verbindung 56 und/oder eine Antenne 58 besitzt, eine Fahrzeugnavigationsvorrichtung 60, die eine USB- 62 oder eine andere Verbindung besitzt, eine bordeigene GPS-Verbindung 24 oder ein (nicht gezeigtes) Fernnavigationssystem, das eine Verbindbarkeit mit dem Netz 61 besitzt. Der USB ist einer von einer Klasse serieller Vernetzungsprotokolle. IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), serielle EIA-Protokolle (Verband der Elektronikindustrie), IEEE 1284 (Centronics-Port), S/PDIF (digitales Zusammenschaltungsformat von Sony/Philips) und USB-IF (Forum der USB-Implementierer) bilden das Rückgrat der seriellen Vorrichtung-Vorrichtung-Standards. Die meisten der Protokolle können entweder für die elektrische oder für die optische Kommunikation implementiert sein.
Ferner könnte die CPU mit verschiedenen anderen Hilfsvorrichtungen 65 in Verbindung stehen. Diese Vorrichtungen können durch eine drahtlose 67 oder eine verdrahtete 69 Verbindung angeschlossen sein. Die Hilfsvorrichtung 65 kann z. B. persönliche Medienplayer, drahtlose medizinische Vorrichtungen, tragbare Computer und dergleichen enthalten, ist aber nicht darauf eingeschränkt.
Außerdem oder alternativ könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73, z. B. unter Verwendung eines WiFi-(IEEE 803.11) Senders/Empfängers 71, verbunden sein. Dies könnte es der CPU erlauben, sich im Bereich des lokalen Routers 73 mit entfernten Netzen zu verbinden.
Zusätzlich zu den beispielhaften Prozessen, die durch ein Fahrzeugcomputersystem, das sich in einem Fahrzeug befindet, ausgeführt werden, können in bestimmten Ausführungsformen die beispielhaften Prozesse durch ein Computersystem ausgeführt werden, das mit einem Fahrzeugcomputersystem in Verbindung steht. Ein derartiges System kann eine drahtlose Vorrichtung (z. B. und ohne Einschränkung ein Mobiltelephon) oder ein entferntes Computersystem (z. B. und ohne Einschränkung einen Server), das durch die drahtlose Vorrichtung angeschlossen ist, enthalten, ist aber nicht darauf eingeschränkt. Derartige Systeme können gemeinsam als dem Fahrzeug zugeordnete Computersysteme (VACS) bezeichnet werden. In bestimmten Ausführungsformen können spezielle Komponenten des VACS in Abhängigkeit von der speziellen Implementierung des Systems spezielle Abschnitte eines Prozesses ausführen. Wenn ein Prozess beispielhaft und nicht als Einschränkung einen Schritt des Sendens oder des Empfangens von Informationen zu bzw. von einer ein Paar bildenden drahtlosen Vorrichtung besitzt, dann ist es wahrscheinlich, dass die drahtlose Vorrichtung den Prozess nicht ausführt, weil die drahtlose Vorrichtung die Informationen nicht an sich selbst bzw. von sich selbst "senden und empfangen" würde. Ein Durchschnittsfachmann auf dem Gebiet erkennt, dass es ungeeignet ist, ein spezielles VACS auf eine gegebene Lösung anzuwenden. In allen Lösungen wird in Betracht gezogen, dass wenigstens das Fahrzeugcomputersystem (VCS), das sich in dem Fahrzeug selbst befindet, die beispielhaften Prozesse ausführen kann.
Es sind verschiedene Lösungen vorgeschlagen worden, um das Bilden einer Schnittstelle mit einem Smartphone und einem Fahrzeugcomputersystem zu erlauben. Unter Verwendung der Kommunikation zwischen einem Telephon mit einer visuellen Schnittstelle und einem Fahrzeugcomputersystem würden die Prozesse oft eine visuelle Anzeige der Telephonoptionen darstellen, wobei dann die Verwendung des Smartphones die Befehle und die Auswahlen aus den Menüs für die Implementierung in einem Fahrzeug zu einem Fahrzeugcomputersystem übertragen würde. Dies umfasst typischerweise sowohl die Verwendung eines Datentarifs, um Daten zwischen einem Telephon und einem Fahrzeug zu übertragen, als auch ferner die Verwendung einer visuellen Anzeige auf einem Telephon, das ein Menü bereitstellt.
In den obigen Fällen könnten die Daten, wenn eine Verbindung zwischen einem Telephon und einem Fahrzeug hergestellt werden könnte, für die Implementierung direkt zu einem Fahrzeug übertragen werden. Um eine derartige Lösung zu implementieren, muss ein Anwender selbstverständlich sowohl ein Smartphone als auch einen Datentarif besitzen, die für die Verwendung verfügbar sind. Während dies zunehmend üblich geworden ist, gibt es immer noch zahlreiche Bereiche, die eine geringe Datenverfügbarkeit besitzen, und es gibt immer noch eine große Anzahl von Menschen, denen Smartphones und/oder Telephone mit passenden Schnittstellen fehlen, um eine vollständig funktionierende Anwendung bereitzustellen, die die Fahrzeugsteueroptionen bereitstellen kann.
Die veranschaulichenden Ausführungsformen schlagen eine Lösung vor, um die einigen der Smartphone + Datentarif-Lösungen zugeordneten strengeren Anforderungen zu lockern. Unter Verwendung der veranschaulichenden Ausführungsformen können die Anwender, denen die Smartphonefähigkeit und/oder der Zugang zu einem Datentarif fehlt, trotzdem ein Telephon, um mit einem Fahrzeugcomputersystem zu kommunizieren, und die Steuermerkmale, wie sie durch einen Hersteller und/oder einen Anwendungsentwickler erlaubt sind, verwenden.
Im Allgemeinen wird in den vorgeschlagenen Ausführungsformen die Textnachrichtenübermittlung als ein "Proxy" für die Datenübertragung zu dem und von dem Fahrzeug über einen Datentarif verwendet. Weil die Textnachrichtenübermittlung oft in den Bereichen verfügbar ist, in denen ein herkömmlicherer Datentarif nicht verfügbar ist, kann diese einen viel umfassenderen Bereich der geographischen Gebiete bereitstellen, in denen die Telephonsteuerung der Fahrzeugoptionen implementiert sein kann. In wenigstens einigen Ausführungsformen werden die Texte direkt an einen Server gesendet, über den ein Telephon mit einem Fahrzeug verbunden ist. Der Server kann dann einen Text-"Feed" zu dem und von dem Fahrzeug übertragen und eine Kommunikation mit dem Fahrzeug bereitstellen.
Selbst in dem Fall, in dem eine Smartphone-Anwendung verwendet wird, kann dieses System eine Redundanzschicht bereitstellen, wenn kein Datentarif verfügbar ist. In einer Ausführungsform kann der Anwender tatsächlich einen Befehl im Befehlszeilenstil eingeben, wie z. B. <window_state = closed> oder <vehicle_temperature = 75>. Dies könnten beispielhafte Fälle der Befehle sein, irgendwelche offenen Fenster zu schließen oder die Fahrzeugtemperatur auf fünfundsiebzig Grad einzustellen. Diese beiden Optionen könnten in einer Anwendung, die in einem Smartphone ausgeführt wird, zugänglich sein, das zuerst versuchen kann, einen Datentarif zu verwenden, um die Befehle direkt zu dem Fahrzeug zu befördern, oder dies nicht versuchen kann. Falls die direkte Kommunikation nicht möglich ist, kann der Prozess versuchen, einen Text-"Feed" zu verwenden, um die Befehle weiterzuleiten. Weil in diesem Beispiel der Anwender auf eine Anwendungsschnittstelle zugreift, im Gegensatz dazu, einen Text einzutippen (was außerdem möglich ist), könnte die Anwendung selbst die Befehle weiterleiten.
In einem weiteren Beispiel kann der Prozess auf einfachen Textnachrichten basieren, wobei ein Anwender die Textbefehle durch einen Server über ein Konto, das zuvor zwischen einem gegebenen Telephon und einem Fahrzeug gekoppelt worden ist, an das Fahrzeug senden könnte. In diesem Fall könnte der Anwender die Befehle im Befehlszeilenstil eingeben oder könnte der Anwender in einem weiteren Beispiel "Klartext"-Befehle eingeben, wobei der Server diese Befehle in die voraussichtlich entsprechenden Befehlszeilenbefehle für das Fahrzeug umsetzen könnte.
2 zeigt ein veranschaulichendes Beispiel eines Prozesses zum Zuordnen eines Telephons zu einem Fahrzeug in einem entfernten Konto. In dieser veranschaulichenden Ausführungsform wird über eine drahtlose Vorrichtung 201 auf einen entfernten Server zugegriffen. In diesem Beispiel stellt der Server die Kommunikation zwischen dem Fahrzeug und der entfernten Vorrichtung (z. B. einem Telephon, einem Tablet-PC usw.) bereit. Dem Server kann eine feste Nummer zugeordnet sein, wobei der Anwender (oder eine Anwendung, die in der Vorrichtung des Anwenders ausgeführt wird) eine Textnachricht an die feste Nummer senden kann (wodurch der Server die Nummer zu dem geeigneten Fahrzeug leiten kann).
Sobald der entfernte Server die Textnachricht empfangen hat, kann er in dieser Ausführungsform prüfen, um zu sehen, ob das aktuelle Telephon bereits einem Fahrzeug zugeordnet ist. Weil die Anforderung für das Bilden eines Paares mit einem neuen Telephon ist, wird in diesem Fall das Telephon keinem Fahrzeug zugeordnet, wobei der Server zuerst ein Konto erzeugen kann, das die ankommende Mobilnummer (oder einen anderen geeigneten Identifizierer) erkennt. Sobald diese erste Hälfte des Bildens eines Paares erzeugt worden ist, kann der Anwender einen Fahrzeugidentifizierer für das Bilden eines Paares mit dem Fahrzeug eingeben. Dies kann z. B. eine Fahrzeugidentifikationsnummer (VIN), die Nummer eines für das Fahrzeug bereitgestellten (im Fahrzeug angebrachten) Mobiltelephons, an das die Nachrichten gesendet werden können, oder sogar nur ein Identifizierer des Eigentümers, der auf eine gespeicherte Datei verweist, um zu sehen, welches Fahrzeug zu diesem Eigentümer gehört, sein.
In dem Fall, in dem eine Mobiltelephonnummer des Fahrzeugs verwendet wird, kann es nicht erforderlich sein, dass zusätzliche Informationen erfasst werden, obwohl es in einigen Fällen ferner erwünscht sein könnte, ein sekundäres Erlaubnisniveau zu erhalten. Der Anwender kann z. B. in wenigstens einem Fall sich bei einer Webseite explizit anmelden und eine Mobiltelephonnummer und ein spezielles Fahrzeug in Wechselbeziehung bringen müssen. Dies schafft einen Grad des Kennwort- und Anmeldeschutzes für den Zuordnungsprozess. Insbesondere in den Fällen, in denen die Kommunikationen verwendet werden, um Fenster zu öffnen/zu schließen, ein Fahrzeug zu starten (z. B. für eine Temperaturänderung) oder anderweitig einen möglichen Zugriff auf und/oder Leistung für ein Fahrzeug bereitzustellen, kann es erwünscht sein, dass es erforderlich ist, dass ein Anwender aus dem Telephon und dem Fahrzeug auf eine geschützte Weise ein Paar bildet.
Sobald irgendwelche geeigneten Absicherungen verwendet worden sind, kann der Server dann ein Fahrzeug einer ankommenden Anwender-ID (z. B. einer Telephonnummer) zuordnen 205. In der Zukunft können die Mobilnachrichten, die von dem Telephon, das die registrierte ID besitzt, bei dem Server eingehen, zu dem zugeordneten Fahrzeug weitergeleitet werden. In wenigstens einem Fall kann ein Telephon mehreren Fahrzeugen zugeordnet sein, wobei die Nachrichten selbst ein spezielles Fahrzeug für die Zustellung bezeichnen können. Falls das bezeichnete Fahrzeug mit einem der zugeordneten Fahrzeuge übereinstimmt, kann die Nachricht zugestellt werden.
Die anfängliche Bildung eines Paares aus dem Fahrzeug und dem Telephon kann auf mehrere Weisen erreicht werden. Eine relativ nahtlose Weise kann in einer Umgebung ausgeführt werden, bei der vorher aus dem Telephon und einem Fahrzeug über Bluetooth ein Paar gebildet worden ist. In einem derartigen Fall kann nach dem Bilden eines Paares aus dem Telephon und dem Fahrzeug beim Bilden eines Bluetooth-Paares (das voraussichtlich einen zulässigen Zugriff auf ein Fahrzeug erfordert), ein Fahrzeugcomputersystem außerdem einen Anwender hinsichtlich dessen auffordern, ob das "Bilden eines Paares mittels Text" erwünscht ist oder nicht. Falls der Anwender wünscht, aus den Vorrichtungen ein Paar zu bilden, kann der Prozess ein Signal an den entfernten Textserver senden, der die Bildung eines Paares aus der Vorrichtung und dem Fahrzeug anweist. Dies könnte verhindern, dass ein Anwender später den Prozess des Bildens eines Paares durchlaufen muss.
In einem weiteren Beispiel, bei dem das Textsystem als eine Sicherung für ein auf einem Datentarif basierendes System wirkt, kann nach der ersten Verwendung der Kommunikation im Datentarifstil zwischen dem Fahrzeug und dem Telephon eine Nachricht an den entfernten Server gesendet werden, um aus dem Telephon und dem Fahrzeug ebenfalls für die Textkommunikation ein Paar zu bilden. Falls in diesem Fall kein Datentarif verfügbar wäre, würde es sogar nicht notwendigerweise für den Anwender offensichtlich sein, dass dies der Fall wäre, da die vorher aktivierte textbasierte Verarbeitung als ein ausreichender "Proxy" für die Daten dienen könnte, wobei der Anwender nicht durch irgendwelche zusätzlichen Authentifizierungsschritte gehen müsste.
In einem noch weiteren Beispiel könnte die Kennwortübertragung (oder die Codeübertragung, die PIN-Übertragung usw.) in jedem Fall erforderlich sein, um eine robustere Form der Sicherheit vor einem und des Schutzes gegen einen Fahrzeugzugriff über ein gestohlenes oder anderweitig unerlaubtes Telephon bereitzustellen. In jedem Fall können nach einem geeigneten Prozess des Bildens eines Paares das Fahrzeug und das Telephon dem entfernten Server zugeordnet werden, so dass annehmbare ankommende Nachrichten geeignet bearbeitet werden können.
Wenn in diesem Fall die Vorrichtungen zugeordnet sind, kann der Server dann eine Liste der Optionen, die über die Textnachrichtenübermittlung gesteuert werden können, zurück zu dem Telephon leiten. Diese Optionen können in einer für den Anwender zugänglichen Datei gesichert werden und/oder können einer Anwenderanwendung bereitgestellt werden, so dass die Anwendung erkennen kann, welche Fahrzeugzustände/-funktionen für ein spezielles Fahrzeug über die Textnachrichtenübermittlung gesteuert werden können.
Die Textnachrichtenübermittlung kann sowohl für die Anweisung von Zustandsänderungen (Temperatur, Fenster, Türen, Lautstärke usw.) als auch für das Abfragen eines aktuellen Zustands eines Fahrzeugsystems (Temperatur, Fenster, Ladung/Kraftstoff usw.) verwendet werden. 3 zeigt ein veranschaulichendes Beispiel eines Abfrageprozesses, um die Informationen über einen oder mehrere Fahrzeugzustände abzurufen.
In diesem veranschaulichenden Beispiel empfängt der entfernte Server eine Anforderung von einer Mobilvorrichtung eines Anwenders, die wegen des Status irgendeines Zustands oder irgendeiner Komponente eines Fahrzeugs fragt 301. Wie vorher angegeben worden ist, kann dies die Fahrzeugtemperatur, den Türverriegelungszustand, den Fensterzustand, die verbleibende Ladung/den verbleibenden Kraftstoff usw. enthalten, ist aber nicht darauf eingeschränkt. In einigen Fällen könnte dies sogar verwendet werden, ein Fahrzeug zu überwachen, wobei Informationen, wie z. B. der Ort oder die aktuelle Geschwindigkeit, bereitgestellt werden könnten.
Sobald der Abfragetext empfangen worden ist, kann der Prozess eine bezüglich eines Fahrzeugs gespeicherte Datei prüfen, um zu sehen, ob die spezielle angeforderte Option für ein gegebenes Fahrzeug verfügbar ist 303. In einigen Fällen können bestimmte Dateien nur für bestimmte Fahrzeuge verfügbar sein, wobei eine Anwendung oder ein Anwender, die bzw. der die Daten anfordert, nicht wissen kann, dass bestimmte angeforderte Daten für das spezifische Fahrzeug, von dem die Daten angefordert worden sind, nicht verfügbar sind. Falls die Daten nicht verfügbar sind, kann der Anwender benachrichtigt werden 305, dass die angeforderten Daten für dieses Fahrzeug nicht verfügbar sind. In anderen Fällen kann der entfernte Prozess einfach die Anforderung senden und dann den Anwender benachrichtigen, falls die Daten nicht verfügbar sind, falls es der Fall ist, dass das Server-System die Datenverfügbarkeit für jedes Fahrzeug nicht verfolgt.
Falls die angeforderten Daten verfügbar sind, kann in diesem veranschaulichenden Beispiel der Prozess eine Textabfrage an das Fahrzeug senden 307. Es ist außerdem möglich, dass sich nur eine Hälfte der Anwender-/Fahrzeugkombination außerhalb eines Bereichs eines Datentarifs befindet. In einem derartigen Fall kann der Server zwischen Daten und Text umsetzen, so dass die effizienteste Verwendung der Datenübertragung erreicht werden kann. Wenn ein Anwender z. B. in einem Bereich wandert, in dem nur Textnachrichten gesendet werden dürfen, ein Fahrzeug aber in einem Bereich geparkt worden ist, in dem die Daten verfügbar sind, dann kann ein Text von dem Anwender, um eine Fahrzeugtemperatur zu prüfen, durch den Server empfangen werden, über einen Datentarif in einem geeigneten Format zu dem Fahrzeug geleitet werden, als eine Datentarifantwort durch das Fahrzeug empfangen werden und dann umgesetzt und als ein Text zurück zum Anwender geleitet werden.
Sobald die Abfrage an das Fahrzeug gesendet worden ist, kann eine Antwort (in dem geeigneten Format) empfangen werden. Das Fahrzeug könnte z. B. mit einer Textnachricht dem entfernten System antworten 309, wobei die Formatierung der Textnachricht für das Zurückleiten zu einem Anwender geeignet sein kann oder nicht. In wenigstens einem Beispiel formatiert das Fahrzeug die Textnachricht und sendet eine geeignete Antwort in einer Form, die für die Übermittlung zu einem Anwender geeignet ist, an den Server. In einem weiteren Beispiel kann das Fahrzeug unter Verwendung irgendeines Codes auf Maschinenebene oder eines anderen nicht lesbaren Codes antworten, woraufhin der Server den Code umsetzen und eine geeignete Antwort zurück an einen Anwender senden kann 311. Jedes Verfahren kann in Abhängigkeit von einer Anzahl von Faktoren, einschließlich der Menge der Arbeit, die erwünscht ist, dass sie ein Fahrzeug und/oder ein entfernter Server ausführen muss, verwendet werden.
4 zeigt ein veranschaulichendes Beispiel eines Einstellungsprozesses. In diesem veranschaulichenden Beispiel kann der Anwender versuchen, einen Zustand, eine Einstellung, ein System usw. eines Fahrzeugs zu modifizieren. Eine nicht einschränkende Menge der modifizierbaren Fahrzeugeinschränkungen enthält die Fenster, die Türen, die Temperatur, die Lautstärke, das Schiebedach, das Ein-/Ausschalten des Ladens usw., ist aber nicht darauf eingeschränkt. Was modifiziert werden kann oder nicht, kann sich außerdem bei besonderen spezifischen Fahrzeugen, Modellen, Marken usw. ändern.
In diesem veranschaulichenden Beispiel empfängt der entfernte Server eine Anforderung für eine Einstellung über einen Text von einer Mobilvorrichtung des Anwenders 401. Dies könnte abermals durch den Anwender direkt gesendet werden oder könnte sich aus einer Anwendung, die in der Mobilvorrichtung ausgeführt wird, ergeben. Außerdem könnte dies eine "Klartext"-Anforderung sein oder könnte in einer Form formatiert sein, um direkt zu einem Fahrzeug geleitet zu werden und direkt durch ein Fahrzeug nutzbar zu sein.
Wie bei der Abfrage kann der entfernte Server für ein gegebenes Fahrzeug wissen, welche Optionen für die Einstellung verfügbar sind oder nicht. In dem Fall, in dem diese Optionen bekannt sind, kann der Prozess bestimmen, ob die angeforderte Option durch einen Anwender eingestellt werden kann 403. Falls die Option nicht eingestellt werden kann, kann der Prozess einen Anwender benachrichtigen 405.
In wenigstens einer Ausführungsform kann sich die Verfügbarkeit der Optionen mit dem Typ der Kommunikation, die mit einem Fahrzeug verfügbar ist, ändern. Wenn der Server z. B. momentan mit dem Fahrzeug sowohl unter Verwendung eines Datentarifs als auch einer Textoption kommunizieren kann, dann kann der volle Bereich der Optionen verfügbar sein. Dies könnte z. B. sein, weil angenommen wird, dass, falls ein Datentarif verfügbar ist, dann die Textnachrichtenübermittlung wahrscheinlich in jedem Fall durchkommen sollte, sogar mit irgendeiner Varianz der Signalstärke. Daher kann z. B. in einem Fall, in dem der Fensterzustand auf "offen" eingestellt wird, der Prozess nur die Einstellung ohne eine Anwenderbenachrichtigung erlauben, wenn es wahrscheinlich ist, dass die Fenster ebenso leicht geschlossen werden können. In dem Fall, in dem nur die Textsignalisierung zu einem Fahrzeug verfügbar ist, kann der Prozess zuerst einen Anwender warnen, dass eine künftige Anforderung, die Fenster zu schließen, nicht verarbeitet werden kann, und eine Bestätigung fordern, um fortzufahren. In einigen Fällen kann die Verfügbarkeit der Daten wenig oder nichts mit der Stärke eines Textsignals zu tun haben, wobei diese gegenseitige Kontrolle nicht notwendig sein kann.
Falls das einzustellende System eine durchführbare Option für die Anwendereinstellung über die Textnachrichtenübermittlung ist, wie angefordert, kann der Prozess einen Einstellbefehl an das Fahrzeug senden 407. Weil eine tatsächliche Modifikation eines Zustands, eines Systems oder eines Prozesses eines Fahrzeugs usw. angefordert wird, kann es nützlich sein, es einen Anwender wissen zu lassen, dass die angeforderte Änderung erfolgreich war. In einem derartigen Fall kann der Prozess außerdem eine Bestätigung von dem Fahrzeug empfangen, dass die Einstellung erfolgreich war, 409. Nach dem Empfang der Bestätigung (oder bei einem Ausfall, die Bestätigung zu empfangen), kann der Prozess dann den Anwender mit dem geeigneten Ergebnis benachrichtigen 411.
Auf diese Weise kann der Anwender mit nicht mehr als einem textfähigen Telephon kommunizieren, um unter Verwendung der Nachrichtenübermittlung zwischen dem Telephon und dem Fahrzeug zu kommunizieren. In einer sehr einfachen Lösung können Befehlszeilenbefehle zwischen dem Telephon und dem Fahrzeug unter Verwendung eines entfernten Servers gesendet werden, der wenig mehr als eine Grundsicherheit und die Bildung von Paaren bereitstellt, wobei sogar die elementarsten Mobiltelephone mit einem minimalen Textplan verwendet werden können, um wenigstens einige Fahrzeugeinstellungen zu steuern.
In einigen Szenarios kann das textbasierte System als eine Sicherung oder sogar als ein Standard-"Backbone" einer Mobilanwendung dienen, die für die Fahrzeugsteuerung über eine Mobilvorrichtung konstruiert ist. In einem derartigen Fall kann die Mobilanwendung eine Anzahl von Optionen besitzen, die durch einen Anwendungsentwickler bereitgestellt werden. Diese Optionen könnten z. B. allen abfragbaren Optionen für die Fahrzeuge aller Hersteller (ähnlich für die einstellbaren Optionen) entsprechen. In einem derartigen Fall kann der Anwender eine spezielle Anwendung mit verschiedenen Optionen konfigurieren. Um eine anwenderfreundlichere Option anzubieten, kann es jedoch außerdem möglich sein, diese Optionen dynamisch anzubieten, so dass sich eine Anwendung in einem gegebenen Telephon selbst konfigurieren kann. Selbst wenn ein Telephon verwendbar wäre, um mehrere Fahrzeuge zu steuern, könnte eine einfache Anfrage eine Liste von Optionen anbieten, die für ein spezielles Fahrzeug verfügbar/nicht verfügbar ist, wann immer der Zugriff erwünscht wäre.
In einem nicht einschränkenden Beispiel kann dies durch eine einfache Textnachricht durch eine Kette binärer Variable, die 1 – verfügbar, 0 – nicht verfügbar für jede Option angibt, erreicht werden. Daher könnte eine Kette mit 256 Zeichen alle (aus 256) verfügbaren Optionen in einem gegebenen Fahrzeug mit nicht mehr als 0100111011001001... usw. angeben, wobei jede binäre Ziffer einer anderen Option entspricht. Falls zwischen allen von einem Hersteller hergestellten Fahrzeugen 256 oder weniger Optionen verfügbar wären, könnte auf diese Weise irgendeine Anwendung irgendwelche verfügbaren Optionen des Fahrzeugs mit einer einfachen Textnachricht bestimmen. Dieses Beispiel ist in keiner Weise als einschränkend gemeint, sondern lediglich, um die relative Einfachheit des Abfragens eines Fahrzeugs zu zeigen, um die Optionsverfügbarkeit in einem standardisierten Format zu bestimmen.
5 zeigt ein veranschaulichendes Beispiel eines Einstelloptions-Zustellungsprozesses. In diesem veranschaulichenden Beispiel wird angenommen, dass eine Anwendung eine Anforderung von einem Anwender für einen Satz abfragbarer und/oder einstellbarer Optionen für ein spezielles Fahrzeug empfangen hat 501 (oder in vielen Fällen der Anwender in diesem Schritt einfach die Anwendung aktiviert). Die Anwendung kann z. B. in einem PC oder einer Mobilvorrichtung entfernt vom Fahrzeug und dem dazwischenliegenden Server ausgeführt werden.
Sobald die Anforderung, auf die Anwendung zuzugreifen, empfangen worden ist, nimmt der Prozess mit dem dazwischenliegenden Server Verbindung auf 503. In dem Fall, in dem das Fahrzeug oder der Server eine vollständige Konfiguration zurückschicken kann, wie oben angegeben worden ist, kann der Prozess eine einfache Abfrage senden, um die Verfügbarkeit bezüglich aller Optionen zu bestimmen. In einem weiteren Fall muss der Prozess möglicherweise eine Testabfrage für einige oder alle Optionen senden und dann basierend darauf, welche verfügbar sind oder nicht, eine Liste der verfügbaren Optionen aufbauen.
Weil der Anwender z. B. die Fenster möglicherweise nicht senken und heben will, um zu bestimmen, ob dies eine verfügbare Option ist, kann in den Fällen, in denen eine Konfiguration nicht unmittelbar verfügbar ist, der Prozess einen "Nicht-Handeln"-Befehl besitzen, der für jede getestete Variable gesendet werden kann. In einem derartigen Fall kann der Server z. B. nur eine Bestätigung (z. B. die Option ist vorhanden) oder eine Ablehnung (z. B. die Option ist nicht vorhanden oder ist nicht veränderbar) jedes "Nicht-Handeln"-Befehls empfangen. Auf diese Weise können die Optionen abgefragt werden, ohne den Zustand irgendeiner Option zu ändern.
Wenn die Konfiguration von dem Server zurückgeschickt worden ist 505, kann die Anwendung dann eine Anzeige der verfügbaren Optionen zusammenstellen 507 und sie dem Anwender darstellen 509. Ob die Option einen Datentarifzugriff oder einen Textzugriff verwendet, ist hier im Wesentlichen für den Anwender transparent, weil dem Anwender die Anzeige gezeigt wird. Sobald dem Anwender die Anzeige bereitgestellt worden ist, kann der Prozess die Anwendereingabe bezüglich irgendwelcher Abfragen und/oder Anweisungen empfangen und dann dementsprechend reagieren.
Während oben beispielhafte Ausführungsformen beschrieben worden sind, ist nicht vorgesehen, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Stattdessen sind die in der Beschreibung verwendeten Wörter Wörter der Beschreibung anstatt der Einschränkung, wobei es selbstverständlich ist, dass verschiedene Änderungen ausgeführt werden können, ohne vom Erfindungsgedanken und Umfang der Erfindung abzuweichen. Außerdem können die Merkmale der verschiedenen implementierenden Ausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 20080287151 [0004]

Zitierte Nicht-Patentliteratur

IEEE 802 PAN-Protokolle [0022]
IEEE 802 LAN-Protokolle [0022]
IEEE 802 PAN [0022]
IEEE 1394 [0025]
IEEE 1284 [0025]
IEEE 803.11 [0027]

Claims

System, das Folgendes umfasst: einen Prozessor, der konfiguriert ist: von einer entfernten Vorrichtung eine Textnachricht zu empfangen, die eine Anweisung für ein Fahrzeugsystem enthält; ein spezifisches Fahrzeug zu bestimmen, das der entfernten Vorrichtung zugeordnet ist; die Anweisung als eine Textnachricht an ein Telephon zu senden, das für das spezifische Fahrzeug bereitgestellt ist, das der entfernten Vorrichtung zugeordnet ist; und die Bestätigung von dem Fahrzeug zu empfangen, dass die Anweisung verarbeitet worden ist; und einen Bestätigungstext an die entfernte Vorrichtung zu senden.
System nach Anspruch 1, wobei der Prozessor konfiguriert ist, basierend auf einer gespeicherten Paarbildung das spezifische Fahrzeug, das der entfernten Vorrichtung zugeordnet ist, zu bestimmen.
System nach Anspruch 1, wobei der Prozessor konfiguriert ist, basierend auf den mit der empfangenen Textnachricht von der entfernten Vorrichtung gesendeten Fahrzeugidentifikationsinformationen, das spezifische Fahrzeug, das der entfernten Vorrichtung zugeordnet ist, zu bestimmen.
System nach Anspruch 1, wobei die von der entfernten Vorrichtung empfangene Textnachricht in einem Klartextformat vorliegt und der Prozessor konfiguriert ist, die Textnachricht von der entfernten Vorrichtung in eine Befehlszeilensprache umzusetzen, die für die Implementierung durch ein für das Fahrzeug bereitgestelltes Fahrzeugcomputersystem geeignet ist.
System nach Anspruch 1, wobei die Bestätigung nicht in einem Klartextformat vorliegt und der Prozessor konfiguriert ist, die Bestätigung in ein Klartextformat umzusetzen.
System nach Anspruch 1, wobei die Anweisung eine Anweisung enthält, den Zustand eines Fahrzeugsystems zu ändern.
System nach Anspruch 1, wobei die Anweisung eine Abfrage bezüglich des Zustands eines Fahrzeugsystems enthält und die Bestätigung eine Antwort auf die Abfrage enthält.