DE102014202306A1

DE102014202306A1 - System und Verfahren für eine Mensch-Maschine-Schnittstelle

Info

Publication number: DE102014202306A1
Application number: DE102014202306.8A
Authority: DE
Inventors: James Stewart Rankin; Basavaraj Tonshal; Pietro Buttolo; Yifan Chen; Gary Steven Strumolo; Jeff Allen Greenberg; Dimitar Petrov Filev; Venkatesh Venkatesh Prasad
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2013-02-14
Filing date: 2014-02-07
Publication date: 2014-08-14
Also published as: US20140380240A1; US20140225724A1; CN103997510A; CN103997510B; US8866604B2

Abstract

Fahrzeugcomputersystem, das einen Funksendeempfänger umfasst, der konfiguriert ist, um eine Nomadic-Device-Mensch-Maschine-Schnittstelle an ein Nomadic Device in einem Webbrowserformat zu senden. Das Fahrzeugcomputersystem umfasst weiter einen Fahrzeugserver, der einen Kontextdatenaggregator verwendet, der Fahrzeugdaten und bordexterne Daten verwendet, um eine dynamische Mensch-Maschine-Schnittstelle zu erzeugen, wobei der Server weiter konfiguriert ist, um eine Mensch-Maschine-Schnittstelle im Fahrzeug für die Ausgabe auf einer Fahrzeuganzeige zu erzeugen und die Nomadic-Device-Mensch-Maschine-Schnittstelle für das Nomadic Device zum Anzeigen zu erzeugen.

Description

Die Ausführungsbeispiele betreffen allgemein eine Vorrichtung und ein Verfahren zum Erzeugen einer Benutzerschnittstelle in einem Fahrzeugmultimediasystem.
Unten werden einige Entertainment-Systeme nach dem Stand der Technik beschrieben. Zusätzliche Einrichtungsnutzungen dieser Systeme können aus den identifizierten Dokumenten unten erhalten und beschrieben werden.
Die US-Patentveröffentlichung 2011/0234427 beschreibt eine telemetrische Einrichtung für ein Fahrzeug, das eine Ortsbestimmungseinrichtung, die ausgelegt ist, um den Ort eines Fahrzeugs zu bestimmen, und eine Sendeeinrichtung, die ausgelegt ist, um Ortsdaten hinsichtlich des Fahrzeugs in Echtzeit oder Nahe-Echtzeit kontinuierlich oder beinahe kontinuierlich zu senden, beinhaltet. Das Senden der Ortsdaten basiert nicht auf einem Zustand des Fahrzeugs und erfolgt ohne Aufforderung durch einen Benutzer.
Die US-Patentveröffentlichung Nr. 8,204,734 beschreibt ein beispielhaftes System, das ein Entwicklungsuntersystem, das konfiguriert ist, um die Entwicklung einer Softwareanwendung zu erleichtern, und ein Simulationsuntersystem, das selektiv und kommunikativ an das Entwicklungsuntersystem gekoppelt ist, beinhaltet. Das Simulationsuntersystem ist konfiguriert, um mehrere Verarbeitungseinrichtungsplattformen zu emulieren, Daten, die repräsentativ für eine Auswahl mindestens einer der mehreren Verarbeitungseinrichtungsplattformen sind, zu empfangen und eine Ausführung der Softwareanwendung durch eine oder mehrere Verarbeitungseinrichtungen, die mit der mindestens einen ausgewählten Verarbeitungseinrichtungsplattform assoziiert sind, zu simulieren.
Die US-Patentveröffentlichung 2012/0179325 beschreibt ein innerhalb eines Fahrzeugs befindliches Informationssystem, das eine Datenspeichereinrichtung beinhaltet, die konfiguriert ist, um programmierte Anweisungen zu speichern, um einen Webbrowser, ein Datenkommunikationsmodul und einen Controller zu implementieren, der betriebsfähig an die Datenspeichereinrichtung und das Datenkommunikationsmodul gekoppelt ist, wobei der Controller konfiguriert ist, um den Webbrowser auszuführen, um mehrere Datenelemente zu empfangen, einen jeweiligen Inhaltstyp für jedes der mehreren Datenelemente zu identifizieren, jedem der mehreren Datenelemente basierend auf dem jeweiligen identifizierten Inhaltstyp einen Relevanzgrad zuzuweisen, die zugewiesene Relevanz mit einer vorher bestimmten Relevanzschwelle zu vergleichen; und eine Benutzerschnittstelle unter Nutzung mindestens eines der mehreren Datenelemente basierend auf dem Vergleich zu erzeugen.
Ein erstes Ausführungsbeispiel offenbart ein Fahrzeugcomputersystem, das einen Funksendeempfänger umfasst, der konfiguriert ist, um eine Verbindung zu einem Nomadic Device aufzubauen, wobei der Funksendeempfänger weiter konfiguriert ist, um eine Nomadic-Device-Mensch-Maschine-Schnittstelle zu senden, die für die Ausgabe auf dem Nomadic Device unter Nutzung eines ersten Webbrowserformats konfiguriert ist. Das Fahrzeugcomputersystem beinhaltet auch eine Fahrzeuganzeige, die konfiguriert ist, um eine Mensch-Maschine-Schnittstelle im Fahrzeug unter Nutzung eines zweiten Webbrowserformats zum Steuern verschiedener Fahrzeugfunktionen auszugeben, und einen Fahrzeugserver, der konfiguriert ist, um die Mensch-Maschine-Schnittstelle im Fahrzeug für die Fahrzeuganzeige zu erzeugen und die Nomadic-Device-Mensch-Maschine-Schnittstelle für das Nomadic Device zu erzeugen.
Ein zweites Ausführungsbeispiel offenbart ein bordexternes Computersystem, das einen Funksendeempfänger umfasst, der mit einem Fahrzeug und einem Server kommuniziert, der einen Kontextdatenaggregator beinhaltet, der aus dem Funksendeempfänger ausgelesene Fahrzeugdaten und bordexterne Daten verwendet, um eine dynamische Kontext-Mensch-Maschine-Schnittstelle basierend auf den Fahrzeugdaten und den bordexternen Daten in einem Webbrowserdatenformat, die unter Verwendung des Funksendeempfängers an das Fahrzeug gesendet werden soll, zu erzeugen.
Ein drittes Ausführungsbeispiel offenbart ein Fahrzeugcomputersystem, das einen Funksendeempfänger umfasst, der konfiguriert ist, um eine Nomadic-Device-Mensch-Maschine-Schnittstelle an ein Nomadic Device in einem Webbrowserformat zu senden. Das Fahrzeugcomputersystem umfasst weiter einen Fahrzeugserver, der einen Kontextdatenaggregator verwendet, der Fahrzeugdaten und bordexterne Daten verwendet, um eine dynamische Mensch-Maschine-Schnittstelle zu erzeugen, wobei der Server weiter konfiguriert ist, um eine Mensch-Maschine-Schnittstelle im Fahrzeug für die Ausgabe auf einer Fahrzeuganzeige zu erzeugen und die Nomadic-Device-Mensch-Maschine-Schnittstelle für das Nomadic Device zum Anzeigen zu erzeugen.
1 zeigt eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Computersystem für ein Fahrzeug.
2 zeigt eine beispielhafte Topologie des fahrzeugbasierten Computersystems, das mit einem cloudbasierten Server kommuniziert, der mit Kontextdatenaggregation konfiguriert ist.
3 ist ein Beispiel für die Fahrzeug-Cloud-Mensch-Maschine-Schnittstelle, die den Kontextdetektor verwendet.
4 ist ein Beispiel für ein Ablaufschema, das die Interaktion des fahrzeugbasierten Computersystems angibt.
5A ist ein Ausführungsbeispiel für eine Netzarchitektur, die verwendet wird, um eine zum Steuern eines Sitzes unter Nutzung einer mobilen Anwendung gebrauchte Fernsteuerung zu demonstrieren.
5B ist ein Ausführungsbeispiel für eine Netzarchitektur, die verschiedene Anzeigen im Fahrzeug verwendet.
6 ist ein Ausführungsbeispiel für eine Mensch-Maschine-Schnittstelle, die auf unterschiedlichen Typen von Nomadic Devices angezeigt wird.
7 veranschaulicht ein Beispiel für eine abfragebasierte MMS, die möglicherweise ein Sprachdialogsystem verwendet.
Wie erforderlich, werden hierin ausführliche Ausführungsformen der vorliegenden Erfindung offenbart; jedoch sollte es sich verstehen, dass die offenbarten Ausführungsformen für die Erfindung lediglich beispielhaft sind, die in verschiedenen und alternativen Formen ausgeführt werden kann. Die Figuren sind nicht zwingend maßstabsgetreu; einige Features sind eventuell übertrieben oder verkleinert, um Einzelheiten konkreter Komponenten zu zeigen. Deshalb dürfen spezifische Struktur- und Funktionseinzelheiten, die hierin offenbart werden, nicht als begrenzend ausgelegt werden, sondern lediglich als repräsentative Grundlage, um dem Fachmann zu lehren, wie von der vorliegenden Erfindung verschieden Gebrauch gemacht werden kann.
Die Erfindung wird nun nachfolgend mit Verweis auf die beiliegenden Zeichnungen, in denen Ausführungsformen der Erfindung gezeigt werden, umfassender beschrieben. Diese Erfindung kann jedoch in vielen unterschiedlichen Formen ausgeführt werden und ist nicht dahingehend auszulegen, dass sie auf die hierin dargelegten Ausführungsformen begrenzt ist. Gleiche Zeichen beziehen sich je auf Elemente. Wie hierin genutzt, beinhaltet der Ausdruck „und/oder“ sämtliche Kombinationen eines oder mehrerer der assoziierten aufgeführten Teile.
Viele neue Features und Funktionalitäten werden in unsere Telefone, Tablets, MP3-Player etc. integriert. Jedoch werden viele dieser Features nicht unter Beachtung der Fahrzeugumgebung entwickelt. Die zunehmende Interoperabilität mobiler Einrichtungen mit dem Computersystem eines Fahrzeugs verhilft Kunden zu einer nahtlosen Erfahrung unabhängig davon, ob sie sich in einer Fahrzeugumgebung aufhalten oder nicht. Ein veranschaulichendes Beispiel für eine nahtlose Kundenerfahrung ermöglicht einem Benutzer, eine Benutzerschnittstelle mit Bezug auf das Fahrzeug auf dem Nomadic Device eines Benutzers zu betreiben. Dadurch kann ermöglicht werden, dass ein Benutzer ein Fahrzeugcomputersystem von mehreren Einrichtungen aus und an unterschiedlichen Orten, sowohl innerhalb des Fahrzeugs als auch außerhalb des Fahrzeugs, steuert.
1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Computersystem 1 (Vehicle Based Computing System, VCS) für ein Fahrzeug 31. Ein Beispiel für ein solches fahrzeugbasiertes Computersystem 1 ist das von der FORD MOTOR COMPANY hergestellte SYNC-System. Ein mit einem fahrzeugbasierten Computersystem aktiviertes Fahrzeug enthält möglicherweise eine im Fahrzeug befindliche visuelle Front-End-Benutzerschnittstelle 4. Der Benutzer kann möglicherweise auch mit der Schnittstelle interagieren, falls sie zum Beispiel mit berührungsempfindlichen resistiven/kapazitiven Schaltflächen versehen ist, die auch auf einem Anzeigebildschirm verwendet werden können. In einem anderen Ausführungsbeispiel erfolgt die Interaktion durch Drücken von Schaltflächen, ein Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
In dem in 1 gezeigten Ausführungsbeispiel 1 steuert ein Prozessor 3 mindestens teilweise den Betrieb des fahrzeugbasierten Computersystems. Der Prozessor, der innerhalb des Fahrzeugs bereitgestellt ist, ermöglicht eine bordinterne Verarbeitung von Befehlen und Routinen. Weiter ist der Prozessor sowohl mit einem flüchtigen 5 als auch mit einem nichtflüchtigen Speicher 7 verbunden. In diesem Ausführungsbeispiel ist der flüchtige Speicher ein Random Access Memory (RAM) und der nichtflüchtige Speicher ein Festplattenlaufwerk (HDD) oder ein Flash-Speicher. Der Prozessor ist auch mit einer Anzahl unterschiedlicher Eingänge versehen, die dem Benutzer ermöglichen, sich über eine Schnittstelle mit dem Prozessor zu verbinden. In diesem Ausführungsbeispiel sind ein Mikrofon 29, ein Hilfseingang 25 (für den Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24 und ein BLUETOOTH-Eingang 15 alle bereitgestellt. Ein Eingangsauswähler 51 ist ebenfalls bereitgestellt, um zu ermöglichen, dass ein Benutzer zwischen verschiedenen Eingängen auswählt. Die Eingabe sowohl in das Mikrofon als auch in den Hilfsanschluss wird von einem Umsetzer 27 von analog in digital umgesetzt, bevor sie an den Prozessor geleitet wird. Wenngleich dies nicht gezeigt wird, kommunizieren diese und andere Komponenten möglicherweise über ein Fahrzeugmultiplexnetz (wie unter anderem einen CAN-Bus) mit dem VCS, um Daten zu und von dem VCS (oder Komponenten davon) zu leiten.
Ausgänge des Systems können unter anderem eine Sichtanzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang beinhalten. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal vom Prozessor 3 durch einen Digital-Analog-Umsetzer 9. Die Ausgabe kann auch zu einer Remote-BLUETOOTH-Einrichtung wie einem PND 54 oder einer USB-Einrichtung wie einer Fahrzeugnavigationseinrichtung 60 entlang den bidirektionalen Datenströmen mit den Bezugszeichen 19 bzw. 21 erfolgen.
In einem Ausführungsbeispiel nutzt das System 1 den BLUETOOTH-Sendeempfänger 15, um mit dem Nomadic Device 53 eines Benutzers (z. B. Mobiltelefon, Smartphone, PDA oder einer beliebigen anderen Einrichtung mit Drahtlos-Remote-Netzkonnektivität) zu kommunizieren 17. Das Nomadic Device kann dann genutzt werden, um mit einem Netz 61 außerhalb des Fahrzeugs 31 zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen ist der Mast 57 möglicherweise ein WiFi-Zugangspunkt.
Eine beispielhafte Kommunikation zwischen dem Nomadic Device und dem BLUETOOTH-Sendeempfänger wird durch ein Signal 14 dargestellt.
Zum Paaren eines Nomadic Device 53 und des BLUETOOTH-Sendeempfängers 15 kann durch eine Schaltfläche 52 oder eine ähnliche Eingabe angewiesen werden. Folglich wird die CPU angewiesen, dass der bordinterne BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einem Nomadic Device gepaart wird.
Daten können zum Beispiel unter Verwendung eines Datentarifs, von Data over Voice oder von mit einem Nomadic Device 53 assoziierten DTMF-Tönen zwischen der CPU 3 und dem Netz 61 kommuniziert werden. Alternativ ist es eventuell wünschenswert, ein bordinternes Modem 63 mit einer Antenne 18 aufzunehmen, um Daten zwischen der CPU 3 und dem Netz 61 über das Sprachband zu kommunizieren 16. Das Nomadic Device 53 kann dann genutzt werden, um mit einem Netz 61 außerhalb des Fahrzeugs 31 zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen baut das Modem 63 eventuell eine Kommunikation 20 mit dem Mast 57 zum Kommunizieren mit dem Netz 61 auf. Als nicht begrenzendes Beispiel ist das Modem 63 möglicherweise ein USB-Funkmodem und die Kommunikation 20 möglicherweise eine Mobilfunkkommunikation.
In einem Ausführungsbeispiel ist der Prozessor mit einem Betriebssystem versehen, das eine API beinhaltet, um mit einer Modemanwendungssoftware zu kommunizieren. Die Modemanwendungssoftware greift möglicherweise auf ein eingebettetes Modul oder eine eingebettete Firmware im BLUETOOTH-Sendeempfänger zu, um drahtlose Kommunikation mit einem Remote-BLUETOOTH-Sendeempfänger (wie dem in einem Nomadic Device vorfindbaren) durchzuführen. Bluetooth ist eine Untermenge der Protokolle für IEEE 802 PANs (Personal Area Networks). Protokolle für IEEE 802 LANs (Local Area Networks) beinhalten Wi-Fi und weisen eine Funktionalität auf, die sich erheblich mit derjenigen von IEEE 802 PANs deckt. Beide sind für drahtlose Kommunikation innerhalb eines Fahrzeugs geeignet. Ein anderes Kommunikationsmittel, das in diesem Bereich genutzt werden kann, sind optische Freiraumnachrichtenübertragung (wie IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
In einer anderen Ausführungsform beinhaltet ein Nomadic Device 53 ein Modem für Sprachband- oder Breitbanddatenkommunikation. In der Data-over-Voice-Ausführungsform kann eine als Frequenzmultiplexverfahren bekannte Technik implementiert werden, wenn der Besitzer des Nomadic Device über die Einrichtung reden kann, während Daten übermittelt werden. Zu anderen Zeiten, zu denen der Besitzer die Einrichtung gerade nicht nutzt, kann bei der Datenübermittlung die ganze Bandbreite (in einem Beispiel 300 Hz bis 3,4 kHz) genutzt werden. Während das Frequenzmultiplexverfahren bei der analogen Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet häufig vorkommen kann und nach wie vor genutzt wird, wurde es weitgehend abgelöst von Mischformen wie Code Domain Multiple Access (CDMA), Time Domain Multiple Access (TDMA), Space-Domain Multiple Access (SDMA) für digitale Mobilfunkkommunikation. Diese Standards sind alle mit ITU IMT-2000 (3G) konform und bieten Datenraten von bis zu 2 Mbit/s für stationäre oder umhergehende Benutzer und 385 Kbit/s für Benutzer in einem sich fortbewegenden Fahrzeug. 3G-Standards werden derzeit abgelöst von IMT-Advanced (4G), der 100 Mbit/s für Benutzer in einem Fahrzeug und 1 Gbit/s für stationäre Benutzer bietet. Falls der Benutzer über einen mit dem Nomadic Device assoziierten Datentarif verfügt, ist es möglich, dass der Datentarif eine Breitbandübertragung zulässt und das System eine viel größere Bandbreite nutzen könnte (was die Datenübermittlung beschleunigt). In noch einer anderen Ausführungsform ist das Nomadic Device 53 durch eine Mobilfunkkommunikationseinrichtung (nicht gezeigt) ersetzt, die am Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform ist das ND 53 möglicherweise eine Einrichtung für ein drahtloses Local Area Network (LAN), die zu Kommunikation zum Beispiel (unter anderem) über ein 802.11g-Netz (d. h. Wi-Fi) oder ein WiMax-Netz fähig ist.
In einer Ausführungsform können ankommende Daten durch das Nomadic Device über Data over Voice oder einen Datentarif durch den bordinternen BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Fall bestimmter temporärer Daten zum Beispiel können die Daten auf dem HDD oder in einem anderen Speichermedium 7 so lange gespeichert werden, bis die Daten nicht mehr benötigt werden.
Zusätzliche Quellen, die möglicherweise eine Schnittstelle zum Fahrzeug haben, beinhalten eine persönliche Navigationseinrichtung (Personal Navigation Device) 54 zum Beispiel mit einer USB-Verbindung 56 und/oder einer Antenne 58, eine Fahrzeugnavigationseinrichtung 60 mit einer USB- 62 oder einer anderen Verbindung, eine bordinterne GPS-Einrichtung 24 oder ein Remote-Navigationssystem (nicht gezeigt) mit Konnektivität zu einem Netz 61. USB gehört zu einer Gruppe von Protokollen für serielle Anschlüsse. IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), Serienprotokolle der EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Standards zwischen Einrichtungen. Die meisten Protokolle können entweder für elektrische oder für optische Kommunikation implementiert werden.
Weiter könnte die CPU mit verschiedenartigen anderen Hilfseinrichtungen 65 kommunizieren. Diese Einrichtungen können durch eine drahtlose 67 oder eine drahtgebundene 69 Verbindung verbunden sein. Die Hilfseinrichtung 65 beinhaltet unter anderem möglicherweise Personal Media Player, drahtlose medizinische Geräte, tragbare Computer, ein Nomadic Device, einen Schlüsselanhänger und dergleichen. Auch oder alternativ könnte die CPU, zum Beispiel unter Nutzung eines Sendeempfängers für Wi-Fi (IEEE 803.11) 71, mit einem fahrzeugbasierten Funkrouter 73 verbunden sein. Dadurch könnte ermöglicht werden, dass die CPU mit Remote-Netzen in der Reichweite des lokalen Routers 73 verbunden wird.
Zusätzlich dazu, dass beispielhafte Prozesse von einem in einem Fahrzeug befindlichen Fahrzeugcomputersystem ausgeführt werden, werden die beispielhaften Prozesse in bestimmten Ausführungsformen möglicherweise von einem mit einem Fahrzeugcomputersystem kommunizierenden Computersystem ausgeführt. Ein solches System beinhaltet unter anderem möglicherweise eine drahtlose Einrichtung (z. B. und ohne Begrenzung ein Mobiltelefon) oder ein Remote-Computersystem (z. B. und ohne Begrenzung einen Server), die oder das durch die drahtlose Einrichtung verbunden ist. Gemeinsam werden solche Systeme gegebenenfalls als fahrzeugassoziierte Computersysteme (Vehicle Associated Computing Systems, VACS) bezeichnet. In bestimmten Ausführungsformen führen konkrete Komponenten der VACS möglicherweise konkrete Abschnitte eines Prozesses abhängig von der konkreten Implementierung des Systems durch. Beispielhaft und ohne Begrenzung ist es, falls ein Prozess einen Schritt des Sendens oder des Empfangens von Informationen mit einer gepaarten drahtlosen Einrichtung aufweist, wahrscheinlich, dass die drahtlose Einrichtung den Prozess gerade nicht durchführt, weil die drahtlose Einrichtung Informationen mit sich selbst nicht „senden und empfangen“ würde. Der Durchschnittsfachmann versteht, wann es unangebracht ist, ein konkretes VACS auf eine gegebene Lösung anzuwenden. In allen Lösungen ist vorgesehen, dass mindestens das innerhalb des Fahrzeugs selbst befindliche Fahrzeugcomputersystem (Vehicle Computing System, VCS) zum Durchführen der beispielhaften Prozesse fähig ist.
2 zeigt eine beispielhafte Topologie des Fahrzeugs, das mit der Cloud kommuniziert, um unterschiedliche Daten von verschiedenen Quellen zu kommunizieren. Der Fahrzeugserver in der Cloud schafft möglicherweise die Voraussetzung für die Verwaltung und die Verwendung der Daten. Der Server befindet sich möglicherweise auch außerhalb des Fahrzeugs oder in der Cloud. Der Server befindet sich möglicherweise im Fahrzeug und verwendet möglicherweise Hardware und/oder Software, um Webinhalt zuzustellen, auf den durch das Internet oder über eine TCP/IP-Verbindung zugegriffen werden soll. Der Server kann verschiedenen Clients Anforderungen zustellen, indem er HTTP oder andere Mittel zum Zustellen von HTML-Dokumenten und zusätzlichen Inhalten wie Bildern, Scripts etc. nutzt. Die Daten des Servers werden möglicherweise aktualisiert und aggregiert. Die Daten stammen eventuell von einer großen Community in der Cloud. Der Server stellt eventuell auch eine Datensynthese bereit, etwa unter Verwendung von Kontextinformationen zur Extraktion. Zusätzlich schafft der Fahrzeugserver in der Cloud möglicherweise die Voraussetzung für Intelligenz und Entscheidungsfindung durch Verwenden eines Agenten in der Cloud. Der Fahrzeugserver kennt möglicherweise einen Bestimmungspunkt, daher verwendet der Server möglicherweise den Agenten, um den Fahrer proaktiv in das Zustellen von Wetter am festgelegten Bestimmungspunkt eines Benutzers einzubinden.
Bidirektionales Datenstreaming in Echtzeit zwischen einem Fahrzeug und dem Fahrzeugserver und zwischen einer mobilen Einrichtung und dem Fahrzeugserver kann durch das offenbarte Ausführungsbeispiel bewerkstelligt werden. Die relevanten Daten der Interaktion vom Fahrzeug-CAN und vom Fahrzeug an das Smartphone (V2SP) werden möglicherweise in den Server hochgeladen. Die Daten werden möglicherweise verwendet, um eine Kontext-MMS herzustellen, die am Server in Echtzeit erzeugt werden kann, wofür der Kontextdatenaggregator genutzt wird. Die Kontext-MMS wird möglicherweise an einen oder mehrere Clients übermittelt, etwa ein Fahrzeug, eine Einrichtung im Fahrzeug oder ein anderes Modul/eine andere Anzeige. Möglicherweise werden Websockets verwendet, um den Kommunikationskanal bereitzustellen. Die Websocket-Spezifikation, die im Rahmen der HTML5-Initiative entwickelt wurde, hat die WebSocket-JavaScript-Schnittstelle eingeführt. Die Websocket-Schnittstelle ermöglicht eine Vollduplex-Einzelsocketverbindung, über die Nachrichten zwischen einem Client und einem Server gesendet werden können. Der Websocket-Standard vereinfacht weitgehend die Komplexität um die Verwaltung bidirektionaler Webkommunikation und Verbindungen. Die Nutzung von Websockets macht eine Echtzeitaktualisierung der kontextbasierten MMS für unterschiedliche Benutzerszenarios möglich. Ein Beispiel für ein konkretes Benutzerszenario beinhaltet möglicherweise das Anzeigen des Klimas für verschiedene Situationen auf der Fahrzeuganzeigeschnittstelle. Das Car Area Network (CAN) hat zum Beispiel möglicherweise Zugriff auf Klimainformationen, die über eine Klimadatenquelle verfügbar sind, die bordextern vom Fahrzeug und vom Fahrzeugserver ist. Somit ist das Fahrzeugcomputersystem möglicherweise konfiguriert, um das Bestimmungsklima anzuzeigen, indem es die Klimadaten vom bordexternen Server, verschiedene Daten vom Fahrzeug und den Kontextdatenaggregator verwendet. Des Weiteren ist es möglicherweise zum Bereitstellen von Wetterinformationen am Wohnsitz des Fahrers oder einem Wegpunkt fähig. Die Klimadaten können über eine persistente Websocket-Verbindung zum Fahrzeug-Cloudserver zur Zeit des Renderns einer visuellen Schnittstelle von einem Fahrzeug-Cloudserver abgerufen werden. Dies schafft möglicherweise die Voraussetzung dafür, dass unterschiedliche MMS-Schnittstellen auf dem mobilen Nomadic Device einer Person statt in einem bordinternen Fahrzeugsystem wie MYFORD TOUCH verwendet werden. Des Weiteren wird dadurch eine direkte Interaktion zwischen Einrichtungen und einem Server ermöglicht. Dem Benutzer kann ermöglicht werden, entweder mit der mobilen Einrichtung oder mit der übertragenen MMS im bordinternen System des Fahrzeugs direkt zu interagieren.
Das fahrzeugbasierte Computersystem 201 von 2 ist möglicherweise zum Kommunizieren mit einem Fahrzeug-Cloudserver 203 fähig. Das fahrzeugbasierte Computersystem verbindet sich mit dem Fahrzeug-Cloudserver 203 möglicherweise über ein mit dem Fahrzeugsystem gepaartes Bluetooth-Mobiltelefon, eine eingebettete Mobilfunkverbindung und/oder sowohl eine langreichweitige als auch eine kurzreichweitige drahtlose Verbindung. Auf den Fahrzeug-Cloudserver 203 können möglicherweise auch andere Nomadic Devices oder Computersysteme zugreifen. Zusätzlich kann die Zugreifbarkeit verschiedene Sicherheitseinschränkungen erfordern, um die Voraussetzung für den Zugriff auf den cloudbasierten Fahrzeugserver zu schaffen. Das Fahrzeug sendet unter Verwendung von Websockets 217 möglicherweise relevante Daten unterschiedlicher Typen an den Server. Dadurch wird die Voraussetzung für Vollduplex-Kommunikationskanäle über eine einzige TCP-Verbindung geschaffen. Somit verwendet ein Webbrowser oder ein Webserver einer Client- oder Serveranwendung möglicherweise die Websocket-API, um die Live-Echtzeit-Aktualisierung von Inhalten zu erleichtern. Auch wenn in diesem Beispiel die Websocket-API und das Websocket-Protokoll verwendet werden, können noch andere ähnliche alternative Ausführungsformen verwendet werden.
Der Fahrzeug-Cloudserver 205 speichert möglicherweise verschiedenartige fahrzeug- und benutzerbezogene Daten in einer Datenbank 205 des Servers. Im offenbarten Ausführungsbeispiel beinhaltet die Datenbank 205 möglicherweise Fahrzeug-CAN-Daten 207, Smartphone-Fahrzeugdaten 209 und Fahrzeug-MMS-Daten 211. Die Fahrzeug-CAN-Daten 207 werden möglicherweise zum Verwenden von mit dem Fahrzeugsystem und der Fahrzeugleistung assoziierten Daten verwendet. Somit könnten sie Fahrerchronik-, Fahrzeugdiagnose- und Wartungsdaten bereitstellen. Die relevanten Fahrzeug-CAN-Daten werden möglicherweise in den Server hochgeladen. Des Weiteren werden Daten mit Bezug auf die Fahrzeug- und Smartphone-Interaktion 209 möglicherweise auch auf demselben Server gespeichert. Die Smartphone-Fahrzeugdaten 209 werden möglicherweise zum Identifizieren von Kontakten, der Benutzereinrichtung etc. verwendet. Das Fahrzeugcomputersystem ist eventuell über eine Schnittstelle mit mehr als einer in das Fahrzeug eingebrachten Einrichtung verbunden. Somit trägt der Fahrzeugserver möglicherweise zur Vorbereitung der Einrichtung auf die Zusammenarbeit mit dem Fahrzeugsystem bei. Die Fahrzeug-MMS-Daten 211 werden eventuell verwendet, um Benutzereinstellungen zu speichern, Spracherkennungsdaten und Daten mit Bezug auf Interaktion, die während des Fahrens übertragen werden, bereitzustellen, etwa unter anderem Advertisement Bookmarks, Location Bookmarks und individuelle Entertainment-Einstellungen. Auch wenn die Ausführungsbeispiele die Datenbank zeigen, wenn sie Fahrzeug-CAN-Daten, Smartphone-Fahrzeugdaten und Fahrzeug-MMS-Daten beinhaltet, können noch andere Daten gespeichert werden. Die Datenbank 205 kann zum Beispiel die Fahrzeugherstellerdaten und mehr speichern.
Der Inhalt wird möglicherweise auch von den externen Cloudservern 219 bereitgestellt. Einige Beispiele für bordexterne Daten, auf welche die externen Cloudserver möglicherweise zugreifen können, sind Verkehrsdaten, Navigations-/Richtungs-/Routingdaten, Musikinhalt, Händler-/Fahrzeugwartungsdaten, Wetterinhalt, Daten zu sozialer Interaktion, die aus Social Networks wie Google Plus, Facebook, Path, Twitter etc. bezogen werden. Der externe Cloudserver stellt eventuell zusätzliche Daten bereit, um zum Verbessern der Kontext-MMS-Erzeugung beizutragen. Der externe Cloudserver trägt eventuell bei zur Bereitstellung ortsspezifischer Informationen wie Point-of-Interest(POI)-Informationen (Stunden, Ort, Menü, Bewertungen etc.), Verkehr, Wetter etc.
Der Fahrzeug-Cloudserver 203 verwendet eventuell eine andere Computerverarbeitung zum Bereitstellen der Kontextdatenaggregation 213. Das Fahrzeug setzt eventuell die zusätzlichen Ressourcen ein, die der Fahrzeug-Cloudserver 203 bereitstellt, um dem Fahrer zu einer verbesserten Benutzererfahrung zu verhelfen. In einem Ausführungsbeispiel verwendet der Fahrzeugserver zum Beispiel möglicherweise die Mobiltelefonnummer, die Version und das Modell des Benutzers, um die Fähigkeit der Einrichtung zu identifizieren und die MMS für die Einrichtung vorzubereiten. Das fahrzeugbasierte Computersystem erhält diese Daten eventuell vom Mobiltelefon des Benutzers, sobald das Bluetooth-Telefon mit dem Fahrzeug gepaart wurde. Des Weiteren erzeugt der Server eventuell, indem er zusätzliche Daten wie die Fahrzeug-CAN-Daten und die Fahrzeug-MMS-Daten verwendet, eine eindeutige MMS für die Einrichtung des aktuellen Benutzers. Die MMS-Erzeugung 215 kann durch vom Kontextdatenaggregator 213 verwendete Algorithmen und Formeln bewerkstelligt werden. Auf dem Cloudserver werden möglicherweise sowohl eine eindeutige visuelle MMS als auch ein Sprachdialogsystem erzeugt, die dem Benutzer präsentiert werden. Zahlreiche Kombinationen unterschiedlicher Daten können verwendet werden, um die Ausgabe der Kontext-MMS bereitzustellen. Die unterschiedlichen Kombinationen der Daten schaffen die Voraussetzung dafür, dass Aktualisierungen von Anwendungen verfügbar werden. Zusätzlich schaffen sie die Voraussetzung für eine sehr schnelle Integration neuer Anwendungen und Nutzungsfälle im fahrzeugbasierten Computersystem. Die MMS-Daten können basierend auf dem Kontextdatenaggregator möglicherweise in Echtzeit auf dem Server erzeugt werden. Die MMS-Daten können auch an den Client übermittelt werden, der in einer Ausführungsform das Fahrzeug sein kann. In einer alternativen Ausführungsform ist der Client eventuell ein Nomadic Device, das sich entweder innerhalb des Fahrzeugs befindet oder sich vom Fahrzeug entfernt befindet. Nach der Erzeugung durch den Kontextaggregator des Servers sendet der Server die notwendigen Daten möglicherweise über Websockets 217 an das Fahrzeug. Die Websockets tragen dazu bei, dass kontextbasierte MMS-Daten einfacher in Echtzeit aktualisiert werden können.
3 veranschaulicht ein anderes Ausführungsbeispiel für den Fahrzeugserver unter Verwendung einer vollkommen bordexternen Lösung. Die Cloud-MMS des Fahrzeugs verwendet eventuell unterschiedliche Webstandards, um einen Fahrzeugserver herzustellen. Der Fahrzeugserver 401 befindet sich möglicherweise am Fahrzeug, bordextern oder verwendet möglicherweise eine hybride Methode, die bestimmte Software-Features, die sich am Fahrzeug befinden, und andere, die sich bordextern befinden, aufweist. Eine bordexterne oder cloudbasierte Lösung schafft möglicherweise die Voraussetzung dafür, dass Server mit hoher Verarbeitungsleistung Daten in effizienter Weise aggregieren und umwandeln, wobei bordexterne Verbindungen jedoch unter bestimmten Umständen eventuell nicht immer verfügbar sind (d. h. kein Signal oder Dienst für eine langreichweitige Verbindung). Somit kann für den Fahrzeugserver auch eine bordinterne Lösung verwendet werden. Der bordinterne Fahrzeugserver beinhaltet möglicherweise auch einen Kontextdetektor 403 und Software, um kontextabhängige visuelle und Audiometadaten 405 zu erzeugen. Der Fahrzeugserver verwendet möglicherweise nicht nur Fahrzeugsensordaten, sondern verwendet möglicherweise auch andere relevante Informationen von bordexternen Servern und anderen Einrichtungen und Sensoren, die nicht im Fahrzeug eingebettet sind.
Der Fahrzeugserver 401 verwendet möglicherweise auch den Kontextdetektor 403, um die Umgebung zu verstehen, in der das Fahrzeug oder ein anderer Client gerade betrieben wird. Des Weiteren bestimmt der Kontextdetektor die Umgebung möglicherweise in Anbetracht der unterschiedlichen Clients oder Einrichtungen, die mit dem Fahrzeugserver kommunizieren. Der Fahrzeug-Cloudserver kommuniziert möglicherweise mit einem eingebetteten Fahrzeugserver oder mit einem Nomadic Device, somit muss der Kontextdetektor den Kontext für ein geeignetes MMS-Rendering bestimmen. Die Kontextdetektion kann basierend auf Fahrzeugsensordaten und anderen relevanten Daten vollständig in der Cloud erfolgen. Falls ein Fahrer sich zum Beispiel seinem Wohnhaus nähert und der Fahrzeugserver diese Information kennt und eine MMS erzeugt, kann er sie an das Fahrzeug senden. Die Anzeige der visuellen MMS weist eventuell ein Fenster für den Betrieb des Garagentors des Wohnhauses auf. Auch wenn für die vorliegende Ausführungsform eine Kontextdetektion in der Cloud vorhanden ist, sind sowohl bordinterne Fahrzeuglösungen als auch hybride Lösungen alternative Ausführungsformen.
Der Fahrzeugserver 401 wird möglicherweise ähnlich betrieben wie ein Webserver mit Websocket-Unterstützung. Der Fahrzeug-MMS-Renderer kann einfach ein moderner Browser sein, der zum Beispiel HTML 5 und Websockets unterstützt. Das Fahrzeug sendet möglicherweise Daten, die sich innerhalb des Fahrzeugdatenbusses oder an Fahrzeugsensoren befinden, etwa Fahrzeuggeschwindigkeit, -ort etc., an den Fahrzeugserver. Der Fahrzeug-Cloudserver nutzt diese Daten möglicherweise für Kontextdetektion und Fahrmustererkennung. Der im Fahrzeug eingebettete Browser nutzt möglicherweise die Daten zum Rendern der MMS für den Benutzer. In einer alternativen Ausführungsform wird zum Rendern der MMS statt eines Browsers möglicherweise eine Grafikrenderinganwendung verwendet. Die Anwendung wird möglicherweise verwendet, um das Rendern einer Seite in einem Browser einzugrenzen oder zu eliminieren.
Der Kontextdetektor 403 kommuniziert möglicherweise mit einem Heimserver 411. Der Heimserver stellt möglicherweise Daten bereit, die sich am Wohnsitz eines Benutzers befinden. Solche Daten, die genutzt werden können, sind Heimautomatisierungsdaten, z. B. für die Heim-Heizungs-, -Lüftungs- und -Klimaanlage, die Sicherheit, die Beleuchtung und den Beleuchtungsstand, den Gasstand etc. Des Weiteren kommuniziert der Kontextdetektor 403 möglicherweise mit einem externen Medienserver 412. Der externe Medienserver verwendet möglicherweise Daten wie Fotos, Musik und Videodateien.
Nachdem der Kontextdetektor 403 Daten von mehreren Servern und Quellen empfangen hat, erzeugt der Fahrzeugserver möglicherweise kontextabhängige visuelle und Audiometadaten 405. Die Metadaten können dann an den Client 407 gesendet werden, der das Fahrzeug, ein Nomadic Device oder ein Browser auf einer Personal-Computer-Einrichtung sein kann. Die Fahrzeug-MMS-Rendering-Engine 409 wird möglicherweise genutzt, um eine MMS von einem spezifischen Typ basierend auf den Daten, dem Client und anderen Faktoren zu erzeugen. Die MMS-Rendering-Engine kann in Verbindung mit einem Webbrowser oder einer Anwendung verwendet werden.
In einer anderen Ausführungsform kann die hybride Methode verwendet werden, um die MMS unter Verwendung des im Fahrzeug eingebetteten Servers zu rendern. Dadurch kann ein potenzielles Problem gelöst werden, falls das Fahrzeug keine Verbindung zum Fahrzeug-Cloudserver aufrechterhalten kann. Die Fahrzeug-MMS-Rendering-Engine ist möglicherweise konfiguriert, um sowohl mit als auch ohne den Fahrzeug-Cloudserver zu arbeiten, um die MMS zu rendern, wenn keine Verbindung zur Cloud besteht. Diese hybride Architektur ist eventuell ideal geeignet für Fahrzeug-MMS-Rendern, wenn nicht immer eine Verbindung zum Server verfügbar ist.
4 ist ein Beispiel für ein Ablaufschema, das die Interaktion des fahrzeugbasierten Computersystems angibt. Das fahrzeugbasierte Computersystem ist möglicherweise entweder mit einem bordinternen, einem bordexternen oder einem hybriden (Kombination aus bordinternem und bordexternem) Server ausgestattet. Somit können die Schritte in einer beliebigen Kombination oder insgesamt entweder innerhalb des Fahrzeugs, außerhalb des Fahrzeugs in einer Cloud oder in einer hybriden Kombination, die eine Verarbeitung sowohl bordinterner als auch bordexterner Lösungen nutzt, durchgeführt werden. Der Server kann Fahrzeugdaten 501 aus verschiedenen Fahrzeugmodulen auslesen, indem er eine drahtgebundene Verbindung (z. B. CAN, USB, seriell etc.) oder eine drahtlose Verbindung (z. B. Bluetooth, Wi-Fi, Wi-Fi Direct, Mobilfunkverbindung etc.) nutzt. Zusätzlich beinhalten die Fahrzeugdaten möglicherweise Mediendaten aus einer Mediensammlung eines Benutzers, Navigationsdaten (z. B. POI-Informationen, Geschwindigkeitsbegrenzungsinformationen und andere Zuordnungsdaten) und Mobiltelefondaten. Die Fahrzeugdaten können verwendet werden, um spezifische Informationen auf einer Schnittstelle auszugeben (z. B. Geschwindigkeit des Fahrzeugs oder Ort des Fahrzeugs), oder sie könnten genutzt werden, um ein spezifisches Feature oder eine spezifische Schnittstelle für die MMS zu erzeugen.
Das Fahrzeugcomputersystem ist möglicherweise konfiguriert, um zu bestimmen, ob eine Verbindung zu einem bordexternen Cloudserver oder Datenserver 502 besteht. Falls die Verbindung besteht, empfängt das Computersystem möglicherweise bordexterne Daten 503 von verschiedenen Datenquellen, die sich nicht am oder im Fahrzeug befinden. Diese Datenquellen beinhalten eventuell das Wetter, den Verkehr, Sportspielstände, bordexterne Navigationsdaten etc. Ähnlich wie die Fahrzeugdaten werden die bordexternen Daten möglicherweise verwendet, um spezifische Informationen auf der Benutzerschnittstelle auszugeben (z. B. eine Wetterkarte), oder sie könnten genutzt werden, um ein spezifisches Feature oder eine spezifische Schnittstelle für die MMS zu erzeugen. Der Server kann die mit einer Browseranwendung zu nutzende Schnittstelle erzeugen.
Nach dem Empfangen der bordexternen Daten oder dem Bestimmen, dass keine Verbindung besteht, verwendet das Fahrzeugcomputersystem möglicherweise einen Kontextdatenaggregator. In einigen Ausführungsformen kommuniziert das Fahrzeugcomputersystem möglicherweise mit einem Kontextaggregator, der dynamische Features und Kontext basierend auf den Fahrzeugdaten und/oder den bordexternen Daten erzeugt. Der Kontextaggregator analysiert möglicherweise die Daten 505, um zu bestimmen, ob von der Schnittstelle irgendwelche dynamischen Features verwendet werden können. Falls der Kontextaggregator keine Features erkennt, die gegebenenfalls dynamisch sind, nutzt er eventuell die statischen MMS-Features des Fahrzeugcomputersystems. In einem alternativen Szenario erkennt der Kontextaggregator eventuell, dass entweder die Fahrzeugdaten oder die bordexternen Daten die Möglichkeit beinhalten können, dass das Fahrzeugcomputersystem ein dynamisches Feature oder eine dynamische MMS 507 erzeugt. In einem Szenario empfängt der Kontextaggregator eventuell Daten, die angeben, dass das Fahrzeug sich fortbewegt und sich auf einer Straße mit Verkehr befindet. Somit kann der Aggregator die Daten verwenden, um auf der Benutzerschnittstelle ein Fenster anzuzeigen, das einen Benutzer zum Umfahren des Verkehrs auffordert. In einem anderen Szenario erkennt der Kontextaggregator das Mobiltelefon eventuell als sekundären Fahrer und zeigt eventuell eine Benutzerschnittstelle an, die auf die Bedürfnisse dieses Fahrers zugeschnitten ist. Zum Beispiel können basierend auf dem Fahrer möglicherweise eine bestimmte Skin oder Grafik genutzt und Voreinstellungen gespeichert werden. Falls kein Kontextnutzungsfall oder keine Kontextdaten vorliegen, erzeugt das System möglicherweise einfach eine statische MMS, die in einem Fahrzeugsystem gerendert werden soll. Zusätzlich wird die MMS möglicherweise für Features angepasst, die der konkrete Benutzer am häufigsten nutzt. Der Kontextaggregator befindet sich eventuell bordextern vom Fahrzeug, bordintern oder verwendet eventuell eine hybride Lösung.
Das Fahrzeugcomputersystem bestimmt möglicherweise, ob ein Nomadic Device, das mit dem Fahrzeugcomputersystem verbunden ist, gerade eine Anwendung 509 verwendet. Die Verwendung einer Anwendung durch ein Nomadic Device kann das Erfordernis beseitigen, dass der Server die Webseite erzeugt. Stattdessen sendet der Server möglicherweise einfach die relevanten Daten für die MMS 511 des Nomadic Device, falls bestimmt wird, dass das Nomadic Device gerade eine Benutzerschnittstellenanwendung für das Fahrzeug nutzt. Die Daten können die Form eines beliebigen Datentyps wie JSON (JavaScript Object Notation) haben. Somit wird die Seite vorgerendert, bevor die relevanten Fahrzeugdaten vom Nomadic Device gesendet werden. Das Nomadic Device verwendet jegliche relevanten Daten, um die notwendigen Informationen zum Anzeigen auf der Benutzerschnittstelle auszugeben. Zusätzlich kann die Anwendung für ein spezifisches Benutzerfallszenario eines Fahrers oder eines Beifahrers zugeschnitten werden, etwa eine Anwendung zum Verstellen der Sitzsteuerungselemente des Fahrzeugs.
Falls das Fahrzeugcomputersystem bestimmt, dass die Einrichtung gerade keine Anwendung für die Benutzerschnittstelle nutzt, fordert die Einrichtung beim im Fahrzeug eingebetteten Server möglicherweise die gerenderte MMS an, welche die Form einer Webseite haben kann. Das Fahrzeugcomputersystem rendert die Webseite der MMS 513 möglicherweise unter Verwendung einer bordinternen, einer bordexternen oder einer hybriden Lösung. Nach dem Rendern der MMS sendet das Fahrzeugcomputersystem die MMS möglicherweise an das Nomadic Device 515. Die Einrichtung nutzt möglicherweise einen Webbrowser, der mit den Protokollen des Servers übereinstimmt, um die MMS anzufordern oder zu laden, welche die Form einer Webseite haben kann. Die Webseite kann chromlos sein, was bedeutet, dass kein Browser-Chrom gezeigt werden muss. Der Browser verwendet möglicherweise eine Rendering-Engine, Java Script und Browser-Plugins, um die Benutzererfahrung zu verbessern. Des Weiteren können jegliche der Daten, die vom Fahrzeugcomputersystem genutzt werden, zum Erzeugen der MMS verwendet werden.
5A ist ein Ausführungsbeispiel für eine Netzarchitektur, die verwendet wird, um ein zum Steuern eines Sitzes gebrauchtes Smartphone zu demonstrieren. Ein Nomadic Device 601 wird möglicherweise in das Fahrzeug eingebracht. Das Nomadic Device weist möglicherweise eine Fahrzeugschnittstellenanwendung 603 auf oder nicht, die ausgeführt wird, um eine Mensch-Maschine-Schnittstelle (MMS) für verschiedene Fahrzeugsteuerelemente zu verwenden. Das Smartphone kann ermöglichen, dass der Browser Fahrzeug-MMS-Webseiten vom im Fahrzeug eingebetteten Server anfordert. Weiter wird das Nomadic Device eventuell verwendet, um verschiedene Teile, Komponenten oder Module des Radios zu steuern. In der unten beschriebenen Ausführungsform wird die Anwendung verwendet, um die Funktionalität eines Sitzes zu betreiben. Jedoch können sämtliche Module, Komponenten oder Computer des Fahrzeugs verwendet werden. Einige Beispiele beinhalten unter anderem das Radio, die Navigation, das System, das Schiebedach, das Glasschiebedach, den Kofferraum, die Leuchten etc. Diese Ausführungsform demonstriert einen Funksendeempfänger 605, der mit dem Nomadic Device kommuniziert. Verschiedene Funksendeempfänger beinhalten möglicherweise einen Wi-Fi-Sendeempfänger, einen Bluetooth-Sendeempfänger, Nahfeldkommunikation (NFC), Infrarot etc. Wenngleich in der Ausführungsform für das Fahrzeug ein Funksendeempfänger zum Kommunizieren mit dem Nomadic Device gezeigt ist, kann auch eine drahtgebundene Lösung (z. B. USB, seriell, CAN, Firewire etc.) möglich sein. Die Datenkommunikation zwischen dem Nomadic Device 601 und dem Funksendeempfänger 605 wird möglicherweise aufgebaut, wenn die Sicherheit autorisiert worden ist. Die Einrichtungen verwenden möglicherweise eine Paarungssequenz aus Erzeugen einer Zufallszahl und Abgleichen mit dem Fahrzeugcomputersystem oder umgekehrt. Zusätzlich erfordert das Fahrzeug oder die Einrichtung möglicherweise eine Schaltfläche, die in einem bestimmten Moment eine bestimmte Zeit lang zu drücken ist, um eine Verbindung aufzubauen. Zusätzlich verwendet die NFC möglicherweise RFD-Tags, um eine Kommunikation aufzubauen.
Der Funksendeempfänger kommuniziert möglicherweise direkt mit dem Fahrzeugnetz 606. Ein Fahrzeugcomputer beinhaltet möglicherweise einen in das Fahrzeug eingebetteten Server 611 und einen CAN/USB-Manager, um Daten überall in der Fahrzeugnetzinfrastruktur 602 zu kommunizieren. Wenngleich der in das Fahrzeug eingebettete Server 611 einen CAN-Manager und einen USB-Sitz-Controller beinhalten kann, können diese in anderen Ausführungsformen je auch separate einzelne Module sein. Die Infrastruktur 602 verwendet zum Kommunizieren möglicherweise Funksignale, oder sie verwendet möglicherweise ein Kabelnetz 606, etwa ein CAN, USB, DVI etc. Der in das Fahrzeug eingebettete Server 611 kommuniziert möglicherweise mit einem oder mehreren USB- oder CAN-Sendeempfängern 609, um mit anderen Modulen zu kommunizieren. Der Sendeempfänger 609 kommuniziert möglicherweise wiederum mit einem Sitz- & Positionssteuermodul 607. Das Sitz- & Positionssteuermodul kommuniziert möglicherweise Daten von und zu der Fahrzeugnetzinfrastruktur 602. Die Daten können verwendet werden, um zu ermöglichen, dass ein Benutzer Sitzpositionen auf einem Nomadic Device 601 wie einem Mobiltelefon steuert.
Weiter kann ein in das Fahrzeug eingebetteter Server 611 eine MMS erzeugen oder an die verschiedenen Anzeigen des Fahrzeugs ausgeben, etwa auf der Anzeige eines Nomadic Device 601. Der in das Fahrzeug eingebettete Server ist möglicherweise zusätzlich mit den bordexternen Fahrzeug-Cloudservern verbunden, um verschiedene Daten zu kommunizieren, etwa bordexterne Daten, eine Standardbenutzerschnittstelle oder eine Kontextbenutzerschnittstelle. Der Server 611 kann Ton oder Musik durch die Fahrzeuglautsprecher 627 durch Verwenden von DSP, 5.1, THX oder einer anderen Audiokompressionstechnologie ausgeben.
Die Lenkradsteuerelemente 613 können eventuell auch Daten an den Server 611 und andere Einrichtungen innerhalb des VCS kommunizieren. Das Lenkrad schafft möglicherweise die Voraussetzung für Flexibilität beim Steuern der Benutzerschnittstelle, während es ermöglicht, dass ein Fahrer das Fahrzeug sicher betreibt. Die Lenkradsteuerelemente 613 steuern möglicherweise nur einige der Benutzerschnittstellen der Anzeige oder alle unterschiedlichen Benutzerschnittstellen innerhalb des Fahrzeugs.
Ein anderer Fahrzeugcomputer 629 beinhaltet möglicherweise eine Anwendung, die als Datenmanager, HUD-Modul und Spracherkennungsengine dient. Der Datenmanager wird möglicherweise verwendet, um das Senden relevanter CAN-Daten an die verschiedenen Fahrzeugmodule zu erleichtern. Die Spracherkennungsengine kann die Fähigkeit von zu sprechenden und über ein MIK 631 einzugebenden Benutzerbefehlen bereitstellen. Die Spracherkennungsengine kann eine Engine zur Erkennung natürlicher Sprache nutzen und das Erfordernis beseitigen, dass nur spezifische Befehle gesprochen werden, verwendet jedoch möglicherweise Kontextinformationen, um die gesprochenen Befehle des Benutzers zu interpretieren. Somit sendet die Sprach-Engine nach dem Identifizieren des Befehls des Benutzers die relevante CAN-Nachricht oder die relevanten CAN-Daten an das relevante Modul zum Agieren gemäß dem Befehl. Der eingebettete Fahrzeugserver kann möglicherweise mit allen relevanten MMS-Schnittstellen im Fahrzeug kommunizieren, etwa unter anderem mit dem Heads-up-Display (HUD), dem Kombiinstrument, der Mittelkonsole und Spracherkennungs-/Sprachdialogsystemen. Die Sprach-Engine 629 kann den Dialog unter Nutzung verschiedener Lautsprecher 627 im Fahrzeug ausgeben.
Ein HUD 631 kann verwendet werden, um eine Benutzerschnittstelle von einem spezifischen Typ zu rendern oder um spezifische Daten anzuzeigen. Die HUD schafft möglicherweise die Voraussetzung für eine auf der Windschutzscheibe eines Fahrzeugs anzuzeigende Projektion, um relevante Informationen im peripheren Sehfeld des Fahrers anzuzeigen. Die HUD kann als ein die MMS des Fahrzeugservers verwendender Typ der Anzeige im Fahrzeug dienen.
Ein anderer Typ der Anzeige, der möglicherweise die MMS des Fahrzeugservers verwendet, ist das Fahrzeugkombiinstrument. Das Fahrzeugkombiinstrument kann verwendet werden, um verschiedene Fahrzeuginformationen wie die Geschwindigkeit, die Umdrehungen pro Minute, die Wirtschaftlichkeit des Kraftstoffverbrauchs, den Kraftstoffstand etc. anzuzeigen. Die Kombiinstrumentanzeige 635 kommuniziert möglicherweise mit einem Kombiinstrumentmanager 633. Der Kombiinstrumentmanager 633 empfängt möglicherweise die Schnittstellendaten vom Fahrzeugserver für die Ausgabe auf der Kombiinstrumentanzeige 635. Des Weiteren ist der Kombiinstrumentmanager 633 möglicherweise dazu fähig, seine eigene MMS zu rendern oder die Datenkommunikation mit einer anderen Einrichtung innerhalb des Fahrzeugnetzes zu erleichtern. Ein anderer Typ der Anzeige, der möglicherweise die MMS des Fahrzeugservers verwendet, ist die Fahrzeugmittelkonsole. Die Fahrzeugmittelkonsole wird möglicherweise verwendet, um verschiedene Fahrzeuginformationen wie Audioinformationen, Navigationsinformationen, Telefoninformationen, Fahrzeugeinstellungen etc. anzuzeigen. Die Mittelkonsolenanzeige 639 kommuniziert möglicherweise mit einem Mittelkonsolenmanager 637. Der Mittelkonsolenmanager 637 empfängt möglicherweise die Schnittstellendaten vom Fahrzeugserver für die Ausgabe auf der Kombiinstrumentanzeige 639. Des Weiteren ist der Kombiinstrumentmanager 637 möglicherweise dazu fähig, seine eigene MMS zu rendern oder die Datenkommunikation mit anderen Einrichtungen innerhalb des Fahrzeugnetzes zu erleichtern.
5B ist ein Ausführungsbeispiel eines vereinfachten Blockdiagramms, das die Netzarchitektur, die verschiedene Anzeigen im Fahrzeug verwendet, abbildet. Das Fahrzeugcomputersystem 657 hostet möglicherweise einen in das Fahrzeug eingebetteten Server, um Daten und Webseiten unter Verwendung eines Browsers oder einer Anwendung an verschiedene Einrichtungen zu kommunizieren. Einige der Anzeigen sind möglicherweise festverdrahtet, etwa das Fahrzeugkombiinstrument 655, die Mittelkonsole 659, die HUD 651 oder eine andere Anzeige zum Ausgeben einer MMS-Schnittstelle 653. Zusätzlich verwendet der Webserver eventuell eine drahtgebundene/drahtlose Verbindung 661, um ein Nomadic Device 663 einzubringen. Das Nomadic Device 663 gibt eventuell verschiedene Fahrzeug-MMS 665 zur Verwendung auf dem Nomadic Device aus. Die verschiedenen Einrichtungen 663 kommunizieren möglicherweise durch eine drahtgebundene oder drahtlose Verbindung 661 mit dem Fahrzeug-Webserver 657. Die verschiedenen Anzeigen und Einrichtungen nutzen möglicherweise eine Anwendung, um die relevanten MMS-Daten auszugeben, um eine Schnittstelle 665 auszugeben. In einer anderen Ausführungsform wird die Schnittstelle 665 möglicherweise unter Verwendung eines Nomadic-Device-Browsers ausgegeben, der seine eigene Seite rendert.
6 ist ein Ausführungsbeispiel für eine Mensch-Maschine-Schnittstelle, die auf unterschiedlichen Typen von Nomadic Devices angezeigt wird. 701 ist ein Beispiel für ein Tablet, das sich mit dem Fahrzeugserver verbinden kann, um das Fahrzeugcomputersystem zu betreiben. Die Schnittstelle des Nomadic Device schafft möglicherweise die Voraussetzung dafür, dass ein Benutzer verschiedene Features steuert, etwa die Radionavigation, die Klimatisierung, das Mobiltelefon und andere Features und Einstellungen. Die Tablet-Schnittstelle 702 imitiert möglicherweise die Schnittstelle einer MMS im Fahrzeug oder ist möglicherweise auf spezifische Features für das Tablet zugeschnitten. Die Schnittstelle wird möglicherweise in unterschiedlichen Betriebssystemen wie iOS und Android ausgeführt. Der Fahrzeugserver sendet die MMS möglicherweise an das Tablet 701, das für die Bildschirmgröße und die Auflösung des Tablets formatiert ist.
703 ist ein Beispiel für ein Mobiltelefon, das sich mit dem Fahrzeugserver verbinden kann, um das Fahrzeugcomputersystem zu betreiben. Das Tablet 701 und das Mobiltelefon 703 verbinden sich möglicherweise über eine drahtgebundene, eine kurzreichweitige drahtlose (z. B. Bluetooth, Wi-Fi, Wi-Fi Direct) oder eine langreichweitige drahtlose (CDMA, GSM, LTE, etc.). Die Schnittstelle 705 ist möglicherweise so zugeschnitten, dass sie optimal auf den Bildschirm eines Mobiltelefons passt und optimal darauf angezeigt wird. Wenngleich 6 ein Beispiel für ein Mobiltelefon und ein Tablet veranschaulicht, das zum Anzeigen der Schnittstelle verwendet wird, können noch andere mobile Einrichtungen genutzt werden. Dazu können ein MP3-Player, ein Laptop-Computer, ein PDA oder eine tragbare Spieleinrichtung gehören.
7 veranschaulicht ein Beispiel für eine abfragebasierte MMS, die möglicherweise ein Sprachdialogsystem verwendet. Das abfrage-/suchbasierte System 801 schafft möglicherweise die Voraussetzung für eine Spracherkennungsengine zur Verwendung in Verbindung mit dem Cloudserver für eine Mensch-Maschine-Schnittstellenumgebung.
Das abfragebasierte System 801 kann im Fahrzeug sein, sich auf einem bordexternen Server befinden oder eine hybride Kombination verwenden, die bestimmte Aspekte der Verarbeitung sowohl am Fahrzeug als auch bordextern einschließt. In der abfrage-/suchbasierten Automobil-MMS kann ein Benutzer nach Funktionalität abfragen oder nach Funktionalität oder Informationen suchen, indem er das Sprachdialogsystem verwendet, das zusammen mit dem cloudbasierten Fahrzeugserver arbeitet. Der Fahrzeugserver kann für den Benutzer unterschiedliche Optionen bereitstellen. Der Benutzer kann zum Beispiel nach einer Multikonturfunktionalität abfragen und dem Benutzer wird mit entsprechender Werbung auf der Anzeige der visuellen MMS eine akustische Beschreibung des Multikontur-Features angeboten.
Ein Sprachdialogsystem 803 gibt für einen Benutzer möglicherweise einen akustischen Dialog aus. Dadurch kann ermöglicht werden, dass der Benutzer eine computersynthetisierte Stimme (Text zu Sprache) durch die Fahrzeuglautsprecher vernimmt und Befehle durch ein MIK bereitstellt. Das Dialogsystem 803 verwendet möglicherweise verschiedene Spracherkennungsengines, um die Befehle zu erkennen. Zusätzlich liegt das Sprachdialogsystem für zusätzliche Rechenleistung möglicherweise bordextern auf einem anderen Server. Des Weiteren wird das Sprachdialogsystem 803 eventuell in Verbindung mit den Elementen der visuellen MMS verwendet. Zum Beispiel wird ein beliebiges Menü oder ein beliebiger Text, das oder der auf dem System grafisch angezeigt wird, eventuell als eine verfügbare Dialoganforderung betrieben. Falls zum Beispiel auf der Anzeige auf einer grafischen Schaltfläche „Suche vor“ steht, um zum nächsten Radiosender zu wechseln, kann das abfragebasierte System 801 ermöglichen, dass das Dialogsystem 803 als möglichen Befehl „Suche vor“ oder „nächster Radiosender“ ausgibt.
Des Weiteren wird das abfragebasierte System 801 möglicherweise in Verbindung mit einem cloudbasierten Server 807, der einen Kontextaggregator 809 verwendet, um unterschiedliche MMS-Befehle zu erzeugen, oder in Verbindung mit zusätzlichen Rechenprozessen genutzt. Durch Verwenden des Kontextaggregators 809, um ein eindeutiges Sprachdialogsystem 803 zu erzeugen, empfängt der Aggregator 809 möglicherweise Ortsdaten 813 und andere Fahrzeuginformationen 811, um einen Dialog für das abfragebasierte System 801 zu erzeugen. In einem Beispiel erkennt der Kontextaggregator 809 über von der Motor-ECU empfangene Fahrzeugdaten 811 eventuell, dass das Fahrzeug über wenig Kraftstoff verfügt. Durch Verwenden von Ortsdaten 813 weiß das System eventuell, dass eine Tankstelle in der Nähe ist. Somit kann das Dialogsystem 803 den Benutzer fragen: „Möchten Sie die nächste Mobile-Tankstelle aufsuchen?“ Des Weiteren können die Elemente 805 der visuellen MMS auf einer Karte den genauen Ort der Tankstelle anzeigen, nebst anderen greifbaren Informationen wie der Adresse oder der Telefonnummer. Wenngleich die veranschaulichte Ausführungsform nur ein Beispiel zeigt, können beliebige Kombinationen der verschiedenen Fahrzeugdaten und bordexternen Daten in Verbindung mit dem abfragebasierten System 801 verwendet werden. In einem Beispiel kann der Benutzer nach einer geeigneten Lendenwirbelstützenverstellposition abfragen/suchen, die als Option bei einem Multikontursitz angeboten wird. Das Sprachdialogsystem kann die Daten von einem Fahrzeug-Cloudserver aggregieren und geeignete Hilfe für eine gegebene Abfrage bereitstellen.
Wenngleich oben beispielhafte Ausführungsformen beschrieben werden, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Patentschrift verwendeten Begriffe beschreibende und keine begrenzenden Begriffe, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Gedanken und vom Schutzbereich der Erfindung abzuweichen. Zusätzlich können die Features verschiedener implementierender Ausführungsformen so kombiniert werden, dass sie weitere Ausführungsformen der Erfindung bilden.
Bezugszeichenliste
Fig. 5B

655: Kombiinstrument
659: Mittelkonsole
653: MMS-Schnittstelle...
657: In-Vehicle-Infotainment(IVI)-Fahrzeugwebserver
661: Drahtgebunden/Drahtlos

803: Sprachdialogsystem
805: Elemente von visueller MMS
807: cloudbasierter Server
809: Kontextaggregator
813: Ort
811: Fahrzeuginformationen

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 2011/0234427 [0003]
US 8204734 [0004]
US 2012/0179325 [0005]

Zitierte Nicht-Patentliteratur

IEEE 802 [0027]
IEEE 802 [0027]
IEEE 802 [0027]
IEEE 1394 [0030]
IEEE 1284 [0030]
IEEE 803.11 [0031]

Claims

Fahrzeugcomputersystem, das Folgendes umfasst: einen Funksendeempfänger, der konfiguriert ist, um eine Verbindung zu einem Nomadic Device aufzubauen, wobei der Funksendeempfänger weiter konfiguriert ist, um eine Nomadic-Device-Mensch-Maschine-Schnittstelle (MMS) zu senden, die für die Ausgabe auf dem Nomadic Device unter Nutzung eines ersten Webbrowserformats konfiguriert ist; eine Fahrzeuganzeige, die konfiguriert ist, um eine MMS im Fahrzeug unter Nutzung eines zweiten Webbrowserformats zum Steuern verschiedener Fahrzeugfunktionen auszugeben; und einen Fahrzeugserver, der konfiguriert ist, um die MMS im Fahrzeug für die Fahrzeuganzeige zu erzeugen und die Nomadic-Device-MMS für das Nomadic Device zu erzeugen.
Fahrzeugcomputersystem nach Anspruch 1, wobei das Fahrzeugcomputersystem weiter einen mit dem Fahrzeugcomputersystem kommunizierenden bordexternen Server beinhaltet, wobei der bordexterne Server konfiguriert ist, um bordexterne Daten zum Erzeugen der Nomadic-Device-MMS oder der MMS im Fahrzeug zu verwenden oder bereitzustellen.
Fahrzeugcomputersystem nach Anspruch 2, wobei der bordexterne Server bordexterne Fahrzeugdaten und/oder Smartphone-Fahrzeugdaten und/oder Fahrzeug-Mensch-Maschine-Schnittstellendaten enthält.
Fahrzeugcomputersystem nach Anspruch 2, wobei der bordexterne Server weiter konfiguriert ist, um Daten zwischen dem Fahrzeugserver unter Verwendung von Websockets auszutauschen.
Fahrzeugcomputersystem nach Anspruch 2, wobei der bordexterne Server einen Kontextdatenaggregator beinhaltet, der bordexterne Fahrzeugdaten und/oder Smartphone-Fahrzeugdaten und/oder Fahrzeug-Mensch-Maschine-Schnittstellendaten verwendet, um eine an das Fahrzeugcomputersystem zu sendende Kontext-Mensch-Maschine-Schnittstelle zu erzeugen.
Fahrzeugcomputersystem nach Anspruch 2, wobei das Fahrzeugcomputersystem eine persistente Verbindung zum bordexternen Server unter Verwendung von Websockets aufrechterhält.
Fahrzeugcomputersystem nach Anspruch 1, wobei die MMS im Fahrzeug eine sprachinteraktive Schnittstelle beinhaltet.
Fahrzeugcomputersystem nach Anspruch 1, wobei der Fahrzeugserver konfiguriert ist, um einen Vollduplex-Kommunikationskanal über eine einzige TCP-Verbindung zu verwenden.
Fahrzeugcomputersystem nach Anspruch 1, wobei die Verbindung zum Nomadic Device eine Wi-Fi-Direktverbindung ist.
Fahrzeugcomputersystem nach Anspruch 1, wobei das erste Webbrowserformat und das zweite Webbrowserformat gleich sind.
Fahrzeugcomputersystem nach Anspruch 1, wobei der Fahrzeugserver konfiguriert ist, um ein fähiges Format des Browsers zu detektieren und die Nomadic-Device-MMS oder die MMS im Fahrzeug basierend auf dem fähigen Format des Browsers zu erzeugen.
Fahrzeugcomputersystem nach Anspruch 1, wobei der Fahrzeugserver konfiguriert ist, um eine auf Abfragesuchen für natürliche Sprache basierende Mensch-Maschine-Schnittstelle zu unterstützen.
Bordexternes Computersystem, das Folgendes umfasst: einen mit einem Fahrzeug kommunizierenden Funksendeempfänger; und einen Server, der einen Kontextdatenaggregator beinhaltet, der aus dem Funksendeempfänger ausgelesene Fahrzeugdaten und bordexterne Daten verwendet, um eine dynamische Kontext-Mensch-Maschine-Schnittstelle basierend auf den Fahrzeugdaten und den bordexternen Daten in einem Webbrowserdatenformat zu erzeugen, die unter Verwendung des Funksendeempfängers an das Fahrzeug gesendet werden soll.
Bordexternes Computersystem nach Anspruch 13, wobei der Funksendeempfänger weiter zum Kommunizieren mit einem Nomadic Device fähig ist.
Bordexternes Computersystem nach Anspruch 13, wobei die dynamische Kontext-Mensch-Maschine-Schnittstelle ein an das Fahrzeug zu sendendes Spracherkennungsmenü beinhaltet.
Bordexternes Computersystem nach Anspruch 13, wobei die bordexternen Daten von einem Heimserver empfangene Daten beinhalten.
Bordexternes Computersystem nach Anspruch 13, wobei die bordexternen Daten von einem Medienserver empfangene Mediendaten beinhalten.
Bordexternes Computersystem nach Anspruch 17, wobei die Mediendaten Musikdaten, Bilddaten oder Videodaten beinhalten.
Bordexternes Computersystem nach Anspruch 13, wobei der Server weiter konfiguriert ist, um eine die Fahrzeugdaten und die bordexternen Daten verwendende Sprachabfragesuche-MMS zu erzeugen, wobei die an das Fahrzeug zu sendende Abfragesuche-MMS den Funksendeempfänger verwendet.
Fahrzeugcomputersystem, das Folgendes umfasst: einen Funksendeempfänger, der konfiguriert ist, um eine Nomadic-Device(ND)-Mensch-Maschine-Schnittstelle (MMS) an ein ND in einem Webbrowserformat zu senden; und einen Fahrzeugserver, der einen Kontextdatenaggregator verwendet, der Fahrzeugdaten und bordexterne Daten verwendet, um eine dynamische MMS zu erzeugen, wobei der Server weiter konfiguriert ist, um eine MMS im Fahrzeug für die Ausgabe auf einer Fahrzeuganzeige zu erzeugen und die ND-MMS für das ND zum Anzeigen zu erzeugen.