DE102015119282A1

DE102015119282A1 - Verfahren und System zum Starten einer Anwendung

Info

Publication number: DE102015119282A1
Application number: DE102015119282.9A
Authority: DE
Inventors: Tom Nelson; David Anthony Hatton; William Donald HASS; Hussein F. NASRALLAH
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2014-11-18
Filing date: 2015-11-09
Publication date: 2016-05-19
Also published as: CN105610896A

Abstract

Ein Fahrzeugrechensystem mit mindestens einer Steuerung, die mit einem Transceiver kommuniziert. Die mindestens eine Steuerung ist dafür programmiert, ein drahtloses Signal, das einen ersten Anwendungsbezeichner für eine erste Anwendung, die in dem nomadischen Gerät gestartet werden soll, aufweist, zu konfigurieren. Die mindestens eine Steuerung ist ferner dafür programmiert, das drahtlose Signal, einschließlich des ersten Anwendungsbezeichners, über den Transceiver zu broadcasten.

Description

QUERBEZUG ZU VERWANDTEN ANMELDUNGEN
Diese Anmeldung ist eine Teil-Weiterführung der US-Anmeldung mit Serien-Nr.: 14/286,003, eingereicht am 23. Mai 2014, deren Offenbarung hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen wird.
TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft im Allgemeinen Fahrzeug-Infotainmentsysteme und insbesondere Systeme und Verfahren, die Anwendungen auf Mobilgeräten in Infotainmentsystemen benutzen.
ALLGEMEINER STAND DER TECHNIK
Die US-Patentschrift 7,324,833 offenbart im Allgemeinen ein Audiosystem, das ein elektronisches Gerät mit einer Anzeige, einem Speicher, einem Audiodatenspieler und einem Gehäusebauteil enthält, welches mindestens teilweise einen Hohlraum definiert, in dem der Speicher und der Audiodatenspieler befestigt sind. Das elektronische Gerät kann ein tragbarer MP3-Spieler sein. Das System kann außerdem einen Prozessor oder eine Playlist-Maschine enthalten, der bzw. die eine erste Playlist und eine zweite Playlist erhalten kann. In der Praxis kann die erste Playlist eine Auswahl von Audioinhalt mit einer entsprechenden Audiodatei enthalten, die im Speicher des elektronischen Geräts gespeichert ist. Das System kann außerdem ein Kraftfahrzeug mit einer Kraftfahrzeugtonanlage enthalten, die einen Lautsprecher und eine Tonanlagenkomponente im Armaturenbrett aufweist, welche über ein Kabel abnehmbar an das elektronische Gerät gekuppelt sein kann. Die Tonanlagenkomponente im Armaturenbrett kann eine Auswahlvorrichtung enthalten, die beispielsweise ein Knopf sein kann und ermöglicht, dass ein Benutzer die erste Playlist zum Ausgeben über den Lautsprecher auswählt. Das Kabel, das das elektronische Gerät und die Tonanlagenkomponente im Armaturenbrett miteinander verbindet, kann dazu imstande sein, das elektronische Gerät neben dem kommunikationsfähigen Kuppeln des elektronischen Geräts an die Fahrzeugtonanlage mit Strom zu versorgen.
Die US-Patentschrift 8,346,310 offenbart im Allgemeinen eine fahrzeugbasierte Rechenvorrichtung mit einem Computerprozessor in Kommunikation mit persistentem und nicht persistentem Speicher. Die Vorrichtung enthält außerdem einen lokalen drahtlosen Transceiver in Kommunikation mit dem Computerprozessor, der zum drahtlosen Kommunizieren mit einem drahtlosen Gerät konfiguriert ist, welches sich im Fahrzeug befindet. Der Prozessor ist zum Empfangen einer Verbindungsanforderung von einem mobilen drahtlosen Gerät über den drahtlosen Transceiver betriebsfähig, wobei die Verbindungsanforderung mindestens einen Namen einer Anwendung enthält, die die Kommunikation mit dem Prozessor sucht. Der Prozessor ist ferner zum Empfangen von mindestens einer sekundären Kommunikation vom nomadischen Gerät betriebsfähig, wenn die Verbindungsanforderung verarbeitet wurde. Die sekundäre Kommunikation ist mindestens eines von einem Sprechalarmbefehl, einem Anzeigentextbefehl, einem Satzerstellungsbefehl und einem Aufforderungs- und Anhörbefehl.
Die US-Patentanmeldung 2013/0102300 offenbart im Allgemeinen ein System zum automatischen Neustarten einer Anwendung, die auf einem Smartphone läuft, das in einer vorgegebenen Umgebung vorhanden ist, nachdem die Anwendung vorübergehend angehalten wurde. Eine Hardwareverbindungsvorrichtung kann zum Herstellen einer ersten Kommunikationsverbindung mit dem Smartphone und außerdem zum Herstellen einer zweiten Kommunikationsverbindung mit einem elektronischen Gerät konfiguriert sein, das in der vorgegebenen Umgebung vorhanden ist. Eine prozessorausführbare Autostartanwendung kann dazu imstande sein, auf dem Smartphone zum Erkennen, wenn eine vorher ausgewählte Anwendung angehalten und/oder vorübergehend angehalten wurde, und zum automatischen Neustarten der vorher ausgewählten Anwendung zu laufen, ohne dass ein Befehl durch einen Benutzer des Smartphones physisch in das Smartphone eingegeben wurde.
KURZDARSTELLUNG
In einer ersten veranschaulichenden Ausführungsform enthält ein Fahrzeugrechensystem mindestens eine Steuerung, die mit einem Transceiver kommuniziert. Die mindestens eine Steuerung ist dafür programmiert, ein drahtloses Signal zu konfigurieren, das einen ersten Anwendungsbezeichner für eine erste Anwendung, die in dem nomadischen Gerät gestartet werden soll, aufweist. Die mindestens eine Steuerung ist ferner dafür programmiert, das drahtlose Signal, einschließlich des ersten Anwendungsbezeichners, über den Transceiver zu broadcasten.
In einer zweiten veranschaulichenden Ausführungsform ist ein Computerprogrammprodukt enthalten, das in einem nichtflüchtigen, computerlesbaren Medium verkörpert ist, das zum Übertragen eines drahtlosen Signals zum Starten einer Anwendung in einem nomadischen Gerät programmiert ist. Das Computerprogrammprodukt umfasst ferner Anweisungen zum Konfigurieren eines drahtlosen Signals, das einen Anwendungsbezeichner für eine Anwendung, die in dem nomadischen Gerät gestartet werden soll, aufweist. Das Computerprogrammprodukt umfasst ferner Anweisungen zum Broadcasten des drahtlosen Signals, einschließlich des Anwendungsbezeichners, über einen Transceiver.
In einer dritten veranschaulichenden Ausführungsform ist ein Anwendungsstartverfahren zum Konfigurieren eines drahtlosen Signals enthalten. Das Verfahren kann das drahtlose Signal konfigurieren, das einen ersten Anwendungsbezeichner für eine erste Anwendung, die in einem nomadischen Gerät gestartet werden soll, aufweist. Das Verfahren kann das drahtlose Signal einschließlich des Anwendungsbezeichners über einen Transceiver broadcasten.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 ist eine beispielhafte Blocktopologie eines Fahrzeug-Infotainmentsystems, das ein benutzerinteraktives Fahrzeuginformationsanzeigesystem gemäß einer Ausführungsform implementiert;
2 ist eine beispielhafte Blocktopologie eines Systems zum Integrieren von einem oder mehreren verbundenen Geräten mit dem fahrzeugbasierten Rechensystem gemäß einer Ausführungsform;
3 ist eine beispielhafte Blocktopologie eines Systems zum automatischen Starten einer Anwendung beim Verbinden eines drahtlosen Geräts mit dem Fahrzeugrechensystem gemäß einer Ausführungsform;
4 ist ein Blockdiagramm, das das Fahrzeugrechensystem in Kommunikation mit dem nomadischen Gerät darstellt;
5 ist ein Ablaufdiagramm, das ein Beispielverfahren des Fahrzeugrechensystems, das ein iBeacon-Signal an das nomadische Gerät zum Starten der Anwendung kommuniziert, gemäß einer Ausführungsform darstellt;
6 ist ein Ablaufdiagramm, das ein Beispielverfahren des Fahrzeugrechensystems, das das iBeacon-Signal zum nomadischen Gerät zum Starten der Anwendung überträgt, gemäß einer Ausführungsform darstellt;
7 ist ein Ablaufdiagramm, das ein Beispielverfahren des nomadischen Geräts, das eine Anwendungsaufweckanforderung zum Starten der Anwendung empfängt, gemäß einer Ausführungsform darstellt;
8 ist ein Ablaufdiagramm, das ein Beispielverfahren des Fahrzeugrechensystems, das das iBeacon-Signal an das nomadische Gerät zum Starten der Anwendung kommuniziert, gemäß einer Ausführungsform darstellt;
9 ist ein Ablaufdiagramm, das ein Beispielverfahren eines Callcenters, das eine Push-Mitteilung zum Starten der Anwendung bei dem nomadischen Gerät überträgt, gemäß einer Ausführungsform darstellt;
10 ist ein Blockdiagramm, das das nomadische Gerät, das mit dem Fahrzeugrechensystem und Callcenter kommuniziert, gemäß einer Ausführungsform darstellt; und
11 ist ein Ablaufdiagramm, das ein Beispielverfahren des nomadischen Geräts, das mit dem Fahrzeugrechensystem und Callcenter kommuniziert, gemäß einer Ausführungsform darstellt.
12 ist ein Ablaufdiagramm, das ein Beispielverfahren darstellt, wie das Fahrzeugrechensystem einen drahtlosen Transceiver konfiguriert, einen vordefinierten Anwendungsbezeichner zu broadcasten.
DETAILLIERTE BESCHREIBUNG
Hierin sind Ausführungsformen der vorliegenden Offenbarung beschrieben. Es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich Beispiele sind und andere Ausführungsformen verschiedene und alternative Formen annehmen können. Die Figuren sind nicht notwendigerweise maßstabsgetreu; einige Merkmale könnten überhöht oder verkleinert sein, um Details bestimmter Komponenten zu zeigen. Daher sind hierin offenbarte, spezifische bauliche und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um den Fachmann zu lehren, die Ausführungsformen verschiedentlich umzusetzen. Wie für den Durchschnittsfachmann ersichtlich, können verschiedene Merkmale, die unter Bezugnahme auf beliebige der Figuren dargestellt und beschrieben sind, mit Merkmalen kombiniert werden, die in einer oder mehreren anderen Figuren dargestellt sind, um Ausführungsformen zu erzeugen, die nicht ausdrücklich dargestellt oder beschrieben sind. Die Kombinationen von dargestellten Merkmalen sehen repräsentative Ausführungsformen für typische Anwendungen vor. Verschiedene Kombinationen und Modifikationen der Merkmale, die mit den Lehren dieser Offenbarung konsistent sind, könnten jedoch für bestimmte Anwendungen oder Implementierungen erwünscht sein.
Die Ausführungsformen der vorliegenden Offenbarung sehen im Allgemeinen mehrere Schaltungen oder andere elektrische Geräte vor. Alle Bezugnahmen auf die Schaltungen und anderen elektrischen Geräte und die Funktionalität, die von jedem vorgesehen ist, sollen nicht zum Umfassen von nur dem hierin Dargestellten und Beschriebenen beschränkt sein. Während den verschiedenen Schaltungen oder anderen elektrischen Geräten bestimmte Bezeichnungen zugeordnet sein können, sollen derartige Bezeichnungen den Betriebsumfang für die Schaltungen und die anderen elektrischen Geräte nicht einschränken. Derartige Schaltungen und andere elektrische Geräte können auf jegliche Art und Weise auf Grundlage der bestimmten Art elektrischer Implementierung, die gewünscht ist, miteinander kombiniert und/oder voneinander getrennt sein. Es versteht sich, dass jegliche, hierin offenbarte Schaltung oder anderes elektrisches Gerät jegliche Anzahl von Mikroprozessoren, integrierten Schaltungen, Speichergeräten (beispielsweise FLASH, Direktzugriffsspeicher (RAM), Festwertspeicher (ROM), elektrisch programmierter Festwertspeicher (EPROM), elektrisch löschbarer programmierbarer Festwertspeicher (EEPROM) oder andere geeignete Varianten davon) und Software enthalten können, die zum Ausführen eines Betriebs (von Betrieben), die hierin offenbart sind, zusammenwirken können. Zudem kann ein beliebiges oder mehrere der elektrischen Geräte zum Ausführen eines Computerprogramms konfiguriert sein, das in einem nichtflüchtigen computerlesbaren Medium verkörpert ist und zum Ausführen von jeglicher Anzahl der Funktionen wie offenbart programmiert ist.
Ein Fahrzeug kann ein Rechensystem enthalten, das zum Ermöglichen einer Kommunikationsverbindung zwischen einem oder mehreren drahtlosen Geräten (d.h. nomadischen Geräten) konfiguriert ist. Das nomadische Gerät kann mit dem Fahrzeugrechensystem unter Verwendung von drahtloser und/oder verdrahteter Technologie kommunizieren. Die Kommunikationsverbindung ermöglicht es dem Fahrzeugrechensystem, sich mit (einer) Anwendung(en) im nomadischen Gerät zu verbinden. Die Information, die über die Anwendung(en) zwischen dem Fahrzeugrechensystem und dem nomadischen Gerät kommuniziert wird, kann Internetradio, soziale Medieninformation und/oder Navigationsdaten enthalten. Die Anwendungen können außerdem fahrersicherheitsbezogene Information enthalten, darunter u.a. 24-Stunden-Pannenhilfe, 911 ASSIST^TM und/oder andere Callcenterdienste enthalten.
Die eine oder die mehreren Anwendungen im nomadischen Gerät können verschiedene Betriebszustände aufweisen, darunter u.a. ermöglichtes Laufen im Vordergrund, ermöglichtes Laufen im Hintergrund und/oder abgeschaltet. Der Anwendungsbetriebszustand kann bestimmen, ob das Fahrzeugrechensystem Daten empfangen kann, wenn die Kommunikation mit dem nomadischen Gerät hergestellt ist. Das Fahrzeugrechensystem kann erfordern, dass die Anwendung im Smartphone aktiviert ist und im Vordergrund läuft, sodass das System mit der Anwendung kommunizieren kann. Beispielsweise kann (können), wenn das nomadische Gerät, wie etwa ein Smartphone, Kommunikation mit dem Fahrzeugrechensystem herstellt, die Anwendung(en), die entweder im Hintergrund läuft (laufen) und/oder im Smartphone deaktiviert ist (sind), keine Daten mit dem Fahrzeugrechensystem kommunizieren.
Das Verfahren und System zum Initiieren (d.h. Starten) einer Anwendung im nomadischen Gerät, wenn Kommunikation mit dem Fahrzeugrechensystem hergestellt ist, kann in dieser Schrift offenbart sein. Das Fahrzeugrechensystem enthält eine oder mehrere Anwendungen, die in der Hardware des Systems zum Kommunizieren mit dem nomadischen Gerät ausgeführt werden. Das Fahrzeugrechensystem kann mit dem nomadischen Gerät auf Grundlage von einer oder mehreren drahtlosen Technologien kommunizieren. Diese Offenbarung kann es dem Fahrzeugrechensystem ermöglichen, ein Mittel zum Senden von Aufweckmitteilungen an das nomadische Gerät unter Verwendung von drahtloser Technologie (beispielsweise Bluetooth Low Energy) vorzusehen. Diese Offenbarung kann es dem Fahrzeugrechensystem außerdem ermöglichen, automatisch eine oder mehrere Anwendungen im nomadischen Gerät über die Mitteilung zu starten.
1 stellt eine Beispielblocktopologie für ein fahrzeugbasiertes Rechensystem 1 (VCS) für ein Fahrzeug 31 dar. Ein Beispiel eines derartigen fahrzeugbasierten Rechensystems 1 ist das SYNC System, das von THE FORD MOTOR COMPANY hergestellt wird. Ein Fahrzeug, das mit einem fahrzeugbasierten Rechensystem ausgerüstet ist, kann eine visuelle Frontend-Benutzeroberfläche 4 enthalten, die sich im Fahrzeug befindet. Der Benutzer kann außerdem dazu imstande sein, mit der Benutzeroberfläche zu interagieren, wenn sie beispielsweise mit einem berührungsempfindlichen Bildschirm versehen ist. In einer anderen veranschaulichenden Ausführungsform erfolgt die Interaktion durch Knopfdrücken, Sprachdialogsystem mit automatischer Spracherkennung und Sprachsynthese.
In der veranschaulichenden Ausführungsform 1, die in 1 gezeigt ist, steuert ein Prozessor 3 mindestens einigen Anteil des Betriebs des fahrzeugbasierten Rechensystems. Der Prozessor, der innerhalb des Fahrzeugs vorgesehen ist, ermöglicht bordinternes Verarbeiten von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit einem nichtpersistenten 5 als auch persistenten Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der nichtpersistente Speicher ein Direktzugriffsspeicher (RAM) und der persistente Speicher ein Festplattenlaufwerk (HDD) oder Flash-Speicher. Im Allgemeinen kann der persistente (nichtflüchtige) Speicher alle Formen von Speicher beinhalten, die Daten erhalten, wenn ein Rechner oder anderes Gerät abgeschaltet wird. Diese enthalten u.a. HDDs, CDs, DVDs, Magnetbänder, Festkörperlaufwerke, tragbare USB-Sticks und jegliche andere geeignete Form von persistentem Speicher.
Der Prozessor ist außerdem mit einer Anzahl von verschiedenen Eingängen versehen, die es dem Benutzer ermöglichen, sich mit dem Prozessor zu verbinden. In dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, ein zusätzlicher Eingang 25 (für Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, Bildschirm 4, der eine Berührungsbildschirmanzeige sein kann, und ein BLUETOOTH-Eingang 15 alle vorgesehen. Ein Eingangsauswähler 51 ist ebenfalls vorgesehen, um es dem Benutzer zu ermöglichen, zwischen den verschiedenen Eingängen zu schalten. Eingabe sowohl ins Mikrofon als auch zum zusätzlichen Verbinder wird durch einen Konverter 27 von analog auf digital umgewandelt, bevor sie zum Prozessor weitergeleitet wird. Obgleich nicht gezeigt, können zahlreiche der Fahrzeugkomponenten und zusätzlichen Komponenten in Kommunikation mit dem VCS ein Fahrzeugnetz (wie etwa u.a. einen CAN-Bus) zum Weiterleiten von Daten zum und vom VCS (oder Komponenten davon) benutzen.
Ausgänge zum System können u.a. eine visuelle Anzeige 4 und einen Lautsprecher 13 oder Stereosystemausgang beinhalten. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal vom Prozessor 3 über einen D/A-Konverter 9. Ausgabe kann außerdem zu einem entlegenen BLUETOOTH-Gerät, wie etwa PND 54, oder einem USB-Gerät, wie etwa einem Fahrzeugnavigationsgerät 60, entlang der bidirektionalen Datenströme, die bei 19 bzw. 21 gezeigt sind, erfolgen.
In einer veranschaulichenden Ausführungsform benutzt das System 1 den BLUETOOTH-Transceiver 15 zum Kommunizieren 17 mit einem nomadischen Gerät 53 (beispielsweise Mobiltelefon, Smartphone, PDA oder jegliches andere Gerät mit drahtloser entlegener Netzkonnektivität) des Benutzers. Das nomadische Gerät kann dann zum Kommunizieren 59 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 beispielsweise über Kommunikation 55 mit einem Zellfunkturm 57 benutzt werden. In einigen Ausführungsformen kann der Turm 57 ein WiFi-Zugangspunkt sein.
Beispielhafte Kommunikation zwischen dem nomadischen Gerät und dem BLUETOOTH-Transceiver ist durch Signal 14 dargestellt.
Paarung eines nomadischen Geräts 53 und des BLUETOOTH-Transceivers 15 kann über einen Knopf 52 oder eine ähnliche Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der bordinterne BLUETOOTH-Transceiver mit einem BLUETOOTH-Transceiver in einem nomadischen Gerät gepaart wird.
Daten können zwischen CPU 3 und Netzwerk 61 beispielsweise unter Nutzung eines Datenplans, Daten über Sprache oder DTMF-Töne, die dem nomadischen Gerät 53 zugeordnet sind, kommuniziert werden. Alternativ kann es wünschenswert sein, ein bordinternes Modem 63 mit Antenne 18 zum Kommunizieren 16 von Daten zwischen der CPU 3 und dem Netzwerk 16 über das Sprachband zu beinhalten. Das nomadische Gerät 53 kann zum Kommunizieren 59 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 beispielsweise über Kommunikation 55 mit einem Zellfunkturm 57 benutzt werden. In einigen Ausführungsformen kann das Modem 63 Kommunikation 20 mit dem Turm 57 zum Kommunizieren mit dem Netzwerk 61 herstellen. Als nicht einschränkendes Beispiel kann das Modem 63 ein USB-Zellfunkmodem sein, und die Kommunikation 20 kann Zellfunkkommunikation sein.
In einer veranschaulichenden Ausführungsform ist der Prozessor mit einem Betriebssystem mit einer API zum Kommunizieren mit Modemanwendungssoftware versehen. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder Firmware im BLUETOOTH-Transceiver zugreifen, um die drahtlose Kommunikation mit einem entlegenen BLUETOOTH-Transceiver (wie jener, der im nomadischen Gerät zu finden ist) fertigzustellen. Bluetooth ist ein Teilsatz der IEEE 802 PAN (Personal Area Network) Protokolle. IEEE 802 LAN (Local Area Network) Protokolle beinhalten WiFi und weisen erhebliche übergreifende Funktionalität mit IEEE 802 PAN auf. Beide sind zur drahtlosen Kommunikation innerhalb eines Fahrzeugs geeignet. Ein anderes Kommunikationsmittel, das in diesem Bereich benutzt werden kann, ist optische Freiraumkommunikation (wie etwa IrDA) und nichtstandardisierte IR-Verbraucherprotokolle.
In einer anderen Ausführungsform enthält das nomadische Gerät 53 ein Modem für Sprachband- oder Breitbanddatenkommunikation. In der Daten-über-Sprache-Ausführungsform kann eine Technik, die als Frequenzmultiplex-Verfahren bekannt ist, implementiert sein, wenn der Besitzer des nomadischen Geräts über das Gerät sprechen kann, während Daten übertragen werden. Zu einem anderen Zeitpunkt, wenn der Besitzer das Gerät nicht benutzt, kann die Datenübertragung die gesamte Bandbreite benutzen (beispielsweise 300 Hz bis 3,4kHz). Während das Frequenzmultiplex-Verfahren für analoge Zellfunkkommunikation zwischen dem Fahrzeug und dem Internet üblich sein kann und weiterhin benutzt wird, wurde es doch weitgehend durch Hybridformen von Code Domain Multiple Access (CDMA), Time Domain Multiple Access (TDMA), Space-Domain Multiple Access (SDMA) für digitale Zellfunkkommunikation ersetzt. Diese sind alle ITU IMT-2000 (3G) erfüllende Standards und bieten Datenübertragungsgeschwindigkeiten bis zu 2 mbs für stillstehende oder gehende Benutzer und 385 kbs für Benutzer in einem sich bewegenden Fahrzeug. 3G Standards werden nun durch IMT-Advanced (4G) ersetzt, das 100 mbs für Benutzer in einem Fahrzeug und 1 gbs für stillstehende Benutzer bietet. Falls der Benutzer einen dem nomadischen Gerät zugeordneten Datenplan aufweist, ist es möglich, dass der Datenplan Breitbandübertragung ermöglicht und das System eine viel breitere Bandbreite benutzen könnte (wodurch die Datenübertragung beschleunigt wird). In wiederum einer anderen Ausführungsform ist das nomadische Gerät 53 durch ein zelluläres Kommunikationsgerät (nicht gezeigt) ersetzt, das im Fahrzeug 31 eingerichtet ist. In wiederum einer anderen Ausführungsform kann das ND 53 ein drahtloses LAN-Gerät sein, das zur Kommunikation über beispielsweise (und ohne Einschränkung) ein 802.11g Netz (d.h. WiFi) oder ein WiMax-Netz imstande ist.
In einer Ausführungsform können ankommende Daten durch das nomadische Gerät über Daten-über-Sprache oder einen Datenplan durch den bordinternen BLUETOOTH-Transceiver und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Falle von bestimmten zeitweiligen Daten können die Daten beispielsweise im HDD oder anderen Speichermedien 7 gespeichert werden, bis die Daten nicht länger benötigt werden.
Zusätzliche Quellen, die sich mit dem Fahrzeug verbinden können, beinhalten ein persönliches Navigationsgerät 54, das beispielsweise eine USB-Verbindung 56 und/oder eine Antenne 58 aufweist, ein Fahrzeugnavigationsgerät 60 mit einer USB- 62 oder anderen Verbindung, ein bordinternes GPS-Gerät 24 oder entlegenes Navigationssystem (nicht gezeigt) mit Konnektivität zum Netzwerk 61. USB ist eines einer Klasse von seriellen Vernetzungsprotokollen. IEEE 1394 (FireWire^TM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), EIA (Electronics Industry Association) serielle Protokolle, IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Standards von Gerät zu Gerät. Die meisten Protokolle können für entweder elektrische oder optische Kommunikation benutzt werden.
Ferner könnte die CPU in Kommunikation mit vielerlei anderen zusätzlichen Geräten 65 stehen. Diese Geräte können über eine drahtlose 67 oder verdrahtete 69 Verbindung verbunden sein. Das zusätzliche Gerät 65 kann u.a. persönliche Medienabspieler, drahtlose Gesundheitsgeräte, tragbare Rechner und dergleichen beinhalten.
Außerdem oder alternativ könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 verbunden sein, beispielsweise unter Benutzung eines WiFi (IEEE 803.11) 71 Transceivers. Dies könnte es der CPU ermöglichen, sich mit entlegenen Netzwerken im Bereich des lokalen Routers 73 zu verbinden.
Neben dem Ausführenlassen von Beispielprozessen durch ein Fahrzeugrechensystem, das sich in einem Fahrzeug befindet, können die Beispielprozesse in bestimmten Ausführungsformen durch ein Rechensystem in Verbindung mit einem Fahrzeugrechensystem ausgeführt werden. Ein derartiges System kann u.a. ein drahtloses Gerät (beispielsweise u.a. ein Mobiltelefon) oder ein entlegenes Rechensystem (beispielsweise u.a. einen Server) beinhalten, das über das drahtlose Gerät verbunden ist. Kollektiv können derartige Systeme als fahrzeugzugehörige Rechensysteme (VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS bestimmte Anteile eines Prozesses abhängig von der bestimmten Implementierung des Systems ausführen. Als Beispiel und nicht als Einschränkung ist es, wenn ein Prozess einen Schritt des Sendens oder Empfangens von Information mit einem gepaarten drahtlosen Gerät aufweist, wahrscheinlich, dass das drahtlose Gerät den Prozess nicht ausführt, da das drahtlose Gerät Information nicht mit sich selbst „senden und empfangen“ würde. Der Durchschnittsfachmann wird verstehen, wann es unangemessen ist, ein bestimmtes VACS auf eine jeweilige Lösung auszuüben. Bei allen Lösungen ist berücksichtigt, dass mindestens das Fahrzeugrechensystem (VCS), das sich innerhalb des Fahrzeugs selbst befindet, zum Ausführen der Beispielprozesse imstande ist.
2 ist eine Beispielblocktopologie eines Systems 100 zum Integrieren von einem oder mehreren verbundenen Geräten in das VCS 1. Die CPU 3 kann mit einem oder mehreren Transceivern in Verbindung stehen. Der eine oder die mehreren Transceiver sind zur verdrahteten und drahtlosen Kommunikation zur Integration von einem oder mehreren Geräten imstande. Zum Erleichtern der Integration kann die CPU 3 ein Geräteintegrationsgerüst 101 enthalten, das zum Vorsehen von verschiedenen Diensten für die verbundenen Geräte konfiguriert ist. Diese Dienste können das Transportrouten von Nachrichten zwischen den verbundenen Geräten und der CPU 3, globale Benachrichtigungsdienste zum Ermöglichen, dass verbundene Geräte dem Benutzer Warnungen zuleiten, Anwendungsstart- und -verwaltungseinrichtungen zum Ermöglichen von vereinheitlichtem Zugriff auf Anwendungen, die von der CPU 3 ausgeführt werden, und jene, die von den verbundenen Geräten ausgeführt werden, Unfallerkennungsmitteilung (d.h. 911 ASSIST^TM) und Sonderzielauffindungs- und -verwaltungsdienste für verschiedene mögliche Ziele des Fahrzeugs 31 beinhalten.
Wie oben angegeben kann die CPU 3 des VCS 1 dazu konfiguriert sein, sich mit einem oder mehreren nomadischen Geräten 53 verschiedener Arten zu verbinden. Das nomadische Gerät 53 kann ferner eine Geräteintegrationsclientkomponente 103 beinhalten, um es dem nomadischen Gerät 53 (beispielsweise Smartphone) zu ermöglichen, die Dienste, die vom Geräteintegrationsgerüst 101 vorgesehen sind, zu nutzen. Die Geräteintegrationsclientkomponente 103 kann als Anwendung bezeichnet werden. Die Anwendung wird auf Hardware des nomadischen Geräts 53 ausgeführt. Die Anwendung kann Daten vom nomadischen Gerät über den Transceiver zum VCS 1 kommunizieren.
Der eine oder die mehreren Transceiver können einen Multiport-Verbinderhub 102 enthalten. Der Multiport-Verbinderhub 102 kann zum Verbinden zwischen der CPU 3 und zusätzlichen Arten von verbundenen Geräten neben den nomadischen Geräten 53 benutzt werden. Der Multiport-Verbinderhub 102 kann mit der CPU 3 über verschiedene Busse und Protokolle, wie etwa über USB, kommunizieren und ferner mit den verbundenen Geräten unter Benutzung verschiedener anderer Busse und Protokolle kommunizieren, wie etwa Serial Peripheral Interface Bus (SPI), Inter-integrated circuit (I2C) und/oder Universal Asynchronous Receiver/Transmitter (UART). Der Multiport-Verbinderhub 102 kann ferner Kommunikationsprotokollübersetzung und Netzübergangsdienste zwischen den Protokollen, die von den verbundenen Geräten benutzt werden, und dem Protokoll, das zwischen dem Multiport-Verbinderhub 102 und der CPU 3 benutzt wird, ausführen. Die verbundenen Geräte können, als nicht einschränkende Beispiele, einen Radardetektor 104, ein globales Positionsempfängergerät 106 und ein Speichergerät 108 enthalten.
3 ist eine Beispielblocktopologie eines Systems zum automatischen Starten der Anwendung im nomadischen Gerät 53 beim Verbinden mit dem VCS 1 gemäß einer Ausführungsform. Das nomadische Gerät 53 kann mindestens einen Prozessor 202, ein Betriebssystem 204, einen Transceiver (nicht gezeigt) und einen Speicher 206 zum Speichern von einer oder mehreren Anwendungen 208 beinhalten. Das VCS 1 kann u.a. einen Prozessor 3, einen Speicher 5, das Benutzeroberflächensystem (d.h. die Berührungsbildschirmanzeige 4) und den Transceiver 15 (beispielsweise drahtlosen Bluetooth-Transceiver) enthalten.
Das VCS 1 kann Hardwarekomponenten des Systems auf Grundlage eines Aufweckanzeigers (nicht gezeigt) initialisieren und/oder aktivieren. Der Aufweckanzeiger kann u.a. eine Fahrzeugstartanforderung, ein Berühren oder Ziehen eines Türgriffs, ein Signal, das von einem Sitzsensor empfangen wird, und/oder eine Kombination davon enthalten. Der Aufweckanzeiger kann einen oder mehrere Transceiver des VCS 1 zum Rundsenden eines Signals 14 zum Suchen des nomadischen Geräts in der Nähe des Fahrzeugs 31 aktivieren. Beispielsweise kann das VCS 1 zum Übertragen des Signals 14 (beispielsweise Bluetooth Low Energy, Near Field Communication usw.) in einem vordefinierten periodischen Intervall, in einem vordefinierten kontinuierlichen Intervall und/oder einer Kombination davon konfiguriert sein. In einem anderen Beispiel kann das VCS 1 über eine verdrahtete Verbindung 21 mit dem nomadischen Gerät 53 kommunizieren. Das VCS kann ein Broadcast-Signal über die verdrahtete Verbindung 21 übertragen. Beispielsweise kann das VCS 1, wenn ein Benutzer das nomadische Gerät 53 über eine verdrahtete Verbindung verbindet, eine Mitteilung zum Aufwecken/Initialisieren von einer oder mehreren Anwendungen im nomadischen Gerät 53 vortreiben. Die Mitteilung kann u.a. einen eindeutigen Bezeichner beinhalten, der der einen oder den mehreren Anwendungen zugeordnet ist.
Das drahtlose gesendete Signal 14 kann durch den drahtlosen Transceiver 15 erzeugt werden. Das drahtlose Broadcast-Signal 14 kann dem nomadischen Gerät 53 das Vorhandensein des VCS 1 anzeigen. Beispielsweise kann der drahtlose Transceiver 15 u.a. iBeacon-Broadcast beinhalten. Der drahtlose Transceiver, der das iBeacon-Signal erzeugt, kann u.a. einen leistungsarmen drahtlosen Transceiver 15 beinhalten. Der iBeacon-Broadcast, der durch den drahtlosen Transceiver 15 erzeugt ist, kann eine Push-Mitteilung an die nomadischen Geräte (d.h. drahtlosen Geräte) in enger Nähe des VCS 1 senden.
Der iBeacon kann Bluetooth Low Energy (BLE) Näheerkennung zum Übertragen eines universal eindeutigen Bezeichners (UUID) benutzen. Der UUID ist ein Bezeichnerstandard, der zum eindeutigen Bezeichnen der Anwendung im nomadischen Gerät 53, das dem VCS 1 zugeordnet ist, benutzt werden kann. Beispielsweise kann das nomadische Gerät 53 eine Anwendung mit dem UUID (beispielsweise einen Bezeichner mit 64 Hexadezimalzeichen) enthalten.
Das VCS 1 kann einen Aufweckindikator zum Beginnen des iBeacon-Broadcast empfangen, der den UUID aufweist. Der iBeacon-Broadcast an ein oder mehrere nomadische Geräte 53 in der Nähe des Fahrzeugs 31 übertragen werden. Der iBeacon-Broadcast kann den UUID enthalten, der der Anwendung zugeordnet ist, welche im nomadischen Gerät 53 gespeichert ist.
Das nomadische Gerät 53 kann den UUID empfangen, in dem das Betriebssystem 204 arbeiten kann. Das nomadische Gerät 53 kann bestimmen, ob eine Anwendung 208 mit dem UUID übereinstimmt. Wenn eine Übereinstimmung aufgefunden wird, kann das nomadische Gerät 53 die Anwendung starten. Das nomadische Gerät 53 kann die Anwendung über den iBeacon-UUID in mehreren Betriebszuständen starten, darunter u.a. Laufen im Hintergrund, ausgesetzt und/oder in einem beendeten Zustand.
Wenn die Anwendung gestartet ist, kann das nomadische Gerät 53 Daten an das VCS 1 übertragen, um anzuzeigen, dass die Anwendung ausgeführt wird. Beispielsweise kann das nomadische Gerät 53, unter Rückbezug auf die Unfallmitteilungsanwendung, das VCS 1 darauf hinweisen, dass die Anwendung überwacht, ob sich ein Unfall ereignet hat. Das nomadische Gerät 53 kann über ein generisches Attributprofilprotokoll (d.h. GATT) Daten an den VCS 1 senden und/oder von dort empfangen.
Das VCS 1 kann über einen oder mehrere Sensoren überwachen, ob sich ein Unfall ereignet hat. Wenn ein Unfall erkannt wird, kann das VCS 1 eine Nachricht über das drahtlose Signal 14 zum nomadischen Gerät 53 übertragen. Beispielsweise kann die 911 ASSIST^TM Anwendung 208 im nomadischen Gerät 53 auf Grundlage des iBeacon-Broadcastsignals bereits aktiviert sein, sodass die empfangene Nachricht verarbeitet und von der Anwendung zum Anweisen des Geräts zum Kontaktieren eines Callcenters 210 benutzt werden kann.
In einem anderen Beispiel kann das VCS über einen oder mehrere Sensoren überwachen, um zu bestimmen, ob sich ein Unfall ereignet hat. Wenn ein Unfall erkannt wird, kann das VCS 1 den iBeacon, der den UUID umfasst, zum Ausführen der 911 ASSIST^TM Anwendung 208 zum nomadischen Gerät 53 übertragen. Wenn die 911 ASSIST^TM Anwendung 208 ausgeführt wird, kann das nomadische Gerät 53 Unfallinformationen empfangen. Das nomadische Gerät 53 kann die Unfallinformationen zum Callcenter 210 übertragen.
In einem anderen Beispiel kann das VCS 1 ein eingebettetes Zellmodem (nicht gezeigt) aufweisen, sodass, wenn ein Unfall erkannt wird, das System die Unfallinformationsdaten über ein drahtloses Signal 19 an ein Netzwerk in Kommunikation mit dem Callcenter 210 übertragen kann. In diesem Beispiel kann das VCS 1 außerdem den iBeacon an das nomadische Gerät 53 zum Aktivieren von Mitteilungsinformation nach einem Zusammenstoß an einen oder mehrere vordefinierte Kontakte über die 911 ASSIST^TM Anwendung 208 übertragen. Wenn die Anwendung 208 aktiviert ist, kann das System Mitteilungsinformation nach einem Zusammenstoß über das nomadische Gerät 53 an einen oder mehrere vordefinierte/vorkonfigurierte Kontakte übertragen. Die 911 ASSIST^TM Anwendung 208 kann diese Information unter Benutzung von SMS, Textnachrichten, E-Mails und/oder soziale Medienplattformen an einen oder mehrere vorkonfigurierte Kontakte weiterleiten.
4 ist ein Blockdiagramm, das das VCS 1 in Kommunikation mit dem nomadischen Gerät 53 darstellt. Das VCS 1 kann eine drahtlose Verbindung mit dem nomadischen Gerät 53 herstellen. Das VCS 1 kann mit einer oder mehreren Anwendungen im nomadischen Gerät 53 kommunizieren. Das VCS 1 kann eine oder mehrere Anwendungen aufweisen, die in Hardware des Systems zum Vorsehen des Broadcast-Signals ausgeführt werden. Das Broadcast-Signal kann zum automatischen Starten einer Anwendung benutzt werden, die im nomadischen Gerät 53 gespeichert ist.
Das VCS 1 kann eine Anforderung zum Initialisieren 302 des drahtlosen Bluetooth-Transceivers 15 auf Grundlage des Aufwecksignals, eines vordefinierten periodischen Broadcast-Impulses und/oder einer Kombination davon übertragen. Der drahtlose Bluetooth-Transceiver 15 kann ein drahtloses Protokoll 304, wie etwa iBeacon, zum Vorsehen eines Mittels zum Senden von Mitteilungen an das nomadische Gerät 53 senden. Der iBeacon-Broadcast kann einen definierten UUID aufweisen. Der UUID kann durch einen Originalausstattungshersteller definiert sein. Beispielsweise kann der UUID willkürlich mit einem üblichen Werkzeug erstellt werden, das in den meisten Betriebssystemen verfügbar ist. Der UUID wird willkürlich erstellt und ist lang genug, dass es unwahrscheinlich ist, dass der UUID dupliziert würde.
Das nomadische Gerät 53 (beispielsweise Smartphone, Tablet usw.) kann den UUID über iBeacon 306 empfangen 306. Das nomadische Gerät 53 kann in der Betriebssystemsoftwaredatenbank nach der mobilen Anwendung suchen, die mit dem UUID übereinstimmt 308, der vom VCS 1 empfangen wurde. Das nomadische Gerät 53 kann die Anwendung finden, die dem UUID zugeordnet ist, der vom VCS 1 empfangen wurde. Das nomadische Gerät 53 kann die Anwendung mit dem UUID starten 310, selbst wenn die Anwendung im Hintergrund ist, ausgesetzt ist, beendet ist und/oder das Smartphone blockiert ist.
Das nomadische Gerät 53 kann eine Kommunikationsverbindung 312 über das drahtlose Protokoll (d.h. iBeacon) unter Benutzung des Bluetooth-Dienstes der mobilen Anwendung herstellen. Die mobile Anwendung, die im nomadischen Gerät 53 gestartet wird, kann Anwendungsdaten 314a an das VCS 1 übertragen. Die Anwendungsdaten können u.a. ein Statusbit enthalten, das das VCS 1 informiert, dass die Anwendung läuft. Der drahtlose Bluetooth-Transceiver 15 kann die Anwendungsdaten 314b an den einen oder die mehreren Prozessoren im VCS 1 zur Ausführung übertragen.
Das VCS 1 kann ein oder mehrere Systeme enthalten, die melden, verhindern und/oder erkennen, wenn sich ein Unfall ereignet hat. Das eine oder die mehreren Systeme können u.a. ein Airbagentfaltungssystem, ein Bremsassistenzsystem und/oder ein Traktionskontrollsystem enthalten. Das VCS 1 kann das eine oder die mehreren Systeme überwachen, um zu bestimmen, ob sich das Fahrzeug in einem Unfall befunden hat. Wenn das VCS 1 erkennt, dass sich ein Unfall ereignet hat, kann das VCS 1 Unfalldaten 318a zur Übertragung an das nomadische Gerät 53 erstellen. Der Bluetooth-Transceiver 15 kann die Unfalldaten 318b an das nomadische Gerät 53 übertragen. Das nomadische Gerät 53 kann die Unfalldaten empfangen und die Daten 318c über die mobile Anwendung ausführen.
Die Anwendung kann mehrere Merkmale und Funktionen enthalten, darunter u.a. Kontaktieren des Callcenters, Senden von Daten an das Callcenter, Erstellen und Senden von Nachrichten an einen oder mehrere Kontakte, einen oder mehrere Kontakte telefonisch anrufen und/oder eine Kombination davon. Die Anwendung kann zusätzliche Daten 320a, 320b, 320c bezüglich Fahrzeuginformation und Insasseninformation vom VCS 1 anfordern.
Beispielsweise kann die Anwendung, wenn ein Unfall durch das VCS 1 erkannt wurde, Breiten- und Längengradinformation des Unfallorts anfordern. Die Anwendung kann außerdem Insassendaten anfordern, darunter u.a. Sicherheitsgurtstatus. Das VCS 1 kann die zusätzlichen Daten 322a, 322b, 322c, die von der Anwendung angefordert sind, übertragen.
Die Anwendung kann Softwareanweisungen zur Ausführung auf Hardware im nomadischen Gerät 53 zum Übertragen der Unfallort- und Insassendaten an das Callcenter vorsehen. Die Anwendung kann außerdem Softwareanweisungen zur Ausführung auf Hardware im nomadischen Gerät zum Erstellen von Benachrichtigungsmitteilungen nach dem Zusammenstoß an Freunde und Familie über SMS und/oder eine Infrastruktur sozialer Netze vorsehen.
5 ist ein Ablaufdiagramm, das ein Beispielverfahren 400 des Fahrzeugrechensystems, welches einen Push zum nomadischen Gerät 53 zum Starten der Anwendung kommuniziert, gemäß einer Ausführungsform darstellt. Das Verfahren 400 kann unter Benutzung von Softwarecode implementiert werden, der innerhalb des VCS 1 enthalten ist. In anderen Ausführungsformen kann das Verfahren 400 in anderen Fahrzeugsteuerungen implementiert sein oder auf mehrere Fahrzeugsteuerungen verteilt sein.
Unter erneuter Bezugnahme auf 5 wird während der Besprechung des Verfahrens auf das Fahrzeug und seine Komponenten, die in 1 und 2 dargestellt sind, Bezug genommen, um das Verständnis verschiedener Aspekte der vorliegenden Offenbarung zu erleichtern. Das Verfahren 400 zum Starten der Anwendung im nomadischen Gerät über eine Kommunikationsverbindung mit dem VCS kann über einen Computeralgorithmus, maschinenausführbaren Code, oder Softwareanweisungen implementiert werden, die in (einem) geeigneten programmierbaren Logikgerät(en) des Fahrzeugs programmiert sind, wie etwa dem Fahrzeugsteuermodul, dem Gerätesteuermodul, einer anderen Steuerung in Kommunikation mit dem Fahrzeugrechensystem oder einer Kombination davon. Obgleich die verschiedenen Betriebsvorgänge, die im Ablaufdiagramm 400 gezeigt sind, in einer chronologischen Abfolge vor sich zu gehen scheinen, können mindestens einige der Betriebsvorgänge in einer anderen Reihenfolge vor sich gehen, und einige Betriebsvorgänge können gleichzeitig oder überhaupt nicht ausgeführt werden.
Beim Betriebsvorgang 402 kann ein Benutzer das VCS 1 durch Einschalten einer Anstellanforderung eines Fahrzeugzündungssystems initialisieren. Die Anstellanforderung ermöglicht es dem VCS 1, mehrere Systeme, Untersysteme, Hardwarekomponenten und/oder Softwareroutinen zu initialisieren.
Beim Betriebsvorgang 404 kann das VCS 1 die iBeacon-Übertragung über BLE senden. Das iBeacon-Protokoll kann eine oder mehrere Anwendungen im nomadischen Gerät 53 aufwecken. Der iBeacon kann einen UUID übertragen, sodass einer kompatiblen Anwendung oder einem Betriebssystem befohlen werden kann, Tätigkeit im nomadischen Gerät 53 auszulösen. Das nomadische Gerät 53 (d.h. nomadische Gerät) kann den iBeacon-Broadcast vom VCS 1 empfangen. Die mobile Anwendung und das VCS sind über BLE nach dem Durchlaufen der angemessenen Sicherheits-Handshakes und -protokolle bei Betriebsvorgang 406 verbunden.
Beim Betriebsvorgang 408 kann das VCS 1 Bestätigung vom nomadischen Gerät 53 empfangen, dass der iBeacon empfangen und/oder die kompatible Anwendung gestartet wurde. Das VCS 1 kann bei Betriebsvorgang 410 periodisch prüfen, dass die mobile Anwendung im Hintergrund läuft und mit dem VCS 1 kommuniziert.
In einem Beispiel kann das VCS 1 einen Sicherheitsprozess zum Gewährleisten implementieren, dass die Kommunikation mit der mobilen Anwendung zum Gebrauch im Fahrzeug annehmbar ist. Das VCS 1 kann einen Token zum Authentifizieren des nomadischen Geräts übertragen. Der Token gewährleistet, dass das nomadische Gerät zum Kommunizieren mit dem VCS1 akzeptabel ist. In einem anderen Beispiel kann ein Nachrichtenprotokoll zum Codieren von Nachrichten, die zwischen dem nomadischen Gerät 53 und dem VCS 1 ausgetauscht werden, zum Befehlen und Steuern von autorisierter Kommunikation benutzt werden.
Beim Betriebsvorgang 412 kann das VCS 1 einen Zusammenstoß erkennen und eine Unfallmitteilung über BLE GATT Dienste an die mobile Anwendung übertragen. Das VCS 1 kann zusätzliche Daten, darunter u.a. Fahrzeuginformation und Insasseninformation, über die BLE GATT Dienste übertragen.
Beim Betriebsvorgang 414 kann das VCS 1 Bestätigung erhalten, dass die mobile Anwendung die Daten vom VCS 1 empfängt und (eine) Mitteilungsfunktion(en) nach dem Zusammenstoß entsprechend ausführt. Beispielsweise kann das System, wenn das VCS 1 erkennt, dass sich ein Unfall ereignet hat, Daten über BLE GATT Dienste an das nomadische Gerät 53 übertragen. Die Daten können u.a. Breiten- und Längengradinformation beinhalten. Die mobile Anwendung kann die Daten, die vom VCS 1 empfangen wurden, an das Callcenter übertragen. Die mobile Anwendung kann außerdem Daten, die vom VCS 1 empfangen wurden, über Mitteilung nach dem Zusammenstoß an Freunde und Familie übertragen.
Beim Betriebsvorgang 416 kann das VCS die Kommunikation mit dem nomadischen Gerät 53 auf Grundlage mehrerer Faktoren, darunter u.a. der Standort des nomadischen Geräts 53 und/oder die Anforderung an das VCS 1, sich abzuschalten, unterbrechen. Es ist zu beachten, dass die mobile Anwendung im nomadischen Gerät weiterhin eine oder mehrere Mitteilungen nach dem Zusammenstoß an vordefinierte Kontakte erstellen und übertragen kann, nachdem die Kommunikation mit dem VCS 1 unterbrochen wurde.
6 ist ein Ablaufdiagramm, das ein Beispielverfahren 500 des Fahrzeugrechensystems, das einen iBeacon zum Starten einer mobilen Anwendung im nomadischen Gerät 53 (d.h. nomadischen Gerät) überträgt, gemäß einer Ausführungsform darstellt. Das VCS 1 kann den iBeacon auf Grundlage von einer oder mehreren vorkonfigurierten Bedingungen, darunter u.a. das Aufwecksignal, kontinuierliches Broadcasten, periodisches Broadcasten, und/oder auf Grundlage einer Unfallmitteilungsnachricht übertragen.
Beim Betriebsvorgang 502 kann das VCS 1 die iBeacon-Übertragung über BLE kontinuierlich senden. Die iBeacon-Übertragung kann mehrere Nachrichten enthalten, darunter u.a. den UUID. Das BLE kann leistungsarme Voraussetzungen beinhalten, um den kontinuierlichen iBeacon-Broadcast zu ermöglichen, ohne das Fahrzeugbatteriesystem zu entladen.
Beim Betriebsvorgang 504 kann das VCS 1 einen Hinweis empfangen, dass das nomadische Gerät 53 eine drahtlose Übertragung empfangen hat, während es sich dem Fahrzeug innerhalb des Nähebereichs des BLE angenähert hat. Das VCS 1 kann den iBeacon mit einem UUID im Betriebsvorgang 506 übertragen. Das nomadische Gerät 53 kann den iBeacon-Broadcast vom VCS 1 empfangen und die mobile Anwendung aufwecken, die dem UUID zugeordnet ist. Beispielsweise kann der Handshake zwischen dem Fahrzeug und dem nomadischen Gerät 53 unter Benutzung von BLE erfolgen, wodurch leistungsarme und latenzarme Anwendungen vom drahtlosen Gerät 53 innerhalb eines Nahbereichs (beispielsweise bis zu 50 Meter / 160 Fuß) ermöglicht sind. Dies erleichtert es, dass das nomadische Gerät 53 vom VCS 1 erkannt wird, wenn sich der Benutzer dem Fahrzeug nähert, ohne viel Fahrzeugbatterieleistung zu benutzen.
Beim Betriebsvorgang 508 können die mobile Anwendung und das VCS 1 über BLE nach dem Durchführen der angemessenen Sicherheits-Handshakes und -protokolle verbunden werden. Beispielsweise können das VCS 1, in Kommunikation mit einer PEPS-Steuerung (passive entry passive start), und das nomadische Gerät 53 einer Reihe von Vor- und Rückkommunikationen (beispielsweise Handshake) für Fahrzeugzugangs-/Mobilanwendungsauthentifizierungszwecke unterzogen werden. Wenn der Handshake abgeschlossen ist, kann das nomadische Gerät 53 die eine oder die mehreren Sicherheitseigenschaften an das VCS 1 und/oder die PEPS-Steuerung übertragen. Die PEPS-Steuerung und/oder das VCS 1 können einen oder mehrere Sicherheitscodes vom nomadischen Gerät 53 empfangen.
In einem anderen Beispiel können das VCS 1 und/oder die PEPS-Steuerung bestimmen, ob das nomadische Gerät 53 die korrekten, dem Fahrzeug zugehörigen Sicherheitscodeeigenschaften übertragen hat, um Kommunikation zwischen dem VCS 1 und der nomadischen Geräteanwendung zuzulassen. Wenn das nomadische Gerät 53 die korrekten, diesem Fahrzeug zugehörigen Sicherheitscodes übertragen hat, können das VCS 1 und/oder die PEPS-Steuerung eine Steuerungs-/Kommunikationsanforderung der empfangenen Fahrzeugdaten und/oder Funktionen vom nomadischen Gerät 53 zulassen.
Beim Betriebsvorgang 510 kann das VCS 1 eine Anforderung zum Überwachen von fahrzeugspezifischen Daten und Sensoren über BLE GATT Kommunikationsprotokoll mit der mobilen Anwendung empfangen. Beispielsweise kann die mobile Anwendung Türverriegelungsstatus, Zündungsstatus, Klimasteuerungen, Reifendruck, Fahrzeugzusammenstoßerkennung (d.h. Unfall erfolgte), Kraftstoffpegel usw. überwachen.
Beim Betriebsvorgang 512 kann das VCS 1 spezifische Funktionen auf Grundlage der Fahrzeugdaten und/oder Benutzerdaten über die mobile Anwendung empfangen. Die mobile Anwendung kann Fahrzeug- und Personendaten empfangen und auf Grundlage der Daten eine oder mehrere Nachrichten erstellen. Die eine oder die mehreren Nachrichten können eine Anforderung zum Steuern einer Fahrzeugfunktion und/oder Ausführen einer Mitteilung an einen Benutzer auf Grundlage einer Fahrzeugfunktion enthalten.
Beim Betriebsvorgang 514 kann das VCS 1 eine fahrzeugspezifische Anforderung über die mobile Anwendung empfangen. Das VCS 1 kann die fahrzeugspezifische Anforderung, die von der mobilen Anwendung empfangen wurde, beim Betriebsvorgang 516 ausführen. Beispielsweise kann das VCS 1 eine Anforderung zum Anweisen des Systems zum Hinweisen des nomadischen Geräts 53 empfangen, wenn ein Unfall über eine oder mehrere drahtlose Übertragungen von Nachrichten erkannt ist.
Beim Betriebsvorgang 518 kann das VCS 1 spezifische Anforderungen auf Grundlage der Fahrzeugdaten und/oder Benutzerdaten über die mobile Anwendung empfangen. Das VCS 1 kann die anwendungsspezifische Anforderung, die von der mobilen Anwendung empfangen wird, im Betriebsvorgang 520 ausführen. Beispielsweise kann die mobile Anwendung anfordern, darauf hingewiesen zu werden, wie viele Insassen sich im Fahrzeug befinden. Das VCS 1 kann die Anzahl von Insassen überwachen und diese Daten über die Bluetooth-Kommunikationsverbindung des nomadischen Geräts an die mobile Anwendung übertragen.
Beim Betriebsvorgang 522 kann das VCS 1 die Kommunikation mit dem nomadischen Gerät 53 auf Grundlage mehrerer Faktoren, darunter u.a. der Standort des nomadischen Geräts 53 und/oder die Anforderung an das VCS, sich auszuschalten, unterbrechen.
7 ist ein Ablaufdiagramm, das ein Beispielverfahren 600 des nomadischen Geräts, das eine Anwendungsaufweckanforderung zum Starten der Anwendung empfängt, gemäß einer Ausführungsform darstellt. Das nomadische Gerät (d.h. drahtlose Gerät, nomadische Gerät usw.) kann eine oder mehrere Softwareanwendungen (d.h. mobile Anwendung(en)) aufweisen, die in Hardwarekomponenten des Geräts ausgeführt werden. Die Hardwarekomponenten können u.a. einen oder mehrere Transceiver, einen Prozessor, einen Speicher und/oder ein Betriebssystem enthalten.
Im Betriebsvorgang 602 kann die mobile Anwendung den UUID über die iBeacon-Übertragung empfangen, die vom VCS empfangen wurde. Die eine oder die mehreren mobilen Anwendungen können bestimmen, ob das nomadische Gerät mit dem VCS gepaart wurde. Wenn das nomadische Gerät nicht mit dem VCS gepaart wurde, kann das VCS bei Betriebsvorgang 606 eine Paarungssequenz anfordern.
Beim Betriebsvorgang 608 kann, wenn das nomadische Gerät vorher mit dem VCS gepaart wurde, das nomadische Gerät damit beginnen, nach einer oder mehreren Anwendungen zu suchen, die dem UUID zugehören. Wenn das nomadische Gerät eine Unterbrechung der Kommunikationsverbindung mit dem VCS erfährt, kann die mobile Anwendung beim Betriebsvorgang 610 Kommunikation mit dem VCS anfordern.
Beim Betriebsvorgang 612 kann das nomadische Gerät nach einer oder mehreren mobilen Anwendungen suchen, die denselben UUID wie jenen aufweisen, der vom iBeacon empfangen wurde. Wenn das nomadische Gerät eine Übereinstimmung des UUID findet, der einer mobilen Anwendung zugeordnet ist, kann das Gerät die mobile Anwendung beim Betriebsvorgang 614 starten.
In einem Beispiel kann das nomadische Gerät einen Sicherheitsprozess implementieren, um zu gewährleisten, dass der UUID und/oder die zugeordneten mobilen Anwendungen zum Kommunizieren mit dem VCS annehmbar sind. Beispielsweise kann das nomadische Gerät, wenn das nomadische Gerät die mobile Anmeldung entdeckt, die den UUID aufweist, bei einem Backend-Server prüfen, um zu bestimmen, ob die mobile Anwendung im Fahrzeug benutzt werden kann.
Beim Betriebsvorgang 616 kann das nomadische Gerät eine oder mehrere Nachrichten über das GATT Protokoll an das VCS übertragen. Die eine oder die mehreren Nachrichten können mindestens eine Variable enthalten, die auf Fahrzeugunfallerkennung bezogen ist. Die mobile Anwendung kann beim Betriebsvorgang 618 eine oder mehrere Fahrzeugunfallvariablen über das GATT Protokoll überwachen.
Beim Betriebsvorgang 620 kann die mobile Anwendung bestimmen, ob ein vordefiniertes Ereignis auf Grundlage des Überwachens der einen oder der mehreren Variablen erkannt wird. Beispielsweise kann das vordefinierte Ereignis beinhalten, dass die mobile Anwendung bestimmt, ob ein Zusammenstoß auf Grundlage des Überwachens der einen oder der mehreren Variablen erkannt ist. Wenn ein Zusammenstoß erkannt ist, kann die mobile Anwendung im Betriebsvorgang 622 zusätzliche Daten vom VCS anfordern. Beispielsweise können die zusätzlichen Daten u.a. die Anzahl der Insassen, den Standort des Fahrzeugs und/oder andere unfallbezogene Information enthalten.
Beim Betriebsvorgang 624 kann die mobile Anwendung die zusätzlichen Daten über das nomadische Gerät an mehrere Einrichtungen übertragen, darunter u.a. ein Callcenter, Notrufannahmestelle, Polizeiwache und/oder einen oder mehrere Kontakte, die von einem Benutzer vorkonfiguriert sind. Beispielsweise kann die mobile Anwendung zuerst eine Verbindung mit dem Callcenter und/oder der Notrufannahmestelle herstellen. Die Mitteilung von Information an das Callcenter und/oder die Notrufannahmestelle kann ermöglichen, dass Erstretter/Notfallpersonal beim Unfall Hilfe leisten. Das nomadische Gerät kann eine oder mehrere Nachrichten an einen vorkonfigurierten Kontakt übertragen. Die Nachricht kann u.a. eine hergestellte Kommunikationsverbindung zwischen dem Kontakt und dem Benutzer, eine an den Kontakt übertragene Textnachricht, eine an den Kontakt übertragene E-Mail, eine Nachricht über soziale Medien an den Kontakt und/oder eine Kombination davon beinhalten.
Es ist zu beachten, dass das nomadische Gerät mehrere Konfigurationen aufweisen kann, darunter u.a. ein externes tragbares Gerät, das der Benutzer trägt, ein eingebettetes Gerät, das mit dem VCS konfiguriert ist, und/oder eine Kombination davon. Beispielsweise kann das nomadische Gerät, das das externe tragbare Gerät ist, das der Benutzer trägt, ein Smartphone sein. In einem anderen Beispiel kann das eingebettete Gerät, das mit dem VCS konfiguriert ist, ein eingebettetes Mobiltelefon und/oder Modem sein.
Beim Betriebsvorgang 626 kann das nomadische Gerät die eine oder die mehreren Anwendungen ausschalten, wenn ein Benutzer anfordert, sie auszuschalten und/oder das nomadische Gerät abgeschaltet wird.
8 ist ein Ablaufdiagramm, das ein Beispielverfahren 700 des Fahrzeugrechensystems, das den iBeacon zum nomadischen Gerät zum Starten einer Anwendung leitet, gemäß einer Ausführungsform darstellt. Das VCS kann die Übertragung von Daten an ein oder mehrere externe Geräte mit der Benutzung einer Softwareanwendung verwalten, die in Hardware ausgeführt wird, welche mit dem System konfiguriert ist.
Beim Betriebsvorgang 702 kann der Benutzer in das Fahrzeug einsteigen und den Zündschalter zum Initialisieren des VCS anstellen. Die Initialisierung des VCS kann eine drahtlose Protokollübertragung (d.h. Bluetooth) über einen oder mehrere Transceiver beim Betriebsvorgang 704 beinhalten. Die Bluetooth-Übertragung kann den iBeacon-Broadcast beinhalten.
Beim Betriebsschritt 706 kann das VCS eine Anforderung zum Verbinden von dem nomadischen Gerät über die drahtlose Übertragung des Bluetooth-Protokolls oder durch den Gebrauch einer verdrahteten Verbindung (d.h. USB) empfangen. Das VCS kann beim Betriebsvorgang 708 bestimmen, ob das Gerät anfordert, sich mit dem System zu verbinden.
Beim Betriebsvorgang 710 kann, falls das Gerät nicht vorher mit dem VCS gepaart wurde, das System Konfiguration anfordern. Wenn das Gerät vorher mit dem VCS gepaart wurde, kann das System beim Betriebsvorgang 712 Kommunikation mit dem Gerät über einen Handshake-Prozess herstellen.
Beim Betriebsvorgang 714 kann das VCS eine Anforderung über iBeacon zum Starten einer Anwendung übertragen, die zum Kommunizieren mit dem System auf Grundlage des UUID konfiguriert ist. Das VCS kann im Betriebsvorgang 716 eine oder mehrere Nachrichten zum Bestätigen empfangen, dass zugehörige Anwendungen im Gerät gestartet werden.
Beim Betriebsvorgang 718 kann das VCS überwachen, ob das eine oder die mehreren Fahrzeugsysteme Variablen erkennen, die den Anwendungen zugehören, welche im Gerät gestartet wurden. Beispielsweise kann die Anwendung auf Unfallerkennung und Notfallschutz bezogen sein, weswegen das VCS eine oder mehrere Variablen überwachen kann, die auf Unfallerkennung bezogen sind.
Beim Betriebsvorgang 720 kann das VCS bestimmen, ob ein Fahrzeugstatusereignis eingetreten ist (sich beispielsweise ein Unfall ereignet hat). Wenn ein Unfall erkannt wird, kann das VCS einen Insassen im Fahrzeug beim Betriebsvorgang 722 über die Anwendung im Gerät mit dem Callcenter verbinden.
Beim Betriebsvorgang 724 kann das System, wenn das VCS über das nomadische Gerät eine Kommunikationsverbindung mit dem Callcenter hergestellt hat, Daten an das Callcenter übertragen. Die Daten können u.a. den Fahrzeugstandort beinhalten.
Beim Betriebsvorgang 726 kann das VCS überwachen, ob die Kommunikation mit dem Callcenter abgeschlossen ist. Wenn die Kommunikation mit dem Callcenter geendet hat, kann das VCS eine Mitteilung an das Gerät übertragen. Das VCS kann beim Betriebsvorgang 728 eine Nachrichtenmitteilung über die Anwendung im Gerät an einen oder mehrere vordefinierte Kontakte übertragen.
Beim Betriebsvorgang 730 kann das VCS die Kommunikation mit dem nomadischen Gerät unterbrechen, wobei das Gerät die mobile Anwendung jedoch weiterhin zum Übertragen einer (von) Nachricht(en) nach dem Zusammenstoß an einen oder mehrere Kontakte aktiv halten kann.
9 ist ein Ablaufdiagramm, das ein Beispielverfahren 800 darstellt, bei dem das Callcenter eine Push-Mitteilung zum Starten der mobilen Anwendung im nomadischen Gerät überträgt. Das Callcenter kann zum Zweck des Empfangens oder Übertragens von Daten zum Verbessern der Fahrerfahrung benutzt werden. Das Callcenter kann u.a. mindestens einen Server, Rechnerarbeitsplätze, eine oder mehr Personen (d.h. Bearbeiter) zum Bedienen der Rechnerarbeitsplätze und/oder eine Kombination davon beinhalten.
Beim Betriebsvorgang 802 kann sich das nomadische Gerät unter Benutzung von drahtloser und/oder verdrahteter Technologie mit dem VCS verbinden. Nach dem Handshake und/oder anderen Sicherheitsprotokollen zum Paaren des nomadischen Geräts mit dem VCS kann das Gerät bei Betriebsvorgang 804 beginnen, mit dem VCS zu kommunizieren.
Beim Betriebsvorgang 806 kann das nomadische Gerät Daten vom VCS empfangen, die hinweisen, dass sich ein Unfall ereignet hat. Das nomadische Gerät kann bei Betriebsvorgang 808 eine Nachricht vom VCS zum Verbinden des Insassen mit dem Callcenter empfangen.
Beim Betriebsvorgang 810 kann das nomadische Gerät Daten an das Callcenter übertragen. In einem Beispiel kann der Insasse über die Verbindung, die mit dem Callcenter hergestellt ist, mit einem Callcenterbearbeiter sprechen. In einem anderen Beispiel können die an das Callcenter übertragenen Daten u.a. Fahrzeugstandort und/oder die Anzahl der Insassen im Fahrzeug enthalten.
Beim Betriebsvorgang 812 kann das nomadische Gerät überwachen, wann die Kommunikation mit dem Callcenter abgeschlossen ist. Wenn die Kommunikation abgeschlossen ist, kann das nomadische Gerät beim Betriebsvorgang 814 eine Push-Mitteilung vom Callcenter zum Aufwecken einer mobilen Anwendung im nomadischen Gerät empfangen. Die Push-Mitteilung kann dem Gerät durch einen Token übermittelt werden und die Zusammenstoßereignisdetails enthalten, wie etwa Richtung, Reaktionszeit, Schwere des Ereignisses.
Beim Betriebsvorgang 816 kann das nomadische Gerät in Reaktion auf die Push-Mitteilung die mobile Anwendung starten. Die mobile Anwendung kann u.a. eine Anwendung für Mitteilungen nach dem Zusammenstoß sein. Die Anwendung für Mitteilungen nach dem Zusammenstoß kann eine oder mehrere Nachrichten an vorkonfigurierte Kontakte übertragen. Die Mitteilung nach dem Zusammenstoß kann unmittelbare und automatische Insassenaktualisierungen auf Grundlage des Zusammenstoßes an mindestens einen vordefinierten Kontakt ermöglichen. Die Mitteilung nach dem Zusammenstoß kann einem oder mehreren Kontakten über SMS, Textnachrichten, E-Mails, soziale Netzwerke und/oder Kombinationen davon übermittelt werden. Das nomadische Gerät kann die eine oder die mehreren Anmeldungen im Betriebsvorgang 818 abschalten, wenn ein Benutzer anfordert, sie auszuschalten, und/oder das nomadische Gerät abgeschaltet wird.
10 ist ein Blockdiagramm 900, das das nomadische Gerät 904, das eine oder mehrere mobile Anwendungen durch Kommunizieren mit dem Fahrzeugrechensystem 902 (d.h. Kopfeinheit) und einem Server 906 (d.h. Callcenter) verwaltet, gemäß einer Ausführungsform darstellt. Das nomadische Gerät 904 (d.h. Smartphone) kann eine oder mehrere Anwendungen enthalten, die in Hardware des Geräts zum Vorsehen zusätzlicher Dienste für den Fahrzeuginsassen ausgeführt werden. Die zusätzlichen Dienste können u.a. Internetradio, Klimasteuerung, Navigation, Unfallhilfe, Mitteilung nach einem Zusammenstoß und/oder andere Funktionen, die die Fahrerfahrung verbessern, enthalten.
Das Smartphone 904 kann eine drahtlose Verbindung 912 mit der Kopfeinheit 902 herstellen. Die drahtlose Verbindung 912 kann auf Grundlage verschiedener Verfahren hergestellt werden, darunter u.a. ein Paarungsprozess, der eine Anfangsverbindung zwischen der Kopfeinheit 902 und dem Smartphone 904 ist. Die drahtlose Kommunikation kann u.a. Bluetooth, BLE, NFC und/oder WiFi beinhalten.
Die eine oder die mehreren mobilen Anwendungen im Smartphone 904 können bestimmte Funktionen auf Grundlage von Information/Daten ausführen, die von der Kopfeinheit 902 über die drahtlose Kommunikation 912 empfangen werden. Beispielsweise kann, wenn die Kopfeinheit 902 erkennt, dass das Fahrzeug in einen Unfall verwickelt war, das System eine Nachricht an das Smartphone 904 zum Ausführen einer Funktion übertragen. Das Smartphone kann durch die Kopfeinheit 902 zum Herstellen einer Kommunikation mit dem Callcenter 906 auf Grundlage der Unfallerkennungsnachricht angewiesen werden.
Das Smartphone 904 kann Kommunikation 914 mit dem Callcenter 906 herstellen. Das Smartphone 904 weist ein Betriebssystem auf, das in Hardware des Gerätes ausgeführt werden kann und einen Geräte-Token an das Callcenter 906 übertragen kann. Der Geräte-Token kann an das Callcenter 906 gesendet werden, sodass die Telefonnummer des Smartphones 904 zusammen mit dem Geräte-Token registriert werden kann. Der Geräte-Token, der zusammen mit der Telefonnummer registriert wird, kann in einer Datenbank 908 gespeichert werden. Die Datenbank 908 kann einem Fahrzeughersteller, dem Callcenter, der mobilen Anwendung und/oder einer Kombination davon zugeordnet sein. In einem Beispiel kann das Smartphone 904 an das Callcenter 906 übertragen, dass das Fahrzeug in einen Unfall verwickelt war. Das Callcenter 906 kann den Geräte-Token mit der ankommenden Telefonnummer, die vom Smartphone 904 empfangen wurde, abgleichen.
Das Callcenter 906 kann ein Netzwerk mit einem oder mehreren Rechnern in Kommunikation über einen oder mehrere Server aufweisen. Das Callcenter 906 kann Zusammenstoßdaten über die Kommunikationsverbindung 914 mit dem Smartphone 904 empfangen. In einem Beispiel kann das Callcenter einen Bearbeiter aufweisen, der Details des Zusammenstoßes in der Callcenterdatenbank aufzeichnen kann. Die Details können u.a. Standort, Schwere und Anzahl der Insassen beinhalten.
Das Callcenter 906 kann den Geräte-Token von der Datenbank 908 auf Grundlage der ankommenden Telefonnummer anfordern 916. Das Callcenter kann den Geräte-Token von der Datenbank 908 empfangen 918. Nach Beendigung des Anrufs kann das Callcenter 906 eine Push-Mitteilung unter Benutzung des Geräte-Tokens an den Smartphonegeräteserver 910 übertragen 920 (d.h. Push-Dienst). Die Push-Mitteilung kann u.a. Geräte-Token, Fahrzeugdaten und/oder Insassendaten beinhalten.
Der Push-Dienst 910 kann eine Aufweckanwendungsanforderung an das Smartphone 904 übertragen 924. Der Geräte-Token wird zum Identifizieren des Smartphones für die Aufweckanwendungsanforderung über die Push-Mitteilung benutzt. Das Smartphone 904 kann die Push-Mitteilung empfangen und die angeforderte Anwendung kann aufwachen. In einem Beispiel kann die Anwendung eine Anwendung für Mitteilungen nach dem Zusammenstoß sein, die zum Übertragen von einer oder mehreren Nachrichten an einen vorkonfigurierten Kontakt auf Grundlage der Unfallmitteilung benutzt wird. Die Mitteilung nach dem Zusammenstoß kann unfallbezogene Details an einen zugewiesenen Server zur Verarbeitung übertragen. Die Mitteilung nach dem Zusammenstoß kann außerdem unfallbezogene Details über Hyper Text Transfer Protocol (HTTP), SMS und/oder andere Dienste an den vorkonfigurierten Notfallkontakt übertragen.
11 ist ein Ablaufdiagramm, das ein Beispielverfahren 1000 des nomadischen Geräts, das mit dem Fahrzeugrechensystem (d.h. Kopfeinheit) und dem Callcenter (d.h. einem oder mehreren Servern) kommuniziert, gemäß einer Ausführungsform darstellt. Das Verfahren 1000 kann unter Benutzung von Softwarecode implementiert werden, der innerhalb der Kopfeinheit, des nomadischen Geräts, des Callcenters und/oder Kombinationen davon enthalten ist. In anderen Ausführungsformen kann das Verfahren 1000 in anderen Steuermodulen in Kommunikation mit dem nomadischen Gerät implementiert sein.
Im Betriebsvorgang 1002 kann das nomadische Gerät Daten von der Kopfeinheit über eine drahtlose Verbindung auf Grundlage von einem oder mehreren vordefinierten Ereignissen empfangen. Das eine oder die mehreren vordefinierten Ereignisse können durch die mobile Anwendung, die im nomadischen Gerät ausgeführt wird, durch einen Benutzer und/oder eine Kombination davon eingestellt werden. Das nomadische Gerät kann bestimmen, ob eine Verbindung mit der mobilen Anwendung hergestellt wurde, die eine Anwendungsprogrammierschnittstelle (API) aufweist, welche zum Kommunizieren mit der Kopfeinheit im Betriebsvorgang 1004 konfiguriert ist.
Im Betriebsvorgang 1006 kann das nomadische Gerät, wenn die mobile Anwendung, die die API aufweist, verbunden ist, eine SMS-Nachricht an das Callcenter übertragen, die GPS-Daten aufweist. Beispielsweise kann, wenn das nomadische Gerät die mobile Anwendung ausführt, die zum Kommunizieren mit der Kopfeinheit auf Grundlage der API konfiguriert ist, das Gerät zusätzliche Daten über drahtlose Kommunikation an das Callcenter übertragen. In einem anderen Beispiel kann das nomadische Gerät bestimmen, ob eine Internetverbindung verfügbar ist, und beim Betriebsvorgang 1010 auf Grundlage der Verbindung ein HTTP mit GPS-Daten an das Callcenter übertragen.
Beim Betriebsvorgang 1016 kann das nomadische Gerät auf das Empfangen einer Bestätigung vom Callcenter zum Bestimmen, ob die Information, die an das Callcenter übertragen wurde, erfolgreich empfangen wurde, warten. Beispielsweise kann die mobile Anwendung versuchen, die Daten erneut zu übertragen, wenn die anfängliche Übertragung von Daten an das Callcenter fehlgeschlagen ist.
Beim Betriebsvorgang 1012 kann, wenn das nomadische Gerät nicht über die API mit der Kopfeinheit kommuniziert, und/oder wenn keine Internetverbindung besteht, das nomadische Gerät auf den Abschluss des Callcenter-Anrufs warten, bevor es zusätzliche Daten überträgt. Beispielsweise kann das nomadische Gerät überwachen, wann die Kommunikation mit dem Callcenter abgeschlossen ist, bevor es eine Push-Mitteilung vom Callcenter zum Aufwecken der mobilen Anwendung empfängt.
Beim Betriebsvorgang 1014 kann die Callcenter-API, wenn der Anruf an das Callcenter abgeschlossen ist, einen Aufweckbefehl an das nomadische Gerät übermitteln. Der Aufweckbefehl kann die mobile Anwendung starten, die durch die API angefordert wurde. Beispielsweise kann das Callcenter eine Push-Mitteilung mit einer API übertragen, die zum Aufwecken einer Anwendung für Mitteilungen nach dem Zusammenstoß definiert ist.
Beim Betriebsvorgang 1018 kann die mobile Anwendung, die in Hardware im nomadischen Gerät ausgeführt wird, SMS an einen oder mehrere vordefinierte Kontakte (beispielsweise Notfallkontakte) senden. Wenn eine Internetverbindung verfügbar ist, kann das nomadische Gerät die Nachrichten beim Betriebsschritt 1020 an einen oder mehrere der vordefinierten Kontakte über das Internet übertragen.
Beim Betriebsvorgang 1022 kann die mobile Anwendung eine oder mehrere Nachrichtenmitteilungen an verfügbare Notfallkontakte und/oder einen sozialen Netzwerkserver übertragen. Beispielsweise kann die eine oder die mehreren Nachrichtenmitteilungen u.a. Weibo-Mitteilung, soziale Mediennachrichten, Textnachrichten und/oder E-Mailnachrichten enthalten.
Beim Betriebsvorgang 1024 kann die mobile Anwendung, wenn keine Internetverbindung verfügbar ist, eine Anforderung zum Anrufen des einen oder der mehreren vordefinierten Kontakte übertragen. In einem anderen Beispiel kann, wenn die Internetverbindung nicht verfügbar ist, das nomadische Gerät eine Textnachricht an einen oder mehrere vordefinierte Kontakte senden.
Beim Betriebsvorgang 1026 kann die mobile Anwendung überwachen, wann ein Anruf zwischen dem einen oder den mehreren vordefinierten Kontakten beendet ist. Beispielsweise kann die mobile Anwendung automatisch einen oder mehrere vordefinierte Kontakte erneut anwählen und/oder anwählen. Die mobile Anwendung kann eine Anforderung empfangen, den einen oder mehrere vordefinierte Kontakte nicht anzurufen und/oder Daten hinzusenden. Wenn die mobile Anwendung eine Anforderung empfängt, den einen oder die mehreren vordefinierten Kontakte nicht anzurufen und/oder mit ihnen zu kommunizieren, kann sich die mobile Anwendung beim Betriebsvorgang 1028 zurücksetzen und die Anwendung ausschalten.
Beim Betriebsvorgang 1030 kann das nomadische Gerät die eine oder die mehreren Anwendungen ausschalten, wenn ein Benutzer anfordert, sie auszuschalten, und/oder das nomadische Gerät ausgeschaltet wird. Die mobile Anwendung kann aufgeweckt und/oder erneut initialisiert werden, wenn eine Anforderung von der Kopfeinheit (d.h. VCS) und/oder dem Callcenter (d.h. einem oder mehreren Servern) empfangen wird.
12 ist ein Ablaufdiagramm, das ein Beispielverfahren 1100 des Fahrzeugrechensystems (d.h. der Kopfeinheit) darstellt, das einen drahtlosen Transceiver konfiguriert, einen vordefinierten Anwendungsbezeichner zu broadcasten. Das Verfahren 1100 kann unter Verwendung von Software-Code implementiert werden, der in einer Steuerung des VCS enthalten ist. In anderen Ausführungsformen kann das Verfahren 1000 in anderen, mit dem VCS in Kommunikation befindlichen, Steuermodulen implementiert werden.
Beim Betriebsvorgang 1102 kann das VCS programmiert sein, einen oder mehrere UUIDs zu konfigurieren. Der eine oder die mehreren UUIDs können auf mehreren Faktoren basierend konfiguriert sein, einschließlich unter anderem einem spezifischen Steuermodul, einer spezifischen Anwendung, einer spezifischen Anwendung in dem nomadischen Gerät, einem Fahrzeugbetriebszustand und/oder einer Kombination davon. Zum Beispiel kann ein UUID dafür vordefiniert sein, anzufordern, eine spezifische Anwendung in dem nomadischen Gerät zu starten, die sich auf Satellitenfunk zur Kommunikation mit der Steuerung im VCS bezieht. In einem weiteren Beispiel kann ein UUID vordefiniert sein, eine Navigationsanwendung in dem nomadischen Gerät zu starten, darauf basierend, dass das Fahrzeug in einen Initialisierungs-Betriebszustand eintritt.
Bei Betriebsvorgang 1104 kann das VCS, als Reaktion auf den konfigurierten einen oder die mehreren UUIDs, ein Beacon-Signal (d.h. iBeacon) broadcasten, das mindestens ein UUID aufweist. Das VCS kann eine Nachricht von einem nomadischen Gerät empfangen, die anfordert, zu kommunizieren. Das VCS kann beim Betriebsvorgang 1106 bestimmen, ob das nomadische Gerät von dem System erkannt wird. Falls das nomadische Gerät nicht erkannt wird, kann das System beim Betriebsvorgang 1107 bestimmen, ob der gerade gebroadcastete UUID geändert wird oder nicht.
Das VCS kann zum Beispiel eine oder mehrere Anwendungen in der Steuerung herunterladen. Die eine oder die mehreren heruntergeladenene Anwendungen können ein zugeordnetes UUID aufweisen. Das VCS kann zum Broadcasten durch den/die in dem System gespeicherte(n) UUID(s) scrollen. Das VCS kann bei Betriebsvorgang 1104 das Beacon-Signal mit dem vorherigen UUID oder dem nächsten UUID, der in dem System gespeichert ist, broadcasten.
Beim Betriebsvorgang 1108, kann das VCS bestimmen, ob das nomadische Gerät schon früher mit der Einheit gepaart war. Falls das nomadische Gerät früher gepaart war, kann das VCS bei Betriebsvorgang 1110 Daten von der einen oder den mehreren in dem nomadischen Gerät gestarteten Anwendungen empfangen, die mit dem mindestens einen UUID assoziiert sind.
Beim Betriebsvorgang 1112 kann das VCS Daten von der einen oder den mehreren gerade in dem nomadischen Gerät ausgeführten Anwendungen an die jeweiligen Steuermodule im System übertragen. Das VCS kann beim Betriebsvorgang 1114 auch Daten an die eine oder die mehreren in dem nomadischen Gerät ausgeführten Anwendungen kommunizieren.
Bei Betriebsvorgang 1116 kann das VCS die Kommunikation weiterführen bis eine Kommunikationsverbindung mit dem nomadischen Gerät deaktiviert wird. Das VCS kann bestimmen, ob der gerade bei Betriebsvorgang 1107 gebroadcastete UUID geändert wird oder nicht. Das VCS kann den gerade gebroadcastete UUID basierend auf einer oder mehreren vordefinierten Bedingungen ändern. Die eine oder die mehreren vordefinierten Bedingungen können einen identifizierten Fahrer, einen Fahrzeugsbetriebszustand, einen Standort des Fahrzeugs und/oder eine Kombination davon einschließen. Das VCS kann die Kommunikation mit dem nomadischen Gerät abbrechen, allerdings kann das nomadische Gerät damit weitermachen, die eine oder die mehreren Anwendungen zu befähigen, Anwendungsdaten über das nomadische Gerät an den Benutzer zu übertragen.
Während obenstehend beispielhafte Ausführungsformen beschrieben sind, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen beschreiben, die die Ansprüche umfassen. Die in der Schrift verwendeten Worte dienen der Beschreibung statt der Einschränkung, und es versteht sich, dass verschiedene Veränderungen vorgenommen werden können, ohne von Geist und Wesen der Offenbarung abzuweichen. Wie vorher beschrieben können die Merkmale verschiedener Ausführungsformen zum Ausbilden weiterer Ausführungsformen der Erfindung kombiniert werden, die nicht ausdrücklich beschrieben oder dargestellt sein könnten. Während verschiedene Ausführungsformen als vorteilhaft oder anderen Ausführungsformen oder Implementierungen des Stands der Technik bezüglich eines oder mehrerer erwünschter Kennzeichen gegenüber bevorzugt beschrieben wurden, wird der Durchschnittsfachmann erkennen, dass ein oder mehrere Merkmale oder Kennzeichen beeinträchtigt werden können, um erwünschte Gesamtsystemattribute zu erzielen, die von der spezifischen Anwendung und Implementierung abhängen. Diese Attribute können u.a. Kosten, Festigkeit, Beständigkeit, Lebenszykluskosten, Vermarktbarkeit, Erscheinung, Verpackung, Größe, Dienlichkeit, Gewicht, Herstellbarkeit, Montagefreundlichkeit usw. beinhalten. Von daher befinden sich Ausführungsformen, die als weniger wünschenswert als andere Ausführungsformen oder Implementierungen des Stands der Technik bezüglich eines oder mehrerer erwünschter Kennzeichen gegenüber beschrieben sind, nicht außerhalb des Umfangs der Offenbarung und können für bestimmte Anwendungen erwünscht sein.
Bezugszeichenliste
Figur 11

1002: Daten von Kopfeinheit empfangen
1004: Ist eine kopfeinheitbezogene mobile Anwendung verbunden?
1006: SMS mit GPS an Callcenter senden
1008: Ist Internet verfügbar?
1010: HTTP mit GPS an Callcenter senden
1012: Warten, bis Callcenteranruf abgeschlossen ist
1014: Callcenter-API pusht Aufweckbefehl an Anwendung
1016: Warten auf e-Anrufbestätigungsstatusänderung
1018: SMS an Notfallkontakte senden (wenn Benutzer ausgewählt ist)
1020: Ist Internet verfügbar?
1022: WeiBo-Mitteilung an verfügbare Notfallkontakte und Callcenter/soziales Netzwerk senden (wenn Benutzer ausgewählt ist)
1024: Anrufen eines Notfallkontakts anfordern?
1026: Anruf beendet?
1028: E-Call-Flag zurückstellen
1030: Ende
Yes: Ja
No: Nein

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 7324833 [0003]
US 8346310 [0004]

Zitierte Nicht-Patentliteratur

IEEE 802 PAN [0034]
IEEE 802 LAN [0034]
IEEE 802 PAN [0034]
IEEE 1394 [0037]
IEEE 1284 [0037]
IEEE 803.11 [0039]

Claims

Fahrzeugrechensystem, das Folgendes umfasst: mindestens eine Steuerung, die mit einem Transceiver kommuniziert, wobei die mindestens eine Steuerung zu Folgendem programmiert ist: Konfigurieren eines drahtlosen Signals, das einen ersten Anwendungsbezeichner für eine erste Anwendung, die in dem nomadischen Gerät gestartet werden soll, aufweist; und Broadcasten des drahtlosen Signals, einschließlich des ersten Anwendungsbezeichners, über den Transceiver.
Fahrzeugrechensystem nach Anspruch 1, wobei das drahtlose Signal ein BLUETOOTH-Signal ist.
Fahrzeugrechensystem nach Anspruch 2, wobei das BLUETOOTH-Signal ein BLUETOOTH-Beacongerät ist.
Fahrzeugrechensystem nach Anspruch 3, wobei das BLUETOOTH-Beacongerät ein iBeacon ist.
Fahrzeugrechensystem nach Anspruch 1, wobei der erste Anwendungsbezeichner ein universal eindeutiger Bezeichner mit einem Bezeichner mit vierundsechszig Hexadezimalzeichen ist.
Fahrzeugrechensystem nach Anspruch 1, wobei die mindestens eine Steuerung ferner dafür programmiert ist, das drahtlose Signal, das einen zweiten Anwendungsbezeichner für eine zweite Anwendung, die in dem nomadischen Gerät gestartet werden soll, aufweist, zu konfigurieren; und das drahtlose Signal einschließlich des zweiten Anwendungsbezeichners, über den Transceiver zu broadcasten.
Fahrzeugrechensystem nach Anspruch 6, wobei das nomadische Gerät dafür konfiguriert sein kann, die erste Anwendung und/oder die zweite Anwendung zu starten, basierend auf einer Übereinstimmung zwischen dem ersten Anwendungsbezeichner oder dem zweiten Anwendungsbezeichner.
Computerprogrammprodukt, das in einem nichtflüchtigen, computerlesbaren Medium verkörpert ist, das zum Übertragen eines drahtlosen Signals programmiert ist, eine Anwendung in einem nomadischen Gerät zu starten, wobei das Computerprogrammprodukt Anweisungen zu Folgendem umfasst: Konfigurieren eines drahtlosen Signals, das einen Anwendungsbezeichner für eine Anwendung, die in dem nomadischen Gerät gestartet werden soll, aufweist; und Broadcasten des drahtlosen Signals, einschließlich des Anwendungsbezeichners, über einen Transceiver.
Computerprogrammprodukt nach Anspruch 8, wobei das drahtlose Signal ein BLUETOOTH-Signal ist.
Computerprogrammprodukt nach Anspruch 9, wobei das BLUETOOTH-Signal ein BLUETOOTH-Beacongerät ist.
Computerprogrammprodukt nach Anspruch 10, wobei das BLUETOOTH-Beacongerät ein iBeacon ist.
Computerprogrammprodukt nach Anspruch 8, wobei der Anwendungsbezeichner ein universal eindeutiger Bezeichner ist.
Computerprogrammprodukt nach Anspruch 12, wobei der universal eindeutige Bezeichner ein Bezeichner mit vierundsechszig Hexadezimalzeichen ist.
Computerprogrammprodukt nach Anspruch 8, wobei die Anwendung dafür konfiguriert ist, mit mindestens einer Steuerung in einem Fahrzeugrechensystem über eine Anwendungsprogrammierschnittstelle zu kommunizieren.
Anwendungsstartverfahren, das Folgendes umfasst: Konfigurieren eines drahtlosen Signals, das einen ersten Anwendungsbezeichner für eine erste Anwendung, die in dem nomadischen Gerät gestartet werden soll, aufweist; und Broadcasten des drahtlosen Signals, einschließlich des Anwendungsbezeichners, über einen Transceiver.
Anwendungsstartverfahren nach Anspruch 15, wobei das drahtlose Signal ein BLUETOOTH-Signal ist.
Anwendungsstartverfahren nach Anspruch 16, wobei das BLUETOOTH-Signal ein BLUETOOTH-Beacongerät ist.
Anwendungsstartverfahren nach Anspruch 17, wobei das BLUETOOTH-Beacongerät ein iBeacon ist.
Anwendungsstartverfahren nach Anspruch 15, das ferner das Konfigurieren des drahtlosen Signals, das einen zweiten Anwendungsbezeichner für eine zweite Anwendung, die in dem nomadischen Gerät gestartet werden soll, aufweist, umfasst; und das drahtlose Signal einschließlich des zweiten Anwendungsbezeichners, über den Transceiver zu broadcasten.
Anwendungsstartverfahren nach Anspruch 19, zum Umfassen, als Reaktion darauf, dass der erste und/oder der zweite Anwendungsbezeichner mit mindestens einer Anwendung in dem nomadischen Gerät in Übereinstimmung gebracht wird, des Startens der mindestens einen Anwendung in dem nomadischen Gerät und des Kommunizierens von Daten von der mindestens einen Anwendung an die mindestens eine Steuerung in einem Fahrzeugrechensystem über eine Anwendungsprogrammierschnittstelle.