DE102014219232A1 - Fahrzeugdiagnostik- und -prognostiksysteme und verfahren - Google Patents

Abstract

Ein Fahrzeugdatenverarbeitungssystem weist einen Computerprozessor in Kommunikation mit einem drahtlosen Sendeempfänger auf, dergestalt, dass der drahtlose Sendeempfänger zu Kommunikation mit einer entfernt vom Prozessor angeordneten drahtlosen Kommunikationsvorrichtung fähig ist. Der Computerprozessor ist dafür ausgelegt, mittels der drahtlosen Kommunikationsvorrichtung eine oder mehrere Anweisungen von einem entfernten Server zu empfangen. Der Prozessor kann auf der Basis der einen oder mehreren Anweisungen ein Speicherlesen aus einem oder mehreren Modulen anfordern, wobei das Speicherlesen mindestens eine Variable umfasst, die in einem Fahrzeugnetzwerk nicht verfügbar ist. Der Prozessor kann auf der Basis des Speicherlesens aus dem einen oder den mehreren Modulen Daten empfangen und die Daten zu dem entfernten Server senden.

Description

• Die vorliegende Offenbarung betrifft Verfahren und Systeme zum Diagnostizieren von Kundenbeschwerden in einem Fahrzeug und Aufzeichnen von Diagnostikdaten und anderen Informationen in Bezug auf die Betriebsbedingungen des Fahrzeugs und Übertragen eines Teils der aufgezeichneten Daten zu einer Vorrichtung.
• Das US-Patent 7,317,975 offenbart allgemein ein System, das Tracking und drahtlose Kommunikation zur Ferndiagnostik eines Fahrzeugs bereitstellt. Das System überträgt über den CAN-Bus eines Fahrzeugsystems übermittelte Daten zu einem entfernten Ort. Das System ist dafür ausgelegt, aus einem Fahrzeug empfangene Daten zu verwenden, um die Leistungsfähigkeit des Fahrzeugs und/oder des Bedieners des Fahrzeugs mit der Leistungsfähigkeit anderer Fahrzeuge und/oder Bediener anderer Fahrzeuge zu vergleichen. Das System umfasst fortschrittliche Power-Management-Funktionalität, um Strom zu sparen, insbesondere wenn das System von einer Hauptstromversorgung getrennt ist, und wodurch die Identifikation von Fahrzeugen ermöglicht wird, die sich dem System nicht zurückgemeldet haben oder die sich innerhalb eines spezifizierten Zeitraums nicht bewegt haben.
• Das US-Patent 6,956,501 offenbart allgemein ein verbessertes Überwachungssystem zur Verwendung mit Kraftfahrzeugen, die mehrere Sensoren zur Messung der Leistungsfähigkeit des Fahrzeugs und einen Speicher zum Speichern von aus den Sensoren abgeleitete Daten spezifizierenden Informationen aufweisen. Die Offenbarung umfasst eine drahtlose Kommunikationsverbindung zum Übertragen der Informationen zu einem Endgerät, das sich in der Nähe des Fahrzeugs befindet. Das Endgerät übermittelt durch das Endgerät verarbeitete Informationen zum Bediener des Fahrzeugs. Die Offenbarung kann implementiert werden, indem ein Verbinder in dem Standard-Scannerport am Fahrzeug installiert wird. Der Verbinder umfasst eine drahtlose Verbindung, die eine Verbindung mit einem herkömmlichen Fahrzeug-Scanner emuliert, indem Steuersignale an den entsprechenden Leitern an dem Scannerport erzeugt werden.
• Die US-Patentanmeldung 2013/0204484 offenbart allgemein ein Mikroprozessorausführbares Diagnostikmodul, betreibbar zum Empfangen eines Signals hinsichtlich einer Warnung und/oder eines Fehlers von einer Fahrzeugkomponente und Auswählen eines Ziels für das Signal aus mehreren Zielen. Die mehreren Ziele umfassen ein oder mehrere eines Fahrzeugeingabe-/Ausgabesystems zum Präsentieren der Warnung und/oder des Fehlers für einen Fahrzeuginsassen, einen Notdienstanbieter, einen Notdienst, einen Hersteller des Fahrzeugs, eine sich in der Nähe eines aktuellen Fahrzeugorts befindende Serviceeinrichtung und einen entfernt angeordneten Diagnostikdienst zum Diagnostizieren einer Ursache des Warn- und/oder Fehlersignals.
• Bei der ersten beispielhaften Ausführungsform besitzt ein Fahrzeugdatenverarbeitungssystem einen Computerprozessor in Kommunikation mit einem drahtlosen Sendeempfänger, dergestalt, dass der drahtlose Sendeempfänger zu Kommunikation mit einer entfernt von dem Prozessor angeordneten drahtlosen Kommunikationsvorrichtung fähig ist. Der Computerprozessor ist dafür ausgelegt, durch die drahtlose Kommunikationsvorrichtung eine oder mehrere Anweisungen von einem entfernten Server zu empfangen. Der Prozessor kann ein Speicherlesen aus einem oder mehreren Modulen auf der Basis der einen oder der mehreren Anweisungen anfordern, wobei das Speicherlesen mindestens eine Variable umfasst, die in einem Fahrzeugnetzwerk nicht verfügbar ist. Der Prozessor kann auf der Basis des Speicherlesens aus dem einen oder mehreren Modulen Daten empfangen und die Daten zu dem entfernten Server senden.
• Bei der zweiten beispielhaften Ausführungsform besitzt ein Server einen Computerprozessor in Kommunikation mit einem drahtlosen Sendeempfänger, dergestalt, dass der drahtlose Sendeempfänger zu Kommunikation mit einem entfernt von dem Prozessor angeordneten Fahrzeug fähig ist. Der Computerprozessor ist dafür ausgelegt, eine oder mehrere Anweisungen, darunter einen Trigger eines Fahrzeugereignisses, zu empfangen, um zu bestimmen, wann das Sammeln eines Datensatzes zu beginnen ist. Der Prozessor kann die eine oder mehreren Anweisungen zu dem Fahrzeug senden. Der Prozessor kann auf der Basis der einen oder mehreren Anweisungen ein Speicherlesen aus einem oder mehreren Modulen abrufen, wobei das Speicherlesen mindestens eine Variable umfasst, die in einem Fahrzeugnetzwerk nicht verfügbar ist. Der Prozessor kann mindestens einen Teil des Datensatzes ausgeben.
• Bei der dritten beispielhaften Ausführungsform zeichnet ein Speichermedium Prozessoranweisungen auf, die einen Prozessor dafür konfigurieren, Anweisungen durch eine drahtlose Kommunikationsvorrichtung von einem entfernten Server zu empfangen. Die Anweisungen können, aber ohne Beschränkung darauf, einen Trigger umfassen, der angibt, wann mit dem Sammeln eines Datensatzes zu beginnen ist. Der Prozessor kann auf der Basis der Anweisungen ein Datenlesen aus einem Modul anfordern, wobei mindestens ein Teil der Daten in einem Fahrzeugnetzwerk nicht verfügbar ist. Die Anweisungen können es dem Prozessor erlauben, die Daten zu dem entfernten Server zu senden.
• 1 zeigt eine beispielhafte Blocktopologie für ein fahrzeuggestütztes Datenverarbeitungssystem für ein Fahrzeug;
• 2 zeigt eine beispielhafte Blocktopologie für ein fahrzeuggestütztes Datenverarbeitungssystem, das mit einem entfernten Server kommuniziert;
• 3 ist ein Flussdiagramm eines beispielhaften Prozesses zur Implementierung von Ausführungsformen der vorliegenden Offenbarung;
• 4 ist ein Flussdiagramm, das eine Technikervorrichtung zur Kommunikation mit einem Fahrzeugdatenverarbeitungssystem darstellt;
• 5 ist ein Flussdiagramm, das einen entfernten Server zur Kommunikation einer technischen Vorrichtung zu einem Fahrzeugdatenverarbeitungssystem darstellt;
• 6 ist eine beispielhafte Blocktopologie für eine Computervorrichtung mit einer oder mehreren angepassten Anwendungen, die zur Prognostik eines Fahrzeugdatenverarbeitungssystems verwendet werden;
• 7A ist eine beispielhafte graphische Benutzeroberfläche (GUI) zum Empfangen von Daten von einer oder mehreren in einem Fahrzeug ausgeführten Diagnostikroutinen;
• 7B ist eine beispielhafte graphische Benutzeroberfläche (GUI) zum Anzeigen von Daten von einer oder mehreren in einem Fahrzeug ausgeführten Diagnostikroutinen;
• 8 ist einen beispielhafte GUI des Auswählens einer oder mehrerer Datenkennungen von einer Vorrichtung zur Verwendung bei einer Diagnostikanweisung und die zu einem Fahrzeugdatenverarbeitungssystem gesendet werden;
• 9 ist eine beispielhafte GUI des Auswählens von Diagnostikerfassungstriggern zur Verwendung bei einer Diagnostikanweisung und die zu einem Fahrzeugdatenverarbeitungssystem gesendet werden; und
• 10 ist ein Flussdiagramm einer Diagnostikvorrichtung zum Erzeugen und Senden eines Anweisungssatzes zum Erfassen einer oder mehrerer Variablen in einem Fahrzeugdatenverarbeitungssystem.
• 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; bestimmte Merkmale können übertrieben oder minimiert sein, um Einzelheiten bestimmter Komponenten zu zeigen. Hier offenbarte spezifische strukturelle und Funktionsdetails sind deshalb nicht als Beschränkung aufzufassen, sondern lediglich als repräsentative Grundlage, um Fachleute zu lehren, die vorliegende Erfindung verschiedenartig einzusetzen.
• 1 zeigt eine beispielhafte Blocktopologie für ein fahrzeuggestütztes Datenverarbeitungssystem 1 (VCS) für ein Fahrzeug 31. Ein Beispiel für ein solches fahrzeuggestütztes Datenverarbeitungssystem 1 ist das von THE FORD MOTOR COMPANY hergestellte System SYNC. Ein mit einem fahrzeuggestützten Datenverarbeitungssystem befähigtes Fahrzeug kann eine sich in dem Fahrzeug befindende visuelle Frontend-Schnittstelle 4 enthalten. Der Benutzer kann auch in der Lage sein, mit der Schnittstelle in Interaktion zu treten, wenn sie zum Beispiel mit einem berührungsempfindlichen Bildschirm ausgestattet ist. Bei einer anderen beispielhaften Ausführungsform erfolgt die Interaktion durch Tastenbetätigungen, Sprachdialogsysteme mit automatischer Spracherkennung und Sprachsynthese.
• Bei der in 1 gezeigten beispielhaften Ausführungsform 1 steuert ein Prozessor 3 mindestens einen Teil des Betriebs des fahrzeuggestützten Datenverarbeitungssystems. Der Prozessor ist in dem Fahrzeug vorgesehen und erlaubt Verarbeitung von Befehlen und Routinen an Bord. Ferner ist der Prozessor sowohl mit nichtpersistentem 5 als auch mit persistentem Speicher 7 verbunden. Bei dieser beispielhaften Ausführungsform ist der nichtpersistente Speicher Direktzugriffsspeicher (RAM) und der persistente Speicher ein Festplattenlaufwerk (HDD) oder Flash-Speicher. Persistenter (nichtflüchtiger) Speicher kann im Allgemeinen alle Formen von Speicher umfassen, die Daten aufrechterhalten, wenn ein Computer oder eine andere Vorrichtung heruntergefahren wird. Dazu gehören, aber ohne Beschränkung darauf, HDDs, CDs, DVDs, Magnetbänder, Halbleiterlaufwerke, tragbare USB-Laufwerke und eine beliebige andere Form von persistentem Speicher.
• Der Prozessor ist auch mit einer Anzahl von verschiedenen Eingängen ausgestattet, die es dem Benutzer erlauben, sich an den Prozessor anzuschalten. Bei dieser beispielhaften Ausführungsform sind ein Mikrofon 29, ein Zusatzeingang 25 (für den Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der ein Touchscreen-Bildschirm sein kann, und ein BLUETOOTH-Eingang 15 vorgesehen. Außerdem ist ein Eingangsselektor 51 vorgesehen, um es einem Benutzer zu erlauben, zwischen verschiedenen Eingängen zu wechseln. Eingaben sowohl in den Mikrofon- als auch in den Zusatzverbinder werden durch einen Umsetzer 27 von analog in digital umgesetzt, bevor sie zu dem Prozessor geleitet werden. Obwohl es nicht gezeigt ist, können zahlreiche der Fahrzeugkomponenten und Hilfskomponenten in Kommunikation mit dem VCS ein Fahrzeugnetzwerk (wie etwa, aber ohne Beschränkung darauf, einen CAN-Bus) verwenden, um Daten zu und von dem VCS (oder Komponenten davon) weiterzuleiten.
• Ausgaben des Systems können, aber ohne Beschränkung darauf, ein visuelles Display 4 und einen Lautsprecher 13 oder Stereoanlagenausgang umfassen. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal durch einen Digital-Analog-Umsetzer 9 von dem Prozessor 3. Ausgaben können auch an eine entfernte BLUETOOTH-Einrichtung erfolgen, wie etwa die PND 54 oder eine USB-Einrichtung, wie etwa die Fahrzeugnavigationseinrichtung 60, entlang der bei 19 bzw. 21 gezeigten bidirektionalen Datenströme.
• Bei einer beispielhaften Ausführungsform verwendet das System 1 den BLUETOOTH-Sendeempfänger 15 zum Kommunizieren 17 mit der nomadischen Einrichtung 53 (z. B. Mobiltelefon, Smartphone, PDA oder einer beliebigen anderen Einrichtung mit Konnektivität zu einem drahtlosen entfernten Netzwerk) eines Benutzers. Die nomadische Einrichtung kann dann verwendet werden, um zum Beispiel durch Kommunikation 55 mit einem Zellularmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. Bei bestimmten Ausführungsformen kann der Mast 57 ein WiFi-Zugangspunkt sein.
• Beispielhafte Kommunikation zwischen der nomadischen Einrichtung und dem BLUETOOTH-Sendeempfänger wird durch das Signal 14 repräsentiert.
• Die Paarung einer nomadischen Einrichtung 53 und des BLUETOOTH-Sendeempfängers 15 kann durch eine Taste 52 oder ähnliche Eingabe befohlen werden. Dementsprechend wird der CPU mitgeteilt, dass der Onboard-BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einer nomadischen Einrichtung gepaart wird.
• Daten können zum Beispiel unter Verwendung eines Datenplans, von Data-over-Voice oder von DTMF-Tönen, die mit der nomadischen Einrichtung 53 assoziiert sind, zwischen der CPU 3 und dem Netzwerk 61 übermittelt werden. Als Alternative kann es wünschenswert sein, ein Onboard-Modem 63 vorzusehen, das eine Antenne 18 aufweist, um Daten zwischen der CPU 3 und dem Netzwerk 61 über das Sprachband zu übermitteln 16. Die nomadische Einrichtung 53 kann dann dazu verwendet werden, zum Beispiel durch Kommunikation 55 mit einem Zellularmast 57 mit einem Netzwerk 61 außerhalb des Fahrzeugs 31 zu kommunizieren 59. Bei bestimmten Ausführungsformen kann das Modem 63 Kommunikation 20 mit dem Mast 57 zur Kommunikation mit dem Netzwerk 61 herstellen. Als nicht einschränkendes Beispiel kann das Modem 63 ein USB-Zellularmodem sein und die Kommunikation 20 kann Zellularkommunikation sein.
• Bei einer beispielhaften Ausführungsform ist der Prozessor mit einem Betriebssystem ausgestattet, das eine API zur Kommunikation mit Modem-Anwendungssoftware umfasst. Die Modem-Anwendungssoftware kann auf ein eingebettetes Modul oder Firmware auf dem BLUETOOTH-Sendeempfänger zugreifen, um drahtlose Kommunikation mit einem entfernten BLUETOOTH-Sendeempfänger (wie etwa dem in einer nomadischen Einrichtung anzutreffenden) herzustellen. BLUETOOTH ist eine Teilmenge der Protokolle IEEE 802 PAN (Personal Area Network). Die Protokolle IEEE 802 LAN (Lokales Netzwerk) umfassen WiFi und besitzen beträchtliche Kreuzfunktionalität mit IEEE 802 PAN. Beide eignen sich für drahtlose Kommunikation in einem Fahrzeug. Ein anderes Kommunikationsmittel, das in diesem Bereich verwendet werden kann, sind optische Freiraumkommunikation (wie etwa IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
• Bei einer anderen Ausführungsform umfasst die nomadische Einrichtung 53 ein Modem für Sprachband- oder Breitband-Datenkommunikation. Bei der Data-over-Voice-Ausführungsform kann eine als Frequenzmultiplexen bekannte Technik implementiert werden, wenn der Eigentümer der nomadischen Einrichtung über die Einrichtung sprechen kann, während Daten transferiert werden. Zu anderen Zeiten, wenn der Eigentümer die Einrichtung nicht benutzt, kann der Datentransfer die gesamte Bandbreite verwenden (in einem Beispiel 300 Hz bis 3,4 kHz). Obwohl Frequenzmultiplexen für analoge zellulare Kommunikation zwischen dem Fahrzeug und dem Internet üblich sein kann und weiterhin verwendet wird, wurde es zum großen Teil durch Hybride von CDMA (Code Domain Multiple Access), TDMA (Time Domain Multiple Access), SDMA (Space-Domain Multiple Access) für digitale zellulare Kommunikation ersetzt. Diese sind alle ITU IMT-2000 (3G) genügende Standards und bieten Datenraten bis zu 2 mbs für stationäre oder gehende Benutzer und 385 kbs für Benutzer in einem sich bewegenden Fahrzeug. 3G-Standards werden nunmehr durch IMT-Advanced (4G) ersetzt, das für Benutzer in einem Fahrzeug 100 mbs und für stationäre Benutzer 1 gbs bietet. Wenn der Benutzer über einen mit der nomadischen Einrichtung assoziierten Datenplan verfügt, ist es möglich, dass der Datenplan Breitband-Übertragung ermöglicht und das System eine viel größere Bandbreite verwenden könnte (wodurch der Datentransfer beschleunigt wird). Bei einer weiteren Ausführungsform wird die nomadische Einrichtung 53 durch eine (nicht gezeigte) zellulare Kommunikationseinrichtung ersetzt, die in das Fahrzeug 31 installiert ist. Bei einer weiteren Ausführungsform kann die ND 53 eine Einrichtung eines drahtlosen lokalen Netzwerks (LAN) sein, die zum Beispiel (und ohne Beschränkung) über ein 802.11g-Netzwerk (d. h. WiFi) oder ein WiMax-Netzwerk kommunizieren kann.
• Bei einer Ausführungsform können ankommende Daten durch die nomadische Einrichtung über Data-over-Voice oder Datenplan geleitet werden, durch den Onboard-BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs. Im Fall bestimmter temporärer Daten können die Daten zum Beispiel auf der HDD oder einem anderen Speichermedium 7 gespeichert werden, bis die Daten nicht mehr benötigt werden.
• Zu zusätzlichen Quellen, die an das Fahrzeug angeschaltet werden können, gehören eine persönliche Navigationseinrichtung 54, die zum Beispiel eine USB-Verbindung 56 und/oder eine Antenne 58 aufweist, eine Fahrzeugnavigationseinrichtung 60 mit einem USB 62 oder einer anderen Verbindung, eine Onboard-GPS-Einrichtung 24 oder ein (nicht gezeigtes) Fernnavigationssystem, das Konnektivität mit dem Netzwerk 61 aufweist. USB ist eines einer Klasse von Serienvernetzungsprotokollen. IEEE 1394 (FireWireTM (Apple), i.LINK^TM (Sony) und Lynx^TM (Texas Instruments)), serielle Protokolle der EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Standards von Einrichtung zu Einrichtung. Die meisten der Protokolle können entweder für elektrische oder optische Kommunikation implementiert werden.
• Ferner könnte sich die CPU in Kommunikation mit vielfältigen anderen Hilfseinrichtungen 65 befinden. Diese Einrichtungen können durch eine drahtlose 67 oder verdrahtete 69 Verbindung verbunden sein. Die Hilfseinrichtung 65 kann, aber ohne Beschränkung darauf, persönliche Medien-Player, drahtlose Gesundheitseinrichtungen, tragbare Computer und dergleichen umfassen.
• Außerdem oder als Alternative könnte die CPU zum Beispiel unter Verwendung eines Sendeempfängers für WiFi (IEEE 803.11) 71 mit einem fahrzeuggestützten drahtlosen Router 73 verbunden werden. Dadurch könnte die CPU sich mit entfernten Netzwerken in der Reichweite des lokalen Routers 73 verbinden.
• Zusätzlich dazu, dass beispielhafte Prozesse durch ein Fahrzeugdatenverarbeitungssystem ausgeführt werden, das sich in einem Fahrzeug befindet, können bei bestimmten Ausführungsformen die beispielhaften Prozesse durch ein Datenverarbeitungssystem in Kommunikation mit einem Fahrzeugdatenverarbeitungssystem ausgeführt werden. Ein solches System kann eine drahtlose Einrichtung (zum Beispiel, aber ohne Beschränkung darauf, ein Mobiltelefon) oder ein entferntes Datenverarbeitungssystem (zum Beispiel, aber ohne Beschränkung darauf, ein Server), das durch die drahtlose Einrichtung verbunden ist, einschließen, aber ohne Beschränkung darauf. Kollektiv können solche Systeme als ein fahrzeugassoziiertes Datenverarbeitungssystem (VACS) bezeichnet werden. Bei bestimmten Ausführungsformen können bestimmte Komponenten des VACS abhängig von der bestimmten Implementierung des Systems bestimmte Teile eines Prozesses ausführen. Zum Beispiel und ohne Beschränkung ist es, wenn ein Prozess einen Schritt des Sendens oder Empfangens von Informationen mit einer gepaarten drahtlosen Einrichtung aufweist, dann ist es wahrscheinlich, dass die drahtlose Einrichtung den Prozess nicht ausführt, da die drahtlose Einrichtung nicht Informationen mit sich selbst ”senden und empfangen” würde. Für Durchschnittsfachleute ist verständlich, wann es nicht angemessen ist, ein bestimmtes VACS auf eine gegebene Lösung anzuwenden. Bei allen Lösungen wird in Betracht gezogen, dass mindestens das Fahrzeugdatenverarbeitungssystem (VCS), das sich in dem Fahrzeug selbst befindet, in der Lage ist, die beispielhaften Prozesse auszuführen.
• 2 zeigt eine beispielhafte Blocktopologie für ein fahrzeuggestütztes Datenverarbeitungssystem, das mit einem entfernten Server kommuniziert. Bei einer Ausführungsform der vorliegenden Offenbarung kann eine nomadische Vorrichtung 208, die unter Verwendung von BLUETOOTH-Technologie mit dem VCS 204 kommuniziert 216, drahtlose Kommunikation 212 mit einem terrestrischen Mast 210 herstellen. Der terrestrische Mast 210 kann seinerseits durch ein Telefonvermittlungsnetz Kommunikation 222 mit einem entfernten Server 214 herstellen. Der entfernte Server 214 kann sich in Kommunikation mit einem oder mehreren voneinander entfernt angeordneten Endgeräten 228 befinden. Das eine oder die mehreren Endgeräte 228 können sich an mehreren Orten befinden, darunter, aber ohne Beschränkung darauf, in einer Vertragshändlerwerkstatt, technischen Einrichtung und/oder bei einem technischen Servicevertreterbüro.
• Das VCS 204 kann sich mit einer drahtlosen Vorrichtung oder einem durch die drahtlose Vorrichtung verbundenen entfernten Datenverarbeitungssystem zur Herstellung von Kommunikation mit dem entfernten Server 214 verbinden. Die drahtlose Vorrichtung wäre zum Beispiel, aber ohne Beschränkung darauf, ein eingebettetes Zellularmodem, eine eingebette WiFi-Vorrichtung, ein Bluetooth-Sender, mit dem Telefon verbundene Nahfeldkommunikation, eine hereingebrachte zellulare Vorrichtung wie ein USB-Modem, MiFi, ein Smartphone 208, das durch SYNC oder eine andere Bluetooth-Paarungsvorrichtung mit dem Fahrzeug verbunden werden kann, oder ein PC-Netzwerk, das durch SYNC oder eine andere Bluetooth-Paarungsvorrichtung mit dem Fahrzeug verbunden werden kann. Durch Verwendung der drahtlosen Vorrichtung kann das VCS 204 drahtlos eine Datenübertragung mit dem entfernten Server 214 kommunizieren. Nachdem das Fahrzeugsystem Kommunikation mit den entfernten Server 214 befähigt hat, können dann Informationen durch das VCS von dem einen oder den mehreren Endgeräten 228 und/oder Diagnostikvorrichtungen 230 in Kommunikation 224, 232 mit dem Server gesendet und empfangen werden.
• In einem anderen Beispiel kann ein eingebettetes Mobiltelefon in dem VCS 204 unter Verwendung eines drahtlosen Sendeempfängers 206 direkte Kommunikation 220 mit einem terrestrischen Mast 210 herstellen. Das VCS 204 mit einem eingebetteten Telefon kann unter Verwendung der terrestrischen Mastverbindung 222 Kommunikation mit dem entfernten Server 214 herstellen und damit zu einem oder mehreren Modulen 203 von einer Vorrichtung 230, die mit dem entfernten Server verbunden ist 232, heraufgeladene und heruntergeladene Daten erlauben.
• Das VCS 204 kann auch mit einem Netzwerk kommunizieren, das zugeordnete Speicherung aufweist, das Host für mehrere Webseiten für Internetzugang durch mehrere Browser ist, darunter, aber ohne Beschränkung darauf, Fertigungsanlagen, Vertragshändler, Servicewerkstätten, OEM (Original Equipment Manufacturer) usw. Bestimmte Browser, wie etwa Mobiltelefonbesitzer, können Daten über das Internet zu Speicherung hochladen, und andere Browser, wie etwa ein OEM-Netzwerk, können Daten zum entfernten Server herunterladen. Die Daten können unter Verwendung mehrerer Arten von Übertragungsmedien hoch- und heruntergeladen werden, darunter, aber ohne Beschränkung darauf, Schmalband, Breitband und/oder das Voice-Over-Internet-Protokoll.
• Der entfernte Server 214 kann eine Übertragungsanforderung einer Diagnostikanweisung, die einen Teil von Daten umfasst, von dem einen oder den mehreren Modulen 203 in einem Fahrzeug 202 empfangen, darunter, aber ohne Beschränkung darauf, ein direktes Speicherlesen von Variablen, die nicht im Fahrzeugnetzwerk verfügbar sind. Ein Verfahren zum Senden dieser Informationen vom VCS zu dem Server wäre, aber ohne Beschränkung darauf, ein Inband-Modem oder Data-Ouer-Voice. Nachdem der entfernte Server 214 die Informationen empfängt, kann man einen oder mehrere Algorithmen verwenden, um die Daten zu unterbrechen, so dass die Fahrzeugidentifikationsnummer (VIN) mit den Daten verwendet wird, dergestalt, dass der entfernte Server die durch das Fahrzeug empfangenen Informationen auf der Basis der VIN organisieren und zu dem einen oder den mehreren Endgeräten 228 übermitteln kann.
• Die angeforderten und empfangenen Fahrzeugdaten können auch auf einem drahtlosen Diagnostikwerkzeug 230 in Kommunikation 232 mit dem entfernten Server 214 gesteuert werden. Nachdem die Menge von Daten von dem Fahrzeug 202 zu dem entfernten Server 214 gesendet wurden, können die Daten der jeweiligen VIN zugeordnet werden. Die empfangenen Daten von dem einen oder den mehreren Steuermodulen 203 in einem Fahrzeug 202 können durch das eine oder die mehreren Endgeräte 228 und/oder das drahtlose Diagnostikwerkzeug analysiert werden. Der entfernte Server 214 kann auf der Basis empfangener Eingaben von dem einen oder den mehreren Endgeräten 228 und/oder dem drahtlosen Diagnostikwerkzeug 230 eine oder mehrere Anweisungen zu dem VCS 204 senden, die eine Anforderung zusätzlicher Daten angeben.
• Das Fahrzeugdatenverarbeitungssystem 204 kann dafür ausgelegt sein, eine angepasste Anwendung zu empfangen, die Echtzeitzugriff auf den Fahrzeugkommunikationsbus erlauben kann. Die angepasste Anwendung kann Daten anfordern, darunter, aber ohne Beschränkung darauf, direkte Speicherlesungen einer Variablen, die sich auf einem spezifischen Modul befindet, einen Algorithmus, der die Sendung eines oder mehrerer Datenpunkte triggern kann, einen Hinweis, wann ein bestimmtes Manöver in dem Fahrzeugsystem stattgefunden hat, und/oder eine Kombination davon. Ein Produktingenieur, ein Servicetechniker und/oder ein Einsatz-Servicevertreter, der ein in Kommunikation mit dem entfernten Server 214 befindliches Endgerät 228 und/oder Diagnostikwerkzeug 230 verwendet, kann eine kundenspezifische Anwendung senden, um Variablen aus einem oder mehreren Modulen in dem Fahrzeugdatenverarbeitungssystem zu debuggen, zu entwickeln und/oder zu überwachen.
• Zum Beispiel kann ein Kunde einen Mangel an Leistungsfähigkeit an einem oder mehreren Fahrzeugmerkmalen oder -funktionen erfahren, ohne dass das Fahrzeug einen Diagnostikproblemcode setzt. Da das Fahrzeug über keine Instrumentation verfügt, kann ein Servicetechniker und/oder Ingenieur beim Untersuchen des einen oder der mehreren Module, die mit dem Mangel an Leistungsfähigkeit, den der Kunde mit dem Fahrzeugmerkmal/der Funktion/dem System erfährt, in Beziehung stehen können, eingeschränkt sein. Eine prognostische Anwendung kann es dem Techniker und/oder Ingenieur erlauben, eine Diagnostikroutine zu schreiben, die die Signale überwacht, die an dem Merkmal/der Funktion/dem System beteiligt sind, und einen oder mehrere Algorithmen laufen zu lassen, die dafür ausgelegt sind, einen spezifischen Datensatz zu erfassen. Die prognostische Anwendung kann es dem Ingenieur und/oder Techniker erlauben, Signale anzufordern, die mit einem oder mehreren Modulen in Beziehung stehen, die nicht in dem Fahrzeugnetzwerk übermittelt werden. Die prognostische Anwendung kann von einem entfernten Endgerät/einer entfernten Vorrichtung aus zu dem Fahrzeugdatenverarbeitungssystem gesendet werden. Das Fahrzeug kann an den Kunden zurückgegeben werden, während es dem Techniker und/oder Ingenieur gestattet wird, sich zu einem beliebigen Zeitpunkt auf der Basis der zu dem Fahrzeugdatenverarbeitungssystem gesendeten Diagnostikroutine drahtlos mit dem Fahrzeug zu verbinden und Variable(n) aus dem einen oder den mehreren Modulen zur Datenuntersuchung zu überwachen. Die Diagnostikroutine kann den Techniker und/oder Ingenieur darauf hinweisen, wenn irgendwelche der Triggerbedingungen, die die Kundenbeschwerde betreffen, erfüllt wurden, um die Ursache des Problems zu finden. Der Hinweis wäre zum Beispiel, aber ohne Beschränkung darauf, eine E-Mail, eine SMS und/oder eine Instant-Nachricht.
• In einem anderen Beispiel kann ein Kunde ein Fahrzeug besitzen, bei dem mehrere Kombinationen von Diagnostikfehlern gesetzt sind, die bewirken können, dass der Techniker die Ursache bei der tatsächlichen Komponente, dem tatsächlichen System, dem tatsächlichen Merkmal, der tatsächlichen Funktion und/oder dem tatsächlichen Subsystem, die bzw. das den einen oder die mehreren Fehler einleitet, nicht richtig oder klar finden kann. Der Techniker kann einen Servicevertreter kontaktieren, um eine oder mehrere angepasste Anwendungen zum Senden zu dem Fahrzeugdatenverarbeitungssystem des Kunden unter Verwendung drahtloser Technologie und/oder durch den Borddiagnostik-(OBD-)Verbinderport zu empfangen. Der Servicevertreter und/oder Techniker kann die Fahrzeugidentifikationsnummer des Kunden empfangen, um die eine oder mehreren angepassten Anwendungen unter Verwendung eines Endgeräts 228 und/oder von Servicewerkzeugen 230 durch den entfernten Server, der sich mit beidem in Kommunikation befindet, zu dem Fahrzeugdatenverarbeitungssystem 204 zu senden. Das Endgerät 228 und/oder die drahtlosen Servicewerkzeuge 230 können UEM-Authentifizierungssoftware laufenlassen, um unbefugten Zugriff auf das Fahrzeugdatenverarbeitungssystem zu verhindern.
• 3 ist ein Flussdiagramm eines beispielhaften Prozesses zur Implementierung von Ausführungsformen der vorliegenden Offenbarung. Das Verfahren wird gemäß einer oder mehreren Ausführungsformen unter Verwendung von in dem Fahrzeugsteuermodul enthaltenem Softwarecode implementiert. Bei anderen Ausführungsformen wird das Verfahren 300 in anderen Fahrzeugsteuerungen oder über mehrere Fahrzeugsteuerungen verteilt implementiert.
• Wieder mit Bezug auf 3 wird im Verlauf der Besprechung des Verfahrens auf das Fahrzeug und seine in 1 dargestellten Komponenten Bezug genommen, um das Verständnis verschiedener Aspekte der vorliegenden Offenbarung zu erleichtern. Das Verfahren zur Überwachung eines oder mehrerer Module in einem Fahrzeug kann durch einen Computeralgorithmus, maschinenausführbaren Code oder Softwareanweisungen implementiert werden, die in eine geeignete programmierbare Logikvorrichtung(en) des Fahrzeugs programmiert werden, wie etwa das Fahrzeugsteuermodul, das Fahrzeugkommunikationsmodul, eine andere Steuerung in Kommunikation mit dem Fahrzeugdatenverarbeitungssystem oder eine Kombination davon. Obwohl die in dem Flussdiagramm 300 gezeigten verschiedenen Schritte scheinbar in einer chronologischen Sequenz auftreten, können mindestens bestimmte der Schritte in einer anderen Reihenfolge auftreten, und bestimmte Schritte können gleichzeitig oder überhaupt nicht ausgeführt werden.
• Das Fahrzeugdatenverarbeitungssystem kann dafür ausgelegt sein, eine Zellularstrecke zu erlauben, die den Kunden/Techniker durch eine Cloud mit dem Fahrzeugsystem verbindet. Die Zellularstreckenverbindung mit dem Fahrzeug kann Ferndiagnostikprogramme erlauben, die es einem Servicetechniker, Ingenieur und/oder Kunden erlauben können, über Diagnostikzugriff auf das gesamte Fahrzeugdatenverarbeitungssystem zu verfügen. Die Ferndiagnostikfunktionalität zum Fahrzeugdatenverarbeitungssystem ermöglicht einem Ingenieur, der eine mobile Datenverarbeitungsvorrichtung verwendet, über Diagnostikzugriff auf ein oder mehrere Fahrzeuge zu verfügen. Die mobile Datenverarbeitungsvorrichtung wäre zum Beispiel, aber ohne Beschränkung darauf, Verwendung eines Laptop, eines Smartphone und/oder Tablet. Das eine oder die mehreren Fahrzeuge wären zum Beispiel, aber ohne Beschränkung darauf, eine gesamte Entwicklungsflotte.
• Das Fahrzeugdatenverarbeitungssystem kann einen drahtlosen Sendeempfänger umfassen, der Kommunikation mit einer entfernt vom System angeordneten drahtlosen Vorrichtung ermöglicht. Der drahtlose Sendeempfänger wäre zum Beispiel, aber ohne Beschränkung darauf, ein eingebettetes Zellularmodem, eine eingebettete WiFi-Vorrichtung, ein Bluetooth-Sender, mit Telefon verbundene Nahfeldkommunikation, eine hereingebrachte Zellularvorrichtung wie ein USB-Modem, MiFi, ein Smartphone, das durch SYNC oder eine anderen Bluetooth-Paarungsvorrichtung mit dem Fahrzeug verbunden werden kann, oder ein PC-Netzwerk, das durch SYNC oder eine andere Bluetooth-Paarungsvorrichtung mit dem Fahrzeug verbunden werden kann. Die entfernt angeordnete drahtlose Vorrichtung kann zum Beispiel, aber ohne Beschränkung darauf, einen entfernten Server umfassen.
• Im Schritt 302 kann sich das Fahrzeugdatenverarbeitungssystem unter Verwendung von BLUETOOTH-Technologie oder einer USB-Verbindung mit einer Kommunikationsvorrichtung verbinden. Unter Verwendung der verbundenen Kommunikationsvorrichtung kann das Fahrzeugdatenverarbeitungssystem Kommunikation mit dem entfernten Server herstellen (Schritt 304).
• Im Schritt 306 kann, sobald das Fahrzeugdatenverarbeitungssystem Kommunikation mit dem entfernten Server hergestellt hat, das System die Fahrzeugidentifikationsnummer (VIN) senden. Das Fahrzeugdatenverarbeitungssystem kann eine Menge von Anweisungen an eine Vorrichtung ausgeben, die einem Servicetechniker und/oder Ingenieur Zugriff dazu erlaubt, eine oder mehrere Variablen in dem System zu überwachen, die im Controller Area Network (z. B. CAN-Bus) übermittelt werden. Einem Servicetechniker und/oder Ingenieur kann es erlaubt sein, Zugriff zur Kommunikation mit dem Fahrzeug unter Verwendung der Vorrichtung anzufordern. Die Vorrichtung kann drahtlos auf das VCS unter Verwendung eines entfernten Servers zugreifen. Der Servicetechniker und/oder Ingenieur kann ein oder mehrere Servicewerkzeuge verwenden, darunter, aber ohne Beschränkung darauf, ein Computerterminal, einen Laptop, ein Smartphone und/oder ein Tablet, die sich an einem von dem Fahrzeug entfernten Ort befinden können. Das eine oder die mehreren Servicewerkzeuge können Authentifizierungssoftware umfassen, um unbefugten Zugriff auf das Fahrzeugdatenverarbeitungssystem zu verhindern.
• Das eine oder die mehreren Servicewerkzeuge können durch den entfernten Server eine Anforderung zu dem Fahrzeugdatenverarbeitungssystem senden, Diagnostikcodes aus dem Fahrzeug zu ziehen. Das Fahrzeugdatenverarbeitungssystem kann eine Anforderung empfangen, Diagnostikcodes zu ziehen (Schritt 308).
• Im Schritt 310 kann das Fahrzeugdatenverarbeitungssystem bestimmen, ob irgendwelche Fehler gerade aktiv sind und/oder vorgeschichtlich in dem einen oder den mehreren Modulen im Fahrzeug gespeichert wurden. Das Fahrzeugdatenverarbeitungssystem kann die Diagnostikcodes, die aktiv und/oder vorgeschichtlich gespeichert sind, zu dem entfernten Server senden (Schritt 312). Der Servicetechniker und/oder Ingenieur kann den einen oder die mehreren Diagnostikcodes empfangen und unter Verwendung von Datenkennung(en) (DID) im Fahrzeugnetzwerk und/oder eines direkten Speicherlesens (DMR) einer oder mehrerer Variablen in einem Modul, die nicht über das Fahrzeugnetzwerk übermittelt werden, bestimmen, ob die den Codes zugeordneten Module weiter zu untersuchen sind. Nachdem das Fahrzeugdatenverarbeitungssystem den einen oder die mehreren Diagnostikcodes gesendet hat, kann es unter Verwendung einer DMR-Anforderung von dem einen oder den mehreren Servicewerkzeugen, die durch den entfernten Server kommunizieren, eine Anforderung empfangen, ein oder mehrere Module und/oder Komponenten zu untersuchen (Schritt 314).
• Im Schritt 316 kann das Fahrzeugdatenverarbeitungssystem Genehmigung senden, es dem einen oder den mehreren Servicewerkzeugen zu erlauben, eine Fernprognostik freizugeben. Das Fahrzeugdatenverarbeitungssystem kann eine Diagnostikroutine vom entfernten Server empfangen, die es dem einen oder den mehreren Modulen erlaubt, weitere Informationen in das Fahrzeugnetzwerk zu legen (Schritt 318). Die Diagnostikroutine kann durch einen Servicetechniker unter Verwendung eines Servicetechnikerwerkzeugs programmiert werden, das zum Beispiel, aber ohne Beschränkung darauf, eine konfigurierbare DID- und/oder DMR-Variablenliste für ein oder mehrere Module im Fahrzeug sein kann. Das VCS kann es dem einen oder den mehreren Servicewerkzeugen erlauben, die Diagnostikroutine zu überwachen, darunter, aber ohne Beschränkung darauf, eine oder mehrere Variablen, die in einem Fahrzeugnetzwerk nicht verfügbar sind (Schritt 320).
• Die eine oder mehreren Variablen, die nicht in einem Fahrzeugnetzwerk verfügbar sind, wären zum Beispiel, aber ohne Beschränkung darauf, CPU-Auslastung, Flag-Status, Zwischenspannungen, ungefilterte Sensorlesungen, Diagnostikfehlerzähler, Timer, Diagnostikfehlerzähler und/oder andere Variablen in Bezug auf den Betrieb einer Komponente, eines Subsystems und/oder Systems. Zum Beispiel kann ein Modul die Übermittlung von einundzwanzig (21) DID-Variablen über ein Fahrzeugnetzwerk erlauben, während zusätzliche vierhundert (400) Direktspeicherlesevariablen in der Modulsoftware vorliegen, die beim Treffen von Entscheidungen für diese Komponente, dieses Subsystem und/oder System verwendet werden. In einem anderen Beispiel können die DID einzeln über das Fahrzeugnetzwerk übermittelt werden, die Diagnostikroutine kann jedoch dafür ausgelegt sein, den Empfang/die Aufzeichnung der angeforderten Daten im selben Zeitrahmen zu erlauben, und nicht auf der Basis der Ablieferung über das Fahrzeugnetzwerk versetzt.
• Im Schritt 322 kann das Fahrzeugdatenverarbeitungssystem auf der Basis mindestens eines Triggers, von Timern und/oder Flags, die in den Diagnostikanweisungen programmiert sind, einen Datensatz sammeln. Zum Beispiel kann der Servicetechniker eine Diagnostikroutine programmieren, um eine oder mehrere Variablen aufzuzeichnen, wenn ein Fahrzeugparameter gesetzt wird. Der Fahrzeugparameter wäre zum Beispiel, aber ohne Beschränkung darauf, Fahrzeuggeschwindigkeit, Motortemperatur, Batterietemperatur, Hybridmodus und/oder Motorumdrehungen pro Minute. Nachdem der Trigger gesetzt ist, beginnt die Diagnostikroutine mit dem Sammeln des Datensatzes, und das Fahrzeugdatenverarbeitungssystem kann die Daten zum entfernten Server senden, wodurch es dem Servicewerkzeug erlaubt wird, zu analysieren.
• 4 ist ein Flussdiagramm einer Technikervorrichtung zur Kommunikation mit einem Fahrzeugdatenverarbeitungssystem. Die Technikervorrichtung wäre zum Beispiel, aber ohne Beschränkung darauf, ein Smartphone, ein Laptop und/oder ein OEM-Vertragshändlerservice-/-diagnostikwerkzeug. Das OEM-Vertragshändlerservice-/-diagnostikwerkzeug kann, aber ohne Beschränkung darauf, einen OBD-Scanner umfassen. Die Technikervorrichtung kann unter Verwendung drahtloser Technologie und/oder einer festverdrahteten Verbindung mit einem Fahrzeug kommunizieren.
• Im Schritt 402 kann eine Technikervorrichtung auf der Basis einer oder mehrerer Fahrzeugidentifikationsaufzeichnungen, darunter, aber ohne Beschränkung darauf, eine Fahrzeugidentifikationsnummer(n), eine eingebettete Telefonnummer, eine IP-Adresse (Internetprotokoll) des eingebetteten Modems und/oder eine MAC-Adresse (Media Access Control) anfordern, mit einem Fahrzeug zu kommunizieren. Die Technikervorrichtung kann unter Verwendung eines entfernten Servers mit dem Fahrzeug kommunizieren, um die Kommunikation von der Vorrichtung zum VCS zu überbrücken.
• Indem das VCS zum Beispiel ein mit dem Fahrzeug integriertes drahtloses Modul an Bord verwendet, kann das System durch drahtlose Technologie (z. B. Zellulartechnologie) mit einem Cloud-Datenverarbeitungsdienst kommunizieren. Ein Servicetechniker, Technik und/oder ein Fahrzeugbesitzer kann eine Softwareanwendung auf der technischen Vorrichtung (z. B. eine Smartphone-Anwendung) oder Website verwenden, um mit dem sicheren Cloud-Datenverarbeitungsserver zu kommunizieren, wodurch hochaktueller Zugriff auf Fahrzeuginformationen und eine vollständige Suite ferngesteuerter Funktionalität unterstützt wird, darunter, aber ohne Beschränkung darauf, die Anforderung von Variablen, die nicht über ein Fahrzeugnetzwerk übermittelt werden.
• Im Schritt 404 kann die Technikervorrichtung eine Bestätigung empfangen, dass sie sich in Kommunikation mit einem Fahrzeug befindet. Wenn sich die Vorrichtung in Kommunikation mit dem Fahrzeug befindet, kann sie eine oder mehrere Angabevariablen empfangen, um zu identifizieren, dass das Werkzeug mit dem korrekten Fahrzeug verbunden ist. Die Vorrichtung kann die im Fahrzeugdatenverarbeitungssystem gespeicherte VIN-Nummer empfangen, um sicherzustellen, dass die Vorrichtung mit dem korrekten Fahrzeug kommuniziert (Schritt 406).
• Das Fahrzeugdatenverarbeitungssystem kann dem Fahrer eine oder mehrere Nachrichten anzeigen, bevor Verbindung des Technikerwerkzeugs erlaubt wird. Zum Beispiel kann die Vorrichtung eine Anforderung senden, sich mit einem Fahrzeug zu verbinden, und das VCS kann diese Anforderung durch Anzeigen einer Nachricht, die die Anforderung der Vorrichtung, sich zu verbinden, angibt, dem Fahrer übermitteln. Der Fahrer kann die Anforderung von der Vorrichtung, sich zu verbinden, erlauben oder zurückweisen, indem er einen oder mehrere Eingänge unter Verwendung der Infotainmentsystem-Benutzeroberfläche auswählt. In einem anderen Beispiel kann der Fahrer anfänglich das VCS dafür einrichten, Verbindung von einer oder mehreren ausgewählten Technikervorrichtungen zu erlauben.
• Im Schritt 408 kann die Technikervorrichtung eine Anforderung senden, Diagnostikcodes auf dem einen oder den mehreren Modulen, die mit dem VCS kommunizieren, zu lesen. Die Technikervorrichtung kann die Diagnostikcodes, die aktiv sind, sich in der Vorgeschichte befinden und/oder einen Zähler eingeleitet haben, empfangen, um einen Diagnostikcode zu setzen (Schritt 410). Die Technikervorrichtung kann bestimmen, ob irgendwelche Fehler gesetzt wurden, und es dem Ingenieur, Besitzer und/oder Servicetechniker die Möglichkeit erlauben, ein System weiter zu analysieren und/oder eine spezifische Diagnostikroutine zu entwickeln (Schritt 412).
• Im Schritt 414 kann die Technikervorrichtung auf der Basis des aus dem Fahrzeug empfangenen aktiven/vorgeschichtlichen Diagnostikcodes eine Anforderung senden, ein oder mehrere Systeme, Subsysteme und/oder eine oder mehrere Komponenten zu untersuchen. Das VCS kann die Anforderung, ein oder mehrere Module zu untersuchen, automatisch genehmigen und/oder das System kann eine Nachricht anzeigen, die den Fahrer um Genehmigung bittet. Wenn zum Beispiel die Vorrichtung einen aktiven Diagnostikcode in Bezug auf den Drosselkörper am Motor empfangen hat, kann der Servicetechniker zusätzliche Variablen in Bezug auf den Drosselkörper von dem Motorsteuermodul wünschen. Deshalb kann sich die Vorrichtung auf die Untersuchung von Informationen über das Motorsteuermodul in Bezug auf den Drosselkörper konzentrieren, darunter, aber ohne Beschränkung darauf, die Klappenstellung, Referenzspannung, Gaspedalposition und/oder Drosselsensorinformationen.
• Im Schritt 416 kann die Vorrichtung Fahrergenehmigung vom VCS empfangen, eine oder mehrere Komponenten zu untersuchen. Der Bediener der Vorrichtung kann auf der Basis der Kundenbeschwerde, der Diagnostikcode(s) und/oder der Systemleistungsfähigkeit eine spezifische Diagnostikroutine senden (Schritt 418). Als Fortsetzung des obigen Drosselkörper beispiels kann die Diagnostikroutine drosselbezogene Variablen umfassen, die nicht über das Fahrzeugnetzwerk gesendet werden, darunter, aber ohne Beschränkung darauf, Diagnostikzählervariablen (z. B. Positionssensor-Außerbereichszähler), Fehler-Flags, Massenluftflussvariablen und/oder Massen luftdruckvariablen.
• Bei 420 kann der Bediener der Technikervorrichtung über die Möglichkeit verfügen, die eine oder mehreren Variablen zu überwachen, die in den angeforderten Parametern enthalten sind, die über das Fahrzeugnetzwerk und/oder in der Diagnostikroutine verteilt sind. Zum Beispiel kann ein Ingenieur auf das Fahrzeug zugreifen und aktuelle Bedingungen überwachen und wie erforderlich Tests laufen lassen. In bestimmten Fällen kann ein Bediener in Sicht des Fahrzeugs verwendet werden, um physische Aufgaben auszuführen, wie etwa Fahren und Freigeben spezifischer Merkmale/Funktionen, während der entfernte Ingenieur Daten sammelt. Wenn der Bediener wählt, die Variablen in Echtzeit zu überwachen, kann die Vorrichtung weiter angemeldet bleiben und mit dem Fahrzeug kommunizieren (Schritt 422).
• Wenn im Schritt 424 der Bediener der Technikervorrichtung die Kommunikation mit dem Fahrzeug abmeldet, kann die Kundendiagnostik weiter im Fahrzeug ausgeführt werden. Wenn die Vorrichtung abgemeldet bleibt, kann die Diagnostikroutine einen Trigger umfassen, der dafür programmiert wurde, den bei einem bestimmten Fahrzeugereignis angeforderten Datensatz aufzuzeichnen, und die Vorrichtung kann die Daten empfangen, nachdem ein oder mehrere Trigger freigegeben wurden (Schritt 426).
• Im Schritt 428 kann, wenn die Vorrichtung abgemeldet ist, beim nächsten Anmelden zur Kommunikation mit dem Fahrzeug der Techniker die aufgezeichneten und im VCS abgespeicherten Diagnostikdaten empfangen. Zum Beispiel kann das Fahrzeug die Diagnostikroutine von der Technikervorrichtung empfangen, und der Kunde/Fahrer kann das Fahrzeug weiter benutzen. Die Diagnostikroutine/-anweisungen können weiter ausgeführt werden, ohne dass der Kunde/Fahrer unterbrochen wird und einen Vertragshändler oder eine Servicewerkstätte aufsuchen muss. Nachdem die Diagnostikroutine auf der Basis eines Parameters, darunter, aber ohne Beschränkung darauf, eines Triggers, Zählers und/oder Timers, den angeforderten Datensatz empfangen hat, kann das VCS die Vorrichtung benachrichtigen. Das VCS kann die Vorrichtung unter Verwendung mehrerer Verfahren benachrichtigen, darunter SMS-Nachrichten, E-Mail-Nachrichten und/oder Instant-Nachrichten.
• 5 ist ein Flussdiagramm eines entfernten Servers zur Kommunikation einer technischen Vorrichtung mit einem Fahrzeugdatenverarbeitungssystem. Der entfernte Server kann ein sicherer OEM-Server auf Cloud-Basis sein, was dabei hilft, Sicherheit zu garantieren, wenn die entfernte Vorrichtung über Kommunikationszugriff bei dem VCS verfügt. Der Server kann eine oder mehrere Datenbanken aufweisen, mit denen aus Fertigungsanlagen empfangene Informationen hinsichtlich Fahrzeuginformationen gespeichert werden, darunter Bauvorgeschichte, freigegebene Merkmale/Funktionen, Servicevorgeschichte, VIN, IP-Adresse, Adresse des eingebetteten Telefons und/oder MAC. Der Server kann sich mit einem oder mehreren Endgeräten in Kommunikation befinden, denen es erlaubt ist, Informationen hinsichtlich Fahrzeugbaudaten und/oder Anwendungsaktualisierungen für die technische(n) Vorrichtung(en) zu aktualisieren.
• Im Schritt 502 kann der Server eine Anforderung von einer drahtlosen Entwicklungs-/Diagnostikvorrichtung empfangen, die mit einem oder mehreren Fahrzeugen unter Verwendung eines Identifikationscodes kommunizieren möchte, darunter, aber ohne Beschränkung darauf, VIN, Identifikationsadresse des eingebetteten Telefons, IP-Adresse des eingebetteten Modems, MAC und/oder eine Flottenidentifikationsnummer. Der Server kann die Anforderung zu dem identifizierten Fahrzeug bzw. den identifizierten Fahrzeugen zur Initialisierung von Kommunikation mit dem VCS auf der Basis des Identifikationscodes von der drahtlosen Entwicklungs-/Diagnostikvorrichtung senden (Schritt 504).
• Im Schritt 506 kann das Fahrzeug die Anforderung empfangen, wodurch es dem VCS erlaubt wird, einer Ausgabevorrichtung, darunter, aber ohne Beschränkung darauf, einem Instrumentencluster, einem Mittelkonsolen-LCD-Display und/oder einem Smartphone mit BLUETOOTH-Technologie in Kommunikation mit dem VCS eine oder mehrere Nachrichten zu präsentieren. Z. B. kann das VCS eine Fern-Entwicklungs- und/oder -diagnostikvorrichtungsanforderung für Kommunikation empfangen und auf der Basis dieser Anforderung eine Nachricht zu einem Fahrer im Fahrzeug senden, ob er/sie es der Vorrichtung erlauben würden, zu kommunizieren, indem die Kommunikationsverbindung entweder angenommen oder verweigert wird. In einem anderen Beispiel kann das VCS auf der Basis mehrerer Fraktionen, wie zum Beispiel, aber ohne Beschränkung darauf, Ort des Fahrzeugs, OEM-Einstellungen, die es einem drahtlosen Servicewerkzeug erlauben, sich während des Aufenthalts in einer Servicewerkstätte zu verbinden, und/oder vordefinierten Einstellungen von Fahrzeugbesitzern eine Fern-Entwicklungs- und/oder Diagnostikvorrichtungsanforderung der Kommunikation automatisch annehmen.
• Im Schritt 508 kann der Server eine Bestätigungsantwort vom VCS empfangen, die zum Beispiel, aber ohne Beschränkung darauf, die VIN, eine Annahmenachricht und/oder eine verschlüsselte Nachricht ist, die Kommunikation vom VCS zu der drahtlosen Vorrichtung durch den Server erlaubt. Der Server kann von der Diagnostik-/Entwicklungsvorrichtung eine Anforderung empfangen, einen oder mehrere Diagnostikcodes aus dem VCS zu lesen (Schritt 510). Der Server kann die Lesung eines oder mehrerer Diagnostikcodes zum VCS senden. Der Server kann den einen oder die mehreren Diagnostikcodes vom Fahrzeug empfangen und diese Informationen zu der Vorrichtung senden (Schritt 512).
• Im Schritt 514 kann der Benutzer der Diagnostik-/Entwicklungsvorrichtung auf der Basis des einen oder der mehreren Diagnostikcodes anfordern, eine oder mehrere Komponenten zur weiteren Analyse am Fahrzeug zu untersuchen. Der Server kann eine zusätzliche Genehmigungsanforderung, eine oder mehrere Komponenten in Kommunikation mit dem VCS zu untersuchen, senden. Die eine oder mehreren Komponenten können sich auf mehreren Modulen in Kommunikation mit dem VCS befinden. Wenn der Server eine Annahme vom Fahrzeug empfängt, die eine oder mehreren Komponenten in Kommunikation mit dem VCS zu untersuchen, kann der Server die Annahme der Diagnostik-/Entwicklungsvorrichtung ankündigen. Der Server kann eine auf die Leistungsfähigkeitsbeschwerden (z. B. gesetzten Diagnostikcodes), die das Fahrzeug in Kommunikation mit dem Server erfährt, zugeschnittene Diagnostikroutine von der Diagnostik-/Entwicklungsvorrichtung empfangen (Schritt 518).
• Im Schritt 520 kann der Server der Vorrichtung erlauben, die vom VCS angeforderten Daten zu betrachten, während sie tatsächlich aufgezeichnet werden. Zum Beispiel kann sich ein Servicetechniker bei dem Fahrzeug befinden, während sich ein Ingenieur unter Verwendung der drahtlosen Diagnostik-/Entwicklungsvorrichtung an einem entfernten Ort befindet, um die Ursache einer oder mehrerer Kundenbeschwerden an einem Fahrzeug zu finden. Der Ingenieur kann auf der Basis der Beschwerde Diagnostikanweisungen senden und den Servicetechniker das Fahrzeug betreiben lassen, während er/sie die Daten augenblicklich auf der Vorrichtung betrachtet.
• Im Schritt 522 kann der Server kontinuierliche Kommunikation der Vorrichtung erlauben, sobald eine oder mehrere Diagnostikroutinen zum VCS gesendet wurden. Die eine oder mehreren Diagnostikroutinen wären zum Beispiel, aber ohne Beschränkung darauf, ein oder mehrere Algorithmen mit Triggern, Timern und/oder anderen vordefinierten Variablen, die sicherstellen, dass angeforderte Variablen während eines bestimmten Fahrzeugsystemszenarios aufgezeichnet/überwacht werden. Der Server kann es dem Fahrzeug und/oder der Diagnostik-/Entwicklungsvorrichtung erlauben, sich abzumelden, während die Diagnostikroutine auf dem VCS ausgeführt wird, und dadurch die Aufzeichnung und Speicherung des Datensatzes in einem oder mehreren Fahrzeugmodulen ermöglichen (Schritt 524).
• Im Schritt 526 kann der Server einen oder mehrere Datensätze von dem Fahrzeug empfangen, sobald sie aufgezeichnet wurden und/oder die Diagnostikroutine auf der Basis eines Triggers, Timers und/oder anderer vordefinierter Variablen ihre Analyse abgeschlossen hat. Wenn die Vorrichtung vom Server abgemeldet ist, kann der Datensatz auf dem Server gespeichert und beim nächsten Anmelden zu der Diagnostik-/Entwicklungsvorrichtung gesendet werden (Schritt 528).
• Zum Beispiel kann das VCS durch einen Server eine Diagnostikroutine von einer drahtlosen Vorrichtung zur Ausführung auf einem oder mehreren Modulen im Fahrzeug empfangen. Das Fahrzeug und die drahtlose Vorrichtung können Kommunikation mit dem Server abmelden und es der angepassten Diagnostik erlauben, zu laufen. Die Diagnostikanweisung kann auf dem einen oder den mehreren Modulen im Fahrzeug laufen und die aufgezeichneten Daten in dem Register der elektronischen Steuereinheit speichern. Nachdem das Fahrzeug Kommunikation mit dem Server hergestellt hat, können die Daten gesendet und auf dem Server gespeichert werden. Nachdem die drahtlose Vorrichtung Kommunikation mit dem Fahrzeug und/oder Server hergestellt hat, können die Daten zu der Vorrichtung gesendet werden.
• 6 ist eine beispielhafte Blocktopologie für eine Computervorrichtung mit einer oder mehreren angepassten Anwendungen, die zur Prognostik eines Fahrzeugsystems verwendet werden. Dies ist ein Beispiel für eine Fernprognostikarchitektur 600, mit der es einer oder mehreren mobilen Vorrichtungen und/oder einem stationären PC 606 ermöglicht werden kann, eine programmierbare Diagnostikroutine zu einem Fahrzeug 602 zu übermitteln. Die programmierbare Diagnostikroutine kann durch Verwendung einer oder mehrerer Anwendungen 610 entwickelt werden. Die eine oder mehreren Anwendungen 610 können entwickelt werden, um Überwachung und Einzelfehler-Ursachenanalyse für eine oder mehrere Komponenten in einem Fahrzeug durchzuführen.
• Die entwickelte eine oder die entwickelten mehreren Anwendungen können für ein spezifisches Betriebssystem 608 zusammengestellt und/oder entwickelt werden. Das Betriebssystem 608 kann auf der Basis der mobilen Vorrichtung oder des stationären PC 606 spezifisch sein (z. B. können Apple-Vorrichtungen ein iOS-Betriebssystem aufweisen, und Samsung-Vorrichtungen können das Android-Betriebssystem aufweisen). Die mobile Vorrichtung und/oder der stationäre PC 606 können sich in Kommunikation mit einem Server befinden, wodurch Fernkommunikation mit einem Fahrzeug 602 möglich wird.
• Der Server 604 kann das Streamen von unmittelbaren Daten aus dem Fahrzeug 602 auf Anforderung und/oder anderweitiges Speichern der Daten in der Cloud 604 erlauben. Das Fahrzeug 602 wäre z. B., aber ohne Beschränkung darauf, Entwicklungsfahrzeuge, Prototypfahrzeuge, Kundenfahrzeuge und/oder Flottenfahrzeuge. Das Fahrzeug kann erweiterte Datenverfügbarkeit auf der Basis von direktem Speicherlesen (DMR) von Variable(n) in einem oder mehreren Modulen im Fahrzeug 602 aufweisen. Das DMR von Variablen wäre zum Beispiel, aber ohne Beschränkung darauf, Variablen, die nicht im Fahrzeugnetzwerk (z. B. CAN-Bus) übermittelt werden.
• 7A ist eine beispielhafte GUI zum Empfangen von Daten von einer oder mehreren programmierbaren Diagnostikroutinen, die in einem Fahrzeug ausgeführt werden. Das System kann einen angepassten Datensatz 700, definiert durch den Benutzer der Diagnostik-/Entwicklungsvorrichtung, abliefern. Die Daten können in unverarbeiteter Form 702 mit einer oder mehreren Variablen 704 und den unter der Variablen aufgelisteten zugeordneten Daten 706 präsentiert werden. Der Benutzer kann eine Anwendung entwickeln, um die Daten auf die Weise anzuzeigen, die seinem Zweck am besten gerecht wird.
• Zum Beispiel kann in 7B der Benutzer eine Anzeige entwickeln, um die Daten in einem Tabellenlayout 708 auszugeben, wobei eine oder mehrere Variablen 710 auf der Seite mit zugeordneten Daten 712 neben ihnen aufgelistet werden. Die Daten können die Variableninformationen durch Aufrufen der jeweiligen Kombination der Steuermodulidentifikation (z. B. BCCM, Batterieladesteuermodul) und der variablen Adresse (z. B. in einem Hex-Format) präsentieren. Die zugeordneten Daten wären zum Beispiel, aber ohne Beschränkung darauf, die wissenschaftliche Messeinheit für diese Variable und eine Beschreibung der Variablen.
• Manchmal sind bereits unverarbeitete Variablendaten ausreichend, aber andernfalls kann der Benutzer übliche Softwarewerkzeuge verwenden, um die Daten grafisch aufzutragen oder um die Daten in ein Diagramm oder eine bestimmte andere grafische Oberfläche 714, die die Diagnostikvorrichtung verwendet, zu legen. Das grafische Layout 714 kann eine oder mehrere Variablen umfassen, um es einem Benutzer zu erlauben, visuell zu bestimmen, wie die Variablen während des Fahrzeugbetriebs reagieren. Das grafische Layout 714 kann durch einen Benutzer beim Entwickeln einer angepassten Diagnostik unter Verwendung der Diagnostikvorrichtung definiert werden.
• 8 ist eine beispielhafte GUI zum Auswählen einer oder mehrerer Datenkennungen unter Verwendung einer Vorrichtung zur Verwendung bei einer Diagnostikanweisung, und die zu einem Fahrzeugdatenverarbeitungssystem gesendet werden. Die Vorrichtung wäre zum Beispiel, aber ohne Beschränkung darauf, ein tragbares Mobiltelefon, ein Laptop und/oder ein Computerterminal. In einem anderen Beispiel wäre die Vorrichtung zum Beispiel, aber ohne Beschränkung darauf, ein Vertragshändler-Servicewerkzeug (z. B. Ford STAR Tester, GM TECH 2 usw.).
• Die Vorrichtung kann es einem Benutzer erlauben, ein oder mehrere DIDs auszuwählen, um eine Menge von zu dem Fahrzeugdatenverarbeitungssystem zu sendenden Variablen zu entwickeln. Die GUI kann es einem Benutzer erlauben, ein oder mehrere Module auszuwählen und eine Liste von das ausgewählte Modul betreffenden Variablen 802 zu betrachten. Zum Beispiel wäre die Liste von Variablen 802 für ein Batterielademodul zum Beispiel, aber ohne Beschränkung darauf, die Controlleradresse, die DID-Adresse, die wissenschaftliche DID-Messung und/oder eine Kurzbeschreibung des DID. Der Benutzer kann auswählen, ob eine oder mehrere Variablen zu der ausgewählten DID-Monitorliste 808 hinzugefügt 804 oder aus dieser entfernt werden sollen. Nachdem der Benutzer das Modul bzw. die Module und zugeordnete Variable(n), die zum Finden der Ursache einer Kundenbeschwerde oder zur Analyse eines Entwicklungs-Prototypfahrzeugs benötigt werden, bestimmt hat, kann die ausgewählte DID-Monitorliste 808 unter Verwendung der Vorrichtung zum VCS gesendet werden.
• Nachdem die Variablen zum VCS gesendet wurden, kann die Vorrichtung die Variablen überwachen, während sie durch das VCS im Fahrzeug gelesen werden. In einem anderen Beispiel können das eine oder die mehreren DID zum VCS übermittelt werden, und die aufgezeichneten DID-Daten können durch ein oder mehrere Module im VCS gespeichert werden, bis sich die Vorrichtung anmeldet und/oder anfordert, die aufgezeichneten Daten zu sammeln.
• 9 ist eine beispielhafte GUI des Auswählens von Diagnostikerfassungstriggern zur Verwendung bei einer Diagnostikanweisung und Übertragung zu einem Fahrzeugdatenverarbeitungssystem. Ein Server kann sich während der Produktentwicklung mit einem oder mehreren Prototypfahrzeugen in Kommunikation befinden. Das eine oder die mehreren Prototypfahrzeuge können Testfahrten unternehmen, um eine oder mehrere Komponenten, Subsysteme und Systeme zu validieren. Während der Testfahrt können auf der Basis der Kombination eines Fahrmanövers, des Straßenzustands und/oder der Umgebungsbedingungen ein oder mehrere Fehler gesetzt werden. Es kann eine angepasste Diagnostik entwickelt werden, um die Daten unter Verwendung mehrerer Variablentrigger zu erfassen, darunter, aber ohne Beschränkung darauf, Batterieladezustandswert, Batterieladestatus, Fahrzeuggeschwindigkeit und/oder Getriebeöltemperatur.
• Eine Softwareanwendung kann auf einer Entwicklungsvorrichtung in Kommunikation mit dem einen oder den mehreren Prototypfahrzeugen verwendet werden, um die programmierbare Diagnostikroutine bzw. die programmierbaren Diagnostikroutinen zu entwickeln und zu senden. Die Softwareanwendung auf der Entwicklungsvorrichtung kann über eine GUI verfügen, die einem Benutzer eine Liste von Auswahlmöglichkeiten 900 zur Entwicklung einer Diagnostikanweisung bereitstellt, darunter, aber ohne Beschränkung darauf, Auswählen einer Bedingungsvariablen 902, Wählen einer Modulvariablen 904, Auswählen einer Bedingungsmessvariablen 906 und/oder Wählen einer oder mehrerer zusätzlicher Modulvariablen 908. Die Softwareanwendung kann es den Diagnostikanweisungen erlauben, eine zu der Entwicklungsvorrichtung zu sendende Aktion 910 aufzunehmen, wenn der eine oder die mehreren Trigger gesetzt wurden und/oder die variablen Daten aufgezeichnet wurden.
• Die Softwareanwendungs-GUI kann es dem Benutzer erlauben, eine oder mehrere Bedingungen und Variablen auszuwählen und zu wählen und den Diagnostikanweisungsalgorithmus 912 aufzufüllen. Nachdem die Diagnostikanweisung/routine abgeschlossen ist, kann die Entwicklungsvorrichtung die Diagnostikanweisung/routine zusammenstellen und durch einen Server zu dem einen oder den mehreren Prototypfahrzeugen senden. Das eine oder die mehreren Prototypfahrzeuge können die angepasste Diagnostik empfangen und sie im VCS speichern. Nachdem der eine oder die mehreren Trigger, Bedingungen und/oder Timer erfüllt wurden, kann die angepasste Diagnostik die Anforderungsdaten sammeln. Nachdem die Daten gesammelt wurden, kann die angepasste Diagnostik eine Nachricht zu der Entwicklungsvorrichtung senden, wie z. B., aber ohne Beschränkung darauf, eine SMS, eine Seite und/oder eine E-Mail. Die Entwicklungsvorrichtung kann die Daten auf der Basis der angepassten Diagnostik von dem einen oder den mehreren Prototypfahrzeugen zur weiteren Analyse herunterladen.
• 10 ist ein Flussdiagramm einer Diagnostikvorrichtung zum Erzeugen und Senden eines Anweisungssatzes zur Erfassung einer oder mehrerer Variablen in einem Fahrzeugdatenverarbeitungssystem. Die Diagnostikvorrichtung wäre zum Beispiel, aber ohne Beschränkung darauf, ein tragbares Mobiltelefon, ein Laptop-Computer, ein Computerterminal und/oder eine OEM-/Nachrüstvorrichtung, die zur Kommunikation mit einem Fahrzeug für Diagnostik- und Analysezwecke verwendet wird. Die Diagnostikvorrichtung kann mit einem Server kommunizieren, um spezifische Fahrzeuginformationen abzurufen, wie z. B., aber ohne Beschränkung darauf, Software und Kalibrationsvariablen. Der Server kann eine oder mehrere Datenbanken aufweisen, um Fahrzeuginformationen auf der Basis der Fahrzeugbauvorgeschichte und/oder Serviceaufzeichnungen zu speichern. Die Datenbanken können die Fahrzeuginformationen auf der Basis einer Identifikation eines Fahrzeugs unter Verwendung einer oder mehrerer Fahrzeugkennungen speichern, darunter, aber ohne Beschränkung darauf, eine VIN, eine MAC-Adresse, eine Adresse des eingebetteten Telefons und/oder die dem eingebetteten WiFi/MiFi-System zugeordnete IP-Adresse.
• Im Schritt 1002 kann die Diagnostikvorrichtung initialisiert werden, um auf der Basis eines oder mehrerer durch eine auf der Vorrichtung laufende Softwareanwendung konfigurierter Prozessoren eine Analyse an einem VCS durchzuführen. Die Softwareanwendung wäre zum Beispiel, aber ohne Beschränkung darauf, Diagnostik- und Meldefähigkeit an Bord. Die Softwareanwendung umfasst ferner eine oder mehrere Auswahlmöglichkeiten zur Entwicklung und Zusammenstellung von Diagnostikroutinen durch Auswählen von Diagnostikinformationen, die über OBD verfügbar sind, und Zusatzinformationen auf einem oder mehreren Modulen, die nicht über ein Fahrzeugnetzwerk übermittelt werden.
• Im Schritt 1004 kann ein Benutzer ein spezifisches Fahrzeug zum Entwickeln und Senden einer Diagnostikanweisung-/routine auf der Basis einer oder mehrerer Kennungen auswählen, darunter, aber ohne Beschränkung darauf, Fahrzeugmodelljahr, Fahrzeugmarke, Fahrzeugmodell, Ausstattung, Kraftübertragungssystem und/oder VIN. Wenn zum Beispiel ein Benutzer eine Diagnostikroutine für einen Ford Focus von 2005 mit Vierzylinder-Kraftübertragungsmotor und Vierganggetriebe entwickeln möchte, kann der Benutzer die Informationen in die Vorrichtung eingeben und die Erlaubnis erhalten, eine oder mehrere Variablen auf der Basis der bei dieser Auswahl verfügbaren Module auszuwählen. Der Benutzer kann auch eine VIN eingeben, um die Variablen hervorzurufen, um auf der Basis dieses spezifischen Fahrzeugbaus eine Diagnostikanweisung zu entwickeln.
• Im Schritt 1006 kann, nachdem ein Fahrzeug ausgewählt ist, die Diagnostikvorrichtung einem Benutzer erlauben, die Variablen, die verfügbar sind, auf der Basis einer Anzahl von Faktoren auszuwählen, wie zum Beispiel, aber ohne Beschränkung darauf, der in diesem Fahrzeug verfügbaren Auswahlmöglichkeiten, der Merkmale/Funktionen, Systeme, Subsysteme, Bauinformationen für ein bestimmtes Fahrzeug und/oder der Servicevorgeschichte des Fahrzeugs. Die Vorrichtung kann es einem Benutzer erlauben, einen oder mehrere in die Diagnostikanweisung aufzunehmende Trigger auszuwählen, die den Beginn der Aufzeichnung der notwendigen Daten ermöglichen können, sowie einen anderen Trigger zum Stoppen des Aufzeichnens (Schritt 1008).
• Zum Beispiel kann ein Techniker an einem Fahrzeug arbeiten und kann wünschen, einen Diagnostiktest zu erzeugen, um Daten in Bezug auf ein Merkmal an diesem Fahrzeug zu erfassen. Der Techniker kann die VIN in die Vorrichtung eingeben, um die Variablen und die zugeordneten Modul-/Variablenadressen, die für dieses Fahrzeug verfügbar sind, abzurufen.
• In einem anderen Beispiel kann ein Ingenieur eine Diagnostikanweisung für eine Flotte von Fahrzeugen entwickeln, die im selben Moduljahr gebaut sind und/oder dieselbe Marke und dasselbe Modell aufweisen. Der Ingenieur kann diese Diagnostikanweisung auf der Basis einer spezifischen Beschwerde erstellen, die am Einsatzort gesehen wird, so dass ein Techniker die Anweisung ziehen und sie dazu verwenden kann, ordnungsgemäß die Ursache eines Problems/einer Beschwerde zu finden.
• Im Schritt 1010 kann die Vorrichtung, nachdem der Benutzer eine Diagnostikanweisung entwickelt hat, die Anweisung für das ausgewählte Fahrzeug bzw. die ausgewählten Fahrzeuge zusammenstellen. Die Vorrichtung kann Kommunikation mit einem entfernten Computer einleiten, um die Kommunikation zwischen der Diagnostikvorrichtung und einem oder mehreren Fahrzeugen zu überbrücken (Schritt 1012). Der entfernte Computer kann einen OEM-Server umfassen, der es der Vorrichtung ermöglicht, mit OEM-Fahrzeugen zu kommunizieren. Nachdem ein Fahrzeug von einem OEM gefertigt wurde, kann zum Beispiel die Bauvorgeschichte des Fahrzeugs mit der VIN zur Speicherung im entfernten Computer gesendet werden. Dem entfernten Computer kann erlaubt werden, unter Verwendung eines eingebetteten Zellularmoduls im Fahrzeug und/oder eines dem Besitzer des Fahrzeugs zugeordneten registrierten tragbaren Mobiltelefons mit dem Fahrzeug zu kommunizieren. Das registrierte tragbare Mobiltelefon kann Kommunikation von dem entfernten Computer zum Fahrzeug unter Verwendung von BLUETOOTH-Technologie transferieren.
• Im Schritt 1014 kann die Vorrichtung einen Benutzer benachrichtigen, wenn eine Verbindung mit dem entfernten Computer hergestellt ist, oder mehrere Versuche unternehmen, wenn die Verbindung fehlgeschlagen ist. Nach der Verbindung mit dem entfernten Computer kann die Diagnostikvorrichtung ein oder mehrere Fahrzeuge zum Zusenden der Diagnostikanweisung unter Verwendung mehrerer Verfahren auswählen, darunter, aber ohne Beschränkung darauf, eine VIN, MAC, IP und/oder eine Nummer eines registrierten tragbaren Mobiltelefons (Schritt 1016). Auf der Basis der mehreren Verfahren für die Vorrichtung zum Identifizieren des einen oder der mehreren Fahrzeuge, zu denen die Diagnostikanweisung zu übermitteln ist, kann der entfernte Computer mehrere Versuche unternehmen, mit dem Fahrzeug bzw. den Fahrzeugen zu kommunizieren (Schritt 1018).
• Wenn im Schritt 1020 der entfernte Computer Kommunikation mit dem Fahrzeug hergestellt hat, kann der entfernte Computer Rückmeldung vom Fahrzeug empfangen, die die Kommunikation mit der Diagnostikvorrichtung annimmt. Die Vorrichtung kann die Diagnostikanweisung durch die Kommunikation des entfernten Computers mit dem Fahrzeug zu dem Fahrzeug senden. In einem anderen Beispiel kann die Vorrichtung unter Verwendung des OBD-Ports eine festverdrahtete Verbindung mit dem Fahrzeug herstellen und die Diagnostikanweisungen direkt ohne Verwendung drahtloser Kommunikation zwischen der Diagnostikvorrichtung und dem Fahrzeugdatenverarbeitungssystem zu dem Fahrzeugsystem senden.
• Im Schritt 1024 kann die Diagnostikvorrichtung einen Teil der Daten empfangen, nachdem die Diagnostikanweisung freigegeben und in dem Fahrzeugdatenverarbeitungssystem ausgeführt wurde. Der Teil der Daten wäre zum Beispiel, aber ohne Beschränkung darauf, Daten aus dem Speicher eines oder mehrerer Module. Die Diagnostikvorrichtung kann einen Teil der Daten auf einem oder mehreren Displays ausgeben, wie zum Beispiel, aber ohne Beschränkung darauf, auf einem LCD-Bildschirm (Schritt 1026).
• Obwohl oben beispielhafte Ausführungsformen beschrieben werden, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Formen der Erfindung beschreiben. Stattdessen sind die in der Beschreibung verwendeten Wörter 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 Erfindung abzuweichen. Außerdem können die Merkmale verschiedener Implementierungsausführungsformen kombiniert werden, um weitere Ausführungsformen der Erfindung zu bilden.
• Bezugszeichenliste
• Fig. 1

61

Netzwerk

53

ND

63

Mdm

17

BTT

4

Display

51

Eingangsselektor

11

Verst.

52

BT-Paar

9

DIA

23

USB

3

CPU

73

Drahtloses Modul

7

HDD

5

RAM

27

A/D

25

Aux

24

GPS

56

USB

65

Hilfseinrichtung

69

USB

54

Persönliche Navigationseinrichtung

60

Fahrzeugnavigationseinrichtung

62

USB

Fig. 2

203

Andere Automodule (d. h. BCM, AHU, usw.)

Fig. 3

302

Mit Kommunikationsvorrichtung verbinden

N

Nein

304

Fahrzeug in Kommunikation mit Cloud?

306

VIN-Nummer gesendet

308

Anforderung, Diagnostikcodes zu ziehen empfangen

310

Irgendwelche Fehler gesetzt?

312

Diagnostikcodes senden

314

Anforderung, eine oder mehrere Komponenten zu untersuchen, empfangen

316

Genehmigung senden, um Prognostik zu erlauben

318

Angepasste Diagnostikroutine empfangen

310

Variablen überwachen

322

Daten gesammelt?

324

Angepasste Diagnostikdaten senden

Fig. 4

402

Anforderung, mit Fahrzeug zu kommunizieren, auf der Basis von VIN/Nummer eingebetteten Telefons/IP-Adresse eingebetteten Modems senden

404

Fahrzeug in Kommunikation mit Technikervorrichtung?

406

VIN-Nummer empfangen

408

Anforderung, Diagnostikcodes zu lesen, senden

410

Diagnostikcodes empfangen

412

Irgendwelche Fehler gesetzt?

414

Anforderung, eine oder mehrere Komponenten zu untersuchen, senden

416

Genehmigung, eine oder mehrere Komponenten zu untersuchen, empfangen

418

Angepasste Diagnostikroutine senden

420

Variable in Echtzeit überwachen?

422

Angemeldet bleiben, um angepasste Diagnostikdaten zu betrachten

424

Kommunikation abmelden?

426

Angepasste Diagnostikdaten empfangen

428

Empfang angepasster Diagnostik beim nächsten Anmelden erlauben

Fig. 5

502

Anforderung von Tech-Werkzeug, mit einem Fahrzeug zu kommunizieren, auf der Basis von VIN/Nummer eingebetteten Telefons/IP-Adresse eingebetteten Modems empfangen

504

Anforderung zu einem Fahrzeug zur Kommunikation mit Fahrzeug auf der Basis von VIN/Nummer eingebetteten Telefons/IP-Adresse eingebetteten Modems senden

506

Fahrzeug nimmt Anforderung an?

508

VIN-Nummer von Fahrzeug empfangen und zu Tech-Werkzeug gesendet

510

Anforderung, Diagnostikcodes zu lesen, von Werkzeug empfangen und zu Fahrzeug gesendet

512

Diagnostikcodes von Fahrzeug empfangen und zu Werkzeug senden

514

Anforderung, eine oder mehrere Komponenten zu untersuchen, von Werkzeug empfangen und zu Fahrzeug senden

516

Genehmigung, eine oder mehrere Komponenten zu untersuchen, von Fahrzeug empfangen und zu Werkzeug senden

518

Angepasste Diagnostikroutine von Werkzeug empfangen und zu Fahrzeug senden

520

Variablendaten in Echtzeit streamen?

522

Kommunikation fortsetzen, um Betrachtung von angepassten Diagnostikdaten zu erlauben

524

Kommunikation abmelden?

526

Angepasste Diagnostikroutine von Fahrzeug empfangen und zu Werkzeug senden

528

Speicherung angepasster Diagnostik auf einer Datenbank in Kommunikation mit der Cloud und Senden beim nächsten Anmelden des Werkzeugs erlauben

• Fig. 7b
• verfügbare Ladegerät-Eingangsleistung
• Ladegerät-Eingangsspannung
• Ladegerät-Eingangsstrom
• Ladegerät-Eingangsfrequenz
• Pilot-Tastverhältnis
• Prox.-Detektionsstatus
• EVSE-Prox.-Spannung
• Steckerverbindungsstatus
• Ladegerät-Kontaktorsteuerung
• Batterieladestrom-Anf.
• Batterieladespannungs-Anf.
• Ladegerät-Ausgangsstrom
• Ladegerät-Ausgangsspannung
• Ladestatus (0 = n. bereit 1 = warten 2 = bereit 3 = ämndern 4 = vergl. 5 = Fehler)
• Ladegerät-Innentemperatur A
• Ladegerät-Innentemperatur B
• Ladegerät-Innentemperatur C
• Bezugszeichenliste
• Fig. 6

606

Intelligente Mobilvorrichtung oder stationärer PC

608

Betriebssystem

• Fig. 8
• Ladegerät-Status
• Fehler
• ECU-Status
• ungültig
• EVSE-Typ detektiert
• nicht detektiert
• Watt, verfügbare Ladegerät-Eingangsleistung
• Ladegerät-Eingangsspannung
• Ladegerät-Eingangsstrom
• Ladegerät-Eingangsfrequenz
• Pilot-Tastverhältnis
• Prox.-Detektionsstatus
• EVSE-Prox.-Spannung
• Steckerverbindungsstatus
• Ladegerät-Kontaktorsteuerung
• Batterieladestrom-Anf.
• Batterieladespannungs-Anf.
• Ladegerät-Ausgangsstrom
• s, globale Echtzeit
• Steckerverbindungsstatus
• Ladegerät-Kontaktorsteuerung
• Batterieladestrom-Anf.
• Batterie
• Fig. 9
• 902
• Auswählen
• FALLS
• WÄHREND
• WENN
• BIS
• GRÖSSER ALS
• KLEINER ALS
• IST GLEICH
• NICHT GLEICH
• 904
• Nachricht wählen
• Ladegerät-Status
• Fehler
• ECU-Status
• ungültig
• EVSE-Typ detektiert
• nicht detektiert
• Watt, verfügbare Ladegerät-Eingangsleistung
• Ladegerät-Eingangsleistung
• Ladegerät-Eingangsstrom
• Ladegerät-Eingangsfrequenz
• 906
• Auswahl/Wert
• FALLS
• WÄHREND
• WENN
• BIS
• GRÖSSER ALS
• KLEINER ALS
• IST GLEICH
• NICHT GLEICH
• UND
• 908
• Nachricht wählen
• Ladegerät-Status
• Fehler
• ECU-Status
• ungültig
• EVSE-Typ detektiert
• nicht detektiert
• Watt, verfügbare Ladegerät-Eingangsleistung
• Ladegerät-Eingangslspannung
• Ladegerät-Eingangsstrom
• Ladegerät-Eingangsfrequenz
• 910
• Aktion
• DTC lesen
• Daten erfassen
• Hinweis senden
• Skript ausführen
• SMS senden
• Seite senden
• Zu Cloud senden
• 912
• angepasste Diagnostik
• falls
• Ladegerät-Status GRÖSSER ALS
• Bezugszeichenliste
• Fig. 10

1002

Diagnostikvorrichtung initialisieren

1004

Fahrzeug nach Modelljahr, Marke, Modell, Ausstattung usw. oder unter Verwendung einer VIN auswählen

1006

Eine oder mehrere Variablen auswählen

1008

Einen oder mehrere Trigger zum Beginnen der Aufzeichnung der einen oder mehreren Variablen auswählen

1010

Eine Diagnostikanweisung für das ausgewählte Fahrzeug erzeugen und zusammenstellen

1012

Kommunikation mit entfernten Computer einleiten

1014

Verbunden?

1016

Fahrzeug zum Senden von Diagnostikanweisung auswählen (unter Verwendung von VIN, MAC, IP, Telefonnummer usw...)

1018

Kommunikation mit Fahrzeug mittels entferntem Computer herstellen?

1020

Nachricht von Fahrzeug empfangen

1022

Diagnostikanweisungen senden

1024

Einen Teil der Daten empfangen

1026

Einen Teil der Daten ausgeben

• ZITATE ENTHALTEN IN DER BESCHREIBUNG
• Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
• Zitierte Patentliteratur
• US 7317975 [0002]
• US 6956501 [0003]
• Zitierte Nicht-Patentliteratur
• IEEE 802 PAN [0028]
• IEEE 802 LAN [0028]
• IEEE 802 PAN [0028]
• IEEE 1394 [0031]
• IEEE 1284 [0031]
• IEEE 803.11 [0033]

Claims (8)

1. Fahrzeugdatenverarbeitungssystem, umfassend: einen Computerprozessor in Kommunikation mit einem drahtlosen Sendeempfänger, wobei der drahtlose Sendeempfänger zu Kommunikation mit einer entfernt vom Prozessor angeordneten drahtlosen Kommunikationsvorrichtung fähig ist, wobei der Computerprozessor ausgelegt ist zum Empfangen einer oder mehrerer Anweisungen von einem entfernten Server mittels der drahtlosen Kommunikationsvorrichtung; Anfordern von Daten aus einem Speicherlesen eines oder mehrerer Module auf der Basis der einen oder mehreren Anweisungen, wobei das Speicherlesen mindestens eine Variable umfasst, die in einem Fahrzeugnetzwerk nicht verfügbar ist; Empfangen eines Teils von Daten als Reaktion auf das Speicherlesen aus dem einen oder den mehreren Modulen, und Senden des Teils von Daten zu dem entfernten Server.
2. Fahrzeugdatenverarbeitungssystem nach Anspruch 1, wobei die drahtlose Kommunikationsvorrichtung ein tragbares Mobiltelefon ist.
3. Fahrzeugdatenverarbeitungssystem nach Anspruch 1, wobei die drahtlose Kommunikationsvorrichtung ein eingebettetes Mobiltelefon ist.
4. Fahrzeugdatenverarbeitungssystem nach Anspruch 1, wobei die eine oder mehreren Anweisungen mindestens einen Trigger eines Fahrzeugereignisses umfassen, wodurch definiert wird, wann mit dem Sammeln der Daten zu beginnen ist.
5. Fahrzeugdatenverarbeitungssystem nach Anspruch 4, wobei der eine oder die mehreren Trigger auf der Basis eines benutzerdefinierten Parameters verwendet werden, um anzugeben, wann das Aufzeichnen zu beginnen ist.
6. Fahrzeugdatenverarbeitungssystem nach Anspruch 5, wobei der benutzerdefinierte Parameter ein Batterieladezustandswert ist.
7. Fahrzeugdatenverarbeitungssystem nach Anspruch 1, wobei das Speicherlesen eine Anforderung auf der Basis einer Modulidentifikations- und Variablenadressenkombination über das Fahrzeugnetzwerk umfasst.
8. Fahrzeugdatenverarbeitungssystem nach Anspruch 7, wobei die Modulidentifikations- und Variablenadressenkombination dem Fahrzeugnetzwerk erlaubt, zu bestimmen, aus welchem Modul und welcher Variablen in dem Modul die Daten vom Server angefordert werden.

Images