-
TECHNISCHES GEBIET
-
Die veranschaulichenden Ausführungsformen betreffen im Allgemeinen Verfahren und Geräte für einen mobilen Sitzungsaufbau mit belastbarer Wiederverbindungsstrategie.
-
ALLGEMEINER STAND DER TECHNIK
-
Fahrzeugtelematikeinheiten stellen eine Konnektivität und einen Fernressourcenzugang für Fahrzeugrechensysteme bereit, während das Fahrzeug unterwegs ist. Die Telematiksteuereinheit (telematics control unit - TCU) verbindet sich, üblicherweise durch Einsetzen eines Onboard-Mobilfünkmodems oder einer lokalen Benutzervorrichtung, mit einem Fern-Dienstbereitstellungsnetz (service delivery network - SDN), um Telematikdienste des Originalausrüstungsherstellers (OEM) zu erlangen. Dies kann unter anderem Musik, Werbung, Fahrzeugsoftwareupdates, Diagnoseübermittlung und eine beliebige andere Form von nützlicher Datenübertragung und nützlichem Datenempfang beinhalten.
-
Bei einem üblichen Modell baut die TCU eine Sitzung mit einem Kernnetz eines mobilen Bedieners und mit einem MQ-Telemetrietransport (message queuing telemetry transport - MQTT) auf, um eine Verbindung zwischen der TCU und dem SDN aufzubauen. Der MQTT ist das Sitzungsschichtprotokoll. Die TCU baut eine Sitzung mit einem Message Broker (AKA MQTT) auf, durch den sie mit dem SDN kommuniziert. Der Message Broker könnt eine vom SDN getrennte Einheit oder in diesem integriert sein.
-
Die Verbindung zum Kernnetz des mobilen Bedieners und/oder dem MQTT-Broker kann aus verschiedenen Gründen fehlschlagen. Dies verursacht eine Dienstunterbrechung und kann eine Erfahrung des Kunden verschlechtern, falls der Fehlschlag zu einem wichtigen Zeitpunkt vorkommt (z. B. wenn die TCU vom Kunden angeforderte Daten übermittelt). Während gewisse Paradigmen für Verbindung und Neuversuch bereits existieren, fehlen ihnen möglicherweise Aspekte, die dabei helfen könnten, eine belastbare Wiederverbindungsstrategie sicherzustellen.
-
KURZDARSTELLUNG
-
In einer ersten veranschaulichenden Ausführungsform beinhaltet ein System einen Prozessor, der dazu konfiguriert ist, eine Verbindung für Paketdaten (packet data - PD) für eine erste Anzahl von Versuchen, einschließlich einer vorbestimmten kurzen Verzögerung zwischen jedem erfolglosen Versuch, zu versuchen. Der Prozessor ist auch dazu konfiguriert, für eine längere vorbestimmte Verzögerung, die auf Grundlage einer vorbestimmten langen Verzögerung abzüglich einer Gesamtdauer vorhergehender fehlgeschlagener Verbindungsversuche bestimmt wird, als Reaktion auf einen weiteren fehlgeschlagenen Verbindungsversuch nach Fehlschlägen für die erste Anzahl von Versuchen zu verzögern und die Versuchs- und Verzögerungsschritte zu wiederholen, bis eine Verbindung aufgebaut ist.
-
In einer zweiten veranschaulichenden Ausführungsform beinhaltet ein computerimplementiertes Verfahren Wecken eines ausgeschalteten Fahrzeugs und Anfordern einer MQTT-Verbindung. Das Verfahren beinhaltet zudem Warten für einen vorbestimmten Zeitüberschreitungs-Zeitraum auf Grundlage einer erwarteten Verbindungszeit, bis die angeforderte MQTT-Verbindung aufgebaut ist. Das Verfahren beinhaltet ferner Starten eines Timers aus Reaktion auf das Aufbauen der MQTT-Verbindung, Senden beliebiger Fahrzeugwarnungen, die in einer Warteschlange anstehen, nach dem MQTT-Verbindungsaufbau, und Beenden der MQTT-Verbindung nach Ablauf des Timers, außer das Fahrzeug wurde eingeschaltet, bevor der Timer abgelaufen ist.
-
In einer dritten veranschaulichenden Ausführungsform beinhaltet ein System einen Fahrzeugprozessor, der dazu konfiguriert ist, eine MQTT-Verbindung als Reaktion auf eine Fahrzeugzündung anzufordern. Der Prozessor ist außerdem dazu konfiguriert, für die Dauer eines ersten Timers zu warten, die auf Grundlage einer erwarteten Zeitdauer vorbestimmt ist, um die MQTT-Verbindung aufzubauen und die MQTT-Verbindung nach Ablauf des ersten Timers zu entfernen. Der Prozessor ist außerdem dazu konfiguriert, für die Dauer eines zweiten Timers zu warten, die auf Grundlage einer Verzögerung, von der erwartet wird, dass sie dazu führt, dass eine weitere MQTT-Anforderung nicht abgelehnt wird, weil sie zu nahe an einer vorhergehenden MQTT-Verbindungsanforderung ist, vorbestimmt ist. Der Prozessor ist auch dazu konfiguriert, die Anforderung zu wiederholen, auf den ersten Timer zu warten, zu entfernen und auf die zweiten Timerschritte warten, bis die angeforderte MQTT-Verbindung aufgebaut ist.
-
Figurenliste
-
- 1 zeigt ein veranschaulichendes Fahrzeugrechensystem;
- 2 zeigt einen veranschaulichenden Prozess für MQTT-Verbindungsversuche;
- 3 zeigt einen veranschaulichenden Prozess eines Wiederverbindungsversuchs;
- 4 zeigt einen weiteren veranschaulichenden Prozess eines Wiederverbindungsversuchs; und
- 5 zeigt einen veranschaulichenden MQTT-Wiederversuchsprozess.
-
DETAILLIERTE BESCHREIBUNG
-
Wie erforderlich, sind hierin detaillierte Ausführungsformen offenbart; man muss jedoch verstehen, dass die offenbarten Ausführungsformen rein veranschaulichend sind und in verschiedenen und alternativen Formen ausgeführt werden können. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können stark vergrößert oder verkleinert sein, um Einzelheiten bestimmter Komponenten zu zeigen. Daher sollen hier offenbarte spezielle strukturelle und funktionale Einzelheiten nicht als einschränkend interpretiert werden, sondern lediglich als eine repräsentative Basis, um einen Fachmann zu lehren, wie der beanspruchte Gegenstand auf verschiedene Art und Weise einzusetzen ist.
-
1 veranschaulicht eine beispielhafte räumliche Blockanordnung für ein fahrzeugbasiertes Rechensystem 1 (vehicle based computing system - VCS) für ein Fahrzeug 31. Ein Beispiel eines solchen 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 Front-End-Schnittstelle 4 aufweisen, die sich im Fahrzeug befindet. Der Benutzer kann auch mit der Schnittstelle interagieren, falls diese zum Beispiel mit einem berührungsempfindlichen Bildschirm versehen ist. In einer anderen veranschaulichenden Ausführungsform findet die Interaktion durch das Drücken von Tasten, ein gesprochenes Dialogsystem mit automatischer Spracherkennung und Sprachsynthese statt.
-
In der in 1 gezeigten veranschaulichenden Ausführungsform 1 steuert ein Prozessor 3 zumindest einen Teil des Betriebs des fahrzeugbasierten Rechensystems. Falls er im Fahrzeug bereitstellt ist, ermöglicht der Prozessor eine Onboard-Verarbeitung von Befehlen und Routinen. Ferner ist der Prozessor sowohl mit einem nicht-persistenten Speicher 5 als auch mit einem persistenten Speicher 7 verbunden. In dieser veranschaulichenden Ausführungsform ist der nicht persistente Speicher ein wahlfreier Zugriffsspeicher (RAM) und ist der persistente Speicher ein Festplattenspeicher (HDD) oder ein Flashspeicher. Im Allgemeinen kann der persistente (nichtflüchtige) Speicher alle Formen von Speichern beinhalten, die Daten verwalten, wenn ein Computer oder eine andere Vorrichtung abgeschaltet wird. Dazu gehören unter anderem HDDs, CDs, DVDs, magnetische Bänder, Solid-State-Laufwerke, tragbare USB-Laufwerke und jede beliebige andere geeignete Form von persistentem Speicher.
-
Dem Prozessor wird auch eine Anzahl verschiedener Eingaben bereitgestellt, die es dem Benutzer ermöglichen, sich über eine Schnittstelle mit dem Prozessor zu verbinden. In dieser veranschaulichenden Ausführungsform sind ein Mikrofon 29, eine Hilfseingabe 25 (für die Eingabe 33), eine USB-Eingabe 23, eine GPS-Eingabe 24, ein Bildschirm 4, der eine Berührungsschirmanzeige sein kann, und eine BLUETOOTH-Eingabe 15 bereitgestellt. Ein Eingabewähler 51 ist ebenfalls bereitgestellt, damit ein Benutzer zwischen verschiedenen Eingaben wechseln kann. Die Eingabe sowohl für das Mikrofon als auch den Hilfsverbinder wird von einem Wandler 27 von analog in digital umgewandelt, bevor sie an den Prozessor geleitet wird. Wenngleich nicht dargestellt, können zahlreiche Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS kommunizieren, ein Fahrzeugnetzwerk (wie unter anderem einen CAN-Bus) verwenden, um Daten an das und von dem VCS (oder Komponenten davon) zu übertragen.
-
Ausgaben zum System können unter anderem eine visuelle Anzeige 4 und einen Lautsprecher 13 oder eine Stereosystemausgabe beinhalten. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal von dem Prozessor 3 durch einen Digital-Analog-Wandler 9. Eine Ausgabe kann auch an eine Fern-BLUETOOTH-Vorrichtung wie PND 54 oder eine USB-Vorrichtung wie eine Fahrzeugnavigationsvorrichtung 60 entlang der bidirektionalen Datenströme erfolgen, die bei 19 bzw. 21 dargestellt sind.
-
In einer veranschaulichenden Ausführungsform verwendet das System 1 den BLUETOOTH-Sendeempfänger 15, um mit einer tragbaren Vorrichtung 53 eines Benutzers (z. B. Mobiltelefon, Smartphone, PDA oder eine beliebige andere Vorrichtung, die eine drahtlose Fern-Netzwerkkonnektivität aufweist) zu kommunizieren (bei 17). Die tragbare Vorrichtung kann dann verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 durch beispielsweise Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren (bei 59). In einigen Ausführungsformen kann ein Mast 57 ein Wi-Fi-Zugangspunkt sein.
-
Eine beispielhafte Kommunikation zwischen der tragbaren Vorrichtung und dem BLUETOOTH-Sendeempfänger wird von dem Signal 14 dargestellt.
-
Die Kopplung einer tragbaren Vorrichtung 53 und des BLUETOOTH-Sendeempfängers 15 kann von einer Taste 52 oder einer ähnlichen Eingabe angewiesen werden. Dementsprechend wird die CPU angewiesen, dass der BLUETOOTH-Sendeempfänger an Bord mit einem BLUETOOTH-Sendeempfänger in einer tragbaren Vorrichtung gekoppelt wird.
-
Daten können zwischen der CPU 3 und dem Netzwerk 61 unter Verwendung zum Beispiel eines Datenplans, Data-Over-Voice oder DTMF-Tönen, die der tragbaren Vorrichtung 53 zugeordnet sind, übermittelt werden. Als Alternative kann es wünschenswert sein, ein Onboard-Modem 63 mit einer Antenne 18 aufzunehmen, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu übermitteln (bei 16). Die tragbare Vorrichtung 53 kann dann verwendet werden, um mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 durch beispielsweise Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren (bei 59). In einigen Ausführungsformen kann das Modem 63 eine Kommunikation 20 mit dem Mast 57 zum Kommunizieren mit dem Netzwerk 61 herstellen. Als ein nicht einschränkendes Beispiel kann das Modem 63 ein zelluläres USB-Modem sein und die Kommunikation 20 kann eine zelluläre Kommunikation sein.
-
In einer erläuternden Ausführungsform ist der Prozessor mit einem Betriebssystem versehen, das eine API aufweist, um mit einer Modemanwendungssoftware zu kommunizieren. Die Modemanwendungssoftware kann auf ein eingebettetes Modul oder Firmware auf dem BLUETOOTH-Sendeempfänger zugreifen, um eine drahtlose Kommunikation mit einem Fern-BLUETOOTH-Sendeempfänger (wie demjenigen in einer tragbaren Vorrichtung) zu vollenden. Bluetooth ist ein Teilsatz der IEEE 802 PAN (Personal Area Network)-Protokolle. IEEE 802 LAN (Local Area Network)-Protokolle schließen Wi-Fi ein und haben eine erhebliche Kreuzfunktionalität mit IEEE 802 PAN. Beide sind zur drahtlosen Kommunikation innerhalb eines Fahrzeugs geeignet. Ein weiteres Kommunikationsmittel, welches in diesem Bereich eingesetzt werden kann, sind die optische Freiraumkommunikation (wie beispielsweise IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
-
In einer anderen Ausführungsform beinhaltet die tragbare Vorrichtung 53 ein Modem zur Sprachband- oder Breitband-Datenkommunikation. In der Ausführungsform mit Data-Over-Voice kann eine Technik implementiert werden, die als Frequenzmultiplexverfahren bekannt ist, wenn der Besitzer der tragbaren Vorrichtung über die Vorrichtung sprechen kann, während Daten übertragen werden. Zu anderen Zeiten, wenn der Benutzer die Vorrichtung nicht nutzt, kann die Datenübertragung die gesamte Bandbreite (in einem Beispiel 300 Hz bis 3,4 kHz) nutzen. Während das Frequenzmultiplexverfahren bei der analogen zellulären Kommunikation zwischen dem Fahrzeug und dem Internet geläufig sein kann und nach wie vor verwendet wird, wurde es größtenteils durch Hybride der Folgenden für eine digitale Mobilfunkkommunikation ersetzt: Codemultiplexverfahren (CDMA), Zeitmultiplexverfahren (TDMA), Raummultiplexverfahren (SDMA). Falls der Nutzer über einen Datenplan, der dem mobilen Gerät zugeordnet ist, verfügt, ist es möglich, dass der Datenplan eine Breitbandübertragung erlaubt und das System könnte eine viel größere Bandbreite nutzen (was die Datenübertragung beschleunigen würde). In noch einer anderen Ausführungsform wird die tragbare Vorrichtung 53 durch eine zelluläre Kommunikationsvorrichtung (nicht dargestellt) ersetzt, die im Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform kann die ND 53 (Nomadic Device = tragbare Vorrichtung) eine drahtlose Local Area Network-(LAN)-Vorrichtung sein, die zur Kommunikation über beispielsweise (und ohne Einschränkung) ein 802.11g-Netzwerk (d. h. Wi-Fi) oder ein Wi-Max-Netzwerk fähig ist.
-
In einer Ausführungsform können ankommende Daten durch die tragbare Vorrichtung über Data-Over-Voice oder einen Datenplan durch den Onboard-BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs weitergeleitet werden. Im Falle bestimmter temporärer Daten können die Daten zum Beispiel auf dem HDD oder anderen Speichermedien 7 so lange gespeichert werden, bis die Daten nicht mehr benötigt werden.
-
Zusätzliche Quellen, die über eine Schnittstelle mit dem Fahrzeug verbunden sein können, beinhalten eine persönliche Navigationsvorrichtung 54, die zum Beispiel eine USB-Verbindung 56 und/oder eine Antenne 58 aufweist, eine Fahrzeugnavigationsvorrichtung 60, die eine USB 62 oder eine andere Verbindung aufweist, eine Onboard-GPS-Vorrichtung 24 oder ein Fern-Navigationssystem (nicht dargestellt), das Konnektivität zum Netzwerk 61 aufweist. USB ist eine von einer Klasse von seriellen Netzwerkprotokollen. Die seriellen Protokolle IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony) und Lynx™ (Texas Instruments)), 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 Gerät-zu-Gerät-Standards. Die meisten Protokolle können entweder zur elektrischen oder zur optischen Kommunikation verwendet werden.
-
Ferner könnte die CPU mit verschiedenen anderen Hilfsvorrichtungen 65 in Verbindung stehen. Diese Vorrichtungen können durch eine drahtlose Verbindung 67 oder eine drahtgebundene Verbindung 69 verbunden sein. Die Hilfsvorrichtung 65 kann unter anderem persönliche Mediaplayer, drahtlose Gesundheitsvorrichtungen, tragbare Computer und dergleichen beinhalten.
-
Ferner oder als Alternative könnte die CPU mit einem fahrzeugbasierten drahtlosen Router 73 verbunden sein, der zum Beispiel einen Wi-Fi (IEEE 803.11) 71-Sendeempfänger verwendet. Dadurch kann die CPU mit Fern-Netzwerken innerhalb der Reichweite des lokalen Routers 73 verbunden werden.
-
Zusätzlich zu beispielhaften Prozessen, die von einem Fahrzeugrechensystem ausgeführt werden, das sich in einem Fahrzeug befindet, können die beispielhaften Prozesse bei bestimmten Ausführungsformen von einem Rechensystem ausgeführt werden, das mit einem Fahrzeugrechensystem in Verbindung steht. Ein solches System kann unter anderem eine drahtlose Vorrichtung (z. B. und ohne Einschränkung ein Mobiltelefon) oder ein Fern-Rechensystem (z. B. und ohne Einschränkung ein Server), der durch die drahtlose Vorrichtung verbunden ist, beinhalten. Insgesamt können solche Systeme als fahrzeugassoziierte Rechensysteme (vehicle associated computing system - VACS) bezeichnet werden. In bestimmten Ausführungsformen können bestimmte Komponenten des VACS in Abhängigkeit der jeweiligen Implementierung des Systems bestimmte Teile eines Prozesses ausführen. Falls ein Prozess, als Beispiel und nicht beschränkend, einen Schritt des Sendens oder Empfangens von Informationen mit einer gekoppelten drahtlosen Vorrichtung aufweist, dann ist es wahrscheinlich, dass die drahtlose Vorrichtung diesen Teil des Prozesses nicht ausführt, da die drahtlose Vorrichtung keine Informationen an sich selbst „sendet und empfängt“. Ein Durchschnittsfachmann wird verstehen, wann es unangemessen ist, ein bestimmtes Rechensystem für eine gegebene Lösung anzuwenden.
-
Bei jeder der hier besprochenen beispielhaften Ausführungsformen ist ein beispielhaftes, nicht einschränkendes Beispiel eines Prozesses, der von einem Rechensystem durchführbar ist, gezeigt. Im Hinblick auf jeden Prozess ist es möglich, dass das Rechensystem, das den Prozess ausführt, nur für die Zwecke der Ausführung des Prozesses als ein Spezialprozessor konfiguriert ist, um den Prozess durchzuführen. Alle Prozesse müssen nicht in ihrer Gesamtheit durchgeführt werden und sind als Beispiele von Prozessarten zu verstehen, die durchgeführt werden können, um Teile der Erfindung zu erreichen. Zusätzliche Schritte können je nach Wunsch zu den beispielhaften Prozessen hinzugefügt oder aus diesen entfernt werden.
-
Im Hinblick auf die in der Figur beschriebenen erläuternden Ausführungsformen, die erläuternde Prozessabläufe zeigen, sei angemerkt, dass ein Universalprozessor vorübergehend als ein Spezialprozessor aktiviert werden kann, um einige oder alle der in diesen Figuren dargestellten beispielhaften Verfahren auszuführen. Beim Ausführen von Code, der Anweisungen zum Durchführen einiger oder aller Schritte des Verfahrens bereitstellt, kann der Prozessor vorübergehend zu einem Spezialprozessor umfunktioniert werden, bis zu dem Zeitpunkt, wenn das Verfahren abgeschlossen ist. In einem anderen Beispiel kann, soweit angemessen, Firmware, die gemäß einem vorkonfigurierten Prozessor wirkt, veranlassen, dass der Prozessor als ein Spezialprozessor zu wirken, der zur Durchführung des Verfahrens oder einer geeigneten Variation davon bereitgestellt ist.
-
Die veranschaulichenden Ausführungsformen schlagen Verbindungs- und Neuversuchsstrategien vor, die einen Vollleistungs-/Standbymodus und einen Niedrigleistungsmodus umfassen, wobei der Focus zumindest teilweise auf Leistungserhalt liegt.
-
Im Vollleistungs-/Standbymodus ist der veranschaulichende Prozess ausgelegt, bei möglichen Fehlschlagszenarien belastbar zu sein und zur gleichen Zeit verfügbare Netzressourcen zu optimieren und mit Trägeranforderungen übereinzustimmen. Da es eine feine Grenze gibt zwischen effizientem Neuanfordern einer Netzressource und vom Netz als aggressiv betrachtet zu werden, beinhaltet die dynamische Strategie Versuchen, die PDN-Konnektivität dreimal (oder eine andere vernünftige Zahl) in konfigurierbaren „kurzen PD-Verzögerungstimer“-Intervallen zu aktivieren, dann die „Netzzugangsvorrichtung“ zurückzusetzen, um jeden möglichen modeminternen Fehlschlag oder Anwendungs-Modem-Fehlschlag zu lösen, dann Versuchen für ein viertes Mal. Während dieser ersten Phase der Strategie kann ein Häufungstimer laufen, um den Zeitraum zum Vollenden dieser Phase zu berechnen. Der Wert des Häufungstimers wird von einem konfigurierbaren „lange PD-Verzögerung“-Timer subtrahiert und das Modem wartet für den Rest der langen Verzögerung und wiederholt dann die Strategie.
-
Im Niedrigleistungsmodus beinhaltet ein Schwerpunkt den Verbrauch von so wenig Leistung wie möglich, während ein effizienter Verbindungsmechanismus aufrechterhalten wird. Somit versucht die TCU eine Paketverbindungsanforderung an einen „Zugangspunkt“ des Netzes nicht erneut, wenn die TCU auf einen Fehlschlag auf dieser Ebene trifft. Gleichzeitig kann die TCU eine konfigurierbare Timerverzögerung „Zeitüberschreibung Verbindung“ für das Netz tolerieren, um die Sitzung mit dem MQTT aufzubauen und kann dies im Falle eines Fehlschlags für eine konfigurierbare Anzahl von Versuchen wiederholen.
-
2 zeigt einen veranschaulichenden Prozess für MQTT-Verbindungsversuche. In diesem Beispiel erkennt der Prozess bei 201 einen Zustand der eingeschalteten Zündung. Somit kann der Prozess die MQTT-Verbindung versuchen, wenn ein Fahrer das Fahrzeug startet. Bevor die MQTT-Verbindung angefordert wird, kann der Prozess beliebige Variablen initialisieren, die in dem Prozess verwendet werden. Diese können vom Benutzer/OEM konfigurierbare Variablen beinhalten, und in diesem Fall beinhalten die Variablen einen Verzögerungstimerwert und einen Verbindungsverlängerungszeitwert.
-
Der Prozess fordert eine MQTT-Verbindung an und setzt bei 205 einen ersten Timer A. Der Prozess verwendet diesen Timer, um die Zeitdauer zu bestimmen, die der Verbindungsversuch ansteht, bevor der Prozess die MQTT-Anforderung entfernt. In diesem Beispiel kann der Timer auf 30 Sekunden gesetzt sein, auch wenn jeder geeignete Timerwert verwendet werden kann. Während die 30 Sekunden laufen, versucht der Prozessor bei 207, sich mit dem MQTT-Broker zu verbinden.
-
Wenn der Verbindungsversuch bei 209 nicht erfolgreich ist, bestimmt der Prozess bei 211, ob der Timer A abgelaufen ist. Solange noch Zeit verbleibt, fährt der Prozess mit dem Verbindungsversuch fort. Sobald der Timer abgelaufen ist, entfernt der Prozess bei 213 den Verbindungsversuch und leitet bei 215 einen zweiten Timer B ein. Der zweite Timer ist ein Verzögerungstimer und stellt das Ausmaß der Verzögerung dar, bevor der Prozess den Verbindungsversuch wiederholt. Sobald der Timer B abgelaufen ist und die angemessene Verzögerung bei 217 erreicht ist, wiederholt der Prozess bei 205 den Verbindungsversuch. In diesem Beispiel wird die Zeitdauer, über die der Timer B läuft, auf Grundlage eines Vergleichs mit dem oben erläuterten Verzögerungstimerwert bestimmt. Die Verzögerung kann zum Beispiel auf Grundlage einer vernünftigen erwarteten MQTT-Reaktionszeit neu konfiguriert werden.
-
Wenn der Verbindungsversuch innerhalb der vom Timer A gesetzten Zeit erfolgreich ist, leitet der Prozess bei 219 einen Timer C ein, der der Zeitdauer entspricht, über die die MQTT-Sitzung nach einem Zustand der ausgeschalteten Zündung vorhanden ist. Der Prozess vergleicht bei 221 die Zeit, die der Timer C gelaufen ist, mit dem Wert, der für den Verbindungsverlängerungszeitwert gesetzt ist, um zu bestimmen, ob die MQTT-Sitzung andauern soll. Sobald der Wert des Timers C den Verlängerungswert übersteigt, beendet der Prozess bei 223 die MQTT-Sitzung.
-
3 zeigt einen veranschaulichenden Prozess eines Wiederverbindungsversuchs. Dieser Prozess kann ähnlich den bestehenden Wiederverbindungsversuchprozessen sein. In diesem Beispiel fordert der Prozess bei 301 eine Paketdaten (PD)-Verbindung an. Ähnlich zu 2 initialisiert der Prozess bei 303 alle Variablen, die zur Ausführung benötigt werden. Diese Werte können auf vom Benutzer oder OEM konfigurierten Werten für die Variablen basieren, und in diesem Beispiel beinhalten die Werte einen Verzögerungstimer und eine Gesamtversuchszahl.
-
In diesem Beispiel setzt der Prozess einen Versuchszähler bei 305 auf null und setzt eine aktive Variable bei 307 auf „wahr“. Dies gibt an, dass eine Paketdatenverbindung immer noch benötigt wird. Der Prozess versucht dann bei 309, eine PD-Verbindung aufzubauen. Bei Erfolg geht der Prozess zum Ende, da er die gewünschte Verbindung aufgebaut hat.
-
Wenn der Verbindungsversuch nicht erfolgreich ist, bestimmt der Prozess bei 313, ob der Versuchszähler unter dem konfigurierbaren Schwellenwert für die Gesamtversuchsanzahl liegt. Wenn der Zähler über dem Schwellenwert liegt, setzt der Prozess bei 325 den Verzögerungszähler auf einen konfigurierbaren vorbestimmten Wert. Wenn der Zähler unter dem Schwellenwert der Maximalanzahl liegt, setzt der Prozess den Zähler bei 315 hoch und referenziert bei 317 eine Lookup-Tabelle, basierend auf dem Zählerwert, um eine angemessene Verzögerungszeit zu bestimmen.
-
In diesem Beispiel ist eine veranschaulichende Lookup-Tabelle in 3 als 317a gezeigt. Wie aus der Tabelle 317a zu erkennen ist, wird der Verzögerungswert schrittweise hochgesetzt, wenn die Zahl größer wird. Dies bedeutet, dass erfolgreiche Versuche zunehmende Verzögerungen vor der Aktivierung erfahren.
-
Nach dem Setzen der angemessenen Zeit für die Verzögerung setzt der Prozess bei 319 das Aktiv-Flag (das einen andauernden Verbindungsversuch angibt) auf falsch. Der Prozess aktiviert dann bei 321 einen Timer, der ausgeführt wird, bis der Timerwert bei 323 den gesetzten Verzögerungswert übersteigt. Dann wird der Verbindungsversuch wiederholt.
-
4 zeigt einen weiteren veranschaulichenden Prozess eines Wiederverbindungsversuchs. Dieser Prozess stellt eine Alternative zu dem in 3 gezeigten Prozess dar und kann einige Wirkungen erzielen, die durch den Prozess der 3 nicht erreicht werden können. In diesem Beispiel empfängt der Prozess bei 401 eine Anforderung, einen PDP-Kontext oder einen PD-Verbindungsversuch zu aktivieren.
-
Wiederum initialisiert der Prozess bei 403 eine Reihe von nützlichen Variablen, die ebenfalls wieder vom Benutzer/OEM konfigurierbar sind. In diesem Beispiel setzt der Prozess eine kurze Verzögerung, eine lange Verzögerung und einen Zählwert. Der Prozess setzt zudem bei 405 einen Versuchszähler auf null und initialisiert bei 407 einen Häufungstimer.
-
In diesem Beispiel verwendet der Prozess den Häufungstimer, um die Gesamtzeit, die die Häufung von Anforderungen gedauert hat, zu messen. Dieser Wert wird dann von dem Verzögerungstimer subtrahiert, um einen Verzögerungswert zu erlangen, der einer Zeitdauer, die von den gehäuften Versuchen belegt wurde, Rechnung trägt.
-
Der Prozess versucht bei 409 eine PD-Kontextaktivierung/einen PD-Verbindungsversuch. Bei LTE-Kommunikation über einen standardmäßigen Träger (der immer aktive logische Pfad zwischen der TCU und dem Gateway des drahtlosen Netzes), kann diese Aktivierung beinhalten, dass die TCU-Anwendung eine Verbindung zu einem Modem-TCP/IP-Stapel anfordert, gefolgt von der Verwendung eines Jasper-Zugangspunktkamens (APN), um den MQTT-Broker zu erreichen. Bei LTS-Verbindungen mit zusätzlichen Trägern (z. B. Wi-Fi) würde dies Einrichten eines neuen Trägerkanals beinhalten. Bei 3G-Kommunikation würde dies PD-Kontextaktivierung und Übernahme einer IP-Adresse beinhalten.
-
Ein Fehlschlag unter den vorstehenden Umständen kann auf Grundlage der versuchten Verbindungsart variieren. Bei LTE-Kommunikation kann sich ein weitverbreiteter Fehlschlag auf ein internes TCU/Modem-Schnittstellenproblem beziehen. Bei 3G- und LTE-Kommunikation mit zusätzliche Trägern könnte ein Fehlschlag durch ein Netzproblem verursacht werden.
-
Wenn der Verbindungsversuch bei 411 erfolgreich ist, setzt der Prozess bei 413 alle Zähler und Timer zurück und/oder verwirft deren Werte. Wenn der Verbindungsversuch nicht erfolgreich ist, kann der Prozess bei 415 einen Versuchszähler erhöhen. Wenn die Versuchszahl bei 417 immer noch unter dem definierten Schwellenwert liegt, kann der Prozess die Verzögerung bei 423 auf den kurzen Verzögerungswert setzen (da die Zahl der insgesamt angehäuften Versuche noch nicht versucht wurde). Wenn der Versuchszähler bei 419 auf dem Schwellenwert ist (der letzte angehäufte Versuch), kann der Prozess einen Rest versuchen, indem er bei 421 im Flugmodus läuft (bei dem alle Konnektivität deaktiviert ist), und dann bei 423 den Verzögerungswert auf den kurzen Timer setzen. Dieses periodische Zurücksetzen geht alle Probleme an, die durch Zurücksetzen des Systems gelöst werden können, was in der vorhergehenden Figur fehlt.
-
Wenn die Versuchszahl den Schwellenwert überschritten hat, kann der Prozess bei 425 den Verzögerungswert auf Grundlage des langen Verzögerungswerts abzüglich des aktuellen Häufungstimerwerts (die Dauer der vorherigen Verbindungsversuche in der Häufung) setzen. Der Prozess hält dann bei 427 den Häufungstimer an und setzt den Versuchszähler bei 429 zurück.
-
An diesem Punkt beginnt der Prozess bei 431 einen Verzögerungstimer für die Dauer 433, die durch das Setzen der Verzögerung festgelegt wird, egal ob die Verzögerung auf eine lange Verzögerung oder eine kurze Verzögerung gesetzt war. Sobald die Verzögerung verstrichen ist, bestimmt der Prozess bei 435, ob die Verzögerung einer langen Verzögerung oder einer kurzen Verzögerung entsprochen hat. Falls die Verzögerung eine lange Verzögerung war, kehrt der Prozess zurück zum Zurücksetzen des Häufungstimers 407, während der Prozess, wenn die Verzögerung eine kurze Verzögerung war (ein Versuch innerhalb der Anzahl von zulässigen angehäuften Versuchen), zu dem Versuch, den PD-Kontext bei 409 zu aktivieren, zurückkehrt. In letzterem Fall misst der Burst-Verzögerungstimer immer noch die Gesamtzeit für die Häufung.
-
5 zeigt einen veranschaulichenden MQTT-Neuversuchsprozess. In diesem Beispiel beinhaltet der Prozess einen Weckprozess und einen Warnungsprüfungsprozess. Dieser Prozess ist nützlich, wenn sich das Fahrzeug in einem Niedrigleistungszustand befindet, etwa wenn das Fahrzeug zum Beispiel nicht eingeschaltet ist. Das Fahrzeug kann eine Warnung erkennen oder anderweitig einen Weckbefehl empfangen und kann in beiden Fällen Verwendung einer Verbindung für Berichte anfordern.
-
In diesem Beispiel empfängt der Prozess bei 501 einen Weckbefehl und baut bei 503 eine PD-Verbindung auf. Der Prozess setzt ebenfalls einen Zähler für MQTT-Anforderungsversuche bei 505 auf null und erstellt bei 507 einen MQTT-Broker-Verbindungsversuch.
-
Der Prozess startet bei 509 einen Timer und setzt einen Zähler hoch, und wartet dann, ob der Verbindungsversuch bei 511 erfolgreich ist. Wenn der Prozess nicht verbindet, bestimmt der Prozess bei 513, ob der Timer einen Schwellenwert erreicht hat. Falls der Prozess den Timer-Schwellenwert ohne Verbindung erreicht, entfernt der Prozess 515 die Verbindungsversuchanforderung und fährt damit fort, bei 533 zu bestimmen, ob registrierte Niedrigleistungsbedingungen (LPR) erfüllt sind, was nachfolgend erläutert wird. Zur Erläuterung: FPO steht für „volle Leistung an“ und FPS steht für „volle Leistung Standby“.
-
Wenn der Prozess verbinden kann, setzt der Prozess bei 517 den Timer zurück und setzt den Versuchszähler auf null. Der Prozess startet zudem den Timer neu, zur Verwendung bei der Nachverfolgung der Länge der MQTT-Sitzung. Der verbundene Prozess bestimmt bei 519, ob Warnungen in einer Warteschleife anstehen. Falls nicht, hält der Prozess bei 521 die MQTT-Verbindung für ein festgelegtes Timermaß aufrecht. Dies kann ermöglichen, dass alle Warnungen, die während dieser Zeit auftreten, sofort in die Warteschlange eingereiht werden. Sobald der Timer abläuft, überprüft der Prozess, ob die LPR-Bedingungen erfüllt sind. Wenn sich eine oder mehrere Warnungen in der Warteschlange befinden, sendet der Prozess bei 523 die Warnung an den richtigen Beteiligten. Der Prozess wartet dann, bis die Warnung bei 525 quittiert wird, wobei der Prozess an diesem Punkt bei 529 die Warnung aus der Warteschlange löscht. Während der Prozess wartet, berücksichtigt der Prozess, ob bei 527 eine Zeitüberschreitung auftritt. Dieser Warnungsausgabe- und Wartezeitraum dauert an, bis der laufende Timer bei 531 den MQTT-Schwellenwert übersteigt. An diesem Punkt berücksichtigt der Prozess bei 533, ob Bedingungen für LPR erfüllt sind.
-
Wenn die Bedingungen für LPR erfüllt sind, wiederholt der Prozess die Verbindungsversuche bei 535 so lange, wie der Versuchszähler unter einem vorgesehenen Neuversuchsschwellenwert liegt. Wenn die Zahl bei 535 den Schwellenwert übersteigt, bricht der Prozess die PD-Verbindung bei 537 ab und endet. Wenn die Bedingungen für LPR nicht erfüllt sind (wenn das Fahrzeug bei voller Leistung ist), hält der Prozess die Verbindung aufrecht, wenn sie aufgebaut ist, oder bleibt bei den Verbindungsversuchen, wenn die Verbindung noch nicht aufgebaut ist.
-
Durch die Verwendung der veranschaulichenden Ausführungsformen können belastbare und stabile Verbindungsversuche und Wiederverbindungsversuche bei Fahrzeugzuständen mit voller Leistung oder niedriger Leistung verarbeitet werden. Gleichzeitig können Verzögerungen minimiert werden und Resets, die zum Beheben bestimmter Probleme erforderlich sind, können aufgenommen werden. Dies hilft dabei, Verzögerung für den Kunden und mögliche Beeinträchtigung zu minimieren, während eine andauernde Konnektivität bereitgestellt wird.
-
Auch wenn oben beispielhafte Ausführungsformen beschrieben sind, ist es nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Vielmehr sind die in der Beschreibung verwendeten Begriffe beschreibende und nicht einschränkende Begriffe, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne von Geist und Umfang der Erfindung abzuweichen. Zusätzlich können die Merkmale verschiedener realisierter Ausführungsformen in logischer Weise kombiniert werden, um je nach Situation geeignete Variationen der hierin beschriebenen Ausführungsformen zu erzeugen.
