DE102017119451A1

DE102017119451A1 - Verfahren zum Telematikkonnektivitätsmanagement

Info

Publication number: DE102017119451A1
Application number: DE102017119451.7A
Authority: DE
Inventors: Andrew J. Macdonald; George Knish; James J. Piwowarski; Scott T. Droste
Original assignee: GM Global Technology Operations LLC
Current assignee: GM Global Technology Operations LLC
Priority date: 2016-08-26
Filing date: 2017-08-24
Publication date: 2018-03-01
Also published as: CN108307461A; US20180063882A1

Abstract

Verfahren zum Konnektivitätsmanagement einer Telematikeinheit. Das Verfahren umfasst: Einstellung einer Telematikeinheit über eine Steuerung in einem ersten Konnektivitätsmodus; Aufbauen einer Kommunikation mit einem Drahtlosträgersystem über eine Antenne in dem ersten Konnektivitätsmodus; Bestimmen über die Steuerung, dass bei dem Fahrzeug ein Konnektivitätsartereignis aufgetreten ist; Schalten der Telematikeinheit über die Steuerung aus dem ersten Konnektivitätsmodus in einen zweiten Konnektivitätsmodus; und Aufbauen einer Kommunikation mit dem Drahtlosträgersystem über die Antenne in dem zweiten Konnektivitätsmodus.

Description

EINLEITUNG
Mobilfunknetze sind nicht allgegenwärtig. Ein bestimmter Prozentsatz der Sprach- und Datenanrufe ist nicht mit ihrem beabsichtigten Drahtlosträgersystem verbindbar. Bei der Betrachtung von Fahrzeugtelematik können fehlgeschlagene Aufrufe für bestimmte kritischen Anwendungen, wie z. B. Fahrzeugaufprallbenachrichtigung und Notrufe, schädlich sein. Aufgrund ihres geringen Datendurchsatzes und geringen Latenzanforderungen kann eine Konnektivität des Internets der Dinge (IoT), die in der Regel durch einen 4.5G oder 5G 3GPP Standard (Third Generation Partnership Project Standard) implementiert wird, viel weiter als andere 3GPP-Konnektivitätsarten verbreitet werden. Die Konnektivität des Internets der Dinge (IoT) kann daher durchgeführt werden, um einem Anrufer stärkere Erfolgschancen zu bieten, wenn andere 3GPP-Verbindungen nicht hergestellt werden können.
Die Telematikeinheit zieht außerdem Energie aus der Batterie, wenn das Fahrzeug nicht geladen wird (Zündung aus). Obwohl der Telematikeinheit ein Energiebudget zugewiesen wird, ist die Telematikeinheit nur für eine vorgegebene Zeitspanne aktiv, um dem Budget zu entsprechen. Wie folgt, kann während dieser Zeitspanne das Gerät erreicht werden, um grundlegende Funktionen, wie Fernstart oder Türentriegelung, auszuführen. Nach Ablauf dieses Zeitraums jedoch ist die Telematikeinheit funktionsunfähig und kann zum Ausführen solcher Aufgaben nicht erreicht werden. Aufgrund seines geringen Datendurchsatzes und der geringen Latenzanforderungen zieht die Konnektivität des Internets der Dinge wenig Energie und würde der Telematikeinheit ermöglichen, für längere Zeiträume aktiv zu bleiben, ohne das zugeteilte Energiebudget zu überschreiten. Es ist daher wünschenswert, dass die Telematikeinheit eine Managementkonfiguration beinhaltet, die es ermöglicht, dass Konnektivitätsarten des Internets der Dinge für eine verbesserte Leistung unter bestimmten Umständen genutzt werden kann.
ZUSAMMENFASSUNG
Ein Verfahren zum Konnektivitätsmanagement einer Telematikeinheit wird hierin vorgestellt. Das Verfahren umfasst: Einstellung einer Telematikeinheit über eine Steuerung in einem ersten Konnektivitätsmodus; Aufbauen einer Kommunikation mit einem Drahtlosträgersystem über eine Antenne in dem ersten Konnektivitätsmodus; Bestimmen über die Steuerung, dass bei dem Fahrzeug ein Konnektivitätsartereignis aufgetreten ist; Schalten der Telematikeinheit über die Steuerung aus dem ersten Konnektivitätsmodus in einen zweiten Konnektivitätsmodus; und Aufbauen einer Kommunikation mit dem Drahtlosträgersystem über die Antenne in dem zweiten Konnektivitätsmodus.
Das Verfahren kann weiterhin umfassen zu versuchen, die Drahtlosträgersystemkommunikation im ersten Konnektivitätsmodus wiederherzustellen. Das Konnektivitätsartereignis kann sein, dass das Fahrzeug AUSGESCHALTET wird. Die Konnektivitätsartereignis kann auch darin bestehen, dass das Fahrzeug mit einer Batterie bei einem vorgegebenen Ladezustand läuft. Die Konnektivitätsartereignis kann auch von der Steuerung erstellt werden, und auf einem bestimmten Zeitpunkt basieren. Die spezifische Uhrzeit kann auf dem Ablauf eines vorgegebenen Zeitgeberwerts basieren.
Das Konnektivitätsereignis kann ein gescheiterter Versuch sein, eine Fahrzeugaufprallbenachrichtigung zu senden und/oder einen Notruf aufzubauen. Das Ereignis mit niedriger Konnektivität kann auftreten, wenn die normale Konnektivitätsart das Drahtlosträgersystem nicht erreicht oder sich das Fahrzeug an einem Standort ohne Service-Konnektivität befindet.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Eine oder mehrere Ausführungsformen der Erfindung werden im Folgenden in Verbindung mit den beigefügten Zeichnungen beschrieben, worin gleiche Bezeichnungen gleiche Elemente bezeichnen, und worin:
1 ein Blockdiagramm ist, das eine Ausführungsform eines Kommunikationssystems darstellt, das fähig ist, das hierin offenbarte Verfahren zu verwenden;
2 eine Ansicht eines exemplarischen Fahrzeugs in einer exemplarischen Umgebung ist, in der eine Ausführungsform eines Verfahrens zum Fahrzeugtelematik-Konnektivitätsmanagement umgesetzt werden kann;
3 ein exemplarisches Flussdiagramm eines exemplarischen algorithmischen Verfahrens des Fahrzeugtelematik-Konnektivitätsmanagements ist; und
4 ein exemplarisches Flussdiagramm eines exemplarischen algorithmischen Verfahrens des Fahrzeugtelematik-Konnektivitätsmanagements ist.
AUSFÜHRLICHE BESCHREIBUNG
Ausführungsformen der vorliegenden Offenbarung werden hierin 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 unbedingt maßstabsgerecht; einige Merkmale können größer oder kleiner dargestellt sein, um die Einzelheiten bestimmter Komponenten zu veranschaulichen. Folglich sind die offenbarten aufbau- und funktionsspezifischen Details nicht als einschränkend zu verstehen, sondern lediglich als repräsentative Grundlage, um den Fachleuten die verschiedenen Arten und Weisen der Nutzung der exemplarischen Aspekte der vorliegenden Offenbarung zu vermitteln. Wie der Fachleute verstehen, können verschiedene Merkmale, die mit Bezug auf beliebige der Figuren dargestellt und beschrieben werden, mit Merkmalen kombiniert werden, die in einer oder mehreren anderen Figuren dargestellt sind, um Ausführungsformen zu erzeugen, die nicht explizit dargestellt oder beschrieben sind. Die dargestellten Kombinationen von Merkmalen stellen repräsentative Ausführungsformen für typische Anwendungen bereit. Beliebige Kombinationen und Modifikationen der Merkmale, die mit den Lehren dieser Offenbarung übereinstimmen, könnten jedoch für bestimmte Anwendungen und Implementierungen erwünscht sein.
Mit Bezug auf 1 ist eine Betriebsumgebung dargestellt, die u. a. ein mobiles Fahrzeugkommunikationssystem 10 umfasst, das verwendet werden kann, um das hierin offenbarte Verfahren zu implementieren. Das Kommunikationssystem 10 umfasst im Allgemeinen ein Fahrzeug 12, ein oder mehrere Drahtlosträgersysteme 14, ein Festnetz 16, einen Computer 18 und ein Datenzentrum 20. Es versteht sich, dass das offenbarte Verfahren mit einer beliebigen Anzahl von unterschiedlichen Systemen verwendet werden kann und nicht speziell auf die hierin gezeigte Betriebsumgebung einschränkt ist. Auch die Architektur, Konstruktion, Konfiguration und der Betrieb des Systems 10 und seiner einzelnen Komponenten sind in der Technik allgemein bekannt. Somit stellen die folgenden Absätze lediglich einen kurzen Überblick über ein solches Kommunikationssystem 10 bereit; aber auch andere, hierin nicht dargestellte Systeme könnten die offenbarten Verfahren einsetzen.
Fahrzeug 12 ist in der veranschaulichten Ausführungsform als ein Personenkraftwagen dargestellt, es sollte jedoch beachtet werden, dass jedes andere Fahrzeug, einschließlich Motorräder, Lastwagen, Geländewagen (SUV), Campingfahrzeuge (RV), Wasserfahrzeuge, Flugzeuge usw. ebenfalls verwendet werden kann. Ein Teil der Fahrzeugelektronik 28 wird im Allgemeinen in 1 gezeigt und beinhaltet eine Telematikeinheit 30, ein Mikrofon 32, eine oder mehrere Tasten oder andere Steuereingänge 34, ein Audiosystem 36, eine optische Anzeige 38, ein GPS-Modul 40 sowie eine Anzahl von Fahrzeugsystemmodulen (VSMs) 42. Einige dieser Vorrichtungen können direkt mit der Telematikeinheit, wie z. B. dem Mikrofon 32 und der/den Taste(n) 34, verbunden sein, während andere indirekt unter Verwendung einer oder mehrerer Netzwerkverbindungen, wie einem Kommunikationsbus 44 oder einem Entertainmentbus 46, verbunden sind. Beispiele geeigneter Netzwerkverbindungen beinhalten ein Controller Area Network (CAN), einen medienorientierten Systemtransfer (MOST), ein lokales Kopplungsstrukturnetzwerk (LIN), ein lokales Netzwerk (LAN) und andere geeignete Verbindungen, wie z. B. Ethernet oder andere, die u. a. den bekannten ISO-, SAE- und IEEE-Standards und -Spezifikationen entsprechen.
Die Telematikeinheit 30 kann eine OEM-installierte (eingebettete) oder eine Aftermarketvorrichtung sein, die in dem Fahrzeug installiert ist und drahtlose Sprach- und/oder Datenkommunikation über das Drahtlosträgersystem 14 und über drahtlose Vernetzung ermöglicht. Dies ermöglicht dem Fahrzeug die Kommunikation mit dem Datenzentrum 20, anderen telematikfähigen Fahrzeugen oder anderen Einheiten oder Vorrichtungen. Die Telematikeinheit verwendet vorzugsweise Funkübertragungen, um einen Kommunikationskanal (einen Sprachkanal und/oder einen Datenkanal) mit dem Drahtlosträgersystem 14 herzustellen, sodass Sprach- und/oder Datenübertragungen über den Kanal gesendet und erhalten werden können. Durch Bereitstellen von sowohl Sprach- als auch Datenkommunikation ermöglicht die Telematikeinheit 30 dem Fahrzeug das Anbieten einer Anzahl von unterschiedlichen Diensten, darunter solche, die sich mit Navigation, Fernsprechen, Nothilfe, Diagnose, Infotainment usw. befassen. Daten können entweder über eine Datenverbindung, z. B. die Paketdatenübertragung über einen Datenkanal oder über einen Sprachkanal unter Verwendung von auf dem Fachgebiet bekannten Techniken gesendet werden. Für kombinierte Dienste, die sowohl Sprachkommunikation (z. B. mit einem Live-Berater oder einer Sprachdialogeinheit im Datenzentrum 20) als auch Datenkommunikation (z. B. für die Bereitstellung von GPS-Ortsdaten oder Fahrzeugdiagnosedaten im Datenzentrum 20) einschließen, kann das System einen einzelnen Anruf über einen Sprachkanal verwenden und nach Bedarf zwischen Sprach- und Datenübertragung über den Sprachkanal umschalten, und dies kann unter Verwendung von Techniken erfolgen, die dem Fachmann bekannt sind.
Gemäß einer Ausführungsform verwendet die Telematikeinheit 30 Mobilfunkkommunikation entweder nach verschiedenen Standards, aber nicht beschränkt auf beispielsweise 3GPP-(Third Generation Partnership Project Standard) oder 3GPP2 (Code Division Multiple Access/Codevielfachzugriff)-Standards, und beinhaltet somit einen Mobiltelefonchipsatz 50 für die Sprachkommunikation, wie Freisprechen, ein drahtloses Modem für die Datenübertragung, eine Telematiksteuerungsvorrichtung 52, eine oder mehrere digitale Speichervorrichtungen 54 und eine Dual-Antenne 56. Es versteht sich, dass das Modem entweder durch Software implementiert sein kann, die in der Telematikeinheit 30 gespeichert ist, und durch die Steuerung 52 ausgeführt wird, oder es kann eine separate Hardwarekomponente sein, die sich innerhalb oder außerhalb der Telematikeinheit 30 befinden kann. Das Modem kann mithilfe einer beliebigen Anzahl unterschiedlicher Standards oder Protokolle, wie etwa GSM, EVDO, CDMA, GPRS, EDGE, UMTS und LTE betrieben werden, ist jedoch nicht darauf beschränkt. Die drahtlose Vernetzung zwischen dem Fahrzeug und den anderen vernetzten Vorrichtungen kann auch unter Verwendung der Telematikeinheit 30 erfolgen. Für diesen Zweck kann die Telematikeinheit 30 konfiguriert sein, gemäß einem oder mehreren Protokollen drahtlos zu kommunizieren, wie irgendwelche von den IEEE 802.11-Protokollen, WiMAX oder Bluetooth. Wenn die Telematikeinheit für paketvermittelte Datenkommunikation, wie TCP/IP, verwendet wird, kann sie mit einer statischen IP-Adresse konfiguriert oder eingerichtet werden, automatisch eine zugewiesene IP-Adresse von einer anderen Vorrichtung am Netzwerk, wie einem Router oder einem Netzwerkadressenserver, erhalten.
Die Telematiksteuerung 52 (Prozessor) kann jede Vorrichtungsart sein, die fähig ist, elektronische Befehle zu verarbeiten, einschließlich Mikroprozessoren, Mikrocontrollern, Hostprozessoren, Steuerungen, Fahrzeugkommunikationsprozessoren und anwendungsspezifische integrierte Schaltungen (ASICs). Er kann ein speziell dafür vorgesehener Prozessor sein, der nur für die Telematikeinheit 30 verwendet wird, oder er kann mit anderen Fahrzeugsystemen geteilt werden. Die Telematiksteuerung 52 führt verschiedene Arten von digital gespeicherten Befehlen aus, wie beispielsweise Software- oder Firmware-Programme, die in dem Speicher 54 gespeichert sind und die es der Telematikeinheit ermöglichen, eine breite Vielfalt von Diensten bereitzustellen, wie beispielsweise, aber nicht beschränkt auf das Verschieben zwischen zwei oder mehreren Konnektivitätsmodi, um der Telematikeinheit 30 zu ermöglichen, die Antenne 56 zu aktivieren, um mit verschiedenen Typen eines 3GPP-Zellkommunikationsstandards oder verschiedenen Konnektivitätsarten eines einzelnen 3GPP-Standards zu kommunizieren. Zum Beispiel kann die Steuerung 52 Programme ausführen oder Daten verarbeiten, um mindestens einen Teil des Verfahrens auszuführen, das hierin beschrieben ist.
Die Dual-Antenne 56 kann Sender und Empfänger-Hardware-Komponenten enthalten, die Upload und Download von Datenübertragungen mit verschiedenen Bandbreiten und Bereichen der Kommunikation ermöglichen. Die Dual-Antenne 56 kann Maschinentyp-Kommunikation (MTC) senden und empfangen, wobei die Telematikeinheit 30 automatisch mit einer weit entfernten Maschine kommuniziert, wie z. B., aber nicht beschränkt auf, Computer 18 oder auf einen Server, der sich im Datenzentrum 20 (unten abgehandelt) befindet. Wenn die Telematikeinheit 30 einen Modus der Durchführung von Mobilfunkkommunikationen nach einem 4 G LTE nutzt, kann die Antenne 56 Kategorie 1 und höhere Kommunikation senden und empfangen. Wenn die Telematikeinheit 30 einen Modus der Durchführung nach einem 4.5 bzw. 5 G GSM nutzt, kann die Antenne 56 jedoch Mitteilungen von und an eine oder mehrere der folgenden Konnektivitätskategoriearten des Internets der Dinge Kategorie 0 (Cat-0), Kategorie M1 (Cat-M1), LTE MTC (LTE-M), Kategorie NB1 (NB-IoT/Cat-NB1), 3GPP mit erweiterter Abdeckung für IoT (EC-GSM-IoT/EC-EGPRS), Lower Power Wide Area (LPWA), eDRX und PSM übertragen. Es versteht sich, dass sich die Telematikeinheit 30 nicht auf einen einzelnen Kommunikationsstandard (oder Verbindungstyp für jeden Standard) beschränkt, und so konfiguriert werden kann, dass mehrere Mobilfunkstandards nach 3GPP- und/oder 3GPP2-Standards verwendet werden. Es versteht sich des Weiteren, dass das Kommunikationssystem 10 bis zu acht Antennen oder mehr beinhalten kann.
Die Telematikeinheit 30 kann verwendet werden, um eine vielfältige Palette von Fahrzeugdiensten bereitzustellen, die drahtlose Kommunikation zu und/oder vom Fahrzeug beinhalten. Derartige Dienste beinhalten: Wegbeschreibungen und andere navigationsbezogene Dienste, die in Verbindung mit dem GPS-basierten Fahrzeugnavigationsmodul 40 bereitgestellt sind; Benachrichtigung über die Airbagauslösung und andere mit Notruf oder Pannendienst verbundene Dienste, die in Verbindung mit einem oder mehreren Aufprallsensorschnittstellenmodulen, wie einem Fahrzeugbeherrschbarkeitsmodul (nicht gezeigt), bereitgestellt sind; Diagnosemeldungen unter Verwendung von einem oder mehreren Diagnosemodulen; und mit Infotainment verbundene Dienste, wobei Musik, Internetseiten, Filme, Fernsehprogramme, Videospiele und/oder andere Informationen durch ein Infotainmentmodul (nicht gezeigt) heruntergeladen und für die gegenwärtige oder spätere Wiedergabe gespeichert werden. Die vorstehend aufgelisteten Dienste sind keineswegs eine vollständige Liste aller Fähigkeiten der Telematikeinheit 30, sondern sie sind einfach eine Aufzählung von einigen der Dienste, welche die Telematikeinheit anbieten kann. Des Weiteren versteht es sich, dass mindestens einige der vorstehend genannten Module in der Form von Softwarebefehlen implementiert sein könnten, die innerhalb oder außerhalb der Telematikeinheit 30 gespeichert sind, sie könnten Hardwarekomponenten sein, die sich innerhalb oder außerhalb der Telematikeinheit 30 befinden, oder sie könnten integriert sein und/oder miteinander oder mit anderen Systemen geteilt zu sein, die sich im Fahrzeug befinden, um nur einige Möglichkeiten zu nennen. Für den Fall, dass die Module als VSM 42 implementiert sind, die sich außerhalb der Telematikeinheit 30 befinden, könnten sie den Fahrzeugbus 44 verwenden, um Daten und Befehle mit der Telematikeinheit auszutauschen.
Das GPS-Modul 40 empfängt Funksignale von einer Konstellation 60 von GPS-Satelliten. Von diesen Signalen kann das Modul 40 die Fahrzeugposition ermitteln, die verwendet wird, um Navigation und andere mit der Position verbundene Dienste an den Fahrzeugführer bereitzustellen. Navigationsinformationen können auf der Anzeige 38 (oder einer anderen Anzeige innerhalb des Fahrzeugs) dargestellt oder in verbaler Form präsentiert werden, wie es beispielsweise bei der Wegbeschreibungsnavigation der Fall ist. Die Navigationsdienste können unter Verwendung von einem zugehörigen Fahrzeugnavigationsmodul (das Teil des GPS-Moduls 40 sein kann) bereitgestellt werden, oder einige oder alle Navigationsdienste können über die Telematikeinheit 30 erfolgen, wobei die Positionsinformationen zum Zweck des Ausstattens des Fahrzeugs mit Navigationskarten, Kartenanmerkungen (Sehenswürdigkeiten, Restaurants usw.), Routenberechnungen und dergleichen zu einem entfernten Standort gesendet werden. Die Positionsinformationen können auch für andere Zwecke, wie z. B. das Fuhrparkmanagement an das Datenzentrum 20 oder ein anderes abgesetztes Computersystem, wie Computer 18, übermittelt werden. Außerdem können neue oder aktualisierte Kartendaten zum GPS-Modul 40 vom Datenzentrum 20 über die Telematikeinheit 30 heruntergeladen werden.
Abgesehen vom Audiosystem 36 und dem GPS-Modul 40 kann das Fahrzeug 12 andere Fahrzeugsystemmodule (VSM) 42 in der Form von elektronischen Hardwarekomponenten beinhalten, die sich im Fahrzeug befinden und typischerweise eine Eingabe von einem oder mehreren Sensoren erhalten und die erfassten Eingaben verwenden, um Diagnose, Überwachung, Steuerung, Berichterstattung und/oder andere Funktionen auszuführen. Jedes der VSMs 42 ist vorzugsweise durch den Kommunikationsbus 44 mit den anderen VSM sowie der Telematikeinheit 30 verbunden und kann programmiert werden, Fahrzeugsystem- und Subsystemdiagnosetests auszuführen. Als Beispiele kann ein VSM 42 ein Motorsteuergerät (ECM) sein, das verschiedene Aspekte des Betriebs des Motors, wie Kraftstoffzündung und Zündzeitpunkt, steuert. Gemäß einer Ausführungsform ist das Motorsteuergerät mit integrierten Diagnose-(OBD)-Funktionen ausgestattet, die unzählige Echtzeitdaten, wie z. B. die von verschiedenen Sensoren, einschließlich Fahrzeugemissionssensoren, erhaltenen Daten bereitstellen und eine standardisierte Reihe von Diagnosefehlercodes (DTCs) liefern, die einem Techniker ermöglichen, Fehlfunktionen innerhalb des Fahrzeugs schnell zu identifizieren und zu beheben. Fachleute auf dem Fachgebiet werden erkennen, dass es sich bei den vorgenannten VSMs nur um Beispiele von einigen der Module handelt, die im Fahrzeug 12 verwendet werden können, zahlreiche andere Module jedoch ebenfalls möglich sind.
Die Fahrzeugelektronik 28 beinhaltet auch eine Anzahl von Fahrzeugbenutzeroberflächen, die Fahrzeuginsassen mit einem Mittel zum Bereitstellen und/oder das Erhalten von Informationen ausstattet, einschließlich Mikrofon 32, Taste(n) 34, Audiosystem 36, und optischer Anzeige 38. Wie hierin verwendet, beinhaltet der Begriff „Fahrzeugbenutzeroberfläche“ weitgehend jede geeignete Form von elektronischer Vorrichtung, die sowohl die im Fahrzeug befindlichen Hardware- als auch Softwarekomponenten beinhaltet und einem Fahrzeugbenutzer ermöglicht, mit einer oder durch eine Komponente des Fahrzeugs zu kommunizieren. Das Mikrofon 32 stellt eine Audioeingabe an die Telematikeinheit bereit, um dem Fahrer oder anderen Insassen zu ermöglichen, Sprachsteuerungen bereitzustellen und Freisprechen über das Drahtlosträgersystem 14 auszuführen. Für diesen Zweck kann es mit einer integrierten automatischen Sprachverarbeitungseinheit verbunden sein, welche die unter Fachleuten auf dem Gebiet bekannte Mensch-Maschinen-Schnittstellen-(HMI)-Technologie verwendet. Die Taste(n) 34 ermöglichen eine manuelle Benutzereingabe in die Telematikeinheit 30, um drahtlose Telefonanrufe zu initiieren und andere Daten, Antworten oder eine Steuereingabe bereitzustellen. Separate Tasten können zum Initiieren von Notrufen gegenüber regulären Dienstunterstützungsanrufen beim Datenzentrum 20 verwendet werden. Das Audiosystem 36 stellt eine Audioausgabe an einen Fahrzeuginsassen bereit und kann ein zugehöriges selbstständiges System oder Teil des primären Fahrzeugaudiosystems sein. Gemäß der bestimmten Ausführungsform, die hierin gezeigt ist, ist das Audiosystem 36 operativ sowohl mit dem Fahrzeugbus 44 als auch mit dem Entertainmentbus 46 gekoppelt und kann AM-, FM- und Satellitenradio, CD-, DVD- und andere Multimediafunktionalität bereitstellen. Diese Funktionalität kann in Verbindung mit dem vorstehend beschriebenen Infotainmentmodul oder davon unabhängig bereitgestellt werden. Die optische Anzeige 38 ist vorzugsweise eine Grafikanzeige, wie z. B. ein Berührungsbildschirm am Armaturenbrett oder eine Warnanzeige, die von der Frontscheibe reflektiert wird, und verwendet werden kann, um eine Vielzahl von Eingabe- und Ausgabefunktionen bereitzustellen (d. h. zur GUI-Implementierung in der Lage). Verschiedene andere Fahrzeugbenutzeroberflächen können ebenfalls verwendet werden, denn die Schnittstellen von 1 dienen lediglich als Beispiel für eine bestimmte Implementierung.
Das Drahtlosträgersystem 14 ist vorzugsweise ein Smartphonesystem, das eine Vielzahl von Mobilfunkmasten 70 (nur einer gezeigt), eine oder mehrere mobile Vermittlungszentrale Einrichtung (MSC) 72 sowie irgendwelche anderen Netzwerkkomponenten umfasst, die erforderlich sind, um das Drahtlosträgersystem 14 mit dem Festnetz 16 zu verbinden. Jeder Mobilfunkturm 70 beinhaltet Sende- und Empfangsantennen und eine Basisstation, wobei die Basisstationen von unterschiedlichen Mobilfunktürmen mit der MSC 72 entweder direkt oder über zwischengeschaltete Geräte, wie z. B. eine Basisstationssteuereinheit, verbunden sind. Das Drahtlosträgersystem 14 kann jede geeignete Kommunikationstechnik implementieren, darunter beispielsweise analoge Technologien, wie AMPS oder die neueren Digitaltechnologien, wie CDMA (z. B. CDMA2000 oder 1xEV-DO) oder GSM/GPRS/UMTS/LTE (z. B. 3G, 4G LTE, 4.5G und/oder 5G). Der Fachmann wird erkennen, dass verschiedene Zellenturm 70/Basisstations/MSC-Anordnungen möglich sind und mit dem drahtlosen System 14 verwendet werden könnten. Zum Beispiel könnten sich Basisstation und Zellenturm 70 an derselben Stelle oder entfernt voneinander befinden (wie in 2 exemplarisch dargestellt), jede Basisstation könnte für einen einzelnen Zellenturm zuständig sein oder eine einzelne Basisstation könnte verschiedene Zellentürme 70 bedienen und verschiedene Basisstationen könnten mit einer einzigen MSC gekoppelt werden, um nur einige der möglichen Anordnungen zu nennen.
Abgesehen vom Verwenden des Drahtlosträgersystems 14 kann ein unterschiedliches Drahtlosträgersystem in der Form von Satellitenkommunikation verwendet werden, um unidirektionale oder bidirektionale Kommunikation mit dem Fahrzeug bereitzustellen. Dies kann unter Verwendung von einem oder mehreren Fernmeldesatelliten 62 und einer aufwärtsgerichteten Sendestation 64 erfolgen. Bei der unidirektionalen Kommunikation kann es sich beispielsweise um Satellitenradiodienste handeln, worin programmierte Inhaltsdaten (Nachrichten, Musik usw.) von der Sendestation 64 erhalten werden, für das Hochladen gepackt und anschließend zum Satelliten 62 gesendet werden, der die Programmierung an die Teilnehmer sendet. Bidirektionale Kommunikation kann beispielsweise Satellitentelefoniedienste unter Verwendung der Satelliten 62 sein, um Telefonkommunikationen zwischen dem Fahrzeug 12 und der Station 64 weiterzugeben. Bei Verwendung kann dieses Satellitenfernsprechen entweder zusätzlich zum oder anstatt des Drahtlosträgersystems 14 verwendet werden.
Das Festnetz 16 kann ein konventionelles landgebundenes Telekommunikationsnetzwerk sein, das mit einem oder mehreren Festnetztelefonen verbunden ist und das Drahtlosträgersystem 14 mit dem Datenzentrum 20 verbindet. So kann beispielsweise das Festnetz 16 ein Fernsprechnetz (PSTN), wie jenes sein, das verwendet wird, um festverdrahtetes Fernsprechen, paketvermittelte Datenkommunikationen und die Internetinfrastruktur bereitzustellen. Ein oder mehrere Segmente des Festnetzes 16 könnten durch Verwenden eines normalen drahtgebundenen Netzwerks, eines Lichtleiter- oder eines anderen optischen Netzwerks, eines Kabelnetzes, von Stromleitungen, anderen drahtlosen Netzwerken, wie drahtlose lokale Netzwerke (WLANs) oder Netzwerke, die drahtlosen Breitbandzugang (BWA) bereitstellen oder jeder Kombination davon implementiert sein. Des Weiteren muss das Datenzentrum 20 nicht über das Festnetz 16 verbunden sein, sondern könnte Funktelefonieausrüstung beinhalten, sodass direkt mit einem drahtlosen Netzwerk, wie dem Drahtlosträgersystem 14, kommuniziert werden kann.
Der Computer 18 kann einer von einer Anzahl von Computern sein, die über ein privates oder öffentliches Netzwerk, wie das Internet, zugänglich sind. Jeder dieser Computer 18 kann für einen oder mehrere Zwecke, wie einen Webserver verwendet werden, der vom Fahrzeug über die Telematikeinheit 30 und das Drahtlosträgersystem 14 zugänglich ist. Andere derartige zugängliche Computer 18 können beispielsweise sein: ein Kundendienstzentrumcomputer, wo Diagnoseinformationen und andere Fahrzeugdaten vom Fahrzeug über die Telematikeinheit 30 hochgeladen werden können; ein Clientcomputer, der vom Fahrzeugbesitzer oder einem anderen Teilnehmer für solche Zwecke, wie das Zugreifen auf oder das Erhalten von Fahrzeugdaten oder zum Einstellen oder Konfigurieren von Teilnehmerpräferenzen oder Steuern von Fahrzeugfunktionen, verwendet wird; oder ein Drittparteispeicherort, zu dem oder von dem Fahrzeugdaten oder andere Informationen entweder durch Kommunizieren mit dem Fahrzeug 12 oder dem Datenzentrum 20 oder beiden bereitgestellt werden. Ein Computer 18 kann auch für das Bereitstellen von Internetkonnektivität, wie DNS-Dienste oder als ein Netzwerkadressenserver, verwendet werden, der DHCP oder ein anderes geeignetes Protokoll verwendet, um dem Fahrzeug 12 eine IP-Adresse zuzuweisen.
Das Datenzentrum 20 ist konzipiert, die Fahrzeugelektronik 28 mit einer Anzahl von unterschiedlichen System-Back-End-Funktionen bereitzustellen, und beinhaltet nach der hierin gezeigten exemplarischen Ausführungsform im Allgemeinen einen oder mehrere Schalter 80, Server 82, Datenbanken 84, Live-Berater 86 sowie ein automatisiertes Sprachausgabesystem (VRS) 88, die alle auf dem Fachgebiet bekannt sind. Diese verschiedenen Komponenten des Datenzentrums sind vorzugsweise miteinander über ein verdrahtetes oder drahtloses lokales Netzwerk 90 verbunden. Der Schalter 80, der ein Nebenstellenanlagen(PBX)-Schalter sein kann, leitet eingehende Signale weiter, sodass Sprachübertragungen gewöhnlich entweder zum Live-Berater 86 über das reguläre Telefon oder automatisiert zum Sprachdialogsystem 88 unter Verwendung von VoIP gesendet werden. Der Server 82 kann eine Datensteuerung 81 beinhalten, die im Wesentlichen den gesamten Betrieb und die Funktion des Servers 82 steuert. Die Steuerung 81 kann Dateninformationen (z. B. Datenübertragungen) aus einer oder mehreren der Datenbanken 84 und der mobilen Computervorrichtung 57 steuern, senden und/oder empfangen. Die Steuerung 81 kann ausführbare Befehle, die in einem nicht-transitorischen maschinenlesbaren Speichermedium gespeichert sind, lesen, und kann einen oder mehrere aus einem Prozessor, einem Mikroprozessor, einer zentralen Verarbeitungseinheit (CPU), einem Grafikprozessor, anwendungsspezifischen integrierten Schaltungen (ASICs), feldprogrammierbaren Gate-Arrays (FPGAs), Zustandsmaschinen und eine Kombination von Hardware-, Software- und Firmware-Komponenten beinhalten. Das Live-Berater-Telefon kann auch VoIP verwenden, wie durch die gestrichelte Linie in 1 angezeigt. VoIP und andere Datenkommunikation durch den Schalter 80 werden über ein Modem (nicht gezeigt) implementiert, das zwischen dem Schalter 80 und Netzwerk 90 verbunden ist.
Datenübertragungen werden über das Modem an den Server 82 und/oder die Datenbank 84 weitergegeben. Die Datenbank 84 kann Kontoinformationen speichern, wie beispielsweise, jedoch nicht beschränkt auf, Fahrzeugdynamikinformationen und andere entsprechende Teilnehmerinformationen. Datenübertragungen können zudem durch drahtlose Systeme, wie z. B. 802.11x, GPRS und dergleichen, erfolgen. Obwohl die veranschaulichte Ausführungsform beschrieben wurde, als ob sie in Verbindung mit einem bemannten Datenzentrum 20 verwendet werden würde, das den Live-Berater 86 einsetzt, ist es offensichtlich, dass das Datenzentrum stattdessen VRS 88 als einen automatisierten Berater verwenden kann, oder eine Kombination von VRS 88 und dem Live-Berater 86 verwendet werden kann.
2 zeigt eine Betriebsumgebung 200, die mehrere Mobilfunkkonnektivitätszonen veranschaulicht, in denen jede Zonenart eine gewisse Bandbreite ist. Die Umgebung 200 hat mehrere Mobilfunkbereiche oder Zellen oder Bereiche des Normalbetriebs 210, 220, 230 (Mobilfunkvorgänge in der Regel mit mehr als einem Mbit/s oder diejenigen, die in den LTE UE-Kategorien 1 und darüber zu finden sind). Ein Beispiel für diese Mobilfunkbereiche ist eines, bei dem die Telematikeinheit 30 Mobilfunkkommunikationen gemäß der Konnektivitätsart „eine Größe passt für alle“ durchführen kann, die 3GPP 2G zugeordnet ist. 3G- und 4G-Standards oder eine oder mehrere Konnektivitätsarten sind 4.5 G und 5G GSM zugeordnet. Die Telematikeinheit 30 kann darüber hinaus in einem Konnektivitätsmodus (Art) arbeiten, der ein vorgegebenes oder vorgeschriebenes Energiebudget ermöglicht.
2 zeigt auch Zonen 211, 221 und 231 von extrem niedriger Service-Konnektivität. Jede Zone 211, 221 und 231 mit niedriger Service-Konnektivität erstreckt sich außerhalb der Normalbetriebszonen, 210, 220 und 230 und anderen Zonen mit niedriger Service-Konnektivität, und kann die anderen Zonen mit niedriger Service-Konnektivität bis zu einem gewissen Grad überschneiden. Ein Beispiel für diese Mobilfunkbereiche mit niedriger Konnektivität sind Zonen, in denen die Telematikeinheit 30 im Allgemeinen darauf begrenzt ist, Mobilfunkvorgänge gemäß einer Konnektivitätsart des Internets der Dinge durchzuführen (z. B. NB LTE-M/LTE-M/EG-GSM/LPWA/eDRX/PSM), die 4.5G und 5G GSM zugeordnet sind. Im Wesentlichen haben diese Zonen nicht die Mobilfunksignalqualität, um ausreichend Übertragungen einer normalen Konnektivitätsart durchzuführen.
Die Konnektivitätsarten des Internets der Dinge benötigen allgemein weniger Energie im Standby-/Ruhezustand (Senkung des Energieverbrauchs) und haben eine breitere, robustere Abdeckung mit einem Verbindungsbudget in der Regel etwa 15–20 dB besser als die von anderen Mobilfunkkommunikationen in Übereinstimmung mit 2 G/3G oder 4G LTE. Die Konnektivitätsart des Internets der Dinge (IoT) ist auch weiter verbreitet als andere Konnektivitätsarten und kann bestimmte physische Barrieren wie beispielsweise, aber nicht beschränkt auf Parkhaus 250, durchdringen. In vielen Fällen kann die Konnektivität des Internets der Dinge zum Verbinden intelligenter Maschinen (z. B. Verkaufsautomaten, Kopiergeräte, HVAC-Einheiten usw.) innerhalb physisch gekapselter Standorte 250 mit einem Drahtlosträgersystem 14 umgesetzt werden. Erfahrene Techniker erkennen, dass normale Konnektivitätsarten solche mit Datenraten über denjenigen der Konnektivität des Internets der Dinge sind (z. B. normale Konnektivitätsarten sind in der Regel mehr als ein Mbit/s oder diejenigen, die in LTE UE Kategorien 1 und darüber zu finden sind).
Zum Beispiel während einer Reise am Standort 261, zwischen Betriebszonen (z. B. zwischen Zonen 210 und 220 unterwegs 260), kann eine erste Art von Konnektivitätsartereignis (Auslöser) auftreten, wobei Datenübertragungen der normalen (d. h. ersten) Konnektivitätsart das Drahtlosträgersystem 14 (d. h. aufgrund von extrem schlechtem WLAN-Signal) nicht erreichen. Als solche kann die Steuerung 52 konfiguriert werden, um dieses Konnektivitätsartereignis zu erkennen, und die Telematikeinheit 30 wiederum in einen Modus schalten, der die Konnektivitätsart des Internets der Dinge zur Kommunikation mit dem Drahtlosträgersystem 14 implementiert. In bestimmten Fällen im umgeschalteten Modus mit der Konnektivitätsart des Internets der Dinge kann es vorkommen, dass sich das Fahrzeug 12 über die Grenzen der gesamten Drahtloskonnektivität bewegt. In solchen Fällen kann die Steuerung 52 weiter konfiguriert werden, um die Telematikeinheit 30 wieder zurück in ihren Originalmoduszustand zu schalten, der die normale Konnektivitätsart beinhaltet, im Bemühen, die Kommunikation mit dem Drahtlosträgersystem 14 wieder herzustellen.
Ein zweites ähnliches Konnektivitätsartereignis kann auftreten, während Fahrzeug 12 am Standort 262 ist. Aufgrund der Kein-Service-Konnektivität an diesem Standort 262 (z. B. außerhalb aller Konnektivitätszonen unterwegs 260) erreicht keine der Datenübertragungen das Drahtlosträgersystem 14. Als solche kann die Steuerung 52 konfiguriert werden, um dieses Konnektivitätsartereignis zu erkennen, und die Telematikeinheit 30 wiederum in einen Modus schalten, der die Konnektivitätsart des Internets der Dinge im Bemühen, eine bessere Chance zum Aufbauen von Kommunikation mit dem Drahtlosträgersystem 14 implementiert.
Wenn die Telematikeinheit 30 im umgeschalteten Modus ist, die die Konnektivitätsart des Internets der Dinge enthält, kann die Steuerung 52 konfiguriert werden, um die Servicefestigkeit der Konnektivität um das Fahrzeug 12 (d. h. eine Art Wiederholungsverfahren) in regelmäßigen Zeitabständen zu überprüfen. Infolgedessen wann immer die Steuerung 52 erkennt, dass das Fahrzeug 12 an einem Standort mit verbessertem Drahtlosträgersystemdienst ist (z. B. beim Zurückkehren innerhalb der Grenzen einer der Normalbetriebszonen, 210, 220, 230) oder sonst die Fähigkeit zum Herstellen einer Verbindung mit dem Drahtlosträgersystem 14 hat, kann die Steuerung 52 die Telematikeinheit 30 wieder umschalten, um den ursprünglichen Moduszustand wiederherzustellen und eine normale Konnektivitätsart zu implementieren.
Eine dritte Art von Konnektivitätsartereignis kann außerdem durch einen gescheiterten Versuch auftreten, eine Fahrzeugaufprallbenachrichtigung zu senden und/oder eine Notfall(EMER)-Kommunikation aufzubauen (z. B. wird dies versucht, wenn man sich in einem Bereich mit schlechtem/ohne Drahtlosträgersystemdienst befindet). Es sollte auch gewürdigt werden, dass die Fahrzeugaufprallbenachrichtigung möglicherweise eine erweiterte automatische Kollisionsbenachrichtigung (AACN) sein kann, die Versandinformationen (Fahrzeugaufprallschweregrad und Fahrzeugunfallort) beinhaltet, die an Datenzentrum 20 geschickt werden, damit Live-Berater 86 anschließend in der Nähe befindliches Notfall-/medizinisches Personal kontaktieren kann. Es versteht sich des Weiteren, dass eine Kommunikation im Notfall auf der Bedienung von einer oder mehreren Drucktasten 34 aufgebaut werden kann, um sofort direkt eine Verbindung der Telematikeinheit 30 zu dem Live-Berater 86 herzustellen, und den Berater 86 zu veranlassen, anschließend in der Nähe befindliches Notfall-/medizinisches Personal zu kontaktieren. Nach Abschluss der Fahrzeugaufprallbenachrichtigung und/oder Notfallkommunikation kann die Steuerung 52 konfiguriert werden, um die Telematikeinheit 30 wieder in ihren Originalmoduszustand umzuschalten, die eine normale Konnektivitätsart beinhaltet.
In Übereinstimmung mit einem anderen Aspekt des Telematikeinheitsverfahrens, wenn das Fahrzeug 12 AUSGESCHALTET wurde (z. B. während es auf einem Parkplatz 250 geparkt ist), um eine vierte Art von Konnektivitätsartereignis zu schaffen, die als ein Energiereduktionsereignis betrachtet werden kann, kann die Steuerung 52 das Abschalten des Batteriestroms erkennen und anschließend verursachen, dass die Telematikeinheit 30 gemäß einem Niedrigenergiemodus arbeitet, der es der Telematikeinheit 30 ermöglicht, eine Konnektivitätsart des Internets der Dinge nutzen zu können. Der Betrieb in diesem Niedrigenergiemodus ermöglicht der Telematikeinheit 30, weniger Energie aus der Energiequelle (z. B. Fahrzeugbatterie) des Fahrzeugs 12 zu entnehmen, um das Energiebudget des Fahrzeugs 12 zu erhöhen und somit die Fahrzeugfunktionalitätszeitdauer zu verlängern, während es AUSGESCHALTET ist, was möglicherweise bis zu Hunderten von Tagen länger als bei anderen Konnektivitätsarten sein kann. Eine fünfte Art von Konnektivitätsartereignis, die auch als ein Energiereduktionsereignis betrachtet werden kann, würde auftreten, wenn die Fahrzeugbatterie ausfällt (z. B. die Batterie verliert alle Ladung). Die Steuerung 52 erkennt möglicherweise einen vorbestimmten Ladezustand als einen Ausfall der Batterieenergie und veranlasst die Telematikeinheit 30, gemäß einem Niedrigenergiemodus zu arbeiten, was der Telematikeinheit 30 ermöglicht, eine Konnektivitätsart des Internets der Dinge nutzen zu können. Erfahrene Techniker würden erkennen, dass die Telematikeinheit 30 eine unabhängige Backup-Batterie erfordern kann, um während der gesamten Zeitdauer dieser Konnektivitätsartereignisse funktionsfähig zu bleiben.
Während das Fahrzeug 12 bei einem vorbestimmten Ladezustand betrieben wird, der darin besteht, dass die Batterie ein niedriges Energieniveau aufweist (z. B. unter 25 %), kann eine sechste Art von Konnektivitätsartereignis aufgebaut werden, die auch als ein Energiereduktionsereignis betrachtet werden kann, und die Steuerung 52 kann diesen vorbestimmten Ladezustand erkennen und die Telematikeinheit 30 veranlassen, gemäß dem Niedrigenergiemodus zu arbeiten. Dieses Konnektivitätsartereignis kann in diesen Fällen vorteilhaft sein bei einer Fahrzeugaufprallbenachrichtigung und/oder bei einer versuchten Notfallkommunikation, sodass die Fahrzeugbatterie nicht zu einem bestimmten Zeitpunkt während der Kommunikation ausfällt. Erfahrene Techniker würden sehen, dass der vorbestimmte Ladezustand möglicherweise ein anderer Ladezustand ist, der hier nicht abgehandelt wird.
Wenn die Telematikeinheit 30 sich im umgeschalteten Niedrigsignalmodus befindet, kann die Steuerung 52 in regelmäßigen Abständen/kontinuierlich die Fahrzeugbatterieladungsstärke (d. h. eine Art Wiederholungsverfahren) überprüfen. Infolgedessen, wenn die Steuerung 52 erkennt, dass sich die Fahrzeugbatteriestärke auf ein Niveau verbessert hat, auf dem die Batterie kontinuierlich eine normale Konnektivität mit dem Drahtlosträgersystem 14 aufrechterhalten kann (z. B. das Fahrzeug in einem EIN-Zustand ist, sich der Fahrzeugbatterieladezustand verbessert, die Fahrzeugbatterie wiederhergestellt wurde, eine neue Batterie installiert wurde usw.), kann die Steuerung 52 die Telematikeinheit 30 wieder umschalten, um den ursprünglichen Moduszustand wiederherzustellen und eine normale Konnektivitätsart zu implementieren.
Es versteht sich, dass die Steuerung 52 auch eine oder mehrere ausführbare Anweisungen beinhalten kann, die eine Zeitgeberfunktion bereitstellen und die konfiguriert sind, die Telematikeinheit 30 zu veranlassen, gemäß diesem Niedrigsignalmodus zu einem bestimmten Zeitpunkt zu arbeiten, der durch den Fahrzeugführer oder das Datenzentrum 20 befohlen werden kann. Beispielsweise basierend auf Vorgängen, die für das Fahrzeug 12 normal sind, kann die Steuerung 52 eingestellt werden, um Modi zu einer bestimmten Zeit von 01:00 zu schalten (und könnten weiter eingestellt werden, um wieder zurück zu einer normalen Konnektivitätsart um 05:00 zu schalten). Die Telematikeinheit 30 kann auch in den Niedrigsignalmodus zu einem bestimmten Zeitpunkt schalten, der als Ablauf eines vorbestimmten Zeitgeberwerts angesehen wird (was weiter von der Erkennung eines separaten Konnektivitätsartereignisses abhängig sein kann). Beispielsweise kann die Steuerung 52 angewiesen werden, gemäß einem Niedrigenergiemodus zu arbeiten, nachdem das Fahrzeug 12 für die bestimmte Zeit von 30 Minuten AUSGESCHALTET wurde.
Indem wir uns nun 3 zuwenden, ist ein Beispiel für Verfahren 300 des Telematikeinheits-Konnektivitätsmanagemants dargestellt. Einer oder mehrere Schritte des Verfahrens 300 können durch die Umsetzung der Steuerung 52 abgeschlossen werden, die eine oder mehrere ausführbare Anweisungen beinhalten kann, die in den Speicher 54 integriert sind, und durch die Telematikeinheit 30 und Antenne 56 ausgeführt werden. Einer oder mehrere Aspekte des Verfahrens 300 können außerdem vom Server 82 des Datenzentrums 20 implementiert werden, was eine oder mehrere ausführbare Anweisungen beinhalten kann, die in die Datenbank 81 integriert, und durch die Telematikeinheit 30 und Antenne 56 ausgeführt werden können (das über einen oder mehrere Satelliten 62 durchgeführt werden kann).
Das Verfahren wird von der Telematikeinheit 30 unterstützt, die für das Konnektivitätsmanagement mit einem oder mehreren Konnektivitätsmodi konfiguriert ist. Diese Konfiguration kann durch den Fahrzeughersteller in oder nahe der Zeit der Montage der Telematikeinheit oder als Aftermarket-Element erfolgen (z. B. über Fahrzeug-Download mittels des oben dargestellten Kommunikationssystems 10 oder während einer Fahrzeugwartung, um nur einige Beispiele zu nennen). In mindestens einer Implementierung werden eine oder mehrere Anweisungen für die Telematikeinheit bereitgestellt und auf einem nicht transitorischen computerlesbaren Medium (z. B. auf Speicher 54) gespeichert.
Schritt 310 beinhaltet das Vorkonfigurieren der Telematikeinheit 30 durch Einstellen der Einheit auf einen ersten Konnektivitätsmodus. Wie oben abgehandelt, kann dieser erste Konnektivitätsmodus beinhalten, die Telematikeinheit 30 in die Lage zur Übertragung von Daten bei einem oder mehreren normalen Konnektivitätsarten versetzen.
Schritt 320 enthält eine Telematikeinheit 30, die eine Datenübertragungskonnektivität mit dem Drahtlosträgersystem 14 festlegt, während sie sich in dem ersten Konnektivitätsmodus befindet. Solche Übertragungen können durch eine oder mehrere Antennen 56 implementiert werden. Dieser Schritt kann weiterhin beinhalten, dass die Steuerung 52 konfiguriert wird, um diese Übertragungen zu analysieren, um ihre Datenrate und Abweichungen davon, sowie die Dauer der Signalstärke zu bestimmen, die weniger als der Schwellenwert und größer als der Schwellenwert ist. Und andere Faktoren können auch berücksichtigt werden.
Schritt 330 beinhaltet, dass ein Fahrzeug 12 über die Grenzen der Bereiche des normalen Mobilfunkbetriebs 210, 220, 230 fährt, während es noch durch eine oder mehrere Niedrigkonnektivitätszonen 211, 221 und 231 abgedeckt ist. Bei Schritt 330 kann das Fahrzeug 12 in eine Situation im Einklang mit der ersten, zweiten und/oder dritten Konnektivitätsereignisart geraten. Zum Beispiel kann vom Bediener verlangt werden, zu versuchen, eine Fahrzeugaufprallbenachrichtigung und/oder Notfallkommunikation zu senden. Da sich jedoch das Fahrzeug 12 außerhalb der normalen Mobilfunkvorgänge befindet, schlägt die versuchte Fahrzeugaufprallbenachrichtigung und/oder Notfallkommunikation fehl, weil die Niedrigkonnektivitätszone, in der das Fahrzeug 12 bleibt, nicht die minimale Datenrate befördern kann, die erforderlich für diese Kommunikation ist. Als weiteres Beispiel kann der Bediener versuchen, eine Datenübertragung über eine normale Konnektivitätsart zu senden. Da sich jedoch das Fahrzeug 12 außerhalb der normalen Mobilfunkvorgänge befindet, (z. B. befindet sich in einer oder mehreren Niedrigkonnektivitätszonen 211, 221 und 231) oder in einem Bereich ohne Mobilfunkvorgänge, scheitern die versuchten Datenübertragungen.
Bei Schritt 340 muss die Telematikeinheit 30 bestimmen, dass bei Fahrzeug 12 ein Konnektivitätsartereignis aufgetreten ist. Um eine solche Bestimmung zu machen, kann die Telematikeinheit 30 versuchen, die Kommunikation mit dem Drahtlosträgersystem 14 durch einen erneuten Versuch wieder herzustellen. Ein Wiederholungsverfahren kann beinhalten, dass die Telematikeinheit 30 eine oder mehrere zusätzliche Fahrzeugaufprallbenachrichtigungen und/oder Notfallkommunikationen erstellt, um sicherzustellen, dass bei Fahrzeug 12 tatsächlich gerade ein Konnektivitätsartereignis auftritt, oder wenn der Aufruf aus irgendwelchen anderen technischen Gründen scheiterte. Das Wiederholungsverfahren kann auch beinhalten, dass die Telematikeinheit 30 versucht, mit dem Drahtlosträgersystem 12 durch verschiedene Mittel zu kommunizieren, wie oben beschrieben. Die Telematikeinheit 30 kann auch z. B. eine Drahtlos- oder Mobilfunksignalstärke bestimmen und/oder feststellen, dass die Signalstärke zeitweise weniger als oder größer als ein vordefinierter Schwellenwert variiert. Es kann weiterhin beinhalten, die Datenrate dieser Schwankungen sowie die Zeitdauern der Signalstärke zu bestimmen, die weniger als der Schwellenwert und größer als der Schwellenwert ist. Andere Faktoren können ebenfalls berücksichtigt werden.
Wenn aus einem oder einem anderen Grund das Wiederholungsverfahren erfolgreich bei der Wiederherstellung der Kommunikation mit dem Drahtlosträgersystem 14 ist, dann geht das Verfahren 300 zu Schritt 360 und schließt das Verfahren 300 durch Abschluss der Fahrzeugaufprallbenachrichtigung und/oder Notfallkommunikation ab. Jedoch wenn die Telematikeinheit 30 angemessen bestimmt, dass bei dem Fahrzeug 12 ein Konnektivitätsartereignis aufgetreten ist, dann fährt das Verfahren 300 mit Schritt 350 fort. Bei Schritt 350 schaltet die Telematikeinheit 30 von dem aufgebauten ersten Konnektivitätsmodus (d. h. mit einer normalen Konnektivitätart-Datenrate) auf einen zweiten Konnektivitätsmodus auf eine Konnektivitätsart des Internets der Dinge um. Wie bereits erwähnt, kann eine solche Konnektivitätsart gemäß einem 4.5 G- und/oder 5 G 3GPP-Standard festgelegt werden. Während der festgelegten Konnektivitätsart des Internets der Dinge baut die Telematikeinheit 30 Datenübertragungskonnektivität mit dem Drahtlosträgersystem 14 auf. Das Aufbauen von Übertragungen in dieser Konnektivitätsart sollte eine höhere Chance auf Erfolg haben, wie oben beschrieben. Nachdem Übertragungen eingerichtet wurden, dann kann die Telematikeinheit 30 die zuvor fehlgeschlagene Fahrzeugaufprallbenachrichtigung und/oder Notfallkommunikation erneut senden. Es versteht sich, dass aufgrund der IoT-Konnektivitätsartspezifikationen die Telematikeinheit 30 den Anruf in einem Textformat senden kann, das die notwendigen Informationen des Anrufs aufweist.
Wie durch die optionale Linie 351 gezeigt, kann das Verfahren 300 die Konnektivitätsart des Internets der Dinge beispielsweise beenden, wenn das Fahrzeug 12 wieder in den Bereiche 210, 220, 230 mit normalem Mobilfunkbetrieb eintritt. Wenn das Fahrzeug 12 zurück in einen Bereich mit normalem Mobilfunkbetrieb eintritt, kann das Verfahren wieder zum Schritt 310 übergehen. Danach kann das Verfahren seine Schritte wiederholen.
Indem wir uns nun 4 zuwenden, ist ein Beispiel für das Verfahren 400 des Telematikeinheits-Konnektivitätsmanagemants dargestellt. Einer oder mehrere Schritte des Verfahrens 400 können durch die Umsetzung der Steuerung 52 abgeschlossen werden, die eine oder mehrere ausführbare Anweisungen (Softwarealgorithmen) beinhalten können, die in Speicher 54 integriert sind, und durch die Telematikeinheit 30 und Antenne 56 ausgeführt werden. Einer oder mehrere Aspekte des Verfahrens 400 können außerdem vom Server 82 des Datenzentrums 20 implementiert werden, was eine oder mehrere ausführbare Anweisungen (Softwarealgorithmen) beinhalten kann, die in die Datenbank 81 integriert, und durch die Telematikeinheit 30 und Antenne 56 ausgeführt werden können (das über einen oder mehrere Satelliten 62 durchgeführt werden kann).
Das Verfahren wird von der Telematikeinheit 30 unterstützt, die für das Konnektivitätsmanagement mit einem oder mehreren Konnektivitätsmodi konfiguriert ist. Ähnlich wie das oben abgehandelte Verfahren kann diese Konfiguration durch den Fahrzeughersteller in oder nahe der Zeit der Montage der Telematikeinheit 30 oder als Aftermarket-Element erfolgen (z. B. über Fahrzeug-Download mittels des oben dargestellten Kommunikationssystems 10 oder während einer Fahrzeugwartung, um nur einige Beispiele zu nennen). In mindestens einer Implementierung werden eine oder mehrere Anweisungen für die Telematikeinheit 30 bereitgestellt und auf einem nicht transitorischen computerlesbaren Medium (z. B. auf Speicher 54) gespeichert.
Schritt 410 beinhaltet das Vorkonfigurieren der Telematikeinheit 30 durch Einstellen der Einheit auf einen ersten Konnektivitätsmodus. Wie oben abgehandelt, kann dieser erste Konnektivitätsmodus beinhalten, die Telematikeinheit 30 in die Lage zur Übertragung von Daten bei einer oder mehreren normalen Konnektivitätsarten versetzen.
Schritt 420 beinhaltet, dass bei der Telematikeinheit 30 das Konnektivitätsartereignis im Einklang mit dem vierten, fünften bzw. sechsten Konnektivitätsartereignis auftritt. Beispielsweise wenn das Fahrzeug 12 AUSGESCHALTET wird. Es kann daher erforderlich sein, dass die Telematikeinheit 30 feststellt, dass die Umstände so sind, dass der Fahrzeugmotor AUSGESCHALTET ist und die Fahrzeugbatterie nicht geladen ist (z. B. ein Elektrofahrzeug ist AUSGESCHALTET und von einer Ladestation getrennt). Eines der VSMs 42, wie ECM, kann einen Hinweis auf den AUS-Zustand für die Telematikeinheit 30 bereitstellen. Ein weiteres Beispiel besteht darin, dass das Fahrzeug mit einer Batterie bei einem vorgegebenen Ladezustand in Betrieb ist (z. B. die Batterie mit einem niedrigen Energieniveau, ohne Ladung oder Ausfall).
Wenn die Telematikeinheit 30 jedoch angemessen bestimmt, dass bei dem Fahrzeug 12 ein Konnektivitätsartereignis aufgetreten ist, dann fährt das Verfahren 400 mit Schritt 430 fort. Bei Schritt 430 schaltet die Telematikeinheit 30 von dem aufgebauten ersten Konnektivitätsmodus (d. h. mit einer normalen Konnektivitätsart) auf die Konnektivitätsart des Internets der Dinge (d. h. den zweiten Konnektivitätsmodus) um. Beim Verfahren 400 kann dieser Konnektivitätsmodus als ein Energiesparmodus betrachtet werden, und das Verfahren 400 kann als ein Energiemanagementverfahren für eine Telematikeinheit betrachtet werden. Der Energiesparmodus kann der Telematikeinheit 30 den Betrieb ermöglichen, und ihre gewünschten Aufgaben (z. B. Fernstart, Ferntürentriegelung, Unterstützung von Antriebsstrangbetrieb usw.) für einen verlängerten Zeitraum (z. B. mehr als 100 Tage), oder für einen vorbestimmten Zeitraum auszuführen, und sorgt dafür, dass sich die Telematik 30 nicht vollständig entlädt oder übermäßig die Energie der Fahrzeugbatterie verbraucht, während das Fahrzeug AUSGESCHALTET ist. Wie durch die Linie 431 gezeigt, kann das Verfahren 400 den Energiesparmodus verlassen, z. B. wenn das Fahrzeug EINGESCHALTET werden kann (z. B. Zündung gestartet, ein elektrisches Fahrzeug möglicherweise an eine Energiequelle angeschlossen usw.). Wenn das Fahrzeug 12 EINGESCHALTET ist, erneuert sich die Ladung oder die Fahrzeugbatterie wird wieder funktionsfähig, wobei das Verfahren wieder zum Schritt 410 übergehen kann. Danach kann das Verfahren 400 seine Schritte ab dem Beginn von Schritt 410 wiederholen.
In bestimmten Fällen kann wie oben beschrieben die Telematikeinheit 30 und/oder Steuerung 52-konfiguriert werden, um das Zeitgeber-/Zeitschaltprogramm zu beinhalten, die es dem Bediener ermöglichen, eine bestimmte Uhrzeit für die Telematikeinheit 30 einzugeben, um von dem eingerichteten ersten Konnektivitätsmodus (d. h. bei einer normalen Konnektivitätsart) auf einen zweiten Konnektivitätsmodus auf die Konnektivitätsart des Internets der Dinge umzuschalten. Dieses Programm kann außerdem zuerst erforderlich sein, um zu bestimmen, dass der Motor vor der Umschaltung auf die Konnektivitätsart des Internets der Dinge AUSGESCHALTET ist. Zum Beispiel, wenn ein Bediener weiß, dass sein Zeitplan so ist, dass das Fahrzeug 12 zwischen den Stunden von 12 Uhr (Mitternacht) bis 05:00 in der Regel nicht in Betrieb ist, kann er das Zeitgeber-/Zeitschaltprogramm so einstellen, dass die Telematikeinheit 30 auf den Konnektivitätsartmodus des Internets der Dinge während dieser Stunden umschaltet. Die Telematikeinheit 30 kann weiter konfiguriert werden, um auf den Konnektivitätartmodus des Internets der Dinge umzuschalten, wenn das Fahrzeug für eine vorbestimmte Zeit (z. B. 30 Minuten) AUSGESCHALTET wurde. Wenn das Fahrzeug 12 EINGESCHALTET ist oder für weniger als die vorgegebene Zeit AUSGESCHALTET war, wird die Telematikeinheit 30 jedoch eine solche Modusumschaltung unterlassen (zumindest so lange, bis es für mehr als die vorgegebene Zeit AUSGESCHALTET war). Es versteht sich, dass die hier beschriebenen Verfahren in Implementierungen außer bei Fahrzeugen verwendet werden können.
Obgleich exemplarische Ausführungsformen vorstehend beschrieben sind, sollen diese Ausführungsformen in keiner Weise alle möglichen Formen beschreiben, die die Ansprüche in sich begreifen. Vielmehr dienen die in der Spezifikation verwendeten Worte der Beschreibung und nicht der Einschränkung und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Erfindungsgedanken und Umfang der Offenbarung abzuweichen. Wie zuvor beschrieben, können die Merkmale verschiedener Ausführungsformen kombiniert werden, um weitere exemplarische Aspekte der vorliegenden Offenbarung auszubilden, die nicht explizit beschrieben oder veranschaulicht werden. Während verschiedene Ausführungsformen beschrieben worden sein könnten, um Vorteile zu bieten oder anderen Ausführungsformen oder Implementierungen des Standes der Technik in Bezug auf eine oder mehrere gewünschte Merkmale vorgezogen zu werden, werden Fachleute auf dem Gebiet erkennen, dass eine oder mehrere Merkmale oder Charakteristiken beeinträchtigt werden können, um die gewünschten Gesamtsystemeigenschaften zu erreichen, die von der spezifischen Anwendung und Implementierung abhängen. Diese Eigenschaften können unter anderem Kosten, Festigkeit, Haltbarkeit, Lebenszykluskosten, Marktfähigkeit, Aussehen, Verpackung, Größe, Gebrauchstauglichkeit, Gewicht, Herstellbarkeit, Montagefreundlichkeit, usw. beinhalten. Daher liegen Ausführungsformen, die im Vergleich zu anderen Ausführungsformen oder Implementierungen des Standes der Technik als weniger wünschenswert in Bezug auf eine oder mehrere Merkmale beschrieben sind, nicht außerhalb des Umfangs der Offenbarung und können für bestimmte Anwendungen wünschenswert sein.
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 Nicht-Patentliteratur

IEEE 802.11-Protokollen [0015]

Claims

Verfahren zum Konnektivitätsmanagement einer Telematikeinheit, das Verfahren umfassend: (a) das Einstellen einer Telematikeinheit über eine Steuerung in einem ersten Konnektivitätsmodus; (b) das Aufbauen einer Kommunikation mit einem Drahtlosträgersystem über eine Antenne in dem ersten Konnektivitätsmodus; (c) das Bestimmen über die Steuerung, dass bei dem Fahrzeug ein Konnektivitätsartereignis aufgetreten ist; (d) das Schalten der Telematikeinheit über die Steuerung aus dem ersten Konnektivitätsmodus in einen zweiten Konnektivitätsmodus; und (e) das Aufbauen einer Kommunikation mit einem Drahtlosträgersystem über die Antenne in dem zweiten Konnektivitätsmodus.
Verfahren nach Anspruch 1, des Weiteren umfassend den Versuch, über die Steuerung die Drahtlosträgersystemkommunikation im ersten Konnektivitätsmodus wiederherzustellen.
Verfahren nach Anspruch 1, worin das Konnektivitätsartereignis darin besteht, dass das Fahrzeug AUSGESCHALTET wird.
Verfahren nach Anspruch 1, worin das Konnektivitätsartereignis darin besteht, dass das Fahrzeug mit einer Batterie mit einem vorgegebenen Ladezustand läuft.
Verfahren nach Anspruch 1, worin das Konnektivitätsartereignis von der Steuerung basierend auf einem bestimmten Zeitpunkt erstellt wird.
Verfahren nach Anspruch 1, worin das Konnektivitätsartereignis ein gescheiterter Versuch ist, eine Fahrzeugaufprallbenachrichtigung zu senden und/oder einen Notruf aufzubauen.
Verfahren nach Anspruch 1, worin das Konnektivitätsartereignis auftritt, wenn normale Konnektivitätsarten das Drahtlosträgersystem nicht erreichen oder sich das Fahrzeug an einem Standort ohne Service-Konnektivität befindet.
Verfahren nach Anspruch 1, worin der zweite Konnektivitätsmodus das Auftreten von Datenübertragungen in einer Konnektivitätsart des Internets der Dinge ermöglicht.
Verfahren zum Konnektivitätsmanagement einer Telematikeinheit in einem Fahrzeug, das Verfahren umfassend: (a) das Einstellen einer Telematikeinheit über eine Steuerung, dass sie Daten in einer normalen Konnektivitätssart überträgt; (b) das Aufbauen einer Kommunikation mit einem Drahtlosträgersystem über eine Antenne in der normalen Konnektivitätsart; (c) das Bestimmen über die Steuerung, dass bei der Telematikeinheit ein Versuch fehlgeschlagen ist, eine Fahrzeugaufprallbenachrichtigung zu senden und/oder eine Notfallkommunikation zu senden, und/oder die normale Konnektivitätsart das Drahtlosträgersystem nicht erreicht und/oder sich das Fahrzeug an einem Standort ohne Service-Konnektivität befindet; (d) das Umschalten der Telematikeinheit über die Steuerung von der normalen Konnektivitätsart auf eine Konnektivitätsart des Internets der Dinge; und (e) das Aufbauen von Kommunikation mit dem Drahtlosträgersystem über eine Antenne der Telematikeinheit in der Konnektivitätsart des Internets der Dinge.
Verfahren nach Anspruch 9, des Weiteren umfassend den Versuch, über die Steuerung die Drahtlosträgersystemkommunikation im ersten Konnektivitätsmodus wiederherzustellen.