-
TECHNISCHES GEBIET
-
Aspekte der vorliegenden Offenbarung betreffen allgemein ein Verfahren und eine Vorrichtung zur effizienten Bereitstellung von Telematikdaten von Fahrzeugen.
-
HINTERGRUND
-
Mit Fahrzeug-Telematikeinheiten kann man es einem Benutzer eines Fahrzeugs erlauben, mit Diensten in Interaktion zu treten, die über ein Kommunikationsnetzwerk verfügbar sind. Diese Dienste wären zum Beispiel etappenweise Wegbeschreibungen, Telefonkommunikation, Fahrzeugüberwachung und Pannenhilfe. In einigen Fahrzeugen können Telematikmerkmale verwendet werden, um einem entfernten Cloud-Server Fahrzeugdiagnostik- und andere Daten bereitzustellen, aber mit begrenzten Dateninhalten und Meldeintervallen.
-
KURZFASSUNG
-
Ein System umfasst mindestens einen Prozessor, der dafür ausgelegt ist, als Reaktion auf Empfang einer VIN von einem entfernten Fahrzeug eine Parameterdefinition, die auf der Basis von Feldern der VIN ausgewählt wird, um eine ECU des Fahrzeugs zu konfigurieren, in einen Protokollierungsmodus einzutreten, um Betriebsdaten des Fahrzeugs zu erfassen, zu aggregieren und zu senden, und eine Bandbreitenkonfigurationsdatei für ein Modem des Fahrzeugs auf der Basis von Betriebsdaten zugeordneten historischen Durchsatzanforderungen zu dem Fahrzeug zu senden.
-
Ein System umfasst mindestens einen Prozessor, der dafür ausgelegt ist, als Reaktion auf Empfang einer VIN von einem Fahrzeug eine Parameterdefinition, die auf der Basis der VIN und einer Verbindungsbandbreite mit einer ECU in dem Fahrzeug ausgewählt wird, zu dem Fahrzeug zu senden, wobei die Parameterdefinition die ECU dafür konfiguriert, in einen Protokollierungsmodus zum Erfassen, Aggregieren und Senden von Betriebsdaten des Fahrzeugs einzutreten.
-
Ein computerimplementiertes Verfahren umfasst einen entfernten Sever. Der entfernte Server erzeugt eine Parameterdefinition auf der Basis verfügbarer Bandbreite zwischen dem entfernten Server und einer elektronischen Steuereinheit (ECU) in einem Fahrzeug. Der entfernte Server sendet dem Fahrzeug die Parameterdefinition eines verarbeiteten Parameters, der durch die ECU zu berechnen ist. Der entfernte Server empfängt den verarbeiteten Parameter von einem der ECU zugeordneten Fahrzeugdatenpuffer.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
1 zeigt ein beispielhaftes Fahrzeug, das Telematikdaten-Sammelmerkmale implementiert;
-
2 zeigt eine beispielhafte Darstellung eines Meldesubsystems des Systems für eine der elektronischen Steuereinheiten des Fahrzeugs;
-
3 zeigt eine beispielhafte Darstellung der Verarbeitung von Fahrzeugdaten durch eine Meldeanwendung für ein Meldesubsystem der elektronischen Steuereinheiten des Fahrzeugs;
-
4 zeigt eine beispielhafte Darstellung einer Netzwerkarchitektur für das Fahrzeug, die Datenmelde-Subsysteme umfasst, die dieselben Fahrzeugnetzwerke benutzt, die durch die elektronischen Steuereinheiten benutzt werden;
-
5 zeigt eine beispielhafte Darstellung einer Netzwerkarchitektur für das Fahrzeug, die Datenmelde-Subsysteme umfasst, die ein von den durch die elektronischen Steuereinheiten benutzten Fahrzeugnetzwerken getrenntes Melde-Fahrzeugnetzwerk benutzen;
-
6 zeigt ein Beispiel für eine Meldeanwendung, die unverarbeitete Parameter zur Meldung zu verarbeiteten Parametern komprimiert; und
-
7 zeigt ein beispielhaftes Flussdiagramm zur Ermöglichung von effizientem, automatischem und rekonfigurierbarem Verarbeiten und Uploaden von Fahrzeugdaten;
-
8 zeigt einen beispielhaften Fahrzeuginformationsserver, der Telematik-Datensammelmerkmale mit einem Fahrzeug implementiert; und
-
9 zeigt ein beispielhaftes Flussdiagramm zur Ermöglichung von effizienter, automatischer und rekonfigurierbarer Fahrzeugebenen-Datenverarbeitung durch einen Server.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Wie erforderlich werden hier ausführliche Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Formen realisiert werden kann. Die Figuren sind nicht unbedingt maßstabsgetreu; einige Merkmale können übertrieben oder minimiert werden, um Einzelheiten bestimmter Komponenten zu zeigen. Hier offenbarte spezifische Struktur- und Funktionsdetails sind deshalb nicht als begrenzend aufzufassen, sondern lediglich als repräsentative Grundlage, um es Fachleuten zu lehren, die vorliegende Erfindung verschiedenartig einzusetzen.
-
Fahrzeugdaten-Meldearchitekturen und Software-/Firmwareaktualisierungen von Datenmeldeanwendungen können benutzt werden, um effizientes, automatisches und rekonfigurierbares Fahrzeugdatenverarbeiten und Uploaden von Daten zu einem Fahrzeuginformationsserver zu erleichtern. Während des Fahrzeugbetriebs kann eine vordefinierte Datenmenge unverarbeiteter ECU-Parameter gesammelt, verarbeitet und im Speicher auf jeder Fahrzeug-ECU (elektronischen Steuereinheit) gespeichert werden. Auf der Basis der gesammelten unverarbeiteten Parameter können verfügbare Datenmengen aus den ECU-Speicherstellen extrahiert, falls notwendig durch konfigurierbare Meldeanwendungen, die durch die ECU ausgeführt werden, weiter verarbeitet und als ein Datenstrom zu dem Fahrzeuginformationsserver weitergeleitet werden. Nachdem der verarbeitete Datenstrom hochgeladen wurde, kann er zur weiteren Analyse in einer Fahrzeuginformationsdatenbank abgespeichert werden. Gemäß der Analyse kann der Fahrzeuginformationsserver Implementierung einer Service-Maßnahme, Bereitstellen einer automatischen Softwareaktualisierung für das Fahrzeug oder Bereitstellen einer Anforderung, zusätzliche Datenströme von dem Fahrzeug zu rekonfigurieren, um zusätzliche eingehende Analyse zu ermöglichen, unterstützen.
-
Das Datenmelden von einem Fahrzeug kann durch Ereignisse ausgelöst werden, die entweder intern im Fahrzeug oder aus einer externen Quelle, wie etwa dem Fahrzeuginformationsserver, sein können. Wenn das Auslöseereignis von außerhalb des Fahrzeugs stammt, kann eine eindeutige Fahrzeugkennung (wie etwa eine VIN) von dem Fahrzeug zu dem Fahrzeuginformationsserver gesendet werden, um spezifische Informationen darüber abzurufen, welche ECUs und zugeordnete Softwareversionen sich im Fahrzeug befinden, und dementsprechend welche Datenströme bereitgestellt werden können.
-
Jede ECU kann dafür ausgelegt sein, eine Standardliste unverarbeiteter Parameter bereitzustellen. Eine Liste dieser verfügbaren unverarbeiteten Parameter und ihrer assoziierten Informationen können in der Fahrzeuginformationsdatenbank gespeichert werden. Durch Identifizieren, welche ECUs sich im Fahrzeug befinden, kann das System in der Lage sein, zu identifizieren, welche unverarbeiteten Parameter für Verarbeitung zu Datenströmen verfügbar sind, die dem Fahrzeuginformationsserver bereitzustellen sind. Wenn die angeforderten verarbeiteten Datenströme nicht verfügbar sind, aber die unverarbeiteten Parameter zu ihrer Erstellung verfügbar sind, können die entsprechenden ECUs mit aktualisierten Datenmeldeanwendungen, die dafür ausgelegt sind, den angeforderten Datenstrom zu produzieren, neu geflasht oder anderweitig umprogrammiert werden. Wenn eine Anforderung von Daten von den ECUs des Fahrzeugs nicht unterstützt wird (sie z.B. als Eingabe einen unverarbeiteten Parameter erfordert, der durch die ECUs nicht bereitgestellt wird), kann eine Anforderung-Nicht-Unterstützt-Nachricht an den Fahrzeuginformationsserver zurückgegeben werden.
-
Der resultierende gesammelte Datenstrom kann zur Analyse zum Fahrzeuginformationsserver weitergeleitet werden. In einem Beispiel können die durch die Meldeanwendungen der ECUs berechneten verarbeiteten Parameter zusammen mit Identifizierungsinformationen und/oder Zeitstempeln für die Verarbeitung bis zur Anforderung durch einen Sammelauslöser gepuffert werden. Zum Beispiel können die verarbeiteten Parameter von jeder ECU in einem dedizierten Puffer residieren, der einen einzelnen Datenstrom repräsentiert.
-
Die Fahrzeugdaten-Meldearchitekturen können Subsysteme im Fahrzeugnetzwerk umfassen, die dafür ausgelegt sind, Daten vor dem Upload zum Fahrzeuginformationsserver zu verarbeiten. Es können verschiedene Fahrzeugdaten-Meldearchitekturen benutzt werden, um die Datenfunktionalität zu unterstützen. Eine beispielhafte Meldearchitektur kann gemäß einem dezentralisierten Subsystemansatz implementiert werden, bei dem jede ECU über ihr eigenes dediziertes Verarbeitungssubsystem verfügt, das dafür ausgelegt ist, die angeforderten Daten von der ECU über einen getrennten Netzwerkknoten der ECU bereitzustellen. In einem anderen Beispiel können verarbeitete Daten stattdessen über einen getrennten Fahrzeugbus (nicht unbedingt einen CAN-Bus (Controller Area Network)) zu der Telematiksteuereinheit gesendet werden, um Erschöpfung von Basis-CAN-Busbandbreite zu vermeiden. Indem sie getrennte Netzwerkknoten oder Netzwerke zur Ermöglichung von Datenmeldung aufweisen, können die Fahrzeugdaten-Meldearchitekturen Netzwerk- und Nachrichtenkennungen verwenden, die über Fahrzeuglinien hinweg einheitlich sind, ohne mit anderem Fahrzeugsystembetrieb in Konflikt zu kommen. In einem weiteren Beispiel kann ein zentralisierter Verarbeitungsort, wie etwa die Telematiksteuereinheit, Verarbeitung und Pufferung von aus den Fahrzeug-ECUs gesendeten Datenströmen ausführen.
-
Es können speziell zurechtgeschnittene Meldeanwendungen benutzt werden, um Fahrzeugdaten vor dem Uploaden zu komprimieren. Zum Beispiel kann eine Spur des unverarbeiteten Parameters der Motordrehzahl (RPM), der auf einem CAN-Bus gestreamt wird, tiefpassgefiltert und dann downsampled (abwärtsabgetastet) werden, während die meisten seiner Informationen immer noch behalten werden. Beim Empfang kann das ursprüngliche Signal mit annehmbarem Fehler rekonstruiert werden, nachdem es hochgeladen wurde. In einem anderen Beispiel kann Komprimierung von Fahrzeugdaten mit anderer Verarbeitung (z.B. Fast-Fourier-Transformationen) erreicht werden. Andere beispielhafte Algorithmen, die von Meldeanwendungen verwendet werden können, wären z.B. lineare Filterung, Unterabtastung, Spitzendetektion, Medianfilterung, Min/Max-Werte und angepasste Filterung. Weitere Aspekte der effizienten Bereitstellung von Telematikdaten von Fahrzeugen werden nachfolgend ausführlich beschrieben.
-
1 zeigt ein beispielhaftes System 100, das ein Fahrzeug 102 umfasst, das Fern-Telematikdaten-Ablademerkmale implementiert. Wie dargestellt, umfasst das Fahrzeug 102 mehrere Fahrzeug-ECUs 104 in Kommunikation über einen oder mehrere Fahrzeugbusse 106. Das Fahrzeug 102 umfasst ferner eine Telematiksteuereinheit 108, die dafür ausgelegt ist, eine oder mehrere Parameterdefinitionen 116 über ein Netzwerk 112 von einem Fahrzeuginformationsserver 114 zu empfangen, die Fahrzeug-ECUs 104 zu konfigurieren, die durch die Parameterdefinitionen 116 spezifizierten Informationen bereitzustellen, die durch die Parameterdefinitionen 116 spezifizierten Informationen von den Fahrzeug-ECUs 104 zu sammeln und die spezifizierten Informationen umfassende Datenströme 110 zum Fahrzeuginformationsserver 114 zu senden. Es sollte beachtet werden, dass das System 100 lediglich ein Beispiel ist und andere Anordnungen oder Kombinationen von Elementen verwendet werden können.
-
Das Fahrzeug 102 kann verschiedene Typen von Automobil umfassen, ein CUV (Crossover Utility Vehicle), ein SUV (Sport Utility Vehicle), einen Lastwagen, ein RV (Recreational Vehicle), ein Boot, ein Flugzeug oder eine andere mobile Maschine zum Transportieren von Personen oder Gütern. In vielen Fällen kann das Fahrzeug 102 von einem Verbrennungsmotor angetrieben werden. Als eine andere Möglichkeit kann das Fahrzeug 102 ein HEV (Hybrid-Elektrofahrzeug) sein, das sowohl von einem Verbrennungsmotor als auch einem oder mehreren Elektromotoren angetrieben wird, wie etwa ein SHEV (Reihen-Hybrid-Elektrofahrzeug), ein PHEV (Parallel-Hybrid-Elektrofahrzeug) oder ein PSHEV (Parallel-/Reihen-Hybrid-Elektrofahrzeug). Da Typ und Konfiguration des Fahrzeugs 102 unterschiedlich sein können, können entsprechend die Fähigkeiten des Fahrzeugs 102 unterschiedlich sein. Als einige andere Möglichkeiten können Fahrzeuge 102 verschiedene Fähigkeiten mit Bezug auf Passagierkapazität, Schleppmöglichkeit und -kapazität und Speichervolumen aufweisen. Für titularische, erfindungsgemäße und andere Zwecke können Fahrzeuge 102 mit eindeutigen Kennungen, wie etwa VINs, assoziiert sein.
-
Das Fahrzeug 102 kann mehrere ECUs (elektronische Steuereinheiten) 104 umfassen, die dafür ausgelegt sind, verschiedene Funktionen des Fahrzeugs 102 unter dem Antrieb der Fahrzeugbatterie und/oder -Kraftübertragung durchzuführen und zu verwalten. Wie abgebildet, werden die beispielhaften Fahrzeug-ECUs 104 als diskrete ECUs 104-A bis 104-G repräsentiert. Die Fahrzeug-ECUs 104 können sich jedoch physische Hardware, Firmware und/oder Software teilen, so dass die Funktionalität von mehreren ECUs 104 in eine einzige ECU 104 integriert werden kann und die Funktionalität verschiedener solcher ECUs 104 über mehrere ECUs 104 verteilt werden kann.
-
Einige nichteinschränkende Beispiele für Fahrzeug-ECUs 104: eine Kraftübertragungs-Steuer-ECU 104-A kann ausgelegt sein zum Bereitstellen der Steuerung von Motorbetriebskomponenten (z.B. Leerlaufsteuerkomponenten, Kraftstoffablieferungskomponenten, Emissionssteuerungskomponenten usw.) und zum Überwachen des Status solcher Motorbetriebskomponenten (z.B. Status von Motor-Codes); eine Chassissteuerungs-ECU 104-B kann ausgelegt sein zum Verwalten verschiedener elektrischer Steuerfunktionen wie Außenbeleuchtung, Innenbeleuchtung, schlüsselloser Zutritt, Fernstart und Zugangspunkt-Statusverifikation (z.B. Schließungsstatus der Haube, Türen und/oder des Kofferraums des Fahrzeugs 102); eine Funksendeempfänger-ECU 104-C kann ausgelegt sein zur Kommunikation mit Schlüsselanhängern, mobilen Vorrichtungen und anderen lokalen Vorrichtungen des Fahrzeugs 102; eine Unterhaltungssteuereinheit 104-D kann ausgelegt sein zur Unterstützung von Sprachbefehls- und Bluetooth-Schnittstellen mit dem Fahrer und vom Fahrer mit sich geführten Vorrichtungen; eine Klimaregelverwaltungs-ECU 104-E kann ausgelegt sein zur Bereitstellung der Steuerung von Heizungs- und Kühlsystemkomponenten (z.B. Kompressorkupplung, Gebläse, Temperatursensoren usw.); eine GPS-ECU (Global Positioning System) 104-F kann ausgelegt sein zur Bereitstellung von Fahrzeugortsinformationen; und eine HMI-ECU (Mensch-Maschine-Schnittstelle) 104-G kann ausgelegt sein zum Empfangen von Benutzereingaben über verschiedene Tasten und andere Steuerelemente, sowie zum Bereitstellen von Fahrzeugstatusinformationen für einen Fahrer, wie etwa Kraftstoffstandinfo, Motorbetriebstemperatur-Informationen und den aktuellen Ort des Fahrzeugs 102.
-
Der Fahrzeugbus 106 kann verschiedene Verfahren zur Kommunikation zwischen den Fahrzeug-ECUs 104 sowie zwischen der Telematiksteuereinheit 108 und den Fahrzeug-ECUs 104 zur Verfügung haben. Als nichteinschränkende Beispiele kann der Fahrzeugbus 106 eines oder mehrere eines Fahrzeug-CAN (Controller Area Network), eines Ethernetz-Netzwerks und eines MOST-Netzwerks (medienorientierter Systemtransfer) umfassen. Weitere Aspekte des Layouts und der Anzahl der Fahrzeugbusse 106 werden nachfolgend ausführlicher besprochen.
-
Die Telematiksteuereinheit 108 kann Netzwerkhardware umfassen, die dafür ausgelegt ist, Kommunikation zwischen den Fahrzeug-ECUs 104 und mit anderen Vorrichtungen des Systems 100 zu ermöglichen. Zum Beispiel kann die Telematiksteuereinheit 108 ein Mobilfunkmodem umfassen, das dafür ausgelegt ist, Kommunikation mit dem Kommunikationsnetzwerk 112 zu ermöglichen. Das Netzwerk 112 kann ein oder mehrere verbundene Kommunikationsnetzwerke umfassen, wie etwa das Internet, ein Kabelfernseh-Verteilernetz, ein Satellitenverbindungsnetz, ein lokales Netzwerk, ein großflächiges Netzwerk und ein Fernsprechnetz, um nur einige Beispiele zu nennen. Als ein weiteres Beispiel kann die Telematiksteuereinheit 108 ein oder mehrere von Bluetooth-, WiFi- und verdrahteter USB-Netzwerkkonnektivität benutzen, um Kommunikation mit dem Kommunikationsnetzwerk 112 über die mobile Vorrichtung des Benutzers zu ermöglichen. In einem Beispiel kann die Telematiksteuereinheit 108 dafür programmiert sein, periodisch Informationen von den ECUs 104 zu sammeln, die Informationen zu Datenströmen 110 zu verpacken und die Datenströme 110 über das Kommunikationsnetzwerk 112 dem Fahrzeuginformationsserver 114 bereitzustellen.
-
Die Telematiksteuereinheit 108 kann ferner dafür ausgelegt sein, eine oder mehrere Schnittstellen zu umfassen, aus denen Fahrzeuginformationen gesendet und empfangen werden können. In einem Beispiel kann die Telematiksteuereinheit 108 dafür ausgelegt sein, die Sammlung von Fahrzeuginformationen zur Aufnahme in die Datenströme 110 von den Fahrzeug-ECUs 104, die mit dem einen oder den mehreren Fahrzeugbussen 106 verbunden sind, zu ermöglichen. Die durch die Telematiksteuereinheit 108 abgerufenen Fahrzeuginformationen wären als einige nichteinschränkende Beispiele etwa die Gaspedalstellung, der Lenkradwinkel, die Fahrzeuggeschwindigkeit, der Fahrzeugort (z.B. GPS-Koordinaten usw.), die eindeutige Fahrzeugkennung (z.B. VIN), Motordrehzahl (RPM) und Fahrzeug-HMI-Informationen, wie etwa Lenkrad-Tastenbetätigungsinformationen. Weitere Aspekte des Sammelns von Fahrzeuginformationen von den Fahrzeug-ECUs 104 werden nachfolgend ausführlicher besprochen.
-
Der Fahrzeuginformationsserver 114 kann verschiedene Arten von Datenverarbeitungsvorrichtungen umfassen, wie etwa eine Computer-Workstation, einen Server, einen Desktop-Computer, eine durch einen Mainframe-Server ausgeführte virtuelle Serverinstanz oder ein bestimmtes anderes Datenverarbeitungssystem und/oder eine bestimmte andere Datenverarbeitungsvorrichtung. Datenverarbeitungsvorrichtungen, wie etwa der Fahrzeuginformationsserver 114, umfassen im Allgemeinen einen Speicher, auf dem computerausführbare Anweisungen gehalten werden können, wobei die Anweisungen durch einen oder mehrere Prozessoren der Datenverarbeitungsvorrichtung ausführbar sein können. Solche Anweisungen und andere Daten können unter Verwendung vielfältiger computerlesbarer Medien gespeichert werden. Ein computerlesbares Medium (das auch als prozessorlesbares Medium oder Speicherung bezeichnet wird) umfasst ein beliebiges nichttransitorisches (z.B. greifbares) Medium, das beim Bereitstellen von Daten (z.B. Anweisungen), die durch einen Computer (z.B. durch den Prozessor des Fahrzeuginformationsservers 114) gelesen werden können, teilnimmt. Im Allgemeinen empfangen Prozessoren Anweisungen z.B. vom Speicher über ein computerlesbares Speichermedium usw. und führen diese Anweisungen aus, um dadurch einen oder mehrere Prozesse auszuführen, darunter einen oder mehrere der hier beschriebenen Prozesse. Computerausführbare Anweisungen können aus Computerprogrammen kompiliert oder interpretiert werden, die unter Verwendung vielfältiger Programmiersprachen und/oder -technologien erstellt werden, darunter ohne Beschränkung und entweder alleine oder in Kombination Java, C, C++, C#, Objective C, Fortran, Pascal, Visual Basic, Java Script, Perl, Python, PL/SQL usw. In einem Beispiel kann der Fahrzeuginformationsserver 114 dafür ausgelegt sein, die Datenströme 110 aufrecht zu erhalten, die mittels des Netzwerks 112 von der Telematiksteuereinheit 108 der Fahrzeuge 102 empfangen werden.
-
Der Fahrzeuginformationsserver 114 kann ferner dafür ausgelegt sein, Parameterdefinitionen 116 aufrecht zu erhalten, die die verschiedenen Elemente der Datenströme 110, die durch die Fahrzeuge 102 bereitgestellt werden können, beschreiben. Die Parameterdefinitionen 116 können eine Auflistung von Informationen für jeden möglichen Parameter umfassen, wie etwa eine globale Kennung des bestimmten Parameters, eine Beschreibung des Typs von durch den Parameter repräsentierten Daten (z.B. Name), eine Kennung einer ECU 104, die dafür ausgelegt ist, den Parameter bereitzustellen, und Einzelheiten des Formats der Daten der Parameter (z.B. Bitrate, Maßstab, Genauigkeit, Präzision). In einigen Fällen können die Parameterdefinitionen 116 auch Informationen hinsichtlich Algorithmen oder anderer Verarbeitung umfassen, die verwendet werden können, um die ECUs 104 dafür zu konfigurieren, die Datenströme 110 zu der bestimmten Parameterdefinition 116 zu verarbeiten. In einem Beispiel können die Parameterdefinitionen 116 Software von Firmware umfassen, die in die ECUs 104 installiert oder durch diese ausgeführt werden können, um zu bewirken, dass die ECUs 104 dafür rekonfiguriert werden, die bestimmte Parameterdefinition 116 bereitzustellen.
-
Es sind Varianten des Systems 100 möglich. In einem Beispiel kann statt oder zusätzlich zu der Verwendung der Telematiksteuereinheit 108 zur Bereitstellung von Fernkonnektivität zu dem Fahrzeuginformationsserver 114 die Telematiksteuereinheit 108 Kommunikationsmerkmale eines Modems einer mobilen Vorrichtung eines Benutzers, die mit der Unterhaltung gepaart ist, unter Verwendung der ECU 104-D benutzen, um Kommunikation über das Kommunikationsnetzwerk 112 durchzuführen.
-
2 zeigt eine beispielhafte Darstellung 200 eines Meldesubsystems 202 des Systems 100 für eine der ECUs 104 des Fahrzeugs 102. Wie dargestellt, umfasst das Meldesubsystem 202 eine Meldeanwendung 204, die durch die ECU 104 ausgeführt wird und sich mit einem der ECU 104 zugeordnetem Fahrzeugdatenpuffer 206 in Kommunikation befindet. Die ECU 104 kann dafür ausgelegt sein, die Meldeanwendung 204 in einem programmierbaren Speicher der ECU 104 zu speichern. Die ECU 104 kann ferner dafür ausgelegt sein, kommunikativ mit einem oder mehreren Fahrzeugbussen 106 verbunden zu sein. Obwohl der Puffer als logisch von der ECU 104 getrennt dargestellt ist, ist zu beachten, dass der Puffer 206 einen oder mehrere Speicher umfassen kann, die entweder in der ECU 104 enthalten und/oder außerhalb der ECU 104 sind. Der Puffer 206 kann ferner dafür ausgelegt werden, kommunikativ mit einem oder mehreren Fahrzeugbussen 106 verbunden zu sein. Insbesondere muss der Puffer 206 nicht unbedingt mit demselben weiteren Fahrzeugbus 106 verbunden sein, mit dem die ECU 104 verbunden ist.
-
3 zeigt eine beispielhafte Darstellung 300 der Verarbeitung von Daten des Fahrzeugs 102 durch die Meldeanwendung 204 des Meldesubsystems 202 der ECU 104. Wie gezeigt können unverarbeitete Parameter 302 durch die ECU 104 bereitgestellt werden, wie etwa gemäß der Hardware der ECU 104 und/oder gemäß der Firmwareprogrammierung der ECU 104. Somit können diese unverarbeiteten Parameter 302 durch Änderungen an der Meldeanwendung 204 relativ unveränderlich sein. Eine Aktualisierung der Bereitstellung der unverarbeiteten Parameter 302 kann somit eine Firmwareaktualisierung der Firmware der ECU 104 erfordern, nicht nur eine Aktualisierung der Meldeanwendung 204, die dafür ausgelegt ist, die unverarbeiteten Parameter 302 zu verarbeiten.
-
Die Meldeanwendung 204 kann dafür ausgelegt sein, die unverarbeiteten Parameter 302, die von der ECU 104 verfügbar sind, zu empfangen und verschiedene Algorithmen oder Funktionalität zu benutzen, um die unverarbeiteten Parameter 302 zu verarbeiteten Parametern 304 zu verarbeiten. Zum Beispiel kann die Meldeanwendung 204 dafür ausgelegt sein, die unverarbeiteten Parameter 302 zu verarbeiteten Parametern 304 zu komprimieren, wozu eine datenkomprimierte Version von Aspekten der unverarbeiteten Parameter 302 gehören kann. In einem anderen Beispiel kann die Meldeanwendung 204 dafür ausgelegt sein, die unverarbeiteten Parameter 302 zu verarbeiteten Parametern 304 zu filtern, die nur eine Teilmenge der Informationen der unverarbeiteten Parameter 302 umfassen. Andere beispielhafte Verarbeitungsalgorithmen wären lineare Filterung, Subsampling (Unterabtastung), Spitzendetektion, FFTs, Median-Filterung, Min/Max-Werte und angepasste Filterung. Jeder verarbeitete Parameter 304 kann mit einer Kennung assoziiert sein, wie etwa einer eindeutigen Kennnummer der Parameterdefinition 116, die mit einem verarbeiteten Parameter 304 assoziiert ist, der durch die ECU 104 bereitzustellen ist. Ein ausführliches Beispiel der Umsetzung eines unverarbeiteten Parameters 302 in einen verarbeiteten Parameter 304 wird nachfolgend mit Bezug auf 6 besprochen.
-
Nach der Verarbeitung kann die Meldeanwendung 204 dafür ausgelegt sein, die verarbeiteten Parameter 304 dem Puffer 206 zuzuführen. Der Puffer 206 kann dementsprechend dafür ausgelegt sein, die auszuladenden verarbeiteten Parameter 304 zu speichern. In einem Beispiel kann der Puffer 206 die verarbeiteten Parameter 304 in einer Struktur speichern, die eine Kennnummer der Parameterdefinition 116 umfasst, die die verarbeiteten Parameter 304, die gespeichert werden, einen Wert des verarbeiteten Parameters 304 und einen Zeitstempel (z.B. eine Sammelzeit der unverarbeiteten Parameter 302, mit denen der verarbeitete Parameter 304 berechnet wird, eine Start- oder Abschlusszeit der Berechnung des verarbeiteten Parameters 304 usw.) identifiziert. Als Reaktion auf die Auslösung des Meldens der verarbeiteten Parameter 304 kann der Puffer 206 dafür ausgelegt sein, eine Dateneinheit oder ein Paket (z.B. einen CAN-Rahmen) für jede Struktur von ID/Wert/Zeit jedes für die ECU 104 gesammelten verarbeiteten Parameters 304 zu senden. Bei Ausführung durch die ECU 104 kann dementsprechend die Meldeanwendung 204 dafür ausgelegt sein, zu bewirken, dass die ECU 104 die durch die Parameterdefinitionen 116 spezifizierten verarbeiteten Parameter 304 erzeugt und auch die verarbeiteten Parameter 304 zur Datensammlung zu dem Puffer 206 leitet.
-
Die ECU 104 kann ferner dafür ausgelegt sein, ein Flashen der Meldeanwendung 204 mit einer aktualisierten Meldeanwendung 204 zu erlauben, wie etwa als Reaktion auf von dem Fahrzeuginformationsserver 114 empfangene aktualisierte Parameterdefinitionen 116. In einem Beispiel kann die ECU 104 dafür ausgelegt sein, die aktualisierte Meldeanwendung 204 über einen oder mehrere Fahrzeugbusse 106 des Fahrzeugs 102 zu empfangen. Die Meldeanwendung 204 kann an einem dedizierten Softwareort der ECU 104 residieren, so dass die Meldeanwendung 204 effizient durch eine Differenzaktualisierung aktualisiert werden kann, ohne die andere Programmierung der ECU 104 zu beeinflussen.
-
4 zeigt eine beispielhafte Darstellung einer Netzwerkarchitektur 400 für das Fahrzeug 102. In der beispielhaften Netzwerkarchitektur 400 benutzen die Datenmeldesubsysteme 202 dieselben Fahrzeugnetzwerke 106, die von den ECUs 104 zur Kommunikation von ECU zu ECU verwendet werden. In der dargestellten Netzwerkarchitektur 400 ist jedes Meldesubsystem 202 als mit demselben Fahrzeugbus 106 (z.B. CAN-Bus) wie seine zugeordnete ECU 104 verbunden dargestellt.
-
Die Netzwerkarchitektur 400 umfasst auch einen Netzwerkrouter 402, der dafür ausgelegt ist, die Fahrzeugbusse 106 zu überbrücken, um Kommunikation zwischen den Meldesubsystemen 202 der ECUs 104 und der Telematiksteuereinheit 108 zu ermöglichen. Zum Beispiel kann der Netzwerkrouter 402 dafür ausgelegt sein, zu identifizieren, welcher Fahrzeugbus 106 mit einem Ziel einer empfangenen Nachricht verbunden ist, und die empfangene Nachricht auf den entsprechenden Fahrzeugbus 106 weiterzuleiten. Unter Verwendung der Netzwerkarchitektur kann die Telematiksteuereinheit 108 dafür ausgelegt sein, von den Datenmeldesubsystemen 202 der Fahrzeug-ECUs 104 anzufordern, die verpackten Fahrzeugdaten 306 der Telematiksteuereinheit 108 bereitzustellen. Die Telematiksteuereinheit 108 kann dementsprechend die verpackten Fahrzeugdaten 306 in Datenströme 110 sammeln und die Datenströme 110 dem Fahrzeuginformationsserver 114 bereitstellen.
-
5 zeigt eine alternative beispielhafte Darstellung einer Netzwerkarchitektur 500 für das Fahrzeug 102, die einen von dem durch die ECUs 104 benutzten Fahrzeugbus 106 getrennten Meldefahrzeugbus 106 benutzt. Verglichen mit der Netzwerkarchitektur 400 wird in der Netzwerkarchitektur 500 der Meldedatenverkehr nicht über denselben Fahrzeugbus 106 bereitgestellt, der für Kommunikation von ECU zu ECU benutzt wird.
-
Durch Benutzung eines getrennten Fahrzeugbusses 106 für die Meldesubsysteme 202 kann die Netzwerkarchitektur 500 Bedenken bezüglich zusätzlicher Bandbreitenbenutzung, die erforderlich ist, um zusätzliche Datenübertragung in dem Fahrzeug 102 zu unterstützen, um Sammlung der verpackten Fahrzeugdaten 306 der Telematiksteuereinheit 108 zur Meldung in Datenströme 110 zu unterstützen, mindern.
-
6 zeigt ein Beispiel 600 für eine Meldeanwendung 204, die unverarbeitete Parameter 302 zur Meldung zu verarbeiteten Parametern 304 komprimiert. In dem dargestellten Beispiel 600 ist ein Datenstrom 602 der Motordrehzahl (RPM) als ein ursprünglicher unverarbeiteter Parameter 302, der durch eine Motorsteuerungs-ECU 104 bereitgestellt wird, ein reduzierter Datenstrom 604, eine Version eines erneut abgetasteten (resampled) Datenstroms 606 des reduzierten Datenstroms 604 und eines Fehlerdatenstroms 608, der die Differenz zwischen dem erneut abgetasteten (resampled) Datenstrom 606 und dem ursprünglichen Datenstrom 602 darstellt, gezeigt. Als eine Möglichkeit kann die Motorsteuerungs-ECU 104 mit einer Meldeanwendung 204 konfiguriert sein, die dafür ausgelegt ist, die dargestellte Komprimierung auszuführen, um den unverarbeiteten Parameter 302 der Motordrehzahl (d.h. den ursprünglichen Datenstrom 602) in den verarbeiteten Motordrehzahlparameter 304 (d.h. reduzierten Datenstrom 604) umzusetzen. Die Meldeanwendung 204 oder die ECU 104 kann ferner dafür ausgelegt sein, den reduzierten Datenstrom 604 zur Übertragung über den Fahrzeugbus 106 zu der Telematiksteuereinheit 108 und zum Ausladen aus dem Fahrzeug 102 in den Fahrzeuginformationsserver 114 in dem Fahrzeugdatenpuffer 206 zu speichern.
-
Wie dargestellt, wird der reduzierte Datenstrom 604 um einen Faktor drei dezimiert. Die Dezimierung bezieht sich im Allgemeinen auf einen Prozess des Reduzierens einer Abtastrate eines Datenstroms, wobei der Datenstrom tiefpassgefiltert werden kann und dann Abtastwerte aus dem Datenstrom verworfen werden können. Der Dezimierungsfaktor kann sich auf das Verhältnis der Eingangsrate zur Ausgangsrate beziehen, wobei der Dezimierungsfaktor M so definiert ist, dass Eingangsrate/Ausgangsrate = M ist. Dementsprechend kann der reduzierte Datenstrom 604 einen Abtastwert für jeden dritten Abtastwert des ursprünglichen Datenstroms 602 umfassen.
-
Der erneut abgetastete Datenstrom 606 kann die wieder bis herauf zu der Rate des ursprünglichen Datenstroms 606 erneut abgetasteten Daten des reduzierten Datenstroms 604 umfassen. Da aufgrund der verlusthaften Komprimierung (d.h. Dezimierung), die durchgeführt wurde, um die Menge an Daten des ursprünglichen Datenstroms 602 auf den reduzierten Datenstrom 604 zu reduzieren, einige Informationen verloren wurden, kann ein gewisser Grad an Fehler in dem erneut abgetasteten Datenstrom 606 vorliegen. Der Fehlerdatenstrom 608 illustriert dementsprechend diese Menge an verlorenen Informationen. Insbesondere kann die Menge an Fehler in dem dargestellten Beispiel 600 für viele Melde- und Diagnostikzwecke annehmbar niedrig sein, während Bandbreite des Netzwerks und des Fahrzeugs 102 bei der Datenübertragung gespart wird.
-
7 zeigt einen beispielhaften Prozess 700 zum Ermöglichen von effizientem, automatischem und rekonfigurierbarem Verarbeiten und Uploaden von Fahrzeugdaten. Der Prozess 700 kann zum Beispiel durch das Fahrzeug 102 in Kommunikation mit dem Fahrzeuginformationsserver 114 über das Netzwerk 112 ausgeführt werden. Der Prozess 700 kann durch verschiedene Ereignisse eingeleitet werden, die intern im Fahrzeug 102 sein oder von einer externen Quelle durch das Fahrzeug 102 empfangen werden können.
-
In Operation 702 empfängt das Fahrzeug 102 eine Angabe des Auslösens eines Ereignisses außerhalb des Fahrzeugs 102. In einem Beispiel kann das Fahrzeug 102 eine Meldeanforderung von dem Fahrzeuginformationsserver 114 empfangen, die anfordert, dass das Fahrzeug 102 Datenströme 110 bereitstellt, die Informationen umfassen, die durch die Parameterdefinitionen 116 spezifiziert werden, die durch die Meldeanforderung angegeben werden. In einem anderen Beispiel kann das Fahrzeug 102 eine Meldeanforderung von einem Insassen des Fahrzeugs 102 empfangen, die anfordert, dass das Fahrzeug 102 bestimmte Informationen aus den Fahrzeug-ECUs 104 wie durch die Anforderung angegeben bereitstellt. In einem weiteren Beispiel kann das Fahrzeug 102 das Auftreten eines Ereignisses detektieren, woraufhin die Fahrzeuge 102 bestimmte durch das erzeugte Ereignis angegebene Parameterdefinitionen 116 bereitstellen sollten.
-
In Operation 704 stellt das Fahrzeug 102 als Reaktion auf das Ereignis eine Kennung des Fahrzeugs 102 bereit. In einem Beispiel kann das Fahrzeug 102 eine VIN des Fahrzeugs 102 zu dem Fahrzeuginformationsserver 114 senden, um von dem Fahrzeuginformationsserver 114 anzufordern, Parameterdefinitionen 116 zur Meldung für das Fahrzeug 102 bereitzustellen. Auf der Basis der empfangenen Kennung des Fahrzeugs 102 kann der Fahrzeuginformationsserver 114 dafür ausgelegt sein, die Parameterdefinitionen 116 zu identifizieren, die mit den in dem Fahrzeug 102 installierten ECUs kompatibel sind.
-
In Operation 706 empfängt das Fahrzeug 102 die Parameterdefinition 116 von dem Fahrzeuginformationsserver 114. Zum Beispiel kann der Fahrzeuginformationsserver 114 auf der Basis der Bestimmung der kompatiblen Parameterdefinitionen 116 eine oder mehrere Parameterdefinitionen 116 identifizieren, die dem Fahrzeug 102 bereitzustellen sind. In einem Beispiel kann die Parameterdefinition 116 von dem Fahrzeuginformationsserver 114 die durch das Fahrzeug 102 bereitzustellenden verarbeiteten Parameter 304 als eine eindeutige Kennung der verarbeiteten Parameter 304 beschreiben. In einem anderen Beispiel kann die Parameterdefinition 116 von dem Fahrzeuginformationsserver 114 die durch das Fahrzeug 102 bereitzustellenden verarbeiteten Parameter 304 als eine Meldeanwendung 204 beschreiben, die in einer Fahrzeug-ECU 102 zu installieren ist, um unverarbeitete Parameter 302 zu empfangen und die verarbeiteten Parameter 304 zu berechnen.
-
In Operation 708 bestimmt das Fahrzeug 102, ob die angeforderten Daten verfügbar sind. In einem Beispiel kann die Telematiksteuereinheit 108 des Fahrzeugs 102 die ECUs 104 abfragen, um zu bestimmen, ob die ECUs 104 des Fahrzeugs 102 in der Lage sind, die zum Produzieren der verarbeiteten Parameter 304 erforderlichen unverarbeiteten Parameter 302 bereitzustellen. Wenn die ECUs 104 melden, dass die unverarbeiteten Parameter 302 für die Bereitstellung durch die installierten ECUs 104 des Fahrzeugs 102 nicht verfügbar sind, endet der Prozess 700. Andernfalls wird die Steuerung an Operation 710 abgegeben.
-
In Operation 710 bestimmt das Fahrzeug 102, ob Rekonfiguration notwendig ist, um die angeforderten Daten bereitzustellen. In einem Beispiel kann die Telematiksteuereinheit 108 des Fahrzeugs 102 die ECUs 104 abfragen, um zu bestimmen, ob die ECUs 104 dafür ausgelegt sind, die unverarbeiteten Parameter 302 zu den durch die Parameterdefinitionen 116 spezifizierten verarbeiteten Parametern 304 zu verarbeiten. Wenn eine oder mehrere ECUs Rekonfiguration erfordern, wird die Steuerung an Operation 712 abgegeben. Wenn dagegen die ECUs 104 ordnungsgemäß konfiguriert sind, wird die Steuerung an Operation 714 abgegeben.
-
In Operation 712 konfiguriert das Fahrzeug 102 die Datenströme 110 um. In einem Beispiel kann die Telematiksteuereinheit 108 von den veralteten ECUs 104 anfordern, ihre Meldeanwendungen 204 zu aktualisieren, um die unverarbeiteten Parameter 302 gemäß einer oder mehreren Meldeanwendungen 204, die in den Parameterdefinitionen 116 enthalten oder anderweitig durch diese spezifiziert werden, zu den verarbeiteten Parametern 304 zu verarbeiten.
-
In Operation 714 aktiviert das Fahrzeug 102 die Datenströme 110. In einem Beispiel können die ECUs 104 ihre jeweiligen Meldeanwendungen 204 zum Verarbeiten der unverarbeiteten Parameter 302 zu den verarbeiteten Parametern 304 benutzen. Die Meldeanwendungen 204 können dementsprechend die verarbeiteten Parameter 304 den mit den ECUs 104 assoziierten Fahrzeugdatenpuffern 206 zuführen.
-
In Operation 716 uploadet das Fahrzeug 102 die Daten. In einem Beispiel kann die Telematiksteuereinheit 108 dafür programmiert werden, periodisch die verpackten Fahrzeugdaten 306 aus den mit den ECUs 104 assoziierten Fahrzeugdatenpuffern 206 zu sammeln und die Daten über das Kommunikationsnetzwerk 112 als Datenströme 110 dem Fahrzeuginformationsserver 114 bereitzustellen.
-
In Operation 718 analysiert der Fahrzeuginformationsserver 114 die Daten. Zum Beispiel kann der Fahrzeuginformationsserver 114 Abfragen der aufrechterhaltenen Datenströme 110 unterstützen, um Benutzern des Fahrzeuginformationsservers 114 Datenverarbeitungs- und andere Merkmale bereitzustellen. Nach Operation 718 endet der Prozess 700.
-
8 zeigt einen beispielhaften Prozess 800 zur Ermöglichung von effizienter, automatischer und rekonfigurierbarer Fahrzeugdatenverarbeitung auf Serverbasis und Sammlung von Daten von einem Fahrzeug 102. Der Prozess 800 kann zum Beispiel durch den Fahrzeuginformationsserver 114 ausgeführt werden, der sich über das Netzwerk 112 in Kommunikation mit dem Fahrzeug 102 befindet. Der Prozess 800 kann durch verschiedene Ereignisse eingeleitet werden, die intern im Server 114 sein oder von einer externen Quelle durch den Server 114 empfangen werden können. Datenoperatoren definierten die durch das Fahrzeug zu erfassenden Parameter. Hier sind 3 Datenoperatoren gezeigt, angepasste Datenoperatoren 802, algorithmische Datenoperatoren 804 und diagnostische Datenoperatoren 806. Die angepassten Datenoperatoren 802 dienen typischerweise zur spezifischen Analyse eines Fahrzeugs, das eine Art von Operation aufweist oder ein spezifisches Flag, Diagnostik-Problemcode (DTC), Benachrichtigungen oder Warnungen produziert. Die spezifische Analyse kann einer technischen Notwendigkeit zugeschrieben werden. Das Fahrzeug kann ein einzelnes identifizierbares Fahrzeug, eine Fahrzeuglinie, eine Klasse von Fahrzeugen oder eine Gruppe von Fahrzeugen mit einer spezifischen Fahrzeugoption sein. Zum Beispiel kann ein angepasster Datenoperator für alle Fahrzeuge gelten, die ein spezifisches Modell des Sync-Systems oder ein Karosseriesteuermodul (BCM) aufweisen, das durch einen spezifischen Lieferanten der Stufe 1 hergestellt wird. Außerdem kann der angepasste Datenoperator 802 bezüglich einer Anzahl von Vorfällen des Flags oder einem DTC größer als eine vorbestimmte Schwelle konditional sein. Zum Beispiel ein Vorfall dass der DTC einer Abgasrezirkulation (EGR) eine Schwelle überschreitet, mit anschließender Anforderung von Parametern wie Motordrehzahl, Umgebungslufttemperatur und Motorlufttemperatur.
-
Die algorithmischen Datenoperatoren 804 sind typischerweise für Gebrauch eines Fahrzeugs bestimmt. Das Fahrzeug kann ein einzelnes identifizierbares Fahrzeug, eine Fahrzeuglinie, eine Klasse von Fahrzeugen oder eine Gruppe von Fahrzeugen mit einer spezifischen Fahrzeugoption sein. Der Gebrauch kann dabei hilfreich sein, Verwendungsraten, Gebrauchsmuster, Kundenanforderungen und Geschäftsaspekte, die dem Merkmal zugeordnet sind, zu bestimmen. Zum Beispiel kann das Fahrzeug eine neue Fahrzeuglinie sein und es kann die VIN ausgewählt werden, die den ersten 1000 Fahrzeugen zugeordnet ist, worin ein spezifischer Parameter 6 Monate lang überwacht wird und nach den 6 Monaten die Parameterüberwachung ausgeschaltet wird. Der Parameter kann Verwendung bestimmter Merkmale umfassen, wie etwa automatische Parkhilfe, Infotainment-Benutzung, Umgebungsbeleuchtungsauswahl und -benutzung, Allradantrieb-Benutzung usw.
-
Die diagnostischen Datenoperatoren 806 dienen typischerweise für den Betrieb eines Fahrzeugs. Das Fahrzeug kann ein einzelnes identifizierbares Fahrzeug, eine Fahrzeuglinie, eine Klasse von Fahrzeugen oder eine Gruppe von Fahrzeugen mit einer spezifischen Fahrzeugoption sein. Der Betrieb des Fahrzeugs kann Garantieinformationen zugeschrieben werden. Zum Beispiel kann das Fahrzeug eine neue Fahrzeuglinie sein und es kann die VIN ausgewählt werden, die den ersten 1000 Fahrzeugen zugeordnet ist, worin ein spezifischer Parameter 6 Monate lang überwacht wird und nach den 6 Monaten die Parameterüberwachung ausgeschaltet wird. Der Parameter kann ein Histogramm der Motordrehzahl, des Kraftstoffverbrauchs, der Motortemperatur, der Beschleunigungsrate, der Fahrerleistungsanforderung usw. umfassen.
-
In Operation 808 priorisiert der Server 114 die Datenoperatoren (802, 804 und 806). Die Priorisierung kann auf einem Flag, einer Semaphore, einer Priorisierungsstruktur oder modulspezifischen Beschränkung basieren. Die Prioritätsstruktur kann simple 3 Ebenen umfassen (hoch, mittel, niedrig), wobei jedem Datenoperator ein Niveau zugewiesen wird und bei mehreren Operatoren ein Niveau über eine erstnumerische FIFO-Identifikation (First-In, First-Out) innerhalb des Niveaus bestimmt wird oder eine komplexe Kombination sein kann, wobei mehrere Priorisierungsverfahren oder ein auf Fuzzy-Logik basierendes System verwendet wird, wobei den einzelnen Datenoperatoren zusammen mit einer Klasse ein Gewicht zugewiesen werden kann. Die modulspezifische Beschränkung kann eine nichtatomische Beschränkung einer CPU des Moduls mit Bezug auf gleichzeitige Verarbeitung mehrerer Datenoperatoren umfassen.
-
In Operation 810 erzeugt der Server 114 auf der Basis identifizierter Parameter von dem Prioritätsmanager 808 die Algorithmen zum Erfassen, Aggregieren und Senden der Parameter. Hier können einige der Parameter mit einer schnellen Rate wie 100 µs erfasst und dann aggregiert werden, um ein Histogramm zu bilden, so dass Daten auf der Basis einer Auflösung von 100 µs gesendet und durch den Sender analysiert werden können, ohne einen Engpass durch die Datenmenge auf der Basis der Abtastrate zu erzeugen.
-
In Operation 812 erzeugt der Server 114 die Parameter für jedes identifizierte Modul im Fahrzeug unter Verwendung eines holistischen Ansatzes. Hier erzeugt der Server 114 die Definitionsparameter für jedes Modul unter Berücksichtigung aller Parameter, Algorithmen und Module, die in dem Algorithmuserzeugungsblock 810 identifiziert werden. Bevor die definierten Parameter finalisiert werden, kommuniziert der Server 114 jedoch über die Cloud mit dem Fahrzeug 816, um Daten bezüglich interner Busbandbreite des Fahrzeugs, Status des Fahrzeugs und Transferrate der Verbindung zwischen dem Fahrzeug oder einem individuellen Modul und dem Server zu erhalten. Ein Datenpfad von dem Fahrzeug 816 zum Server 114 ist als die bidirektionalen Leitungen zwischen dem Prioritätsmanager 808, der Algorithmuserzeugung 810, der Parametererzeugung 812 und dem Fahrzeug 816 gezeigt. Diese Gruppe von bidirektionalen Leitungen und Modulen (808, 810, 812 und 816) dient typischerweise dazu, das Fahrzeug 816 dafür einzurichten, Daten zu erfassen, zu aggregieren und zu paketieren. Nachdem die Parameterdefinition in das Fahrzeug 816 geladen ist, kann das Fahrzeug 816 die Daten erfassen, aggregieren, paketieren und zum Server 114 senden.
-
Das Fahrzeug 816, wie etwa das Fahrzeug 102 mit den Modulen 104 und 108 und einem Fahrzeugbus 106 kann auch Module umfassen, wie etwa Module des Typs ABS (Antiblockiersystem), ESC (elektronische Stabilitätskontrolle), PODS (Passagierinsassendetektionssystem) und RCM (Rückhaltesteuermodul). Diese Module können in der Lage sein, viele Aspekte des Fahrzeugbetriebs und -gebrauchs zu sammeln. Zum Beispiel kann das ABS-Modul in der Lage sein, einen Stand eines Bremsbelags, einen Stand von Bremsflüssigkeit und einen Grad von Radblockierung zu bestimmen. Auf der Basis des Stands des Bremsbelags kann das ABS-Modul in der Lage sein, eine Rate der Bremsbelagabnutzung zu bestimmen und auf der Basis einer ausgewählten Parameterdefinition die Auswirkung von Fahreigenschaften mit Bremsbelagabnutzung zu bestimmen. Außerdem kann ein RCM bestimmen, wie oft ein Passagier einen Sitzgurt trägt, oder ein PODS kann bestimmen, wie oft ein Passagier sich im Fahrzeug befindet, zusammen mit Eigenschaften des Passagiers wie Gewicht des Passagiers. Ferner kann Datenverkehr auf einem Fahrzeugbus überwacht werden und eine Parameterdefinition kann einige Module auf einem Bus konfigurieren, um Busverkehr zu verringern, um verfügbare Fahrzeugbandbreite des Busses "freizugeben" oder zu vergrößern, um einem Datenbedarf eines anderen Moduls, der durch den Server 114 angefordert wird, zu erfüllen. Bei einer Zunahme der verfügbaren Fahrzeugbandbreite kann die Parameterdefinition auch die TCU 108 rekonfigurieren, um eine Verbindungsbandbreite zu vergrößern. Dies kann erfordern, dass die TCU einen alternativen Kanal auswählt, auf dem gearbeitet wird, wie etwa Rekonfigurierung der TCU von einem paketierten Data-Over-Voice- zu einem dedizierten Datenkanal wie LTE oder 4G-LTE.
-
Der Datenbus des Fahrzeugs 816 kann einen CAN-Bus (Controller Area Network), einen Flexray-Bus, einen LIN-Bus (Local Interconnect Network), einen Ethernetbus, MOST (Media Oriented System Transport) und Ableitungen dieser Busse umfassen, wie etwa Ethernet AVB und CAN-FD. Einige Module können unter Verwendung mehrerer Busprotokolle mit anderen Modulen kommunizieren. Zum Beispiel können zwei Module mit der Fähigkeit zur Kommunikation über ein CAN-FD-Protokoll dafür ausgelegt sein, typischerweise über Standard-CAN zu kommunizieren. Die Module können hier rekonfiguriert werden, um über CAN-FD zu kommunizieren, um zusätzliche Bandbreite bereitzustellen, die den größeren Nutzinformationen des CAN-FD-Protokolls zugeordnet ist. Außerdem kann die Transferrate einiger Module mit schnelleren Raten betrieben werden als typischerweise der Fall ist. Zum Beispiel kann ein Bus, der typischerweise dafür ausgelegt ist, mit 500 kbps zu arbeiten, in der Lage sein, mit 1 Mbps zu arbeiten. Rekonfigurierung mehrerer Module zum Betrieb auf den höheren 1 Mbps für eine begrenzte Zeit würde hier die verfügbare Bandbreite vergrößern.
-
In Operation 818 empfängt und analysiert der Server 114 die Daten. Die Daten werden so analysiert, dass Daten in "Silos" oder "Eimer" kategorisiert und angeordnet werden. Die Kategorisierung kann auf dem Fahrzeug, der Fahrzeuglinie, der Klasse von Fahrzeugen oder Gruppe von Fahrzeugen mit einer spezifischen Fahrzeugoption basieren. Außerdem kann die Kategorisierung auf dem DTC, der Beschaffenheit des Parameters, dem Wert des Parameters oder Daten, die einem Fahrzeug zugeordnet sind, das eine spezifische Betriebseigenschaft aufweist, basieren. Wenn zum Beispiel ein Fahrzeug hinsichtlich einer Beschwerde über Mangel an Beschleunigung analysiert wird, Daten von mehreren Modulen wie dem PCM (Kraftübertragungssteuermodul), TCM (Getriebesteuermodul), ABS (Antiblockiersystem), TPMS (Reifendruck-Überwachungssystem) usw. Ein Beispiel für Daten von einem PCM wäre Motordrehzahl, Kraftstofffluss, Kraftstoffverbrauch, Lufttemperatur, Kühlmitteltemperatur, Öldruck, Öltemperatur, Abgastemperatur, Abgassauerstoffkonzentration oder Lufteinlass-Sauerstoffkonzentration. In Operation 820 analysiert der Server 114 die Daten, so dass sie zur Speicherung in einer Fahrzeugdatenbank 822 angeordnet werden, auf einem Monitor angezeigt oder mit anderen Daten zur Analyse benutzt werden.
-
9 zeigt ein beispielhaftes Flussdiagramm 900 zur Ermöglichung von effizienter, automatischer und rekonfigurierbarer Fahrzeugebenen-Datenverarbeitung durch einen Server, wie etwa den Server 114. Das Flussdiagramm 900 kann in dem Blockdiagramm 800 implementiert sein.
-
In Operation 902 bestimmt der Server 114 einen Fahrzeugdatensatz. Bei einer Implementierung kann Operation 902 durch Block 810 von 8 implementiert werden. Bei einer alternativen Ausführungsform kann die Operation 902 durch abstrahierte Variablen auf einem Client definiert werden. In Operation 904 definiert der Server die Parameter-Abbildung, wie etwa in Block 812 von 8 gezeigt. Auf der Basis der Parameterabbildung von Operation 902 vergleicht der Server 114 den verfügbaren TCU-Datenstrom in Operation 906 mit dem angeforderten Datenstrom. Wenn der verfügbare Datenstrom kleiner als der angeforderte Datenstrom ist, verzweigt sich der Entscheidungsbaum zurück zu Operation 902, um einen anderen Fahrzeugdatensatz zu bestimmen. Wenn der verfügbare Datenstrom größer als der angeforderte Datenstrom ist, macht der Entscheidungsbaum mit Operation 908 weiter. Bei einer alternativen Ausführungsform kann Operation 904 ein Thema des MQTT (Message Queuing Telemetry Transport) mit einem Protokollpufferformat, wie etwa einem Google-Protokollpufferformat, aktualisieren.
-
In Operation 908 erzeugt der Server 114 die Parameterdefinition, die ausführbare Firmware, Meldecode oder eine Pufferdatei umfassen kann, wie etwa eine Pufferdatei des SDN (Service Delivery Network). Dies ist der Kombination der Schritte 810 und 812 von 8 nach der Verifikation des verfügbaren Datenstroms ähnlich. Die Firmware und der Meldecode können Assembleranweisung für den Prozessor oder die Steuerung des Moduls, Kalibrationsvariablen zum Konfigurieren des Prozessors oder der Steuerung zum Ausführen der Aufgabe oder zum Laufenlassen von Bibliotheken oder Anweisungen zum Laufen auf einer durch den Prozessor oder die Steuerung erzeugten virtuellen Maschine umfassen.
-
In Operation 910 sendet der Server 114 die Parameterdefinition über die Cloud oder ein anderes Netzwerk zum Fahrzeug. In dem entfernten Fahrzeug 816 wird Authentifizierung des Zugriffs auf das Fahrzeug 816 angefordert. In Operation 912 kann Authentifizierung über ein Popup-Menü auf einer Fahrerinformationskonsole (DIC), einem Infotainment-Bildschirm oder einer Instrumententafelanzeige angefordert werden. Authentifizierung kann erforderlich sein, um weiterzukommen, oder bei einer alternativen Ausführungsform kann Authentifizierung erforderlich sein, um Zugriff auf das Fahrzeug 816 zu blockieren oder auszuschalten. Der Zugriff kann entweder ausdrücklich gewährt werden oder implizit durch mangelnde Zugriffsblockierung. Ein Modul oder mehrere Module im Fahrzeug werden mit der Parameterdefinition aktualisiert, nachdem Zugriff gewährt wird. Die Aktualisierungen können Löschen und Umprogrammieren von nichtflüchtigem Speicher, wie etwa EEPROM-, FLASH- oder MRAM-Speicher oder flüchtigem Speicher wie RAM umfassen. Die Verifikation einer ordnungsgemäßen Aktualisierung wird in Operation 914 durchgeführt.
-
In Operation 916 aktualisiert der Server die Serverpufferdatei für die spezifische VIN. Dies kann ein Handshake zwischen den Blöcken 812 und 816 umfassen, um das Modul auf der Basis von Daten von dem Fahrzeug 816 zu konfigurieren. In Operation 918 abstrahiert der Server 114 über die Cloud Daten zum Analysieren der Daten zu Datenstrukturen. Die Daten werden dann zur Speicherung und Analyse in Operation 920 zu einer Datenbank gesendet.
-
Die hier offenbarten Prozesse, Verfahren oder Algorithmen können an eine Verarbeitungsvorrichtung, eine Steuerung, einen Mikrocontroller oder Computer, wozu jede existierende programmierbare elektronische Steuereinheit oder dedizierte elektronische Steuereinheit gehören kann, ablieferbar sein oder durch diese implementiert werden. Ähnlich können die Prozesse, Verfahren oder Algorithmen als durch eine Steuerung oder einen Computer ausführbare Daten und Anweisungen in vielen Formen gespeichert werden, darunter, aber ohne Beschränkung darauf, Informationen, die permanent auf nicht beschreibbaren Speichermedien wie ROM-Vorrichtungen gespeichert werden, und Informationen, die änderbar auf beschreibbaren Speichermedien wie Disketten, Magnetbändern, CDs, RAM-Vorrichtungen und anderen magnetischen und optischen Medien gespeichert werden. Die Prozesse, Verfahren oder Algorithmen können auch in einem ausführbaren Softwareobjekt implementiert werden. Als Alternative können die Prozesse, Verfahren oder Algorithmen ganz oder teilweise unter Verwendung von geeigneten Hardwarekomponenten realisiert werden, wie etwa ASIC (anwendungsspezifische integrierte Schaltungen), FPGA (am Einsatzort programmierbare Gatearrays), Automaten, Steuerungen oder andere Hardwarekomponenten oder -vorrichtungen oder eine Kombination von Hardware-, Software- und Firmwarekomponenten.
-
Obwohl oben beispielhafte Ausführungsformen beschrieben werden, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen durch die Ansprüche eingeschlossenen Formen beschreiben. Die in der Beschreibung verwendeten Wörter sind nicht Wörter der Beschränkung, sondern der Beschreibung, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Gedanken und Schutzumfang der Offenbarung abzuweichen. Wie zuvor beschrieben können die Merkmale verschiedener Ausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden, die nicht ausdrücklich beschrieben oder dargestellt sein können. Obwohl verschiedene Ausführungsformen als gegenüber anderen Ausführungsformen oder vorbekannten Implementierungen mit Bezug auf eine oder mehrere gewünschte Eigenschaften Vorteile bereitstellen oder bevorzugt beschrieben worden sein kann, ist für Durchschnittsfachleute erkennbar, dass ein oder mehrere Merkmale oder Eigenschaften kompromittiert werden können, um gewünschte Gesamtsystemattribute zu erzielen, die von der spezifischen Anwendung und Implementierung abhängen. Diese Attribute wären zum Beispiel, aber ohne Beschränkung darauf, Kosten, Belastbarkeit, Dauerhaftigkeit, Lebenszykluskosten, Vermarktbarkeit, Aussehen, Verpackung, Größe, Wartbarkeit, Gewicht, Herstellbarkeit, leichte Montage usw. Dementsprechend befinden sich Ausführungsformen, die mit Bezug auf eine oder mehrere Eigenschaften als weniger wünschenswert als andere Ausführungsformen oder vorbekannte Implementierungen beschrieben werden, nicht außerhalb des Schutzumfangs der Offenbarung und können für konkrete Anwendungen wünschenswert sein.
