DE10319493A1

DE10319493A1 - Ferndiagnose- und Prognoseverfahren für komplexe Systeme

Info

Publication number: DE10319493A1
Application number: DE10319493A
Authority: DE
Inventors: Kenneth A Marko; Doug Thornburg; George Halow; Shane Rachedi
Original assignee: Ford Global Technologies LLC
Current assignee: Ford Global Technologies LLC
Priority date: 2002-05-16
Filing date: 2003-04-30
Publication date: 2003-11-27
Anticipated expiration: 2023-05-01
Also published as: GB2388666B; US20030216889A1; GB0309702D0; US6745151B2; DE10319493B4; GB2388666A

Abstract

Diagnose-/Prognosesystem zur Überwachung der Leitung eines Fahrzeugs oder einer anderen Ausrüstung, wobei das Fahrzeug mehrere Betriebskomponenten umfaßt. Jede Betriebskomponente weist einen bestimmten Sollbetriebszustand auf und erzeugt ihrem Betrieb entsprechende elektrische Signale. Ein Datenerfassungsspeicher im Fahrzeug speichert Abtastwerte dieser elektrischen Signale in einem umlaufenden Puffer. Ein Analysator im Fahrzeug spricht auf die elektrischen Signale an, um ein auslösendes Ereignis zu erkennen, das auf mindestens eine potentielle Abweichung einer Betriebskomponente von ihrem Sollbetriebszustand hinweist. Ein Rechenzentrum, das fern vom Fahrzeug angeordnet ist, weist eine Datenbank auf, die Darstellungen von elektrischen Signalen speichert, um die Soll- und Fehlerbetriebszustände der Betriebskomponenten zu klassifizieren. Ein Sender wird durch das auslösende Ereignis aktiviert, um mindestens einige der Abtastwerte, die zur Zeit des auslösenden Ereignisses im umlaufenden Puffer gespeichert wurden, an das Rechenzentrum zu übertragen. Das Rechenzentrum empfängt diese übertragenen Abtastwerte und klassifiziert sie den Soll- und Fehlerbetriebszuständen entsprechend.

Description

BESCHREIBUNG DES STANDS DER TECHNIK

Die vorliegende Erfindung betrifft allgemein die Ferndiagnose und -prognose für komplexe Systeme wie z. B. Fahrzeuge und andere Maschinen, und insbesondere ein Fahrzeug-Telematiksystem und -verfahren, um die an Bord eines Fahrzeugs erfaßten Betriebsdaten an ein zentrales Diagnosezentrum zu übertragen.

Komplexe mechanische, elektrische und elektromechanische Systeme wie Kraftfahrzeuge, Maschinen, elektronische Steuerungen und andere Geräte werden serienmäßig hergestellt und sind weit verbreitet. Auch wenn die Zuverlässigkeit und Haltbarkeit solcher Systeme von den Herstellern allgemein ständig verbessert wird, läßt sich die Tendenz zu Ausfällen oder zu eingeschränkter Systemleistung langfristig nicht ganz vermeiden. Aus diesem Grund werden oft Systemüberwachungs- und diagnosetests verwendet, um Anomalien und deren Ursachen zu erkennen.

Diagnose-/Überwachungsfunktionen werden sowohl an Bord der Systeme als auch in speziellen Testzentren eingesetzt. In Kraftfahrzeugsystemen zum Beispiel wird eine Kombination aus Borddiagnose und Werkstattdiagnose verwendet, um ein Problem zu erkennen und seine Ursache zu isolieren, damit der Reparaturvorgang auf wirtschaftliche Weise durchgeführt werden kann. Aufgrund der Kosten- und Hardwarezwänge in einer Fahrzeugumgebung sind der Umfang und die Fähigkeiten von Borddiagnosesystemen jedoch eingeschränkt. Die Werkstattdiagnose zum anderen ist weniger kosten- oder raumbedingten Zwängen ausgesetzt, erfordert aber, daß das Fahrzeug in eine Werkstatt gebracht wird, bevor ein Fehler erkannt werden kann oder Korrekturmaßnahmen (z. B. die Beschaffung von Ersatzteilen) eingeleitet werden können.

Die Verwendung der Fernüberwachung und -diagnose und/oder die Aufzeichnung von Datensignalen wurde zwar geprüft, um diese Situation zu verbessern, jedoch ohne voll zufriedenstellende Ergebnisse. Aufgrund der Bandbreitenbeschränkungen der Fernübertragungskanäle (z. B. Zellular- oder andere HF-Systeme) können während des Normalbetriebs nur relativ kleine Istdatenmengen aus dem Fahrzeug exportiert werden. Selbst, wenn eine größere Bandbreite verfügbar wurde, wäre es dennoch nicht machbar, lediglich größere Datenvolumen für die Fernanalyse zu exportieren, vor allem, wenn eine große Kundschaft (d. h. Fahrzeugflotte) betroffen ist.

Die Aufzeichnung, im Fahrzeug, von Daten für den späteren Zugriff in einer Werkstatt kann größere Datenmengen verwenden, wenn ein Speicher ausreichender Größe vorgesehen wird. Die Verwendung solcher Daten setzt aber einen Werkstattbesuch voraus und ist allgemein nur dann von Nutzen, wenn die eingeschränkte Leistung bereits eingetreten ist.

ZUSAMMENFASSUNG DER ERFINDUNG

Die vorliegende Erfindung erreicht erhebliche Vorteile bei der schnellen und effizienten Erkennung und Vorhersage des Ausfalls oder der nichtoptimalen Leistung von komplexen Systemen, mit gleichzeitigen Verbesserungen bei der Bereitstellung von Korrekturmaßnahmen zur Wiederherstellung der optimalen Leistung.

In einem Aspekt der Erfindung wird ein System zur Überwachung der Leistung einer Ausrüstung bereitgestellt, wobei die Ausrüstung mehrere Betriebskomponenten umfaßt und jede Betriebskomponente einen bestimmten Sollbetriebszustand aufweist. Jede Betriebskomponente erzeugt ihrem Betrieb entsprechende elektrische Signale. Ein Datenerfassungsspeicher in der Ausrüstung speichert Abtastwerte dieser elektrischen Signale in einen umlaufenden Puffer. Ein Analysator in der Ausrüstung spricht auf die elektrischen Signale an, um ein auslösendes Ereignis zu erkennen, das auf mindestens eine potentielle Abweichung einer Betriebskomponente von ihrem Sollbetriebszustand hinweist. Ein Rechenzentrum, das fern von der Ausrüstung angeordnet ist, weist eine Datenbank auf, die Darstellungen von elektrischen Signalen speichert, um die Soll- und Fehlerbetriebszustände der Betriebskomponenten zu klassifizieren. Ein Sender wird durch das auslösende Ereignis aktiviert, um mindestens einige der Abtastwerte, die zur Zeit des auslösenden Ereignisses im umlaufenden Puffer gespeichert wurden, an das Rechenzentrum zu übertragen. Das Rechenzentrum empfängt diese übertragenen Abtastwerte und klassifiziert sie den Soll- oder Fehlerbetriebszuständen entsprechend.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Fig. 1 ist ein Blockdiagramm eines Diagnose- und Prognosedienstsystems zur Wartung eines Fahrzeugs.
Fig. 2 ist ein Blockdiagramm, das die Datenerfassung, die Datenanalyse und die Kommunikationseinrichtung im Fahrzeug zeigt.
Fig. 3 zeigt Abschnitte der Vorrichtung von Fig. 2 mit näheren Details.
Fig. 4 ist ein Blockdiagramm, das den Analysator von Fig. 2 und 3 mit näheren Details zeigt.
Fig. 5 und 6 sind Flußdiagramme, die ein vorzugsweises erfindungsgemäßes Verfahren zeigen.

AUSFÜHRLICHE BESCHREIBUNG

Die vorliegende Erfindung verwendet ein Leistungsüberwachungssystem, das eine Kombination aus einer Borddatenerfassung, beschränkten Bordrechenkapazitäten (d. h. beschränkter Speicher und beschränkte Verarbeitung), ein umfangreiches Rechenzentrum (z. B. ein Datenklassifikations- und Entscheidungsserver) und eine Zweiwegkommunikation mit mäßiger Bandbreite zwischen dem Fahrzeug und dem Rechenzentrum anwendet. In einer vorzugsweisen Ausführungsform verbindet eine Hochgeschwindigkeitsdatenleitung an Bord ein Diagnosemodul im Fahrzeug mit verschiedenen Betriebskomponenten (d. h. elektronische Module, Multiplex-Kommunikationsbusse, Sensoren und Antriebe), die ihrem Betrieb entsprechende elektrische Signale erzeugen. Die Hochgeschwindigkeitsdatenleitung kann von der Diagnoseeinheit gesteuert werden, um die Identität der erfaßten Abtastungswerte zu wählen. Die erfaßten Daten umfassen vorzugsweise Diagnose-Fehlercodes (DTCs), interne Merker, die die verschiedenen Systemzustände anzeigen (z. B. ein Merker, um anzuzeigen, daß ein Fehler bei einer vorherigen Fahrt erkannt wurde), Eingangs- und Ausgangsvariablen für die verschiedenen Steuerungsmikrocontroller, und den Inhalt des Mikrocontrollerspeichers. Die erfaßten und aufgezeichneten Abtastwerte können auch Daten aus der Signalverarbeitung enthalten, die vom Diagnosemodul selbst durchgeführt wird. Die Verarbeitungskapazitäten an Bord umfassen vorzugsweise die einfache numerische Analyse und andere Kapazitäten, insbesondere zur Durchführung der langfristigen Diagnoseanalyse (wie z. B. Histogramme, Parametermittelung usw.).
In einer vorzugsweisen Ausführungsform zeichnet ein umlaufender Puffer die Zeitreihen-Abtastwerte eine Anzahl vorgegebener Parameter (z. B. etwa 20 Parameter) auf, um mindestens die letzten ~20 Sekunden Daten im Puffer zu behalten. Nach Empfang eines auslösenden Ereignisses werden weitere 20 Sekunden Daten aufgezeichnet und behalten. Das auslösende Ereignis wird verwendet, um die Datenübertragung zum Rechen-/Entscheidungszentrum automatisch einzuleiten. Dadurch erfaßt der umlaufende Puffer Informationen sowohl vor als auch nach dem auslösenden Ereignis, um Informationen über den Systembetrieb unmittelbar vor der Fehlererkennung und unmittelbar danach bereitzustellen.
Die erfaßten Daten sind ein Teilsatz aller elektrischen Signale, die in einem Fahrzeug verfügbar sind. Eine vorzugsweise Ausführungsform verwendet die dynamische Rekonfigurierbarkeit der Datenerfassung und der Analyseprozessoren an Bord, auf der Basis der Analyse außerhalb von Bord (d. h. im zentralen Rechenzentrum), die die Eignung und die Vollständigkeit der erfaßten Information für einen bestimmten Diagnosevorgang ermittelt. Das heißt, wenn der Standarddatensatz angesichts eines bestimmten auslösenden Ereignisses, das aufgetreten ist, für die Diagnoseanalyse nicht geeignet ist, kann die erfaßte Information zu einem geeigneteren Satz umgeändert werden, auf Anforderung entweder des externen Entscheidungszentrums oder des Borddiagnosemoduls selbst hin. Mit anderen Worten, das Diagnosemodul wählt die aufzuzeichnenden Daten abhängig von den Fehlercodes, die gesetzt wurden, oder vom auslösenden Ereignis, das aufgetreten ist.
Die Datenübertragung zum Rechen-/Entscheidungszentrum kann durch verschiedene auslösende Ereignisse gestartet werden, einschließlich 1) Bord- DTCs, schwebende Codes oder sonstige Hinweise, in den erfaßten Daten, auf eine potentielle Abweichung einer Betriebskomponente von ihrem Sollbetriebszustand, 2) eine planmäßige Datenübertragung (z. B., um in regelmäßigen Abständen Daten zu übertragen oder bestimmte Analysen durchzuführen), 3) Knopfdruck des Bedieners (bei Ereignissen, die dem Fahrer auffallen, von der vorhandenen Borddiagnose aber nicht erkannt werden), 4) Fernanforderungen, die das Erfassen von Fahrzeugdaten für Diagnose- und Kundenbedürfnisse erlauben (Fahrzeugposition, Fahrzeugzustand usw.), 5) Ausführung von eingebetteten und modifizierbaren logischen Ausdrücken, die eingehende Daten auf bestimmte Betriebsmodi oder relevante Zustände hin abtasten.
Das Diagnose-/Prognosesystem ist in der Lage, kleine Programme auszuführen, um potentielle Abweichungen zu erkennen und auslösende Ereignisse zu erzeugen. Die Skriptprogramme können ferngeladen und an verschiedene Kundenmerkmale und Diagnosebedürfnisse angepaßt werden, die bei der Herstellung eines bestimmten Fahrzeugs nicht vorhergesehen wurden.
Die Erfindung stellt Daten bereit, die das Auftreten eines auslösenden Ereignisses auf eine Weise umgeben, die an spezielle Diagnosebedürfnisse angepaßt werden kann. Zum Beispiel kann die Frequenz der Datenabtastung angepaßt werden (von der maximalen Geschwindigkeit des Kommunikationsanschlusses auf eine niedrigere Geschwindigkeit), um das geeignete Zeitfenster für die Information zu erfassen, die ein auslösendes Ereignis umgibt.
Das System kann programmiert werden, um den Typ, die Frequenz und die Identität der Parameter zu ändern, die einem auslösenden Ereignis oder einen Fernbefehl entsprechend aufgezeichnet werden. Diese Parameter können zum Beispiel aus logischen oder numerischen Operationen an den normalerweise überwachten Daten bestehen.
Die Erfindung ist auch ausgelegt, um bei Ereignissen wie z. B. (auf der Basis von Systemzuständen) intern gesetzten Merkern ausgelöst zu werden, die Fehlerarten ankündigen können. Dadurch ist es möglich, für bestimmte Fehlerarten eine Schätzung der Funktionsdauer bis zum Ausfall anzugeben, vor allem im Anschluß an die umfassende Analyse, die im Rechen- /Entscheidungszentrum durchgeführt wurde.
Die Erfindung verwendet eine externe, zentrale Rechenressource, um die Daten zu analysieren und eine Diagnose auszugeben, ob durch automatisierte Analyse oder durch sachkundige Techniker. Die Analyse kann mit Echtzeit- Datenaustausch zwischen dem Fahrzeug und den ausgeführten Diagnoseroutinen durchgeführt werden, wenn dies zur Erfüllung der Diagnoseaufgabe notwendig ist. Das System protokolliert und archiviert alle Daten, die zusammen mit den erfaßten Daten an den zentralen Server übertragen werden, wie z. B. die Zeit, den Ort und die Identifizierungsnummer des Fahrzeugs.
Das Diagnosemodul kann ausgelegt werden, um die Fernprogrammierung des Mikrocontrollers zu erlauben, um Reparaturvorgänge zu ermöglichen (zum Beispiel die Neuprogrammierung der Betriebsparameter von Fahrzeug- Controllern), die es normalerweise notwendig machen würden, das Fahrzeug in eine Werkstatt zu bringen.
Das Gesamtsystem umfaßt vorzugsweise einen Sicherheitsschutz, um das Fahrzeug vor unbefugten Eingriffen zu schützen. Der Sicherheitsschutz kann mehrere Berechtigungsebenen für den persönlichen Datenschutz und Zugriffsbeschränkungen für mehrere Benutzer aufweisen (z. B. Händler, Hersteller, Personal, Familie usw.).
Ein Bordkommunikationsgerät ist vorgesehen, um die Information an den Fahrzeugbediener auszugeben. Das Gerät kann einfach ein Radiotextdisplay, ein Anzeigebildschirm oder Sprachmeldungen sein, die zum Beispiel von einem Sprecher in das Fahrzeug übertragen werden.
Darüber hinaus können Fahrzeugdaten mit der Information verknüpft werden, die von Fahrzeugbedienern über ein Zellulartelefon, ein lokales Netzwerk oder eine Website erfaßt wurde. Diese Information ist dazu bestimmt, die Diagnoseauswertung zu unterstützen, indem sie die Möglichkeit bereitstellt, beobachtete Symptome oder sonstige Umstände aufzuzeichnen, die mit einem bestimmten auslösenden Ereignis im Zusammenhang stehen, jedoch insbesondere für die vom Bediener gestartete Erfassung von Daten, denen kein DTC zugeordnet ist.
Spezifische Details der vorliegenden Erfindung werden in Verbindung mit einer Ausführungsform zur Überwachung von Kraftfahrzeugen in einer großen, mobilen Flotte unter Bezugnahme auf Fig. 1-6 beschrieben.
Fig. 1 zeigt ein Fahrzeug 10, das über einen Übertragungskanal mit einer drahtlosen Verbindung 11 mit einem Telematik-Antwortzentrum 12 verbunden ist. Die Verbindung 11 und das Antwortzentrum 12 können ein zellulartelefonbasiertes Telematikdienstsystem umfassen, um ein Fahrzeug mit verschiedenen Elektronik- und Kommunikationsdiensten zu verbinden, wie es zum Beispiel bei verschiedenen Zellulardienstanbietern kommerziell verfügbar ist.
Das System kann aber auch die Stapelübertragung von Daten, über eine drahtlose Verbindung, an lokale Netzwerke (LANs) verwenden, die Daten mit viel höheren Bandbreiten empfangen können, wenn das Fahrzeug sich in der Nachbarschaft der dafür vorgesehen Empfänger befindet (die z. B. an Tankstellen oder am Straßenrand angeordnet sein können).
Ein Diagnoserechen- und -entscheidungszentrum 13 kann am selben Ort wie das Antwortzentrum 12 oder an einem fernen Ort angeordnet sein, wie z. B. in den Einrichtungen des Fahrzeugherstellers. Ein digitales Netz 14 wie z. B. das öffentliche Internet oder ein Privatnetz verbindet das Antwortzentrum 12 mit dem Rechenzentrum 13. Der Server 15 startet einen Versuch, die Daten in der empfangenen Meldung den bekannten potentiellen Fehlern des betreffenden Fahrzeugs entsprechend zu klassifizieren. Die Klassifizierung wird zunächst durch den Vergleich mit einer bestehenden Diagnosedatenbank 16 versucht, die vom Hersteller auf der Basis der bekannten Leistungsparameter des Fahrzeugs und seiner Betriebskomponenten (z. B. der Antriebsstrang oder andere Steuermodule, Stellantriebe, Sensoren usw.) erstellt wurde. Der Vergleich kann auf Mustererkennung oder einer anderen Analyse basieren, um "Treffer" oder Übereinstimmungen zwischen den eingehenden Fahrzeugdaten und den in der Datenbank 16 gespeicherten Datenmustern zu erkennen, wobei jeder Treffer für Komponentenfehler oder potentielle Fehler steht, die aus den Daten hervorgehen. Die Komplexität der Daten aus dem Fahrzeug wird vor dem Mustervergleich typischerweise durch einen Vorgang reduziert, der als Merkmalsextraktion bekannt ist. Bei diesem Vorgang werden komplexe Zeitreihensignale analysiert, um "Merkmale" zu extrahieren, die für Diagnosezwecke von Nutzen sind. Zu diesen gehören, ohne darauf beschränkt zu sein, Parameter wie z. B. der Mittelwert eines Signals, seine Abweichung, sein Höchstwert, sein Mindestwert, die Zahl der Nullpunktüberquerungen pro Zeiteinheit, der gewichtete gleitende Mittelwert usw.. Der Satz der extrahierten "Merkmale" wird durch eine Analyse der Relevanz jedes Merkmals für die Diagnose festgelegt, und wenn genügend Merkmale erkannt wurden, um alle bekannten Probleme voneinander und vom Normalbetrieb zu unterscheiden, gilt der Merkmalssatz als für Diagnosezwecke zufriedenstellend.
Wenn ein Versuch, eingehende Daten zu klassifizieren, erfolgreich ist (d. h., der Fehler oder die Unregelmäßigkeit ist alt und wurde bereits zuvor erkannt), dann wird die Klassifikation an einen Antwortblock 17 übergeben, um geeignete Maßnahmen zu ermitteln, falls vorhanden, die bereits zuvor erkannt wurden, um den Fehler oder die Unregelmäßigkeit zu beheben.
Wenn ein Versuch, eingehende Daten zu klassifizieren, erfolglos verlaufen ist, da in der bestehenden Datenbank 16 kein übereinstimmendes Muster vorhanden ist, dann werden die Daten als neuer Fall klassifiziert und an den Analysevorgang 18 übergeben, der ein sachkundiges Team umfassen kann, das mit verschiedenen Prüfgeräten, Testfahrzeugen und Softwaretools (z. B. Simulation) arbeitet. Sobald der Analyseprozeß das Datenmuster als neu klassifizierten Fehler oder Frühwarnzustand aufgelöst hat, werden die Klassifikationsdaten zusammen mit den Bezugsmustern oder sonstigen Erkennungsanweisungen zur Diagnosedatenbank 16 hochgeladen. Die Abhilfemaßnahmen, die in diesem neu erkannten Fall zu ergreifen sind, werden an den Antwortblock 17 und an eine Wartungsorganisation (z. B. das Händlernetz) 20 übertragen.
Auf der Basis der Klassifikation der Daten aus dem Fahrzeug 10 werden vom Antwortblock 17 Abhilfemaßnahmen an das Telematik-Antwortzentrum 12 (zur Weiterleitung an das Fahrzeug 10) und/oder an die Wartungsorganisation übertragen. Diese Maßnahmen, die an das Fahrzeug 10 gesendet werden, können die Übertragung neuer Steuerparameter umfassen, die in seine elektronischen Steuergeräte ferngeladen werden und von diesen verwendet werden, oder eine Meldung, die dem Fahrzeugbediener angezeigt werden soll, um ihm einen Werkstattbesuch für Korrekturmaßnahmen (z. B. die Einstellung von Komponenten oder der Austausch von Teilen) zu empfehlen. Auch die Wartungsorganisation 20 wird über einen empfohlenen Werkstattbesuch informiert, so daß der Besuch eingeplant werden kann und die Ersatzteile, falls erforderlich, im voraus beschafft werden können. Das Telematik-Antwortzentrum 12 kann verwendet werden, um einen Wartungstermin einzuplanen. Dadurch werden Fehlerzustände oder potentielle Fehlerzustände am Fahrzeug 10 schnell erkannt, und eine Wiederherstellung des Normalbetriebs wird auf proaktive Weise mit minimaler Unterbrechung für den Bediener des Fahrzeugs 10 und in kürzestmöglicher Zeit durchgeführt.
Zusätzlich zur Erfassung von Diagnosedaten ist die vorliegende Erfindung in der Lage, Daten zu erfassen, die weit vor der Fehlerkennung an Bord des Fahrzeugs liegen. Solche Daten werden vom Fahrzeug erfaßt, erhalten und auf das Trendverhalten hin analysiert, um die Funktionsdauer bis zum Ausfall der analysierten Systeme zu projektieren. Die Information, die zu diesem Zweck erfaßt wird, und ihre Erfassungshäufigkeit sind vom Verhalten jedes spezifischen Fahrzeugssystems abhängig. Die Datenerfassung und -analyse wird angepaßt, um die höchste Genauigkeit in der Voraussage der Funktionsdauer bis zum Ausfall zu erhalten. Wenn zum Beispiel keine Verschlechterung in einem bestimmten Subsystem festgestellt wird und die projektierte Funktionsdauer bis zum Ausfall extrem lang ist, sind keine weiteren Übertragungen notwendig, außer, wenn die Situation sich geändert hat.
In dieser Hinsicht ist das System auch ausgelegt, um statistisch zusammenfassende Informationen über die Betriebshistorie des Fahrzeugs zu erfassen. Diese Information liegt gewöhnlich in Form von multidimensionalen Histogrammen vor (die verallgemeinerte Histogramminformation ist nicht nur auf ein, zwei oder drei Dimensionen beschränkt, sondern auf mehr als drei erweiterbar, um relevante Korrelationen in den Betriebsparametern zu erfassen).
Diese statistische Zusammenfassung wird verwendet, um die Härte des Betriebs in verschiedenen Betriebsarten zu bewerten, damit Systemlebensdauern besser projiziert werden können.
Um die maximale Effizienz von Diagnose und Reparatur zu gewährleisten, wird ein Überwachungsgerät 21 wie z. B. ein "Six Sigma Process Monitor" als Schnittstelle zwischen dem Fahrzeuginhaber/-benutzer und der Wartungsorganisation 20 verwendet. Die Leistungsmetrik wie z. B. die Genauigkeit der Diagnose, die Häufigkeit der klassifizierten Fehler in einer Flotte oder Fahrzeugreihe, die Reparaturzeit und andere Variablen werden vom Überwachungsgerät 21 gemessen, und Datentrends und mögliche Verbesserungen werden erkannt und implementiert.
Wie in Fig. 2 gezeigt, umfaßt die Vorrichtung an Bord ein Diagnosemodul 25, das in einem Telematik-Hauptmodul untergebracht sein kann oder nicht. In beiden Fällen ist das Diagnosemodul 25 mit einem Sende-Empfangs-Modul 26 der Telematik-Haupteinheit verbunden und kommuniziert über eine HF-Antenne 27 mit dem Telematik-Antwortzentrum. Eine Fahrerschnittstelle 30, die mit dem Diagnosemodul 25 verbunden ist, umfaßt zum Beispiel Eingabedruckknöpfe 31 und ein Display 32.
Zum Erfassen von Diagnosedaten wird das Diagnosemodul 25 mit einem Fahrzeugkommunikationsbus 33 verbunden, wie z. B. ein Standard-Controller- Area-Network (CAN-Bus) oder ein Bus, der der IEEE-Norm J1850 entspricht. Der Bus 33 ist auch mit verschiedenen Betriebskomponenten im ganzen Fahrzeug verbunden, einschliesslich der elektronischen Module 34 und 35, einem Sensor 36 und einem Stellantrieb 37. Die Module 34 und 35 können zum Beispiel ein Antriebsstrang-Steuermodul, ein ABS-Modul, ein Zubehörmodul, ein Beleuchtungssteuermodul, ein Klimaanlagenmodul, ein Audio/Unterhaltungsmodul oder ein Fahrwerkssteuermodul umfassen. Der Sensor 36 leitet die abgetasteten Datensignale über den Bus 33 an das Multiplex-Netz und kann zum Beispiel einen Temperatursensor oder einen Drucksensor umfassen. Der Stellantrieb 37 wird über das Multiplex-Netz ferngesteuert und kann zum Beispiel einen verstellbaren Fahrwerkstoßdämpfer umfassen. Das Diagnosemodul 25 hat im wesentlichen vollen Zugriff auf alle Signale, die im Bus 33 übertragen werden, und weist die Fähigkeit auf, mit jedem anderen Knoten im Multiplex-Netz Meldungen auszutauschen. Dadurch ist das Diagnosemodul 25 in der Lage, den im Netz vorhandenen Datenverkehr zu überwachen und zu extrahieren, oder spezifische Daten aus spezifischen Komponenten (Knoten) anzufordern.
Das Diagnosemodul 25 kann auch weitere Verbindungen zu anderen elektronischen Komponenten aufweisen, wie z. B. eine Direktverbindung mit einem Sensor 38. Ein solcher Sensor ist ein Schall- oder Vibrationssensor, der detaillierte akustische Bandbreitensignale zur detaillierten Analyse von Vibrations- und Lärmproblemen aufzeichnet. Wenn ein Fahrzeug überdies mehrere separate Multiplex-Busse verwendet (z. B. einen für die meisten Komponenten und einen separaten Bus für Audio/Unterhaltungskomponenten, weist das Diagnosemodul 25 vorzugsweise eine Schnittstelle zu jedem Bus auf.
Die Module 34 und 35 umfassen elektronische Steuergeräte (ECUs), jeweils 40 und 43, die typischerweise jedes einen programmierbaren Mikrocontroller enthalten. Das Modul 34 ist mit einem externen Stellantrieb 41 verbunden, während das Modul 35 einen internen Sensor 44 und einen internen Stellantrieb 45 aufweist. Das ECU 40 umfasst einen Speicher 42, um unter anderem einen Diagnose-Fehlercode (DTC) zu speichern, wann immer eine der Selbstdiagnoseroutinen im ECU 40 einen bestimmten Fehlerzustand erkennt. Die Borddiagnosenorm OBD-II zum Beispiel definiert verschiedene Codes, die über das Multiplex-Netz verfügbar gemacht werden müssen.
Das Diagnosemodul 25 umfaßt einen Controller 50, einen Puffer 51 vor dem Ereignis, und einen Puffer 52 nach dem Ereignis. Der Controller 50 ruft vorgegebene Datenteilsätze als elektrische Signale aus den verschiedenen Betriebskomponenten (d. h. Modulen, Sensoren und Stellantrieben) ab und speichert sie periodisch im Puffer 51 vor dem Ereignis. Wenn ein auslösendes Ereignis auftritt, ruft der Controller 50 zusätzliche Daten ab und speichert sie im Puffer 52 nach dem Ereignis, formatiert eine Datenmeldung und sendet die Meldung über den Sender-Empfänger 26 an das Telematik-Antwortzentrum.
Der Controller 50 umfaßt außerdem einen Zeitgeber 53, eine Eingabe/Ausgabe(E/A)-Schnittstelle 54 und einen Analysator 55. Auslösende Ereignisse können im Controller 50 dem Zeitgeber 53 oder Analysator 55 entsprechend erzeugt werden. Die E/A 54 sorgt für die Verbindung zur Fahrerschnittstelle 30 und mit einem optionalen Sender-Empfänger 56 für ein lokales drahtloses Netz, wie z. B. ein Bluetooth-Sender-Empfänger. Das lokale drahtlose Netz kann zum Beispiel in der Werkstatt zur einfachen Verbindung mit dem Diagnosemodul 25 verwendet werden.
Die Arbeitsweise des Controllers 50 wird in Fig. 3 ausführlicher dargestellt. Eine Teilsatzkonfiguration 57 steuert eine Auswahl von Daten aus allen Datensignalen, die zur Erfassung verfügbar sind, und versorgt einen Eingang des Puffers 51 vor dem Ereignis mit periodischen Abtastwerten. Wenn spätere Abtastwerte den Puffer 51 erreichen, läuft der vorhandene Inhalt in einem Zeitschlitz um, wobei der älteste Abtastwert gelöscht wird. Zu jeder bestimmten Abtastzeit wird ein Vektor oder eine Sammlung verschiedener Datensignale oder Parameter (d. h., einschliesslich berechneter Parameter) gespeichert und als eine Einheit behandelt.
Anfangs wird die Teilsatzkonfiguration 57 von einem Teilsatzselektor 58 auf einen Standardteilsatz gesetzt. Der Standardteilsatz gibt ein grobes Allgemeinbild der Fahrzeugleistung wieder und wird während der Zeit benutzt, in der im wesentlichen ein normaler Betrieb aller Betriebskomponenten vorliegt. Nach dem Auftreten eines auslösenden Ereignisses wird vom Teilsatzselektor 58 einer vom Analysator 55 erzeugten Ereigniskennung entsprechend ein Teilsatz gewählt, der angepaßt ist, um zu den mit der Ursache des auslösenden Ereignisses im Zusammenhang stehenden Bedingungen Daten mit größerer Relevanz bereitzustellen.
Der Analysator 55 erkennt auslösende Ereignisse im Anschluß an 1) ein Zeitgebersignal, 2) ein Fernsteuerungsereignis (RCE), das vom Rechenzentrum ausgelöst wird, 3) ein Bedienersteuerungsereignis (OCE), das vom Fahrer ausgelöst wird, indem er einen Knopf auf der Fahrerschnittstelle betätigt, wenn ihm ein symptomatisches Fahrzeugverhalten aufgefallen ist, und 4) die Analyse von Datensignalen, die aus den Fahrzeugkomponenten erfaßt werden, oder von berechneten Parametern, die im Analysator 55 auf der Basis der erfaßten Datensignale ermittelt werden. Die Erzeugung eines auslösenden Ereignisses durch Datenanalyse kann das Setzen eines Merkers oder eines Diagnose- Fehlercodes in einem anderen Modul umfassen, nachdem die Analyse tatsächlich in diesem Modul durchgeführt wurde. Wenn eine dieser Bedingungen vorliegt, erzeugt der Analysator 55 ein Signal zum Auslösen eines Ereignisses, um Auslösevorgänge einzuleiten, und erzeugt die Ereigniskennung, um die Ursache des aktuellen auslösenden Ereignisses anzugeben.
Wenn ein auslösendes Ereignis aufgetreten ist und der Teilsatzselektor 58 die Teilsatzkonfiguration 57 der Ereigniskennung entsprechend neu konfiguriert hat, werden die Abtastdaten durch die Konfiguration 57 zum Puffer 52 nach dem Ereignis geleitet, der eine bestimmte Länge aufweist (z. B. 20 Sekunden Abtastwerte, die mit einer Abtastrate von einem Abtastwert alle 4 Millisekunden erfaßt werden). Ein Schalter 60 kann verwendet werden, um jeden Abtastwert zu seiner entsprechenden Speicherstelle zum Beispiel im Puffer 52 zu leiten. Ein Gesamtabtastfenster von etwa 40 Sekunden (20 Sekunden im Puffer vor dem Ereignis und 20 Sekunden im Puffer nach dem Ereignis) gilt als in den meisten Fällen ausreichend, um die Klassifizierung eine Fehlers oder einer Unregelmäßigkeit zu erlauben. Der Zeit des auslösenden Ereignisses wird eine Zeit T = 0 zugewiesen. Daher enthält der Puffer vor dem Ereignis Daten für die Zeit T -20 Sekunden bis T = 0, und der Puffer nach dem Ereignis enthält Daten für die Zeit T = 0 bis T = 20 Sekunden.
Bei T = 0 wird der Inhalt der Puffers 51 vor dem Ereignis in einem Meldungsformatierungsblock 61 als Schnappschuß abgespeichert. Sobald der Puffer 52 nach dem Ereignis voll ist, wird sein Inhalt zusammen mit dem Schnappschuß vor dem Ereignis, der Ereigniskennung und einer Fahrzeugkennung (z. B. der Identifizierungsnummer des Fahrzeugs) im Formatierungsblock 61 zu einer Meldung formatiert. Die formatierte Meldung wird an den Sender-Empfänger gesendet, um an das Telematik-Antwortzentrum übertragen zu werden.
Weitere funktionale Details der Datenanalyse, die im Analysator 55 durchgeführt wird, um auslösende Ereignisse zu erkennen, werden in Fig. 4 gezeigt. Diese Analyse wird den Script-Algorithmen 62 entsprechend durchgeführt, die vom Mikrocontroller als erste Anzeige oder Warnung vor potentiellen Fehlern oder Unregelmäßigkeiten an den Fahrzeugkomponenten ausgeführt werden (d. h., die Komponenten weichen von ihrem Sollbetriebszustand ab). Dies reduziert die Last des Rechenzentrums und der Kommunikationsverbindung, da Daten nur in den seltenen Fällen übertragen werden, in denen der Betrieb nicht normal ist (oder auf besondere Anforderung oder bei periodischen Kontrollen), statt ständig übertragen zu werden, wie dies bei Systemen nach dem Stand der Technik der Fall ist.
Die Skript-Algorithmen 62 führen die Datenanalyse mit den vom Diagnosemodul erfaßten Datensignalen durch, die im Datenteilsatz enthalten sein können oder nicht, und dann im Puffer vor dem Ereignis oder im Puffer nach dem Ereignis gespeichert werden. Um die Algorithmen zu unterstützen, weist der Mikroprozessor des Diagnosemoduls vorzugsweise funktionelle Möglichkeiten auf, die zum Beispiel Ablaufsteuerungen (WENN-DANN-ODER), Schleifen (FOR- und DO-Schleifen), Boolesche Operationen (UND, ODER, NICHT), Bitverschiebungen und arithmetische Operationen (Ganzzahlen und Fließkomma) umfassen. Außerdem sind Funktionen enthalten, um bestimmte Meldungen an den Fahrzeugbus zu senden und von diesem zu empfangen, um Ereigniskennungen und Auslösesignale zu erzeugen, und um die Datenaufzeichnung im Puffer nach dem Ereignis zu starten.
Der Analysator 55 enthält Histogrammbezugsmuster 63, in Verbindung mit bestimmten Algorithmen, die aktuelle Datenhistogramme in einem Histogramm- Akkumulator 64 kompilieren und sie mit Bezugsmustern 63 vergleichen, um ein auslösendes Ereignis zu erkennen. Eine Ereigniskennung kann zum Beispiel dem übereinstimmenden Bezugsmuster entsprechend zugewiesen werden.
Der Analysator 55 umfaßt zudem Ressourcen (z. B. Speicherplatz und/oder Hardware von Firmware-Elementen), die einen Höchst-/Mindestwert-Block 65 zum Behalten eines Höchst- und/oder Mindestwerts eines Parameters oder Datensignals umfassen. Ein gleitendes Mittel-Block 66 kann angepaßt werden, um zum Beispiel Berechnungen des exponentiell gewichteten gleitenden Mittels durchzuführen. Eine algebraische Einheit 67 stellt Ressourcen zur Implementierung von algebraischen Standardfunktionen bereit.
Die Skript-Algorithmen 62 können zusammen mit den Histogramm-Bezugsmustern 63 durch neue oder modifiziere Algorithmen oder Muster aktualisiert werden, die vom Telematik-Antwortzentrum ferngeladen werden können und typischerweise vom Rechenzentrum bereitgestellt werden.
Ein vorzugsweises erfindungsgemäßes Verfahren wird in Fig. 5 und 6 gezeigt. Die Diagnoseüberwachung beginnt bei Schritt 70, wenn der Zündschlüssel steckt und der Motor läuft, wodurch ein "Key-on" Zyklus gestartet wird. Das Diagnosemodul wird in Schritt 71 konfiguriert, um eine Erfassung der Standardparameter durchzuführen. In Schritt 72 werden Zeitgeber gestartet, um ein periodisches Abtastintervall zu setzen, in dem alle verschiedenen Abtastwerte oder Parameter erfaßt werden.
In Schritt 73 wird eine Kontrolle durchgeführt, um zu prüfen, ob Datensignale von Betriebskomponenten (z. B. von elektronischen Modulen über den Multiplex-Bus) empfangen werden. Wenn nicht, dann wird in Schritt 74 eine Kontrolle durchgeführt, um zu prüfen, ob die Zeitgeber abgelaufen sind. Wenn ein Zeitgeber abgelaufen ist, sendet das Diagnosemodul in Schritt 75 eine Datenanforderung an ein Zielmodul, das über die gewünschten Daten verfügt. Alternativ dazu, wenn die Zieldaten aus einer Direkteingabe in das Diagnosemodul verfügbar sind, werden die Zieldaten einfach am geeigneten Eingang abgetastet. Sobald eine Anforderung gesendet ist, werden die entsprechenden Zeitgeber in Schritt 76 neu gestartet und es erfolgt ein Rücksprung zu Schritt 73.
Wenn in Schritt 73 festgestellt wird, daß eingehende Daten vorhanden sind, werden die Daten in Schritt 77 als Teil einer bestimmten Zeitprobe im Puffer vor dem Ereignis gespeichert. In Schritt 78 werden Prüfungen auf RCE- oder OCE- Ereignisse hin durchgeführt, in Schritt 79 auf DTCs oder Merker hin, und in Schritt 80 auf Datenereignisse hin (z. B., wenn ein Algorithmus feststellt, daß bestimmte Bedingungen erfüllt sind, wie z. B., daß der Reifendruck einen Schwellenwert unterschreitet, oder daß ein Histogramm für den Öldruck mit einem Bezugshistogramm übereinstimmt).
Wenn all diese Prüfungen negativ verlaufen, springt das Verfahren zu Schritt 73 zurück. Wenn eine Prüfung positiv verlaufen ist, dann geht das Verfahren zur Erfassung der Daten nach dem Ereignis in Fig. 6 über.
In Schritt 81 von Fig. 6 wird der Inhalt des Puffers vor dem Ereignis abgerufen. Dies kann durchgeführt werden, indem die Aktualisierung des Puffers unterbrochen wird, bis die Datenmeldung gesendet ist, oder indem der gesamte Pufferinhalt an einen weiteren Zwischenspeicher-Block gesendet wird. In Schritt 82 wird eine Prüfung durchgeführt, um zu ermitteln, ob der Parameterteilsatz, der der Ereigniskennung des auslösenden Ereignisses entspricht, anders ist als der Parameterteilsatz, der aktuell konfiguriert ist. Falls erforderlich, werden der Teilsatz und die Zeitgeber in Schritt 83 neu konfiguriert. Wenn zum Beispiel im Puffer vor dem Ereignis Standardparameter gespeichert sind, wenn ein auslösendes Ereignis mit einer Ereigniskennung auftritt, die auf ein Motorproblem hinweist, kann der Parameterteilsatz zu einem umgeändert werden, der mehr motorbezogene Parameter enthält.
In Schritt 84 werden auf der Basis des Parameterteilsatzes, der aus den Schritten 82 und 83 resultiert, Datenanforderungen an die Betriebskomponenten des Fahrzeugs gesendet. Die empfangenen Daten werden in Schritt 85 im Puffer nach dem Ereignis gespeichert. In Schritt 86 wird eine Kontrolle durchgeführt, um zu prüfen, ob die letzten Abtastwerte für den Puffer nach dem Ereignis erfaßt wurden. Wenn nicht, wird ein Rücksprung zu Schritt 84 durchgeführt.
Sobald die letzten Abtastwerte im Puffer nach dem Ereignis gespeichert sind, wird in Schritt 87 eine Meldung formatiert. Die Meldung enthält vorzugsweise alle Abtastwerte aus den Puffern vor dem Ereignis und nach dem Ereignis, eine Ereigniskennung und eine Fahrzeugkennung wie z. B. die Identifizierungsnummer. Die formatierte Meldung wird in Schritt 88 gesendet. Wenn die Meldung gesendet wurde, springt das Verfahren zur Datenerfassung für den Puffer vor dem Ereignis zurück. In einer Ausführungsform erfolgt ein Rücksprung zu Schritt 71, so daß der Standardparameterteilsatz wiederhergestellt wird. Alternativ dazu kann ein Rücksprung zu Schritt 73 erfolgen, um den Teilsatz, der dem soeben aufgetretenen auslösenden Ereignis entspricht, weiterzuverwenden. In dieser alternativen Ausführungsform wird der Standardteilsatz vorzugsweise nach einer bestimmten Verzögerung (die z. B. vom Diagnosemodul festgelegt wird, oder auf einen Befehl vom Rechenzentrum hin) wiederhergestellt.
Je nach Ernsthaftigkeit des auslösenden Ereignisses kann die Übertragung einer bestimmten Meldung aufgeschoben werden. Die Zellulartelefon-Verbindungskosten sind typischerweise je nach Tageszeit und Wochentag verschieden. Wenn ein geringfügiges auslösendes Ereignis zu einer Zeit auftritt, in der die Verbindungskosten hoch sind, kann es vorteilhaft sein, die Übertragung der Meldung so lange aufzuschieben, bis die Verbindungskosten niedriger sind. Die Merker oder DTCs, die zu einem auslösenden Ereignis führen, können zum Beispiel unterschiedlichen Typs sein. Eine Fehlfunktionsanzeige (MIL) ist eine Leuchte auf dem Armaturenbrett des Fahrzeugs, die aufleuchten muß, wenn die OBD II-Borddiagnosestrategie in einem Abtriebsstrang-Steuermodul einen Hardwarefehler erkennt, der zur Folge haben könnte, daß Abgasemissionsgrenzwerte überschritten werden. Ein DTC dieser Kategorie wird als "bestätigte MIL-DTC" bezeichnet. Einige DTC-Erkennungen haben die Einschaltung der MIL erst dann zur Folge, wenn die DTC seit bestimmter Zeit oder einer bestimmte Zahl von Fahrzyklen fang vorlag. Bis diese Anforderung erfüllt ist, gilt die DTC als "schwebende MIL-DTC". Andere DTCs sind von MIL-Ereignissen unabhängig (d. h., sie entsprechen einer nicht emissionskritischen Komponente) und können je nach der Komponente und dem Fehler, die sie darstellen, eine mehr oder weniger große Ernsthaftigkeit aufweisen.
Bei einem bestätigten MIL-DTC wird die Meldung vorzugsweise sofort gesendet. Bei einem schwebenden MIL-DTC kann die Übertragung vorzugsweise auf eine Zeit aufgeschoben werden, in der die Verbindungskosten niedriger sind. Für sonstige DTCs und für jedes Datenereignis (d. h., für jede Ereigniskennung) kann eine bestimmte Benennung vorgesehen werden, um festzulegen, ob die Übertragung einer Meldung aufgeschoben werden kann oder nicht.
Um die Übertragung einer Meldung aufzuschieben, muß im Diagnosemodul oder Telematikmodul genügend Speicherplatz zum Speichern mehrerer Meldungen verfügbar sein. In einer vorzugsweisen Ausführungsform werden die Datenabtastungen insgesamt 40 Sekunden lang mit einer Abtastrate von 250 pro Sekunde (d. h., 4 Millisekunden zwischen jeder Abtastung) aufgezeichnet. Jeder Abtastwert enthält vorzugsweise etwa 5 Bytes Daten, einen 2 Byte langen Zeitstempel mit, der seine Position im Puffer kennzeichnet, und eine 1 Byte lange Paketkennung. Jede Meldung kann auch Informationen darüber umfassen, welcher Datenteilsatz in der Meldung enthalten ist, und/oder eine spezifische Kennzeichnung jedes einzelnen Parameters in den Meldungsdaten. Der gesamte Speicherbedarf für eine Meldung kann sich daher auf etwa 85 Kilobyte belaufen.
Das erfindungsgemäße System weist für den Benutzer der überwachten Vorrichtung (z. B. den Fahrer des Fahrzeugs) erhebliche Vorteile auf, da es nicht nur für die rechtzeitige und genaue Erkennung und Korrektur der tatsächlich diagnostizierten Fehlfunktion ermöglicht, sondern auch in der Lage ist, einen wahrscheinlichen Fehler und die wahrscheinliche Funktionsdauer bis zum Ausfall vorherzusagen (d. h., Prognose). Solche Prognosen erfordern typischerweise umfangreiche und interaktive Algorithmen, die sich nicht leicht vollständig an Bord eines Fahrzeugs oder einer anderen überwachten Ausrüstung implementieren lassen. Die vorliegende Erfindung teilt die Rechen-/Klassifikationsaufgaben auf, um eine maximale Effizienz, minimale Gesamtkosten und schnellstmögliche Ergebnisse zu erreichen. Die Erfindung ist dadurch in der Lage, 1) außerplanmäßige Ausfallzeiten und Fahrzeugpannen zu reduzieren, 2) die Wartungsintervalle zu optimieren, um die Gesamtwartungskosten eines Fahrzeugs zu senken, 3) die problemlose Wartung an günstig gelegenen Wartungsterminen zu ermöglichen, mit der Möglichkeit, einige Fehler oder Unregelmäßigkeiten durch Fernladen zum Beispiel von Steuerparametern oder Algorithmen zu beheben, und 4) die schnelle Erkennung flottenweiter Fehlfunktionen bestimmter Komponenten zu ermöglichen, so daß ein potentieller Mangel an allen in Betrieb befindlichen Fahrzeugen korrigiert werden kann und Korrekturmaßnahmen ergriffen werden können, um den Mangel an Fahrzeugen zu beheben, die noch in Produktion sind.
Einige Beispiele für prognostizierte Fehler und die entsprechenden überwachten Parameter für Kraftfahrzeuge werden im folgenden angeführt.
Was das Reifensystem anbetrifft, können der Luftdruck, die Auswuchtung und der Verschleiß überwacht werden. Änderungsmuster in diesen Parametern können Fehler vorhersagen, die auf beschädigte oder undichte Reifen und falsche Bereifung zurückzuführen sind. Diese Parameter können auch auf einen möglichen Stoßdämpferfehler hinweisen.
In der Bremsanlage werden der Belagverschleiß und andere Bremsleistungsparameter überwacht. Es ist möglich eine Verschlechterung der Bremsleistung vorherzusagen, die auf Belagverschleiß, verzogene Rotoren oder Scheiben und einen Ausfall des automatischen Bremsreglers zurückzuführen sind.
Was das Getriebesystem anbetrifft, werden Parameter wie die Schaltqualität, die Getriebeölqualität, die Öltemperatur, der Ölstand und die Diagnosecodes des Getriebesteuergeräts erfaßt. Es können Fehler erkannt werden, die auf Zahnrad- und Lagerverschleiß, verstellte Schaltbereiche, Getriebeölverlust und Probleme im elektronischen Modul zurückzuführen sind.
Was das Motorsystem anbetrifft, können die erfaßten Parameter die Motorölqualität, den Ölstand, den Öldruck, die Öltemperatur, die Rauheit, Kühlsystemparameter, Motorfehlzündungen, die Katalysatorleistung und anderes umfassen. Zahlreiche potentielle Fehler können vorhergesagt werden, einschließlich verstopfter Einspritzdüsen, schlechter Zündkerzen, falscher Motoreinstellung, verstopfter Luft-, Kraftstoff- oder Ölfilter, Motorventilfehlfunktion und anderes.

Claims

1. System zur Überwachung der Leistung einer Ausrüstung, umfassend:
mehrere Betriebskomponenten, die in dieser Ausrüstung betrieben werden, wobei jede Betriebskomponente einen bestimmten Sollbetriebszustand aufweist und jeweils ihrem Betrieb entsprechende elektrische Signale erzeugt; einen Datenerfassungsspeicher in der Ausrüstung, der Abtastwerte dieser elektrischen Signale in einen umlaufenden Puffer speichert;
einen Analysator in der Ausrüstung, der auf die elektrischen Signalen anspricht, um ein auslösendes Ereignis zu erkennen, das auf mindestens eine potentielle Abweichung einer Betriebskomponente von ihrem Sollbetriebszustand hinweist;
ein Rechenzentrum, das fern von der Ausrüstung angeordnet ist und eine Datenbank aufweist, die Darstellungen von elektrischen Signalen speichert, um die Soll- und Fehlerbetriebszustände der Betriebskomponenten zu klassifizieren; und
einen Sender, der durch das auslösende Ereignis aktiviert wird, um mindestens einige der Abtastwerte, die zur Zeit des auslösenden Ereignisses im umlaufenden Puffer gespeichert waren, an das Rechenzentrum zu übertragen;
wobei das Rechenzentrum diese übertragenen Abtastwerte empfängt und sie den Soll- oder Fehlerbetriebszuständen entsprechend klassifiziert.

2. System nach Anspruch 1, wobei die Ausrüstung aus einem Kraftfahrzeug besteht und der Sender ein drahtloser Sender ist.

3. System nach Anspruch 1, wobei die vom Sender übertragenen Abtastwerte einen vorgegebenen Teilsatz dieser elektrischen Signale umfassen.

4. System nach Anspruch 3, wobei dieser vorgegebene Teilsatz den elektrischen Signalen entsprechend aus mehreren Teilsätzen gewählt wird.

5. System nach Anspruch 3, wobei dieser vorgegebene Teilsatz einem vom Rechenzentrum empfangenen Steuersignal entsprechend aus mehreren Teilsätzen gewählt wird.

6. System nach Anspruch 1, wobei der Sender gespeicherte Abtastwerte überträgt, die über ein bestimmtes Zeitintervall hinweg erfaßt wurden, das das auslösende Ereignis umspannt.

7. System nach Anspruch 6, wobei die vom Sender übertragenen Abtastwerte einen vorgegebenen Teilsatz der elektrischen Signale umfassen.

8. System nach Anspruch 7, wobei die übertragenen Abtastwerte, die vor dem auslösenden Ereignis erfaßt wurden, einem ersten vorgegebenen Teilsatz der elektrischen Signale entsprechen, und die übertragenen Abtastwerte, die nach dem auslösenden Ereignis erfaßt wurden, einem zweiten vorgegebenen Teilsatz der elektrischen Signale entsprechen.

9. System nach Anspruch 8, wobei der zweite vorgegebene Teilsatz der elektrischen Signale einem Ursprung des auslösenden Ereignisses entsprechend festgelegt wird.

10. System nach Anspruch 1, wobei die Abtastwerte eine Betriebshistorie des Fahrzeugs zusammenfassen und das Rechenzentrum die Betriebshärte für verschiedene Systemkomponenten analysiert, um die Betriebslebensdauer diesen Abtastungen entsprechend zu projizieren.

11. System nach Anspruch 1, wobei die Betriebskomponenten elektronische Module mit jeweiligen Mikrocontrollern enthalten, und wobei die Abtastwerte Eingangs- und Ausgangssignale dieser Mikrocontroller enthalten.

12. System nach Anspruch 1, wobei die Betriebskomponenten elektronische Module mit jeweiligen Mikrocontrollern enthalten, und wobei die Abtastwerte Speicherinhalte in diesen Mikrocontrollern enthalten.

13. System nach Anspruch 1, wobei die Betriebskomponenten Sensoren und Stellantriebe umfassen, und wobei die Abtastwerte elektrische Signale von und zu diesen Sensoren und Stellantrieben umfassen.

14. System nach Anspruch 1, wobei die Betriebskomponenten elektronische Module mit jeweiligen Mikrocontrollern enthalten, und wobei das auslösende Ereignis in der Erkennung eines bestimmten Merkers besteht, das in einem dieser Mikrocontroller gesetzt ist.

15. System nach Anspruch 1, wobei die Betriebskomponenten elektronische Module mit jeweiligen Mikrocontrollern enthalten, und wobei das auslösende Ereignis in der Erkennung eines bestimmten Diagnosecode besteht, der in einem dieser Mikrocontroller gesetzt ist.

16. System nach Anspruch 1, wobei der Analysator mindestens einen Abtastwert mit einem bestimmten Schwellenwert vergleicht, und wobei das auslösende Ereignis diesem Vergleich entsprechend erzeugt wird.

17. System nach Anspruch 1, wobei der Analysator Abtastwerte, die im umlaufenden Puffer gespeichert sind, mit einem vorgegebenen Muster vergleicht, und wobei das auslösende Ereignis diesem Vergleich entsprechend erzeugt wird.

18. System nach Anspruch 17, wobei das vorgegebene Muster aus einem Histogramm besteht.

19. System nach Anspruch 1, wobei der Analysator einen zeitlichen Durchschnittswert eines bestimmten elektrischen Signals ermittelt, diesen Durchschnittswert mit einem bestimmten Durchschnittsschwellenwert vergleicht und das auslösende Ereignis diesem Vergleich entsprechend erzeugt.

20. System nach Anspruch 1, wobei der Analysator eine bestimmte Analyseroutine durchführt, um das auslösende Ereignis zu erkennen.

21. System nach Anspruch 20, wobei der Sender aus einem Sender- Empfänger besteht und wobei diese bestimmte Analyseroutine über den Sender-Empfänger aus dem Rechenzentrum ferngeladen wird.

22. System nach Anspruch 1, wobei das auslösende Ereignis einer abgelaufenen Zeitperiode entsprechend erkannt wird.

23. System nach Anspruch 2, außerdem umfassend eine Bedienerschnittstelle zur Anzeige von Meldungen aus dem Rechenzentrum, die einer Klassifikation der übertragenen Abtastwerte entsprechen.

24. System nach Anspruch 1, wobei das Rechenzentrum die Datenbank den übertragenen Abtastwerten entsprechend anpaßt, so daß diese angepaßte Datenbank von diesem Rechenzentrum zur künftigen Klassifikation für andere Ausrüstungen verwendet wird.