DE102018119244A1

DE102018119244A1 - Fahrzeugkommunikation

Info

Publication number: DE102018119244A1
Application number: DE102018119244.4A
Authority: DE
Inventors: Aziz Makkiya; Tony ZAKARIA; Rajesh Balaji VIJAYAN; Allan MIRAMONTI; John Naum Vangelov; Ritesh Pandya
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2017-08-10
Filing date: 2018-08-07
Publication date: 2019-02-14
Also published as: US20190052522A1; US10547502B2; CN109388123A

Abstract

Ein Fahrzeugsystem beinhaltet eine Telematiksteuereinheit (telematics control unit - TCU), die an eine Vielzahl von Fahrzeugsteuerungen gekoppelt ist. Die TCU ist dazu konfiguriert, Drahtlosaktivitätsdaten in Bezug auf eine Prozedur zur Authentifizierung, Verbindung, Signalisierung, Trennung und Übergabe der TCU periodisch in einem Protokoll aufzuzeichnen, um einen oder mehrere Fahrzeugferndienste bereitzustellen. Die TCU ist ferner dazu konfiguriert, als Reaktion darauf, dass anhand der protokollierten Daten eine Mobilfunkstörung detektiert wird, mindestens einen Teil des Protokolls, der der Mobilfunkstörung entspricht, für einen Server, der zum Diagnostizieren des Betriebs der TCU konfiguriert ist, drahtlos außer Bord des Fahrzeugs zu übertragen.

Description

TECHNISCHES GEBIET
Die vorliegende Offenbarung betrifft Systeme und Verfahren zum Überwachen und Beseitigen von Störungen bei der Fahrzeugkommunikation.
ALLGEMEINER STAND DER TECHNIK
Die Bedeutung von stabiler Fahrzeugkommunikation hat mit der zunehmenden Fortschrittlichkeit von Fahrzeugen zugenommen. Systeme eines Fahrzeugs kommunizieren große Datenmengen untereinander, um den korrekten Betrieb des Fahrzeugs zu koordinieren und sicherzustellen. Darüber hinaus ermöglicht drahtlose Fahrzeugkommunikation angesichts des mobilen Wesens von Fahrzeugen wertvolle Merkmale, die anderweitig nicht verfügbar wären. Es besteht deshalb ein Bedarf, Störungen bei der Fahrzeugkommunikation effizient zu überwachen und zu beseitigen, um eine optimale Funktionsweise eines Fahrzeugs sicherzustellen.
KURZDARSTELLUNG
Die folgende Kurzdarstellung kann eine vereinfachte Übersicht einiger Ausführungsformen der Erfindung darstellen, um ein grundlegendes Verständnis bestimmter Aspekte der hier erörterten Erfindung bereitzustellen. Die Kurzdarstellung soll weder eine umfassende Übersicht der Erfindung bereitstellen noch soll sie entscheidende oder ausschlaggebende Elemente feststellen oder den Umfang der Erfindung abgrenzen. Der Zweck der Kurzdarstellung besteht einzig darin, einige Konzepte als Einführung in die nachstehend dargelegte detaillierte Beschreibung in vereinfachter Form darzustellen.
In einer beispielhaften Ausführungsform beinhaltet ein Fahrzeugsystem eine Telematiksteuereinheit (telematics control unit - TCU), die dazu konfiguriert ist, periodisch in einem Protokoll Drahtlosaktivitätsdaten in Bezug auf eine Prozedur zur Authentifizierung, Verbindung, Signalisierung, Trennung und Übergabe der TCU aufzuzeichnen, um einen oder mehrere Fahrzeugferndienste bereitzustellen. Die TCU ist ferner dazu konfiguriert, als Reaktion darauf, dass anhand der protokollierten Daten eine Mobilfunkstörung detektiert wird, mindestens einen Teil des Protokolls, der der Mobilfunkstörung entspricht, für einen Ferndiagnoseserver drahtlos außer Bord des Fahrzeugs zu übertragen.
In einer weiteren beispielhaften Ausführungsform beinhaltet ein Verfahren durch eine TCU eines Fahrzeugs periodisches Aufzeichnen von Drahtlosaktivitätsdaten in Bezug auf eine Prozedur zur Authentifizierung, Verbindung, Signalisierung, Trennung und Übergabe der TCU in einem Protokoll, um einen oder mehrere Fahrzeugferndienste bereitzustellen. Als Reaktion darauf, dass anhand des Protokolls eine Mobilfunkstörung detektiert wird, beinhaltet das Verfahren ferner durch die TCU drahtloses Übertragen von mindestens einem Teil des Protokolls, der der Mobilfunkstörung entspricht, für einen Ferndiagnoseserver außer Bord des Fahrzeugs.
In einer anderen beispielhaften Ausführungsform beinhaltet ein Diagnoseserver einen Prozessor, der geografisch von einem Fahrzeug entfernt ist, das eine TCU beinhaltet. Die TCU ist dazu konfiguriert, ein erstes Protokoll, das für Drahtlosaktivität der TCU spezifisch ist, und ein zweites Protokoll, das für Komponentenstörungen der TCU spezifisch ist, zu erzeugen. Der Prozessor ist dazu konfiguriert, eine Anforderung für das erste Protokoll zu übertragen, wobei als Reaktion auf die Anforderung das erste Protokoll und nicht das zweite Protokoll durch den Prozessor empfangen wird.
Figurenliste

1 ist eine schematische Darstellung, die ein System zum Überwachen und Beseitigen von Störungen bei der Fahrzeugkommunikation veranschaulicht.
2 ist ein Schwimmbahndiagramm, das einen Prozess zum Überwachen und Beseitigen von Störungen bei der Fahrzeugkommunikation veranschaulicht.

DETAILLIERTE BESCHREIBUNG
1 veranschaulicht ein beispielhaftes System 100 zum Überwachen und Beseitigen von Kommunikationsstörungen eines Fahrzeugs 102. Das Fahrzeug 102 kann eine Telematiksteuereinheit („TCU“) 104 zum drahtlosen Kommunizieren mit Fernsystemen 106, einem Nachrichtenbroker 108 und einem Diagnoseserver 110 über ein Netzwerk 112 beinhalten.
Die Fernsysteme 106 können mobile Vorrichtungen und Server beinhalten, mit denen die TCU 104 drahtlos kommunizieren kann, um Ferndienste für das Fahrzeug 102 bereitzustellen. Zum Beispiel kann ein Benutzer einen Befehl erteilen, um das Fahrzeug 102 von seiner mobilen Vorrichtung aus ferngesteuert zu verriegeln, zu entriegeln oder zu starten. Nach Erteilung des Befehls kann die mobile Vorrichtung den Befehl über das Netzwerk 112 an die TCU 104 übertragen, die dann das Fahrzeug 102 dazu veranlassen kann, den Befehl umzusetzen. Als ein weiteres Beispiel kann die TCU 104 eine Einheit für das globale Positionsbestimmungssystem (global positioning system - „GPS“) zum Nachverfolgen eines Standorts des Fahrzeugs 102 beinhalten. Wenn das Fahrzeug 102 in einen Unfall verwickelt worden ist, kann die TCU 104 automatisch den Standort des Fahrzeugs 102 über das Netzwerk 112 an Notfallpersonal übertragen. In einem anderen Beispiel kann die TCU 104 des Fahrzeugs 102 Standort-, Diagnose- und Fahrerverhaltensdaten an ein Fernsystem zum Flottenmanagement kommunizieren, das es dann einem Manager ermöglichen kann, das Fahrzeug 102 und den Fahrer auf Grundlage dessen zu verwalten.
Es können TCU-Störungen vorkommen, die verhindern, dass das Fahrzeug 102 Daten für Ferndienste empfängt und überträgt, wie etwa die vorstehend beschriebenen. Zum Beispiel können die Komponenten (z. B. Hardware oder Software) der TCU 104 Störungen aufweisen (z. B. Softwareproblem wie etwa Feststecken in einer Schleife, Hardwareproblem wie etwa eine schlechte Antenne), wodurch ein korrekter Betrieb der TCU 104 verhindert wird. Als ein weiteres Beispiel kann eine Netzwerk- (oder Mobilfunk-) Störung vorkommen (z. B. Probleme beim Verbinden mit einem drahtlosen Netzwerk, wenig oder keine Netzwerkverbindung), was zu langsamen Verbindungsgeschwindigkeiten oder einem Verbindungsfehler führen kann. Als ein anderes Beispiel können die Fernsysteme 106 Störungen aufweisen, was die Übertragung von Daten von und an die Fernsysteme 106 verhindern kann. Der Versuch einer nachträglichen Simulation der Umstände, die zu einer TCU-Störung führen, zu Diagnosezwecken ist angesichts des Zeitverlaufs und der Bewegung des Fahrzeugs 102 schwierig. Zum Beispiel können sich die Umstände (z. B. Signalstärke) des Mobilfunknetzwerks ändern, wenn sich der Standort des Fahrzeugs 102 ändert. Die Umstände jeder TCU-Störung können zudem nicht reproduzierbar sein, nachdem die Störung eintritt. Da darüber hinaus die Quelle einer TCU-Störung im Nachhinein oft unbekannt ist, soweit derartige Störungen diagnostiziert werden können, kann das Diagnostizieren der Störung einen Rate- und Prüfprozess nach sich ziehen, der eine erhebliche Nutzung von Ressourcen und Zeit erfordert.
Statt sich auf nachträgliche Simulationen zum Diagnostizieren von TCU-Störungen zu stützen, kann die TCU 104 dementsprechend dazu konfiguriert sein, ein oder mehrere Protokolle in Bezug auf Aktivitäten und Störungen der TCU 104 zu erzeugen. Nach dem Eintreten einer Störung oder periodisch oder bei Bedarf von dem Diagnoseserver 110 kann die TCU 104 dazu konfiguriert sein, mindestens einen Teil der Protokolle für den Diagnoseserver 110 drahtlos außer Bord des Fahrzeugs 102 zu übertragen, wie etwa über den Nachrichtenbroker 108 und ein Message-Queue-Telemetry-Transport-(MQTT-)Protokoll, das spezifisch für die vorliegenden Ausführungsformen ausgestaltet ist. Der Diagnoseserver 110 kann dann auf Grundlage der Protokolle bestimmen, oder einem Benutzer ermöglichen, zu bestimmen, ob eine TCU-Störung aufgrund einer Störung einer Komponente der TCU 104 oder aufgrund einer Netzwerkstörung eingetreten ist, und die Störung dementsprechend beheben.
Das Fahrzeug 102 kann verschiedene Arten von Automobilen, einen Softroader (crossover utility vehicle - CUV), eine Geländelimousine (sport utility vehicle - SUV), einen Truck, ein Wohnmobil (recreational vehicle - RV), ein Boot, ein Flugzeug oder eine andere mobile Maschine zum Befördern von Personen oder Gütern beinhalten. In vielen Fällen kann das Fahrzeug 102 durch einen Verbrennungsmotor angetrieben werden. Als eine andere Möglichkeit kann das Fahrzeug 102 ein Hybridelektrofahrzeug (hybrid electric vehicle - HEV) sein, das sowohl durch einen Verbrennungsmotor als auch einen oder mehrere Elektromotoren angetrieben wird, wie etwa ein Serienhybrid-Elektrofahrzeug (series hybrid electric vehicle - SHEV), ein Parallelhybrid-Elektrofahrzeug (parallel hybrid electrical vehicle - PHEV) oder ein Parallel-/Serienhybrid-Elektrofahrzeug (parallel/series hybrid electric vehicle - PSHEV). Da die Art und Konfiguration des Fahrzeugs 102 variieren können, können entsprechend auch die Betriebseigenschaften des Fahrzeugs 102 variieren. Als einige andere Möglichkeiten kann das Fahrzeug 102 andere Eigenschaften in Bezug auf Fahrgastkapazität, Zugfähigkeit und -kapazität sowie Lagervolumen aufweisen.
Das Fahrzeug 102 kann verschiedene Hardware- und Softwarekomponenten beinhalten, wie etwa unter anderem eine oder mehrere Fahrzeugsteuerungen 116 (in dem System 100 als einzelne Steuerungen 116A bis 116G dargestellt). Die Steuerungen 116 können dazu konfiguriert sein, verschiedene Funktionen des Fahrzeugs 102 mit der Leistung der Fahrzeugbatterie und/oder Kraftübertragung zu überwachen und zu verwalten. Die Steuerungen 116 können einen oder mehrere Prozessoren (z. B. Mikroprozessoren) beinhalten, die dazu konfiguriert sind, Firmware- oder Softwareprogramme auszuführen, die auf einer oder mehreren Speichervorrichtungen der Steuerungen 116 gespeichert sind. Die Steuerungen 116 sind zwar als separate Komponenten veranschaulicht, doch die Fahrzeugsteuerungen 116 können gemeinsame physische Hardware, Firmware und/oder Software besitzen, sodass die Funktionalität mehrerer Steuerungen 116 in eine einzelne Steuerung 116 integriert werden kann und sodass die Funktionalität von verschiedenen derartigen Steuerungen 116 auf eine Vielzahl von Steuerungen 116 verteilt werden kann.
Zu den Fahrzeugsteuerungen 116 können zum Beispiel unter anderem folgende gehören: eine Antriebsstrangsteuerung 116A, die dazu konfiguriert ist, Motorbetriebskomponenten zu verwalten, eine Karosseriesteuerung 116B, die dazu konfiguriert ist, verschiedene Leistungssteuerungsfunktionen wie etwa Außenbeleuchtung, Innenbeleuchtung, schlüssellosen Zugang, Fernstart und Verifikation des Status von Zugangspunkten zu verwalten, eine Funksendeempfängersteuerung 116C, die dazu konfiguriert ist, mit Schlüsselanhängern, mobilen Vorrichtungen oder anderen lokalen Vorrichtungen des Fahrzeugs 102 zu kommunizieren, eine Unterhaltungssteuerung 116D, die dazu konfiguriert ist, Sprachbefehle und BLUETOOTH-Schnittstellen mit dem Fahrer und Fahrermobilvorrichtungen zu unterstützen, eine Klimasteuerungsverwaltungssteuerung 116E, die dazu konfiguriert ist, Heiz- und Kühlsystemkomponenten (z. B. Kompressorkupplung, Gebläselüfter, Temperatursensoren etc.) zu überwachen und verwalten, eine Steuerung für das globale Positionsbestimmungssystem (GPS) 116F, die dazu konfiguriert ist, Fahrzeugstandortinformationen bereitzustellen, und eine Steuerung für eine Benutzerschnittstelle (HMI) 116G, die dazu konfiguriert ist, Benutzereingaben über verschiedene Tasten oder andere Steuereinrichtungen zu empfangen sowie einem Fahrer Fahrzeugstatusinformationen bereitzustellen.
Der Fahrzeugbus 118 kann verschiedene Kommunikationsverfahren beinhalten, die zwischen den Fahrzeugsteuerungen 116 sowie zwischen der TCU 104 und den Fahrzeugsteuerungen 116 verfügbar sind. Die TCU 104 kann somit an die Steuerungen gekoppelt werden und Daten (z. B. Diagnoseinformationen) von den Steuerungen 116 an die Fernsysteme 106 kommunizieren und Daten oder Befehle (z. B. einen Fernstartbefehl) von den Fernsystemen 106 über den Fahrzeugbus 118 an die Steuerungen 116 übertragen. Der Fahrzeugbus 118 kann eines oder mehrere von einem Controller Area Network (CAN) des Fahrzeugs, einem Ethernet-Netzwerk und/oder einem Media-Oriented-System-Transport-(MOST-)Netzwerk beinhalten.
Die TCU 104 kann einen Prozessor 120, Speicher 122 und ein Modem 123 beinhalten. Der Prozessor 120 kann eine oder mehrere Vorrichtungen beinhalten, die aus Mikroprozessoren, Mikrocontrollern, digitalen Signalprozessoren, Mikrocomputern, Hauptprozessoren, feldprogrammierbaren Gate-Arrays, programmierbaren Logikvorrichtungen, Zustandsmaschinen, Logikschaltungen, analogen Schaltungen, digitalen Schaltungen oder beliebigen anderen Vorrichtungen, die (analoge oder digitale) Signale auf Grundlage von Betriebsanweisungen verarbeiten, die in dem Speicher 122 gespeichert sind, ausgewählt ist bzw. sind. Der Speicher 122 kann eine einzelne Speichervorrichtung oder eine Vielzahl von Speichervorrichtungen beinhalten, zu denen unter anderem Festwertspeicher (read-only memory - ROM), Direktzugriffsspeicher (random access memory - RAM), flüchtiger Speicher, nichtflüchtiger Speicher, statischer Direktzugriffsspeicher (SRAM), dynamischer Direktzugriffsspeicher (DRAM), Flash-Speicher, Cachespeicher, Massenspeichervorrichtungen wie etwa ein Festplattenlaufwerk, optisches Laufwerk, Bandlaufwerk und eine nichtflüchtige Solid-State-Vorrichtung und eine beliebige andere Vorrichtung, die zum Speichern von Informationen in der Lage ist, gehören. Der Speicher 122 kann dazu konfiguriert sein, Betriebssysteme und Anwendungen, die durch den Prozessor 120 ausgeführt werden, und Datenbanken für Informationen, auf die durch den Prozessor 120 zugegriffen wird, zu speichern.
Der Prozessor 120 kann dazu konfiguriert sein, Firmware- oder Softwareprogramme auszuführen, wie etwa eine Protokolliereinrichtung 124, die auf dem Speicher 122 der TCU 104 gespeichert sind. Die TCU 104 kann ferner Netzwerkhardware beinhalten, die dazu konfiguriert ist, die Kommunikation zwischen den Fahrzeugsteuerungen 116 zu erleichtern und die Kommunikation zwischen dem Fahrzeug 102 und anderen Vorrichtungen des Systems 100 über das Netzwerk 112 zu erleichtern. Zum Beispiel kann das Modem 123 der TCU 104 drahtlose Verbindungsfähigkeit mit dem Netzwerk 112 bereitstellen und dadurch ermöglichen, dass die TCU 104 Fahrzeugbetriebsdaten drahtlos von den Fahrzeugsteuerungen 116 an ein oder mehrere Fernsysteme 106 überträgt. Gleichermaßen kann das Modem 123 ermöglichen, dass die TCU 104 protokollierte Daten, die TCU-Netzwerkaktivität und/oder TCU-Komponentenstörungen angeben, an den Datenbroker 108 und den Diagnoseserver 110 zu übertragen. Das Netzwerk 112 kann ein oder mehrere miteinander verbundene Kommunikationsnetzwerke beinhalten, wie etwa das Internet, ein Weitverkehrsnetzwerk, ein Kabelfernsehverteilungsnetzwerk, ein Satellitenverbindungsnetzwerk, ein lokales Netzwerk, ein Weitverkehrsnetzwerk und ein Telefonnetzwerk. Die TCU 104 zudem dazu konfiguriert sein, über eines oder mehrere von Bluetooth, Wi-Fi und drahtgebundenen USB-Netzwerkverbindungen zu kommunizieren, und kann die Datenübertragung zwischen dem Fahrzeug 102 und dem Netzwerk 112 über eine mobile Vorrichtung (nicht gezeigt), die in dem Fahrzeug 102 angeordnet oder mit diesem gekoppelt ist, erleichtern.
Nach dem Einschalten oder Starten eines Motors des Fahrzeugs 102 kann die Protokolliereinrichtung 124 dazu konfiguriert sein, Störungsdaten für die TCU 104 zu protokollieren. Konkret kann die Protokolliereinrichtung 124 dazu konfiguriert sein, in einem Protokoll Drahtlosaktivitätsdaten aufzuzeichnen, die Netzwerkstörungen wie etwa ein Netzwerkverbindungsproblem angeben. Die Drahtlosaktivitätsdaten können eine oder mehrere Netzwerkstörungen (wie etwa eine Mobilfunknetzwerkstörung) angeben, die eintreten, wenn die TCU 104 einen oder mehrere Ferndienste für das Fahrzeug 102 bereitstellt, wie etwa Herunterladen oder Empfangen von Daten, Hochladen oder Übertragen von Daten sowie Verbindungsprozesse und -prozeduren, die durch die TCU 104 durchgeführt werden oder mit deren Betrieb in Zusammenhang stehen. Die Verbindungsprozesse und -prozeduren können Prozeduren zur Protokollsignalisierung beinhalten, die beim Verbinden und Kommunizieren über das Netzwerk 112 durch die TCU 104 durchgeführt werden, wie etwa Aktivitäten zur Signalisierung, Authentifizierung, Verbindung, Trennung und Übergabe der TCU 104. Mit anderen Worten können die protokollierten Drahtlosaktivitätsdaten eine Störung in Bezug auf Aktivitäten der TCU 104 feststellen, wozu eine durch die TCU 104 durchgeführte Prozedur zur Authentifizierung, Verbindung, Signalisierung, Trennung und Übergabe gehört, um Daten von den Fahrzeugsteuerungen 116 drahtlos an ein Fernsystem 106 zu übertragen und/oder Daten oder Befehle für die Fahrzeugsteuerungen 116 von einem Fernsystem 106 zu empfangen.
Hinsichtlich der oben erwähnten Prozeduren zur Protokollsignalisierung kann das Signalisieren durchgeführt werden, um zu bestimmen, ob sich die TCU 104 in einem Bereich mit hinreichender Netz- oder Mobilfunkabdeckung befindet und nicht in einem Bereich mit geringer oder keiner Abdeckung (z. B. einem Bereich mit -113 db oder weniger). Wenn eine hinreichende Netz- oder Mobilfunkabdeckung verfügbar ist, kann eine Authentifizierung durchgeführt werden, um die TCU 104 bei einem Netz- oder Mobilfunkanbieter zu authentifizieren, und die TCU 104 kann als Reaktion auf die Authentifizierung entweder eine ANNAHME- oder ABLEHNUNGsnachricht von dem Anbieter empfangen. Eine Verbindung kann hergestellt werden, wann immer eine Sitzung zwischen der TCU 104 und dem Netzwerk 112 begonnen wird, wie etwa über eine Datenverbindungsanforderung (z. B. eine PDP-Verbindungsanforderung), und die TCU 104 kann als Reaktion auf die Anforderung entweder eine ANNAHME- oder ABLEHNUNGsnachricht empfangen. Eine Trennung kann durchgeführt werden, wenn eine Sitzung zwischen der TCU 104 und dem Netzwerk 112 endet, wobei die TCU 104 in diesem Fall eine Trennungsnachricht empfangen kann. Eine Übergabe kann durchgeführt werden, wenn sich das Fahrzeug 102 in Bewegung befindet und die TCU 104 ihre Mobilfunk- oder Netzwerkverbindung von einem Zugangspunkt oder Mobilfunkmast zu einem anderen Zugangspunkt oder Mobilfunkmast ändern muss.
Die Protokolliereinrichtung 124 kann dazu konfiguriert sein, periodisch oder kontinuierlich auf Störungen in Bezug auf Drahtlosaktivitäten hin zu überwachen, die durch die TCU 104 durchgeführt werden, wie etwa Fehler, die während vorstehend beschriebener Verbindungsprozesse und -prozeduren eintreten, um diese als Teil der protokollierten Drahtlosaktivitätsdaten einzuschließen. Zu diesem Zweck kann die Protokolliereinrichtung 124 dazu konfiguriert sein, periodisch oder kontinuierlich Drahtlosaktivitätsdaten in Bezug auf Drahtlosaktivitäten der TCU 104 zu erheben und vorübergehend zu speichern, wie etwa in einem Hauptspeicher der TCU 104 (z. B. RAM). Die Drahtlosaktivitätsdaten können mehrere periodisch aufgezeichnete Einträge beinhalten, die jeweils Einzelheiten zu einer oder mehreren Drahtlosaktivitäten enthalten, die zu einem gegebenen Zeitpunkt durch die TCU 104 durchgeführt werden. Jeder Eintrag kann einen Zeitstempel, der angibt, wann die Daten für den Eintrag erhoben wurden, einen aktuellen Standort des Fahrzeug 102, als die Daten für den Eintrag erhoben wurden, die aktuelle Netzabdeckung des Fahrzeugs 102, als die Daten für den Eintrag erhoben wurde, und/oder ob die TCU 104 Drahtlosaktivitäten vornahm, als der Dateneintrag erhoben wurde, beinhalten. Für jede Drahtlosaktivität kann der Eintrag zudem einen Anfangszeitpunkt der Drahtlosaktivität, einen Endzeitpunkt der Drahtlosaktivität, eine verstrichene Zeit für die Drahtlosaktivität, eine Geschwindigkeit für die ausgewählte Aktivität, einen Status der Drahtlosaktivität (z. B. ausstehend, inaktiv), ein Ergebnis der Drahtlosaktivität (z. B. erfolgreich, fehlgeschlagen) beinhalten.
Als Reaktion darauf, dass eine Netzwerkstörung anhand der vorübergehend gespeicherten Daten detektiert wird, wie etwa langsame Verbindungsgeschwindigkeiten, unzureichende Netzabdeckung, fehlgeschlagener Verbindungsaufbau zu einem verfügbaren Netzwerk und/oder Fehlschlagen von einer der oben erwähnten Drahtlosaktivitäten, kann die Protokolliereinrichtung 124 dazu konfiguriert sein, die festgestellte Störung in einem Protokoll aufzuzeichnen, wie etwa einem Drahtlosprotokoll 126, das für das Speichern von Drahtlosaktivitätsdaten und/oder netzwerkbezogenen Störungen der TCU 104 spezifisch ist. Zu diesem Zweck kann die Protokolliereinrichtung 124 zudem in dem Protokoll mindestens einen Teil der vor der Störung erhobenen Drahtlosaktivitätsdaten aufzeichnen. Zum Beispiel kann das Protokoll die festgestellte Netzwerkstörung, Einzelheiten, die der Drahtlosaktivität der TCU 104 entsprechen, die der in die Drahtlosaktivitätsdaten eingeschlossenen Netzwerkstörung entsprechen, und/oder andere vor der Störung erhobene Drahtlosaktivitätsdaten beinhalten. Konkret kann das Protokoll zudem Drahtlosaktivitätsdaten beinhalten, die einem Zeitstempel zugeordnet sind, der innerhalb eines vorbestimmten Zeitraums unmittelbar vor der Netzwerkstörung fällt. Im Gegensatz zu der vorübergehenden Speicherung kann das Protokoll in einer Vorrichtung zur dauerhaften Speicherung gespeichert werden, wie etwa einer Massenspeichervorrichtung des Speichers 122, und kann eine oder mehrere Protokolldateien beinhalten, die mindestens einen Teil (z. B. die oben erwähnten Teile) der Drahtlosaktivitätsdaten beinhalten.
Alternativ kann die Protokolliereinrichtung 124 dazu konfiguriert sein, periodisch oder kontinuierlich alle Drahtlosaktivitätsdaten in dem Protokoll wie etwa dem Protokoll 126 aufzuzeichnen, und demnach werden die Drahtlosaktivitätsdaten ungeachtet dessen erhoben, ob eine Mobilfunkstörung eintritt. In diesem Fall können die protokollierten Daten nach Detektion der Netzwerkstörung Drahtlosaktivitätsdaten der TCU 104 beinhalten, die der Netzwerkstörung zugeordnet sind, und Drahtlosaktivitätsdaten der TCU 104, die nicht der Mobilfunkstörung zugeordnet sind. In diesem Fall kann die Protokolliereinrichtung 124 vor dem Übertragen des Protokolls außer Bord des Fahrzeugs 102 dazu konfiguriert sein, mindestens einen Teil der Drahtlosaktivitätsdaten, der nicht der Mobilfunkstörung zugeordnet ist, aus dem Protokoll (oder mindestens dem übertragenen Protokoll) zu entfernen und/oder zu verwerfen. Zum Beispiel kann die Protokolliereinrichtung 124 dazu konfiguriert sein, alle Drahtlosaktivitätsdaten, die nicht einer Netzwerkstörung zugeordnet sind, oder die Drahtlosaktivitätsdaten, die einem Zeitstempel zugeordnet sind, der nicht innerhalb des vordefinierten Zeitraums unmittelbar vor der Netzwerkstörung fällt, aus dem Protokoll (oder mindestens dem übertragenen Protokoll) zu entfernen und/oder zu verwerfen.
Die Protokolliereinrichtung 124 kann zudem dazu konfiguriert sein, Daten in Zusammenhang mit Netzwerkaktivität und/oder Betrieb der TCU 104 zu erheben, wie etwa einen Status von Komponenten der TCU 104 (z. B. Komponente arbeitet normal, die Werte von Parametern der Komponenten, eine Komponente meldet einen anormalen Betriebszustand), nachdem die Mobilfunkstörung eine vorbestimmte Zeit (z. B. fünf Sekunden) lang oder bis zu einer vorbestimmten Datengröße detektiert worden ist, und kann diese Daten unter Zuordnung zu der Störung in dem Protokoll aufzeichnen. Auf diese Art und Weise kann das Protokoll Daten, die die Mobilfunkstörung feststellen, Daten in Bezug auf die Netzwerkaktivität und einen Zustand der TCU 104, der zu der Störung führt, und Daten in Bezug auf einen Zustand der TCU 104 und/oder Netzwerkaktivität, nachdem die Störung detektiert worden ist, beinhalten.
Netzwerkaktivitätsdaten der TCU 104, die durch die Protokolliereinrichtung 124 erhoben werden und keiner Störung entsprechen, können verworfen werden, ohne jemals protokolliert zu werden und/oder ohne jemals außer Bord des Fahrzeugs 102 übertragen zu werden.
Die Protokolliereinrichtung 124 kann zudem dazu konfiguriert sein, TCU-Komponentenstörungen, die eine Störung einer Komponente (z. B. Hardware, Software) der TCU 104 angeben, als Reaktion auf eine Komponentenstörung der TCU 104 in einem Protokoll aufzuzeichnen, wie etwa dem Komponentenprotokoll 128 in dem Speicher 122. Das Komponentenprotokoll 128 kann für TCU-Komponentenstörungsdaten spezifisch sein und kann eine oder mehrere Protokolldateien beinhalten, die in einer Vorrichtung zur dauerhaften Speicherung des Speichers 122 enthalten sind, wie etwa einer Massenspeichervorrichtung. Durch die TCU 104 protokollierte Komponentenstörungen können Diagnosefehlercodes (diagnostic trouble codes - DTCs), Fehlschlagen von Firmware Over-the-Air (FOTA), Eingabe-/Ausgabe-(E/A-)Fehler, Fehler beim globalen Positionsbestimmungssystem (GPS), Verbindungsprobleme des MQTT-Nachrichtenbrokers und fehlgeschlagene Lese-/Schreibvorgänge bei einem Speicher beinhalten. Die Protokolliereinrichtung 124 kann dazu konfiguriert sein, TCU-Komponentenstörungen auf Ereignisbasis (z. B. als Reaktion darauf, dass ein DTC empfangen wird) in dem Protokoll aufzuzeichnen.
Wie vorstehend angemerkt, kann die Protokolliereinrichtung 124 die protokollierten TCU-Netzwerkaktivitätsdaten in einem Drahtlosprotokoll 126 des Speichers 122 speichern und die protokollierten TCU-Komponentenstörungsdaten in einem Komponentenprotokoll 128 des Speichers 122 speichern. Alternativ kann die Protokolliereinrichtung 124 die protokollierten Netzwerkaktivitätsdaten und protokollierten Komponentenstörungsdaten in einem einzigen Protokoll des Speichers 122 speichern oder jeden Eintrag der protokollierten Netzwerkaktivitätsdaten und protokollierten Komponentenstörungsdaten in einem separaten Protokoll des Speichers 122 speichern.
Die TCU 104 kann nichtflüchtigen Speicher beinhalten, der zum Speichern der durch die Protokolliereinrichtung 124 erstellten Protokolle vorgesehen ist. Konkret kann der Speicher 122 nichtflüchtigen Speicher beinhalten, und ein Teil des nichtflüchtigen Speichers kann zum Speichern der Protokolle vorgesehen sein. In einigen Ausführungsformen kann der Teil höchstens 2 MB groß sein. Die TCU 104 und/oder die Protokolliereinrichtung 124 kann dazu konfiguriert sein, eine Kombination aus dem zugewiesenen nichtflüchtigen Speicher (z. B. Flash-Speicher) und in dem Speicher 122 enthaltenen RAM zu verwenden, um die Protokolle effizient zu speichern und übertragen. Zum Beispiel kann die TCU 104 und/oder die Protokolliereinrichtung 124 einen Austauschalgorithmus umsetzen, der mit sich bringen kann, dass die Protokolle oder protokollierten Daten in RAM gespeichert und danach in Flash bewegt werden, wie etwa, falls die Protokolliereinrichtung 124 nicht dazu in der Lage ist, die protokollierten Daten erfolgreich an den Diagnoseserver 110 oder den Datenbroker 108 zu übertragen. Darüber hinaus kann die Protokolliereinrichtung 124 die Protokolle periodisch erstellen und in dem nichtflüchtigen Speicher speichern, wie etwa anhand der in dem RAM gespeicherten Daten, und die gespeicherten Protokolle in dem Klartextformat UTF-8 formatieren. Wenn sie protokolliert sind, können Daten in kleinere Datenblöcke unterteilt werden, wie etwa Datenblöcke von jeweils 128 Bytes. In bestimmten Ausführungsformen können maximal sechzehn Datenblöcke in dem nichtflüchtigen Speicher für die gespeicherten Protokolle platziert werden.
Als Reaktion darauf, dass eine TCU-Störung (z. B. eine Netzwerkstörung oder eine Komponentenstörung) eintritt, detektiert wird und in einem Protokoll aufgezeichnet wird, kann die Protokolliereinrichtung 124 dazu konfiguriert sein, zu veranlassen, dass die TCU 104 die protokollierten Daten für den Diagnoseserver 110 außer Bord des Fahrzeugs 102 überträgt. Zum Beispiel kann die Protokolliereinrichtung 124 dazu konfiguriert sein, als Reaktion auf eine Netzwerkstörung die protokollierten Netzwerkaktivitätsdaten, die in dem Drahtlosprotokoll 126 gespeichert sein können, für den Diagnoseserver 110 drahtlos außer Bord des Fahrzeugs 102 zu übertragen. Die Protokolliereinrichtung 124 kann ebenso dazu konfiguriert sein, als Reaktion auf eine TCU-Komponentenstörung die protokollierten Komponentenstörungsdaten, die in dem Komponentenprotokoll 128 gespeichert sein können, für den Diagnoseserver 110 drahtlos außer Bord des Fahrzeugs 102 zu übertragen.
Als ein weiteres Beispiel kann die Protokolliereinrichtung 124 entweder als Reaktion auf eine TCU-Komponentenstörung oder eine Netzwerkstörung dazu konfiguriert sein, alle oder mindestens einen Teil der protokollierten TCU-Komponentenstörungsdaten und alle oder mindestens einen Teil der protokollierten Drahtlosaktivitätsdaten außer Bord des Fahrzeugs 102 zu übertragen. Auf diese Art und Weise kann der Diagnoseserver 110 auf die Netzwerkaktivität der TCU 104 etwa zu dem Zeitpunkt querverweisen, zu dem eine TCU-Komponentenstörung eintrat, und auf die TCU-Komponentenstörungsdaten etwa zu dem Zeitpunkt querverweisen, zu dem eine Netzwerkstörung eintritt. Zum Beispiel kann die Protokolliereinrichtung 124 als Reaktion auf eine Komponentenstörung dazu konfiguriert sein, alle protokollierten Komponentenstörungsdaten und einem Zeitstempel zugeordnete protokollierte Drahtlosaktivitätsdaten, die innerhalb eines vordefinierten Zeitraums unmittelbar vor und/oder eines vordefinierten Zeitraums unmittelbar nach dem Zeitpunkt der Komponentenstörung fallen, zu übertragen. Zu diesem Zweck kann die Protokolliereinrichtung 124 als Reaktion auf die Komponentenstörung dazu konfiguriert sein, Daten in protokollierten Drahtlosaktivitätsdaten festzustellen, die einem Zeitstempel innerhalb eines vordefinierten Zeitraums unmittelbar vor und/oder eines vordefinierten Zeitraums unmittelbar nach der Komponentenstörung zugeordnet sind, und die festgestellten Daten und die protokollierten Komponentenstörungsdaten zu übertragen. Gleichermaßen kann die Protokolliereinrichtung 124 im Fall einer Netzwerkstörung dazu konfiguriert sein, alle protokollierten Netzwerkaktivitätsdaten und die einer Zeit innerhalb eines vordefinierten Zeitraums vor und/oder eines vordefinierten Zeitraums nach dem Zeitpunkt der Komponentenstörung zugeordneten Komponentenstörungsdaten zu übertragen. Durch den vorstehenden Prozess herausgefilterte protokollierte Daten (z. B. protokollierte Daten, die einem Zeitstempel außerhalb der oben erwähnten vordefinierten Zeiträume zugeordnet sind) können verworfen werden, ohne für den Diagnoseserver 110 außer Bord des Fahrzeugs 102 übertragen zu werden.
Die Protokolliereinrichtung 124 kann ferner dazu konfiguriert sein, eines oder mehrere der Protokolle als Reaktion darauf, dass die Speicherzuweisung für die Protokolle voll oder beinahe voll wird (z. B. 85 % voll, 95 % voll), oder als Reaktion darauf, dass eine Anforderung für ein gespeichertes Protokoll von dem Diagnoseserver 110 empfangen wird, oder periodisch für den Diagnoseserver 110 außer Bord des Fahrzeugs 102 zu übertragen.
Wenn protokollierte Daten für den Diagnoseserver 110 außer Bord des Fahrzeugs 102 übertragen werden, kann die Protokolliereinrichtung 124 dazu konfiguriert sein, die protokollierten Daten zur Übertragung in kleinere Datenblöcke aufzuteilen (falls sie nicht bereits aufgeteilt sind), wie etwa Datenblöcke von jeweils 128 Kilobytes. Die Protokolliereinrichtung 124 kann zudem einen Kopf erzeugen, der die Gesamtanzahl von Datenblöcken feststellt, aus denen ein übertragenes Protokoll oder eine Übertragung besteht, und den Kopf an jeden der Datenblöcke anhängen. Der Kopf kann es dem Diagnoseserver 110 und/oder Datenbroker 108 ermöglichen, eine Nachrichtenübertragung zu verstehen und zu dekodieren, wenn die Blöcke empfangen werden, indem der Kopf jedes Datenblocks ausgelesen wird und die Protokolle auf dessen Grundlage wieder zusammengesetzt werden. Vor dem Übertragen der Protokolle kann die Protokolliereinrichtung 124 die Protokolle verschlüsseln, um höhere Sicherheit zu gewährleisten.
Als Reaktion auf eine erfolgreiche Übertragung von protokollierten Daten an den Diagnoseserver 110 oder den Datenbroker 108 kann die Protokolliereinrichtung 124 eine Bestätigungsnachricht empfangen. Als Reaktion darauf kann die Protokolliereinrichtung 124 die übertragenen protokollierten Daten aus dem Speicher 122 entfernen. Im Fall einer fehlgeschlagenen Übertragung, wie etwa aufgrund eines Problems bei der drahtlosen Verbindung, da der Kommunikationskanal (z. B. MQTT-Kanal) ausgelastet ist oder da eine Bestätigung für die Übertragung von dem Datenbroker 108 oder dem Diagnoseserver 110 nicht empfangen wird, kann die Protokolliereinrichtung 124 und/oder die TCU 104 jedoch die protokollierten Daten aufbewahren, wie etwa durch Bewegen der Daten in nichtflüchtigen Speicher und/oder Einsetzen der protokollierten Daten in einen Cache für Protokolldaten zu fehlgeschlagenen Übertragungen 130. Der Cache kann jede Instanz von protokollierten Daten oder jede Protokolldatei beinhalten, die nicht erfolgreich durch den Datenbroker 108 oder den Diagnoseserver 110 empfangen worden ist. Danach kann die Protokolliereinrichtung 124 einen Wiederholungsmechanismus umsetzen. Zum Beispiel kann die Protokolliereinrichtung 124 und/oder die TCU 104 periodische Speicherprüfungen des Cache für Protokolldaten zu fehlgeschlagenen Übertragungen 130 durchführen und erneut versuchen, die Daten zu übertragen. Zusätzlich oder alternativ kann die Protokolliereinrichtung 124 als Reaktion darauf, dass die Datengröße der Protokolldaten zu fehlgeschlagenen Übertragungen in dem Cache 130 gleich einem vorbestimmten Schwellenwert (z. B. 85 % oder 95 % des zum Speichern der Protokolldaten zu fehlgeschlagenen Übertragungen zugewiesenen Platzes) ist oder diesen übersteigt, dazu konfiguriert sein, automatisch und drahtlos erneut zu versuchen, die Protokolldaten zu fehlgeschlagenen Übertragungen für den Diagnoseserver 110 außer Bord des Fahrzeugs 102 zu übertragen.
Zusätzlich zu den oben erwähnten Vorteilen sind hier beschriebene Ausführungsformen dazu ausgestaltet, technische Herausforderungen in Bezug auf das Überwachen und Beheben von TCU-Störungen eines Fahrzeugs 102 zu bewältigen. Die Optimierung des verfügbaren Platzes und der Leistungsnutzung ist ein Faktor beim Ausgestalten eines Fahrzeugs 102 und zu diesem Zweck ist die zuverlässige lokale elektronische Speicherung keine unendliche Ressource zum Überwachen und Beheben von TCU-Störungen. Somit kann eine Lösung zum Überwachen und Beheben von TCU-Störungen eines Fahrzeugs 102 zwar mit sich bringen, dass TCU-Störungsprotokolle lokal gespeichert werden, bis ein Laptop oder eine andere Vorrichtung direkt mit dem Fahrzeug 102 verbunden wird, um die gespeicherten Protokolle herunterzuladen, doch eine derartige Lösung ist unter Umständen nicht effizient oder praktisch umsetzbar. Konkret kann bei dieser Lösung, wenn ein Fahrzeug 102 betrieben wird, die lokale Kapazität zum Speichern der TCU-Störungsprotokolle und TCU-Aktivität immens sein, insbesondere falls ein langes Intervall zwischen den Zeitpunkten vorliegt, zu denen die Protokolle über den Laptop von dem Fahrzeug 102 heruntergeladen werden. Folglich kann das Speichern von TCU-Störungsprotokollen und Aktivität, bis ein Laptop dazu in der Lage ist, sich direkt mit dem Fahrzeug 102 zu verbinden und die Protokolle herunterzuladen, die durch das Fahrzeug 102 verbrauchten Ressourcen stark erhöhen. Da bei dieser Lösung keine Daten zum Diagnostizieren einer Störung verfügbar sind, bis sie direkt über einen Laptop oder eine andere Hardwarevorrichtung von dem Fahrzeug 102 ausgelesen werden, wird darüber hinaus die Reaktionszeit zum Diagnostizieren einer TCU-Störung erhöht.
Um die verbrauchten Ressourcen und Reaktionszeiten in Bezug auf das Überwachen und Beheben einer TCU-Störung zu minimieren, kann die Protokolliereinrichtung 124 somit dazu konfiguriert sein, kontinuierlich auf TCU-Störungen einschließlich TCU-Komponentenstörungen und Netzwerkstörungen hin zu überwachen und diese zu protokollieren. Falls keine Störungen detektiert werden, dann können keine Daten protokolliert werden und etwaige vorübergehend gespeicherte Daten verworfen werden. Alternativ können Daten in Bezug auf die Netzwerkaktivität der TCU 104 protokolliert werden und nach einem Zeitraum, in dem keine Störung detektiert wird, verworfen werden. Mit anderen Worten kann die Protokolliereinrichtung 124 dazu konfiguriert sein, protokollierte Netzwerkaktivitätsdaten zu löschen, die auf Grundlage der in den Daten enthaltenen Zeitstempel älter als ein vordefinierter Zeitpunkt vor einem aktuellen Zeitpunkt sind, wodurch Ressourcen für zusätzliche Daten freigemacht werden.
Falls alternativ eine TCU-Störung detektiert wird, kann die Protokolliereinrichtung 124 dazu konfiguriert sein, Daten, die die Störung angeben (falls diese nicht bereits protokolliert sind), und Wahrscheinlichkeitsdaten in Bezug auf Netzwerkaktivität und Betriebszustände der TCU 104 vor und/oder nach der Störung zu protokollieren. Sobald eine Störung protokolliert und detektiert ist, können die protokollierten Daten automatisch an den Diagnoseserver 110 gesendet werden, wie etwa über den Datenbroker 108, und danach aus dem Speicher 122 der TCU 104 entfernt werden. Auf diese Art und Weise werden die über das Netzwerk 112 gesendeten Datennutzlasten reduziert, da die Protokolliereinrichtung 124 dazu konfiguriert sein kann, Störungsdaten zu übertragen, wenn sie protokolliert werden, und nicht wenn Daten für mehrere Störungen angesammelt sind. Die Belastung der Speicherressourcen des Fahrzeugs 102 durch die protokollierten Daten wird ebenfalls reduziert, da die protokollierten Daten übertragen werden können, nachdem sie protokolliert worden sind, und von der TCU 104 entfernt werden können, sobald sie übertragen worden sind, und nicht zum direkten Herunterladen durch einen Laptop angesammelt werden. Darüber hinaus können die Arten von durch die Protokolliereinrichtung 124 protokollierten Daten und Störungen begrenzt sein (z. B. können konkrete Werte, Parameter und Messungen, die herausgefiltert/markiert/protokolliert werden sollen, definiert werden, wie etwa über den Diagnoseserver 110), um den Datenbedarf der gespeicherten Protokolle weiter zu reduzieren.
Der Diagnoseserver 110 kann dazu konfiguriert sein, den Betrieb der TCU 104 über die empfangenen Protokolle zu diagnostizieren. Der Diagnoseserver 110 kann (ebenso wie die Fernsysteme 106 und der Datenbroker 108) einen Prozessor, Speicher und ein Modem oder einen anderen Netzwerksendeempfänger (nicht gezeigt) wie diejenigen der TCU 104 beinhalten. Nachdem die Protokolle empfangen worden sind, kann der Diagnoseserver 110 dazu konfiguriert sein, über seinen Prozessor die Protokolle automatisch in einer Vorrichtung zur dauerhaften Speicherung zu speichern, die Protokolle zu verarbeiten und die Protokolle in einem optimalen Format zum Beseitigen einer Störung der TCU 104 anzuzeigen. Konkret kann der Diagnoseserver 110 den Kopf aus jedem in einer Übertragung empfangenen Datenblock auslesen und dadurch die Gesamtanzahl von Datenblöcken bestimmen, die in jedem Protokoll der Übertragung enthalten sind. Der Diagnoseserver 110 kann diese Informationen dazu verwenden, die Datenblöcke in ein oder mehrere übertragene Protokolle zu dekodieren, und dazu übergehen, die Protokolle wie nachstehend ausführlicher beschrieben zu verarbeiten.
Der Diagnoseserver 110 kann dazu konfiguriert sein, Protokolle aus mehreren TCUs 104 von mehreren Fahrzeugen 102 zu speichern. Für jede TCU 104 kann der Diagnoseserver 110 dazu konfiguriert sein, während eines bestimmten Zeitrahmens, wie etwa der vergangenen sechs Monate, empfangene Protokolle zu speichern. Der Diagnoseserver 110 kann eine grafische Benutzungsschnittstelle (graphical user interface - GUI) zum Anzeigen der Protokolle von einer oder mehreren TCUs 104 und zum Individualisieren der durch die GUI angezeigten Informationen beinhalten. Zum Beispiel kann der Diagnoseserver 110 ermöglichen, dass ein Benutzer unterschiedliche Konfigurationen der gleichen gespeicherten Protokolle bezieht und anzeigt, indem Datumsangaben und Arten von Protokollinhalt (z. B. Drahtlosprotokolle oder Komponentenprotokolle) eingegeben werden. In dem Fall, dass eine Protokollübertragungsanforderung von dem Diagnoseserver 110 eingeleitet wird, kann die GUI des Diagnoseservers 110 ebenso ermöglichen, dass ein Benutzer ein bestimmtes Protokoll über durch den Benutzer vorgegebene Kriterien wie etwa Datumsangaben zur Eingabe und festgestellte Inhaltsart von der TCU 104 eines Fahrzeugs 102 anfordert. Nachdem eine derartige Anforderung empfangen worden ist, kann die TCU 104 dazu konfiguriert sein, eine Protokollübertragung zu erstellen und zu puffern, sodass die Daten der Protokollübertragung die Kriterien der Anforderung erfüllen.
Der Diagnoseserver 110 kann ferner an eine Fehlerbehebungsdatenbank 111 gekoppelt sein oder diese beinhalten. Die Fehlerbehebungsdatenbank 111 kann automatisierte Fehlerbehebungen für TCU-Störungen beinhalten, die bei der TCU 104 auftreten. Als Reaktion darauf, dass protokollierte Daten empfangen werden, wie etwa Daten, die eine Netzwerkverbindungsstörung oder eine TCU-Komponentenstörung angeben, kann der Diagnoseserver 110 dazu konfiguriert sein, die Fehlerbehebungsdatenbank 111 abzufragen, um eine zweckmäßige Fehlerbehebung für die Störung festzustellen. Danach kann der Diagnoseserver 110 die Fehlerbehebung zur Umsetzung durch die TCU 104 an die TCU 104 übertragen. In einigen Ausführungsformen kann der Diagnoseserver 110 dazu konfiguriert sein, die angemessene Fehlerbehebung für eine Störung dynamisch zu bestimmen, wie etwa auf Grundlage von einem oder mehreren Fehlerbehebungsdateneinträgen, die in der Fehlerbehebungsdatenbank 111 enthalten sind. Dieser Prozess kann vollautomatisch sein. Zusätzlich oder alternativ kann ein Benutzer mit der GUI des Diagnoseservers 110 interagieren, um eine Fehlerbehebung auszuwählen, hochzuladen oder zu erzeugen, und die Fehlerbehebung danach selektiv an die TCU 104 übertragen.
Wie die TCU 104 kann der Diagnoseserver 110 einen Wiederholungsmechanismus beinhalten, wenn Anforderungen für Protokolle von diesem aus eingeleitet werden. Der Diagnoseserver 110 kann den Wiederholungsmechanismus umsetzen, wenn ein Problem bei der Netzwerkkommunikation aufkommt oder wenn die TCU 104 außer Betrieb ist (z. B. in einem Ruhezustand, ausgeschaltet), sodass als Reaktion auf eine von dem Diagnoseserver 110 gesendete Protokollanforderung keine Daten empfangen werden.
Wenngleich in 1 ein beispielhaftes System 100 gezeigt ist, sollen die in der Figur veranschaulichten beispielhaften Komponenten nicht einschränkend sein. Tatsächlich kann das System 100 mehr oder weniger Komponenten aufweisen und es können zusätzliche oder alternative Komponenten und/oder Umsetzungen verwendet werden. Als ein nicht einschränkendes Beispiel können sich die Protokolliereinrichtung 124 und seine entsprechende Funktionalität in einer oder mehreren anderen Steuerungen 116 des Fahrzeugs 102 als der TCU 104 befinden.
2 veranschaulicht einen Prozess 200 zum Überwachen, Melden und Beheben von TCU-Störungen. Der Prozess 200 veranschaulicht die Kommunikation zwischen der TCU 104 und dem Diagnoseserver 110 über den Datenbroker 108. Die TCU 104 kann eine MQTT-Sitzung mit dem Datenbroker 108 aufbauen, um die Übertragung von protokollierten Daten von der TCU 104 an den Diagnoseserver 110 zu erleichtern. Im Vergleich zu HTTP- oder HTTPS-Sitzungen, die für jede Einwegkommunikation eingerichtet werden müssen, kann eine MQTT-Sitzung mehrere Stunden lang (z. B. bis zu vier Stunden) als Zwei-Wege-Kommunikationskanal aufgebaut werden und große Nutzlasten von über 200 MB unterstützen, was jeweils die Systemlatenz beim Übertragen von protokollierten Daten reduziert. Darüber hinaus und wie nachstehend ausführlicher beschrieben, kann der Datenbroker 108 als Puffer oder Cache zum Speichern von Nachrichten oder übertragenen Daten dienen, sodass in dem Fall, dass einer der Endpunkte (z. B. die TCU 104 oder der Diagnoseserver 110) nicht dazu in der Lage ist, Nachrichten oder Daten zu empfangen, der Datenbroker 108 Nachrichten oder Daten aufbewahren und die Übertragung später erneut versuchen kann. Dieses Merkmal kann ermöglichen, dass die übertragende Komponente (z. B. das Fahrzeug 102) Systemressourcen eher freimacht, indem die übertragenen Daten aus dem Speicher gelöscht werden, bevor der Diagnoseserver 110 die Daten empfängt. In alternativen Ausführungsformen kann die Kommunikation zwischen der TCU 104 und dem Diagnoseserver 110 unmittelbar erfolgen (d. h. Protokollübertragungen von der TCU 104 für Protokollanforderungen sind spezifisch an den Diagnoseserver 110 gerichtet und umgekehrt).
Bei Index (A) kann der Diagnoseserver 110 eine Anforderung zum Abonnieren von einem oder mehreren TCU-Protokollen einer oder mehrerer TCUs 104 an den Datenbroker 108 übertragen. Auf diese Art und Weise kann der Datenbroker 108 jedes Mal, wenn die TCU 104 durch die TCU protokollierte Daten an den Datenbroker 108 überträgt (oder auch „veröffentlicht“), die durch die TCU protokollierten Daten per Push an Abonnenten der durch die TCU protokollierten Daten einschließlich des Diagnoseservers 110 übertragen. In einigen Ausführungsformen kann die Abonnementanforderung eine oder mehrere konkrete Arten (oder auch „Themen“) von durch die TCU protokollierten Daten angeben, die der Diagnoseserver 110 auf Wunsch eines Benutzers empfangen soll. Zum Beispiel kann die Abonnementanforderung eine Zeichenfolge beinhalten, wie etwa „TCU104/log/wireless“, die einen Wunsch angeben kann, dass der Diagnoseserver 110 Protokollveröffentlichungen durch die TCU 104 empfängt, die spezifisch mit Netzwerkstörungen in Zusammenhang stehen. Alternativ kann die Abonnementanforderung eine Zeichenfolge beinhalten, wie etwa „TCU104/log/TCUcomponent“, die einen Wunsch angeben kann, Protokollveröffentlichungen durch die TCU 104 zu empfangen, die spezifisch mit TCU-Komponentenstörungen in Zusammenhang stehen. Als eine weitere Alternative kann die Abonnementanforderung einen Wunsch angeben, dass der Diagnoseserver 110 alle TCU-Protokollveröffentlichungen der TCU 104 empfängt. Die konkrete Syntax der Themen, die Daten zugeordnet sind, die durch die TCU 104 (und durch den Diagnoseserver 110) veröffentlich werden, kann vor jeglicher Überwachung und Übertragung definiert und zwischen der TCU 104 und dem Diagnoseserver 110 abgestimmt werden.
Bei Index (B) können Drahtlosaktivitätsdaten der TCU 104 erhoben und vorübergehend gespeichert und/oder in einem Protokoll aufgezeichnet werden. Die Drahtlosaktivitätsdaten können Einzelheiten zu einer oder mehreren Drahtlosaktivitäten enthalten, die zu gegebenen Zeitpunkten durch die TCU 104 durchgeführt werden. Bei Index (C) kann eine TCU-Störung festgestellt und/oder protokolliert werden. Zum Beispiel kann eine Netzwerk- oder Mobilfunkstörung eintreten, die verhindern kann, dass die TCU 104 anhand der vorübergehend gespeicherten oder protokollierten Drahtlosaktivitätsdaten eine Verbindung mit dem Netzwerk 112 aufbaut. Alternativ kann eine Komponente der TCU 104 eine Störung aufweisen. Als Reaktion darauf, dass die TCU-Störung detektiert wird, kann die TCU 104 Störungsdaten in einem angemessenen Protokoll (z. B. Drahtlosprotokoll 126, Komponentenprotokoll 128) aufzeichnen, die die Störung feststellen, falls sie nicht bereit in einem Protokoll aufgezeichnet ist. Im Fall einer Netzwerkstörung kann die TCU 104 Netzwerkstörungsdaten protokollieren, die die Netzwerkstörung in dem Drahtlosprotokoll 126 feststellen und/oder Einzelheiten dazu enthalten. Im Fall einer TCU-Komponentenstörung kann die TCU 104 TCU-Komponentenstörungsdaten protokollieren, die die Komponentenstörung in dem Komponentenprotokoll 128 feststellen und/oder Einzelheiten dazu enthalten.
Bei Index (D) kann die TCU 104 als Reaktion darauf, dass die TCU-Störung eintritt und/oder protokolliert wird, mindestens einen Teil von einem oder mehreren der gespeicherten Störungsprotokolle für den Diagnoseserver 110 außer Bord des Fahrzeugs 102 übertragen. Insbesondere kann die TCU 104 mindestens einen Teil des einen oder der mehreren Protokolle dem Datenbroker 108 gegenüber veröffentlichen. Als Teil der Veröffentlichung kann die TCU 104 ein definiertes Thema einschließen, das die Art der Veröffentlichung und/oder Störung beschreibt (z. B. TCU104/log/wireless), die der Diagnoseserver 110 zuvor abonniert hat. Bei Index (E) kann der Datenbroker 108 eine Bestätigung an die TCU 104 übertragen/veröffentlichen, die den Empfang der Veröffentlichung angibt.
Bei Index (F) kann der Datenbroker 108 die einen oder mehreren veröffentlichten protokollierten Daten per Push an den Diagnoseserver 110 übertragen. Insbesondere kann der Datenbroker 108 nach dem Empfangen der Veröffentlichung von der TCU 104 feststellen, dass der Diagnoseserver 110 ein Abonnent des zugeordneten Themas ist, das in der Veröffentlichung von der TCU 104 enthalten ist. Als Reaktion darauf kann der Datenbroker 108 die protokollierten Daten an den Diagnoseserver 110 übertragen. Bei Index (G) kann der Diagnoseserver 110 eine Bestätigung an den Datenbroker 108 übertragen oder veröffentlichen, die den korrekten Empfang der protokollierten Daten angibt. Bei Index (H) kann der Datenbroker 108 eine Bestätigung an die TCU 104 übertragen oder veröffentlichen, die angibt, dass die Abonnenten, in diesem Fall der Diagnoseserver 110, die Veröffentlichung von der TCU 104 empfangen haben.
Nach dem Übertragen/Veröffentlichen der Daten kann die TCU 104 und/oder der Datenbroker 108 auf mindestens eine Bestätigung warten, dass die Daten korrekt durch den oder die beabsichtigten Beteiligten empfangen worden sind. In einigen Ausführungsformen kann die TCU 104 dazu konfiguriert sein, mehrere Bestätigungen zu erwarten, eine von dem Datenbroker 108, die angibt, dass die Daten korrekt durch den Datenbroker 108 empfangen worden sind, und eine andere von dem Datenbroker 108, die angibt, dass die Daten korrekt durch Abonnenten der Veröffentlichung empfangen worden sind, in diesem Fall dem Diagnoseserver 110. Falls die TCU 104 und/oder der Datenbroker 108 eine erwartete Bestätigung nicht innerhalb einer vorbestimmten Zeit nach dem Vornehmen einer Übertragung/Veröffentlichung empfängt, kann die TCU 104 und/oder der Datenbroker 108 einen Wiederholungsmechanismus umsetzen und die Daten erneut an den beabsichtigten Rezipienten übertragen/erneut veröffentlichen. Falls die TCU 104 zum Beispiel die Bestätigung bei Index (E) nicht empfängt, kann die TCU 104 die Übertragung/Veröffentlichung erneut versuchen.
Hinsichtlich fehlgeschlagener Übertragungen/Veröffentlichungen von Daten hilft der Datenbroker 108 dabei, die Beanspruchung der Rechenressourcen der TCU 104 zu mindern. Neben dem Protokollieren kann die TCU 104 dazu dienen, Kommunikation zwischen jeder der Steuerungen 116 und zwischen den Steuerungen 116 und einem Fernsystem 106 über das Netzwerk 112 bereitzustellen. Falls die TCU 104 die Bestätigung bei Index (E) empfängt, aber der Diagnoseserver 110 eine Störung aufweist und nicht dazu in der Lage ist, die veröffentlichten Daten zu empfangen, dann kann sich die TCU 104 auf den Wiederholungsmechanismus des Datenbrokers 108 stützen, statt die Übertragung selbst erneut zu versuchen. Auf diese Art und Weise muss die TCU 104 keine Rechenressourcen dafür verbrauchen, die Daten kontinuierlich zu speichern und zu versuchen, diese erneut an den Diagnoseserver 110 zu übertragen, da der TCU 104 eine Bestätigung vorliegt, dass sich der Datenbroker 108 in Besitz der Daten befindet und gemäß seinem Wiederholungsmechanismus versuchen wird, die Daten erneut zu übertragen. Dies ermöglicht es der TCU 104, ihre Rechenressourcen für andere Funktionen oder weiteres Protokollieren zu verwenden, wodurch die Effizienz der TCU 104 und des Fahrzeugs 102 insgesamt verbessert wird. Dementsprechend kann in einigen Ausführungsformen als Reaktion darauf, dass eine Bestätigung empfangen wird, dass die protokollierten Daten durch den Datenspeicher 108 empfangen worden sind, und bevor die protokollierten TCU-Daten durch den Diagnoseserver 110 empfangen werden, die Protokolliereinrichtung 124 und/oder die TCU 104 die übertragenen protokollierten Daten aus dem Speicher 122 der TCU 104 löschen.
Der Kürze halber ist bei den übrigen beispielhaften Ausführungsformen, die in dem Prozess 200 veranschaulicht sind, die Übertragung oder Veröffentlichung von Bestätigungen ausgelassen. Es versteht sich jedoch, dass als Reaktion darauf, dass Daten übertragen oder veröffentlicht werden, ein beliebiges oder mehrere beliebige der übertragenden oder veröffentlichenden Systeme erwarten können, mindestens eine Reaktion in Form einer Bestätigung zu empfangen. Ein beliebiges oder beliebige mehrere der übertragenden oder veröffentlichenden Systeme können einen Wiederholungsmechanismus beinhalten, sollte eine derartige Reaktion nicht innerhalb einer vorbestimmten Zeit nach dem Übertragen oder Veröffentlichen von Daten empfangen werden.
Die Indizes (I)-(K) veranschaulichen eine andere Ausführungsform. Bei Index (I) kann der nichtflüchtige Speicher, der zum Speichern der Protokolle der TCU 104 vorgesehen ist, voll oder beinahe voll werden. Nach diesem Ereignis und/oder periodisch kann die Protokolliereinrichtung 124 bei Index (J) die gespeicherten TCU-Protokolle automatisch dem Datenbroker 108 gegenüber veröffentlichen. Die veröffentlichten Protokolle können ein oder mehrere Themen beinhalten, die die Inhalte der Protokolle beschreiben. Bei Index (K) kann der Datenbroker 108 den Diagnoseserver 110 als Abonnenten von einem oder mehreren Themen feststellen, die den veröffentlichten Protokollen zugeordnet sind, und kann die Protokolle auf Grundlage der Abonnements per Push an den Diagnoseserver 110 übertragen.
Die Indizes (L)-(O) veranschaulichen eine andere Ausführungsform, bei der TCU-Störungsprotokolle durch den Diagnoseserver 110 bei Bedarf von der TCU 104 angefordert werden. Bei Index (L) kann der Diagnoseserver 110 eine Protokollanforderung dem Datenbroker 108 gegenüber veröffentlichen. Insbesondere kann ein Benutzer über die GUI des Diagnoseservers 110 ein oder mehrere Protokolle von der TCU 104 anfordern. Danach kann der Datenbroker 108 feststellen, dass die TCU 104 Abonnent von derartigen Anforderungen ist, wie etwa auf Grundlage eines in der Anforderung enthaltenen Themas. Bei Index (M) kann der Datenbroker 108 die Anforderung per Push an die TCU 104 übertragen. Als Reaktion darauf, dass die Anforderung empfangen wird, kann die TCU 104 bei Index (N) das angeforderte eine oder die angeforderten mehreren Protokolle dem Datenbroker 108 gegenüber veröffentlichen. Bei Index (O) kann der Datenbroker 108 die angeforderten Protokolle an den Diagnoseserver 110 übertragen, um die Anforderung zu erfüllen, wie etwa auf Grundlage von einem oder mehreren zugeordneten Themen, die mit den Protokollen übertragen werden, die der Diagnoseserver 110 abonniert hat.
Die Indizes (P)-(S) veranschaulichen eine Ausführungsform des Prozesses 200, nachdem protokollierte TCU-Daten durch den Diagnoseserver 110 empfangen worden sind. Bei Index (P) kann der Diagnoseserver 110 eine Fehlerbehebung für eine TCU-Störung erzeugen, die in den protokollierten TCU-Daten enthalten ist. Zum Beispiel kann der Diagnoseserver 110 die Fehlerbehebungsdatenbank 111 auf Grundlage der TCU-Störung abfragen, um eine Lösung für die Störung festzustellen, wie etwa ein Software-Patch, eine Firmware-Aktualisierung etc. Alternativ oder in dem Fall, dass auf keine vorbestimmte Lösung zugegriffen werden kann, kann der Diagnoseserver 110 dazu konfiguriert sein, dynamisch eine Lösung für die Störung zu erzeugen. Zusätzlich oder alternativ kann ein Benutzer unter Verwendung einer GUI des Diagnoseservers 110 eine Lösung erzeugen oder hochladen.
Bei Index (Q) kann der Diagnoseserver 110 die ausgewählte Fehlerbehebung dem Datenbroker 108 gegenüber veröffentlichen. Bei Index (R) kann der Datenbroker 108 feststellen, dass die TCU 104 Abonnent eines zugeordneten Themas ist, das mit der Fehlerbehebung übertragen wird, und kann die Fehlerbehebung per Push an die TCU 104 übertragen. Bei Index (S) kann die TCU 104 die Fehlerbehebung anwenden, wie etwa durch Installieren der Firmware-Aktualisierung etc.
Zum Beispiel können die durch den Diagnoseserver 110 empfangenen protokollierten TCU-Daten eine TCU-Komponentenstörung feststellen. Dementsprechend der Diagnoseserver 110 als Reaktion darauf, dass die TCU-Protokolldaten empfangen werden, dazu konfiguriert sein, eine Fehlerbehebung, wie etwa eine Firmware-Aktualisierung, aus der Fehlerbehebungsdatenbank 111 festzustellen. Als Reaktion darauf, dass die Firmware-Aktualisierung empfangen wird, kann die TCU 104 dazu konfiguriert sein, die Firmware-Aktualisierung auf der TCU 104 zu installieren.
Als ein anderes Beispiel können die durch den Diagnoseserver 110 empfangenen protokollierten TCU-Daten eine Mobilfunknetzwerkstörung feststellen, wie etwa eine langsamere Mobilfunknetzwerkverbindung als erwartet. Dementsprechend kann der Diagnoseserver 110 als Reaktion darauf, dass die protokollierten TCU-Daten empfangen werden, dazu konfiguriert sein, eine Fehlerbehebung in Form von Computeranweisungen festzustellen, um ein anderes Mobilfunknetzwerk zu verwenden, dessen Auswahl auf einem geografischen Standort des Fahrzeugs 102 beruhen kann, der in den empfangenen protokollierten TCU-Daten enthalten ist. Als Reaktion darauf, dass die Fehlerbehebung empfangen wird, kann die TCU 104 dazu konfiguriert sein, für eine bessere Mobilfunknetzwerkverbindung das andere Mobilfunknetzwerk zu verwenden.
Im Allgemeinen können die Routinen, die ausgeführt werden, um die Ausführungsformen der Erfindung umzusetzen, seien sie als Teil eines Betriebssystems oder einer konkreten Anwendung, einer konkreten Komponente, eines konkreten Programms, eines konkreten Objekts, eines konkreten Moduls oder einer konkreten Anweisungsfolge oder auch als Untermenge davon umgesetzt, hier als „Computerprogrammcode“ oder einfach „Programmcode“ bezeichnet werden. Programmcode umfasst typischerweise computerlesbare Anweisungen, die sich zu verschiedenen Zeitpunkten in verschiedenen Arbeitsspeicher- und Datenspeichervorrichtungen in einem Computer befinden und die, wenn sie durch einen oder mehrere Prozessoren in einem Computer ausgelesen und ausgeführt werden, diesen Computer dazu veranlassen, die notwendigen Abläufe durchzuführen, um Abläufe und/oder Elemente auszuführen, in denen die verschiedenen Aspekte der Ausführungsformen der Erfindung umgesetzt sind. Computerlesbare Programmanweisungen zum Ausführen von Abläufen der Ausführungsformen der Erfindung können zum Beispiel Assemblersprache oder entweder Quellcode oder Objektcode, der in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben ist, sein.
Verschiedenartiger hier beschriebener Programmcode kann auf Grundlage der Anwendung gekennzeichnet sein, in der er in konkreten Ausführungsformen der Erfindung umgesetzt ist.
Es versteht sich jedoch, dass jegliche spezielle Programmnomenklatur im Anschluss lediglich der Annehmlichkeit halber verwendet wird, und somit sollte die Erfindung nicht auf die Verwendung allein in einer konkreten Anwendung beschränkt werden, die durch eine derartige Nomenklatur festgestellt und/oder impliziert wird. Darüber hinaus versteht es sich angesichts der im Allgemeinen unbegrenzten Anzahl von Weisen, auf die Computerprogramme in Routinen, Prozeduren, Verfahren, Modulen, Objekten und dergleichen organisiert sein können, sowie der verschiedenen Weisen, auf die Programmfunktionalität verschiedenen Softwareschichten zugewiesen sein kann, die sich innerhalb eines typischen Computers befinden (z. B. Betriebssysteme, Bibliotheken, APIs, Anwendungen, Applets etc.), dass die Ausführungsformen der Erfindung nicht auf die hier beschriebene konkrete Organisation und Zuweisung von Programmfunktionalität beschränkt sind.
Der in beliebigen der hier beschriebenen Anwendungen/Module umgesetzte Programmcode ist dazu in der Lage, einzeln oder gemeinsam als Programmprodukt in vielfältigen unterschiedlichen Formen verteilt zu sein. Insbesondere kann der Programmcode unter Verwendung eines computerlesbaren Speichermediums verteilt sein, auf dem sich computerlesbare Programmanweisungen befinden, um zu veranlassen, dass ein Prozessor Aspekte der Ausführungsformen der Erfindung ausführt.
Computerlesbare Speichermedien, die grundsätzlich nichttransitorisch sind, können flüchtige und nichtflüchtige sowie austauschbare und nicht austauschbare greifbare Medien beinhalten, die mit einem beliebigen Verfahren oder einer beliebigen Technik zur Speicherung von Informationen wie etwa computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen oder anderen Daten umgesetzt sind. Computerlesbare Speichermedien können ferner RAM, ROM, löschbaren programmierbaren Festwertspeicher (EPROM), elektrisch löschbaren programmierbaren Festwertspeicher (EEPROM), Flash-Speicher oder andere Solid-State-Speichertechnologie, tragbaren Compact-Disc-Festwertspeicher (CD-ROM) oder anderen optischen Speicher, Magnetkassetten, Magnetband, Magnetplattenspeicher oder andere Magnetspeichervorrichtungen oder ein beliebiges anderes Medium, das zum Speichern der gewünschten Informationen verwendet werden kann und das durch einen Computer ausgelesen werden kann, beinhalten. Ein computerlesbares Medium sollte nicht als transitorische Signale an sich ausgelegt werden (z. B. Funkwellen oder andere sich ausbreitende elektromagnetische Wellen, sich durch ein Ausbreitungsmedium wie etwa einen Wellenleiter ausbreitende elektromagnetische Wellen oder durch einen Draht übertragene elektrische Signale). Computerlesbare Programmanweisungen können von einem computerlesbaren Speichermedium auf einen Computer, eine andere Art von programmierbarer Datenverarbeitungseinrichtung oder eine andere Vorrichtung oder über ein Netzwerk auf einen externen Computer oder eine externe Speichervorrichtung heruntergeladen werden.
Auf einem computerlesbaren Medium gespeicherte computerlesbare Programmanweisungen können dazu verwendet werden, einen Computer, eine andere Art von programmierbarer Datenverarbeitungseinrichtung oder eine andere Vorrichtung dazu anzuleiten, auf eine spezielle Weise zu funktionieren, sodass die auf dem computerlesbaren Medium gespeicherten Anweisungen einen Herstellungsartikel erzeugen, zu dem Anweisungen gehören, mit denen die in den Ablaufdiagrammen, Sequenzdiagrammen und/oder Blockdiagrammen angegebenen Funktionen, Handlungen und/oder Abläufe umgesetzt werden. Die Computerprogrammanweisungen können einem oder mehreren Prozessoren eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungseinrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die Anweisungen, die über den einen oder die mehreren Prozessoren ausgeführt werden, veranlassen, dass eine Reihe von Berechnungen durchgeführt wird, um die in den Ablaufdiagrammen, Sequenzdiagrammen und/oder Blockdiagrammen angegebenen Funktionen, Handlungen und/oder Abläufe umzusetzen.
In gewissen alternativen Ausführungsformen können die in den Ablaufdiagrammen, Sequenzdiagrammen und/oder Blockdiagrammen angegebenen Funktionen, Handlungen und/oder Abläufe in Übereinstimmung mit Ausführungsformen der Erfindung neu angeordnet, seriell verarbeitet und/oder gleichzeitig verarbeitet werden. Außerdem können beliebige der Ablaufdiagramme, Sequenzdiagramme und/oder Blockdiagramme in Übereinstimmung mit Ausführungsformen der Erfindung mehr oder weniger Blöcke beinhalten, als veranschaulicht sind.
Die hier verwendete Terminologie dient ausschließlich dem Zweck der Beschreibung spezieller Ausführungsformen und ist nicht dazu beabsichtigt, die vorliegende Offenbarung einzuschränken. Im hier verwendeten Sinne sollen die Einzahlformen „ein“, „eine“ sowie „der“, „die“, „das“ auch die Mehrzahlformen beinhalten, es sei denn, der Kontext gibt eindeutig etwas anderes vor. Es versteht sich ferner, dass die Ausdrücke „umfasst“ und/oder „umfassend“, wenn sie in dieser Beschreibung verwendet werden, das Vorhandensein genannter Merkmale, ganzer Zahlen, Schritte, Abläufe, Elemente und/oder Komponente angeben, aber nicht das Vorhandensein oder die Hinzufügung eines bzw. einer oder mehrerer anderer Merkmale, ganzer Zahlen, Schritte, Abläufe, Elemente, Komponenten und/oder Gruppen davon ausschließt. Darüber hinaus ist beabsichtigt, dass die Ausdrücke „beinhaltet“, „aufweisend“, „aufweist“, „mit“, „besteht aus“ oder Varianten davon, sofern derartige Ausdrücke entweder in der detaillierten Beschreibung oder den Patentansprüchen verwendet werden, auf ähnliche Weise einschließend sind wie der Ausdruck „umfassend“.
Wenngleich die gesamte Erfindung durch eine Beschreibung von verschiedenen Ausführungsformen veranschaulicht worden ist und wenngleich diese Ausführungsformen in beträchtlicher Ausführlichkeit beschrieben worden sind, ist es nicht die Absicht des Anmelders, den Umfang der beigefügten Patentansprüche zu beschränken oder in jeglicher Form auf eine derartige Ausführlichkeit zu begrenzen. Zusätzliche Vorteile und Modifikationen erschließen sich dem Fachmann ohne Weiteres. Deshalb ist die Erfindung in ihren breiteren Aspekten nicht auf die konkreten Einzelheiten, repräsentativen Einrichtungen und Verfahren sowie veranschaulichenden Beispiele begrenzt, die gezeigt und beschrieben sind. Dementsprechend können Abweichungen von derartigen Einzelheiten vorgenommen werden, ohne vom Geist oder Umfang des allgemeinen Erfindungsgedankens des Anmelders abzuweichen.

Claims

Fahrzeug, umfassend: eine Telematiksteuereinheit (telematics control unit - TCU), die dazu konfiguriert ist, periodisch in einem Protokoll Drahtlosaktivitätsdaten in Bezug auf eine Prozedur zur Authentifizierung, Verbindung, Signalisierung, Trennung und Übergabe der TCU aufzuzeichnen, um einen oder mehrere Fahrzeugferndienste bereitzustellen, und als Reaktion darauf, dass anhand der protokollierten Daten eine Mobilfunkstörung detektiert wird, mindestens einen Teil des Protokolls, der der Mobilfunkstörung entspricht, für einen Ferndiagnoseserver drahtlos außer Bord des Fahrzeugs zu übertragen.
Fahrzeug nach Anspruch 1, wobei der übertragene mindestens eine Teil des Protokolls ferner Daten beinhaltet, die sich auf den Betrieb des TCU beziehen und durch die TCU erhoben werden, nachdem die Mobilfunkstörung detektiert wird.
Fahrzeug nach Anspruch 1, wobei die periodisch aufgezeichneten Drahtlosaktivitätsdaten erste Daten, die sich auf eine Aktivität zur Authentifizierung, Verbindung, Signalisierung, Trennung oder Übergabe der TCU beziehen, die der Mobilfunkstörung entspricht, und zweite Daten, die sich auf eine Aktivität zur Authentifizierung, Verbindung, Signalisierung, Trennung oder Übergabe der TCU beziehen, die nicht der Mobilfunkstörung zugeordnet ist, beinhalten.
Fahrzeug nach Anspruch 3, wobei das übertragene Protokoll die ersten Daten und nicht die zweiten Daten beinhaltet und die TCU ferner dazu konfiguriert ist, als Reaktion darauf, dass die Mobilfunkstörung detektiert wird, die zweiten Daten zu verwerfen, ohne die zweiten Daten außer Bord des Fahrzeugs zu übertragen.
Fahrzeug nach Anspruch 3, wobei das Protokoll ein erstes Protokoll der TCU ist und die TCU ferner dazu konfiguriert ist, als Reaktion auf eine Komponentenstörung der TCU, Daten, die die Komponentenstörung angeben, in einem zweiten Protokoll der TCU aufzuzeichnen, und mindestens einen Teil des ersten Protokolls und des zweiten Protokolls für den Ferndiagnoseserver drahtlos außer Bord des Fahrzeugs zu übertragen.
Fahrzeug nach Anspruch 5, wobei die TCU ferner dazu konfiguriert ist, als Reaktion auf die Komponentenstörung, Daten in dem ersten Protokoll festzustellen, die einem Zeitstempel innerhalb eines vordefinierten Zeitraums unmittelbar vor der Komponentenstörung zugeordnet sind, und die festgestellten Daten für den Ferndiagnoseserver drahtlos außer Bord des Fahrzeugs zu übertragen.
Fahrzeug nach Anspruch 6, wobei die TCU ferner dazu konfiguriert ist, als Reaktion auf die Komponentenstörung Daten in dem ersten Protokoll, die nicht einem Zeitstempel innerhalb des vordefinierten Zeitraums unmittelbar vor der Komponentenstörung zugeordnet sind, zu verwerfen, wobei die verworfenen Daten nicht für den Ferndiagnoseserver außer Bord des Fahrzeugs übertragen werden.
Verfahren, umfassend, durch eine Telematiksteuereinheit (TCU) eines Fahrzeugs, periodisches Aufzeichnen von Drahtlosaktivitätsdaten in Bezug auf eine Prozedur zur Authentifizierung, Verbindung, Signalisierung, Trennung und Übergabe der TCU in einem Protokoll, um einen oder mehrere Fahrzeugferndienste bereitzustellen, und als Reaktion darauf, dass anhand des Protokolls eine Mobilfunkstörung detektiert wird, drahtloses Übertragen von mindestens einem Teil des Protokolls, der der Mobilfunkstörung entspricht, für einen Ferndiagnoseserver außer Bord des Fahrzeugs.
Verfahren nach Anspruch 8, wobei das Protokoll ein erstes Protokoll der TCU ist, und ferner umfassend, als Reaktion auf eine Komponentenstörung der TCU, Protokollieren von Daten, die die Komponentenstörung angeben, in einem zweiten Protokoll, und drahtloses Übertragen von mindestens einem Teil des ersten Protokolls und des zweiten Protokolls für den Ferndiagnoseserver außer Bord des Fahrzeugs.
Verfahren nach Anspruch 9 oder Fahrzeug nach Anspruch 5, wobei die Komponentenstörung einen Diagnosefehlercode, eine fehlgeschlagene Aktualisierung mittels Firmware Over-the-Air, einen Eingabe-/Ausgabefehler, einen Fehler bei der globalen Positionsbestimmung, Verbindungsprobleme bei einem Nachrichtenbroker oder einen fehlgeschlagenen Lese-/Schreibvorgang bei einem Speicher beinhaltet.
Verfahren nach Anspruch 8, wobei die Mobilfunkstörung eine langsame Mobilfunknetzwerkverbindung ist, und ferner umfassend: als Reaktion darauf, dass eine Fehlerbehebung, die dem Protokoll entspricht, von dem Ferndiagnoseserver empfangen wird, die Anweisungen für die TCU definiert, ein anderes Mobilfunknetzwerk zu verwenden, Verbinden mit dem anderen Mobilfunknetzwerk.
Verfahren nach Anspruch 8, wobei Übertragen des mindestens einen Teils des Protokolls außer Bord des Fahrzeugs Übertragen des Protokolls und eines zugeordneten Themas außer Bord des Fahrzeugs an einen Nachrichtenbroker umfasst, wobei der Nachrichtenbroker als Reaktion darauf, dass er das Protokoll empfängt, dazu konfiguriert ist, als Reaktion darauf, dass er den Ferndiagnoseserver als einen Abonnenten des Themas feststellt, das Protokoll an den Ferndiagnoseserver zu übertragen.
Verfahren nach Anspruch 12, ferner umfassend, als Reaktion darauf, dass eine Bestätigung von dem Datenbroker empfangen wird, bevor das Protokoll durch den Ferndiagnoseserver empfangen wird, Löschen von Inhalten des Protokolls von der TCU.
Verfahren nach Anspruch 8, ferner umfassend, als Reaktion auf eine fehlgeschlagene Übertragung, Einfügen des mindestens einen Teils des Protokolls in einen Cache für Protokolldaten zu fehlgeschlagenen Übertragungen, und als Reaktion darauf, dass die Datengröße der Protokolldaten zu fehlgeschlagenen Übertragungen in dem Cache einen Schwellenwert übersteigt, drahtloses erneutes Versuchen, den mindestens einen Teil des Protokolls für den Ferndiagnoseserver außer Bord des Fahrzeugs zu übertragen.
Diagnoseserver, umfassend: einen Prozessor, der geografisch von einem Fahrzeug entfernt ist, das eine Telematiksteuereinheit (TCU) beinhaltet, die dazu konfiguriert ist, ein erstes Protokoll, das für Drahtlosaktivität der TCU spezifisch ist, und ein zweites Protokoll, das für Komponentenstörungen der TCU spezifisch ist, zu erzeugen, wobei der Prozessor dazu konfiguriert ist, eine Anforderung für das erste Protokoll zu übertragen, wobei als Reaktion auf die Anforderung das erste Protokoll und nicht das zweite Protokoll durch den Prozessor empfangen wird.