DE19944359C2

DE19944359C2 - Operationsgraphgestützte Ereignisüberwachung

Info

Publication number: DE19944359C2
Application number: DE1999144359
Authority: DE
Inventors: Thomas Buechner; Rolf Fritz; Markus Helms; Kirk Lamb; Thomas Schlipf; Manfred Walz
Original assignee: IBM Deutschland GmbH
Current assignee: International Business Machines Corp
Priority date: 1998-10-30
Filing date: 1999-09-16
Publication date: 2003-03-27
Anticipated expiration: 2019-09-17
Also published as: DE19944359A1

Description

ANWENDUNGSGEBIET DER ERFINDUNG

Die vorliegende Erfindung bezieht sich im allgemeinen auf die Hardware von Computersystemen und im besonderen auf ein Verfahren und ein System zur Verfolgung von Systemoperationen eines Computersystems.

HINTERGRUND DER ERFINDUNG

Während des Betriebs eines Computersystems können viele unterschiedliche Betätigungsformen auftreten, beispielsweise das Drücken der Eingabetaste auf der Tastatur, das Laden von Daten von einer Festplatte in den Arbeitsspeicher oder aber es können schwerwiegende Fehler auftreten, die es nachzuverfolgen gilt. Es gibt systeminterne Ereignisse oder Ereignisse, die von außerhalb in das System gelangen, beispielsweise durch den Benutzer eines Systems. Die genannten Ereignisse sind Bestandteile der Operationen des Computersystems. In einem Computersystem gibt es eine breite Palette an Operationen, beispielsweise die Datenübertragung von der Festplatte in den Arbeitsspeicher, Statusanforderungen, die sich auf alle im Computersystem befindlichen Geräte beziehen können, usw. Während einer solchen Operation durchlaufen entweder Benutzerdaten oder Steuerdaten, die vom Computersystem initiiert oder ausgewertet werden, eine oder mehrere sogenannte funktionale Einheiten, die im Zusammenhang mit der vorliegenden Erfindung als Elemente des Computersystems bezeichnet werden können.

Bedingt durch die hohe Integration von Computersystemen ist es notwendig geworden, Hardwarefehler-Beseitigungsfunktionen in das Computersystem zu integrieren. Während der Hardware- Entwicklungsphase wird die Fehlerbeseitigung normalerweise in einer Simulation durchgeführt. Nachdem jedoch die Hardware auf dem Markt angelangt ist, kann eine Fehleranalyse nur mit Verfolgungsdaten vorgenommen werden, die von der Hardware selbst erstellt werden.

Der neueste Stand der Technik bei der Verfolgung von Ereignissen sind Einheiten, die eine feste Auswahl möglicher Eingaben vornehmen; hierbei handelt es sich um eine standortzentrische Vorgehensweise. Im US-Patent Nr. 5,355,484 sind überwachende sogenannte off-chip- Schnittstellen, überwachende Schnittstellen zwischen funktionalen Einheiten und die Überwachung durch Kopieren von Befehlen und Daten in Arrays die verwendeten Tools und Methoden.

Diese standortzentrische Vorgehensweise ist jedoch in ihrem praktischen Nutzen beschränkt, da solche Methoden durch die Tatsache gekennzeichnet sind, daß sich die Abfolge der Operationen aufgrund der Beschränkungen der Verfolgungs- Arrays nur mit einer kurzen Rückreichweite analysieren läßt; darüber hinaus ist die Ansicht einer solchen Rückverfolgung auf eine bestimmte funktionale Einheit begrenzt, das heißt, eine sogenannte isolierte Ansicht beschränkt die Gesamtanalyse, und letztlich ist die Verfolgung vollkommen unabhängig von der Fehlersuche.

In den heutigen Systemen sind jedoch zahlreiche Warteschlangen und Puffer im Datenfluß enthalten, um zu ermöglichen, daß mehrere Operationen gleichzeitig ablaufen können. Die Steuerlogik dieses Datenflusses wird viel komplexer, was die Fehlerbeseitigung im System wesentlich schwieriger macht. Ein Chip kann beispielsweise so komplex ausgelegt sein, daß er gleichzeitig maximal 24 ausstehende Operationen verarbeiten kann.

Um das Verhalten eines solchen Systems überwachen und analysieren zu können, ist eine standortzentrische Vorgehensweise, wie sie oben beschrieben ist, nicht mehr ausreichend, da die durch die gleichzeitig ablaufenden Operationen bedingte Komplexität den analysierenden Benutzer des Verfolgungssystems daran hindert, einen gesamtanalytischen Überblick über das System zu erhalten.

Somit ist das Ziel der vorliegenden Erfindung, eine ausreichend umfassende Rückverfolgung von Operationen in einem Computersystem, in dem viele unterschiedliche Operationen in vielen unterschiedlichen Systemwarteschlangen und Puffern gleichzeitig verarbeitet werden, zu ermöglichen.

Dieses Ziel wird erreicht, indem ein Verfahren gemäß Anspruch 1 und ein System gemäß Anspruch 5 bereitgestellt wird.

Um voneinander separate Operationen in Systemen mit vielen langen Warteschlangen gleichzeitig mitverfolgen zu können, wird eine im Hintergrund arbeitende Ereignisüberwachung vorgeschlagen. Für jede schwebende Operation verwendet der Monitor die Hardware-Implementierung eines ereignisabhängigen Operationsgraphs, um den Pfad der Operation durch das System mitzuverfolgen. Für jeden verfolgten Pfad wird eine eindeutige Signatur erstellt, die den Umfang der zu speichernden Verfolgungsdaten entscheidend reduziert. In einem bevorzugten Ausführungsbeispiel des Verfahrens und des Systems der vorliegenden Erfindung werden die Informationen zusammen mit einem Zeitstempel gespeichert, um Fehler zu beseitigen und die Warteschlangeneffekte sowie das Zeitverhalten in einem System zu messen.

Die zugrundeliegende Idee zur Lösung des Problems, das der vorliegenden Erfindung innewohnt, besteht darin, eine Verfolgungslogik bereitzustellen, die ihre Hauptausrichtung auf Operationen und nicht nur auf einen Teil einer Logik oder einer funktionalen Einheit hat. Der Pfad einer Operation innerhalb eines Systems wird verfolgt und in einem Array gespeichert. Diese Art der Verfolgung ist von Chip- Begrenzungen oder Begrenzungen funktionaler Einheiten unabhängig. Jede Operation besitzt eine Kennung, die während des gesamten Verlaufs der Operation durch alle funktionale Einheiten hindurch unverändert bleibt. In Übereinstimmung mit der vorliegenden Erfindung erzeugt jede funktionale Einheit Ereignisse für eine spezifische Operation, nämlich ein Ereignis für jede Kennung. Ein zentrales Verfolgungs- Array sammelt die Ereignisse aus den verschiedenen Einheiten und erstellt daraus ein Gesamtbild der Operation. Nur diese zentrale Einheit muß Informationen in ein Array speichern. Auf diese Weise wird der Operationsfluß in einem System durch einen eigenen Statusrechner überwacht, der als ''Graph'' der Operation dient und fortan als Operation Graph Finite State Machine (OGFSM) bezeichnet wird. Hierbei handelt es sich um eine Hardware-Beschreibung, die die Nebenaufgaben und die Abfolge jeder Operation, die das System durchlaufen kann, ''kennt'' und auf diese Weise die Operation der Hardware überwacht.

Mit dem Verfahren und dem System werden in Übereinstimmung mit der vorliegenden Erfindung einer oder mehrere der folgenden Vorteile erzielt:
Die Verfolgung läßt sich mit der Fehlersuche kombinieren.

Zeitliche Abhängigkeiten zwischen unterschiedlichen Operationen können für den Benutzer transparent gemacht werden.

Die Verfolgung läßt sich mit einem Mindestmaß an Verfolgungsdaten durchführen.

Das gesamte System oder Subsystem läßt sich verfolgen. Die Perspektive der Analyse ist nicht länger auf Chip- Begrenzungen oder andere Hardware-Elemente beschränkt.

Es läßt sich der gesamte Verlauf einer Operation verfolgen, das heißt, es ist eine Überwachung der Steuerlogik und nicht länger nur eine Überwachung des Datenflusses möglich. Somit sind die Analyse und die Fehlersuche bequemer, einfacher und schneller.

Für gleichzeitig ablaufende Operationen läßt sich das zeitliche Verhalten verfolgen, also Übernahmeanalysen, Überhänge usw.

Der Operationsgraph ist als endlicher Statusrechner spezifiziert, der die Möglichkeit hat, die Fehlersuche in Echtzeit durchzuführen; es wird nur ein Trace-Array benötigt, mehrere Arrays mit redundanten Daten sind nicht erforderlich. Somit ist die Datenmenge auf ein Mindestmaß beschränkt.

Die eindeutige Kennung ermöglicht es, den Verlauf einer Operation zu verfolgen, auch wenn es Chip-Begrenzungen gibt; die in einem Verfolgungs-Array zu speichernde Datenmenge wird durch die Erzeugung eindeutiger Signaturen für jeden möglichen Operationsverlauf auf ein Mindestmaß reduziert.

Weitere Ziele, Merkmale und Vorteile der vorliegenden Erfindung werden aus den beiliegenden Zeichnungen sowie aus der nachfolgenden ausführlichen Beschreibung ersichtlich.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die vorliegende Erfindung wird beispielhaft veranschaulicht und ist nicht auf die Darstellung in den nachfolgenden beiliegenden Zeichnungen beschränkt.

Fig. 1 ist ein Blockdiagramm, das die wichtigsten Schritte eines bevorzugten Ausführungsbeispiels des Verfahrens der vorliegenden Erfindung darstellt,

Fig. 2 ist eine schematische Darstellung des Steuer- und Datenflusses während des Verlaufs des Verfahrens der vorliegenden Erfindung,

Fig. 3 ist eine schematische Darstellung einer Operation Graph Finite State Machine (OGFSM) in Übereinstimmung mit der Vorliegenden Erfindung,

Fig. 4 ist eine schematische Darstellung, die den Steuer- und Datenfluß zeigt, den die OGFSMs während des Verfahrens der vorliegenden Erfindung verarbeiten,

Fig. 5 ist eine schematische Darstellung eines modifizierten bevorzugten Ausführungsbeispiels des Verfahrens und des Systems der vorliegenden Erfindung, die die Datenkompression der verfolgten Daten einschließt,

Fig. 6 ist eine schematische Darstellung des Steuerflusses innerhalb eines OGFSM, und

Fig. 7 ist eine Tabelle, in der die möglichen Statussequenzen und ihre MISR-Werte, die für das Verfahren gemäß der vorliegenden Erfindung benötigt werden, aufgeführt sind.

AUSFÜHRLICHE BESCHREIBUNG DER ERFINDUNG

Unter Bezugnahme auf die Zeichnungen und unter besonderer Berücksichtigung von Fig. 1 wird nun ein bevorzugtes Ausführungsbeispiel des Verfahrens der vorliegenden Erfindung beschrieben:
In einem ersten Schritt 110 wird jeder Systemoperation eine eindeutige Kennung zugewiesen. Bei dieser Kennung kann es sich um eine Zahl handeln, die lang genug ist, um alle Operationen, die sich gleichzeitig überwachen lassen, eindeutig zu bezeichnen. Die Kennungen werden wiederverwendet, nachdem die jeweilige Operation nicht mehr benötigt oder das Computersystem neu gestartet wird.

Als nächstes wird in Schritt 120 jede Operation ihrem eigenen Operationsgraph zugewiesen. Alle Operationsgraphen, bei denen es sich um durch das System verwaltete Prozesse handelt, können Eingäben von jeder während des Verlaufs der Operation betroffenen funktionalen Einheit empfangen und Verfolgungsinformationen in eine Verfolgungseinheit, in der die Verfolgungsdaten gesammelt werden, schreiben. Da jede Operation normalerweise aus mehreren Nebenschritten besteht und die Nebenschritte sequenziell ausgeführt werden, kann die Abfolge der Nebenschritte als ein gerichteter Graph dargestellt werden, der hier als ''Operationsgraph'' bezeichnet wird. Jeder Nebenschritt, der von einer funktionalen Einheit ausgeführt wird, erzeugt ein Ereignis, das für jede Operation spezifisch ist und das für jede funktionale Einheit, die im Verlauf der Operation beteiligt ist, spezifisch ist. Diese Ereignisgenerierung erfolgt in Schritt 130. Im allgemeinen steuert der Operationsgraph die Fertigstellung der Nebenschritte jeder Operation; er weiß, in welchem Status sich jede Operation befinden darf, und außerdem enthält der Operationsgraph die spezifischen Steuerinformationen für jede funktionale Einheit, das heißt, er weiß, daß eine Ereigniszahl 3 nicht erscheinen darf, bevor nicht die Ereigniszahl 2 erschienen ist. Diese Regeln, die in der nachfolgenden Beschreibung als ''Fachwissen'' bezeichnet werden, müssen in der Programmierung des Operationsgraphen enthalten sein.

Darüber hinaus werden alle Ereignisinformationen, die von den Operationsgraphen verarbeitet werden, in einen Speicher gestellt, der allen Operationsgraphen gemein ist. Bei diesem Speicher kann es sich in der vorliegenden Erfindung um einen sogenannten Verfolgungsdaten-Array handeln. Diese Ereignisinformationsdaten enthalten Informationen über den Fertigstellungsgrad eines Nebenschritts oder eines Schritts sowie über den Verlauf der in den betreffenden funktionalen Einheiten nicht erfolgreichen Nebenschritte oder Schritte. Deshalb ist in den genannten Ereignisinformationsdaten eine Auflistung möglicher Fehler und möglicher Ereignisse enthalten.

Wir betrachten nun Fig. 2. Der Steuer- und Datenfluß des beschriebenen Verfahrens sieht aus wie folgt:
Es wird ein Computersystem 10 herangezogen, das bis zu n unabhängige Operationen ermöglicht. Wie oben bereits angeführt wurde, besitzt jede Operation ihre eigene Kennung OID, die durch r indiziert ist, r = (0 . . . n - 1). Diese Operationen können vom System gleichzeitig verarbeitet werden. Darüber hinaus besitzt das zu verfolgende Computersystem 10 eine Anzahl m funktionaler Einheiten 11, Fu_p, p = (1 . . . m). In jeder funktionalen Einheit gibt es eine sogenannte Ereignisgenerierungslogik 12, die die Fertigstellung eines Nebenschritts T_v, n = (1 . . . s), einer Operation OP_r an einen Operationsgraph 14 meldet; diese Logik besitzt die Abkürzung Og_r. Es wird darauf hingewiesen, daß jede Operation ihren eigenen Operationsgraph besitzt, das heißt, FU1 meldet ein Ereignis T₁, das für OID = 2 an OG₂ fertiggestellt wurde.

Wie aus der Zeichnung hervorgeht, werden die Ereignisinformationsdaten, also beispielsweise ''T1 fertiggestellt für OID = 2'' vom entsprechenden Operationsgraph OG₀ . . . OG_r verarbeitet und die entsprechende Ausgabe an eine Verfolgungseinheit 15 geleitet, von der sie von einem Benutzer, der diese Verfolgungsdaten analysieren will, selektiv abgerufen werden können.

Der Operationsgraph 14 wird als operation graph finite state machine (OGFSM) implementiert. Mit Hilfe des OGFSM wird die Hardware des Computersystems überwacht. Es handelt sich hierbei um eine Hardware-Beschreibungssprache, die in Tabellen den tatsächlichen Zustand einer Operation zusammenfaßt, die daraufhin in einen zweiten, nachfolgenden Zustand übergeht, wenn ein Eingabevektor auf den OGFSM angewandt wird. Alle Zustände werden in einem Register gespeichert. Tritt ein unerwartetes Ereignis auf, das in den OGFSM gestellt wird, geht der OGFSM in einen Fehlerzustand über, und es wird eine Fehlermeldung angezeigt.

Wir betrachten nun Fig. 3. Die Implementierung des Operationsgraphs wird beschrieben wie folgt:
Normalerweise besteht eine Operation aus mehreren Nebenschritten, die nacheinander durchlaufen werden. Somit läßt sich diese Abfolge als gerichteter Graph oder Operationsgraph darstellen, der sich als finite state machine (FSM) spezifizieren und verwirklichen läßt.

Es wird darauf hingewiesen, daß ein einziger Operationsgraph das Verhalten unterschiedlicher Operationsarten beschreiben kann. Für jede Operationsart kann eine Ereignisabfolge definiert werden, die der Fertigstellung oder Initiierung eines Nebenschritts entspricht.

Der in Fig. 3 dargestellte Operationsgraph ermöglicht die Überwachung drei verschiedener Operationsarten:
Die Sequenz ''Leerzustand'' → Zustand 0 → Zustand 3 → Leerzustand'' entlang der Bögen 20, 21, 22 entspricht einer Operationsart 1 mit folgenden Nebenschritten: ''Ereignis A von FU1, Ereignis C von FU2, Ereignis G von FU3''.

Darüber hinaus entspricht die Sequenz ''Leerzustand'' → Zustand 0 → Zustand 1 → Zustand 3 → Leerzustand'' entlang der Bögen 20, 23, 24, 22 einer Operationsart 2 mit folgenden Nebenschritten: ''Ereignis A von FU1, Ereignis B von FU2, Ereignis D von FU4, Ereignis G von FU3''.

Mit dem oben beschriebenen Verfahren und System läßt sich auch eine wirkungsvolle Fehlerprüfung vornehmen:
Für die verschiedenen Operationsarten ist nur eine Untergruppe aller möglichen Ereignisse zulässig. Wenn wir beispielsweise Fig. 3 betrachten, dann sind für die Operationsart 1 die Ereignisse B, D, E und F nicht zulässig. Für eine bestimmte Operationsart ist ein Ereignis nur in einem bestimmten Zustand zulässig.

Die Operation Graph State Machine ist so ausgelegt, daß jedes unzulässige Ereignis den Statusrechner (State Machine) veranlaßt, auf einen Fehlerzustand zu verzweigen. Fehleranzeigen können folgendermaßen aussehen:
Die Operationsart 1 befindet sich in Zustand 0, doch das Ereignis G tritt vor Ereignis C auf.

Für die Operationsart 2 gibt es ein Ereignis F; es ist jedoch nicht davon auszugehen, daß die Operation den Zustand 2 erreicht.

Das Ereignis B hat sich für die Operationsart 3 während der Zeit, als IDLE verlassen wurde, bis zum Zeitpunkt, als IDLE erreicht wurde, zweimal ereignet.

Wir betrachten nun insbesondere Fig. 4. Als nächstes wird ein weiteres wesentliches Merkmal der vorliegenden Erfindung beschrieben.

Damit die Erkennung von Interferenzproblemen möglich ist, wird die Verfolgungseinheit 15 in einen Modus umgeschaltet, in dem jede Zustandsänderung in einem der Operationsgraph-Statusrechner (anstatt die Zustände selbst zu registrieren) einen Eintrag in ein Verfolgungs-Array generiert. Jeder Eintrag wird mit einem Zeitstempel versehen, der es ermöglicht, die zeitlichen Abhängigkeiten zwischen den Nebenschritten T_< mehrerer Operationen abhängig von der Zeit t zu messen. Die Einträge im Verfolgungsarray können dann die folgenden Informationen enthalten:
OGFSM für Operation 3 in Zustand 3 zum Zeitpunkt t,
OGFSM für Operation 1 in Zustand 0 zum Zeitpunkt t + 5 Zyklen,
OGFSM für Operation 3 in Zustand IDLE zum Zeitpunkt T + 6 Zyklen, usw.

Wenn die Einträge im Verfolgungsdaten-Array 15 zeitlich sortiert werden, wie dies im unteren Teil von Fig. 4 der Fall ist, lassen sich die zeitlichen Abhängigkeiten zwischen den Nebenschritten T_< und somit die Hauptursachen für eine Nichtfertigstellung eines Nebenschritts anhand der Analysegesamtansicht des Verfolgungsdaten-Array 15 bestimmen.

Wir betrachten nun Fig. 5. Diese Abbildung entspricht Fig. 4 in ihrer Grundstruktur und macht ein weiteres Merkmal des Verfahrens und Systems der vorliegenden Erfindung deutlich, wonach Verfolgungsdaten komprimiert werden, um die Kosten für zusätzliche Hardwarekomponenten zur Pufferung und Speicherung der Verfolgungsdaten weiter zu reduzieren.

Um dies zu erreichen, muß die Anzahl der Verfolgungsdateneinträge so gering wie möglich gehalten werden. Ein erster Schritt zur Senkung der Anzahl von Einträgen wurde bereits in Verbindung mit Fig. 4 beschrieben, indem nur Statusänderungen in den OGFSMs aufgezeichnet werden.

Um eine weitere Senkung zu erzielen, kann das Überwachungssystem in einem Modus verwendet werden, in dem ein Datenkomprimierungsmechanismus eingesetzt wird. In diesem Modus wird nur ein Eintrag für jede Operation erzeugt. Eine ausführlichere Angabe über die Operation läßt sich später anhand des Verfolgungseintrags selbst ableiten, der den vollständigen von der Operation durchlaufenen Pfad in einem komprimierten Format enthält.

In diesem Sinne wird jedem OGFSM ein Signaturregister mit mehreren Eingängen 30 (MISR) hinzugefügt, das anhand der Statuscodes s^t durch Polynomdivision eine Signatur 32 erzeugt.

Die Signatur 32 wird auf der Grundlage der folgenden Regeln in den Verfolgungs-Array 15 gespeichert:

1. Der MISR wird initialisiert, wenn sich der OGFSM im Leerlaufstatus (IDLE) befindet.
2. Mit jeder Statusänderung im OGFSM wird der MISR aktualisiert.
3. Eine Rückverzweigung zu IDLE führt zu ''speichern in Verfolgungs-Array''.
4. Eine Verzweigung in den Fehlerstatus führt zu ''speichern in Verfolgungs-Array''.

Signaturüberwachungssysteme für FSMs werden hauptsächlich verwendet, um permanente Fehler und Durchgangsfehler zu erkennen, die zu Sequenzfehlern führen. Um das zu erreichen, müssen die Signaturen, die man durch Polynomdivision der Statuscodes mit den ausgewählten Polynomen erhalten hat, nach jedem Zustand mit demselben Nachfolger normalerweise identisch sein.

In Übereinstimmung mit der vorliegenden Erfindung wird die entgegengesetzte Art zur Erzeugung der Signatur verwendet:
Die Statuszuweisung für das OGFSM und das Polynom werden so gewählt, daß, angefangen mit dem Status IDLE, jede bestehende Sequenz ihre eigene eindeutige Signatur besitzt. Wenn innerhalb dieser Sequenzen Schleifen vermieden werden, existiert eine endliche Anzahl möglicher Signaturen, die genau den Pfad beschreiben, den das OGFSM durchlaufen hat.

Wir betrachten nun Fig. 6 sowie die Tabelle von Fig. 7. Es werden die verschiedenen Statussequenzen mit den entsprechenden eindeutigen Signaturen dargestellt, um diese Prozedur zu veranschaulichen.

Das in Fig. 6 dargestellte OGFSM besteht aus einem Zustand IDLE, den 13 Ereigniszuständen SPLC, SNSC, UPDT, DCKH, CBSY, CCHK, CMDT, REQS, RXL2, L2GR, L2CX, L2DX und dem Fehlerzustand ERR1.

Wir gehen von zwei Fehlerarten aus:
Einem Fehler, der das OGFSM in den Fehlerzustand (Typ 1) zwingt, und einem anderen Fehler, der lediglich bewirkt, daß das Operationsüberwachungssystem die Signatur des OGFSM- Status (Typ 2), in welchem der Fehler auftauchte, aufzeichnet. Dadurch ergeben sich 197 mögliche Sequenzen durch das OGFSM, die in der Tabelle von Fig. 7 dargestellt sind.

Wenn wir die 4-Bit-OGFSM-Statuskodierung aus Fig. 6 wählen und den Statuswert dividieren, indem wir ein MISR mit einem Polynom 1 + x³ + x¹⁰ verwenden, ergeben sich die 197 eindeutige Signaturen, die in der Tabelle von Fig. 7 aufgelistet sind.

Aus der vorangegangenen Beschreibung werden die folgenden Vorteile deutlich, die teilweise oder vollständig von einem System abgeleitet werden können, in dem das Verfahren der vorliegenden Erfindung angewandt wird:
Das gesamte System oder Subsystem kann aufgezeichnet (verfolgt) werden. Die Analyse ist nicht länger auf Chip- Begrenzungen beschränkt.

Der gesamte Verlauf einer Operation wird verfolgt, das heißt, eine Überwachung der Steuerlogik anstatt nur eine Überwachung des Datenflusses ist möglich.

Bei gleichzeitig ablaufenden Operationen läßt sich das zeitliche Verhalten verfolgen, beispielsweise Übernahmeanalysen, Überhänge usw.

Der Operationsgraph ist als endlicher Statusrechner mit der Möglichkeit einer Fehlerprüfung in Echtzeit spezifiziert.

Es wird nur ein Verfolgungs-Array benötigt, mehrere Arrays mit redundanten Daten sind nicht erforderlich. Dadurch läßt sich die Datenmenge auf ein Mindestmaß beschränken.

Die eindeutige Operationskennung ermöglicht es, den Verlauf einer Operation auch über Chip-Begrenzungen hinweg zu verfolgen, und schließlich wird die in einem Verfolgungs- Array zu speichernde Datenmenge durch die Erzeugung eindeutiger Signaturen für jeden möglichen Verlauf einer Operation auf ein Mindestmaß beschränkt.

Für das Verfahren und das System der vorliegenden Erfindung gibt es viele Anwendungsbereiche, bei denen mehrere Warteschlangen für den Transport gleichzeitiger Operationen verwendet werden. Beispiele für solche Systeme sind Computer-Eingabe/Ausgabe-Subsysteme, Feldbusse, ATM- Schalter, OSI-gestützte Netzwerk- und Kommunikationsgeräte (Router, Brücken, Gateways usw.) von Schicht 2 bis 4.

AUFLISTUNG DER BEZIFFERUNGEN

1

Computersystem

2

funktionale Einheit

12

Ereigniserzeugungslogik

14

Operationsgraph

15

Verfolgungseinheit

20

bis

26

Bögen

30

MISR

32

Signatur

110

bis

140

Verfahrensschritte der vorliegenden Erfindung

Claims

1. Verfahren zur Verfolgung von Operationen eines Computersystems (10), wobei das Verfahren folgende Schritte umfaßt:
Speicherung von operationspfadbezogenen Daten in einen Speicher (15), wobei der Operationspfad eine Beschreibung einer Sequenz von Operationszuständen enthält, charakterisiert durch
die Zuweisung einer eindeutigen Operationskennung zu jeder Operation,
die Tatsache, daß die Operationskennung während der Verarbeitung der Operation durch eine Mehrzahl funktionaler Einheiten (11) des zu verfolgenden Computersystems konstant bleibt, und
Zuweisung einer Operation zu einem dazugehörigen Operationsgraph (14), der für die genannte Mehrzahl der funktionalen Einheiten (11) Zustandssteuerdaten enthält, und
Auswertung der Inhalte des Speichers (15), um Verfolgungsdaten zu erhalten.

2. Verfahren gemäß Anspruch 1, das weiterhin durch die folgenden Schritte charakterisiert ist:
Speicherung von Ereignisdaten, die von den betreffenden funktionalen Einheiten (11) erzeugt wurden und sich auf verschiedene Operationen beziehen, in einem zentralen Speicher (15),
Zuweisung der operationspfadbezogenen Daten zu Zustandsänderungsdaten,
Hinzufügen eines Zeitstempels zu einem Eintrag in den zentralen Speicher (15), und
Auswertung der Inhalte des zentralen Speichers (15) und Suche nach Verfolgungsdaten.

3. Verfahren gemäß Anspruch 2, das durch folgende Schritte charakterisiert ist:
Verwendung von Signaturen (32) zur Kodierung von Zustandssequenzdaten einer Operation mit Hilfe eines Registerspeichermittels (30) und eines Polynoms,
Kennzeichnung der Sequenz mit einem Operationsgraph, der durch einen endlichen Statusrechner (OGFSM) spezifiziert ist.

4. Verfahren gemäß Anspruch 3, das durch folgende Schritte charakterisiert ist:
Erzeugung der Signatur (32), beginnend mit einem Leerzustand (IDLE) der Operation, und
Verknüpfung der Operationszustände für den OGFSM und das Polynom, so daß jede existierende Zustandssequenz, beginnend beim Leerzustand, eine eindeutige Signatur (32) besitzt.

5. Ein Computersystem (10), das folgendes umfaßt:
Mittel zur Speicherung von operationspfadbezogenen Daten in einen Speicher (15), wobei der Operationspfad eine Beschreibung einer Sequenz von Operationszuständen umfaßt,
wobei das System (10) durch folgende Mittel charakterisiert ist:
Mittel zur Zuweisung einer eindeutigen Operationskennung zu jeder Operation,
Mittel, um die Operationskennung während der Verarbeitung der Operation durch eine Mehrzahl funktionaler Einheiten (11) des zu verfolgenden Computersystems konstant zu halten,
Mittel (12) zur Zuweisung einer Operation zu einem zugehörigen Operationsgraph (14), der Zustandssteuerdaten für die Mehrzahl der funktionalen Einheiten (11) enthält, und
Mittel zur Auswertung der Inhalte des Speichers (15), um Verfolgungsdaten zu suchen.

6. System gemäß Anspruch 5, das durch folgende Mittel charakterisiert ist:
Mittel zur Speicherung von Ereignisdaten, die von den betreffenden funktionalen Einheiten (11) erzeugt wurden und sich auf verschiedene Operationen beziehen, in einem zentralen Speicher (15),
Mittel zur Zuweisung der operationspfadbezogenen Daten zu Zustandsänderungsdaten,
Mittel für das Hinzufügen eines Zeitstempels zu einem Eintrag in den zentralen Speicher (15), und
Mittel zur Auswertung der Inhalte des zentralen Speichers (15), um Verfolgungsdaten zu suchen.

7. System gemäß Anspruch 6, das durch folgende Mittel charakterisiert ist:
Mittel zur Verwendung von Signaturen (32) zur Kodierung von Zustandssequenzdaten einer Operation mit Hilfe eines Registerspeichermittels (30) und eines Polynoms,
Mittel zur Kennzeichnung der Sequenz mit einem Operationsgraph, der durch einen endlichen Statusrechner (OGFSM) spezifiziert ist.

8. System gemäß Anspruch 7, das durch folgende Mittel charakterisiert ist:
Mittel zur Erzeugung der Signatur (32), beginnend mit einem Leerzustand (IDLE) der Operation, und
Mittel zur Verknüpfung der Operationszustände für den OGFSM und das Polynom, so daß jede existierende Zustandssequenz, beginnend beim Leerzustand, eine eindeutige Signatur (32) besitzt.

9. Datenträger, auf dem ein Programm gespeichert ist, das das Verfahren gemäß einem der Ansprüche 1 bis 4 implementiert.