-
TECHNISCHES GEBIET
-
Aspekte der Offenbarung betreffen im Allgemeinen einen cloud-basierten Energiehaushaltsmanager für Konnektivitätsfunktionen.
-
ALLGEMEINER STAND DER TECHNIK
-
Diagnosedaten eines Autos, wie etwa Diagnose-Fehlercodes (Diagnostic Trouble Code - DTC) bilden kompakte informative Nachrichten. Diagnosedaten wurden konzipiert, um zu ermöglichen, dass Fahrzeugsteuerungen einen Systemfehler und/oder eine Notwendigkeit einer Reparatur anzugeben. Auch wenn der DTC für den Zündungszyklus, in dem der Fehler auftrat, in einem ,aktiven‘ oder ,bestätigten‘ Zustand ist, kehren die meisten DTC dann für eine Anzahl von Zündungszyklen zu einem ,Verlaufs-, oder ,Auslagerungs'-Zustand zurück, so dass ein Nachweis des Fehlers weiterhin verfügbar ist, auch wenn das Fahrzeug Wochen nach dem Fehler von einem Techniker überprüft wird.
-
KURZDARSTELLUNG
-
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet ein System einen Speicher, der dazu konfiguriert ist, Diagnosedaten, Kadenzauslöserkriterien, die eine periodische Übertragung der Diagnosedaten definieren, und Prioritätsauslöserkriterien, die eine Außerkadenzübertragung der Diagnosedaten definieren, zu verwalten; und einen Prozessor, der programmiert ist, um periodisch Diagnosedaten, die sich während einer vorherigen Kadenzübertragung angesammelt haben, an einen Remote-Server aufgrund der Kadenzauslöserkriterien zu senden und um Außerkadenzdiagnosedaten, die die Prioritätsauslöserkriterien für den Server erfüllen, an den Remote-Server zu senden.
-
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet ein Verfahren Speichern von Diagnose-Fehlercode (DTC)-Daten, die über einen Fahrzeugbus von anderen Steuerungen empfangen werden, in einer Telematiksteuerung; Senden der DTC-Daten, die die Prioritätsauslöserkriterien erfüllen, von der Telematiksteuerung an den Remote-Server; Löschen der gesendeten DTC-Daten aufgrund Prioritätsauslöserkriterien; periodisches Senden aller gespeicherten DTC-Daten von der Steuerung an einen Remote-Server aufgrund der Kadenzauslöserkriterien; und Löschen der gesendeten DTC-Daten aufgrund der Kadenzauslöserkriterien.
-
In einer oder mehreren veranschaulichenden Ausführungsformen beinhaltet ein nichttransitorisches computerlesbares Medium Anweisungen, die bei Ausführung durch einen Prozessor einer Telematiksteuerung die Telematiksteuerung dazu veranlassen, Diagnose-Fehlercode (DTC)-Daten, die über einen Fahrzeugbus von anderen Steuerungen empfangen werden, zu speichern; die DTC-Daten, die die Prioritätsauslöserkriterien erfüllen, von der Telematiksteuerung an den Remote-Server zu senden; die gesendeten DTC-Daten aufgrund der Prioritätsauslöserkriterien zu löschen; periodisch alle gespeicherten DTC-Daten von der Steuerung an einen Remote-Server aufgrund Kadenzauslöserkriterien zu senden; und die gesendeten DTC-Daten aufgrund der Kadenzauslöserkriterien zu löschen.
-
Figurenliste
-
- 1 veranschaulicht ein beispielhaftes System, das eine effiziente verbundene Fahrzeugdiagnosedatenüberwachung implementiert; und
- 2 veranschaulicht einen beispielhaften Prozess für die effiziente verbundene Fahrzeugdiagnosedatenüberwachung.
-
DETAILLIERTE BESCHREIBUNG
-
Wie erforderlich werden hierin detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; dabei versteht es sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen ausgeführt sein kann. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können vergrößert oder verkleinert dargestellt sein, um Details bestimmter Komponenten zu zeigen. Dementsprechend sind hier offenbarte spezifische strukturelle und funktionelle Details nicht als einschränkend auszulegen, sondern lediglich als repräsentative Grundlage, um einen Fachmann eine vielfältige Verwendung der vorliegenden Erfindung zu lehren.
-
Der DTC-Standard wurde vor der Allgegenwart verbundener Fahrzeuge geschaffen. Mit den verbundenen Fahrzeugen können nun DTC-Daten erfasst und bei jedem Zündungszyklus oder sogar mehrere Male pro Zündungszyklus übertragen werden. Diese Fähigkeit schafft eine Chance und eine Herausforderung. Wenn OEM oder Drittanbieter für Konnektivität ihre Systeme konzipieren, um DTC bei jedem Zündungszyklus zu erfassen und zu senden, kann die Menge an Daten, die erfasst wird, hinsichtlich Größe und Wiederholung überwältigend werden. Wenn das Konnektivitätssystem alternativ konzipiert ist, um nur ,aktive‘/,bestätigte‘ DTC zu erfassen, dann können wichtige Informationen verloren gehen (z. B. Verlaufs-DTC).
-
Somit können einige Vorteile der allgegenwärtigen Konnektivität verloren gehen, da das ,Rauschen‘ in den Daten aus einer sehr häufigen Erfassung von ,historischen‘ DTC die Effektivität eines frühen Warn-/Qualitätssignals reduzieren kann, das durch die weniger häufig auftretenden ,aktiven‘/,bestätigten‘ DTC bereitgestellt werden.
-
Ein effektives verbundenes Fahrzeugdiagnosedaten-Überwachungssystem kann genutzt werden, um diese Probleme mit zu viel oder zu wenig Daten, die erfasst werden, mittels eines Hybridansatzes anzugehen. Dieser Ansatz führt eine regelmäßige Erfassung von DTC-Daten mit fahrzeuginterner Logik ein, um Daten bei zwei Szenarien effizient zu senden. Bei einem ersten Szenario, z. B. ein Zeitszenario, wird eine regelmäßige Kadenz der DTC-Übertragung auf Grundlage einer Zeit oder Anzahl von Zündungszyklen definiert. Bei einem Beispiel könnte ein Zeitszenario Datenübertragung zu jeder vordefinierten Periode (z. B. 30 Tage, 40 Zündungszyklen usw.) beinhalten, ungeachtet des Status der erfassten DTC. Bei einem zweiten Szenario, z. B. einem Auslöserszenario, kann bzw. können ein oder mehrere Auslöser für die Übertragung von Daten gemäß DTF-Status definiert werden. Bei einem Beispiel kann ein Auslöserszenario Logik beinhalten, die als Reaktion auf Erfassung eines ,aktiven‘ oder ,bestätigten‘ DTC eine DTC-Übertragung auslösen, so dass diese an einen Remote-Server gesendet wird. Dies kann ermöglichen, dass auch andere DTC-Statusauslöser eingerichtet werden können, wie etwa Übertragung von DTC-Daten, wenn ein DTC in einem Status ,unerledigt‘ erfasst wird.
-
Die zwei Szenarien, die zusammenarbeiten, erreichen zwei Ziele. Erstens sind regelmäßige Übertragungen erforderlich, um einen regelmäßigen Heartbeat der Daten für Analysezwecke zu beziehen und die Entwicklung der DTC im Status ,Verlauf‘/,Auslagerung‘ zu überwachen. Zweitens ermöglichen Datenübertragungen, die durch den DTC-Status, wie etwa ,aktiv‘/,bestätigt‘, ausgelöst werden, dass sich das System aller ,aktiven‘ DTC in dem Zündungszyklus bewusst ist, in dem der Fehler bestätigt wurde.
-
Da die ,aktiven‘ DTC relativ selten und die wichtigsten DTC-Informationen sind, die von einem verbundenen Fahrzeug zu übertragen sind, dünnt dieser duale Ansatz die Daten auf nur die wertvollsten Diagnoseinformationen aus. Zusätzlich reduziert dies die von verbundenen Fahrzeugen übertragenen Daten durch Bereitstellen einer weniger häufigen, regelmäßigen DTC-Datenerfassung von ,Verlaufs'-DTC. Weitere Aspekte der Offenbarung werden nachstehend genauer beschrieben.
-
1 veranschaulicht ein beispielhaftes System 100, das eine effiziente verbundene Fahrzeugdiagnosedatenüberwachung implementiert. Wie veranschaulicht, beinhaltet das Fahrzeug 102 eine Vielzahl von Fahrzeugsteuerungen 104 in Kommunikation über einen oder mehrere Fahrzeugbusse 106. Das System 100 beinhaltet zudem einen Fahrzeugdatenserver 122, der dazu konfiguriert ist, Diagnosedaten 120, die von verschiedenen Fahrzeugen 102 empfangen werden, zu verwalten. Das Fahrzeug 102 beinhaltet ferner eine Telematiksteuereinheit (telematics control unit - TCU) 108, die dazu konfiguriert ist, Diagnosedaten 120 einschließlich Diagnoseinformationen an den Fahrzeugdatenserver 122 zu senden. Die TCU 108 kann eine Diagnoseanwendung 118 nutzen, die in der TCU 108 installiert ist, um eine regelmäßige Kadenz der Diagnosedaten 120 zu senden sowie um ausgelöste Diagnosedaten 120 als Reaktion darauf, dass Auslöserkriterien 124 erfüllt wurden, zu senden. Es ist anzumerken, dass es sich bei dem System 100 lediglich um ein Beispiel handelt und andere Anordnungen oder Kombinationen von Elementen verwendet werden können.
-
Bei dem Fahrzeug 102 kann es sich um verschiedene Arten von Automobilen, Softroadern (crossover utility vehicle - CUV), Geländelimousinen (sport utility vehicle - SUV), Lastwagen, Wohnmobilen (recreational vehicle - RV), Booten, Flugzeugen oder anderen mobilen Maschinen zum Befördern von Personen oder Transportieren von Gütern handeln. In vielen Fällen kann das Fahrzeug 102 von einem Verbrennungsmotor angetrieben werden. Als weitere Möglichkeit kann das Fahrzeug 102 ein Hybridelektrofahrzeug (hybrid electric vehicle - HEV) sein, das sowohl durch einen Verbrennungsmotor als auch durch einen oder mehrere Elektromotoren angetrieben wird, wie zum Beispiel 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 Fähigkeiten des Fahrzeugs 102 variieren. Als weitere Möglichkeiten können die Fahrzeuge 102 unterschiedliche Fähigkeiten in Bezug auf die Fahrgastkapazität, Schleppfähigkeit und -kapazität und das Lagervolumen aufweisen. Für Eigentums-, Bestands- und andere Zwecke können die Fahrzeuge 102 mit einzigartigen Kennungen, wie etwa VIN (vehicle identification number = Fahrgestellnummer), verknüpft sein.
-
Das Fahrzeug 102 kann eine Vielzahl von Steuerungen 104 beinhalten, die dazu konfiguriert ist, unterschiedliche Funktionen des Fahrzeugs 102 bei einem Antrieb durch die Fahrzeugbatterie und/oder den Fahrzeugantrieb durchzuführen und zu verwalten. Wie dargestellt, werden die beispielhaften Fahrzeugsteuerungen 104 als einzelne Steuerungen 104-A bis 104-G dargestellt. Die Fahrzeugsteuerungen 104 können jedoch physische Hardware, Firmware und/oder Software gemeinsam nutzen, so dass die Funktionen mehrerer Steuerungen 104 in einer einzigen Steuerung 104 zusammengefasst werden können und die Funktionen von derartigen unterschiedlichen Steuerungen 104 über eine Vielzahl von Steuerungen 104 verteilt sein können.
-
Nicht einschränkende Beispiele einiger Fahrzeugsteuerungen 104: eine Antriebsstrangsteuerung 104-A kann dazu konfiguriert sein, eine Steuerung der Motorbetriebskomponenten (z. B. Leerlaufsteuerkomponenten, Kraftstoffzufuhrkomponenten, Emissionssteuerkomponenten usw.) bereitzustellen und zum Überwachen des Status solcher Motorbetriebskomponenten (z. B. Status der Motorcodes); eine Karosseriesteuerung 104-B kann dazu konfiguriert sein, verschiedene Leistungssteuerfunktionen zu verwalten, wie etwa Außenbeleuchtung, Innenbeleuchtung, schlüsselloser Zutritt, Fernstart und Statusverifizierung des Zugangspunkts (z. B. Schließstatus von Motorhaube, Türen und/oder Kofferraum des Fahrzeugs 102); eine Funksendeempfängersteuerung 104-C kann dazu konfiguriert sein, mit Schlüsselanhängern, mobilen Vorrichtungen oder anderen lokalen Vorrichtungen des Fahrzeugs 102 zu kommunizieren; eine Entertainmentsteuerung 104-D kann dazu konfiguriert sein, Sprachbefehl und Bluetooth-Schnittstellen mit dem Fahrer und vom Fahrer getragenen Vorrichtungen zu unterstützen; eine Klimaanlagenverwaltungssteuerung 104-E kann dazu konfiguriert sein, eine Steuerung von Heizungs- und Kühlungssystemkomponenten bereitzustellen (z. B. Verdichterkupplung, Lüftergebläse, Temperatursensoren usw.); eine Steuerung 104-F eines globalen Positionsbestimmungssystems (GPS) kann dazu konfiguriert sein, Fahrzeugpositionsdaten bereitzustellen; und eine Steuerung 104-G einer Mensch-Maschine-Schnittstelle (human-machine interface - HMI) kann dazu konfiguriert sein, Benutzereingaben über verschiedene Tasten oder andere Bedienelemente zu empfangen sowie Fahrzeugstatusinformationen für einen Fahrer bereitzustellen, wie etwa Kraftstoffstandinformationen, Motorbetriebstemperaturinformationen und aktuelle Position des Fahrzeugs 102.
-
Der Fahrzeugbus 106 kann unterschiedliche Verfahren der Kommunikation beinhalten, die zwischen den Fahrzeug-ECU 104 sowie zwischen der TCU 108 und den Fahrzeug-ECU 104 verfügbar sind. Als einige nicht beschränkende Beispiele kann der Fahrzeugbus 106 ein oder mehrere Fahrzeugsteuergerätenetzwerke (CAN), ein Ethernet-Netzwerk oder ein mediengebundenes Systemübertragungs-(MOST - Media Oriented System Transport)-Netzwerk beinhalten. Weitere Aspekte der Auslegung und Anzahl von Fahrzeugbussen 106 sind nachstehend ausführlich weiter beschrieben.
-
Die TCU 108 kann Netzwerkhardware umfassen, die dazu konfiguriert ist, die Kommunikation zwischen den Fahrzeug-ECU 104 und sonstigen Vorrichtungen des Systems 100 zu ermöglichen. Zum Beispiel kann die TCU 108 ein Mobilfunkmodem 110 beinhalten oder anderweitig darauf zugreifen, das dazu konfiguriert ist, die Kommunikation mit dem Wide Area Network 112 zu ermöglichen. Das Wide Area Network 112 kann ein oder mehrere miteinander verbundene Kommunikationsnetzwerke, wie etwa als einige nicht einschränkende Beispiele das Internet, ein Kabelfernsehverteilungsnetzwerk, ein Satellitenverbindungsnetzwerk, ein Local Area Network, ein Wide Area Network und ein Telefonnetzwerk, beinhalten. Als weiteres Beispiel kann die TCU 108 eine oder mehrere einer Bluetooth-, WiFi- und drahtgebundenen USB-Netzwerkkonnektivität nutzen, um Kommunikation mit dem Wide Area Network 112 über die mobile Vorrichtung des Benutzers zu ermöglichen.
-
Die TCU 108 kann ferner verschiedene Arten von Rechenvorrichtungen zur Unterstützung der Leistung der hierin beschriebenen Funktionen der TCU 108 beinhalten. Bei einem Beispiel kann die TCU 108 einen oder mehrere Prozessoren 114, die dazu konfiguriert sind, Computeranweisungen auszuführen, und ein Speichermedium 116, auf dem die computerausführbaren Anweisungen und/oder Daten verwaltet werden können, beinhalten. Ein computerlesbares Speichermedium (auch als prozessorlesbares Medium oder Speicher 116 bezeichnet) beinhaltet ein beliebiges nichttransitorisches (z. B. physisches) Medium, das an der Bereitstellung von Daten (z. B. Anweisungen) beteiligt ist, die von einem Computer (z. B. von dem/den Prozessor(en)) gelesen werden können. Im Allgemeinen empfängt ein Prozessor 114 Anweisungen und/oder Daten, z. B. vom Speicher 116 usw., an einen Arbeitsspeicher und führt die Anweisungen unter Verwendung der Daten aus, wodurch sie einen oder mehrere Prozesse durchführen, darunter einen oder mehrere der hierin beschriebenen Prozesse. Computerausführbare Anweisungen können von Computerprogrammen kompiliert oder ausgewertet werden, die unter Verwendung einer Reihe von Programmiersprachen und/oder - technologien erstellt wurden, einschließlich unter anderem und entweder für sich oder in Kombination Java, C, C++, C#, Fortran, Pascal, Visual Basic, Python, Java Script, Perl, PL/SQL usw.
-
Die TCU 108 kann dazu konfiguriert sein, eine oder mehrere Schnittstellen zu beinhalten, von denen aus Fahrzeuginformationen gesendet und empfangen werden können. Bei einem Beispiel kann die TCU 108 dazu konfiguriert sein, die Erfassung von DTC-Daten und/oder anderen Fahrzeuginformationen von den Fahrzeug-ECU 104, die mit dem einen oder den mehreren Fahrzeugbussen 106 verbunden sind, zu ermöglichen. Diese erfassten Informationen können als Diagnosedaten 120 bezeichnet werden. Die TCU 108 kann die erfassten Diagnosedaten 120 in den Speicher 116 der TCU 108 oder, bei anderen Beispielen, in einen anderen Speicher in Kommunikation mit der TCU 108 speichern. Die Fahrzeuginformationen, die durch die TCU 108 abgerufen werden, können, als einige nicht einschränkende Beispiele, Gaspedalposition, Lenkradwinkel, Fahrzeuggeschwindigkeit, Fahrzeugposition (z. B. GPS-Koordinaten usw.), eindeutige Fahrzeugkennung (z. B. die VIN), Motorumdrehungen pro Minute (U/min) und Fahrzeug-HMI-Informationen, wie etwa Lenkradtastendruckinformationen, beinhalten. Somit können die Diagnosedaten 120 erfasste DTC-Informationen und/oder andere Fahrzeuginformationen, die in den Speicher 116 der TCU 108 gespeichert sind, beinhalten.
-
Die Diagnoseanwendung 118 kann eine Anwendung sein, die in dem Speicher 116 der TCU 108 beinhaltet ist. Die Diagnoseanwendung 118 kann Anweisungen beinhalten, die bei Ausführung durch den Prozessor 114 der TCU 108 die TCU 108 veranlassen, periodisch die Informationen der Diagnosedaten 120 von den Steuerungen 104 (z. B. einschließlich der DTC-Informationen) zu erfassen, die Informationen für eine Übertragung zu speichern und die Diagnosedaten 120 über das Wide Area Network 122 an den Fahrzeugdatenserver 112 zu übertragen.
-
Der Fahrzeugdatenserver 122 kann verschiedene Typen von Rechenvorrichtung umfassen, wie etwa eine Computer-Arbeitsstation, einen Server, einen Desktop-Computer, eine virtuelle Serverinstanz, die von einem Großrechner-Server ausgeführt wird, oder ein anderes Rechensystem und/oder eine andere Rechenvorrichtung. Ähnlich wie die TCU 108 beinhaltet der Fahrzeugdatenserver 122 im Allgemeinen einen Arbeitsspeicher, auf dem computerausführbare Anweisungen gespeichert werden können, wobei die Anweisungen von einem oder mehreren Prozessoren (der Übersichtlichkeit wegen nicht gezeigt) ausführbar sind. Solche Anweisungen und andere Daten können unter Verwendung einer Vielzahl computerlesbarer Medien gespeichert werden. Bei einem Beispiel kann der Fahrzeugdatenserver 122 dazu konfiguriert sein, die Diagnosedaten 120, die von der TCU 108 der Fahrzeuge 102 über das Netzwerk 112 empfangen werden, zu verwalten.
-
Die Diagnoseanwendung 118 kann zudem Anweisungen zum Durchführen von Funktionen als Reaktion auf Auslöserkriterien 124 beinhalten. Die Auslöserkriterien 124 können eine oder mehrere Bedingungen beinhalten, die, wenn sie erfüllt sind, verursachen, das zumindest eine Untermenge der Diagnosedaten 120 übertragen wird. Die Auslöserkriterien 124 können zudem Informationen beinhalten, die angeben, welche erfassten Diagnosedaten 120 auf Grundlage der Erfüllung der Bedingung(en) der Auslöserkriterien 124 an den Fahrzeugdatenserver 122 übertragen werden sollen.
-
Die Auslöserkriterien 124 können Kadenzauslöserkriterien 124 beinhalten. Die Kadenzauslöserkriterien 124 können Bedingungen beinhalten, die verursachen, dass der Großteil der erfassten Diagnosedaten 120 übertragen wird. Die Kadenzauslöserkriterien 124 können ein Zeitszenario beinhalten, bei dem bestimmt wird, dass eine Datenübertragung zu jedem vordefinierten Zeitraum vorgenommen wird (z. B. 30 Tage). Zusätzlich oder alternativ können die Kadenzauslöserkriterien 124 ein Zeitszenario beinhalten, bei dem bestimmt wird, dass eine Datenübertragung nach Auftreten einer vordefinierten Anzahl eines konkreten Ereignisses (z. B. 40 Zündungszyklen) vorgenommen wird.
-
Die Auslöserkriterien 124 können auch Prioritätsauslöserkriterien 124 beinhalten. Die Prioritätsauslöserkriterien 124 können Bedingungen beinhalten, die verursachen, dass die Daten, die die Bedingung auslösen, übertragen werden. Zum Beispiel kann bzw. können ein oder mehrere der Auslöserkriterien 124 für die Übertragung von Daten gemäß DTC-Status definiert werden. Als eine Möglichkeit können die Auslöserkriterien 124 als Reaktion auf eine Erfassung eines ,aktiven‘ oder ,bestätigten‘ DTC einen Übertragungsauslöser beinhalten. Als weitere Möglichkeit können die Auslöserkriterien 124 einen Übertragungsauslöser als Reaktion auf einen anderen DTC-Status beinhalten, wie etwa Übertragung der DTC-Daten, wenn ein DTC in einem Status ,unerledigt‘ erfasst wird.
-
Der Fahrzeugdatenserver 122 dazu ferner dazu konfiguriert sein, einen Analysedienst 126 zu verwalten, der dazu konfiguriert ist, die verwalteten Diagnosedaten 120, die von den Fahrzeugen 102 bereitgestellt werden, zu analysieren. Der Analysedienst 126 kann Anweisungen beinhalten, die bei Ausführung durch einen Prozessor des Fahrzeugdatenservers 122 den Fahrzeugdatenserver 122 veranlassen, die Diagnosedaten 120 zu überprüfen und Statistischen bezüglich häufiger DTC oder anderer Bedingungen bereitzustellen.
-
Abwandlungen des Systems 100 sind möglich. Beispielsweise kann die TCU 108, statt oder zusätzlich zu der Verwendung der TCU 108, um Fernkonnektivität zu dem Fahrzeugdatenserver 122 bereitzustellen, Kommunikationsmerkmale eines Modems einer mobilen Vorrichtung des Benutzers, gekoppelt mit der Entertainmentsteuerung 104-D, nutzen, um eine Kommunikation über das Wide Area Network 112 durchzuführen.
-
2 veranschaulicht einen beispielhaften Prozess 200 für die effiziente verbundene Fahrzeugdiagnosedatenüberwachung. Bei einem Beispiel kann der Prozess 200 durch die Diagnoseanwendung 118, die durch die TCU 108 ausgeführt wird, durchgeführt werden.
-
Bei Vorgang 202 erfasst die TCU 108 Diagnosedaten 120. Bei einem Beispiel erfasst die TCU 108 DTC-Daten und/oder anderen Fahrzeuginformationen von den Fahrzeug-ECU 104, die mit dem einen oder den mehreren Fahrzeugbussen 106 verbunden sind. Bei einem weiteren Beispiel erfasst die TCU 108 andere Fahrzeuginformationen, die den einen oder die mehreren Fahrzeugbusse 106 durchlaufen.
-
Bei Vorgang 204 bestimmt die TCU 108, ob eine Kadenzübertragung fällig ist. Bei einem Beispiel kann die TCU 108 bestimmen, ob Kadenzauslöserkriterien 124 erfüllt wurden. Die Kadenzauslöserkriterien 124 können ein Zeitszenario beinhalten, bei dem bestimmt wird, dass eine Datenübertragung zu jedem vordefinierten Zeitraum (z. B. 30 Tage) vorgenommen wird. Zusätzlich oder alternativ können die Kadenzauslöserkriterien 124 ein Zeitszenario beinhalten, bei dem bestimmt wird, dass eine Datenübertragung nach Auftreten einer vordefinierten Anzahl eines festgelegten Ereignisses (z. B. 40 Zündungszyklen) vorgenommen wird. Wenn die Kadenzauslöserkriterien 124 erfüllt wurden, geht die Steuerung weiter zu Vorgang 206. Anderenfalls kehrt die Steuerung zu Vorgang 202 zurück.
-
Bei 206 sendet die TCU 108 den erfassten Verlauf der Diagnosedaten 120. Bei einem Beispiel sendet die TCU 108 die erfassten Diagnosedaten 120 an den Fahrzeugdatenserver 122, ungeachtet des Status der erfassten DTC. Zum Beispiel können die Diagnosedaten 120 DTC beinhalten, die ,aktive‘/,bestätigte‘ DTC sowie auch ,historische‘ DTC sind. Nach Vorgang 206 geht die Steuerung weiter zu Vorgang 208.
-
Bei 208 bestimmt die TCU 108, ob eine ausgelöste Übertragung erforderlich ist. Bei einem Beispiel kann die TCU 108 bestimmen, ob Prioritätsauslöserkriterien 124 erfüllt wurden. Zum Beispiel kann bzw. können ein oder mehrere der Auslöserkriterien 124 für die Übertragung von Daten gemäß DTC-Status definiert sein. Als eine Möglichkeit können die Auslöserkriterien 124 als Reaktion auf eine Erfassung eines ,aktiven‘ oder ,bestätigten‘ DTC einen Übertragungsauslöser beinhalten. Als weitere Möglichkeit können die Auslöserkriterien 124 einen Übertragungsauslöser als Reaktion auf einen anderen DTC-Status beinhalten, wie etwa Übertragung der DTC-Daten, wenn ein DTC in einem Status ,unerledigt‘ erfasst wird. Wenn die Prioritätsauslöserkriterien 124 erfüllt wurden, geht die Steuerung weiter zu Vorgang 210. Anderenfalls kehrt die Steuerung zu Vorgang 202 zurück.
-
Bei 210 sendet die TCU 108 die Informationen, die die Übertragung ausgelöst haben. Bei einem Beispiel sendet die TCU 108 den einen oder die mehreren DTC, die bei Vorgang 208 zur Übertragung ausgelöst wurden, an den Fahrzeugdatenserver 122. Bei anderen Beispielen kann die TCU 108 zusätzlich oder alternativ weitere Informationen an den Fahrzeugdatenserver 122 senden. Beispielsweise kann die TCU 108 ferner zusätzliche gespeicherte Diagnosedaten 120 an den Fahrzeugdatenserver senden 122, die seit der vorherigen Kadenzübertragung erfasst wurden. Nach Vorgang 210 kehrt die Steuerung zu Vorgang 202 zurück.
-
Hierin beschriebene Rechenvorrichtungen, wie etwa die Steuerungen 104, die TCU 108 und der Fahrzeugdatenserver 122, beinhalten im Allgemeinen computerausführbare Anweisungen, von denen die Anweisungen durch eine oder mehrere Rechenvorrichtungen wie die vorstehenden aufgelisteten ausgeführt werden können. Die computerausführbaren Anweisungen, wie diejenigen der Diagnoseanwendung 118, können von Computerprogrammen zusammengestellt oder interpretiert werden, die unter Verwendung einer Vielzahl von Programmiersprachen und/oder -technologien erstellt wurden, darunter unter anderem, entweder einzeln oder in Kombination, Java™, C, C++, C#, Visual Basic, JavaScript, Python, JavaScript, Perl, PL/SQL usw. Im Allgemeinen empfängt ein Prozessor (z. B. ein Mikroprozessor) Anweisungen, z. B. von einem Speicher, einem computerlesbaren Medium usw., und führt diese Anweisungen aus, wodurch er einen oder mehrere Prozesse durchführt, darunter einen oder mehrere der hier beschriebenen Prozesse. Derartige Anweisungen und andere Daten können unter Verwendung einer Vielzahl von computerlesbaren Medien gespeichert und übertragen werden.
-
Hinsichtlich der hier beschriebenen Prozesse, Systeme, Verfahren, Heuristiken usw. versteht es sich, dass die Schritte solcher Prozesse usw. zwar als gemäß einer bestimmten Reihenfolge erfolgend beschrieben wurden, derartige Prozesse aber mit den beschriebenen Schritten in einer Reihenfolge durchgeführt werden könnten, die von der hier beschriebenen Reihenfolge abweicht. Es versteht sich ferner, dass bestimmte Schritte gleichzeitig durchgeführt, andere Schritte hinzugefügt oder bestimmte hierin beschriebene Schritte weggelassen werden könnten. Anders ausgedrückt, dienen hier die Beschreibungen von Prozessen dem Zwecke der Veranschaulichung bestimmter Ausführungsformen und sollten keinesfalls dahingehend ausgelegt werden, dass sie die Ansprüche einschränken.
-
Dementsprechend versteht es sich, dass die vorstehende Beschreibung veranschaulichend und nicht einschränkend sein soll. Viele Ausführungsformen und Anwendungen, bei denen es sich nicht um die vorgestellten Beispiele handelt, würden beim Lesen der vorstehenden Beschreibung ersichtlich. Der Umfang sollte nicht unter Bezugnahme auf die vorstehende Beschreibung ermittelt werden, sondern stattdessen unter Bezugnahme auf die beigefügten Ansprüche gemeinsam mit dem vollständigen Umfang von Äquivalenten, zu denen derartige Ansprüche berechtigt sind. Es wird erwartet und beabsichtigt, dass es hinsichtlich der hier erläuterten Technologien künftige Entwicklungen geben wird und dass die offenbarten Systeme und Verfahren in derartige künftige Ausführungsformen aufgenommen werden. Insgesamt versteht es sich, dass die Anmeldung modifiziert und variiert werden kann.
-
Allen in den Ansprüchen verwendeten Ausdrücken sollen deren umfassendste nachvollziehbare Konstruktionen und deren allgemeine Bedeutung zugeordnet werden, wie sie mit den hier beschriebenen Technologien vertrauten Fachleuten bekannt sind, sofern hier kein ausdrücklicher Hinweis auf das Gegenteil erfolgt. Insbesondere ist die Verwendung der Singularartikel wie etwa „ein“, „einer“, „eine“, „der“, „die“, „das“ usw. dahingehend auszulegen, dass ein oder mehrere der aufgeführten Elemente genannt werden, sofern ein Anspruch nicht eine ausdrücklich gegenteilige Einschränkung enthält.
-
Die Zusammenfassung der Offenbarung wird bereitgestellt, um dem Leser einen schnellen Überblick über den Charakter der technischen Offenbarung zu ermöglichen. Sie wird in der Auffassung eingereicht, dass sie nicht dazu verwendet wird, den Schutzumfang oder die Bedeutung der Patentansprüche auszulegen oder einzuschränken. Des Weiteren geht aus der vorstehenden detaillierten Beschreibung hervor, dass verschiedene Merkmale in verschiedenen Ausführungsformen zum Zwecke der Vereinfachung der Offenbarung zusammengefasst sind. Dieses Offenbarungsverfahren ist nicht dahingehend auszulegen, dass es eine Absicht widerspiegelt, dass die beanspruchten Ausführungsformen mehr Merkmale als ausdrücklich im jeweiligen Patentanspruch genannt erfordern. Vielmehr liegt der Gegenstand der Erfindung in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform, wie die folgenden Patentansprüche widerspiegeln. Somit werden die folgenden Patentansprüche hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Patentanspruch für sich als separat beanspruchter Gegenstand steht.
-
Obwohl vorstehend beispielhafte Ausführungsformen beschrieben werden, sollen diese Ausführungsformen nicht alle möglichen Formen der Erfindung beschreiben. Die in der Beschreibung verwendeten Ausdrücke sind beschreibende und keine einschränkenden Ausdrücke, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne von Geist und Umfang der Erfindung abzuweichen. Außerdem können die Merkmale verschiedener umsetzender Ausführungsformen miteinander kombiniert werden, um weitere erfindungsgemäße Ausführungsformen zu bilden.
