DE112014005855T5 - System und Verfahren zur Fahrzeugdiagnosemittel-Datensammlung und -Analyse - Google Patents

Abstract

Es ist ein Verfahren zum Überwachen einer Verwendung einer Komponente während Fahrzeugserviceaktivitäten entwickelt worden. Das Verfahren umfasst ein Empfangen mit einem Diagnosegerät von Diagnosedaten von einem Fahrzeug, Empfangen mit dem Diagnosegerät einer Komponentenkennung entsprechend einer Komponente in dem Fahrzeug, die in einem Servicevorgang in Erwiderung auf die Diagnosedaten von dem Diagnosegerät ersetzt wird, Übertragen mit dem Diagnosegerät der Diagnosedaten und der Komponentenkennung an einen Server und Übertragen mit dem Server der Komponentenkennung an ein Hörer-Computergerät, das einem Hersteller der Komponente zugeordnet ist.

Description

• INANSPRUCHNAHME DER PRIORITÄT
• Diese Anmeldung nimmt die Priorität der vorläufigen US-Anmeldung Nr. 61/920,171 mit dem Titel ”System and Method For Automotive Diagnostic Tool Data Collection And Analysis”, die am 23. Dezember 2013 eingereicht wurde, in Anspruch, wobei deren gesamter Inhalt hierin durch Bezugnahme enthalten ist. Diese Anmeldung nimmt ferner die Priorität der vorläufigen US-Anmeldung Nr. 61/922,203 mit dem Titel ”System And Method For Semi-Automated Assistance In Automotive Diagnostics”, die am 31. Dezember 2013 eingereicht wurde, in Anspruch, wobei deren gesamter Inhalt hierin durch Bezugnahme enthalten ist.
• TECHNISCHES GEBIET
• Diese Anmeldung betrifft im Allgemeinen Fahrzeugwartungssysteme und insbesondere Systeme, die Fahrzeugserviceaktivitäten aufzeichnen und analysieren.
• HINTERGRUND
• In den letzten Jahren haben Fahrzeuge und das Gebiet der Fahrzeugwartung/Fahrzeuginstandhaltung ein rasches Wachstum bei computergestützten Systemen sowohl innerhalb von Kraftfahrzeugen als auch in computergestützten Diagnosemitteln, die Wartungsprobleme mit den Fahrzeugen identifizieren, erfahren. Moderne Fahrzeuge umfassen ein oder mehrere Computersysteme, die oftmals als eine elektronische Steuereinheit (electronic control unit – ECU) bezeichnet wird. In einigen Fahrzeugen steuert und überwacht die ECU die Betriebsabläufe von zahlreichen Systemen, einschließlich, in nicht einschränkender Weise, der Brennkraftmaschine, der Lenkung, der Reifen, des Getriebes, der Bremsen, der Kraftstoffzufuhr oder der Batterieladezustandsüberwachung, und von Klimasteuersystemen. Einige Fahrzeuge umfassen ebenfalls zahlreiche Sensoren, die verschiedene Aspekte des Betriebs des Fahrzeugs überwachen. Die ECU empfängt die Sensordaten und ist eingerichtet, um Diagnose-Fehlercodes (diagnostic trouble codes – DTCs) zu erzeugen, wenn die Sensoren anzeigen/angeben, dass ein oder mehrere Systeme in dem Fahrzeug ausfallen können oder außerhalb von vorgegebenen Parametern arbeiten.
• Viele Fahrzeuge verwenden den Controller-Area-Network-(CAN)Fahrzeug-Bus, um Daten zwischen der ECU und den On-Board-Sensoren und -Komponenten in dem Fahrzeug zu übertragen. Der CAN-Bus oder andere gleichwertige Datennetzwerke in einem Fahrzeug stellen ein gemeinsames Kommunikations-Framework zwischen der ECU und den verschiedenen Sensoren und Systemen in dem Fahrzeug bereit. Zusätzlich ermöglicht der CAN-Bus oder ein gleichwertiges Netzwerk eine Kommunikation zwischen der ECU und externen Diagnosemitteln/Diagnosetools. Diagnosemittel sind ebenfalls digitale Computer mit Kommunikationsschnittstellen und Eingabe-/Ausgabegeräten, einschließlich Bildschirmen/Bildschirmanzeigen und Eingabesteuertasten, die Informationen an einen Mechaniker weitergeben und es dem Mechaniker ermöglichen, Tests durchzuführen und Befehle an die ECU zu senden. Die ECU und Diagnosemittel verwenden oft ein Industriestandardprotokoll, wie beispielsweise eine Version des On-Board-Diagnose-(onboard diagnostics – OBD)Protokolls, einschließlich des OBD-II-Protokolls. Kfz-Mechaniker und Servicespezialisten verwenden ein breites Spektrum von digitalen Diagnosemitteln zum Herstellen einer Schnittstelle mit den ECUs in Fahrzeugen, um Probleme mit den Fahrzeugen, die oftmals durch DTC-Daten von der ECU angegeben werden, festzustellen. Einige Diagnosemittel sind ebenfalls eingerichtet, um Befehle an die ECU zu senden, um eine direkte Steuerung von bestimmten Systemen innerhalb des Fahrzeugs während eines Servicevorganges bereitzustellen. Zum Beispiel kann ein Mechaniker einen Befehl senden, um den Anlasser und die Brennkraftmaschine (Motor) in einer kontrollierteren Art und Weise zu testen, als es durch Starten des Fahrzeugs von Hand möglich ist.
• Während Kfz-Diagnose-Geräte heutzutage weit verbreitet sind, sind die Diagnosegeräte typischerweise für eine isolierte Nutzung mit einem Fahrzeug ausgelegt. Zum Beispiel werden die meisten Fahrzeuge, die in einem Servicezentrum für eine Wartung ankommen, mit einem Diagnosegerät verbunden, um ein Feststellen von Problemen in Zusammenhang mit dem Fahrzeug zu erleichtern und um sicherzustellen, dass die Probleme behoben sind, nachdem die Wartung durchgeführt worden ist. Die Diagnoseergebnisse werden typischerweise von einem oder einer kleinen Anzahl von Mechanikern in dem Servicezentrum gelesen und werden lediglich während eines bestimmten Servicebesuchs verwendet. Während also die bestehenden Diagnosegeräte sicherlich den Mechanikern, die eine Fahrzeugwartung und -Reparatur durchführen, helfen, liefern die bestehenden Diagnosegeräte keine Informationen im größeren Maßstab über den Gesamtumfang der Arbeitsvorgänge in einem Servicezentrum. Zum Beispiel erzeugen bestehende Diagnosesysteme keine detaillierten Aufzeichnungen/Datensätze über die Häufigkeit von üblichen/allgemeinen Reparaturvorgängen, die Zeitdauer für die Servicevorgänge, den Grad des Erfolgs für die Servicevorgänge, die Nachfrage nach Ersatzteilen, die in den Reparaturen verwendet werden, und weitere Statistiken. Einige dieser Informationen können durch die Mechaniker und anderem Servicepersonal von Hand aufgezeichnet werden, allerdings ist das manuelle Aufzeichnen von Daten sowohl zeitaufwändig als auch fehleranfällig. Die Probleme werden in größeren Serviceorganisationen, die mehrere Servicezentren an vielen Standorten mit hunderten oder sogar tausenden von Mitarbeitern betreiben, weiter verschärft. Infolgedessen würden Verbesserungen bei Diagnosegeräten und Datenanalysesystemen, die eine Analyse von Aktivitäten in Fahrzeugservicezentren ermöglichen, von Vorteil sein.
• ZUSAMMENFASUNG
• Ein Fahrzeugwartungs-Analysesystem stellt bereit einen Service/Dienst mit einer teilweise öffentlichen Programmschnittstelle (application programming interface – API) für Hersteller von Kfz-Diagnosegeräten, der ermöglicht, dass Diagnosegeräte Diagnosedaten an einen Wartungsanalyseservice/Wartungsanalysedienst durch ein Datennetzwerk übertragen und dass Empfänger-Computergeräte Diagnosedaten über eine zum Teil öffentliche Standard-API empfangen. Die Diagnosedaten identifizieren die allgemeinen und spezifischen Typen von Fahrzeugen, die einen Service in Servicezentren erhalten, die Arten der Wartungen, die an den Fahrzeugen durchgeführt werden, die Diagnosetestverfahren, die unter Verwendung der Diagnosegeräte durchgeführt werden, und weitere Informationen über die Aktivitäten der Servicezentren. Die Empfängeranwendungen empfangen die Diagnosedaten und erzeugen Reports/Berichte und Zusammenfassungen der Serviceaktivitäten in einem oder mehreren Servicezentren unter Verwendung der Diagnosedaten, die unter Verwendung der Kfz-Diagnosegeräte erzeugt werden.
• In einer Ausführungsform ist ein Verfahren zum Überwachen einer Komponentenverwendung während der Fahrzeugserviceaktivitäten entwickelt worden. Das Verfahren umfasst ein Empfangen mit einem Diagnosegerät von Diagnosedaten von einem Fahrzeug, Empfangen mit dem Diagnosegerät einer Komponentenkennung, die einer Komponente in dem Fahrzeug entspricht, die in einem Servicevorgang in Erwiderung auf die Diagnosedaten von dem Diagnosegerät ersetzt wird, Übertragen mit dem Diagnosegerät der Diagnosedaten und der Komponentenkennung an einen Server und Übertragen mit dem Server der Komponentenkennung an ein Empfänger-Computergerät, das einem Hersteller der Komponente zugeordnet ist.
• In einer weiteren Ausführungsform ist ein Verfahren zum Überwachen einer Fahrzeugserviceaktivität entwickelt worden. Das Verfahren umfasst ein Empfangen mit einer Mehrzahl von Diagnosegeräten einer Mehrzahl von Diagnosedaten von einer Mehrzahl von Fahrzeugen, Übertragen mit der Mehrzahl von Diagnosegeräten der Mehrzahl von Diagnosedaten und einer Mehrzahl von Serviceaufzeichnungen/Service-Datensätzen entsprechend einer Mehrzahl von Servicevorgängen, die an der Mehrzahl von Fahrzeugen in Erwiderung auf die Mehrzahl von Diagnosedaten von der Mehrzahl von Fahrzeugen durchgeführt werden, an einen Server, Erzeugen mit dem Server einer Zusammenfassung der Mehrzahl von Servicevorgängen mit Bezug auf die Mehrzahl von Serviceaufzeichnungen und die Mehrzahl von Diagnosedaten von der Mehrzahl von Diagnosegeräten und Übertragen mit dem Server der Zusammenfassung an ein Empfänger-Computergerät, das einem Servicezentrum zugeordnet ist, das die ersten und zweiten Servicevorgänge an dem Fahrzeug durchführt.
• KURZE BESCHREIBUNG DER ZEICHNUNGEN
• 1 zeigt ein schematisches Diagramm eines Systems für eine automatisierte Abfrage, Speicherung und Analyse von Fahrzeugdiagnosedaten, die während des Verlaufs der Reparatur und Wartung des Fahrzeugs erzeugt werden.
• 2 zeigt ein Blockdiagramm eines Verfahrens zur Erzeugung und Sammlung von Fahrzeugdiagnoseinformationen mit einem Diagnosegerät.
• 3 zeigt ein Blockdiagramm eines Verfahrens zur Erzeugung von zusammengefassten Berichten, die die Fahrzeugserviceaktivitäten von einem oder mehreren Fahrzeugservicezentren unter Verwendung durch Diagnosegeräte erzeugten Daten verfolgen.
• 4 zeigt ein Blockdiagramm eines Verfahrens zur Analyse von anonymisierten Daten entsprechend den Fahrzeugserviceaktivitäten von mehreren Fahrzeugservicezentren, um Informationen über den Verbrauch von Komponenten und weiteren Komponenten an den Servicezentren bereitzustellen.
• 5 zeigt ein Blockdiagramm eines Verfahrens zum Identifizieren von Servicevorgängen zum Unterstützen eines Mechanikers beim Lösen eines Problems mit einem Fahrzeug unter Verwendung eines automatisierten Systems, das Diagnosedaten von einem Diagnosegerät empfängt.
• AUSFÜHRLICHE BESCHREIBUNG
• Zum Zwecke der Förderung eines Verständnisses der Grundsätze der hierin beschriebenen Ausführungsformen wird nun Bezug auf die Zeichnungen und Beschreibungen in der folgenden schriftlichen Beschreibung genommen. Es ist nicht beabsichtigt, durch die Bezugnahmen den Schutzumfang des Gegenstandes zu beschränken. Dieses Patent umfasst ebenfalls alle/jegliche Änderungen/Abwandlungen und Modifikationen an den dargestellten Ausführungsformen und umfasst weitere Anwendungen der Grundsätze der beschriebenen Ausführungsformen, wie sie normalerweise bei einem Fachmann auf dem betreffenden Gebiet auftreten würden.
• Wie hierin verwendet, bezieht sich der Begriff ”Kunde” auf einen Fahrzeugserviceanbieter, der Diagnosegeräte während einer Fahrzeugwartung verwendet, Daten von den Diagnosegeräten an einen Online-Wartungsanalysedienst sendet und aggregierte Diagnosegerätedaten, die in dem Online-Wartungsanalysedienst gespeichert werden, analysiert. Beispiele von Kunden umfassen einzelnen Mechaniker, einzelne Serviceshops, die mehrere Mechaniker beschäftigen, und größere Serviceorganisationen, die mehrere Servicezentren betreiben. Da viele Kunden Organisationen mit mehreren Beschäftigen sind, werden Personen, die einem Kunden zugeordnet sind, einzelne Benutzerkonten zugeordnet, um auf einige oder alle Daten, die der Online-Wartungsanalysedienst von dem Kunden empfängt, zuzugreifen.
• Wie hierin verwendet, bezieht sich der Begriff ”Dritte/Dritter” auf jede Person oder Organisation, die auf in dem Online-Wartungsanalysedienst für einen oder mehrere Kunden zu Analysezwecken gespeicherten Daten zugreift. Die meisten Dritt-Benutzer erzeugen nicht die Diagnosedaten durch die Fahrzeugserviceaktivitäten, die die Kunden durchführen. Stattdessen analysieren die Dritten Trends und weitere Statistiken über die Aktivitäten von einem oder mehreren Kunden, um beispielsweise die Effizienz der Produktverteilung an die Kunden zu verbessern. Ein Beispiel eines Dritten ist ein Automobilzulieferer, der die Servicetrends von einem oder mehreren Kunden analysiert, um eine zukünftige Nachfrage nach Ersatzteilen, die der Drittanbieter an die Kunden verkauft, vorherzusagen. Die Funktionen von Kunden und Dritten werden nachfolgend ausführlicher beschrieben. Ein Dritter und ein Kunde stellen oftmals verschiedene Organisationen dar, aber eine einzelne Organisation kann die Rolle von sowohl einem Kunden als auch einem Dritten übernehmen.
• Wie hierin verwendet, bezieht sich der Begriff ”Hörer/Hörer” auf ein Computergerät/Rechengerät, das entweder Diagnoserohdaten oder verarbeitete Daten, die aus den Diagnosedaten von einem Online-Wartungsanalysedienst erzeugt werden, empfängt. In einer Ausführungsform empfängt ein Hörer/Empfänger, der einem Kunden zugeordnet ist, eine Aggregation der Diagnosedaten von einem oder mehreren Diagnosegeräten, die durch den Kunden eingesetzt werden, von dem Wartungsanalysedienst. Die Hörer/Empfänger empfangen ebenfalls Zusammenfassungen und Analyseberichte von dem Wartungsanalysedienst in einigen Ausführungsformen. Neben den Kunden führen die Dritten Hörer-Client-Anwendungen aus, die Statistiken oder anonymisierte Diagnosedaten von dem Wartungsanalysedienst empfangen. In einer Ausführungsform hat ein Kunde Zugriff auf Diagnosedaten von Diagnosegeräten, die bei dem jeweiligen Kunden registriert sind, um zu verhindern, dass ein Kunde Diagnosedaten, die durch den anderen Kunden erzeugt werden, empfängt. Ein Hörer/Empfänger, der einem Dritten zugeordnet ist, kann Diagnosedaten von beiden Parteien abrufen, obwohl die Diagnosedaten anonymisiert oder auf sonstige Weise unkenntlich gemacht werden, um den Umfang des Zugangs für den Dritt-Hörer zu beschränken. Wie weiter unten beschrieben wird, implementiert der Wartungsanalysedienst Software, die mit einer Programmschnittsteile (application programming interface – API), die einer allgemein bekannten Spezifikation entspricht, kompatibel ist. Folglich umfassen verschiedene Ausführungsformen von Hörer-Client-Anwendungen Softwareprogramme, die einige oder alle gespeicherten Diagnosedaten oder andere Analysedaten von dem Wartungsanalysedienst für eine Anzeige oder Weiterverarbeitung abrufen.
• 1 zeigt ein System 100, das die Fahrzeugserviceaktivitäten von Servicezentren für einen oder mehrere Kunden unter Verwendung von Daten, die durch Diagnosegeräte erzeugt werden, überwacht und Überwachungs- und Analysedienstleistungen für die Kunden und Dritte, wie beispielsweise Fahrzeugkomponentenzulieferer, bereitstellt. Wie hierin verwendet, bezieht sich der Begriff ”Serviceaktivität” auf die gesamten Operationen/Arbeitsabläufe, die ein oder mehrere Mechaniker oder andere Kfz-Techniker an einem Kraftfahrzeug durchführen. Beispiele einer Serviceaktivität umfassen eine Diagnose, eine routinemäßige Wartung des Fahrzeugs, Reparatur des Fahrzeugs, Rückrufservice und dergleichen. Das System 100 umfasst ein Online-Diagnose-Analysesystem 104, Diagnosegeräte und weitere Computergeräte/Rechenvorrichtungen, die von Kunden 114 und 118 in dem Ausführungsbeispiel von 1 bedient/betrieben werden, einen Standard-Kunden-Hörerdienst 124, einen proprietären Hörerdienst für einen bestimmten Kunden 128, einen Dritt-Hörer 132, einen Diagnoseanfrage-Hörer 156 und ein Call-Center 140. Zum Zwecke der Veranschaulichung zeigt 1 einen Kfz-Mechaniker 160, der das Diagnosegerät 116C verwendet, um Diagnosedaten von einer elektronischen Steuereinheit (electronic control unit – ECU) in einem Kraftfahrzeug als Teil eines Fahrzeugwartungsvorganges abzurufen. Das Diagnosegerät 116C ist eines der Diagnosegeräte 116A–116C, das dem Kunden 114 und einem einzelnen Mechaniker 160 in dem System 100 zugeordnet ist. Der Mechaniker 160 verwendet optional eine elektronische Kommunikationsvorrichtung 168, wie beispielsweise ein Smartphone, ein Tablet, einen Personal-Computer oder eine andere tragbare Rechenvorrichtung, um mit dem Diagnose-Analysesystem 104 und dem Call-Center 140 in Verbindung zu stehen, um Wartungsprobleme mit dem Fahrzeug zu lösen.
• In dem System 100 ist das Diagnose-Analysesystem 104 ausgeführt mit einer oder mehreren Rechenvorrichtungen, die eingerichtet sind, um als Server zu arbeiten/betrieben zu werden, und die operativ verbunden sind mit den Rechenvorrichtungen, die mit Kunden und Dritten durch ein oder mehrere Datennetzwerke einschließlich Local Area Networks (LANs) oder Wide Area Networks (WANs) verbunden sind bzw. in Verbindung stehen. In einer Ausführungsform im großen Maßstab umfasst das Diagnose-Analysesystem 104 mehrere Server in einer Clusteranordnung/Clusterkonfiguration mit mehreren Digitalprozessoren, Netzwerkschnittstellenvorrichtungen und Datenspeichervorrichtungen einschließlich Festkörper- oder Magnetplatten-Speichervorrichtungen, die in einem redundanten Array unabhängiger Datenträger (Redundant Array of Independent Disks – RAID) angeordnet sind. In einer Ausführungsform sind die Server mit den Datenspeichervorrichtungen durch eine Speichernetzwerk-(Storage Area Network – SAN)Konfiguration, eine netzwerkspeicher-(Network-Attached Storage – NAS)Konfiguration oder jede andere geeignete Konfiguration, die den Servern ermöglicht, auf gespeicherte Daten zuzugreifen, verbunden.
• Die Digitalprozessoren in dem Diagnose-Analysesystem 104 führen gespeicherte Software-Programmanweisungen aus zum Implementieren von Servern für eine Kommunikation mit den Rechenvorrichtungen der Kunden und Dritten, Datenbanken zum Speichern und Indizieren von Daten, die von den Kunden und Dritten empfangen werden, und optional eine oder mehrere Analyse-Engines, die eine Datenanalyse durchführen und Berichte, Zusammenfassungen und weitere Analyseausgaben zur Überprüfung durch die Kunden und Dritten erzeugen. In einer Ausführungsform implementiert der Wartungsanalysedienst eine öffentliche Programmschnittstelle (application programming interface – API), die für verschiedene Kunden frei zugänglich ist. Beispiele von Protokollen, die für die Implementierung der öffentlichen API zwischen dem Diagnose-Analysesystem 104, Diagnosegeräten und Hörern/Empfängern geeignet sind, umfassen die XML-RPC, JSON-RPC und SOAP-Protokolle, die Beispiele von Web-Service-Protokollen darstellen, und andere Middleware-Protokolle einschließlich, in nicht einschränkender Weise, herkömmliche RPC, Java RMI, COBRA und dergleichen. In der Ausführungsform von 1 stellt die öffentliche API ein gemeinsames Datenformat und eine Schnittstelle für eine Übertragung von Diagnosedaten von einem oder mehreren Diagnosegeräten von jedem Kunden, einschließlich der Diagnosegeräte 116A–116C und 120A–120C für die Kunden 114 beziehungsweise 118, zu dem Diagnose-Analysesystem 104 für eine Speicherung bereit.
• Die öffentlichen APIs stellen ebenfalls vorgegebene Schnittstelen bereit, um ein Abfragen der Diagnosegerätdaten und Analyseberichte durch Kunden-Hörer zu ermöglichen. In einer Ausführungsform implementiert das Diagnose-Analysesystem 104 ein Publish-Subscribe-(pub-sub)Kommunikationssystem, in dem das Diagnose-Analysesystem 104 Diagnosedaten, die von den Diagnosegeräten für einen bestimmten Kunden empfangen werden, an die Hörer-Rechenvorrichtungen, die den veröffentlichten Datenstrom abonnieren, veröffentlicht oder ”pusht/vorantreibt”. In alternativen Ausführungsformen laden die Hörer-Rechenvorrichtungen einzelne Service-Datensätze oder Gruppen von Service-Datensätzen in regelmäßigen Abständen oder auf Ad-hoc-Basis herunter. Wie hierin verwendet, bezieht sich der Begriff ”Service-Datensatz” auf Daten, die während eines Servicevorganges, der an einem Fahrzeug durchgeführt wird, erzeugt werden. Der Service-Datensatz umfasst in nicht einschränkender Weise Diagnosedaten, die ein Diagnosegerät von einer ECU in dem Fahrzeug abruft, zusätzliche Diagnoseinformationen von verschiedenen Testmitteln/Testgeräten in einem Fahrzeugwartungsbetrieb, eine Liste von Komponenten, die während der Serviceaktivität ersetzt oder repariert werden, und eine Beschreibung von einem oder mehreren Servicevorgängen, die ein Mechaniker während der Serviceaktivität durchführt. In einer Ausführungsform formatiert das Diagnose-Analysesystem 104 die Diagnosedaten für eine Anzeige unter Verwendung von beispielsweise HTML oder einer anderen Formatierungssprache und die Hörer/Empfänger zeigen die Diagnosedaten unter Verwendung eines Web-Browsers oder eines anderen geeigneten Anzeigeprogramms an. In einer weiteren Ausführungsform rufen die Hörer die Diagnosedaten ab und die Hörer führen lokale Software-Anwendungen aus, um grafische Anzeigen der Diagnosedaten zu erzeugen. In einigen Ausführungsformen führt das Diagnose-Analysesystem 104 zusätzliche Analysen durch und erzeugt Zusammenfassungen, Graphen/Grafiken und andere Berichte/Reports, die auf der Grundlage der Diagnosedaten erzeugt werden, aber nicht notwendigerweise die Diagnosedaten direkt umfassen.
• Um die Diagnosedaten von einem oder mehreren Kunden zu speichern, implementiert das Diagnose-Analysesystem 104 eine Kundendatenbank 108 und Diagnosedatenbank 112. Die Kundendatenbank 108 umfasst Authentifizierungsinformationen zum Empfangen von Daten von den Diagnosegeräten und zum Übertragen von Daten an die verschiedenen Hörerprogramme, die mit verschiedenen Kunden in Zusammenhang/Verbindung stehen. Die Kundendatenbank umfasst ebenfalls Authentifizierungsinformationen für Dritt-Hörer. Die Diagnosedatenbank 112 speichert die Diagnosedaten, die von den Diagnosegeräten empfangen werden. Die Kundendatenbank 108 bringt die Kundeninformationen mit jedem Datensatz in der Diagnosedatenbank 112 in Verbindung, um den Kunden, der jeden Service-Datensatz erzeugt, zu identifizieren. Die Datenbanken 108 und 112 ermöglichen eine effiziente Speicherung, Suche und Abfrage der Diagnosedaten von den Diagnosegeräten zur Übertragung an die Hörer oder für die Erzeugung von Berichten unter Verwendung von Analysesoftware in dem Diagnose-Analysesystem 104. Die Datenbanken 108 und 112 sind zum Beispiel als relationale Datenbanken, Objektspeicher, hierarchische Datenbanken oder mit irgendeinem anderen geeigneten Datenspeicher und Abfrageformat implementiert.
• Während der Datenanalyse und Datenabfrage verwendet das Diagnose-Analysesystem 104 Zugriffskontrolllisten oder andere Zugangskontrolltechniken, um sicherzustellen, dass jeder Hörer nur Diagnosedaten von einem autorisierten Kunden empfängt. Zusätzlich ruft das Diagnose-Analysesystem 104 Diagnosedaten für einen oder mehrere Dritt-Hörer ab und eine Zugriffskontrolle/Zugriffssteuerung oder ein anderer Filter entfernt oder verändert Abschnitte der Diagnosedaten-Datensätze, um die Anonymität zu bewahren. Zum Beispiel, wenn ein Service-Datensatz eine Fahrgestellnummer (vehicle identification number – VIN) oder eine andere eindeutige Komponentenkennung für ein Fahrzeug umfasst, auf die in einem Service-Datensatz verwiesen wird, dann entfernt das Diagnose-Analysesystem 104 entweder die eindeutigen Erkennungsdaten von dem Datensatz oder wendet einen kryptografisch sicheren Hash bei der eindeutige ID an, um einen pseudonymen Datensatz an die Dritt-Hörer bereitzustellen.
• In dem System 100 verwendet jeder Kunde zumindest ein Diagnosegerät während des Verlaufs der Wartung und Reparatur des Automobils. 1 zeigt zwei beispielhafte Kunden 114 und 118, die die Diagnosegeräte 116A–116C beziehungsweise 120A–120C verwenden. Jedes Diagnosegerät stellt eine spezielle Computervorrichtung dar, die eingerichtet ist, um sich mit den ECUs in einer breiten Palette von Fahrzeugen zu koppeln/verbinden, um Daten von den ECUs aufzuzeichnen und Befehle/Anweisungen an die ECUs zu senden. Die Diagnosegeräte umfassen Benutzereingabe- und Ausgabevorrichtungen, einschließlich zum Beispiel Tasten/Knöpfe, Tastaturen, Schalter und Touchscreens. Die Diagnosegeräte umfassen ebenfalls einen Speicher zum Speichern von programmierten Anweisungen, der aufgezeichneten Diagnosedaten von Fahrzeugen und einen Datensatz von Befehlen und Tests, die an die ECUs in Fahrzeugen während einer Wartung übertragen werden. In einigen Ausführungsformen umfasst das Diagnosegerät eine Netzwerk-Schnittstellenvorrichtung, die aufgezeichnete Daten an das Diagnose-Analysesystem 104 überträgt.
• Während eines Betriebs werden die Diagnosegeräte mit den ECUS in den Fahrzeugen verbunden, um Fahrzeuginformationen, Fehlercodes, Sensordaten von Sensoren im Fahrzeug abzurufen und um den Betrieb von einem oder mehreren Systemen in dem Fahrzeug durch Erzeugen von Befehlen für die ECU zu testen. Wenn ein Diagnosegerät mit der ECU in einem Fahrzeug verbunden wird, ruft das Diagnosegerät die VIN oder andere Identifizierungsinformationen für das Fahrzeug, die eine automatische Identifizierung der Marke und des Modells des Fahrzeugs im Test ermöglicht/ermöglichen, ab. Das Diagnosegerät zeichnet ebenfalls einen Datenstrom von Sensoren in dem Fahrzeug und beliebige Fehlercodes von der ECU in dem Fahrzeug auf. Einige Diagnosegerät-Ausführungsformen rufen die Diagnosedaten in dem OBD-II- oder anderem Industriestandardformat, das ermöglicht, dass das Diagnosegerät mit einer breiten Palette von Fahrzeugen operativ verbunden werden kann, ab. In dem System 100 können die Diagnosegeräte durch mehrere Hersteller hergestellt werden. Zum Beispiel verwendet in 1 der Kunde 114 Diagnosegeräte 116A–116C von einem ersten Hersteller, während der Kunde 118 Diagnosegeräte 120A–120C von einem zweiten Hersteller verwendet. In anderen Ausführungsformen verwendet ein einzelner Kunde Diagnosegeräte von zwei oder mehreren Herstellern.
• In der Ausführungsform von 1 umfassen die Diagnosegeräteeine Netzwerkschnittstellenvorrichtung, wie beispielsweise eine drahtgebundene oder drahtlose Netzwerkschnittstellenvorrichtung, die eine direkte Kommunikation mit dem Online-Diagnose-Analysesystem 104 ermöglicht. Das Diagnosegerät erzeugt einen Datensatz von einer oder mehreren Wechselwirkungen/Interaktionen mit einem Fahrzeug und überträgt die Aufzeichnungen an das Online-Diagnose-Analysesystem 104 unter Verwendung von zum Beispiel dem TCP/IP-Protokoll für eine Datenübertragung und der öffentlichen API für das Diagnose-Analysesystem 104, um die Diagnosevorrichtung mit dem entsprechenden Kundenkonto zu authentifizieren und um den aufgezeichneten Datensatz in einem Format, das mit dem Diagnose-Analysesystem 104 kompatibel ist, zu übertragen. In einer alternativen Konfiguration, wenn das Diagnosegerät keine Netzwerkschnittstellenvorrichtung umfasst, dann speichert das Diagnosegerät die Diagnosedaten in einem internen Speicher oder einer entfernbaren Speichervorrichtung. Die gespeicherten Diagnosedaten werden anschließend an einen PC oder eine andere Rechenvorrichtung, die die Diagnosedaten an das Diagnose-Analysesystem 104 überträgt, übertragen. In einigen Ausführungsformen, wo ein bestehendes Diagnosegerät nicht aktualisiert werden kann, um die öffentlichen APIs für eine Kommunikation mit dem Diagnose-Analysesystem 104 zu verwenden, werden die gespeicherten Diagnosedaten übertragen an einen PC, der ein Übersetzungsprogramm zum Umwandeln/Konvertieren der Diagnosedaten in ein Format, das mit der öffentlichen API kompatibel ist, und Übertragen der Daten an das Diagnose-Analysesystem 104 ausführt.
• In einem Betriebsmodus übertragen die Diagnosegeräte Diagnosedaten an das Diagnose-Analysesystem 104, ohne dass eine zusätzliche Eingabe von einem Mechaniker oder anderem Bedienpersonal erforderlich ist. Zum Beispiel umfasst das Wartungstool 116C für den Kunden 114 einen Speicher mit einem gespeicherten Authentifizierungsschlüssel, der bei der Kundendatenbank 108 für den Kunden 114 registriert ist. Der Authentifizierungsschlüssel oder eine andere eindeutige Kennung, der/die in dem Speicher des Wartungstools 116C gespeichert ist, ermöglichen es dem Diagnose-Analysesystem 104, das bestimmte Diagnosegerät, das jeden Service-Datensatz zur Speicherung in der Diagnosedatenbank 112 erzeugt, zu identifizieren. Wenn ein Mechaniker das Wartungstool 116C mit einem Fahrzeug verbindet, sendet das Wartungstool 116C einen ersten Datensatz an das Diagnose-Analysesystem 104, der Identifizierungsinformationen für das Fahrzeug umfasst. Das Wartungstool 116C erzeugt zusätzliche Diagnosedatensätze, wenn der Mechaniker Fehlercodes abruft, streamt Daten von dem Fahrzeug und führt zusätzliche Test während des Wartungsvorganges durch. In einer Ausführungsform überträgt das Wartungstool 116C ebenfalls einen Service-Datensatz an das Diagnose-Analysesystem 104, wenn das Wartungstool 116C von dem Fahrzeug getrennt wird, um es einem Hörerprogramm zu ermöglichen, die Länge der Zeit für jede Sitzung zwischen einem Diagnosegerät und einem Fahrzeug zu identifizieren. In einer Ausführungsform zeichnet das Diagnosegerät 116C einen Zeitstempel entsprechend dem Zeitpunkt der Erzeugung für jeden Satz von Diagnosedaten auf, um eine Analyse der Zeit, bei der jeder Test oder Betrieb durchgeführt wird, zu ermöglichen. In dem System 100 übertragen die Diagnosegeräte die Diagnosedaten an das Diagnose-Analysesystem 104, ohne dass eine zusätzliche Eingabe von einem Mechaniker erforderlich ist oder Ablenkungen des Mechanikers anderweitig vorkommen. Somit ermöglicht das System 100 eine Sammlung der Diagnosedaten mit wenig oder keiner zusätzlichen Belastung für die Mitarbeiter der Kfz-Servicezentren, um Diagnosedaten manuell aufzuzeichnen.
• In dem Ausführungsbeispiel von 1 umfasst das System 100 die Hörer 124, 128, 132 und 156. Jeder der Hörer ist eine Softwareanwendung, die, zumindest teilweise auf einem Unterhaltungselektronikgerät, wie beispielsweise ein PC, Smartphone oder Tablet, ausgeführt wird. Wie weiter unten beschrieben, erfordern einige Ausführungsformen der Hörer, die eine rechenintensive Analyse von Diagnosedaten durchführen, zusätzliche Verarbeitungsfähigkeiten über die Fähigkeiten einer einzelnen Rechenvorrichtung, wie beispielsweise ein einzelner Personal-Computer (PC), hinaus. In diesen Ausführungsformen implementiert ein Kunde oder Dritter ein Computer-Cluster oder anderes Rechensystem mit ausreichenden Verarbeitungsfähigkeiten, um die Analyse durchzuführen, und ein Hörer-Client zeigt die Analyseergebnisse an.
• Der Hörer 124 ist ein ”Standard-”Hörerprogramm, das Kunden zum Überwachen der Diagnosedaten in dem Diagnose-Analysesystem 104 zur Verfügung gestellt wird. In einer Ausführungsform wird der Standard-Hörer implementiert als eine dynamische Web-Anwendung, die einige oder alle der Diagnosedaten von dem Diagnose-Analysesystem 104 abruft und den Status und die letzte Nutzungshistorie für jede der Diagnosevorrichtungen und die entsprechenden Fahrzeuginformationen für die Fahrzeuge, die einem Service an einer oder mehreren Servicezentren unterzogen werden, anzeigt. Der Standard-Hörer stellt ebenfalls einen oder mehrere zusammengefaste Berichte für die Diagnosedaten über eine vorgegebene Zeitdauer, wie beispielsweise eine Stunde, ein Tag, eine Woche oder ein Monat, bereit. Die Berichte umfassen Text und Grafiken, die einen ”Dashboard-”Überblick von Informationen von dem Diagnose-Analysesystem 104 mit einer Benutzerschnittstelle, die den Abruf und die Anzeige von detaillierten Service-Datensätzen auf Anfrage ermöglicht, bereitstellen. Zum Beispiel stellt in einer Konfiguration der Hörer dar eine grafische Schlüsselleistungsindikatoren-(key performance indicator – KPI)Anzeige, die eine grafische Metrik der Gesamtzahl von Fahrzeugdiagnosetests, die in einem Servicezentrum während einer Arbeitsschicht durchgeführt worden sind, bereitstellt. Für größer Kunden, die mehrere Servicezentren betreiben, ist der Standard-Hörer eingerichtet, um verschiedene Datenumfänge in Verbindung mit verschiedenen Benutzerkonten, die bei den Kunden registriert sind, darzustellen. Zum Beispiel stellt der Hörer einem lokalen Manager des Servicezentrums Diagnosedaten und Berichte nur für die Aktivität in einem einzelnen Servicezentrum dar. Der lokale Manager kann nähere Informationen über die spezifischen Diagnosen für bestimmte Fahrzeuge, die in dem Servicezentrum vorhanden sind, überprüfen. Für einen regionalen Manager stellt der Hörer gekürzte/zusammengefasste Berichte, die die Aktivitäten von mehreren Servicezentren zusammenfassen, dar. Die gekürzten Berichte umfassen aggregierte Statistiken über die gesamten Aktivitäten der Servicezentren und können detailliertere Service-Datensätze weglassen, sofern der regionale Manager die ausführlichen Daten von dem Diagnose-Analysesystem 104 nicht ausdrücklich anfordert.
• Einige Kunden implementieren optional einen proprietären Hörer, wie beispielsweise den Hörer 128. Der proprietäre Hörer umfasst jegliches Softwareprogramm, das die öffentliche API implementiert, um Diagnosedaten für die Kunden von dem Diagnose-Analysesystem 104 abzurufen, dass sich jedoch von dem Standard-Hörer unterscheidet. Proprietäre Hörer werden im Allgemeinen von einem Kunden implementiert zum Durchführen von zusätzlichen Analysen von Diagnosedaten, die die Funktionalität, die durch das Diagnose-Analysesystem 104 oder den Standard-Hörer 124 bereitgestellt wird, erweitert. Einige proprietäre Hörer werden als Plug-ins oder andere funktionelle Erweiterungen der Standard-Hörer-Anwendung 124 implementiert. In einer weiteren Ausführungsform umfasst der proprietäre Hörer ein weiteres Rechen-Cluster, das weitere Analysen der kundenspezifischen Diagnosedaten durchführt und die Ergebnisse der Analyse dem Kunden darstellt.
• Der Dritt-Hörer 132 ist ein Softwareprogramm, das einen Teil der Diagnosedaten von der Diagnosedatenbank 112 für einen oder mehrere Kunden empfängt und Berichte/Reports und weitere Analysen auf der Grundlage der Diagnosedaten darstellt. Wie oben beschrieben, wird dem Dritten die Erlaubnis erteilt, einen Teil der Diagnosedaten von einem oder mehreren Kunden, wie beispielsweise die Kunden 114 und 118, zu empfangen. Zum Beispiel, wenn der Dritte ein Automobilzulieferer ist, dann erteilen die Kunden, die Komponenten von dem Zulieferer kaufen, eine Erlaubnis für den Drittanbieter, um einen Teil der Diagnosedaten von der Diagnosedatenbank 112 zu empfangen. Andere Kunden, die den Drittanbieter nicht verwenden, können auswählen, um den Zugriff auf den Drittanbieter zu verweigern. Das Online-Diagnose-Analysesystem 104 implementiert Zugriffskontrolllisten (access control lists – ACLs) oder andere Zugangskontrolltechniken, die im Stand der Technik bekannt sind, um es dem Dritt-Hörer 132 zu ermöglichen, nur die Teile/Abschnitte von Diagnosedaten abzurufen, für welche dem Dritten die Erlaubnis erteilt worden ist. In einer Ausführungsform empfängt der Zulieferer redigierte Service-Datensätze, die eindeutige Kenndaten, wie beispielsweise VINs entfernen oder verändern, während detaillierte Informationen über die Diagnoseprozesse und Serviceaktivitäten, die jeder Kunde durchführt, erhalten bleiben. In einer weiteren Ausführungsform empfängt der Dritt-Hörer 132 zusammengefasste Daten von dem Diagnose-Analysesystem 104. In beiden Ausführungsformen erzeugt der Dritt-Hörer 132 eine Schnittstelle (Interface), die relevante Informationen an den Dritten im Zusammenhang mit den Fahrzeugserviceaktivitäten von einem oder mehreren Kunden bereitstellt.
• Zum Beispiel empfängt ein Drittanbieter, der Zündkerzen an einen Kunden verkauft, eine Zusammenfassung der Anzahl von Servicevorgängen, die wahrscheinlich den Ersatz von Zündkerzen umfassen. Der Dritt-Hörer 132 empfängt entweder die direkten Diagnosedaten oder zusammengefasste Diagnosedaten über eine Anzahl von Serviceverfahren, die typischerweise den Ersatz/Austausch von Zündkerzen umfassen, von dem Diagnose-Analysesystem 104. In einer Ausführungsform geben Diagnosefehlercodes, die Probleme bei der Verbrennung in einem oder mehreren Zylindern einer Brennkraftmaschine (Benzinmotor) anzeigen, die Notwendigkeit für neue Zündkerzen an. Wenn die Diagnosedaten ebenfalls Tests umfassen, die die Verbrennung der Brennkraftmaschine nach einem Servicevorgang bestätigen, dann verwendet das Diagnose-Analysesystem 104 oder der Dritt-Hörer 132 die Reihe von Diagnosedaten, um zu identifizieren, dass der Servicevorgang wahrscheinlich den Ersatz der Zündkerzen umfasste. Der Dritt-Hörer stellt Berichte des geschätzten Verbrauchs von Zündkerzen für mehrere Kunden dar. Der Drittanbieter verwendet dann die Informationen, um Aufträge/Bestellungen für Zündkerzen zu erhöhen oder zu verringern, oder um einen Zündkerzenbestand von Regionen mit einer geringeren Nachfrage in Regionen mit einer höheren Nachfrage zu versenden.
• In dem System empfangen die Diagnoseanfrage-Hörer 156 Hilfeersuchen von Diagnosegeräten oder anderen elektronischen Kommunikationsvorrichtungen, die einem Mechaniker zugeordnet sind, wie beispielsweise das Diagnosegerät 116C und die elektronische Kommunikationsvorrichtung 168, die dem Mechaniker 160 in 1 zugeordnet sind. In einigen Ausführungsformen ist der Diagnoseanfrage-Hörer 156 implementiert als ein proprietärer Hörer 128, der zusätzliche Services/Dienste auf der Grundlage der von den Diagnosegeräten empfangenen Diagnosedaten bereitstellt. Die Diagnoseanfrage-Hörer 156 empfangen Suchanfragen und Diagnosedaten, wie beispielsweise DTCs- und VIN-Informationen, von dem Diagnosegerät 116. In einigen Konfigurationen gibt der Mechaniker zusätzliche Suchbegriffe oder andere Informationen über das Fahrzeug ein, um bei der Diagnose eines Problems während einer Fahrzeugwartung zu unterstützen. Die Diagnoseanfrage-Hörer 156 rufen Wartungsinformationen von der Diagnosehistorie-Datenbank 112 auf der Grundlage von den DTC-Informationen von dem Diagnosegerät 116C ab. Die Diagnoseanfrage-Hörer 156 begrenzen auch die Suchen für Wartungsinformationen in der Diagnosehistorie-Datenbank 112 auf der Grundlage der Fahrzeugmarke, dem Modell und dem Baujahr, die die Diagnoseanfrage-Hörer 156 aus der von dem Diagnosegerät 116C übertragenen VIN identifizieren. Der Diagnoseanfrage-Hörer 156 überträgt Serviceverfahrensdaten einschließlich beispielsweise schriftliche grafische Serviceverfahrensanleitungen, Ersatzteilinformationen und andere relevante Wartungsinformationen an das Diagnosegerät 116C oder die elektronische Kommunikationsvorrichtung 168 zur Überprüfung durch den Mechaniker.
• In einigen Fällen ermöglichen es die Wartungsinformationen von der Diagnosehistorie-Datenbank 112 dem Mechaniker 160 nicht, das mechanische Problem zu lösen. Der Mechaniker 160 verwendet das Diagnosegerät 116C oder die elektronische Kommunikationsvorrichtung 168, um das Call-Center 140 für zusätzliche Unterstützung zu kontaktieren. In dem System 100 stellt der Diagnoseanfrage-Hörer 156 einen Kommunikationskanal zwischen dem Call-Center 140 und den Vorrichtungen 116C oder 168, die mit dem Mechaniker 160 verbunden sind, her. Der Diagnoseanfrage-Hörer 156 leitet Diagnosedaten, wie beispielsweise DTC-Daten, VIN-Informationen, Fahrzeughistorie-Daten und Informationen über früher Wartungsprozesse an das Call-Center 140 weiter. Das Call-Center 140 empfängt die Diagnosedaten und ein Terminal oder andere geeignete Datenanzeigevorrichtung stellt die Diagnosedaten einem Techniker in dem Call-Center 140 dar. Somit ermöglicht das System 100 dem Techniker in dem Call-Center, Diagnoseinformationen in Bezug auf das Fahrzeug zu überprüfen, ohne dass der Mechaniker 160 die Diagnoseinformationen manuell während eines Telefongesprächs oder einer anderen Kommunikationssitzung berichten muss.
• 2 zeigt einen Prozess 200 für den Betrieb des Systems 100 zum Erzeugen und Übertragen von Diagnosedaten von einem Diagnosegerät zu einem Wartungsanalysedienst während eines Servicevorganges. Der Prozess 200 wird zum Zwecke der Veranschaulichung in Verbindung mit dem System 100 von 1 beschrieben.
• Der Prozess 200 beginnt, wenn ein Mechaniker oder anderer Kfz-Servicetechniker ein Diagnosegerät mit der ECU in einem Fahrzeug verbindet (Block 204). Wie oben beschrieben, sind die Diagnosegeräte 116A–116C und 120A–120C eingerichtet, um sich über eine Schnittstelle mit einem CAN-Bus oder einer anderen Datennetzschnittstelle im Fahrzeug zu verbinden/koppeln, um Diagnosedaten von der ECU abzurufen. Das Diagnosegerät extrahiert fahrzeugspezifische Informationen (Block 208), um das Fahrzeug automatisch zu identifizieren. Zum Beispiel umfassen die ECUs in vielen Fahrzeugen einen Speicher, der die VIN für das Fahrzeug speichert, und das Diagnosegerät ruft die VIN unter Verwendung des OBD-II-Modus9-Protokolls oder eines anderen geeigneten Diagnoseprotokolls ab. In der Ausführungsform von 1 speichert das Diagnose-Analysesystem 104 Datenbanken von vorgegebenen VINs oder greift darauf zu, um die Marke, das Modell und das Baujahr für ein Fahrzeug aus der abgerufenen VIN zu identifizieren, wenn das Diagnosegerät die Marken-, Modell- und Baujahrinformationen nicht direkt abruft.
• Während des Prozesses 200 zeichnet das Diagnosegerät Fehlercodes, wie beispielsweise die Diagnosefehlercodes, Betriebszustandsinformationen und weitere Diagnosedaten aus der ECU in dem Fahrzeug auf (Block 212). Während eines Wartungsprozesses erfolgt der Abruf von Fehlercodes typischerweise während einer Anfangsdiagnose des Wartungsproblems oder nach einer Reparatur, um zu überprüfen, ob die Reparatur erfolgreich gewesen ist. Während des Verlaufs der Wartung führt das Diagnosegerät optional Tests durch oder sendet Befehle an die ECU, und das Diagnosegerät speichert einen Datensatz der Diagnosetests, Befehle für die Fahrzeug-ECU und einen Datensatz von Serviceverfahren und Komponenten, die in dem Fahrzeug als Teil der Serviceverfahren ersetzt werden, in dem Speicher (Block 216). Zum Beispiel ruft während eines Servicebesuchs das Diagnosegerät 116C Diagnosedaten zu mehreren Zeiten/Zeitpunkten ab und sendet mehrere Testbefehle an die ECU 166 in dem Fahrzeug. Der Mechaniker 160 führt ein oder mehrere Serviceverfahren/Servicevorgänge in Erwiderung auf ein Empfangen von DTCs und anderen Diagnosedaten von dem Diagnosegerät 116C durch. Das Diagnosegerät 116C empfängt ebenfalls einen Datensatz von Komponentenkennungen entsprechend den Komponenten, die der Mechaniker 160 in dem Fahrzeug während der Serviceverfahren ersetzt. Das Diagnosegerät zeichnet weiter die Diagnose- und Testdaten für mehrere Operationen während des Servicebesuchs auf. Die Liste der Komponentenkennungen umfasst zum Beispiel SKU-Nummern (Stock Keeping Unit – SKU), Seriennummern oder andere Komponentenidentifikationsdaten, die beliebigen Komponenten in dem Fahrzeug entsprechen, die während eines Serviceverfahrens ersetzt werden. Zum Beispiel überträgt das Diagnosegerät 116C eine einer Ersatzschalldämpferkomponente entsprechende SKU, wenn der Mechaniker 160 die Schalldämpferkomponente in Erwiderung auf die Diagnosedaten von dem Diagnosegerät 116C ersetzt, die ein Serviceverfahren für den Schalldämpfer angeben. In einigen Ausführungsformen umfasst das Diagnosegerät 116C oder die elektronische Kommunikationsvorrichtung 168 einen Barcode-Scanner oder einen Leser mit Funkerkennung (Radio Frequency Identifier – RFID), der die SKUs von Ersatzkomponenten abtastet/erfasst, um die Komponentenidentifikationsdaten während des Serviceverfahrens zu sammeln.
• Während des Prozesses 200 führt das Diagnosegerät einen Login durch, um auf das Diagnose-Analysesystem 104 zuzugreifen (Block 220). In einer Ausführungsform ist das Diagnosegerät eingerichtet, um mit einer vorgegebenen Login-Kennung, wie beispielsweise ein Hardware Globally Unique Identifier (GUID) für das Diagnosegerät, und einem Kennwort oder kryptographischen Schlüssel, der es dem Diagnosegerät ermöglicht, sich bei einem Konto (Account), das bei der entsprechenden Kundenorganisation registriert ist, sind automatisch anzumelden. In einigen Ausführungsformen stellt der Login-Prozess einen Kommunikationskanal zwischen dem Diagnosegerät und dem Diagnose-Analysesystem 104 her, um es dem Diagnosegerät zu ermöglichen, mehrere Diagnosedatensätze während der Sitzung zu übertragen. In einer weiteren Ausführungsform wird der Login-Prozess mit der Übertragung von jedem Diagnosedatensatz an den Wartungsanalysedienst verbunden. Jedes Diagnosegerät umfasst entweder die GUID oder eine andere Kennung, die verwendet wird, um Diagnosedatensätze in dem Diagnose-Analysesystem 104 mit einem bestimmten Diagnosegerät zu verbinden. Die jedem Diagnosegerät entsprechenden Service-Datensätze werden weiter mit dem Kunden, der das Diagnosegerät bedient, verbunden.
• Nachdem der Login-Prozess abgeschlossen ist, überträgt das Diagnosegerät Service-Datensätze einschließlich fahrzeugspezifischen Identifikationsdaten, Datensätzen von Service- und Reparaturverfahren und eine Liste von beliebigen Komponenten in dem Fahrzeug, die während des Serviceverfahrens ersetzt wurden, an das Diagnose-Analysesystem 104 (Block 224). Wie in 1 beschrieben, führt das Diagnosegerät eine Software aus, die die aufgezeichneten Daten von dem Fahrzeug in ein Datenformatformatiert, das mit der öffentlichen API für das Diagnose-Analysesystem 104 kompatibel ist. In einer Ausführungsform des Prozesses 200 führt das Diagnosegerät den Login durch und überträgt einen oder mehrere Datensätze nach Beendigung des Fahrzeugservices. In einer weiteren Ausführungsform erfolgt der Login vor oder während der Verbindung des Diagnosegeräts mit dem Fahrzeug, die oberhalb unter Bezugnahme auf die Verarbeitung von Block 204 beschrieben wird. Das Diagnosegerät überträgt dann die Service-Datensätze an das Diagnose-Analysesystem 104 mit einer minimalen Verzögerung in einem ”Live-”Betriebsmodus während der Diagnose- und Testprozesse, was es den Hörern ermöglicht, die Service-Datensätze von dem Diagnose-Analysesystem 104 während eines Servicevorganges abzurufen, um einen aktuellen Bericht der Aktivitäten, die das Diagnosegerät durchführt, bereitzustellen.
• Während des Prozesses 200 speichert das Diagnose-Analysesystem 104 die Daten, die von dem Diagnosegerät empfangen werden, in der Diagnose-Datenbank 112 (Block 228). Das Diagnose-Analysesystem 104 speichert die Service-Datensätze, Ersatzkomponentenkennungen und beliebige andere Daten, die von den Diagnosegeräten empfangen werden, in der Diagnosehistorie-Datenbank 112 in Verbindung mit der Kennung des Diagnosegeräts, einer Kennung für das Kundenkonto in der Kundendatenbank 108, der VIN oder einer anderen Kennung für das Fahrzeug, das mit dem Diagnosegerät verbunden ist, und einem Zeitstempel, wann das Diagnosegerät Daten empfängt oder einen Befehl an die ECU in dem Fahrzeug sendet. Während des Verlaufs der Fahrzeugwartung kann das Diagnosegerät mehrere Datensätze an das Diagnose-Analysesystem 104 senden, die in der Diagnose-Datenbank gespeichert sind.
• 3 zeigt einen Prozess 300 für einen Betrieb eines Kunden-Hörer, der Daten von einem Wartungsanalysedienst empfängt. Der Kunden-Hörer empfängt Zusammenfassungen von Diagnosedaten und Service-Datensätze von einer Mehrzahl von Diagnosegeräten während eines Services von mehreren Fahrzeugen und erzeugt Fahrzeughistorie-Zusammenfassungen entsprechend mehreren Serviceverfahren, die an einem einzelnen Fahrzeug durchgeführt werden. Der Prozess 300 wird zum Zwecke der Veranschaulichung unter Bezugnahme auf das System von 1 beschrieben.
• Während des Prozesses 300 empfängt das Diagnose-Analysesystem mehrere Sätze von Diagnosedaten und Service-Datensätzen von einer Mehrzahl von Diagnosegeräten, wie beispielsweise die Diagnosegeräte 116A–116C in dem System 100 (Block 304). Die Serviceinformationen umfassen sowohl die unmittelbaren Diagnose- und Testdaten, die die Diagnosegeräte an das Diagnose-Analysesystem 104 senden, als auch zusammengefasste Informationen und Berichte von dem Diagnose-Analysesystem 104. Die Kunden-Hörer 124 und 128 können auf die Service-Datensätze und zusammengefassten Daten von dem Diagnose-Analysesystem 104 zugreifen. In einer Konfiguration sind die Kunden-Hörer 124 und 128 bei dem Kunden 114 registriert und empfangen aktualisierte Serviceinformationen, die das Diagnose-Analysesystem 104 während des Betriebs der Diagnosegeräte 116A–116C, wie oben unter Bezugnahme auf Prozess 200 beschrieben, empfängt. Jeder Kunde verwendet einen oder mehrere Hörer, um die Serviceinformationen von dem Diagnose-Analysesystem 104 zu empfangen, und ein einzelner Kunde verwendet eine beliebige Kombination der Standard-Hörer (Default-Hörer) und ein oder mehrere proprietäre Hörer, die sich mit dem Diagnose-Analysesystem 104 über eine Schnittstelle koppeln/verbinden. Die mehreren Diagnosegeräte 116A–116C erzeugen mehrere Service-Datensätze, da die Diagnosegeräte Diagnosedaten abrufen und Service-Datensätze für mehrere Fahrzeuge empfangen. Die Diagnosegeräte 116A–116C übertragen die Diagnosedaten und Service-Datensätze an das Diagnose-Analysesystem 104. Zusätzlich rufen die Diagnosegeräte 116A–116C die VINs von verschiedenen Fahrzeugen ab und das Diagnose-Analysesystem 104 verfolgt mehrere Sätze von Diagnosedaten und Service-Datensätzen, die einem einzelnen Fahrzeug mit Bezug auf die VIN-Daten entsprechen. Zum Beispiel erzeugt das Diagnose-Analysesystem 104 eine Zusammenfassung der Fahrzeugservicehistorie, einschließlich einer Zusammenfassung von Diagnosedaten und Service-Datensätzen, für ein einzelnes Fahrzeug, das mit einem der Diagnosegeräte 116A–116C an zwei separaten Servicebesuchen verbunden ist.
• Das Diagnose-Analysesystem 104 verwendet in der Kundendatenbank 108 gespeicherte Authentifizierungsdaten, um die Hörer 124 und 128 unter Verwendung von zum Beispiel Passwörtern/Kennwörter oder kryptografischen Authentifizierungsschlüsseln zu authentifizieren, und das Diagnose-Analysesystem 104 überträgt nur Serviceinformationen von der Diagnosedatenbank 112, die mit dem Kunden 114 verbunden sind, an den Standard-Hörer 124 und den proprietären Hörer 128. Eine andere Gruppe von Hörern, die mit dem Kunden 118 verbunden sind, empfangen ähnliche Service-Daten entsprechend den Diagnosegeräten 120A–120C, und die Kunden 114 und 118 haben keinen direkten Zugriff auf die Daten der anderen.
• Während des Prozesses 300 erzeugen einer oder beide des Diagnose-Analysesystems 104 und des Standard-Hörers 124 zusammengefasste Daten und führen weitere Datenanalysen unter Verwendung der Serviceinformationen durch (Block 308). Zum Beispiel formatiert in einer Ausführungsform der Standard-Hörer 124 Diagnose-Datensätze mit einer kurzen, für Menschen lesbaren Zusammenfassung des Service-Datensatzes neu. Beispielsweise wird ein Service-Datensatz, der einen Fehlercode für einen Sauerstoffsensor umfasst, in einen String, der die Marke, das Modell und Baujahr des Fahrzeugs umfasst, eine für Menschen lesbare Erläuterung des Fehlercodes (z. B. ”O₂-Sensorfehler”) und eine Kennung für das jeweilige Diagnosegerät, das den Datensatz erzeugte, umformatiert. Das Diagnosegerät kann mit einem bestimmten Mitarbeiter oder einer Fahrzeugbucht in einem Servicezentrum in Verbindung gebracht werden. In einer weiteren Ausführungsform führt das Diagnose-Analysesystem 104 die Zusammenfassung durch oder analysiert mehrere Service-Datensätze von einem oder mehreren Diagnosegeräten, um eine Zusammenfassung der Aktivitäten in einem oder mehreren Servicezentren zu erzeugen. Zum Beispiel erzeugt in einer Ausführungsform das Diagnose-Analysesystem 104 Daten für einen KPI-Graphen oder eine andere Grafik, die die Gesamtzahl von verschiedenen Fahrzeugen, die mit den Diagnosegeräten in einem Servicezentrum über den Verlauf einer Arbeitsschicht verbunden gewesen sind, darstellt. Der Hörer 124 empfängt die zusammengefassten Berichtsdaten von dem Diagnose-Analysesystem 104.
• Während des Prozesses 300 erzeugt der Standard-Hörer 124 eine zusammengefasste Standard-Benutzerschnittstelle oder ein ”Dashboard”, die/das Managern, Servicepersonal und anderen Mitarbeitern des Kunden ermöglicht, die Serviceinformationen zu überprüfen (Block 312). In einer Ausführungsform umfasst die Dashboard-Schnittstelle die Service-Datensätze, die als für Menschen lesbarer Text formatiert sind. Das Dashboard zeigt eine Liste von Service-Datensätzen an und der Standard-Hörer aktualisiert die Liste, um die zuletzt empfangenen Service-Datensätze von den Diagnosegeräten anzuzeigen. Das Dashboard zeigt ebenfalls Graphen oder zusammengefasste Berichtsinformationen über die gesamte Aktivität für ein Diagnosegerät, mehrere Diagnosegeräte in einem Servicezentrum oder die aggregierten Aktivitäten von mehreren Servicezentren an.
• Während des Prozesses 300 empfängt der proprietäre Hörer 128 ebenfalls die Serviceinformationen von dem Diagnose-Analysesystem 104 (Block 316). Wie oben beschrieben, ist der proprietäre Hörer 128 eine Rechenvorrichtung, die die öffentliche API implementiert, um auf Diagnosedaten und andere Serviceinformationen zuzugreifen, die dem Kunden in dem Diagnose-Analysesystem 104 zugeordnet sind/in Verbindung stehen. Der proprietäre Hörer 128 führt dann zusätzliche Analaysen durch oder stellt die Servicedaten auf eine andere Weise als der Standard-Hörer 124 dar. In einer Ausführungsform ist der proprietäre Hörer 128 ein kundenspezifisches Softwareprogramm, das auf einer Rechenvorrichtung ausgeführt wird, oder der proprietäre Hörer 128 ist ein weiteres Server-Rechensystem, das Serviceinformationen für den Kunden speichert und zusätzliche Analysen in einem breiten Spektrum von Kunden-Serviceinformationen durchführt. Der proprietäre Hörer 128 steht unter Leitung eines Kunden, wie beispielsweise der Kunde 114, und der Kunde 114 kann den proprietären Hörer konfigurieren und modifizieren, um eine Analyse, die für den Kunden von Interesse ist, durchzuführen, aber erzeugt keine Berichte, die für eine große Anzahl von Kunden von allgemeinen Interesse sind, in der gleichen Weise wie der Standard-Hörer 124.
• 4 zeigt ein Verfahren für einen Dritt-Hörer, um auf die Serviceinformationen entsprechend einem oder mehreren Kunden in einem Wartungsanalysesystem zuzugreifen. Während des Prozesses 400 ruft ein Dritt-Hörer Serviceinformationen entsprechend einer der Arten von Serviceverfahren ab, die der Mechaniker 160 und andere Mechaniker unter Verwendung der Diagnosedaten und Daten des Serviceverfahrens von den Diagnosegeräten 116A–116C und 120A–120C durchführen. Die Dritt-Hörer empfangen ebenfalls Informationen über Komponenten, die während der Service- und Reparaturverfahren verwendet worden sind. Wie oben beschrieben, empfängt und überträgt das Diagnosegerät, wie beispielsweise das Diagnosegerät 116C, die Komponentendaten an die Diagnosehistorie-Datenbank 112 in dem Diagnose-Analysesystem 104. Der Prozess ermöglicht es Dritt-Hörern, aggregierte Datensätze in Bezug auf die Anzahl und Arten/Typen von Komponenten, die während der Serviceverfahren verwendet werden, in Verbindung mit aggregierten Datensätzen über die Marken, Modelle und Baujahre der Fahrzeuge, die die Teile erhalten, den Servicezentren, die die Servicevorgänge durchführen, und weitere aggregierte Berichtsdatensätze zu empfangen. 4 wird zum Zwecke der Veranschaulichung in Verbindung mit dem System 100 von 1 beschrieben.
• In der Ausführungsform von 4 umfasst der Prozess 400 die Erzeugung von anonymisierten Serviceinformationen entsprechend anonymisierten Service-Datensätzen, aggregierten Komponenten-Datensätzen und weiteren Analysedaten für die Kunden, die dem Dritt-Hörer zugänglich gemacht worden sind (Block 404). Zum Beispiel wird dem Dritt-Hörer 132 in einer Konfiguration Zugriff auf die Serviceinformationen und aggregierten Komponenten-Datensätze für den Kunden 118, aber nicht den Kunden 114 gewährt. Der Dritt-Hörer 132 empfängt optional Metadaten über die Serviceinformationen von den Kunden, wie beispielsweise Filialnummer-Kennungen oder geographische Koordinaten, die es dem Dritten ermöglichen, die Standorte von Servicezentren, wo die Kunden die Fahrzeuge warten, zu identifizieren und um Serviceinformationen mit verschiedenen Servicezentren in Verbindung zu bringen. Allerdings haben die Dritt-Hörer keinen direkten Zugriff auf die Diagnosedaten und andere Serviceinformationen in der gleichen Weise wie der Kunde 118. Stattdessen führt das Diagnose-Analysesystem 104 einen oder mehrere Anonymisierungsvorgänge an den Serviceinformationen durch, bevor der Dritt-Hörer 132 die Serviceinformationen empfängt. Zum Beispiel empfängt der Dritt-Hörer 132 in einigen Ausführungsformen lediglich aggregierte Informationen von dem Diagnose-Analysesystem 104. Das Diagnose-Analysesystem 104 identifiziert alle Serviceinformationen, die die Reparatur oder den Austausch/Ersatz der Schalldämpferkomponente während eines einwöchigen Zeitraumes für den Kunden betreffen. Der Dritt-Hörer empfängt dann nur die aggregierten Statistiken über die Reparatur des Schalldämpfers von dem Wartungssystem 104, wie beispielsweise die Gesamtzahl und den Typ der Schalldämpferkomponenten, die während des einwöchigen Zeitraumes ersetzt wurden. Die Beziehung zwischen dem Dritt-Hörer 132 und dem Kunden kann Einfluss auf die Richtlinien für die Art von Informationen, die ebenfalls offenbart werden, haben. Zum Beispiel, wenn der Dritt-Hörer 132 bei einer Firma, die Schalldämpferkomponenten nur für Fahrzeuge der Marken Honda, Nissan und Toyota verkauft, registriert ist, dann kann der Kunde 118 angeben, dass der Wartungsanalyseservice nur Serviceinformationen für eine Schalldämpfer-Aktivität für die oben genannten Marken und nicht für andere Fahrzeugmarken wiedergibt.
• In einer anderen Konfiguration für eine Datenanonymisierung wird dem Dritt-Hörer 132 Zugriff auf einige individuelle Service-Datensätze gewährt, aber das Diagnose-Analysesystem 104 entfernt VIN-Daten oder andere eindeutige Daten, die es dem Dritten ermöglichen, die Historie des Serviceverfahrens für ein einzelnes Fahrzeug zu identifizieren und zu verfolgen, um die Privatsphäre der Fahrer, die den Kunden für eine Wartung des Fahrzeugs nutzen, zu erhalten. Wenn der Zugriff Dritter die Identifikation eines einzelnen Fahrzeugs erfordert, um zum Beispiel eine Fahrzeughistorie-Zusammenfassung, die die Wirksamkeit von Serviceverfahren für ein einzelnes Fahrzeug über mehrere Servicebesuche verfolgt, zu erzeugen, dann wendet das Diagnose-Analysesystem 104 einen Pseudonymisierungsprozess bei den Serviceinformationen an. Der Pseudonymisierungsprozess erzeugt eine eindeutige Kennung für ein Fahrzeug über mehrere Diagnose- und Serviceinformations-Datensätze, aber die eindeutige Kennung enthält keinerlei aussagekräftige Information, die das Fahrzeug in der gleichen Weise wie eine VIN identifiziert. Somit wird die Kennung als eine pseudonyme Kennung bezeichnet, die eine ähnliche Funktion wie ein Pseudonym für einen Autor hat. Zum Beispiel erzeugt das Diagnose-Analysesystem 104 in einer Ausführungsform eine Tabelle oder andere geeignete Datenstruktur in der Kundendatenbank 108, die eine zufällig erzeugte Zahl jeder eindeutigen VIN zuweist, die aus den Diagnosedaten, die die Diagnosegeräte für die Kunden an das Diagnose-Analysesystem 104 senden, gesammelt wird. Das Diagnose-Analysesystem 104 verwendet dann die gleiche Zufallszahl in mehreren Datensätzen als eine pseudonyme Kennung für das Fahrzeug in den Serviceinformationen, die an den Dritt-Hörer 132 gesendet werden.
• Der Prozess 400 wird fortgesetzt, wenn der Dritt-Hörer 132 die anonymisierten Serviceinformationen und aggregierten Komponenten-Datensätze empfängt (Block 408). In einer Ausführungsform empfängt der Dritt-Hörer 132 die Serviceinformationsdaten von dem Diagnose-Analysesystem 104 unter Verwendung des gleichen Pub-Sub-Aktualisierungssystems, obwohl die Dritt-Hörer eine unterschiedliche API zum Abrufen der Serviceinformationen als die öffentliche API für die Diagnosegeräte und Kunden-Hörer verwenden. In einer weiteren Ausführungsform fordert der Dritt-Hörer Stapel (Batches) der Serviceinformationen in regelmäßigen Abständen, wie auf einer stündlichen, täglichen, wöchentlichen oder monatlichen Basis, an. Die Serviceinformationen umfassen aggregierte Daten, die die Arten von Servicevorgängen, die an mehreren Fahrzeugen durchgeführt werden, betreffen, aggregierte Informationen über die Fahrzeuge einschließlich Daten der Marke, des Modells und Baujahres für die Fahrzeuge, die das Diagnose-Analysesystem 104 von den VINs von den Fahrzeugen extrahiert, und aggregierte Informationen über DTCs, die das Diagnose-Analysesystem 104 von den Diagnosegeräten 116A–116C und 120A–120C empfängt. In ähnlicher Weise empfangen die Dritt-Hörer 132 aggregierte Informationen über die Anzahl von bestimmten Komponententypen, die in den Fahrzeugen über unterschiedliche Zeitintervalle eingebaut worden sind. In einigen Ausführungsformen hat ein Dritt-Hörer 132, der mit einem Komponentenhersteller in Verbindung steht, nur auf die den Komponenten, die der Hersteller produziert, entsprechenden Komponenteninformationen Zugriff. Zum Beispiel empfängt ein Dritt-Hörer 132 für einen Hersteller A aggregierte Komponenten-Datensätze für einen Bremsbelag SKU A, den Hersteller A produziert, während Hersteller A aggregierte Komponenten-Datensätze für einen anderen Bremsbelag SKU B von einem unterschiedlichen Hersteller nicht empfängt.
• Der Prozess 400 wird weitergeführt, wenn der Dritt-Hörer 132 die anonymisierten Serviceinformationen analysiert, um Änderungen oder Trends in den Services, die der Kunde an den Fahrzeugen durchführt, zu identifizieren, um eine Zunahme oder Abnahme der Nachfrage nach Ersatzteilen oder andere Materialien, die der Dritte an die Kunden zuliefert, zu identifizieren (Block 412). Zum Beispiel analysiert der Dritt-Hörer die Serviceinformationen, um Servicetests und Vorgänge/Operationen zu identifizieren, die einen Austausch der Fahrzeugbatterie erfordern. In einer Situation zeigen die Trends eine gleichmäßige Zunahme oder Abnahme der Nachfrage für die Batterien über alle Kunden. In einer anderen Situation zeigen die Trends eine Zunahme der Auswechslungen der Fahrzeugbatterie für Kundenservicezentren in einer bestimmten geografischen Region, während die Rate der Auswechslungen in einer anderen geografischen Region gleich bleibt oder abnimmt. In einer anderen Situation zeigen die Trenddaten eine Zunahme oder Abnahme der Komponentennachfrage nur für einen Kunden oder nur für ein Servicecenter.
• Während des Prozesses 400 identifiziert der Dritt-Hörer 132 die Komponenten, die Gegenstand der zunehmenden oder abnehmenden Trends in der Nachfrage sind, und erzeugt eine Ausgabe mit den identifizierten Komponenten und den identifizierten Trends (Block 416). Zum Beispiel erzeugt der Dritt-Hörer 132 in einer Ausführungsform eine Anzeige einer Karte mit einer Überlagerung (Overlay) von mehreren Servicezentren und grafischen oder numerischen Symbolen, die die Änderungen der Nachfrage für eine ausgewählte Komponente angeben. Die grafischen Symbole ermöglichen eine effiziente Analyse der Trends in der Nachfrage für die Komponenten über mehrere Kunden. In einer weiteren Ausführungsform ist der Dritt-Hörer 132 ferner mit einem Lagerverwaltungssystem für den Drittanbieter verbunden. Der Dritt-Hörer 132 erzeugt eine Ausgabe, die die identifizierten Trends in der Komponentennachfrage darstellt, und stellt eine Empfehlung zum Einstellen/Anpassen des Gesamtlagerbestandes oder der Verteilung des Bestandes dar, um die Änderungen in der Nachfrage anzupassen. Zum Beispiel, wenn ein Trend angibt, dass der Osten der USA eine Zunahme in der Nachfrage für Batterien erfährt, während der Westen der USA eine Abnahme in der Nachfrage erfährt, dann kann der Dritt-Hörer eine Lieferung des Batteriebestandes in den Westen der USA empfehlen, um der erhöhten Nachfrage für Batterien von den Kunden zu begegnen.
• 5 zeigt einen Prozess 500 für den Betrieb des Systems 100, um es dem Mechaniker 160 zu ermöglichen, Empfehlungen für Reparaturen abzurufen und, bei Bedarf, das Call-Center 140 zu kontaktieren, um Unterstützung beim Beheben des Problems zu erhalten. In der folgenden Diskussion bezieht sich ein Verweis/Bezug auf den eine Funktion oder Aktion durchführenden Prozess 500 auf die Ausführung von gespeicherten Programmbefehlen durch einen Prozessor, um die Funktion oder Aktion durchzuführen. Der Prozess 500 wird zum Zwecke der Veranschaulichung unter Bezugnahme auf das System 100 von 1 beschrieben.
• Der Prozess 500 beginnt, wenn der Mechaniker 160 oder ein anderer Kfz-Servicetechniker ein Diagnosegerät mit der ECU in einem Fahrzeug verbindet (Block 504). Wie oben beschrieben, ist das Diagnosegerät 116C eingerichtet, um sich über eine Schnittstelle mit einem CAN-Bus oder einer andren Datennetz-Schnittstelle im Fahrzeug zu koppeln/verbinden, um Diagnosedaten von der ECU 166 abzurufen. Sobald die Verbindung mit der ECU 166 steht, empfängt das Diagnosegerät 116C Diagnosedaten und empfängt optional die VIN oder weitere Fahrzeuginformationsdaten von der ECU (Block 508). Die Diagnosedaten umfassen, sind aber nicht notwendigerweise darauf beschränkt, DTC-Daten, aufgezeichnete Sensorhistoriendaten und aktuelle Daten von Sensoren in dem Fahrzeug, die in einem OBD-II-kompatiblen Format übertragen werden. In einer Ausführungsform empfängt das Diagnosegerät 116C die VIN oder anderen Fahrzeugidentifizierungsdaten von der ECU 166 zusätzlich zu einem Empfangen unter Verwendung von zum Beispiel dem OBD-II-Modus9-Protokoll. In einer weiteren Ausführungsform gibt der Mechaniker 160 die VIN oder andere Identifizierungsinformationen für das Fahrzeug von Hand oder durch einen Barcode-Scanner ein, um die VIN an das Diagnosegerät 116C bereitzustellen.
• Während des Prozesses 500 gibt der Mechaniker 160 eine Anfrage unter Verwendung des Diagnosegeräts 116C für eine Diagnose und Serviceempfehlungen auf der Grundlage der DTCs und weiterer Diagnosedaten ein, die von der ECU empfangen worden sind (Block 512). Die Diagnoseanfrage umfasst sowohl die Diagnosedaten als auch die VIN für das Fahrzeug. Das Diagnosegerät 116C erzeugt die Diagnoseanfrage mit den Diagnosedaten und der VIN in einer automatisierten Weise. Der Mechaniker 160 gibt optional zusätzliche Bedingungen/Begriffe für die Diagnoseanfrage unter Verwendung einer Touchscreen-Schnittstelle oder einer anderen Eingabevorrichtung, die mit dem Diagnosegerät 116C in Verbindung steht, ein. In einem Beispiel erzeugt das Diagnosegerät 116C eine Diagnoseanfrage einschließlich zwei DTCs, die von der ECU 166 empfangen werden, der VIN für das Fahrzeug und einem von Hand eingegebenen Suchbegriff für ”Schleifgeräusche”, um die Diagnosedaten mit Beobachtungen von dem Mechaniker 160 über das Fahrzeug zu ergänzen, um bei der Diagnose des Problems zu unterstützen.
• Das Diagnose-Analysesystem 104 empfängt die Diagnoseanfrage von dem Diagnosegerät 116C und erzeugt Abfrageergebnisse aus den Diagnoseinformationen in der Diagnosehistorie-Datenbank 112 (Block 516). In einer Ausführungsform fragt das Diagnose-Analysesystem 104 zuerst die Diagnosehistorie-Datenbank 112 ab, um zu identifizieren, ob die Kombination der DTCs und anderer Diagnosedaten, die in der Diagnoseanfrage dargestellt sind, einem oder mehreren Service-Datensätzen in der Datenbank 112 entsprechen, die zuvor aufgezeichneten Lösungen für ein Problem des Fahrzeugs entsprechen, die den gleichen Diagnosedaten entsprechen. Das Diagnose-Analysesystem 104 verfeinert ebenfalls die Suche unter Verwendung der VIN oder anderer Fahrzeugidentifikationsdaten in der Diagnoseanfrage. Das Diagnose-Analysesystem 104 verwendet die VIN, um die Marke, das Modell und das Baujahr des Fahrzeugs mit bestehenden Datensätzen in Verbindung zu bringen, um die Datensätze für ähnliche Fahrzeuge mit der größten Wahrscheinlichkeit der Relevanz für den Mechaniker 160 zu identifizieren. Wenn die DTC-Daten einem oder mehreren Datensätzen entsprechen, aber die Diagnosehistorie-Datenbank 112 die DTC-Daten nicht mit der bestimmten VIN des Fahrzeugs in Verbindung bringt, dann gibt das Diagnose-Analysesystem 104 Ergebnisse für die Service-Datensätze, die den DTCs entsprechen, mit einer Anzeige (Indikator), die die unterschiedliche Marke, Modell oder Baujahr der Fahrzeuge identifiziert, die die Service-Datensätze betreffen, wieder.
• In einer Ausführungsform implementiert das Diagnose-Analysesystem 104 einen Web-Server und die Ergebnisse von der Diagnoseanfrage werden als eine oder mehrere Webseiten für eine Anzeige durch das Diagnosegerät 116C oder eine andere beliebige Rechenvorrichtung, die einen Web-Browser umfasst, dargestellt. Wenn die Ergebnisse der Suchanfrage zu mehreren relevanten Ergebnissen führen, erzeugt das Diagnose-Analysesystem 104 Ergebnisse einschließlich kurzer zusammengefasster Informationen oder anderer Steuerelemente/Kontrollelemente, um es dem Mechaniker 160 zu ermöglichen, mehrere Ergebnisse unter Verwendung eines Web-Browsers oder einer anderen geeigneten Anzeigesoftware mit dem Diagnosegerät 116C zu überprüfen.
• Während des Prozesses 500 überprüft der Mechaniker 160 die Ergebnisse von der Suche und bestimmt, ob einer der Service-Datensätze eine Lösung für das Problem der Fahrzeugreparatur beschreibt. In dem System 100 implementiert das Diagnosegerät 116C einen Web-Browser oder eine andere Software, die es dem Mechaniker 160 ermöglicht, die Service-Datensätze zu überprüfen. In einer weiteren Ausführungsform verwendet der Mechaniker 160 die mobile Vorrichtung 168 oder eine andere Rechenvorrichtung (Computergerät), um die Ergebnisse zu überprüfen.
• In vielen Fällen umfassen die Ergebnisse von dem Diagnose-Analysesystem 104 eine geeignete Lösung für den Mechaniker, um das Problem mit dem Fahrzeug zu beheben (Block 520). Der Mechaniker 160 gibt dann ein Feedback unter Verwendung des Diagnosegeräts 116C oder der mobilen Vorrichtung 168 ein, um die Diagnosehistorie-Datenbank 112 zu aktualisieren (Block 524). Da viele Kfz-Reparaturen Stunden oder sogar Tage zum Fertigstellen in Anspruch nehmen können, ist das Diagnose-Analysesystem 104 eingerichtet, um das Feedback zu empfangen, nachdem der Mechaniker 160 eine Gelegenheit gehabt hat, ein empfohlenes Verfahren durchzuführen und die Wirksamkeit des Verfahrens zu überprüfen. Zum Beispiel stellt das Diagnosegerät 116C in einer Ausführungsform dem Mechaniker 160 ein Feedback-Menü nach einer Timeout-Zeit dar. Der Timeout ist eine vorgegebene Zeitdauer (z. B. 24 Stunden) oder ein Timeout, der auf einer erwarteten Zeitdauer basiert, um die Reparatur auf der Grundlage einer Zeitschätzung durchzuführen, die zu den Service-Datensätzen gehört. Zum Beispiel stellt das Diagnosegerät 116C das Feedback-Interface für einen Service-Datensatz mit einer Empfehlung für eine Arbeit mit einer geschätzten Fertigstellungzeit von 8 Stunden dar, nachdem die geschätzte Zeit abgelaufen ist.
• Das Diagnose-Analysesystem 104 verwendet das vereinfachte Feedback, um ein Relevanz-Ranking des Service-Datensatzes, der dem Feedback entspricht, anzupassen. Zum Beispiel, wenn ein oder mehrere Mechaniker einen Service-Datensatz mit einem vorgeschlagenen Verfahren für einen bestimmten Satz von DTCs überprüfen, gibt ein positives Feedback an, dass der Service-Datensatz beim Beheben des Problems mit dem Fahrzeug nützlich war. Das positive Feedback erhöht die Wahrscheinlichkeit, dass das Diagnose-Analysesystem 104 den Service-Datensatz in Erwiderung auf zusätzliche Abfragen, die die DTCs oder eine andere Diagnose und dem Service-Datensatz entsprechenden Fahrzeugidentifikationsdaten angeben, wiedergibt. Beim Wiedergeben mehrerer Service-Datensätze in Erwiderung auf eine Diagnoseanfrage, führt das Diagnose-Analysesystem 104 ein Ranking der Service-Datensätze auf der Grundlage des Feedbacks durch. Das Diagnose-Analysesystem 104 gibt die Ergebnisse auf die Anfragen der Mechaniker auf der Grundlage des Rankings wieder, um dem Mechaniker die Service-Datensätze mit hohen Rankings zuerst darzustellen. Ein negatives Feedback verringert das Ranking eines Service-Datensatzes. In einer Konfiguration, wenn ein Service-Datensatz eine vorgegebene Anzahl von negativen Feedbackergebnissen erhält, während er gleichzeitig keine oder wenige positive Feedbackergebnisse erhält, dann lässt das Diagnose-Analysesystem 104 den Service-Datensatz von den Ergebnissen der Diagnoseanfrage weg.
• In dem System 100 umfasst das Feedback-Interface sowohl vereinfachte als auch detaillierte Eingabesteuerungen für den Mechaniker 160. Zum Beispiel umfasst ein vereinfachtes Feedback-Interface eine Zusammenfassung des Fahrzeugs und DTC-Informationen und die empfohlene Diagnose, um den Mechaniker 160 an einen Service-Datensatz zu erinnern, der zuvor für ein Fahrzeug abgerufen wurde. Das vereinfachte Feedback-Interface stellt ebenfalls eine Ja-/Nein- oder eine Mehrfachauswahl-Frage für den Mechaniker 160 dar, um ein Feedback darüber entlocken, ob der Service-Datensatz beim Beheben des Problems nützlich war. Das vereinfachte Feedback-Interface empfängt die Feedback-Eingabe in einer standardisierten Weise, die eine minimale Zeit für den Mechaniker 160 erfordert. Das Feedback-Interface stellt auch eine detaillierte/ausführliche Eingabeschnittstelle dar. Die detaillierte Eingabeschnittstelle ist zum Beispiel eine Form, die detailliertere Fragen über den Reparaturvorgang (z. B. die Zeit, die für die Reparatur benötigt wird, in der Reparatur verwendete Komponenten, für die Reparatur verwendete Werkzeuge usw.) und eine Texteingabe, um es dem Mechaniker 160 zu ermöglichen, eine Erläuterung des Problems und des Reparaturverfahrens einzugeben, umfassen. Das ausführliche Feedback ist nützlich, wenn der Mechaniker 160 Service-Datensätze empfängt, die den Mechaniker 160 beim Feststellen und Beheben des Problems unterstützen, und wo der der Mechaniker 160 zusätzliche Details zu bestehenden Service-Datensätzen, die in der Diagnosehistorie-Datenbank 112 gespeichert sind, hinzufügen möchte.
• In einigen Fällen ist der Mechaniker 160 nicht in der Lage, das Reparaturproblem mit dem Fahrzeug unter Verwendung der Service-Datensätze, die das Diagnose-Analysesystem 104 in Erwiderung auf die Diagnoseanfrage von dem Diagnosegerät 116C wiedergibt, zu beheben (Block 520). In einer Situation, in der das Diagnose-Analysesystem 104 keinen relevanten Service-Datensatz identifiziert oder in der der Mechaniker 160 keinen Service-Datensatz empfängt, der das Problem behebt, verwendet der Mechaniker 160 das Diagnosegerät 116C oder die mobile Vorrichtung 128, um manuelle Hilfe für der Diagnoseanfrage entsprechende Informationen anzufordern. In dem Diagnose-Analysesystem 104 überträgt der Diagnoseanfrage-Hörer 156 die Diagnoseanfrageinformationen an einen Operator in dem Call-Center 140 und überträgt Adressdaten an das Diagnosegerät 16C oder die mobile Vorrichtung 128, die dem Mechaniker 160 zugeordnet sind, um einen Kommunikationskanal zwischen dem Mechaniker 160 und einem Techniker in dem Call-Center 140 herzustellen (Block 528). Wie oben beschrieben, stellen die Diagnoseanfrage-Hörer 156 einen Kommunikationskanal zwischen dem Mechaniker 160 und dem Call-Center 140 her. In einer Ausführungsform übertragen die Diagnoseanfrage-Hörer 156 Kommunikationsadressdaten an die mobile Vorrichtung 168 oder das Diagnosegerät 116C. Die Adressdaten umfassen zum Beispiel eine Telefonnummer oder einen Uniform Resource Locator (URL), der es dem Mechaniker 160 ermöglicht, einen Kommunikationskanal mit einem menschlichen Operator in dem Call-Center 140 herzustellen. Die mobile Vorrichtung 168 und das Diagnosegerät 116C verwenden die Adressdaten, um den Kommunikationskanal durch das Netzwerk 150 herzustellen. Beispiele von Kommunikationskanälen umfassen Telefonate, oder Text-, Audio- und Video-Chat-Sitzungen. In dem Beispiel von 1 verwendet der Mechaniker 160 das Diagnosegerät 116C oder die mobile Vorrichtung 168, um mit einem menschlichen Operator in dem Call-Center 140 zu kommunizieren. Der menschliche Operator in dem Call-Center empfängt die Diagnosedaten von dem Diagnosegerät 116C automatisch, um den menschlichen Operator beim Verstehen und beim Bereitstellen von Unterstützung für den Mechaniker 160 zu unterstützen.
• Während des Prozesses 500 empfängt das Diagnose-Analysesystem 104 eine Eingabe von dem Mechaniker 160 oder von einem Operator in dem Call-Center 140, um einen neuen Service-Datensatz der Lösung auf das Problem, das in der Diagnosehistorie-Datenbank 112 gespeichert ist, zu erzeugen (Block 532). Das Diagnose-Analysesystem 104 umfasst automatisch die VIN und den DTC und weitere Diagnosedaten von dem Diagnosegerät 116C in dem Service-Datensatz. Die VIN- und DTC-Daten ermöglichen es dem Diagnose-Analysesystem 104, den Service-Datensatz in der Zukunft abzurufen, wenn ein anderer Mechaniker ähnliche DTC-Daten empfängt und zusätzliche Informationen zum Feststellen eines Problems mit dem Fahrzeug benötigt. Der Service-Datensatz umfasst ebenfalls Text oder andere/weitere Daten, die der Mechaniker 160 von Hand zum Beschreiben des Problems und der Verfahren zum Beheben des Problems eingibt. Neben einer Textbeschreibung können die Daten in dem Service-Datensatz Komponentennummern für beliebige erforderliche Ersatzkomponenten, und Bilder oder Videos, die bei der Erläuterung des Problems und des Verfahrens zum Beheben des Problems unterstützen, umfassen. Nach Durchführen der Reparatur stellt der Mechaniker 160 ebenfalls eine Schätzung der zum Durchführen der Reparatur erforderlichen Zeitdauer bereit, was andere Mechaniker beim Schätzen der Reparaturkosten für das Problem unterstützt.
• Das Diagnose-Analysesystem 104 speichert den Service-Datensatz in der Diagnosehistorie-Datenbank 112 in Verbindung mit den Benutzerkonten für den Mechaniker 160 und optional einem Konto eines Operators in dem Call-Center 140, der beim Beheben des Problems unterstützt. Der Service-Datensatz bietet eine mögliche Lösung für das Problem für andere Mechaniker, die Diagnosegeräte oder mobile Vorrichtungen, die den Service-Datensatz von dem Diagnose-Analysesystem 104 abrufen, bedienen.
• Es wird darauf hingewiesen, dass Varianten des oben beschriebenen und andere/weitere Merkmale und Funktionen, oder Alternativen derselben in wünschenswerter Weise in vielen anderen verschiedenen Systemen, Anwendungen/Applikationen oder Verfahren kombiniert werden können. Verschiedene derzeit unvorhergesehene oder unerwartete Alternativen, Modifikationen, Variationen oder Verbesserungen können anschließend von einem Fachmann auf dem Gebiet vorgenommen werden, die ebenfalls durch die folgenden Ansprüche umfasst sein sollen.

Claims (15)

1. Verfahren zum Überwachen einer Komponentenverwendung während Fahrzeugserviceaktivitäten, aufweisend: Empfangen mit einem Diagnosegerät von Diagnosedaten von einem Fahrzeug; Empfangen mit dem Diagnosegerät einer Komponentenkennung entsprechend einer Komponente in dem Fahrzeug, die in einem Servicevorgang in Erwiderung auf die Diagnosedaten von dem Diagnosegerät ersetzt wird; Übertragen mit dem Diagnosegerät der Diagnosedaten und der Komponentenkennung an einen Server; und Übertragen mit dem Server der Komponentenkennung an ein Hörer-Computergerät, das einem Hersteller der Komponente zugeordnet ist.
2. Verfahren nach Anspruch 1, ferner aufweisend: Empfangen mit dem Diagnosegerät einer Fahrgestellnummer (vehicle identification number – VIN) von einer elektronischen Steuereinheit in dem Fahrzeug; Übertragen mit dem Diagnosegerät der VIN an den Server; Identifizieren mit dem Server von zumindest einem aus einer Marke, einem Modell und einem Baujahr des Fahrzeugs mit Bezug auf die VIN; und Übertragen mit dem Server des zumindest einen aus einer Marke, einem Modell und einem Baujahr des Fahrzeugs an das Hörer-Computergerät in Verbindung mit der Komponentenkennung ohne Übertragen der VIN an das Hörer-Computergerät.
3. Verfahren nach Anspruch 1, ferner aufweisend: Empfangen mit dem Diagnosegerät eines Diagnose-Fehlercodes (Diagnostic Trouble Code – DTC) von einer elektronischen Steuereinheit in dem Fahrzeug; Übertragen mit dem Diagnosegerät des DTC an den Server; und Übertragen mit dem Server des DTC an das Hörer-Computergerät in Verbindung mit der Komponentenkennung.
4. Verfahren nach Anspruch 1, ferner aufweisend: Empfangen mit dem Server einer Mehrzahl von Komponentenkennungen von einer Mehrzahl von Diagnosegeräten entsprechend einer Mehrzahl von Komponenten in einer Mehrzahl von Fahrzeugen, die in einer Mehrzahl von Servicevorgängen ersetzt werden; und Erzeugen mit dem Server eines aggregierten Datensatzes der Mehrzahl von Komponentenkennungen; und Übertragen mit dem Server des aggregierten Datensatzes an das Hörer-Computergerät.
5. Verfahren nach Anspruch 4, ferner aufweisend: Empfangen mit dem Server einer Mehrzahl von Fahrgestellnummern (vehicle identification numbers – VINs) von einer Mehrzahl von Diagnosegeräten entsprechend der Mehrzahl von Fahrzeugen; Erzeugen mit dem Server eines aggregierten Datensatzes entsprechend einer Mehrzahl von Marken, Modellen und Baujahren der Mehrzahl von Fahrzeugen mit Bezug auf die Mehrzahl von VINs; und Übertragen mit dem Server des aggregierten Datensatzes der Mehrzahl von Marken, Modellen und Baujahren der Mehrzahl von Fahrzeugen an das Hörer-Computergerät in Verbindung mit dem aggregierten Datensatz der Mehrzahl von Komponentenkennungen.
6. Verfahren nach Anspruch 4, ferner aufweisend: Empfangen mit dem Server einer Mehrzahl von Diagnose-Fehlercodes (diagnostic trouble codes – DTCs) von der Mehrzahl von Diagnosegeräten für die Mehrzahl von Fahrzeugen; und Übertragen mit dem Server der Mehrzahl von DTCs an das Hörer-Computergerät im aggregierten Datensatz der Mehrzahl von Komponentenkennungen.
7. Verfahren zum Überwachen einer Fahrzeugserviceaktivität, aufweisend: Empfangen mit einer Mehrzahl von Diagnosegeräten einer Mehrzahl von Diagnosedaten von einer Mehrzahl von Fahrzeugen; Übertragen mit der Mehrzahl von Diagnosegeräten der Mehrzahl von Diagnosedaten und einer Mehrzahl von Service-Datensätzen entsprechend einer Mehrzahl von Servicevorgängen, die an der Mehrzahl von Fahrzeugen in Erwiderung auf die Mehrzahl von Diagnosedaten von der Mehrzahl von Fahrzeugen durchgeführt werden, an einen Server; Erzeugen mit dem Server einer Zusammenfassung der Mehrzahl von Servicevorgängen mit Bezug auf die Mehrzahl von Service-Datensätzen und die Mehrzahl von Diagnosedaten von der Mehrzahl von Diagnosegeräten; und Übertragen mit dem Server der Zusammenfassung an ein Hörer-Computergerät, das einem Servicezentrum, das die ersten und zweiten Servicevorgänge an dem Fahrzeug durchführt, zugeordnet ist.
8. Verfahren nach Anspruch 7, ferner aufweisend: Empfangen mit einem Diagnosegerät in der Mehrzahl von Diagnosegeräten von ersten Diagnosedaten von einem Fahrzeug in der Mehrzahl von Fahrzeugen; Übertragen mit dem einen Diagnosegerät der ersten Diagnosedaten und eines ersten Service-Datensatzes entsprechend einem ersten Servicevorgang, der an dem einen Fahrzeug in Erwiderung auf die ersten Diagnosedaten von dem einen Fahrzeug durchgeführt wird, an den Server; Empfangen mit dem einen Diagnosegerät von zweiten Diagnosedaten von dem Fahrzeug; Übertragen mit dem einen Diagnosegerät der zweiten Diagnosedaten und eines zweiten Service-Datensatzes entsprechend einem zweiten Servicevorgang, der an dem einen Fahrzeug in Erwiderung auf die zweiten Diagnosedaten von dem einen Fahrzeug durchgeführt wird, an den Server; Erzeugen mit dem Server einer Fahrzeughistorie-Zusammenfassung mit Bezug auf den ersten Service-Datensatz, dem zweiten Service-Datensatz, den ersten Diagnosedaten und den zweiten Diagnosedaten; und Übertragen mit dem Server der anderen Zusammenfassung an das Hörer-Computergerät.
9. Verfahren nach Anspruch 8, ferner aufweisend: Empfangen mit dem einen Diagnosegerät einer Fahrgestellnummer (vehicle identifiaction number – VIN) von dem einen Fahrzeug; Übertragen mit dem einen Diagnosegerät der VIN mit den ersten Diagnosedaten und einem ersten Service-Datensatz an den Server; Übertragen mit dem einen Diagnosegerät der VIN mit den zweiten Diagnosedaten und einem zweiten Service-Datensatz an den Server; und Erzeugen mit dem Server der Fahrzeughistorie-Zusammenfassung mit Bezug auf die VIN, um den ersten Service-Datensatz, den zweiten Service-Datensatz, die ersten Diagnosedaten und die zweiten Diagnosedaten dem einen Fahrzeug zuzuordnen.
10. Verfahren nach Anspruch 9, ferner aufweisend: Identifizieren mit dem Server von zumindest einem aus einer Marke, einem Modell und einem Baujahr des Fahrzeugs mit Bezug auf die VIN; und Erzeugen mit dem Server der Fahrzeughistorie-Zusammenfassung einschließlich des zumindest einen aus einer Marke, einem Modell und einem Baujahr des Fahrzeugs.
11. Verfahren nach Anspruch 7, ferner aufweisend: Empfangen mit der Mehrzahl von Diagnosegeräten einer Mehrzahl von Fahrgestellummern (vehicle identification numbers – VINs, wobei jede VIN in der Mehrzahl von VINs einem Fahrzeug in der Mehrzahl von Fahrzeugen entspricht; Übertragen mit der Mehrzahl von Diagnosegeräten der Mehrzahl von VINs an den Server; Identifizieren mit dem Server von zumindest einem aus einer Marke, einem Modell und einem Baujahr von jedem Fahrzeug in der Mehrzahl von Fahrzeugen mit Bezug auf die Mehrzahl von VINs; und Erzeugen mit dem Server der Zusammenfassung der Mehrzahl von Servicevorgängen einschließlich des zumindest einen aus einer Marke, einem Model und einem Baujahr von jedem Fahrzeug in der Mehrzahl von Fahrzeugen.
12. Verfahren nach Anspruch 7, ferner aufweisend: Empfangen mit einem Diagnosegerät in der Mehrzahl von Diagnosegeräten von ersten Diagnosedaten von einem Fahrzeug in der Mehrzahl von Fahrzeugen; Übertragen mit dem einen Diagnosegerät der ersten Diagnosedaten und einer Diagnoseanfrage an den Server; Identifizieren mit dem Server eines in einer Diagnosehistorie-Datenbank aufgezeichneten Service-Datensatzes entsprechend den Diagnosedaten und der Diagnoseanfrage; Übertragen mit dem Server des Service-Datensatzes an das eine Diagnosegerät; und Erzeugen mit dem Diagnosegerät einer Ausgabe des Service-Datensatzes zum Unterstützen eines Benutzers beim Durchführen eines Servicevorganges für das eine Fahrzeug.
13. Verfahren nach Anspruch 12, ferner aufweisend: Empfangen mit dem einen Diagnosegerät einer Fahrgestellnummer (vehicle identifiaction number – VIN) von einer elektronischen Steuereinheit in dem einen Fahrzeug; Übertragen mit dem einen Diagnosegerät der VIN an den Server; Identifizieren mit dem Server von zumindest einem aus einer Marke, einem Modell und einem Baujahr des Fahrzeugs mit Bezug auf die VIN; und Identifizieren mit dem Server des Service-Datensatzes, der in der Diagnosehistorie-Datenbank gespeichert wird entsprechend einem Servicevorgang, der an einem anderen Fahrzeug mit zumindest einem aus der Marke, dem Modell und dem Baujahr des einen Fahrzeugs durchgeführt wird.
14. Verfahren nach Anspruch 12, ferner aufweisend: Übertragen mit dem Server der ersten Diagnosedaten und der Diagnoseanfrage an ein Diagnoseanfrage-Hörer-Computergerät; und Herstellen mit dem Diagnoseanfrage-Hörer-Computergerät eines Kommunikationskanals zwischen dem einen Diagnosegerät und einem Terminal in einem Call-Center, um eine Kommunikation zwischen einem Benutzer des einen Diagnosegeräts und dem Call-Center zu ermöglichen, um ein Problem mit dem einen Fahrzeug in Bezug auf die ersten Diagnosedaten festzustellen.
15. Verfahren nach Anspruch 14, ferner aufweisend: Übertragen mit dem Diagnoseanfrage-Hörer-Computergerät der ersten Diagnosedaten an das Terminal; und Anzeigen mit dem Terminal in dem Call-Center der ersten Diagnosedaten von dem einen Diagnosegerät.

Images