DE102014219226A1 - Fahrzeugdiagnostik- und -prognostiksysteme und verfahren - Google Patents

Fahrzeugdiagnostik- und -prognostiksysteme und verfahren Download PDF

Info

Publication number
DE102014219226A1
DE102014219226A1 DE102014219226.9A DE102014219226A DE102014219226A1 DE 102014219226 A1 DE102014219226 A1 DE 102014219226A1 DE 102014219226 A DE102014219226 A DE 102014219226A DE 102014219226 A1 DE102014219226 A1 DE 102014219226A1
Authority
DE
Germany
Prior art keywords
vehicle
diagnostic
data
communication
variables
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102014219226.9A
Other languages
English (en)
Inventor
Christopher W. Bell
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ford Global Technologies LLC
Original Assignee
Ford Global Technologies LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ford Global Technologies LLC filed Critical Ford Global Technologies LLC
Publication of DE102014219226A1 publication Critical patent/DE102014219226A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B23/00—Testing or monitoring of control systems or parts thereof
    • G05B23/02—Electric testing or monitoring
    • G05B23/0205—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults
    • G05B23/0218—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults
    • G05B23/0243—Electric testing or monitoring by means of a monitoring system capable of detecting and responding to faults characterised by the fault detection method dealing with either existing or incipient faults model based detection method, e.g. first-principles knowledge model
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808—Diagnosing performance data

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Eine Diagnostikvorrichtung besitzt einen Computerprozessor in Kommunikation mit einem drahtlosen Sendeempfänger, wobei der drahtlose Sendeempfänger zur Kommunikation mit einem entfernt vom Prozessor angeordneten entfernten Computer fähig ist. Der Computerprozessor kann dafür ausgelegt sein, der Diagnostikvorrichtung zu ermöglichen, eine oder mehrere Variablen aus einer Datenbank in Kommunikation mit dem entfernten Computer auszuwählen. Der Computerprozessor kann auf der Basis der einen oder mehreren Variablen eine Diagnostikanweisung für ein Fahrzeug erzeugen, wobei die Diagnostikanweisung Daten aus Speicher eines oder mehrerer Module umfasst, die in einem Fahrzeugnetzwerk nicht verfügbar sind. Die Diagnostikvorrichtung kann die angepasste Diagnostikanweisung zu einem Fahrzeug in Kommunikation mit dem entfernten Computer senden. Die Diagnostikvorrichtung kann als Reaktion auf die Diagnostikanweisung mindestens einen Teil der Daten von dem Fahrzeug empfangen.

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 eine Diagnostikvorrichtung einen Computerprozessor in Kommunikation mit einem drahtlosen Sendeempfänger, wobei der drahtlose Sendeempfänger zur Kommunikation mit einem entfernt vom Prozessor angeordneten entfernten Computer fähig ist. Der Computerprozessor kann dafür ausgelegt sein, es der Diagnostikvorrichtung zu ermöglichen, aus dem entfernten Computer in Kommunikation mit einer Datenbank eine oder mehrere Variablen auszuwählen. Der Computerprozessor kann auf der Basis der einen oder der mehreren Variablen eine Diagnostikanweisung für ein Fahrzeug erzeugen, wobei die Diagnostikanweisung Daten aus Speicher eines oder mehrerer Module umfasst, die in einem Fahrzeugnetzwerk nicht verfügbar sind. Die Diagnostikvorrichtung kann die angepasste Diagnostikanweisung zu einem Fahrzeug in Kommunikation mit dem entfernten Computer senden. Die Diagnostikvorrichtung kann mindestens einen Teil der Daten als Reaktion auf die Diagnostikanweisung von dem Fahrzeug empfangen.
  • Bei der zweiten beispielhaften Ausführungsform speichert ein nichtflüchtiges computerlesbares Speichermedium Anweisungen, die, wenn sie durch einen Prozessor ausgeführt werden, den Prozessor dafür konfigurieren, eine oder mehrere Variablen aus einer Datenbank in Kommunikation mit dem Prozessor auszuwählen. Die Anweisungen können den Prozessor ferner dafür konfigurieren, auf der Basis der einen oder mehreren Variablen eine Diagnostikanweisung für ein Fahrzeug zu erzeugen, wobei die Diagnostikanweisung eine Anforderung von Daten aus Speicher eines oder mehrerer Module umfasst, die in einem Fahrzeugnetzwerk nicht verfügbar sind. Die Anweisungen konfigurieren den Prozessor dafür, die Diagnostikanweisung zu dem Fahrzeug in Kommunikation mit dem Prozessor zu senden und von dem Fahrzeug als Reaktion auf die Diagnostikanweisung mindestens einen Teil der Daten zu empfangen.
  • Bei der dritten beispielhaften Ausführungsform kann ein Verfahren Auswählen einer Variablen aus einer Datenbank umfassen, dergestalt, dass die Variable einen Speicherort repräsentiert. Das Verfahren kann auf der Basis der Variablen eine Anweisung für ein Fahrzeug erzeugen, wobei die Anweisung einen Trigger und eine Anforderung von Daten aus Speicher eines oder mehrerer Module umfasst, die in einem Fahrzeugnetzwerk nicht verfügbar sind. Das Verfahren kann die Anweisung zu dem Fahrzeug senden und als Reaktion auf die Anweisung mindestens einen Teil der Daten von dem Fahrzeug empfangen.
  • 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.LINKTM (Sony) und LynxTM (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-Over-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 Massenluftdruckvariablen.
  • 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, Prototypfahrzeugee, 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. 3
    302
    Mit Kommunikationsvorrichtung verbinden Nein
    304
    Fahrzeug in Kommunikation mit Cloud? Ja
    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
    320
    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? Nein Ja
    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 Nein
    506
    Fahrzeug nimmt Anforderung an? Ja
    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 (0 = offplg 1 = onplg 2 = onplg 7 = Fehler)
    EVSE-Prox.-Spannung
    Steckerverbindungsstatus
    Ladegerät-Kontaktorsteuerung
    Batterieladestrom-Anf.
    Batterieladespannungs-Anf.
    Ladegerät-Ausgangsstrom
    Ladegerät-Ausgangsspannung
    Ladestatus (0 = nrdy 1 = wait 2 = rdy 3 = chg 4 = cmp 5 = flt)
    Ladegerät-Innentemperatur A
    Ladegerät-Innentemperatur B
    Ladegerät-Innentemperatur C
    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
    Hinzufügen
    Entfernen
    Steckerverbindungsstatus
    Ladegerät-Kontaktorsteuerung
    Batterieladestrom-Anf.
    Batter.
    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/invalid
    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-Eingangsspannung
    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
    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? Nein Ja
    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]

Claims (7)

  1. Diagnostikvorrichtung, umfassend: einen Computerprozessor in Kommunikation mit einem drahtlosen Sendeempfänger, wobei der drahtlose Sendeempfänger zur Kommunikation mit einem entfernt vom Prozessor angeordneten entfernten Computer fähig ist, wobei der Computerprozessor ausgelegt ist zum Auswählen einer oder mehrerer Variablen aus dem entfernten Computer in Kommunikation mit einer Datenbank; Erzeugen einer Diagnostikanweisung für ein Fahrzeug auf der Basis der einen oder mehreren Variablen, wobei die Diagnostikanweisung eine Anforderung von Daten aus Speicher eines oder mehrerer Module umfasst, die in einem Fahrzeugnetzwerk nicht verfügbar sind; Senden der Diagnostikanweisung zu dem Fahrzeug in Kommunikation mit dem entfernten Computer; und Empfangen mindestens eines Teils der Daten von dem Fahrzeug als Reaktion auf die Diagnostikanweisung.
  2. Diagnostikvorrichtung nach Anspruch 1, wobei die eine oder mehreren Variablen auf Modulidentifikation und Variablenadressen basieren.
  3. Diagnostikvorrichtung nach Anspruch 1, wobei die Diagnostikanweisung einen oder mehrere Trigger eines Fahrzeugereignisses umfassen, die definieren, wann das Sammeln der Daten zu beginnen ist.
  4. Diagnostikvorrichtung nach Anspruch 3, wobei das Fahrzeugereignis ein Batterieladestatus ist.
  5. Diagnostikvorrichtung nach Anspruch 1, die ferner einen Ausgang des mindestens einen Teils der Daten umfasst.
  6. Diagnostikvorrichtung nach Anspruch 5, wobei der Ausgang ein tragbares Mobiltelefon ist.
  7. Diagnostikvorrichtung nach Anspruch 5, wobei sich der Ausgang an einem Computerterminal befindet.
DE102014219226.9A 2013-09-30 2014-09-24 Fahrzeugdiagnostik- und -prognostiksysteme und verfahren Withdrawn DE102014219226A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/041,030 2013-09-30
US14/041,030 US20150094903A1 (en) 2013-09-30 2013-09-30 Vehicle diagnostic and prognostic systems and methods

Publications (1)

Publication Number Publication Date
DE102014219226A1 true DE102014219226A1 (de) 2015-04-02

Family

ID=52673371

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102014219226.9A Withdrawn DE102014219226A1 (de) 2013-09-30 2014-09-24 Fahrzeugdiagnostik- und -prognostiksysteme und verfahren

Country Status (3)

Country Link
US (1) US20150094903A1 (de)
CN (1) CN104516344A (de)
DE (1) DE102014219226A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017207014A1 (de) * 2017-04-26 2018-10-31 Audi Ag Verfahren zur Datenerhebung
DE102018213011A1 (de) * 2018-08-03 2020-02-06 Bayerische Motoren Werke Aktiengesellschaft Verfahren, System, Fahrzeug, sowie ein Computerprogramm zur Ausführung einer Testprozedur
DE102020103904A1 (de) 2020-02-14 2021-08-19 Audi Aktiengesellschaft Verfahren zum Überwachen eines Kraftfahrzeugsystems, Telematikeinrichtung, und Servervorrichtung
DE102023001048A1 (de) 2023-03-17 2024-09-19 Mercedes-Benz Group AG Verfahren zum Betreiben eines Verbundes von elektronischen Recheneinrichtungen in einem Kraftfahrzeug, Computerprogrammprodukt, computerlesbares Speichermedium, Verbund von elektronischen Recheneinrichtungen sowie Kraftfahrzeug

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014219407A1 (de) * 2014-09-25 2016-03-31 Volkswagen Aktiengesellschaft Diagnoseverfahren und Erhebungsverfahren für Fahrzeuge
US9767626B2 (en) * 2015-07-09 2017-09-19 Ford Global Technologies, Llc Connected services for vehicle diagnostics and repairs
CN105068897A (zh) * 2015-07-17 2015-11-18 东莞市健创电子有限公司 实现车载智能双系统的方法及其双系统和该双系统平台
US9955240B1 (en) * 2016-10-24 2018-04-24 General Motors Llc System and method to dynamically determine status of vehicle to be used by mobile application
US10553041B2 (en) 2017-03-27 2020-02-04 Ford Global Technologies, Llc Method and apparatus for vehicle system wear prediction
US10510194B2 (en) 2017-06-12 2019-12-17 Ford Global Technologies, Llc Cloud-based connectivity energy budget manager
CN107291068B (zh) * 2017-07-28 2021-08-10 深圳市元征科技股份有限公司 车辆诊断方法和车辆诊断设备
JP2019100721A (ja) * 2017-11-28 2019-06-24 トヨタ自動車株式会社 診断装置、診断プログラム、及び接続設定方法
US11024102B2 (en) * 2018-05-10 2021-06-01 Mahle International Gmbh Apparatuses, systems, and methods for remotely capturing automotive vehicle diagnostic information, monitoring, and controlling
US11295560B2 (en) * 2018-08-01 2022-04-05 Ford Global Technologies, Llc Cloud-managed validation and execution for diagnostic requests
US10818106B2 (en) 2018-10-15 2020-10-27 Bendix Commercial Vehicle Systems Llc System and method for pre-trip inspection of a tractor-trailer
US11062534B2 (en) 2018-11-28 2021-07-13 Repairify, Inc. Remote automotive diagnostics
CN110322585A (zh) * 2019-06-28 2019-10-11 武汉小安科技有限公司 电动车自检方法、装置、设备及存储介质
DE102019121086B4 (de) * 2019-08-05 2022-02-03 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Diagnostikanordnung und Diagnostikkommunikation für einen Ladepark
US11417155B2 (en) * 2019-09-10 2022-08-16 Ford Global Technologies, Llc On-board data request approval management
US12111663B2 (en) * 2019-10-02 2024-10-08 William D. Nemedi System and method of organizing and controlling autonomous vehicles
US11488404B2 (en) 2019-10-14 2022-11-01 Ford Global Technologies, Llc Session unique access token for communications with a vehicle
CN110716535A (zh) * 2019-11-06 2020-01-21 深圳市道通科技股份有限公司 一种汽车诊断设备、系统及方法
CN112199145A (zh) * 2020-10-10 2021-01-08 上海星融汽车科技有限公司 车辆智能诊断方法、系统及诊断设备
CN115016445A (zh) * 2022-07-27 2022-09-06 浙江极氪智能科技有限公司 车辆的远程故障诊断方法、装置、车辆及计算机存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6956501B2 (en) 2002-06-12 2005-10-18 Hewlett-Packard Development Company, L.P. Wireless link for car diagnostics
US7317975B2 (en) 2004-02-03 2008-01-08 Haldex Brake Products Ab Vehicle telematics system

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7734287B2 (en) * 2000-04-10 2010-06-08 I/O Controls Corporation System for providing remote access to diagnostic information over a wide area network
US7092803B2 (en) * 2000-08-18 2006-08-15 Idsc Holdings, Llc Remote monitoring, configuring, programming and diagnostic system and method for vehicles and vehicle components
US7689334B2 (en) * 2006-09-28 2010-03-30 Perkins Engines Company Limited Engine diagnostic method
US8285439B2 (en) * 2009-04-07 2012-10-09 Ford Global Technologies, Llc System and method for performing vehicle diagnostics
US20110071725A1 (en) * 2009-09-23 2011-03-24 Ford Global Technologies, Llc Remotely interacting with a vehicle to perform servicing and engineering functions from a nomadic device or computer

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6956501B2 (en) 2002-06-12 2005-10-18 Hewlett-Packard Development Company, L.P. Wireless link for car diagnostics
US7317975B2 (en) 2004-02-03 2008-01-08 Haldex Brake Products Ab Vehicle telematics system

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017207014A1 (de) * 2017-04-26 2018-10-31 Audi Ag Verfahren zur Datenerhebung
US11373518B2 (en) 2017-04-26 2022-06-28 Audi Ag Method for data collection
DE102018213011A1 (de) * 2018-08-03 2020-02-06 Bayerische Motoren Werke Aktiengesellschaft Verfahren, System, Fahrzeug, sowie ein Computerprogramm zur Ausführung einer Testprozedur
DE102020103904A1 (de) 2020-02-14 2021-08-19 Audi Aktiengesellschaft Verfahren zum Überwachen eines Kraftfahrzeugsystems, Telematikeinrichtung, und Servervorrichtung
DE102023001048A1 (de) 2023-03-17 2024-09-19 Mercedes-Benz Group AG Verfahren zum Betreiben eines Verbundes von elektronischen Recheneinrichtungen in einem Kraftfahrzeug, Computerprogrammprodukt, computerlesbares Speichermedium, Verbund von elektronischen Recheneinrichtungen sowie Kraftfahrzeug

Also Published As

Publication number Publication date
US20150094903A1 (en) 2015-04-02
CN104516344A (zh) 2015-04-15

Similar Documents

Publication Publication Date Title
DE102014219226A1 (de) Fahrzeugdiagnostik- und -prognostiksysteme und verfahren
DE102014219232A1 (de) Fahrzeugdiagnostik- und -prognostiksysteme und verfahren
DE102019107797B4 (de) FAHRZEUGPROGNOSEN UND ABHILFEMAßNAHMEN
EP3425878B1 (de) Kommunikationsverfahren, vorrichtung und system zur ferndiagnose eines automobils
DE102011017590B4 (de) Verfahren zur Fahrzeugdatenaufzeichnung für Fahrzeugservice
CN106104636B (zh) 使用基于网络的计算基础结构的汽车检测系统
DE102017123406A1 (de) Telematikbasierte fahrzeugwertberichte
DE102018100095A1 (de) Softwareaktualisierungs-verwaltung
DE102009045711A1 (de) Datenübertragung an ein Fahrzeug und Laden des Fahrzeuges
DE102018122313A1 (de) Verfahren und System zum Übermitteln von Fahrzeugdiagnosen
DE102017100750A1 (de) Verfahren und vorrichtung für over-the-air-updates
DE102010040679A1 (de) Verfahren und System zum Durchführen von Funktionen der Wartung und Betriebstechnik von einer nomadischen Vorrichtung oder einem Computer aus
DE102017113435A1 (de) Fahrzeug-Gateway-Netzwerkschutz
DE102016102186A1 (de) Verfahren und Vorrichtung zur Fahrzeugwarnlichtbehandlung
DE112014005855T5 (de) System und Verfahren zur Fahrzeugdiagnosemittel-Datensammlung und -Analyse
DE102014114084A1 (de) Fahrzeugorts- und Fehlerdiagnosesysteme und -verfahren
DE102015116445A1 (de) Verteilen geheimer Schlüssel zum Verwalten eines Zugriffs auf ECUs
EP2705430A1 (de) System zur diagnose einer komponente in einem fahrzeug
DE102014219158A1 (de) Systeme und verfahren für die identifikation eines beeinträchtigten moduls
DE102017115717A1 (de) Verfahren und systeme zum speichern in und abrufen aus einer fahrzeugdatenbank
DE102013211515A1 (de) Modul und System zur Fahrzeugdiagnose
DE102013107920A1 (de) Verfahren und Vorrichtung für periodische an Bord ausgeführte Regelkonformitätstests
DE112016004325T5 (de) Universalsensor und/oder Sensorcluster zur Bereitstellung eines Detektionsmusters
DE102015208856A1 (de) Verfahren und System für ein Fahrzeugrechensystem, das zu einer Social Media Website kommuniziert
DE102016105400A1 (de) Verfahren und systeme zur konfiguration eines fahrzeugmerkmals

Legal Events

Date Code Title Description
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee