DE60026796T2

DE60026796T2 - Hybrides Diagnosesystem

Info

Publication number: DE60026796T2
Application number: DE60026796T
Authority: DE
Inventors: Meera Penfield Sampath; Ashok Pittsford Godambe; Eric Penfield Jackson; Edward W. Henrietta Mallow
Original assignee: Xerox Corp
Current assignee: Xerox Corp
Priority date: 1999-09-15
Filing date: 2000-09-15
Publication date: 2006-10-12
Anticipated expiration: 2020-09-16
Also published as: EP1085416B1; EP1085416A2; JP2001175328A; EP1085416A3; JP4878674B2; DE60026796D1; US6519552B1

Description

Gegenwärtige elektronische Systeme wie Drucker und Fotokopierer funktionieren, bis ein Funktionsfehler auftritt. Beim Auftreten eines oder mehrerer Funktionsfehler in einem Gerät zeigt ein entsprechender Sensor im Gerät eine Fehlermeldung auf beispielsweise einer Benutzeroberfläche an, welche darauf hinweist, dass eine überwachte Komponente ausgefallen ist. Diese Fehlermeldung enthält allgemeine Informationen mit Bezug auf die ausgefallene überwachte Komponente. Auf Grundlage des Inhalts dieser Fehlermeldung kann der Benutzer entweder versuchen, eine Reparatur selbst durchzuführen oder zum Beispiel den Kundendienstmechaniker kontaktieren, um eine Wartung des Gerätes einzuleiten.
Manders u.a.: „Signal Interpretation for Monitoring and Diagnosis, A Cooling System Testbed", in IMTC/99, Proceedings of the 16^th IEEE instrumentation and Measurement Technology Conference (cat. No. 99CH36309), Measurements for the New Millennium, Venedig, Italien (24.05.1999), Vol. 1, S. 498–503, beschreibt ein Verfahren für das Überwachen und die Diagnose dynamischer Systeme. Der Ansatz schließt die Interaktion zwischen einer qualitativen Diagnosemaschine, welche symbolische Eingabedaten benötigt, und einer Überwachungskomponente, welche ein Signal zur Symbolumwandlung an überwachte Signale gibt, ein.
Gleichermaßen beschreibt EP-A-0784240 einen bildgebenden Apparat mit einem funktionalen Redundanzsystem. Der Apparat ist mit Sensoren ausgestattet, welche quantitative Daten ausgeben, die dann in qualitative Symbole wie zum Beispiel „hoch", „normal" und „niedrig" umgewandelt werden. Diese werden verwendet, um Fehler zu diagnostizieren und entsprechende Reparaturen zu bestimmen.
Die oben genannten Systeme funktionieren gut für sensorüberwachte Komponenten. Die oben genannten Systeme können jedoch nicht bestimmen, welche Komponente ausgefallen ist, wenn die ausgefallene Komponente keine überwachte Komponente ist. Außerdem erkennen die oben genannten Systeme Funktionsfehler, nachdem sie aufgetreten sind, und sind nicht in der Lage, Funktionsfehler oder potentielle Funktionsfehler dynamisch in Echtzeit zu diagnostizieren. Dementsprechend erhöhen sich Reparaturzeit, Dienstleistungskosten und Geräteausfallzeiten, was zur Unzufriedenheit der Kunden führt.
Diese Erfindung stellt ein System bereit, welches eine Kombination aus qualitativen modellbasierten Schlussfolgerungen und quantitativen Analysetechniken in einem hybriden Diagnoseschema für das Diagnastizieren und Vorhersagen des Zustandes einer oder mehrerer Komponenten in einem oder mehreren elektronischen Systemen verwendet. Die quantitativen Schemata basieren auf der Analyse von Gerätedaten, welche zum Beispiel von herkömmlichen Überwachungsvorrichtungen empfangen werden. Dieses hybride Diagnoseschema ermöglicht die Diagnose und Vorhersage bis zur Ebene der einzelnen Komponenten mit kaum oder keinen zusätzlichen Sensoren außer denen, die für die normale Bedienung des Gerätes benötigt werden. Diese hybride Technologie ermöglicht einem elektronischen System die Fähigkeit der Selbstdiagnose, zum Beispiel in Vorgängen, bei denen Kundenaufträge durchgeführt werden, um zum Beispiel die Dienstleistungskosten zu verringern, Geräteeinsatzzeiten zu erhöhen und Kundenzufriedenheit zu verbessern. Alternativ kann das System dieser Erfindung auf jeder Stufe des Herstellungsprozesses oder der Nutzungszeit des Gerätes verwendet werden, um das Diagnostizieren von Funktionsfehlern bis zum Beispiel zur Ebene der einzelnen Komponenten, die direkt überwachte Komponenten sein können oder nicht, zu unterstützen.
In Übereinstimmung mit der vorliegenden Erfindung umfasst ein hybrides Diagnosesystem für die Vorhersage und Diagnose des Zustandes eines überwachten Systems
wenigstens einen Systemsensor, der so eingerichtet ist, dass er konkrete Systeminformationen erfasst;
wenigstens einen virtuellen Sensor, der so eingerichtet ist, dass er konkrete Systeminformationen verarbeitet und so Statusinformationen einer Komponente des überwachten Systems bestimmt, wobei der oder jeder virtuelle Sensor wenigstens ein Modul enthält, das so eingerichtet ist, dass es eine numerische Analyse konkreter Systeminformationen durchführt; und
eine diagnostische Interferenzvorrichtung, die so eingerichtet ist, dass sie Informationen von dem wenigstens einen Systemsensor und dem wenigstens einen virtuellen Sensor analysiert und den Zustand des Systems einschätzt;
wobei der oder jeder Systemsensor konkrete Systeminformationen, die direkt mit einem Systemereignis korrelieren, zu der diagnostischen Interferenzvorrichtung weiterleitet und der oder jeder virtuelle Sensor der diagnostischen Interferenzvorrichtung bestimmte Statusinformationen bereitstellt, die sich auf zusätzliche Systemereignisse beziehen.
Das System der Erfindung verbindet eine qualitative Einzelereignis-Systemdiagnosemethodik mit quantitativen Analysemethodiken, um ein hybrides Diagnoseschema zu erzielen, welches Echtzeit-Funktionsfehlerdiagnose und -vorhersage durchführen kann.
Die Erfindung bietet auch eine Kombination qualitativer modellbasierter Schlussfolgerungen und quantitativer Analyse in einem hybriden Diagnoseschema für das Diagnostizieren dokumentenverarbeitender Systeme wie beispielsweise Drucker, Fotokopierer, Scanner, Faxgeräte oder Ähnlicher.
Das Diagnosesystem dieser Erfindung ermöglicht die Konstruktion und Produktion intelligenter Selbstdiagnosegeräte. Im Speziellen überwacht und verfolgt das System Signaländerungen in einer oder mehreren Komponenten. Diese Überwachung kann in Echtzeit oder einem anderen vorgegebenen oder benutzerdefinierten Intervall stattfinden. Die Überwachung kann auch im normalen Betriebsmodus der Vorrichtung oder in einem speziellen Diagnosemodus stattfinden.
Das System dieser Erfindung verwendet eine Diagnosemethodik, welche das Arbeiten eines oder mehrerer Systeme überwacht, indem es in einem System auftretende „Ereignisse" wie beispielsweise Befehle, Kontrollsignale, Sensorlesungen, hohe oder niedrige Signalübergänge, Testergebnisse, Fehleridentifizierungssignale, Zähler, Parameteränderungen und ähnliches betrachtet. Basierend auf dem Auftreten dieser Ereignisse kann das Diagnosesystem Schätzungen über den Zustand des Systems erzeugen und von den Zustandsschätzungen den momentanen Betriebszustand des Systems wie zum Beispiel einen Fehler ableiten.
Da das Diagnosesystem dieser Erfindung auf einer hybriden Herangehensweise an Diagnose basiert, ist das Diagnosesystem in der Lage, mit zahlreichen Quellen der Diagnoseinformation umzugehen und den Zustand des Gerätes auf Basis einer oder mehrerer überwachter Signaländerungen und zusätzlicher Informationen von zum Beispiel einem oder mehreren virtuellen Sensoren einzuschätzen. Daher ist das Diagnosesystem nicht auf die Anzahl der Sensoren und/oder der virtuellen Sensoreingaben beschränkt. Die Verwendung von virtuellen Sensoren in den Systemen und Verfahren dieser Erfindung ergänzt Gerätesensoren und unterstützt die Ermöglichung einzelner Diagnosen auf Komponentenebene eines Gerätes, während die Notwendigkeit der Installation zusätzlicher Sensoren verringert oder ausgeschlossen wird.
Daher kann das Diagnosesystem ein oder mehrere Systeme automatisch verfolgen und mit mehreren Informationsquellen umgehen wie beispielsweise Sensoren, virtuellen Sensoren und Indikatoren. Des Weiteren kann das Diagnosesystem einen Gerätezustand wie beispielsweise einen Funktionsfehler, einen vermuteten Funktionsfehler oder einen vorhergesehenen Funktionsfehler mindestens bis zur ausgefallenen Komponente, wie beispielsweise eine durch den Außendienst ersetzbare Einheit oder eine durch den Kunden ersetzbare Einheit, identifizieren.
Im Besonderen übermitteln wenigstens ein Systemkontroller, Systemsensor und virtueller Sensor Informationen von einem oder mehreren Systemen oder zusätzlich von Untersystemen an einen Ereignisgenerator. Der Ereignisgenerator stellt Informationen von einem oder mehreren Systemen, Controllersensoren und/oder virtuellen Sensoren zusammen und generiert ein „Ereignis" auf Basis der empfangenen Informationen. Dieses Ereignis" wird dann an ein Diagnosesystem weitergeleitet. Beim Analysieren der Ereignisse kann das Diagnosesystem dann den Zustand des Systems einschätzen, zum Beispiel auf Basis eines endlichen Zustandsgerätemodells der einen oder mehreren Komponenten im System, eines einschränkungsbasierten Modells des Systems, eines regelbasierten Systems oder Ähnlichem. Der geschätzte Zustand, welcher den Zustand des Systems wiedergibt, wie beispielsweise normaler Zustand, Funktionsfehlermodus oder vorhergesehener Funktionsfehlermodus, kann dann auf einer oder mehreren Ausgabevorrichtungen ausgegeben werden. Außerdem können Informationen, die den Systemzustand betreffen, an mindestens einen oder mehrere Nutzer, Systembetreiber, War tungs- oder Kundenbetreuungseinheiten, einen unabhängigen Reparaturdienst, einen lokalen oder entfernten Bestimmungsort oder ein verteiltes Netzwerk wie das in der mitangemeldeten US Patentanmeldung Nr. 09/464597 beschriebene weitergeleitet werden.
Somit ist das hybride Diagnosesystem dieser Erfindung in der Lage, ein „Front-End" zum Beispiel für einen Diagnoseserver bereitzustellen, welcher wiederum eine entsprechende Maßnahme für die Übertragung spezieller Datentypen direkt oder indirekt an einen oder mehrere Kunden, autonome Reparaturdienste, Dienstleister und/oder Teile/Verschleißteilelieferanten bestimmen kann und/oder die entsprechende Unterstützung, Reparatur, Teile und/oder Lieferanten zur Bereitstellung der Systeme/des Systems, deren/dessen Funktionsfehler vorhergesagt wurde oder das ausgefallen ist, einleiten kann, damit diese die entsprechenden Informationen oder Teile für die Reparatur oder Wartung der Maschine zur Verfügung stellen.
Diese und andere Vorteile dieser Erfindung werden beschrieben in oder gehen hervor aus der folgenden detaillierten Beschreibung der bevorzugten Ausführungsbeispiele.
Die bevorzugten Ausführungsbeispiele dieser Erfindung werden im Detail mit Bezug auf die folgenden Figuren beschrieben, wobei:
1 ein funktionales Blockdiagramm ist, welches das erste Ausführungsbeispiel des Diagnosesystems entsprechend dieser Erfindung zeigt;
2 ein funktionales Blockdiagramm darstellt, welches ein zweites Ausführungsbeispiel des Diagnosesystems entsprechend dieser Erfindung zeigt;
3 ein funktionales Blockdiagramm darstellt, welches ein drittes Ausführungsbeispiel des Diagnosesystems entsprechend dieser Erfindung zeigt;
4 ein exemplarisches Arbeitsablaufdiagramm für die Entwicklung eines Diagnosesystems entsprechend dieser Erfindung zeigt;
5 ein exemplarisches überwachtes System entsprechend dieser Erfindung zeigt;
6 ein detailliertes funktionales Blockdiagramm des exemplarischen überwachten Systems in 5 zeigt;
7 ein exemplarisches Arbeitsablaufdiagramm für das exemplarische überwachte System in 6 zeigt;
8 eine exemplarische Ausgabe des Ereignisgeneratorsystems für das exemplarische System in 6 zeigt;
9 ein exemplarisches Arbeitsablaufdiagramm für das Erstellen der Sortiermaschine für das exemplarische System in 6 zeigt;
10 ein exemplarisches Arbeitsablaufdiagramm der Bedienung der Sortiermaschine für das in 6 gezeigt exemplarische System zeigt;
11 Teil eines exemplarischen Diagnosesystems für das exemplarische System in 6 zeigt; und
12 ein Ablaufdiagramm ist, welches ein erstes exemplarisches Ausführungsbeispiel des Verfahrens für Diagnosesysteme entsprechend dieser Erfindung skizziert.
Das System dieser Erfindung kann durch die Verwendung einer hybriden Diagnosemethodik die benötigten Daten ermitteln und verarbeiten, um den Betriebszustand einer oder mehrerer Komponenten in einem Gerät, wie zum Beispiel einem Drucker, Fotokopierer oder jedem anderen System, für welches das Ermitteln von Zustandsdaten in Bezug auf das System benötigt wird, zu bestimmen. Daher kann das System dieser Erfindung ein „Front-End" bereitstellen, welches das Ermitteln, Verarbeiten und Weiterleiten vielfältiger Zustandsdatentypen zwischen vielen Endnutzern, Wartungs-/Teilelieferanten und/oder einem oder mehreren Diagnoseservern und sekundären Informationsquellen ermöglicht, um Dienstleistungen und/oder Teile für ein oder mehrere überwachte Systeme vorherzusagen, zu diagnostizieren, zu reparieren, zu planen und/oder zu versenden.
1 zeigt einen Systemüberblick des hybriden Diagnosesystems 1 entsprechend dieser Erfindung. In diesem exemplarischen Ausführungsbeispiel ist das System 5, welches überwacht wird, getrennt von Diagnosesystem. Es ist jedoch anzuerkennen, dass sich die verschiedenen Komponenten, die in Verbindung mit dem System dieser Erfindung beschrieben werden, überall befinden können, einschließlich innerhalb der eigentlich überwachten Vorrichtung oder des überwachten Systems, auf einer zugehörigen Diagnosevorrichtung, welche mit dem System 5 über beispielsweise eine oder mehrere drahtlose oder Drahtverbindungen verbunden ist, wie zum Beispiel ein Netzwerk, das Internet, ein Intranet oder jede andere bekannte oder zukünftig entwickelte Verbindung, die Informationen zwischen den angeschlossenen Komponenten übertragen kann, oder jede mögliche Kombination daraus. Das hybride Diagnosesystem 1 umfasst einen Systemcontroller 20, einen oder mehrere Systemsensoren 30, einen oder mehrere virtuelle Sensoren 100, einen Ereignisgenerator 200, ein Diagnosesystem 300 und eine Ausgabevorrichtung 400.
Der Systemcontroller 20, die Systemsensoren 30 und/oder die virtuellen Sensoren 100 sammeln Informationen in Bezug auf den Zustand des Systems 5 und leiten diese an den Ereignisgenerator 200 weiter. Im Speziellen leitet der Systemcontroller 20 Daten wie zum Beispiel Befehle, die beispielsweise vom System und Untersystemcontrollern ausgegeben werden, nicht gezeigt, Bedienteilsignale, Sollwertsignale, Planungs- und Zeitdaten, Auftragsinformationen, Gerätebedienmodus oder Ähnliches an den Ereignisgenerator 200. Die Kontrollbefehle können als Teil einer Echtzeitbedienung des Systems ausgegeben werden oder können spezielle Befehle sein, die in einem speziellen Testmodus oder Diagnosemodus ausgegeben werden. Zusätzlich leiten die Systemsensoren 30 Daten an den Ereignisgenerator 200 weiter, einschließlich Kontrolldaten wie Signaländerungen als Antwort auf Kontrollbefehle und/oder Testbefehle, Ablaufkontrolldaten oder Ähnliches, Überwachungsdaten wie Ausgaben von speziellen Diagnosesensoren und Zählern, Signaländerungen als Antwort auf Funktionsfehler, Abnutzungsinformationen, Fehlerinformationen, Statusinformationen oder Ähnliches und Umgebungs/Bedienungsdaten wie Temperaturinformationen, Luftfeuchtigkeitsinformationen oder Ähnliches. Die Sensorensignale können analog oder digital sein und können als Teil der normalen Bedienung des Systems generiert werden oder als Antwort auf spezielle Befehle in speziellen Testmodi oder Diagnosemodi ausgegeben werden.
Die virtuellen Sensoren/der virtuelle Sensor 100 stellt dem Ereignisgenerator Diagnoseinformationen über analytische Mittel bereit, das heißt durch eine quantitative und/oder qualitative Verarbeitung der eigentlichen Systeminformationen. Die virtuellen Sensoren ergänzen die von dem einen oder mehreren Systemcontrollern 20 und dem Sensor 30 bereitgestellten Informationen. Im Speziellen helfen der eine oder mehrere virtuelle Sensoren 100 beim Filtern der Diagnose, welche unter Verwendung der vom Systemcontroller 20 und dem Systemsensor 30 erhaltenen Daten durchgeführt werden kann, um zum Beispiel speziellen Komponenten innerhalb des Systems 5, die eventuell direkt überwacht werden oder nicht, eine Fehlerisolierung bereitzustellen. In anderen Worten „füllen" die virtuellen Sensoren „die Lücken", um die von den „fest verdrahteten" Systemsensoren bereitgestellten Informationen zu ergänzen. Für den virtuellen Sensor 100 gibt es eine Vielfalt verschiedener Auswahlmöglichkeiten. Das einfachste Beispiel eines virtuellen Sensors 100 ist ein Zähler. Zähler werden beispielsweise sehr häufig für Diagnosezwecke in Druckermaschinen verwendet. Alternativ kann der virtuelle Sensor auf einem Grenzwertanalyseaufbau basieren. Für die Grenzwertanalyse wird ein Signal vom System 5 mit einem vorgegebenen Wert verglichen um zu bestimmen, ob der Wert eine obere oder untere Grenze über- beziehungsweise unterschritten hat. Diese Vergleichsinformation kann dann analysiert werden, um nützliche Diagnoseinformationen in Bezug auf den Zustand des Systems 5 bereitzustellen. Alternativ kann der virtuelle Sensor 100 auf einem Signaturanalysemodell basieren. Hierbei unterliegen jegliche relevanten Systemsignale und/oder Daten, wie ein Grundstrom, ein Bedienteilsignal oder ähnliches einer Signaturanalyse, so dass die Merkmale, welche nützliche Diagnoseinformationen enthalten, extrahiert werden können. Des Weiteren kann die virtuelle Sensortechnologie 100 auf einer statistischen Analyse der vom System 5 erhaltenen Daten basieren. Zum Beispiel sind Durchschnitts- und Abweichungsanalysen, statistische Schätzungen und ähnliches oft nützliche Diagnoseindikatoren. Alternativ kann der virtuelle Sensor auf Trendanalyse, Zeitanalyse und Ratenanalyse basieren. Alternativ kann der virtuelle Sensor auf Berechnungstechniken wie linearer Algebra, Differenzialrechnung, qualitativer Rechnung, logischen Gleichungen, topologischer Analyse und Ähnlichem basieren.
Schließlich kann der virtuelle Sensor 100 auch auf Bildqualitätsanalysetechniken basieren. In diesem Fall unterliegt das Ausgabebild von zum Beispiel einem Drucker oder Fotokopierer einer Bildqualitätsanalyse und/oder einer Defekterkennungsanalyse. Die aus dieser Analyse resultierenden Maße können dann an einen Ereignisgenerator 200 wei tergeleitet werden, um die Bestimmung des Zustands des Systems 5 zu unterstützen. Ebenso wie Sensorsignale können virtuelle Sensorsignale als Teil der normalen Bedienung des Systems generiert werden oder als Antwort auf spezielle Befehle in speziellen Testmodi oder Diagnosemodi ausgegeben werden.
Der Ereignisgenerator 200 erfasst und analysiert einen oder mehrere Datentypen, die vom Systemcontroller 20, dem Systemsensor 30 und dem virtuellen Sensor 100 ankommen. Der Ereignisgenerator 200 kann fortlaufend oder für einen vorgegebenen Zeitabschnitt arbeiten, um Daten, welche von den verschiedenen Sensoren, virtuellen Sensoren und/oder Controllern erhalten wurden, zu sammeln und optional zu speichern. Der Ereignisgenerator überträgt diese Daten in ein vom Diagnosesystem 300 erkennbares Format. Diese Übertragung kann zum Beispiel die Diskretisierung der von einem oder mehreren Sensoren empfangenen Daten in qualitative Werte einschließen. Alternativ kann diese Übertragung das Übertragen von Gerätesignalen in einzelne Ereignisabfolgen einschließen, zum Beispiel durch Erkennen spezieller Signalübergänge wie einen Übergang von hoch zu niedrig, an zu aus oder Ähnliches.
Alternativ kann der Ereignisgenerator die Ergebnisse spezieller Systemtests, wie entsprechend formatierte Durchgangs- und Ausfallwerte an das Diagnosesystem 300 weiterleiten. Schließlich kann der Ereignisgenerator 200 die Ergebnisse der virtuellen Sensoranalyse für das Diagnosesystem 300 in ein qualitatives Format übertragen. Die vom Ereignisgenerator weitergeleiteten Daten können zeitlich nicht festgelegte oder mit einer Zeitangabe versehene Daten sein, abhängig von der Art und den Anforderungen des Diagnosesystems 300. Daher überträgt der Ereignisgenerator 200 die Daten von einem oder mehreren Sensoren, virtuellen Sensoren und Controllern in einzelne Ereignisse, welche der Bedienung des Systems 5 entsprechen. Um diese Ereignisse in der entsprechenden Abfolge an das Diagnosesystem weiterzuleiten, werden die Signalübergänge, die von Interesse sind, beispielsweise die verschiedenen Befehle und Sensoränderungen und deren Reihenfolge des Auftretens, die Testabfolge und das Anfordern der virtuellen Sensorausgaben zum Beispiel in einer Tabelle vorgegeben, auf welche sich zu Beginn eines Diagnoselaufs bezogen wird. Diese Tabelle beinhaltet beispielsweise eine Liste der „Ereignisse", die vom Diagnosesystem 300 erkannt werden.
Das Diagnosesystem 300 analysiert dann die einzelnen vom Ereignisgenerator 200 bestimmten Ereignisse und schätzt einen Zustand des Systems 5 auf Basis dieser Ereignisse ab. Dieser geschätzte Zustand spiegelt den Zustand des Systems wieder, wie beispielsweise normaler Zustand, Funktionsfehlermodus oder vorhergesagter Funktionsfehlermodus. Das Diagnosesystem basiert auf qualitativen Schlussfolgerungsschemata wie modellbasierte Schlussfolgerung, Systemdiagnosetechnologie einzelner Ereignisse, Bedingungsprogrammierung, Bayessche Netzwerke, Kausalnetzwerke, neuronale Netzwerke, Expertensysteme und Ähnliches. Im Speziellen kann die Diagnosemaschine, welche auf einzelnen Ereignissystemen basiert, entwickelt und gebaut werden wie beschrieben in „Diagnosibility of Discrete Event System," IEEE Trans. Automatic Control, 40(9): 1555–1575, September 1995 und in „Failure Diagnosis Using Discrete Event Models," IEE Trans. Control Systems Technology, 4(2): 105–124, März 1996, beide von M. Sampath und andere. Die Ausgabe des Diagnosesystems, zum Beispiel ein Funktionsfehlermodus, kann dann auf einer Ausgabevorrichtung 400, wie einer Benutzeroberfläche, einer lokalen oder entfernten Überwachungsstelle oder Benutzeroberfläche, einem Wartungstechniker, einem Teilelieferant, einer Internetseite, einer E-Mail-Adresse oder Ähnlichem, ausgegeben werden. Alternativ oder zusätzlich kann die Ausgabe des Diagnosesystems an ein Reparaturplanungsmodul weitergegeben werden, welches gemäß des Funktionsfehlers über den entsprechenden Reparaturvorgang entscheidet. Der Reparaturvorgang kann eines oder mehreres oder eine Kombination sein von Kundenreparatur, Platzierung eines Wartungsanrufs und/oder autonome Reparatur ausgeführt durch beispielsweise einen Reparaturbeauftragten. Die Ausgabe des Reparaturplanungsmoduls 500 kann zum Beispiel eine Nachricht „Teil ersetzen" an den Kunden sein oder es kann das Durchführen eines automatisierten Konfigurationsvorgangs sein. Sobald der Reparaturvorgang festgelegt ist, wird die Ausgabe des Reparaturplanungssystems an den entsprechenden Empfänger umgeleitet, wie in der mitangemeldeten US Patentanmeldung Nr. 09/464,597 beschrieben.
2 zeigt ein Blockdiagramm eines hybriden Diagnosesystems mit einer Reihe von speziellen Beispielen der virtuellen Sensortechnologien. Im Speziellen umfasst das hybride Diagnosesystem das Diagnosesystem 300, den Ereignisgenerator 200, einen oder mehrere virtuelle Sensoren 100, das System 5 und einen oder mehrere Sätze von Datenströmen vom System 5 zu den virtuellen Sensoren 100, wie der analoge Datenfluss 1050 und der digitale Datenfluss 1060. Die virtuellen Sensoren 100 können ein oder mehrere oder eine Kombination sein von einem Signaturanalysemodul 1005, einem Grenzwertanalysemodul 1015, einem Ratenanalysemodul 1020, einem quantitativen Zustandsschätzmodul 1025, einem Kontrollabfolgeüberwachungsmodul 1030, einem Grenzwertanalysemodul 1035, einem Ereigniszählermodul 1040 und einem Zeitmodul 1045.
Das Signaturanalysemodul 1005 analysiert von dem analogen Signalfluss 1050 empfangene Signale und kann zum Beispiel erkannte Signale mit gespeicherten Signalsignaturen vergleichen oder vorgegebene Parameter des Signals berechnen. Die Signaturanalyse kann entweder an den vom analogen Datenfluss empfangenen Rohsignalen stattfinden oder zum Beispiel an einer Gruppe vorgegebener Eigenschaftsvariablen, die aus den Rohsignalen extrahiert wurden. Das statistische Analysemodul 1010 empfängt von dem analogen Datenfluss 1050 ein oder mehrere analoge Signale und bestimmt, basierend auf statistischer Analyse, Eigenschaften des Datenstroms/der Datenströme wie beispielsweise Mittelwerte, Abweichungen, Weißmessungen oder ähnliches. Das Grenzwertanalysemodul 1015 gewinnt Zustandsinformationen auf Basis eines Vergleichs der empfangenen Daten mit den Grenzwerten. Der Ratenanalysesensor 1020 überwacht die Änderungsrate, wie eine Erhöhung/Verringerung eines Wertes einer oder mehrerer Systemvariablen. Das quantitative Zustandsschätzmodul 1025 kann zum Beispiel auf den analytischen redundanzbasierten Schemata wie Luenberger-Beobachtern, robusten Beobachtern, Kalman-Filtern, Fehlerdiagnosefiltern, Parity-Space-Ansätzen, Parameterschätztechniken oder Ähnlichen basieren. Der Kontrollabfolgeüberwachungssensor 1030 überwacht Systemkontrollbefehle und bestimmt zum Beispiel Befehle außerhalb des Ablaufs oder fehlende Befehle. Der Grenzwertanalysesensor 1035 erhält Zustandsinformationen auf Basis eines Vergleichs der empfangenen Daten mit Grenzwerten. Der Ereigniszählersensor 1040 zählt Systemereignisse und der Zeitsensor 1045 überwacht und analysiert die zeitliche Planung von Ereignissen im System 5.
3 zeigt ein anderes Beispiel eines Diagnosesystems entsprechend dieser Erfindung. Dieses veranschaulichende Ausführungsbeispiel umfasst das System 5, einen oder mehrere Systemsensoren 30, einen virtuellen Sensor, hier einen Zustandsschätzer 100, einen Rückmeldungscontroller 95, den Ereignisgenerator 200 und das Diagnosesystem 300. Im Speziellen stellt dieses Ausführungsbeispiel die Interaktion eines ge schlossenen Regelsystems mit statistischer Zustandsschätzung auf Basis von virtuellen Sensoren wie beispielsweise Kalman-Filtern dar.
4 ist ein exemplarisches Ablaufdiagramm, welches die Entwicklung des Systemmodells und des Diagnosesystems entsprechend dieser Erfindung zeigt. Im Speziellen werden Komponentenmodelle, Controllermodelle und eine oder mehrere Funktionsfehlermerkmaltabellen zusammengestellt, um ein Systemmodell zu generieren. Die Komponentenmodelle erfassen die verschiedenen Abläufe der Kontrollbefehle, welche als Teil der normalen Bedienung des Systems ausgegeben werden oder alternativ während eines Spezialtests oder eines Diagnosemodus der Bedienung. Es wird darauf hingewiesen, dass das Controllermodell optional ist und eventuell nicht nötig ist für die explizite Formung des Controllers, abhängig vom Entwurf und der Umsetzung des Diagnosesystems. Die Funktionsfehlermerkmaltabelle listet die Ausgaben der Sensoren und virtuellen Sensoren auf, die vom Diagnosesystem für die verschiedenen Fehlfunktionsmodi ebenso wie für den normalen Modus der Bedienung des Systems verwendet werden. Dieses Systemmodell wird dann gemeinsam mit einer Auflistung der Diagnoseanforderungen verwendet, um die Diagnoseobertlächenmaschine zu generieren. Die Diagnoseanforderungen legen die Auflösung fest, mit der die Funktionsfehler diagnostiziert werden sollen, so zum Beispiel ob jeder Fehler einzeln diagnostiziert werden soll, oder ob es genügt festzustellen, ob einer aus einer Gruppe von Funktionsfehlern aufgetreten ist. Im Speziellen werden im Fall des einzelnen Ereignissystemdiagnoseansatzes die Generierung des Systemmodells und der Diagnosemaschine entsprechend den Algorithmen durchgeführt, die in „Diagnosibility of Discrete Event Systems," IEE Trans. Automatic Control, 40(9): 1555–1575, September 1995 und in „Failure Diagnosis Using Discrete Event Models," IEEE Trans. Control Systems Technology, 4(2): 105–124, März 1996, beide von M. Sampath und andere beschrieben werden. Es wird außerdem darauf hingewiesen, dass die Diagnosemaschine direkt aus den Komponentenmodellen, den Controllermodellen und Funktionsfehlermerkmaltabellen aufgebaut werden kann, ohne die Zwischenphase der Generierung des Systemmodells.
5–11 stellen dar, wie das System entsprechend dieser Erfindung in einem einfachen exemplarischen elektronischen System arbeitet. Im Besonderen ist das exemplarische elektronische System ein Drucker oder ein Fotokopierer und das diagnostizierte Untersystem ist ein Papiervorschubbauteil in dem Drucker oder Fotokopierer.
Im Speziellen stellt 5 ein exemplarisches funktionales Blockdiagramm des Papiervorschubsystems mit einem eingebauten Diagnosesystem dar. In diesem Fall sind die vom Systemcontroller ausgegebenen Kontrollbefehle die Befehle an und aus zum Drehen eines Vorschubmotors, welcher die verschiedenen Papiervorschubsystemkomponenten antreibt, eines Hebemotors, welcher den Papierstapel im Papierschacht hebt, und eines Aufnahmemagneten, welcher die Papierzufuhr kontrolliert. Die Sensoren im System sind ein Wartestationssensor, welcher das Ankommen von Papier erkennt, und ein Stapelhöhensensor, welcher die Höhe des Papiers in den Papierschächten prüft. Zwei Arten sind virtuelle Sensoren, die in diesem System verwendet werden. Der eine ist ein Datenextraktions- und Diskriminanzanalyse basierter virtueller Sensor und der zweite ist eine Gruppe von Zählersensoren. Ein Zähler verfolgt die Ablesungen des Stapelhöhensensors über aufeinanderfolgende Papiervorschübe und der andere Zähler verfolgt die Anzahl der eingezogenen Blätter. Die diagnostizierten Funktionsfehler beinhalten blockierte Motoren, defekte oder schwache Magneten, beschädigte Vorschubrollen und das Fehlen von Papier.
6 stellt das Diagnosesystem aus 5 detaillierter dar. Wie zuvor in Bezug auf 5 beschrieben beinhaltet das Drucksystem 10 ein Papiervorschubuntersystem 21, einen Papiervorschubsystemcontroller 31 und Papiervorschubsystemsensoren 40. Zusätzlich umfasst der Diagnoseabschnitt des Systems 10 ein virtuelles Sensorsystem 100, ein Ereignisgeneratorsystem 200, ein Diagnosesystem 300 und eine Ausgabevorrichtung 400, welche alle über Verbindungen 50 miteinander verbunden sind.
Die Verbindungen 50 können drahtlose oder Drahtverbindungen oder jede anderen bekannten oder zukünftig entwickelten Elemente sein, welche elektronische Daten an die und von den verbundenen Elementen zur Verfügung stellen können.
Das virtuelle Sensorsystem 100 umfasst eine Datensammelvorrichtung 110, eine Datenextraktionsvorrichtung 120, eine Diskriminanzanalysevorrichtung 130, eine Basisspitzenstrom-Erkennungsschaltung 140, eine Energiespektralamplituden-Bestimmungsschaltung 150, eine Klassifiziererschaltung 160, einen Papiervorschubzähler 170 und einen Stapelhöhensensorzähler 180.
Das Ereignisgeneratorsystem 200 umfasst eine Kontrolldatenübertragungsschaltung 210, eine Sensordatenübertragungsschaltung 220, eine virtuelle Sensorübertragungsschaltung 230 und eine Ereignisablaufsteuerungsschaltung 240. Das Diagnosesystem 300 umfasst einen Controller 310, einen I/O Controller 320, einen Zustandsschätzer 330 und einen Systemzustandsinformationenassembler 340.
Wie bereits beschrieben werden die Informationen von den Papiervorschubsystemcontrollern 30, den Papiervorschubsystemsensoren 40 und den virtuellen Sensoren 100 an das Ereignisgeneratorsystem 200 weitergeleitet. Somit werden Informationen, aus denen „Ereignisse" direkt korreliert werden können, direkt an das Ereignisgeneratorsystem 200 weitergeleitet.
Informationen von den Sensoren 40 und zusätzlich dazu vom Erdrückstrom, welcher eine Gesamtsumme des Stroms ist, der von allen Komponenten des Papiervorschubsystems bezogen wird, werden an die virtuelle Sensorvorrichtung 100 weitergeleitet, um zusätzliche System-„Ereignisse" zu generieren, welche von den Systemcontrollern und -sensoren eventuell direkt erkennbar sind oder nicht. Die Datensammelvorrichtung 110 verfolgt und speichert diese Informationen. Mit den ermittelten Daten und für eine erweiterte Bestimmung des Systemzustands werden der Papiervorschubzähler 170, der Stapelhöhensensorzähler 180, die Datenextraktionsvorrichtung 120 und die Diskriminanzanalysevorrichtung 130 verwendet, um die Informationen mit Bezug auf den Systemzustand, welche von einem oder mehreren Systemcontrollern 20 und Systemsensoren 30 nicht einfach verfügbar sind, zu extrahieren. Der Stapelhöhensensorzähler 180 verfolgt die Ablesungen des Stapelhöhensensors über aufeinanderfolgende Papiervorschübe und der Papiervorschubzähler 170 verfolgt die Anzahl der eingezogenen Blätter, indem er einen Wartestationssensor über aufeinanderfolgende Vorschübe überwacht.
Erläuternd umfasst die Datenextraktionsvorrichtung 120 die Basisspitzenstrom-Erkennungsschaltung 140 und die Energiespektralamplituden-Bestimmungsschaltung 150. Es sollte jedoch beachtet werden, dass alternative Merkmale, wie Stromspektralfrequenzen, Ergebnisse von Vibrationssignalanalysen, Zeitfrequenzsignalen und Ähnlichen an Stelle oder in Verbindung mit der Basisspitzenstrom-Erkennungsschaltung 140 und der Energiespektralamplituden-Bestimmungsschaltung 150 verwendet werden können, ohne die Funktionsweise des virtuellen Sensorsystems 100 zu beeinflussen. In die sem erläuternden Beispiel übernacht und speichert die Basisspitzenstrom-Erkennungsschaltung 140 zum Beispiel den Basisspitzenstrom, der von den Komponenten des Papiervorschubsystems bezogen wird. Zusätzlich überwacht die Energiespektralamplituden-Bestimmungsschaltung 150 die Energiespektralamplituden des Grundstroms, der von den Komponenten des Papiervorschubsystems bezogen wird, und stellt diese zusammen. Wenn das gewünschte Merkmal/die gewünschten Merkmale extrahiert wurden, werden die Merkmale an die Diskriminanzanalysevorrichtung 130 weitergeleitet.
Wie bereits beschrieben werden der Basisspitzenstrom und die Energiespektralamplitude auf Grund der einfachen Berechnung dieser Merkmale und der leichten Zuordnung der Merkmale zu den entsprechenden Funktionsfehlermodi des Systems zur Verdeutlichung gewählt. Jegliche Zuordnung muss jedoch die statistischen Abweichungen in den Merkmalwerten in Betracht ziehen, die während der Bedienung des Systems auftreten. Daher werden vorzugsweise multivariate Diskriminanzanalysen in der Diskriminanzanalysevorrichtung 130 durchgeführt. Eine Diskussion der multivariaten Analyse findet sich in T.W. Anderson, An Introduction to Multivariate Statistical Analysis, John Wiley & Sons 1984 und in D. Morrison, Multivariate Statistical Methods, McGraw Hill, 1976.
Die Diskriminanzanalysevorrichtung 130 umfasst normalerweise eine Klassifiziererschaltung. In diesem erläuternden Beispiel wird als Klassifizierer ein quadratischer Klassifizierer 160 gewählt. Die Diskriminanzanalysevorrichtung kann jedoch auf jeder der bekannten multivariaten Analysetechniken basieren. Im Speziellen gibt es eine Reihe alternativer Algorithmen für die Erstellung des Klassifizierers, welche sich im Klassifizierungsalgorithmus unterscheiden und auch in Verbindung mit dem System dieser Erfindung verwendet werden können, ohne dessen Funktionseigenschaften zu beeinträchtigen. Siehe zum Beispiel R. Duda u.a., Pattern Classification and Scene Analysis, John Wiley & Sons, 1973 und außerdem Anderson und Morrison, wie oben zitiert. Beispiele beinhalten, sind jedoch nicht beschränkt auf lineare Klassifizierer, logistische Regression, Hauptkomponentenanalyse, Bayes Klassifizierer und Ähnliche.
Der quadratische Klassifizierer 160 arbeitet auf Basis von Klassifiziererparametern, welche zum Beispiel die Gesamtanzahl der Cluster, deren entsprechende Identifikationsnummern, die Mittel- und Kovarianzmatrizen der Cluster und eine parametrische Kon stante für jedes Cluster beinhalten. Im Allgemeinen analysiert die Diskriminanzanalysevorrichtung 130 die von der Datenextraktionsvorrichtung 120 zusammengestellten Daten und klassifiziert die Merkmalgruppe in eines der gegebenen Cluster, basierend auf der Entfernung der gegebenen Samplegruppe der Merkmale, von der Region oder dem Cluster, welches von jeder Gruppe im multidimensionalen Raum gebildet wird, der durch die Merkmalvariablen umspannt wird. Der Sample Point wird dann in das Cluster mit der nächsten Nähe klassifiziert. Im Fall des virtuellen Sensorsystems 100 entsprechen die Cluster den verschiedenen Zuständen, zum Beispiel Funktionsfehler, Modi. Der Clustername oder die Clusternummer sind die Ausgabe des virtuellen Sensorsystems 100. Dieses Cluster wird dann vom Ereignisgeneratorsystem 200 in ein „Ereignis" übertragen.
Das Ereignisgeneratorsystem 200 überträgt die verschiedenen von den Systemsensoren, Controllern, und virtuellen Sensoren erhaltenen Informationen und überträgt diese Informationen in einzelne Ereignisse oder Vorkommnisse, die von dem Diagnosesystem 300 erkannt werden können. Im Besonderen empfängt die Kontrolldatenübertragungsschaltung 210 Daten von einem oder mehreren Systemcontrollern, die Sensordatenübertragungsschaltung 220 empfängt Daten von einem oder mehreren System Sensoren 30 und die virtuelle Sensordatenübertragungsschaltung 230 empfängt Daten von einem oder mehreren virtuellen Sensoren wie 100. Das Ereignisgeneratorsystem 200 vergleicht diese Informationen beispielsweise mit einer Nachschlagetabelle für die Übertragung der Daten in „einzelne Ereignis-" Daten. Die Ereignisablaufsteuerungsschaltung 240 steuert die Abläufe der verschiedenen Ereignisse und leitet diese in der richtigen Reihenfolge an das Diagnosesystem 300 weiter.
Das Diagnosesystem 300 wertet die vom Ereignisgeneratorsystem 200 weitergeleiteten einzelnen Ereignisse aus, um eine entsprechende Gerätezustandsinformation zu generieren. Das Diagnosesystem basiert auf qualitativen Modellen des Systems, wobei die qualitativen Informationen über die „Ereignisse" bereitgestellt werden. Das Diagnosesystem basiert auf einer oder mehreren verschiedenen Technologien, wie Systemdiagnosetechnologie für einzelne Ereignisse, modellbasierte Schlussfolgerung, Bayes Rückschluss, Constraint-basierte Programmierung, neuronale Netzwerke und Kausalnetzwerke. Normalerweise können zwei Ansätze für die Erstellung und Umsetzung des Diagnosesystems 300 verfolgt werden. Im ersten Ansatz werden ein oder mehrere Komponentenmodelle, Controllermodelle und Funktionsfehlersystemtabellen in Verbindung mit Diagnoseanforderungen verwendet, um eine Diagnoserückschlussmaschine zu generieren, welche dann im Speicher des Diagnosesystems 300, wie beispielsweise in einer Nachschlagetabelle oder einem regelbasierten System, gespeichert wird. Zum Zeitpunkt der eigentlichen Diagnose findet das Rückschließen einfach durch Aktualisierung des Zustands der Rückschlussmaschine statt, auf Basis der durch das Ereignisgeneratorsystem 200 generierten „Ereignisse". Alternativ kann entweder das gesamte Systemmodell oder die Komponentenmodelle und die Funktionsfehlersystemtabellen im Speicher des Diagnosesystems 300 gespeichert und die Diagnoseberechung online durchgeführt werden, so wie „Ereignisse" von dem Ereignisgeneratorsystem 200 empfangen werden. In anderen Worten kann die Diagnoserückschlussmaschine schrittweise während des Diagnosevorgangs generiert werden.
Die Statusinformationsausgabe vom Diagnosesystem kann zum Beispiel anzeigen, ob das Gerät normal funktioniert, das heißt, es gibt keinen Fehler, ob bestimmte Funktionsfehler aufgetreten sind, oder ob der Verdacht besteht, dass Funktionsfehler aufgetreten sind, oder ob das Auftraten von Funktionsfehler vorhergesehen wird. Nach der Bestimmung des aktuellen Zustandes des Systems stellt der Systemzustandsinformationenassembler 340 eine entsprechende Nachricht zusammen, welche über die Verbindung 50 an die Ausgabevorrichtung 400 übertragen wird.
Die Ausgabevorrichtung 400 kann ein lokales Ausgabeanzeigemodul, wie zum Beispiel eine Benutzeroberfläche, für das Anzeigen der Zustandsinformations- oder Funktionsfehlerinformationsausgabe an das Diagnosesystem 300 sein. Die Ausgabevorrichtung 400 kann beispielsweise eine Benutzeroberfläche sein, welche einen H-Pegel-Zustandsindikator und eine Funktionsfehlerliste anzeigt. Der H-Pegel-Indikator, welcher mit einer entsprechenden Farbe ausgestattet oder hörbar hervorgehoben werden kann, gibt den aktuellen Gerätestatus an. Der Zustand kann zum Beispiel normal, vermuteter Funktionsfehler oder bestimmter Funktionsfehler sein. Die Funktionsfehlerliste zeigt sowohl vermutete als auch sichere Funktionsfehler zum Beispiel in separaten Kategorien auf der Benutzeroberfläche an. Alternativ kann die Ausgabevorrichtung 400 ein entferntes Anzeigemodul bei den Empfängern der Diagnoseinformation und des Kommunikationskanals sein, wie in der mitangemeldeten US Patentanmeldung Nr. 09/464597 beschrieben.
7 stellt ein exemplarisches Ablaufdiagramm dar, welches in Verbindung mit dem System in 6 steht. Die Kontrolle beginnt in Schritt S10, wo der Druck- und/oder Kopierauftrag begonnen wird. Als nächstes werden in Schritt S20 die Vorschubsystemkontrollbefehle und Sensorsignaländerungen ermittelt. Zusätzlich werden in Schritt S50 die Stromproben der Erdrückleitung ermittelt. Dann werden in Schritt S30 die Kontroll- und/oder Sensorsignale analysiert, um Ereignisse zu erhalten, wie die in der exemplarischen Ereignisgeneratorsystemausgabe in 8 festgelegten. In der Zwischenzeit extrahiert der virtuelle Sensor in Schritt S60 illustrativ den Basisspitzenstrom und die Energiespektralamplitudeneigenschaften aus den Stromproben der Erdrückleitung. Dann werden in Schritt S70 die extrahierten Eigenschaften in eines einer vorgegebenen Anzahl von Clustern klassifiziert, indem zum Beispiel festgelegte Klassifizierparameter und Ausgabeklassifiziernummern verwendet werden.
In Schritt S40 kombiniert der Ereignisgenerator die Kontroll- und/oder Sensorereignisse mit der Klassifiziererausgabe in einer von der Diagnosesystemspezifikation vorgegebenen Reihenfolge. Diese Ereignisse werden dann in Schritt S80 an das Diagnosesystem weitergegeben. Als nächstes wird in Schritt S90 der Zustand des Systems durch das Diagnosesystem auf Basis der Ereignisse bestimmt. Dann werden in Schritt S100 die Zustandsinformationen oder Funktionsfehler, welche durch das Diagnosesystem bestimmt wurden, ausgegeben.
8 stellt eine exemplarische Ausgabe des Ereignisgeneratorsystems für den exemplarischen Papiervorschubaufbau dar. Im Speziellen umfasst die Ereignisgeneratortabelle Ereignisnummern und/oder Ereignisnamen, welche an das Diagnosesystem 300 zum Einschätzen des Zustands des Papiervorschubsystems weitergeleitet werden. Wenn der Zustand des Gerätes von dem Zustandseinschätzer 360 wie zuvor erläutert bestimmt wurde, leitet der Systemzustandsinformationenassembler 340 die entsprechenden Zustandsinformationen an die Ausgabevorrichtung 400 oder das Reparaturplanungsmodul 500 weiter.
9 und 10 stellen exemplarische Optionen der quadratischen Klassifiziererschaltung 160 dar. So wird beispielsweise im Fall des exemplarischen Papiervorschubsystems in 9 in einer Offline-Erstellungsphase des Klassifizierers für jedes Cluster oder jede Gruppe, das heißt im normalen Modus und im Fehlermodus, eine Anzahl von Blattvorschüben im Drucker und/oder Kopierer durchgeführt und Merkmale, welche zu diesen Blattvorschüben gehören, werden ermittelt. Dann werden für eine ausgewählte Klasse der Klassifiziererstruktur, das heißt quadratisch; linear oder Ähnliches, die Klassifiziererparameter mittels der statistischen Werkzeuge festgelegt.
10 stellt dar, wie ein Cluster während der Online-Bedienung eines Klassifizierers bestimmt wird, sobald die Offline-Erstellungs- oder -trainingsphase beendet ist. Im Speziellen wird der Abstand der Merkmalsvektoren von jedem Cluster mittels der Klassifiziererparameter in der Offline-Erstellungsphase berechnet. Dann wird das nächste Cluster an das Ereignisgeneratorsystem ausgegeben.
11 stellt einen Teil eines exemplarischen Diagnosesystems für das exemplarische System der 6 dar. Das Diagnosesystem wird in diesem Beispiel als ein regelbasiertes System gezeigt. Die Diagnoserückschlussmaschine wird als Diagnoser bezeichnet.
12 stellt ein exemplarisches Ablaufdiagramm dar, welches ein exemplarisches Ausführungsbeispiel für die Diagnose eines Systems entsprechend dieser Erfindung skizziert. Die Kontrolle beginnt in Schritt S1000 und wird bis Schritt S1100 fortgesetzt. In Schritt S1100 werden ein oder mehrere Systemsensoren/-controller überwacht und optional werden die von den Sensoren gesammelten Daten gespeichert. Danach werden in Schritt S1200, oder parallel zu Schritt S1100, ein oder mehrere virtuelle Sensoren überwacht und optional werden die von den Sensoren gesammelten Daten gespeichert. Dann werden in Schritt S1300 die gesammelten Daten in Ereignisdaten umgewandelt, basierend zum Beispiel auf Ereignisablauftabellen. Die Kontrolle wird dann bis Schritt S1400 fortgesetzt.
In Schritt S1400 werden die Ereignisdaten analysiert, um den Zustand des Systems einzuschätzen. Als nächstes werden in Schritt S1500 Informationen in Bezug auf den Funktionsfehlerstatus des Systems ausgegeben. Die Kontrolle wird dann bis Schritt S1600 fortgesetzt, wo der Kontrollablauf endet.
Wie in den 1–11 gezeigt, wird das Diagnose- und Funktionsfehlervorhersagesystem vorzugsweise entweder auf einem Universalcomputer mit einem Programm oder auf einem speziell programmierten Universalcomputer umgesetzt. Das Diagnose- und Funktionsfehlervorhersagesystem kann jedoch auch auf einem Spezialcomputer, einem programmierten Mikroprozessor oder Mikrocontroller und peripher integrierten Schaltungselementen, einer kundenspezifisch integrierten Schaltung (ASIC) oder anderen integrierten Schaltungen, einem digitalen Signalprozessor, einer festverdrahteten elektronischen oder logischen Schaltung wie einer getrennten Elementschaltung, einer programmierbaren logischen Vorrichtung wie PLD, PLA, FPGA, PAL oder Ähnlichem umgesetzt werden. Im Allgemeinen kann jede Vorrichtung für die Implementierung des Diagnose- und Funktionsfehlervorhersagesystems verwendet werden, welche eine finite Zustandsmaschine integrieren kann, die wiederum Ablaufdiagramme und Arbeitsablaufdiagramme wie in 12 implementieren kann.
Des Weiteren kann die dargelegte Methode leicht in Software implementiert werden, welche Objekt- oder objektorientierte Softwareentwicklungsumgebungen verwendet, die übertragbaren Quellcode liefern, welcher auf verschiedenen Computer- oder Arbeitsplatzhardwareplattformen verwendet werden kann. Alternativ kann das dargelegte Suchsystem teilweise oder komplett in Hardware implementiert werden, welche standardmäßige logische Schaltungen oder einen VLSI-Aufbau verwendet. Ob zur Implementierung des Systems in Übereinstimmung mit dieser Erfindung Software oder Hardware verwendet wird, ist abhängig von den Geschwindigkeits- und/oder Effizienzanforderungen des Systems, der speziellen Funktion und den speziellen Software- oder Hardwaresystemen oder Mikroprozessoren und Mikrocomputersystemen, die verwendet werden. Das oben beschriebene Diagnose- und Funktionsfehlervorhersagesystem kann jedoch unter Verwendung bekannter oder zukünftig entwickelter Systeme oder Strukturen, Vorrichtungen und/oder Software von Fachleuten mittels der hier gelieferten Beschreibung zusammen mit Allgemeinwissen im Bereich Computertechnik leicht und ohne unangemessenes Experimentieren in Hardware oder Software implementiert werden.
Des Weiteren kann das dargelegte System leicht als Software auf einem programmierten Universalcomputer, einem Spezialcomputer, einem Mikroprozessor oder Ähnlichem implementiert werden. In diesem Fall kann das System dieser Erfindung als Routine implementiert werden, die in einen PC eingebettet ist, wie Java^® oder CGI Script, als Ressource, die sich auf einem Server oder Arbeitsplatz befindet, als Routine, die ein zugehöriges Diagnose- und Funktionsfehlervorhersagesystem eingebettet ist, oder Ähnli ches. Das Diagnose- und Funktionsfehlervorhersagesystem kann auch durch physisches Einbeziehen des Systems und der Methode in ein Software- und/oder Hardwaresystem, wie die Hardware- und Softwaresysteme eines Arbeitsplatzes oder eines zugehörigen Diagnosesystems, implementiert werden.
Es wird daher deutlich, dass in Übereinstimmung mit der vorliegenden Erfindung ein System für die Diagnose und Funktionsfehlervorhersage elektronischer Systeme bereitgestellt wurde.

Claims

Hybrides Diagnosesystem für Vorhersage und Diagnose des Status eines überwachten Systems, das umfasst: wenigstens einen Systemsensor (30), der so eingerichtet ist, dass er konkrete Systeminformationen erfasst; wenigstens einen virtuellen Sensor (100), der so eingerichtet ist, dass er konkrete Systeminformationen verarbeitet und so Statusinformationen einer Komponente des überwachten Systems bestimmt, wobei der oder jeder virtuelle Sensor (100) wenigstens ein Modul enthält, das so eingerichtet ist, dass es eine numerische Analyse konkreter Systeminformationen durchführt; und eine diagnostische Interferenzvorrichtung (300), die so eingerichtet ist, dass sie Informationen von dem wenigstens einen Systemsensor (30) und dem wenigstens einen virtuellen Sensor (100) analysiert und den Zustand des Systems einschätzt; wobei der oder jeder Systemsensor (30) konkrete Systeminformationen, die direkt mit einem Systemereignis korrelieren, zu der diagnostischen Interferenzvorrichtung (300) weiterleitet und der oder jeder virtuelle Sensor (100) der diagnostische Interferenzrichtung (300) bestimmte Statusinformationen bereitstellt, die sich auf zusätzliche Systemereignisse beziehen.