DE60017457T2

DE60017457T2 - Verfahren zur isolierung eines fehlers in fehlernachrichten

Info

Publication number: DE60017457T2
Application number: DE60017457T
Authority: DE
Inventors: Peter Eriksson; Magnus Larsson
Original assignee: ABB AB
Current assignee: ABB AB
Priority date: 1999-11-03
Filing date: 2000-11-03
Publication date: 2005-12-29
Anticipated expiration: 2020-11-04
Also published as: US7124060B1; DE60017457D1; ATE287106T1; SE9904008D0; WO2001033354A1; JP2003514276A; EP1236110B1; AU1322101A; EP1236110A1

Description

Technisches Gebiet
Die vorliegende Erfindung betrifft ein Verfahren, eine Verwendung des Verfahrens, ein System und eine Verwendung des Systems, ein Computerprogrammcode-Element, und ein computerlesbares Medium zum Isolieren eines Fehlers aus einer Vielzahl von Fehlermeldungen in einem Systemprotokoll eines Vorgangs, der durch ein objektorientiertes Programm gesteuert wird.
Stand der Technik
Das Entwickeln von Steuersystemen für komplexe Systeme ist eine schwierige und zunehmend wichtige Aufgabe. Größere Steuersysteme sind herkömmlicherweise unter Verwendung strukturierter Analyse und funktionaler Zerlegung entwickelt worden, siehe beispielsweise T. DeMarco, Structured Analysis and System Specification, Prentice-Hall, 1979. Wenn herkömmliche Programmierung angewendet wird, ist es möglich, einen Programmiercode in Bezug auf Echtzeit-Anforderungen zu optimieren, und es ist einfacher, genaue Fehlermeldungen zu erzeugen, da der Zustand eines ganzen Programms zu jedem Zeitpunkt bekannt ist.
Heute werden viele große Systeme unter Verwendung eines objektorientierten Ansatzes ausgelegt. Dies hat einige Vorteile gegenüber herkömmlichen Ansätzen, einschließlich einer besseren Möglichkeit, mit einer Komplexität umzugehen und eine gute Wartbarkeit und Wiederverwendung zu erreichen. Jedoch kann es, da Fehlermeldungen, die von einem bestimmten Fehler herrühren, häufig die Auslegung des Steuersystems und dessen Architektur reflektieren, für einen Betreiber sehr schwierig sein zu verstehen, welche Fehlermeldung einer Vielzahl von Fehlermeldungen am ehesten relevant und dem realen bzw. echten Fehler am nächsten ist.
Ein Verfahren, das zur Fehlerisolierung verwendet werden kann, ist es, eine Datenbank zu kompilieren bzw. zusammenzutragen, oder ein Expertensystem zu verwenden, siehe z.B. W.T.
Scherer und C.C. White, A survey of expert systems for equipment maintenance and diagnostics, in S.G. Tzafestas, Verfasser, Knowledge-based system diagnosis, supervision and control, Seiten 285–300, Plenum, Ne York, 1989 und S. Tzafestas und K. Watanabe, Modern approaches to system/sensor fault detection and diagnosis, Journal A, 31(4):42–57, Dezember 1990. Aber ein hochgradig konfigurierbares System besitzt den Nachteil, dass jede Installation des Steuersystems eine neue Datenbank benötigt. Ebenso kann dies, wenn Änderungen an dem System selbst ausgeführt werden, eine aufwendige Datenbank nutzlos machen.
Eine andere Möglichkeit zur Fehlerisolierung ist es, ein Modell zu verwenden, das für die Fehlerisolierung maßgeschneidert ist. Einige allgemeine Beispiele können gefunden werden in W. Hamscher, L.Console und J. de Kleer, Verfasser, Readings in madel-based diagnosis, Morgan Kaufmann Publishers, San Mateo, CA, 1992, und M. Sampath, R. Sengupta, S. Lafortune, K. Sinnamohideen und D. Teneketzis, Diagnosability of discrete-event systems, IEEE Transactions on Automatic Control, 40(9):1555–1575, September 1995.
Der Vorteil der Verwendung eines spezialisierten Modells ist, dass ein solches Modell genau die Information enthalten kann, die für die Fehlerisolierung erforderlich ist, und der Fehlerisolierungsvorgang kann stark vereinfacht werden kann. Der Nachteil ist, dass dieses Modell separat gewartet bzw. aufrechterhalten werden muss. Ein solches Modell aufrechtzuerhalten ist nicht trivial und eine Menge Arbeit könnte erforderlich sein, um das Modell auf dem neuesten Stand zu halten.
Ausnahmebehandlungsmechanismen (exception handling mechanisms) sind dazu vorgesehen, dabei zu helfen, die Fehlerbehandlung in Software zu verbessern, um Programme verlässlicher und robuster zu machen. Sie sind Sprachkonstrukte, die die Fehlerbehandlung außerhalb des herkömmlichen Programmflusses und auf der angemessenen Ebene bzw. dem Niveau erleichtern. Die Ausnahmekonstrukte könnten ebenso einen Programmierer dabei unterstützen, dem Fehlerbehandlungscode mehr Informationen zur Verfügung zu stellen, als durch die herkömmliche Objektschnittstelle verfügbar sind, um die Fehlerwiederherstellung bzw. Fehlerbehebung zu erleichtern.
Ausnahme-Behandlungsmechanismen sind von ihrer Natur her Konstrukte auf niedriger Ebene, und als solche adressieren sie ein Fehlerbehandlungsproblem von unten herauf. Es daher bekannt, wie in R. Miller und A. Tripathi „Issues with exception handling in object-oriented systems", in Verfahren der 11ten Europäischen Konferenz über objektorientierte Programmierung (ECOOP97), Jyväskylä, Finland, Juni 1997, herausgestellt, anzumerken, dass die Ziele der Ausnahmebehandlung häufig in direktem Konflikt mit den Zielen einer objektorientierten Architektur stehen, den genau gleichen Zielen der Verkapselung (encapsulation) und Modularität, welche das Fehlerverbreitungsproblem bzw. Fehlerfortpflanzungsproblem bewirken, das von der vorliegenden Erfindung adressiert bzw. angesprochen wird.
Die Druckschrift US-A-5,845,272 zeigt ein System und ein Verfahren zum Isolieren von Fehlern in einer Lokomotive mit einer Vielzahl von Untersystemen. Ein Versorgungsmittel liefert Ereignis-Information, die in jedem der Vielzahl von Untersystemen während dem Betrieb der Lokomotive auftritt. Ein Zuordnungsmittel ordnet einige der Vorfälle Indikatoren zu. Ein Fehlerisolator, der mit dem Zuordnungsmittel gekoppelt ist, bestimmt Ursachen von und Fehler, die mit den Vorfällen in Verbindung stehen. Der Fehlerisolator umfasst eine Diagnose-Wissensbasis mit Diagnoseinformation über Fehler, die in jedem der Vielzahl von Untersystemen auftreten und den Indikatoren bzw. die Indikatoren. Der Fehlerisolator umfasst ein Diagnosesystem zum Verarbeiten der zugeordneten Indikatoren mit der Diagnoseinformation in der Diagnose-Wissensbasis. Ein Bereitstellungsmittel stellt eine Handlungsweise bereit, die auszuführen ist, um die Fehler zu korrigieren. Die Aufgabe des Systems und des Verfahrens ist es, den Bedarf an menschlicher Mitwirkung zu minimieren.
Zusammenfassung der Erfindung
Die vorliegende Erfindung stellt ein Modell-basiertes Verfahren für die Fehlerisolierung bereit, durch Einführen einer zusätzlichen Schicht zwischen einem Betreiber und/oder einem Vorgangssteuerungsmittel und eigentlichen Fehlernachrichten, die von einem Steuersystem erzeugt werden. Diese Herangehensweise bzw. dieser Ansatz kann so zusammengefasst werden, dass er eine liberale Strategie bzw. Verfahrensweise für das Senden von Fehlermeldungen für einzelne Objekte aufweist, mit einer strukturierten Signatur für die Meldungen, und ein Zusammenstellungsverfahren, um Fehlerszenarien zu isolieren. Ein Modell des Systems wird dann verwendet, um das Objekt/die Objekte zu isolieren, die dem Fehler in jedem Fehlerszenario am nächsten sind. Die Meldung(en), die dem Fehler am nächsten sind, und daher am ehesten relevant, können dann gemäß der vorliegenden Erfindung beispielsweise einem Betreiber bzw. Bediener einfacher angezeigt werden, als es vorhergehend bekannt ist, der Maßnahmen ergreifen kann, um mit einem Fehler umzugehen.
Um Nachteile und Probleme zu überwinden, die mit der Isolierung von Fehlern heute zusammenhängen, zum Beispiel für Vorgänge, die einen Industrieroboter einbeziehen, stellt die vorliegende Erfindung ein Verfahren, ein entsprechendes System und ein entsprechendes Softwareprogrammprodukt zum Isolieren eines Fehlers aus einer Vielzahl von Fehlermeldungen in einem Systemprotokoll eines Vorgangs, der durch ein objektorientiertes Programm gesteuert wird, gemäß den angehängten unabhängigen Ansprüchen 1, 9 bzw. 16 bereit.
In einer Ausführungsform der vorliegenden Erfindung umfasst sie die Schritte:

– Erzeugen einer vordefinierten Signatur für jede Fehlermeldung der Vielzahl von Fehlermeldungen;
– Bilden eines Zeitabschnitts, um aus der Vielzahl von Fehlermeldungen die Fehlermeldungen festzulegen, die zu einem Fehlerszenario des Fehlers gehören;
– Zusammenstellen der Fehlermeldungen, die in den Zeitabschnitt fallen;
– Bilden eines Basisgraphen, der eine formale Darstellung des Fehlerszenarios ist, und der Information über die Beziehung von Ursache-Wirkung dieser Fehlermeldungen trägt, aus den Signaturen der zusammengestellten Fehlermeldungen;
– Analysieren des Basisgraphen, um den Fehler zu isolieren; und
– Berichten von Information, welche den Fehler enthält, an ein Steuermittel, das Mittel bzw. Maßnahmen bereitstellt, um sich des Fehlers anzunehmen.

In einer Ausführungsform der vorliegenden Erfindung wird jede der Signaturen dazu gebracht, Informationen über die Beanstandung (complaint) und den Beanstander (complainer) zu enthalten.
Ein Erklärungsmodell wird in einer Ausführungsform der Erfindung aus einer grundlegenden Annahme einer Kommunikation zwischen Systementitäten, die nötig sind, um eine bestimmte Aufgabe auszuführen, gebildet, wobei die Systementitäten Objekte, Pakete und Threads umfassen, und die Signaturen auf der Basis des Erklärungsmodells definiert sind.
Der erwähnte Zeitabschnitt beginnt in einer Ausführungsform der Erfindung mit der ersten Fehlermeldung in einem Fehlerszenario und endet mit einer Stoppmeldung.
Gemäß einer Ausführungsform der vorliegenden Erfindung umfasst die berichtete Information eine Verlässlichkeitsabschätzung des Fehlers.
In einer Ausführungsform der Erfindung, im Falle eines nicht aussagekräftigen Basisgraphen, umfasst der Analysierungsschritt weiter die Schritte:

– Erweitern des Basisgraphen mit Hilfe eines Systemmodells, enthaltend Information über die Abhängigkeitsbeziehung zwischen Systementitäten; und
– Analysieren des erweiterten Basisgraphen mit einem Satz von vorbestimmten Erklärungsregeln, um den Fehler zu isolieren.

Eine andere Ausführungsform der vorliegenden Erfindung umfasst, dass das Systemmodell unter Verwendung der „Unified Modeling Language" (UML) gebildet ist.
Noch eine andere Ausführungsform der vorliegenden Erfindung schließt die Verwendung eines Verfahrens gemäß dem Vorhergehenden in einem Vorgang ein, der einen Industrieroboter einbezieht.
Weiter stellt die vorliegende Erfindung ein System zum Isolieren eines Fehlers aus einer Vielzahl von Fehlermeldungen in einem Systemprotokoll eines Vorgangs bereit, der durch ein objektorientiertes Programm gesteuert wird.
Jede Fehlermeldung der Vielzahl von Fehlermeldungen umfasst in einer bevorzugten Ausführungsform der vorliegenden Erfindung eine vorausgelegte bzw. vorbestimmte Signatur, und dass eine Schnittstelle zwischen dem Programm und einem Mittel für die Vorgangssteuerung angeordnet ist, wobei die Schnittstelle Mittel zum Zusammenstellen von Fehlermeldungen, die zu einem Fehlerszenario des Fehler gehören, zum Bilden eines Zeitabschnitts, um aus der Vielzahl von Fehlermeldungen die Fehlermeldungen festzulegen, die zu einem Fehlerszenario des Fehlers gehören und Zusammenstellen der Fehlermeldungen, die in den Zeitabschnitt fallen umfasst, Mittel zum Bilden einer formalen Darstellung, eines Basisgraphen, des Fehlerszenarios aus den zusammengestellten Fehlermeldungen, Mittel zum Analysieren der formalen Darstellung, um den Fehler zu isolieren, und Mittel zum Berichten von Information, die den Fehler enthält, an das Vorgangsteuerungsmittel, welches Mittel bereitstellt, um sich des Fehlers anzunehmen.
Eine andere Ausführungsform der vorliegenden Erfindung schließt ein, dass die Signatur Information über Beanstandung, Beanstander und Beanstandungsstelle (complainee) umfasst, und dass die Signatur aus einem Erklärungsmodell umfassend eine grundlegende bzw. zugrunde liegende Annahme einer Kommunikation zwischen Systementitäten gebildet ist, die erforderlich sind, um eine bestimmte Aufgabe auszuführen, wobei die Systementitäten Objekte, Pakete und Threads umfassen.
Der Zeitabschnitt beginnt in einer Ausführungsform der vorliegenden Erfindung mit der ersten Fehlermeldung in dem Fehlerszenario und endet mit einer Stoppmeldung.
Noch eine weitere Ausführungsform stellt bereit, dass das System Mittel zum Erstellen einer Verlässlichkeitsabschätzung des Fehlers umfasst, und dass die Fehlerinformation die Abschätzung umfasst.
Im Falle, dass der Basisgraph nicht aussagekräftig ist, umfasst das System in einer Ausführungsform der Erfindung weiter Mittel, um den Basisgraphen mit Hilfe eines Systemmodells zu erweitern, das Information über die Abhängigkeitsbeziehung zwischen Systementitäten enthält, und Mittel zum Isolieren des Fehlers aus dem erweiterten Graphen unter Verwendung von vorbestimmten Erklärungsregeln.
Die „Unified Modeling Language" (UML) wird in einer bevorzugten Ausführungsform der Erfindung verwendet, um das Systemmodell zu bilden.
Noch eine andere Ausführungsform stellt die Verwendung des Systems gemäß dem vorher beschriebenen System in einem Vorgang bereit, der einen Industrieroboter einbezieht.
Eine weitere Ausführungsform der vorliegenden Erfindung wird durch ein Computerprogrammcode-Element bereitgestellt, das Computercodemittel umfasst, um einem Prozessor zu ermöglichen, einen Fehler aus einer Vielzahl von Fehlermeldungen in einem Systemprotokoll eines Vorgangs zu isolieren, der von einem objektorientierten Programm gesteuert wird.
Es ermöglicht einem Prozessor, die Schritte auszuführen:

– Erzeugen einer vorbestimmten Signatur für jede Fehlermeldung der Vielzahl von Fehlermeldungen;
– Bilden eines Zeitabschnitts, um aus der Vielzahl von Fehlermeldungen die Fehlermeldungen festzulegen, die zu einem Fehlerszenario des Fehlers gehören;
– Zusammenstellen der Fehlermeldungen, die in den Zeitabschnitt fallen;
– Bilden eines Basisgraphen aus den zusammengestellten Fehlermeldungen, der eine formale Darstellung des Fehlerszenarios ist, und der Information über Ursache-Wirkung der Fehlermeldungen trägt;
– Analysieren des Basisgraphen, um den Fehler zu isolieren; und
– Berichten von Information, die den Fehler enthält, an ein Steuermittel, das Mittel bereitstellt, um sich des Fehlers anzunehmen.

Eine Ausführungsform stellt bereit, dass das Code-Element auf einem computerlesbaren Medium enthalten ist.
Eine andere Ausführungsform der Erfindung stellt bereit, dass das Code-Element zumindest teilweise über ein Netzwerk so wie das Internet bereitgestellt wird.
Von der vorliegenden Erfindung wird ebenso ein computerlesbares Medium bereitgestellt.
Wobei es ein Computerprogrammcode-Element enthält, umfassend Computercodemittel, um einem Prozessor zu ermöglichen, einen Fehler aus einer Vielzahl von Fehlermeldungen in einem Systemprotokoll eines Vorgangs zu isolieren, der von einem objektorientierten Programm gesteuert wird, durch das dem Prozessor ermöglicht wird, die Schritte auszuführen:

– Bilden einer Schnittstelle zwischen dem Programm, welches die Vielzahl von Fehlermeldungen erzeugt, und einem Vorgangssteuerungsmittel;
– Erzeugen einer Zusammenstellung aus der Vielzahl von Fehlermeldungen, die zu einem Fehlerszenario des Fehlers gehören;
– Analysieren der Zusammenstellung unter Verwendung vorbestimmter Fehlermeldungssignaturen und eines vorbestimmten Systemmodells, um den Fehler zu isolieren; und
– Berichten von Information, die den Fehler enthält, an ein Steuermittel, das Mittel bereitstellt, die sich des Fehlers annehmen.

Kurze Beschreibung der Zeichnung
Für ein vollständigeres Verständnis der vorliegenden Erfindung und für weitere Aufgaben und Vorteile davon kann nun Bezug genommen werden auf die folgende Beschreibung in Verbindung mit der begleitenden Zeichnung, in welcher:
1 schematisch ein herkömmliches Nachrichten- bzw. Meldungssystem mit einem Systemprotokoll darstellt;
2 schematisch ein Meldungssystem für die Fehlerisolierung gemäß der vorliegenden Erfindung darstellt;
3 schematisch grafische Notationen für verschiedene Fehlermeldungen gemäß einer Ausführungsform der Erfindung darstellt;
4 schematisch ein Flussdiagramm über einen Analysevorgang gemäß der vorliegenden Erfindung darstellt;
5 schematisch vier mögliche Eigenschaften eines Basisgraphknotens gemäß der vorliegenden Erfindung darstellt; und
6 schematisch ein allgemeines Beispiel eines UML Durchlauf-Algorithmus darstellt.
Tabelle
Tabelle 1 auf der letzten Seite der vorliegenden Beschreibung stellt Serverketten dar, die von einem UML Durchlauf-Algorithmus für das Modell gemäß 6 zurückgegeben werden.
Detaillierte Beschreibung von bevorzugten Ausführungsformen
Die Merkmale der vorliegenden Erfindung stellen bezüglich der Fehlerisolierung eine abstraktere Ansicht bereit als der Stand der Technik, und adressiert das Problem, hauptsächlich Fehlerfortpflanzung, aus einer von-oben-herab-Perspektive. Es ist nicht beabsichtigt, Fehlerbehandlung auf unterem Niveau (low level error handling) zu ersetzen, sondern um in Verbindung mit der Fehlerbehandlung auf unterem Niveau in einer Form verwendet zu werden. Es kann z.B. eine disziplinierte Verwendung von Rückgabe-Codes oder vollständige bzw. vollwertige Ausnahmehandhabungsmechanismen sein.
In einer objektorientierten Auslegung sind Einschließung und Modularität grundlegende und wichtige Auslegungsziele aus Gründen der Wiederverwendung, Wartung und Komplexität. Ein häufig im Konflikt stehendes Auslegungsziel liegt in der Notwendigkeit unnötige, sich fortpflanzende bzw. ausbreitende, Fehlermeldungen zu unterdrücken und schließlich einem Betreiber und/oder Vorgangssteuerungsmittel ein genaues Bild einer Fehlersituation zu geben, um darauf zu reagieren.
Das Thema ist, wie ein konfigurierbares und sicherheitskritisches Steuerungssystem mit einer objektorientierten Architektur Laufzeitfehler und Alarme handhabt und isoliert, und speziell die Probleme, die aufgrund der objektorientierten Struktur und Komplexität des Steuerungssystems selbst entstehen.
Das Steuerungssystem kann in der Multi-thread-Form ausgeführt sein, mit einigen gleichzeitigen Aufgaben (tasks), die sowohl asynchron als auch synchron kommunizieren. Die Aufgaben in dem System gemäß der vorliegenden Erfindung sind sowohl reine Softwareaufgaben als auch Aufgaben, die der Hardware entsprechen. Die Erfindung konzentriert sich hauptsächlich auf die Fehlerhandhabung für ein voll betriebsfähiges bzw. in Betrieb befindliches System, und wird keine Installations- und Start-Probleme ansprechen.
Mit dem Ausdruck Fehler ist hier eine Laufzeitveränderung oder ein Ereignis gemeint, normalerweise in der Hardware, die/das letztendlich bewirkt, dass das System den herkömmlichen bzw. normalen Betrieb abbricht. Wenn ein Fehler während dem normalen Betrieb auftritt, erzeugt das System häufig eine große Anzahl an Fehlermeldungen, zum Beispiel Ausbrüche (bursts) von Fehlern. Fehlermeldungen werden von einzelnen Objekten gesendet, um einen Betreiber oder ein Mittel zum Betreiben zu benachrichtigen, wenn das Objekt eine Fehlerbedingung erfasst hat. Das einzelne Objekt weiß allgemein nicht, wie nahe es an dem echten Fehler liegt, oder ob ausreichendes Berichten bereits stattfindet, und daher, ob es an den Betreiber berichten soll oder nicht.
1 stellt schematisch ein herkömmliches Meldungssystem des Stands der Technik mit einem Systemprotokoll dar, in dem ein Kasten oder Block 100 Eingangssignale, Sensoren, I/O-Ausrüstung eines Motors etc. darstellt. Die Bezugsziffer 110 bezeichnet ein objektorientiertes Steuersystem, das eine Anordnung so wie einen Industrieroboter steuert, und abhängig von seinen Eingangssignalen prüft, ob in einem Systemprotokoll 120 Meldungen vorliegen. Wenn Meldungen vorhanden sind, die dem Verarbeiten der Signale durch das Steuersystem 110 entsprechen, werden Meldungen betreffend Fehler oder irgendeine andere Meldung, die einem Betreiber des Systems/der Anordnung angezeigt werden muss, als Information für die Wartung etc. ausgegeben. Steuersysteme des Stands der Technik und Systemprotokolle sind nicht ausgelegt, primäre Fehler zu benennen (pinpoint) oder diese aus einer Vielzahl von Meldungen auszusortieren, um Wartung, Reparatur etc. zu bestimmen, für einen Betreiber von zum Beispiel einem komplexen Steuersystem, dies ist auf hochbegabte Ingenieure oder dergleichen beschränkt.
Wenn eine Fehlerbedingung angetroffen wird, lässt das betroffene Objekt normalerweise das passende Schnittstellenverfahren einen Fehlercode an das anrufende bzw. aufrufende Objekt zurückgeben. Es könnte ebenso entscheiden, seinen normalen Betrieb fortzusetzen, z.B. in dem Fall einer ereignisgesteuerten bzw. ereignisorientierten Threads-Hauptschleife. Der zurückgegebene Fehlercode kann von dem aufrufenden Objekt wiederum als eine Fehlerbedingung betrachtet werden. Wenn es von den Auslegern als angemessen angesehen wird, registriert das Objekt eine Fehlermeldung zu einem zentralen Protokoll 120. Wenn eine Fehlerbedingung von einem erfassenden Objekt als so ernst angesehen wird, dass ein normaler Betrieb nicht fortgesetzt werden kann, wird ein spezieller asynchroner Aufruf ausgeführt, der einen Nothalt ausführt.
Für Objekte in einem Programm, die nahe bei einander sind, ist es möglich, Fehlermeldungen durch Informationsweitergabe zu unterdrücken, aber dies ist nicht immer durchführbar – es ist ein explizites Ziel von objektorientiertem Modellieren, Wissen über den internen Zustand von Objekten einzuschließen und Unabhängigkeit zwischen Gruppen von zusammenarbeitenden Objekten zu erreichen (d.h. Einschließung bzw. Verkapselung und Modularität). Ferner, das hier betrachtete Steuersystem ist sicherheitskritisch. Im Falle eines ernsten Fehlers ist es die erste Priorität, das System oder die Anordnung in einen sicheren Zustand zu bringen. Nur dann ist es möglich, damit zu beginnen, zu analysieren, was den Fehler verursacht haben könnte.
Ein primärer Belang ist eine Situation, in der ein betriebsbereites System normalerweise ohne direkte Aufsicht arbeitet. Da die Fehlermeldungen, die von einem bestimmten Fehler stammen, häufig die Auslegung und Architektur des Steuersystems reflektieren, kann es für den Betreiber sehr schwierig sein, zu verstehen, welche Fehlermeldung am ehesten relevant und dem echten Fehler am nächsten 120 ist.
Die vorliegende Erfindung, wie in 2 dargestellt, stellt schematisch ein Meldungssystem zur Fehlerisolierung dar, und beschreibt ein Modell-basiertes Verfahren für die Fehlerisolierung, durch Einfügen einer zusätzlichen Schicht 210, 220, 230 zwischen dem Betreiber oder Mittel zum Betreiben und den eigentlichen Fehlermeldungen 200, die von dem Steuersystem 110 erzeugt werden. Der Ansatz kann so zusammengefasst werden, dass er eine liberale Verfahrensweise (policy) für das Senden von Fehlermeldungen für einzelne Objekte aufweist, mit einer strukturierten Signatur für die Meldungen, und ein Zusammenstell- 210 Verfahren, um (Fehler-) Szenarios zu isolieren. Ein Modell 220 des Systems wird dann verwendet, um das Objekt/die Objekte zu isolieren, die dem Fehler in jedem Fehlerszenario am nächsten sind (Zusammenstellung 1 und Zusammenstellung 2 in 2). Die Meldung(en), die dem Fehler (primäre Fehlermeldung 1 und primäre Fehlermeldung 2 in 2) am nächsten sind, und daher am meisten relevant, können dann einem Betreiber oder Mittel zum Betreiben angezeigt werden.
Eine grundlegende Terminologie wird nun erstellt:
Definition: Steuersystemprotokoll
Das Systemprotokoll 200 bildet eine Liste von Ereignissen, die von dem System in chronologischer Reihenfolge in der Form von Meldungen aufgezeichnet worden sind.
Schließlich werden die Bezeichnungen Ereignis und Meldung austauschbar verwendet.
Definition: Fehler
Ein Fehler ist eine Laufzeit-Veränderung oder ein Ereignis, häufig in Hardware 100, die schließlich bewirkt, dass das System von seinem normalen Betrieb abweicht.
Definition: Fehlermeldung
Eine Fehlermeldung ist eine Meldung, die von einem einzelnen Softwareobjekt an den Betreiber gesendet wird, als Antwort auf die Erfassung einer Fehlerbedingung für das Objekt.
Die Art von Fehlerbedingung, die in einem Objekt auftreten kann, steht eng in Bezug mit den Verfeinerungen der Fehlermeldung, was im Folgenden weiter besprochen wird.
Definition: Fehlerszenario
Ein Fehlerszenario besteht aus allen instanziierten (instantiated) Systementitäten und Ereignissen, die in der Herkunft und Erscheinungsform eines bestimmten Fehlers einbezogen sind bzw. eine Rolle spielen.
Beispiele von Systementitäten sind Objekte, Verbindungen, Threads, Hardwareausrüstung und physikalische Verbindungen.
Das Systemprotokoll kann Meldungen enthalten, die zu einigen verschiedenen Fehlerszenarien gehören. Um eine Analyse eines einzelnen Fehlerszenarios auszuführen, werden Meldungen, die während dem gleichen Fehlerszenario aufgetreten sind, gemäß der vorliegenden Erfindung zusammengestellt 200, 210. Ein Zeitabschnitt wird gebildet, um aus einer Vielzahl von Fehlermeldungen die Fehlermeldungen festzulegen, die zu einem Fehlerszenario des Fehlers gehören.
Ein Zusammenstellungs- 210 Verfahren zum Zusammenstellen der Fehlermeldungen, die in den Zeitabschnitt fallen, basiert gemäß der vorliegenden Erfindung auf einer maximalen Zeitspanne einer Zusammenstellung, die hier als von Zusammenstellungsabschnitten eingerahmte bzw. begrenzte Teilungsereignisse bezeichnet wird. Ein Teilungsereignis zeigt an, dass eine neue Zusammenstellung mit diesem Ereignis beginnt, auch wenn der Zeitabschnitt gültig ist. Jede Zusammenstellung wird identifiziert und für eine Analyse 230 weitergegeben. Ein Beispiel eines grundlegenden Zusammenstellungsalgorithmus kann folgend gefunden werden.
Der Pseudo-Code des Zusammenstellungsalgorithmus:
Auslegungsparameter zum Zusammenstellen sind Ereignisse in einer Teilergruppe und die Länge eines Zusammenstellungsabschnitts. Ein adaptives Verfahren könnten z.B. mit zunehmend größeren (oder kleineren) Zusammenstellungsabschnitten oder Verknüpfung bzw. Verkettung von Zusammenstellungen in Betracht gezogen werden.
Um ein spezifisches Erklärungsmodell 220 auf ein Fehlerszenario anzuwenden, ist es erforderlich, zu wissen, wie die Fehlermeldungen in dem Protokoll mit der/den gewählte(n) Erklärungsbasis/-Basen in Beziehung stehen. Die allgemeine Semantik dieser Beziehung, ausgelöst durch die Anforderungen einer OO Architektur (objektorientiert, OO) ist, dass eine Fehlermeldung eine Beanstandung von einer (instanziierten) Entität über eine (instanziierten) Entität ist. Die Beanstandungsstellen-Entität kann die gleiche wie die Beanstander-Entität sein (interner Fehler), oder die Beanstandungsstelle kann aus Gründen der OO-Architektur unbekannt sein. Die zwei Entitäten müssen allgemein nicht von der gleichen Art sein, z.B. könnte ein Objekt etwas über einen Thread beanstanden. Eine Fehlermeldungssignatur ist Beanstander und Beanstandungsstelle für eine Fehlermeldung. Eine Fehlermeldungssignatur ist in Fehlermeldungen vorhanden, umfassend Informationen eines sendenden Quellenobjekts und – Threads, und falls möglich, der Grund für die Fehlermeldung in Form von Information darüber, welche Systementität dabei versagt hat, einen angeforderten Dienst auszuführen.
Eine Fehlermeldungssignatur für Objekte wie eine Erklärungsbasis ist im Folgenden genauer beschrieben.
Ein gewöhnliches Verfahren, um ein anderes Objekt aufzurufen, das einen Fehlercode zurückgibt, ist das am häufigsten anzutreffende Beispiel einer Fehlerbedingung, die zu einer relationalen Fehlermeldung mit bekannter Beanstandungsstelle führen sollte. Die Beanstandungsstelle kann unbekannt sein, wenn das verantwortliche Objekt dem Beanstander nicht bekannt ist, aufgrund von Verkapselungs- oder Modularitätsgründen.
Eine entsprechende Fehlerbedingung könnte ein erfasster Fehler in Hardware oder einer externen Ausrüstung sein, über das das Objekt Wissen verkapselt.
Eine grafische Notation für die verschiedenen Arten von Fehlermeldungen wird eingeführt und beschrieben in 3. Kästen oder Blöcke 30, 32, 34, 36 stellen Objekte dar. Eine relationale Fehlermeldung mit bekannter Beanstandungsstelle ist mit einem Pfeil 38 zwischen dem Beanstander 30 und der Beanstandungsstelle 32 angegeben. Eine spezifische Fehlermeldung verwendet einen Pfeil zu sich selbst bezeichneten Block 34 mit dem Buchstaben „s". Eine relationale Fehlermeldung mit unbekannter Beanstandungsstelle verwendet ebenso einen Pfeil zu sich selbst bezeichneten Block 36 mit dem Buchstaben „u". Es sollte bemerkt werden, dass die zwei Arten von Pfeilen zu sich selbst semantisch verschieden sind. Die relationale Fehlermeldung mit unbekannter Beanstandungsstelle könnte zum Beispiel suggestiver als ein Pfeil gezeichnet werden, der in einem Fragezeichen endet. Die Notation ist aus Gründen der Einfachheit ausgewählt worden.
Die Information, die aus Fehlermeldungen erhalten werden kann, die den OO-Auslegungsregeln folgen, ist nicht immer ausreichend, um ein vollständiges und kohärentes Übersichtsbild eines Fehlerszenarios zu bilden. Um die Fehlermeldungen zu vervollständigen wird ein Systemmodell 220 verwendet, das Informationen darüber enthält, wie Systementitäten, so wie Softwareentitäten, voneinander abhängen, um ihre Aufgaben auszuführen. Das Modell 220 reflektiert die derzeitige Systemauslegung.
Ein Erklärungsmodell ist die grundlegende Annahme, die erforderlich ist, wenn eine spezifische Art von Systementität als die Basis zur Fehlerisolierung verwendet wird. Arten von Systementitäten, die als eine Basis für ein Erklärungsmodell verwendet werden können, sind z.B.
Objekte, Pakete und Threads (tasks bzw. Aufgaben). Eine Hauptidee ist es, die Struktur des Systems zu verwenden, manifestiert in Entitäten wie erwähnt, um Ursache-Wirkung-Beziehungen zwischen Fehlermeldungen zu erstellen. Beispiele solcher Modellstrukturen sind UML class diagrams, object diagrams and task diagrams Object Management Group, UML Notation Guide, Version 1.1 doc no ad(97-08-05, September 1997.
Eine Systementität besitzt häufig einen bestimmten Typ, von dem einige einzelne instanziiert werden können, wie etwa Klasse – Objekt und Thread-Typ – Thread-Instanz. Fehlermeldungen kommen natürlich von instanziierten Entitäten. Das Systemmodell jedoch muss keine Informationen über Instanzen enthalten, sondern nur über Typen, wie zum Beispiel UML Klassendiagramme. Das Verwenden des Modells, um mögliche Abhängigkeiten zwischen Instanzen zu „raten", würde eine solche Analyse weniger verlässlich machen. Diese Tatsache kann verwendet werden, um die Verlässlichkeit der Analyse abzuschätzen. Ein Hauptziel ist eine Ursache-Wirkung-Beziehung zwischen allen Fehlermeldungen in einem Fehlerszenario, bevorzugt mit einer eindeutigen Grundursachen-(root cause)Fehlermeldung. Dies ist eine erste Maßnahme der Verlässlichkeit.
Ein Auslegungsparameter für die Analyse ist die Suchtiefe, die in dem Modell verwendet werden soll, d.h. von wie vielen „stillen" Entitäten angenommen werden muss, dass sie Teil des Fehlerszenarios sind. Ein anderer Auslegungsparameter ist die prioritätsbasierte Hinzufügung von Ursache-Folge-Beziehungen unter Verwendung des Systemmodells. Die Priorität kann auf Eigenschaften der instanziierten Entitäten oder Eigenschaften basieren, die Entitäten in dem Modell zugewiesen sind.
Aus Gründen der Einfachheit in der folgenden Darstellung ist ein Algorithmus folgend detailliert beschrieben für das spezifische Erklärungsmodell, das nur Objekte als Basis verwendet. Das Erklärungsmodell ist, in Kurzform, dass die Probleme, die ein Objekt erfährt, zum Beispiel durch Fehlermeldungen berichtet, erklärt werden kann durch die Abhängigkeit des Objekts und das Wissen und die Ressourcen, die sie verwalten. Dies ist eine geeignete Annahme, wenn das Interesse hauptsächlich auf von Hardware verursachten Fehlern liegt. Ein vollständigeres Erklärungsmodell würde z.B. sowohl Objekte als auch Threads als Erklärungsbasis verwenden, und daher ebenso Abhängigkeiten zwischen gleichzeitigen Threads berücksichtigen.
Eine Analyse kann in drei Hauptschritte aufgebrochen werden, wie in 4 schematisch durch ein Flussdiagramm über einem Analyseverfahren gemäß der vorliegenden Erfindung dargestellt.
Das Bilden eines rudimentären teilweisen Ablaufs direkt aus den zusammengestellten 400 Fehlermeldungen kann erreicht werden, wenn die Meldungssignatur gegeben ist. Sie kann dargestellt werden als ein gerichteter Graph, der künftig der Fehlermeldungsgraph, Basismeldungsgraph 410 oder Basisgraph genannt werden wird.
Ein Fehlermeldungsgraph kann möglicherweise durch eine Graphenerweiterung 420 modifiziert werden. Alle hinzugefügten Kanten werden relational sein, da ein Ziel bei den Graphenerweiterungen 420 ist, den Graphen verbunden zu machen. Die Kanten zwischen Objekten, sowohl aus dem Protokoll als auch abgeleitet, sollten gelesen werden als „Beanstandung über". Ein gebildeter Basisgraph besteht aus Systementitäten, die beschreiben, wie sie von einander in einem derzeitigen Fehlerszenario abhängen. Der Basisgraph ist unter Verwendung von Information in einer Fehlermeldungssignatur konstruiert.
Der Zweck von Graphenerweiterungen 420 ist es, den Basisgraph verbunden und azyklisch zu machen, mit einem eindeutigen Stammknoten (root node). Ein Basisgraph wird verwendet, um einen möglichen primären Fehler zu isolieren, unter Verwendung der Semantik, die von einem geeigneten Erklärungsmodell 220 bereitgestellt wird.
Objekte in dem Graphen sind klassifiziert in Bezug auf deren Fehlermeldungen, oder besser der Kanten, mit denen sie verbunden sind. Da es drei Arten von Fehlermeldungen (oder Kanten) gibt, zwei, die ein Objekt einbeziehen und eine, die zwei Objekte einbezieht, gibt es vier unabhängige Wege, auf die ein Objekt mit einer Kante verbunden sein kann. Die Objekte in einem Basisgraphen werden dementsprechend klassifiziert, wie im Folgenden beschrieben. Es stellt ebenso eine gewählte Notation für die Objekteigenschaften bereit.
Knoten (Obiekt) Klassifizierung und Notation

U: Ist Beanstander, unbekannte Beanstandungsstelle
Cr: Ist Beanstander, bekannte Beanstandungsstelle
Ce: Ist Beanstandungsstelle
S: Hat spezifische Fehlermeldung

Jedes Objekt in einem Basisgraphen kann natürlich jede Kombination dieser Eigenschaften aufweisen und, in Analogie mit dem bit-weisen oder-Operator in C und C++, wird die Kombination von Eigenschaften zum Beispiel als S bezeichnet. Dieser Ausdruck bezeichnet eine Beanstandungsstelle mit einer spezifischen Fehlermeldung, die sie zu einem guten Kandidaten macht, dem echten Fehler nahe zu sein. Siehe 5, welche schematisch vier mögliche Eigenschaften eines Basisgraphknoten gemäß der vorliegenden Erfindung darstellt, für ein Objekt 50 mit Klassifizierung U. Wenn die Anzahl von Kanten eines spezifischen Typs, mit dem ein Objekt verbunden ist, nicht berücksichtigt wird, ist die Gesamtanzahl von möglichen Objektklassifizierungen 15.
Die eingesetzte Strategie wird einfach bzw. geradlinig, und ein spezieller Fall hat die Knoten in dem Basisgraphen ausgewählt, die keine Beanstandungsstelle oder eine spezifische Fehlermeldung aufweisen, d.h. niemanden, der zu „bezichtigen" wäre, verwendet das Modell, um mögliche Beanstandungsstellen zu finden, die sich bereits in dem Basisgraphen befinden, und erweitert den Graphen entsprechend.
Mit einer solchen Strategie im Kopf werden die 15 Objektklassifizierungen in drei Hauptgruppen aufgeteilt. (Die Klassifizierungen der ersten zwei Gruppen sind gut gebildet benannt, im Gegensatz zu den Klassifizierungen der letzten Gruppe)
Drei-Knoten(Obiekt) Klassifizierungsgruppen
Ein Pseudo-Code für einen möglichen „ExtendGraph" bzw. „ErweitereGraph"-Algorithmus und für den ganzen Graphen wird wie folgt. Die Grapherweiterung für ein einzelnes Objekt ist hier in einer folgenden Subroutine angeordnet worden, genannt ExtendGraph.
Der ErweitereGraph-Algorithmus
Die Grapherweiterung für ein einzelnes Objekt ist hier in einer folgenden Subroutine angeordnet worden, genannt ErweitereGraph.
Der ErweitereGraph-Algorithmus
Wenn entschieden worden ist, den Graphen für ein spezifisches Objekt zu erweitern, wird das UML Modell, siehe 430 in 4, verwendet, um alle möglichen Server dieses Objekts zu nummerieren. Das Objekt, für das Beanstandungsstellen gesucht werden, wird das ursprüngliche Suchobjekt genannt. Die Klasse, die dem ursprünglichen Suchobjekt entspricht, wird die ursprüngliche Suchklasse genannt.
Wenn es ein Objekt bereits in dem Basisgraphen gibt, das der gefundenen Serverklasse entspricht, wird diese Information verwendet, um zu „erraten", dass dies eine gültige Verbindung in dem derzeitigen Fehlerszenario ist, und den Graphen zu erweitern. Da die Suche auf Assoziationsinformation beruht, im Gegensatz zu instanziierten Verbindungen, und die gefundenen Server natürlich nur Klassen sind, ist nicht mit Sicherheit bekannt, ob ein Objekt, das der Klasse entspricht, in dem derzeitigen Fehlerszenario aktiv ist.
Die Suche in dem UML Modell 430 stellt eine Kette von Klassen bereit, die durch durchfahrbare bzw. navigierbare (navigable) Assoziationen verbunden sind, wobei die erste Klasse immer die ursprüngliche Suchklasse oder eine Unterklasse der ursprünglichen Suchklasse ist. Eine solche Kette wird eine Serverkette genannt. Eine Serverkette ist schematisch in 6 dargestellt, als ein allgemeines Beispiel eines UML Durchlauf-Algorithmus.
Die Erweiterung des Graphen besteht aus dem Erzeugen von Knoten 60 und Kanten 62, die den Klassen und Assoziationen in der Serverkette entsprechen. Pseudo-Code für den Algorithmus ist vorstehend gezeigt. Die Nummerierung von Servern unter Verwendung des UML Modells wird in einer breiten ersten Weise ausgeführt und ist im Folgenden im Detail beschrieben.
Da das Softwaremodell sehr groß sein kann, und da es nicht stark auf statische Klasseninformation angewiesen sein soll, kann die Suchtiefe in der Servernummerierung begrenzt werden. Die Suchtiefe ist die Anzahl von verwendeten Assoziationen, um von der ursprünglichen Klasse zu dem letzten Server in der Serverkette zu gelangen.
Wenn die erste Anforderung, dass der Graph verbunden und azyklisch ist, erfüllt ist, dann könnte eine Maßnahme der Verlässlichkeit 440 sein
was 1 ist, falls keine Kanten 62 hinzugefügt werden müssen.
Der ExtendGraph-Algorithmus kann verbessert werden durch Einführen einer Priorität auf den Objekten in dem Graphen, wenn es einige Objekte gibt, die als eine Beanstandungsstelle für das ursprüngliche Suchobjekt dienen könnten. Eine natürliche Priorität ist es, zuerst Knoten mit Klassifizierungen von der „OK wie es ist"-Gruppe als abgeleitete Beanstandungsstellen zu berücksichtigen. Wenn dies fehlschlägt, werden Knoten mit Klassifizierungen von der „Benötigt Beanstandungsstelle"-Gruppe berücksichtigt. Diese Strategie erfordert entweder zwei Durchläufe des UML Modells, oder ein Zwischenspeichern von Serverketten mit derem letzten Element entsprechend „Benötigt Beanstandungsstelle"-Knoten.
Da Superklassen der gesuchten bzw. durchsuchten Server, sowohl die ursprünglichen als auch die anderen, nicht zurückgegeben werden, muss nicht nur überprüft werden, ob die zurückgegebenen Server selbst in dem Graphen sind, sondern auch, ob es eine Superklasse der zurückgegebenen Server bereits in dem Graphen gibt. Der Grund für diese Unbequemlichkeit ist, dass es wünschenswert ist, das Hinzufügen einer Superklasse eines Servers zu vermeiden, um den Graphen so spezifisch wie möglich zu belassen, aber wenn die Superklasse bereits vorhanden ist, aufgrund von Fehlermeldungen oder anderen Grapherweiterungen, sollte sie beim Erweitern verwendet werden.
Eine Klasse, für welche Server gesucht werden, wird eine Suchklasse genannt werden, und die Klasse, für die die Suche begonnen wurde, wird die ursprüngliche Suchklasse genannt.
Eine Serverkette ist eine Klassenkette, die aus Klassen besteht, die durch durchfahrbare Assoziationen in dem UML Modell verbunden sind. Die erste Klasse ist immer die ursprüngliche Suchklasse oder eine Unterklasse der ursprünglichen Suchklasse. Die Suchtiefe der Suchkette ist definiert als die Anzahl von Assoziationen, die verwendeten werden, um von der ursprünglichen Suchklasse zu dem letzten Server in der Kette zu gelangen. Diese Ansicht der Nähe von Klassen wird manchmal als die Assoziations-Norm bezeichnet, auch wenn sie natürlich streng genommen keine Norm ist.
Da der Algorithmus einen Strom von Serverketten zurückgibt, ist er in zwei Teilen definiert, GetFirstServer bzw. HoleErstenServer und GetNextServer bzw. HoleNächstenServer. Pseudo-Code für die zwei Teile wird folgend gezeigt.
Der UML Durchlauf-Algorithmus Pseudo-Code
6 stellt eine Durchlauf-Reihenfolge des UML Modells dar, wenn nach möglichen Beanstandungsstellen für eine ursprüngliche Suchklasse genannt „red" gesucht wird.
Ein Beispiel ist in 6 gezeigt, mit einer ziemlich komplizierten Klasse und allen Serverketten, die von dem Algorithmus für die ursprüngliche Suchklasse „red" erzeugt worden sind, in Tabelle 1. Die verwendete Suchtiefe ist 2. Die Nummerierungen der Klassen haben die Semantik <Suchtiefe>.<Laufende Zahl>.
Sowohl Super- als auch Unterklassen der ursprünglichen Suchklasse werden nach Servern durchsucht, siehe Klassen 1.6 bzw. 1.7 und 1.8 in Tabelle 1. Superklassen müssen durchsucht werden, da die Assoziationen ererbt sind, und Unterklassen müssen durchsucht werden, da die Fehlermeldung oder Grapherweiterung, welche die ursprüngliche Suchklasse eingeführt hat, eine Superklasse der Klasse herausgestellt haben könnte, die tatsächlich in dem unter Betrachtung stehenden Szenario aktiv ist.
Alle Unterklassen eines möglichen Servers werden nummeriert als mögliche Server selbst, siehe 1.3 bis 1.5 in Tabelle 1. In diesen Serverketten ist nur die Unterklasse und nicht der ursprüngliche Server vorhanden, da die Assoziation, die zu einem Elternteil führt, als ererbt angesehen wird.
Superklassen eines Servers werden nicht zurückgegeben, da die Assoziation, die zu dem Server führt, spezifisch die Superklasse ausschließt. Zum Beispiel, die Klassen „redSup" und „B1" in Tabelle 1 werden nicht zurückgegeben. Server der Superklassen werden dennoch zurückgegeben, da diese Assoziation ererbt ist. In der Serverkette ist ausgewählt, die Superklasse selbst nicht einzuschließen, da die Assoziation als ererbt angesehen wird.
In einer bevorzugten Ausführungsform des Systems der vorliegenden Erfindung ist es gedacht für das Isolieren eines Fehlers aus einer Vielzahl von Fehlermeldungen in einem Systemprotokoll 200 eines Vorgangs, der von einem objektorientierten Programm 110 gesteuert wird. Jede Fehlermeldung der Vielzahl von Fehlermeldungen umfasst eine vorbestimmte Signatur, und eine Schnittstelle ist zwischen dem Programm und einem Mittel für die Vorgangssteuerung angeordnet. Wobei die Schnittstelle Mittel zum Zusammenstellen 210 von Fehlermeldungen umfasst, die zu einem Fehlerszenario des Fehlers gehören. Ebenso Mittel zum Bilden einer formalen Darstellung, eines Basisgraphen 410, aus den Signaturen der zusammengestellten 210 Fehlermeldungen des Fehlerszenarios. Weiter umfasst es Mittel zum Analysieren 230 der formalen Darstellung, um den Fehler zu isolieren, und Mittel zum Berichten von Information enthaltend den Fehler an das Vorgangssteuerungsmittel, welches Mittel bereitstellt, um sich des Fehlers anzunehmen.
Daher ist die Vorgangssteuerung in der Lage, den erfassten Fehler in einer viel schnelleren Art aufrecht zu erhalten bzw. zu warten, zu reparieren, zu diagnostizieren etc., als es im Stand der Technik bekannt ist.
Eine Signatur umfasst Information über Beanstandung, Beanstander und Beanstandungsstelle, und die Signatur ist gebildet aus einem Erklärungsmodell umfassend eine grundlegende Annahme einer Kommunikation zwischen Systementitäten, die erforderlich sind, um eine bestimmte Aufgabe auszuführen. Systementitäten umfassend Objekte 60, Pakete und Threads.
Bezüglich des Zeitabschnitts startet er in einer Ausführungsform der vorliegenden Erfindung mit der ersten Fehlermeldung in dem Fehlerszenario und endet mit einer Stoppmeldung.
In einer Ausführungsform der Erfindung umfasst das System weiter Mittel zum Erstellen einer Verlässlichkeitsabschätzung 440 des Fehlers, und dass die Fehlerinformation die Abschätzung enthält.
Wenn der Basisgraph 410 nicht aussagekräftig ist, umfasst das System weiter, in einer Ausführungsform der Erfindung, Mittel zum Erweitern davon durch Bereitstellen eines Systemmodells 220, enthaltend Information über Abhängigkeitsbeziehungen zwischen Systementitäten, und Mittel zum Isolieren des Fehlers aus dem erweiterten Graphen 420 durch Verwendung von vorbestimmten Erklärungsregeln.
In einer Ausführungsform des Systems gemäß der vorliegenden Erfindung wird es in einem Vorgang verwendet, der einen Industrieroboter einbezieht.
Eine andere Ausführungsform der vorliegenden Erfindung stellt ein Computerprogrammcode-Element bereit, umfassend Computercodemittel, um einem Prozessor zu ermöglichen, einen Fehler aus einer Vielzahl von Fehlermeldungen in einem Systemprotokoll 200 eines Vorgangs zu isolieren, der von einem objektorientierten Programm 110 gesteuert wird. Dadurch wird einem Prozessor ermöglicht, die Schritte auszuführen:

– Bilden einer Schnittstelle zwischen dem Programm 110, das die Vielzahl von Fehlermeldungen erzeugt, und einem Vorgangssteuerungsmittel;
– Erzeugen einer Zusammenstellung 210 aus der Vielzahl von Fehlermeldungen, die zu einem Fehlerszenario des Fehlers gehören;
– Analysieren der Zusammenstellung 400 unter Verwendung vorbestimmter Fehlermeldungssignaturen und eines vorbestimmten Systemmodells 220, um den Fehler zu isolieren; und
– Berichten von Information, die den Fehler enthält, an das Steuermittel, welches Mittel bereitstellt, die sich des Fehlers annehmen.

Das Code-Element ist einer Ausführungsform der vorliegenden Erfindung auf einem computerlesbaren Medium enthalten.
Weiter wird das Code-Element in einer Ausführungsform der vorliegenden Erfindung zumindest teilweise über ein Netzwerk bereitgestellt, so wie das Internet.
In einer anderen Ausführungsform der vorliegenden Erfindung wird ein computerlesbares Medium bereitgestellt, enthaltend ein Computerprogrammcode-Element umfassend Computercodemittel, um einem Prozessor zu ermöglichen, einen Fehler aus einer Vielzahl von Fehlermeldungen in einem Systemprotokoll 200 eines Vorgangs zu isolieren, der von einem objektorientierten Programm 110 gesteuert wird. Wodurch dem Prozessor ermöglicht wird, die Schritte auszuführen:

– Bilden einer Schnittstelle zwischen dem Programm, das die Vielzahl von Fehlermeldungen erzeugt, und einem Vorgangssteuerungsmittel;
– Erzeugen einer Zusammenstellung 210, 400 aus der Vielzahl von Fehlermeldungen, die zu einem Fehlerszenario des Fehlers gehören;
– Analysieren 230 der Zusammenstellung 400 unter Verwendung vorbestimmter Fehlermeldungssignaturen und eines vorbestimmten Systemmodells 220, um den Fehler zu isolieren; und
– Berichten von Information, die den Fehler enthält, an ein Steuermittel, das Mittel bereitstellt, um sich des Fehlers anzunehmen.

Ebenso ist das System gemäß der vorliegenden Erfindung in der Lage, in einem Verfahren Merkmale wie vorstehend beschrieben auszuführen.
Mittel, die in der Schnittstelle verwendet werden, sind zum Beispiel Software und Softwaretreiber, jede Art von geeigneter Anzeige etc., und andere Mittel, die einem Fachmann bekannt sind.
Es wird daher davon ausgegangen, dass der Betrieb und die Ausführungsformen der vorliegenden Erfindung einem Fachmann aus der vorstehenden Beschreibung ersichtlich sein werden. Obwohl das Verfahren und die Schnittstelle, die gezeigt oder beschrieben worden sind, als bevorzugt angesehen werden, wird es ersichtlich sein, dass vielfältige Änderungen und Modifikationen daran gemacht werden können, ohne den Schutzumfang der vorliegenden Erfindung zu verlassen, wie er in den angehängten Ansprüchen definiert ist.
Tabelle 1

Claims

Verfahren zum Isolieren eines Fehlers aus einer Vielzahl von Fehlermeldungen in einem Systemprotokoll (200) eines Vorgangs, der durch ein objektorientiertes Programm (110) gesteuert wird, gekennzeichnet durch die Schritte: – Erzeugen einer vordefinierten Signatur für jede Fehlermeldung der Vielzahl von Fehlermeldungen; – Bilden eines Zeitabschnitts, um aus der Vielzahl von Fehlermeldungen die Fehlermeldungen festzulegen, die zu einem Fehlerszenario des Fehlen gehören; – Zusammenstellen (210) der Fehlermeldungen, die in den Zeitabschnitt fallen; – Bilden eines Basisgraphen (410), der eine formale Darstellung des Fehlerszenarios ist, und der Information über die Beziehung von Ursache-Wirkung dieser Fehlermeldungen trägt, aus den Signaturen der zusammengestellten (210, 400) Fehlermeldungen; – Analysieren (230) des Basisgraphen (410), um den Fehler zu isolieren; und – Berichten von Information, welche den Fehler enthält, an ein Steuermittel, das Maßnahmen bereitstellt, um sich des Fehlers anzunehmen.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass jede der Signaturen dazu gebracht wird, Informationen über die Beanstandung (complaint) und den Beanstander (complainer) zu enthalten.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass ein Erklärungsmodell gebildet wird, aus einer grundlegenden Annahme einer Kommunikation zwischen Systementitäten, die nötig sind, um eine bestimmte Aufgabe auszuführen, wobei die Systementitäten Objekte, Pakete und Threads umfassen, und die Signaturen auf der Basis des Erklärungsmodells definiert sind.
Verfahren nach irgendeinem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Zeitabschnitt mit der ersten Fehlermeldung in dem Fehlerszenario beginnt und mit einer Stoppmeldung endet.
Verfahren nach irgendeinem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die berichtete Information eine Verlässlichkeitsabschätzung (430) des Fehlers umfasst.
Verfahren nach irgendeinem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass im Falle eines nicht aussagekräftigen Basisgraphen (410) der Analysierungsschritt weiter die Schritte umfasst: – Erweitern (420) des Basisgraphen (410) mit Hilfe eines Systemmodells (220), enthaltend Information über die Abhängigkeitsbeziehung zwischen Systementitäten; und – Analysieren (230) des erweiterten Basisgraphen (420) mit einem Satz vorbestimmter Erklärungsregeln, um den Fehler zu isolieren.
Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass das Systemmodell (220) unter Verwendung der „Unified Modeling Language" (UML) (430) gebildet wird.
Verwendung eines Verfahrens gemäß irgendeinem der vorhergehenden Ansprüche in einem Vorgang unter der Einbeziehung eines Industrieroboters.
System zum Isolieren eines Fehlers aus einer Vielzahl von Fehlermeldungen in einem Systemprotokoll (200) eines Vorgangs, der durch ein objektorientiertes Programm gesteuert wird, gekennzeichnet – dadurch, dass jede Fehlermeldung der Vielzahl von Fehlermeldungen eine vorbestimmte Signatur aufweist; – dass ein Zeitabschnitt gebildet wird, um aus der Vielzahl von Fehlermeldungen die Fehlermeldungen festzulegen, die zu einem Fehlerszenario des Fehlers gehören; – durch Zusammenstellen (210) der Fehlermeldungen, die in den Zeitabschnitt fallen; – dadurch, dass eine Schnittstelle zwischen dem Programm (110) und einem Mittel zur Vorgangsteuerung angeordnet ist, wobei die Schnittstelle Mittel zum Zusammenstellen (210, 400) von Fehlermeldungen umfasst, die zu einem Fehlerszenario des Fehlers gehören, – durch Mittel zum Bilden einer formalen Darstellung, eines Basisgraphen (410) des Fehlerszenarios, aus den Signaturen der zusammengestellten (210, 400) Fehlermeldungen; – Mittel zum Analysieren (230) der formalen Darstellung, um den Fehler zu isolieren; und – Mittel zum Berichten von Information enthaltend den Fehler an das Vorgangsteuerungsmittel, welches Mittel bereitstellt, um sich des Fehlers anzunehmen.
System nach Anspruch 9, dadurch gekennzeichnet, dass die Signatur Information über die Beanstandung, den Beanstander und die Beanstandungsstelle (complainee) umfasst, und dass die Signatur aus einem Erklärungsmodell gebildet ist, umfassend eine grundlegende Annahme einer Kommunikation zwischen Systementitäten, die erforderlich sind, um eine bestimmte Aufgabe auszuführen, wobei die Systementitäten Objekte, Pakete und Threads umfassen.
System nach Ansprüchen 9–10, dadurch gekennzeichnet, dass der Zeitabschnitt mit der ersten Fehlermeldung in dem Fehlerszenario beginnt und mit einer Stoppmeldung endet.
System nach Ansprüchen 9–11, dadurch gekennzeichnet, dass das System Mittel umfasst, um eine Verlässlichkeitsabschätzung (440) des Fehlers zu erstellen, und dass die Fehlerinformation die Abschätzung umfasst.
Verfahren nach Ansprüchen 9–12, dadurch gekennzeichnet, dass im Falle, dass der Basisgraph (410) nicht aussagekräftig ist, das System weiter Mittel umfasst, um den Basisgraphen (410) mit Hilfe eines Systemmodells (220) zu erweitern (420), enthaltend Information über die Abhängigkeitsbeziehung zwischen Systementitäten, und Mittel zum Isolieren des Fehlers aus dem erweiterten Graphen (420) durch Verwendung von vorbestimmten Erklärungsregeln.
System nach Anspruch 13, dadurch gekennzeichnet, dass die „Unified Modeling Language" (UML) (430) verwendet wird, um das Systemmodell (220) zu bilden.
Verwendung eines Verfahrens gemäß den Ansprüchen 9–14 in einem Vorgang unter der Einbeziehung eines Industrieroboters.
Computerprogrammcode-Element, umfassend Computercodemittel, um einem Prozessor zu ermöglichen, einen Fehler aus einer Vielzahl von Fehlermeldungen in einem Systemprotokoll (200) eines Vorganges zu isolieren, der von einem objektorientierten Programm (110) gesteuert wird, indem dem Prozessor ermöglicht wird, die Schritte des Verfahrens nach irgendeinem der Ansprüche 1–7 auszuführen.
Computerprogrammcode-Element nach Anspruch 16, enthalten auf einem computerlesbaren Medium.
Computerprogrammcode-Element nach Anspruch 16, zumindest teilweise über ein Netzwerk wie das Internet bereitgestellt.
Computerlesbares Medium, enthaltend ein Computerprogrammcode-Element, umfassend Computercodemittel, um einem Prozessor zu ermöglichen, einen Fehler aus einer Vielzahl von Fehlermeldungen in einem Systemprotokoll (200) eines Vorganges zu isolieren, der von einem objektorientierten Programm (110) gesteuert wird, durch das dem Prozessor ermöglicht wird, die Schritte des Verfahren nach irgendeinem der Ansprüche 1–7 auszuführen.