DE68928433T2

DE68928433T2 - Verwaltungssystem für verbundene einheiten in einem verteilten rechnersystem

Info

Publication number: DE68928433T2
Application number: DE68928433T
Authority: DE
Inventors: William Adams; Jill Callander; Christine Chan-Lizardo; Timothy Dixon; Leonard Fehskens; Stanley Goldfarb; James Lemmon; Sheryl Namoglu; Linsey O'brien; Dennis Rogers; Richard Rosenbaum; Robert Ross; Robert Schuchard; Mark Seger; David Shurtleff; Danny Smith; Colin Strutt; Mark Sylor; Philip Trasatti
Original assignee: Digital Equipment Corp
Current assignee: Digital Equipment Corp
Priority date: 1988-09-14
Filing date: 1989-09-13
Publication date: 1998-04-16
Anticipated expiration: 2009-09-14
Also published as: US6438591B1; EP0767427B1; AU3980393A; WO1990003005A1; EP0767427A2; AU4305289A; US5475838A; US5832224A; JPH06502505A; AU3980493A; ATE160034T1; EP0441798A1; EP0767427A3; US5557796A; AU3980093A; DE68928433D1; EP0441798B1; AU3980293A; CN1044175A; US5608907A

Description

Hintergrund der Erfindung

Die Erfindung bezieht sich allgemein auf das Gebiet des Managements komplexer Systeme und insbesondere auf Anordnungen zum Managen komplexer Systeme wie z. B. verteilter digitaler Datenverarbeitungs systeme.
Da digitale Datenverarbeitungssysteme oder Computer kleiner und kostengünstiger geworden sind werden einzelne Computer von Einzelpersonen und kleinen Gruppen genutzt. Um die gemeinsame Nutzung von Daten, die Kommunikation zwischen den Benutzern und die Wirtschaftlichkeit bei der Verbindung mit Betriebsmitteln, die von einer Einzelperson möglicherweise nur selten benutzt werden, zu verbessern, wurden die Computer zu Netzen verbunden, auf denen mittels Nachrichten kommuniziert wird, die über Kommunikationsverbindungen übertragen werden, welche zusätzlich zu den direkt von den einzelnen Benutzern verwendeten Computern Server enthalten, die z. B. große Datenmengen speichern, auf die von mehreren Benutzern im System zugegriffen werden kann und die verwendet und aktualisiert werden können, wodurch die gemeinsame Nutzung von Daten erleichtert wird. Server können ferner Drucker, Telekommunikationsverbindungen und dergleichen steuern. Außerdem können Server spezialisierte Berechnungsdienste anbieten, wie z. B. eine Datenbanksuche und -sortierung und dergleichen. Die verschiedenen Computer, die als Client bezeichnet werden, und die Server sind mittels einer Kommunikationsverbindung verbunden, damit zwischen den verschiedenen Computern und Servern, die im verteilten System enthalten sind, Nachrichten übertragen werden können.

Zusammenfassung der Erfindung

Die Erfindung schafft eine neuartige und verbesserte Steueranordnung zum Steuern und Überwachen eines komplexen Systems wie z. B. eines verteilten digitalen Datenverarbeitungssystems, in dem mehrere Computer über z. B. ein lokales Netz kommunizieren.
Kurz zusammengefaßt enthält die Steueranordnung ein oder mehrere Darstellungsmodule, Funktionsmodule und Zugriffsmodule, die über Kerneinrichtungen kommunizieren, um Anfragen zu verarbeiten, die als Antwort auf Kommandos von einem Operator erzeugt werden, und um dem Operator Antworten anzuzeigen. Die Darstellungsmodule handhaben Operatorschnittstellenfunktionen, die das Empfangen von Kommandos von einem Operator und das Darstellen von Antworten für denselben umfassen. Das Darstellungsmodul erzeugt als Antwort auf ein Kommando von einem Operator eine Anfrage. Die Kerneinrichtung empfängt eine Anfrage und kann diese zur weiteren Verarbeitung an ein Funktionsmodul weiterleiten. Die Funktionsmodule handhaben allgemeine funktionelle Operationen in Verbindung mit der Verarbeitung einer Anfrage. Als Antwort auf eine Anfrage erzeugt ein Funktionsmodul eine oder mehrere Anfragen (im folgenden manchmal der Bequemlichkeit halber als Hilfsanfragen bezeichnet), die es zur Verarbeitung an die Kerneinrichtung oder an andere Funktionsmodule weiterleitet Die Kerneinrichtung leitet Hilfsanfragen, die sie empfängt, zur Verarbeitung an ein Zugriffsmodul weiter. Die Zugriffsmodule handhaben Frimitivoperationen in Verbindung mit den Objekten, die im komplexen System enthalten sind.
Die Patentanmeldung EP 0 281 102 des Standes der Technik lehrt ein Benutzersystem (lokales System) und ein gesteuertes System (mit dem Benutzersystem verbunden dargestellt), die beide auf dem gleichen Bildschirm gezeigt sind. Einige Kommunikationsparameter werden auf demselben Bildschirm visuell dargestellt. Der Gegenstand der Veröffentlichung des Standes der Technik ist das Editieren, bei vorhandenen angeschlossenen Datenbanken, unter Verwendung eines Computerprogramms, das als Konfigurationseditor bekannt ist.
Die Erfindung beruht in ihrer allgemeinsten Form auf einem System zum Steuern und Ausführen von Managementfunktionen, wie es im Anspruch 1 dargestellt ist.
Bevorzugte Ausführungsform dieses Aspekts besitzen die folgenden Merkmale. Die Managementmodule sind wenigstens für das Anfordern von Statusinformationen von den Objekten, das Modifizieren von Managementparametern der Objekte oder das Freigeben der Selbsttestmodi der Objekte ausgelegt.
Die Managementspezifikationsinformationen können ferner die Attribute und Operationen der Objekte auflisten, die anderen Objekten untergeordnet sind. Die Managementspezifikationsinformationen enthalten Abrufinformationen in vorgegebenen Feldern der allgemeinen Syntax. Die Abrufinformationen enthalten Felder zum Spezifizieren einer Vorgaberate und einer maximalen Abruf rate, mit der die Werte der Attribute von den Objekten angefordert werden sollen. Die Managementspezifikationsinformationen können ferner in vorgegebenen Feldern der allgemeinen Syntax Partitionsinformationen enthalten, die Gruppen von Attributen mit gemeinsamen Datentypen darstellen. Die Managementspezifikationsinformationen können ferner in vorgegebenen Feldern der allgemeinen Syntax Häufungsinformationen enthalten. Die Häufungsinformationen stellen Gruppen von Attributen dar, die verwandte Funktionen im Management des Objekts aufweisen.
Die Managementspezifikationsinformationen können ferner in vorgegebenen Feldern der allgemeinen Syntax Kommandoinformationen enthalten, die die Managementinformationen, für deren Durchführung die Objekte ausgelegt sind, die Struktur der an die Objekte auszugebenden Anweisungen und die Struktur der zu empfangenden Antworten auflisten. Die Struktur der auszugebenden Anfragen enthält Felder zum Auflisten von Argumenten für ein Kommando. Die Struktur der zu empfangenden Antworten enthält Felder, die zum Anzeigen des erfolgreichen Abschlusses der angeforderten Operation verwendet werden. Die Struktur der zu empfangenden Antworten enthält Felder, die zum Anzeigen von Fehlerbedingungen verwendet werden, die einen nicht erfolgreichen Abschluß der angeforderten Operation verursacht haben.
Wenigstens ein Managementmodul enthält ein Zugriffsmodul, das Protokolle für die Kommunikation mit einem oder mehreren Objekten implementiert. Die Protokolle sind konsistent mit den Ethernet-Normen oder den Decnet-Phase-IV-Normen oder den DECnet-Phase-V-Normen.
Jedes Kommando enthält Felder, die wenigstens ein zugehöriges Objekt und eine Operation auflisten, während der Kern einen Versender zum Empfangen und Weiterleiten von Kommandos enthält, der wenigstens teilweise auf dem Objekt und den darin aufgelisteten Operationen beruht. Die Tabelle der Versendezeiger umfaßt einen gerichteten Graphen von Datenstrukturen, wobei aufeinanderfolgende Datenstrukturen im Graphen den Feldern der Kommandos entsprechen. Der Versender enthält einen Parser (Prüfer) zum Prüfen des gerichteten Graphen entsprechend dem Objekt und der Operation, die in einem Kommando aufgeli stet sind, um eine Zieldatenstruktur mit einem Versendezeiger zu lokalisieren. Der gerichtete Graph enthält Stellvertreterzeichenmerker und aufeinanderfolgende Datenstrukturen, die einem beliebigen Wert in einem bestimmten Feld eines Kommandos zugeordnet sind. Der gerichtete Graph enthält Ellipsenzeichen-Merker und aufeinanderfolgende Datenstrukturen, die einer beliebigen Anzahl von Werten in den Feldern der Kommandos zugeordnet sein können. Der Prüfer enthält eine Beste-Übereinstimmung-Einheit zum Ermitteln der besten Übereinstimmung für die Felder eines Kommandos, die zuerst nach genauen Übereinstimmungen der Felder und anschließend nach Stellvertreterzeichenübereinstimmungen der Felder sucht oder die zuerst nach genauen Übereinstimmungen der Felder und anschließend nach Ellipsenzeichen-Übereinstimmungen der Felder sucht.
Das System enthält eine Darstellungsvorrichtung zum Anzeigen von Informationen für einen Benutzer und zum Empfangen von Kommandos von einem Benutzer, wobei die Kommandos und Informationen spezielle vorgegebene Formate aufweisen. Ein Darstellungsmodul empfängt Kommandos von der Darstellungsvorrichtung und leitet Informationen an die Darstellungsvorrichtung weiter, wobei das Darstellungsmodul einen Umsetzungscode enthält, um die von einem Objekt empfangenen Informationen in ein vorgegebenes Format für die Darstellungsvorrichtung umzusetzen, sowie einen Weiterleitungscode, um Kommandos von der Darstellungsvorrichtung an den Versender weiterzuleiten. Das Darstellungsmodul enthält Benutzerschnittstelleninformationen, die Modi definieren, in welchen die Benutzer mit dem System in Wechselwirkung treten. Die Benutzerschnittstelleninformationen enthalten Hilfsinformationen, um dem Benutzer Informationen darüber zur Verfügung zu stellen, wie das System zu benutzen ist. Die Benutzerschnittstelleninformationen enthalten Graphikmodusinformationen, die Pop-up-Menü-Inhalte und Kommandozeilen-Prüftabellen definieren.
Der Kern enthält ferner eine Klassendatenbank, die die unterschiedlichen Managementinformationen definiert, die von den entsprechenden Objekten zur Verfügung gestellt werden. Das Darstellungsmodul enthält Menü-Erzeugungsroutinen zum Extrahieren von Daten aus der Klassendatenbank und zum Erzeugen von Menüs gültiger Kommandos, um sie dem Benutzer anzuzeigen. Die Menü-Erzeugungsroutinen dienen zum Ermitteln von Informationen, die die Konfiguration der Gruppe betreffen, und zum Erzeugen von Menüs verfügbarer Objekte, um diese dem Benutzer anzuzeigen.

Kurzbeschreibung der Zeichnungen

Diese Erfindung ist in den beigefügten Ansprüchen genauer dargestellt. Die obenerwähnten und weitere Vorteile dieser Erfindung können mit Bezug auf die folgende Beschreibung besser verstanden werden, die sich auf die beigefügten Zeichnungen bezieht; in welchen:
Fig. 1A ein Funktionsblockschaltbild einer Steueranordnung ist, die gemäß der Erfindung konstruiert ist;
Fig. 1B ein Blockschaltbild der im Speicherobjekt der Fig. 1A gespeicherten Informationen ist;
Fig. 2A ein funktionelles Blockschaltbild eines Abschnitts der in Fig. 1A dargestellten Steueranordnung ist, das ein in der Steueranordnung enthaltenes Objekt genauer definiert;
Fig. 2B die Struktur eines Managementmoduls zeigt;
Fig. 3A bis 3D die Managementspezifikationen definieren, die die Managementansicht definieren, die von den Funktionsmodulen und den Zugriffsmodulen geschaffen wird, die in der in Fig. 1A gezeigten Steueranordnung enthalten sind, wobei Fig. 3E die Versendespezifikationen für die Funktionsmodule und Zugriffsmodule definiert;
Fig. 4 die Struktur eines Datenverzeichnisses zeigt, das Informationen enthält, die durch die in den Fig. 3A bis 3D gezeigten Managementspezifikationen definiert sind;
Fig. 5 und 6 funktionelle Blockschaltbilder sind, die verschiedene Module und Datenstrukturen in der in Fig. 1A gezeigten Steueranordnung darstellen;
Fig. 7A die Parameter zeigt, die in Anfragen verwendet werden, die von den Darstellungsmodulen und Funktionsmodulen in der in Fig. 1A gezeigten Steueranordnung erzeugt werden;
Fig. 7B die Struktur der Zeitkontexthantierer und der Kontextblöcke zeigt, die von der Anfrage der Fig. 7A verwendet werden;
Fig. 8A und 8B Datenstrukturen in Versendetabellen zeigen, die von einem Versender wie in den Fig. 5 und 6 gezeigt in Verbindung mit der Verarbeitung von Anfragen von den Darstellungsmodulen und Funktionsmodulen in der in Fig. 1A gezeigten Steueranordnung verwendet werden;
Fig. 9A und 9B die Operationen eines Versenders in Verbindung mit seiner zugeordneten Versendetabelle bei der Verarbeitung einer Anfrage von einem Darstellungsmodul oder einem Funktionsmodul zeigen;
Fig. 9C das Format einer Konfigurations- und Bereichsdatenbank zeigt;
Fig. 10A die Struktur eines Funktionsmoduls zeigt, das beim Einrichten und Ermitteln von Alarmbedingungen verwendet wird, wobei Fig. 10B die Struktur der bei der Einrichtung von Alarmbedingungen verwendeten Regeln zeigt.

ALLGEMEINE BESCHREIBUNG

Fig. 1A zeigt ein funktionelles Blockschaltbild einer Anordnung, die gemäß der Erfindung konstruiert ist, um den Status und den Zustand eines komplexen Systems zu steuern und zu überwachen. (Das komplexe System selbst ist nicht gezeigt.) Vorweg sei erwähnt, daß ein Beispiel eines komplexen Systems, das von der in Fig. 1A gezeigten Anordnung gesteuert wird, ein verteiltes digitales Datenverarbeitungssystem enthält, das mehrere Knoten umfaßt, die einzelne Computer, Endgeräte, Endgerät-Server und andere Komponenten enthalten, die mittels über ein Netz übertragener Nachrichten kommunizieren.
Solche komplexen Systeme erfordern ein Management, insbesondere da sich der Status und die Fähigkeiten des komplexen Systems ständig ändern. Daher müssen sich die Managementanordnung und die Managementfunktionen, die dieses bietet, ebenfalls ändern, um sich an die neuen Managementanforderungen des Systems anzupassen. Wie später genauer beschrieben wird, weist die Anordnung der Fig. 1A eine Erweiterbarkeit auf, die es der Anordnung ermöglicht, sich effizient an Änderungen des komplexen Systems anzupassen.
Für die Zwecke dieses Dokuments werden die Komponenten des komplexen Systems als Objekte bezeichnet. Objekte werden mit den Begriffen Klassen und Instanzen beschrie ben. Eine Objektklasse definiert Objekte eines bestimmten Typs, z. B. enthält eine Klasse alle lokalen Netzbrücken eines gegebenen Lieferanten. Jedes Objekt ist ein Mitglied einer Klasse und bildet eine Instanz dieser Klasse.
Wie in Fig. 1A gezeigt, enthält die Steueranordnung mehrere Typen von Steuermodulen, die Präsentationsmodule 10A bis 10K (allgemein mit dem Bezugszeichen 10 bezeichnet), Funktionsmodule 11A bis 11M (allgemein mit dem Bezugszeichen 11 bezeichnet) und Zugriffsmodule 12A bis 12N (allgemein mit dem Bezugszeichen 12 bezeichnet) enthalten. Die Darstellungsmodule 10 stellen im allgemeinen die Benutzerschnittstelle für die Operatoren dar, die eine Steuerung des komplexen Systems einschließlich der Steuerung von Endgeräten, die von den Systemoperatoren verwendet werden, bietet. Jedes Funktionsmodul 11 bietet allgemein eine Managementsteuerung und Überwachung in Verbindung mit einer Klasse von Funktionen. Jedes Zugriffsmodul 12 bietet im allgemeinen eine Managementsteuerung für einen bestimmten Typ eines steuerbaren Objekts in einem Satz, der zu einer Klasse steuerbarer Objekte gehört, innerhalb des komplexen Systems. Die Darstellungsmodule 10 kommunizieren mit den Funktionsmodulen 11 über ein Darstellungsfunktionsmerkmal eines Kerns 13, 14, im folgenden einfach mit Darstellungsfunktions-Kern 13 bezeichnet, während die Funktionsmodule 11 mit den Zugriffsmodulen über ein Funktionszugriffsmerkmal des Kerns 13, 14 kommunizieren, im folgenden einfach mit Funktionszugriffs-Kern 14 bezeichnet.
Die Funktionen, die von den Steuermodulen 10, 11, 12 benötigt werden, können sich in Abhängigkeit von der Topologie des gemanagten komplexen Systems stark ändern. Um der Anordnung eine Anpassungsfähigkeit und Erweiterbarkeit zu verleihen, können daher die Steuermodule 10, 11, 12 dynamisch zur Anordnung hinzugefügt oder aus derselben entfernt werden, um die Anordnung an die Topologie eines bestimmten komplexen Systems und an die Veränderungen dieser Topologie anzupassen.
Um die Ziele der Anpassungsfähigkeit und der Erweiterbarkeit zu erreichen, bilden die Steuermodule 10, 11, 12 eine "Arbeitsaufteilung" für die Tasks, die während des Managements des komplexen Systems auszuführen sind. Auf diese Weise können die Tasks, die z. B. den Managementprotokollen eines verteilten Datenverarbeitungssystems zugeordnet sind, von den Tasks getrennt werden, die z. B. dem Anzeigen der Managementinformationen für den Benutzer zugeordnet sind.

A. DARSTELLUNGSMODULE

Genauer bieten die Darstellungsmodule 10 Darstellungsdienste, die z. B. die Unterstützung für eine Benutzerschnittstelle wie z. B. ein Videoanzeigegerät, einen Personalcomputer oder einen Workstation-Computer umfassen können, die von einem Systemoperator verwendet werden kann, um die Operation der verschiedenen Funktionsmodule 11 und Zugriffsmodule 12 zu steuern und somit die verschiedenen Objekte im komplexen System zu steuern und zu überwachen. Die Darstellungsdienste werden unabhängig von den Managementfunktionen oder den Objekten, die von dem in Fig. 1A dargestellten System gemanagt werden, benötigt und werden daher unabhängig von der Art der Managementfunktionen oder Objekte zur Verfügung gestellt. Jede Operatorschnittstelle oder jedes Endgerät kann von mehreren Darstellungsmodulen 10 gesteuert werden. Die verschiedenen Darstellungsmodule 10 steuern verschiedene Aspekte der Operatorschnittstelle, einschließlich solcher Einzelheiten wie z. B. Symbole, Menüs, Graphiken sowie die Unterstützung zum Anzeigen und Prüfen einer Kommandozeile. Andere Darstellungsmodule 10 bieten eine spezielle Ausgabeunterstützung für verschiedene Typen graphischer Anzeigen, wie z. B. Histogrammen, Balkengraphen, Kreisdiagrammen oder anderen Typen bildlicher Darstellungen, die für einen Operator auf einem Gerätebildschirm angezeigt werden sollen. Weitere Darstellungsmodule 10 bieten die Übertragung von Managementanfragen, die mittels Symbolen, Menüs, Graphiken oder Kommandos, die der Operator in der Kommandozeile eingegeben hat, dem Darstellungsfunktions-Kern 13 mitgeteilt werden können, sowie der Übertragung von Managementinformationen vom Darstellungsfunktions-Kern 13 zur Anzeige auf dem von einem Operator benutzten Videoanzeigegerät.

B. FUNKTIONSMODULE

Den Funktionsmodulen 11 sind spezielle Managementanwendungen zugeordnet, die sie allgemein unterstützen und die von der in Fig. 1A gezeigten Steueranordnung geschaffen werden. Die Managementanwendungen bestehen unabhängig von den Darstellungsdiensten, die von den Darstellungsmodulen 10 zur Verfügung gestellt werden (anders als bis zu dem Ausmaß, zu dem die Darstellungsmodule 10 einen Operator über die Managementanwendungen informieren, die von der Steueranordnung zur Verfügung gestellt werden), und den bestimmten Objekten, die das komplexe System umfaßt, das von der Steueranordnung gemanagt wird.
Eine Managementanwendung, die von einem Funktionsmodul 11 geschaffen werden kann, kann z. B. die Kommunikationslast in einem verteilten Datenleitsystem analysieren. Um eine solche Analyse durchzuführen, würde ein Funktionsmodul auf Kommunikationsdaten wie z. B. die Anzahl der gesendeten Pakete und die Anzahl der gesendeten Bytes, von mehreren Objekten des verteilten Leitsystems zugreifen. Das Funktionsmodul würde anschließend die Informationen zu Informationen höherer Ebene zusammenfassen, wie z. B. die mittlere Paketgröße und die prozentuale Nutzung der Kommunikationsbetriebsmittel des Leitsystems. Diese Informationen würden anschließend an den Benutzer weitergeleitet oder anderen Funktionsmodulen bei der Ausführung anderer Managementanwendungen zur Verfügung gestellt.
Wie im obigen Beispiel gezeigt, "steogert" ein Funktionsmodul den "Wert" von Managementinformationen, die im komplexen System verfügbar sind, in Form von Datensammlungs- oder Korrelationsdiensten. Außerdem können Funktionsmodule die Daten nutzen, die von anderen Funktionsmodulen erzeugt werden, um für das Management des komplexen Systems Dienste höherer Ebene auszuführen.
In einer speziellen Steueranordnung zum Steuern eines verteilten digitalen Datenverarbeitungssystems managt z. B. ein Funktionsmodul 11 die Topologie des Netzes und zeigt die Topologie über ein Darstellungsmodul 10 einem Operator an.
Ein weiteres Funktionsmodul 11 kann ein Konfigurations- Funktionsmodul umfassen, das z. B. die Konfiguration, d. h. die verschiedenen Objektinstanzen und deren Beziehungen untereinander, des verteilten digitalen Datenverarbeitungssystems definiert, so daß es einem Operator ermöglicht, die Konfiguration des Netzes zu steuern, indem es ermöglicht, Knoten und andere Objektinstanzen hinzuzufügen oder aus dem Netz zu entfernen, Zugriffsrechte verschiedener Benutzer der Knoten zu ändern, und indem es ferner eine Konfigurationdatenbank (oder Instanzendatenbank) hält, mit der der Operator die Änderungen der Konfiguration des Netzes im Zeitverlauf ermitteln kann.
Ein weiteres Funktionsmodul 11 in der Steueranordnung kann z. B. verschiedene Alarme steuern, die das Auftreten ausgewählter Ereignisse im verteilten digitalen Datenverarbeitungssystem anzeigen; dieses Alarmfunktionsmodul 11 überwacht den Status und den Zustand verschiedener Objekte im verteilten digitalen Datenverarbeitungssystem und erzeugt eine Alarmanzeige für einen Operator über das entsprechende Darstellungsmodul 10 als Antwort auf den Status oder die Zustände, die ausgewählte Werte aufweisen, um den Operator darüber zu informieren.
Ein weiteres Funktionsmodul 11 kann z. B. Bereiche von Objekten im verteilten digitalen Datenverarbeitungssystem einrichten, um den Rahmen der Steuerung oder der Überwachung durch einen Operator zu begrenzen oder um die Steuerung oder Überwachung durch den Operator zu vereinfachen.
Ein weiteres Funktionsmodul 11 kann z. B. als ein Historiedaten-Aufzeichnungsfunktionsmodul 11 dienen, um periodisch verschiedene Objekte im komplexen System abzurufen, um zu bestimmten Zeitpunkten deren Werte zu ermitteln und eine Datenbank der Zeiten und Werte einzurichten und zu führen, um die Erzeugung von Nutzungsstatistiken zu erleichtern.
Ein weiteres Funktionsmodul 11 kann vielleicht keinen bestimmten Aspekt des komplexen Systems steuern, sondern statt dessen als ein Durchlaß arbeiten, um einem Operator zu ermöglichen, Primitivfunktionen eine komplexen Systems direkt über die Zugriffsmodule 12 zu steuern oder zu überwachen.
Eine Managementanwendung kann die Dienste und Operationen anfordern, genauer koordinieren Sequenzen einer Anzahl von Zugriffsmodulen 12 und das Funktionsmodul 11, das die Managementanwendung unterstützt, die Sequentierung der Operationen durch die verschiedenen Zugriffsmodule 12, die benötigt werden, um die Managementanwendung auszuführen. Außerdem kann die Managementanwendung, die von einem Funktionsmodul 11 zur Verfügung gestellt wird, die Anwendung zusätzlicher Funktionsmodule 11 in der Steueranordnung erfordern, die das eine Funktionsmodul ebenfalls koordinieren kann.
Die Funktionsmodule 11 werden anfangs vom Darstellungsfunktions-Kern 13 als Antwort auf Managementanfragen aktiviert, die von einem Operator eingegeben und von einem Darstellungsmodul 10 erhalten werden. Ein Funktionsmodul 11 kann ferner durch eine Anfrage aktiviert werden, die direkt von einem weiteren Funktionsmodul empfangen worden ist. Außerdem kann ein Funktionsmodul 11 eine Anfrage zur Verarbeitung durch ein Zugriffsmodul 12 erzeugen.

C. ZUGRIFFSMODULE

Den Zugriffsmodulen 12 sind verschiedene Primitiv-Managementoperationen zugeordnet, die sie unterstützen und die von der Steueranordnung in Verbindung mit den verschiedenen Objekten, die das von der in Fig. 1A gezeigten Steueranordnung gemanagte komplexe System umfaßt, zur Verfügung gestellt werden. Zum Beispiel können in einem verteilten digitalen Datenverarbeitungssystem die Objekte nicht nur die verschiedenen Hardwarekomponenten des Systems einschließlich verschiedener Computer, Plattenund Bandspeichereinheiten, Leitvorrichtungen usw. umfassen, die Knoten im verteilten digitalen Datenverarbeitungssystem bilden können, sondern auch Softwarekomponenten einschließlich virtueller Schaltungen, Datenbanken und dergleichen. Die Zugriffsmodule 12 werden vom Funktionszugriffs-Kern 14 als Antwort auf Anfragen von einem Funktionsmodul 11 aktiviert.
Die Zugriffsmodule 12 zum Steuern und Überwachen eines verteilten digitalen Datenverarbeitungssystems können mehrere unterschiedliche Typen von Knoten oder unterschiedliche Ebenen in den Nachrichtenübertragungsprotokollen steuern, die von den Knoten verwendet werden, um Nachrichten zu erzeugen und zu übertragen. Ein Zugriffsmodul 12 kann z. B. den Status verschiedener Abschnitte einer Brücke steuern und überwachen, die zwei lokale Netze miteinander verbindet, wodurch ermöglicht wird, daß zwischen den Knoten der zwei lokalen Netze Nachrichten ausgetauscht werden können. Ein solches Zugriffsmodul 12 kann z. B. die Brücke initialisieren und diese zum Betrieb freigeben, die Brücke sperren, ihre Ende-Ende- Operation überwachen, die Anzahl der Nachrichtenweiterleitungspuffer ermitteln, die sie besitzt, und ermitteln, ob sie genügend Puffer besitzt, um im System effektiv zu arbeiten.
Ein weiteres Zugriffsmodul 12 kann die Operation der Nachrichtenerzeugungs- und Decodierungsabschnitte der verschiedenen Knoten des verteilten digitalen Datenverarbeitungssystems, die virtuellen Schaltungen, die Sitzungen und andere Verbindungen, die zwischen Knoten eingerichtet sind, verschiedene Zeitgeber und Zähler, die die Aktivität oder Inaktivität hiervon anzeigen, und dergleichen steuern und überwachen. Gleichermaßen kann ein weiteres Zugriffsmodul 12 die Operation der Netzschichtabschnitte der Knoten steuern und überwachen, die das aktuelle Senden und Empfangen von Nachrichten über das Netz steuern, einschließlich verschiedener Nachrichtensende- und -empfangszähler, Sende- und Empfangszeitgeber und dergleichen. Ferner können Zugriffsmodule 12 verwendet werden, die beides steuern, zusätzlich zum Überwachen der Werte der verschiedenen Zeitgeber und Zähler, um Grenzen für die Anzahl konkurrierender virtueller Schaltungen und Sitzungen einzurichten, die ein Knoten halten kann, und andere Vorgabe- und Betriebsparameter einrichten.
In speziellen Ausführungsformen können Zugriffsmodule einen Zugriff auf Managementfunktionen an ETHERNET-LAN- Brücken, einen Verbindungstest oder IEEE-802-Funktionen an ETHERNET-Stationen, Anschlußsegmentierungssteuer- und Prüffunktionen an ETHERNET-Verstärkern oder Managementfunktionen an FDDI-Objekten zur Verfügung stellen. Außerdem können Zugriffsmodule Zugriff auf die Managementunterstützung an Decnet-Phase-IV- oder Decnet-Phase-V- Knoten oder DEC-Terminal-Server bieten, wie sie von der Digital Equipment Co., Maynard, MA, vertrieben werden.

D. ANFRAGEN

Die Steuermodule 10, 11, 12 stehen untereinander und mit dem Benutzer über Anfragen in Wechselwirkung. Die Anfragen weisen zwei allgemeine Typen auf. Eine Anfrage kann z. B. ermöglichen, daß etwas im komplexen System geschieht, d. h. sie kann veranlassen, daß der Zustand oder die Bedingung des komplexen Systems verändert wird. Bei der Verarbeitung einer solchen Anfrage führen ein oder mehrere Zugriffsmodule 12 vorgegebene Operationen aus, die den Zustand oder die Bedingung eines oder mehrere Objekte im gemanagten System ändern. Die Zugriffsmodule 12, die eine solche Anfrage verarbeiten, erzeugen Statusinformationen, die den Status der Anfrage anzeigen und die sie an den Funktionszugriffs-Kern 14 zurückgeben.
Alternativ kann eine Anfrage Informationen über den Status oder die Bedingung eines oder mehrerer Objekte im System erbitten, wobei die Objekte in der Anfrage definiert sind. Bei der Verarbeitung einer solchen Anfrage können ein oder mehrere Zugriffsmodule 12 den Status oder die Bedingung der Objekte ermitteln und eine Identifizierung derselben an den Funktionszugriffs-Kern 14 zurückgeben. In anderen Fällen können die in der Steueranordnung (z. B. mittels eines Historiedaten-Aufzeichnungsfunktionsmoduls) gespeicherten Informationen verwendet werden, um die Anfrage zu bedienen.
Außerdem kann eine Anfrage beiden Typen entsprechen, d. h. sie kann den Zustand oder die Bedingung eines oder mehrere Objekte verändern und kann ferner Informationen über die Zustände oder Bedingungen der Objekte nach der Änderung anfordern. Bei der Verarbeitung einer solchen Anfrage bewirken die Zugriffsmodule 12 das Auftreten der Veränderung, falls möglich, und geben Statusinformationen über den Status der Anfrage sowie Informationen über den Status oder die Bedingungen der Objekte zurück.
Anfragen können als Antwort auf eine Operatoraktion an einer Endgerät-Darstellungsvorrichtung erzeugt werden. In diesem Fall erzeugt das Darstellungsmodul 10, das das Endgerät steuert, eine Anfrage, die es an den Darstellungsfunktions-Kern 13 sendet. Außerdem können Anfragen direkt durch entsprechende Funktionsmodule 11 erzeugt werden. Zum Beispiel kann ein Funktionsmodul 11, das als Historiedaten-Aufzeichnungsvorrichtung arbeitet, Anfragen erzeugen, um periodisch den Status oder die Bedingungen entsprechender Objekte im komplexen System zu ermitteln und in einer Historie-Datenbank zur Verwendung bei der späteren Verarbeitung zu speichern, wenn sie von einem Operator benötigt werden.

E. KERN

Der Kern 13, 14 enthält mehrere Objekte, einschließlich eines Informationsmanagers 15, 20 (im folgenden einfach als Informationsmanager 15 oder Informationsmanager 20 bezeichnet, die ein und denselben Informationsmanager bilden), eines Versenders 16, 21 (im folgenden einfach als Versender 16 oder als Versender 21 bezeichnet, die ein und denselben Versender bilden) und eines Datenspeicherobjekts 17, 22 (im folgenden einfach als Datenspeicherobjekt 17 oder als Datenspeicherobjekt 22 bezeichnet, die ein und dasselbe Datenspeicherobjekt bilden), wie im folgenden beschrieben wird.

F. DATENSPEICHER

Das Datenspeicherobjekt 17, 22 kann ein oder mehrere Hochgeschwindigkeits-RAMs umfassen, die Versendedatenstrukturen enthalten, oder ein oder mehrere Festplattenlaufwerke oder andere Speichervorrichtungen, in Abhängigkeit von den Typen und der Menge der darin gespeicherten Daten.
Außerdem können Daten unterschiedlicher Typen zur späteren Verwendung durch den Kern in unterschiedlichen Speichervorrichtungen gespeichert sein, wobei alle diese Einrichtungen schematisch durch das einzelne Datenspeicherobjekt 17, 22 dargestellt sind.
Wie in Fig. 1B gezeigt, hält in einer Ausführungsform das Datenspeicherobjekt 17, 22 Informationen über die Existenz und den Zustand der verschiedenen Objekte, die das komplexe System zu verschiedenen Zeitpunkten enthält, insbesondere ausgewählte Informationen über den Status und die Bedingungen der verschiedenen Objekte, die von den Zugriffsmodulen 10 gesteuert werden, wie sie mittels des Historiedatenaufzeichnungs-Funktionsmoduls 11 erhalten werden. Diese werden in einer Historiedatenbank 26 gespeichert.
Andere Informationen können ebenfalls im Datenspeicherobjekt 17, 22 gespeichert werden. Wie oben beschrieben ist, kann ein Konfigurationsmodul insbesondere eine Konfigurationsdatenbank 23 bilden, die das Vorhandensein von Objektinstanzen im komplexen System anzeigt. Ein Bereichsmodul kann eine Datenbank 25 speichern, die Bereiche von Objekten beschreibt und bei der Begrenzung des Steuerumfangs des Benutzers verwendet wird. Alternativ können die Bereichsinformationen als ein Objekt der Konfigurationsdatenbasis 23 gespeichert werden. Ferner kann ein Alarmmodul eine Alarmregeldatenbank 24 verwenden, um Alarmbedingungen innerhalb des komplexen Systems zu prüfen.
Andere Informationen, die sich auf die einzelnen Module in der Steueranordnung beziehen, können ebenfalls im Speicherobjekt 17, 22 enthalten sein. Wie im folgenden genauer beschrieben wird, kann z. B. eine Versendetabelle 28, die vom Versender 16, 21 verwendet wird, die Orte der Module sowie die Operationen, Objekte und Attribute, die diese unterstützen, speichern. Außerdem kann die Steueranordnung ein Datenverzeichnis 27 enthalten, das die Attribute, Direktiven und Unterobjekte aller verschiedenen Klassen von Objekten im komplexen System speichert. Diese letzteren Informationen können verwendet werden, um z. B. Anfragen vom Benutzer zu verarbeiten und/oder Menüs zu erzeugen, um auf Benutzeranfragen zu antworten.

G. INFORMATIONSMANAGER

Wie in Fig. 1 gezeigt ist und im folgenden genauer beschrieben wird, fängt der Informationsmanager 15 dann, wenn er eine Anfrage von einem Darstellungsmodul 10 empfängt, auf die er unter Verwendung der Informationen im Datenspeicherobjekt 17 antworten kann, die Anfrage ab und erzeugt eine Antwort auf die Anfrage, die er zur Anzeige für den Operator, der die Anfrage erzeugt hat, an ein entsprechendes Darstellungsmodul 10 sendet. Wenn der Informationsmanager 15 auf die Anfrage nicht antworten kann, ermittelt er anschließend, ob sich die Anfrage auf den aktuellen Zeitpunkt oder einen Zeitpunkt in der Zukunft bezieht; d. h., der Informationsmanager 15 ermittelt, ob die Anfrage sofort verarbeitet oder für einen bestimmten Zeitpunkt in der Zukunft eingeteilt werden soll. Der Informationsmanager sendet die Anfrage zum richtigen Zeitpunkt, entweder sofort oder zum eingeteilten Zeitpunkt, zum Versender 16. Anhand der Art der Anfrage identifiziert der Versender 16 ein Funktionsmodul 11 zum Verarbeiten der Anfrage und sendet die Anfrage zu diesem Funktionsmodul 11.
Das Funktionsmodul 11 fährt als Antwort auf den Empfang einer Anfrage vom Versender 16 mit der Verarbeitung der Anfrage fort. Es kann als Antwort auf die Anfrage eine oder mehrere Operationen einleiten, die jeweils durch eine Anfrage dargestellt werden, woraufhin eine Hilfsanfrage aufgerufen wird, die es an ein weiteres Funktionsmodul 11 oder an den Funktionszugriffs-Kern 14 richtet. Nach dem Empfang von Antworten auf alle Hilfsanfragen erzeugt das Funktionsmodul 11 eine Antwort, die es zum Versender 16 sendet. Der Versender 16 formuliert anschließend eine Antwort, die er über den Informationsmanager 15 zur Anzeige für den Benutzer an das entsprechende Darstellungsmodul 10 sendet.
Das Funktionszugriffs-Merkmal des Kerns 14 enthält den Informationsmanager 20, den Versender 21 und das Datenspeicherobjekt 21. Eine Hilfsanfrage von einem Funktionsmodul 11, die an den Funktionszugriffs-Kern 14 gerichtet ist, wird anfangs vom Informationsmanager 20 empfangen. Das Datenspeicherobjekt 22 enthält ferner Informationen über den Zustand des komplexen Systems zu verschiedenen Zeitpunkten, die vom Historiedaten-Aufzeichnungsfunktionsmodul 11 zur Verfügung gestellt werden, insbesondere ausgewählte Informationen über den Status und die Bedingungen der verschiedenen Objekte, die von den Zugriffsmodulen 10 gesteuert werden.
Wenn der Informationsmanager 20 eine Hilfsanfrage von einem Funktionsmodul 11 empfängt, auf die er unter Verwendung der Informationen im Datenspeicherobjekt 22 antworten kann, fängt er die Anfrage ab und erzeugt eine Antwort auf die Hilfsanfrage, die er zu dem Funktionsmodul 11 sendet, von dem er die Hilfsanfrage empfangen hat. Wenn der Jnformationsmanager 20 auf eine Hilfsanfrage von einem Funktionsmodul 11 nicht antworten kann, ermittelt er anschließend, ob sich die Anfrage auf den aktuellen Zeitpunkt oder auf einen Zeitpunkt in der Zukunft bezieht; d. h., der Informationsmanager 20 ermittelt, ob die Anfrage sofort verarbeitet werden soll oder für einen bestimmten Zeitpunkt in der Zukunft eingeteilt werden soll. Der Informationsmanager 20 überträgt die Hilfsanfrage zum geeigneten Zeitpunkt, entweder sofort oder zum eingeteilten Zeitpunkt, zum Versender 21. Der Versender 21 identifiziert als Antwort auf das Empfangen einer Hilfsanfrage vom Informationsmanager 20 ein Zugriffsmodul 12 für die Verarbeitung der Hilfsanfrage und überträgt die Hilfsanfrage zu diesem Zugriffsmodul 12.
Das Zugriffsmodul 12 fährt als Antwort auf den Empfang einer Hilfsanfrage vom Versender 21 mit der Verarbeitung der Anfrage fort. Es kann als Antwort auf die Hilfsanfrage eine oder mehrere Operationen in Verbindung mit dem Objekt des dadurch gesteuerten komplexen Systems einleiten. Wenn die Hilfsanfrage erfordert, daß das Zugriffsmodul 12 den Zustand oder die Bedingung des Objekts ändert, versucht es dies durchzuführen und erzeugt eine Antwort, die Statusinformationen enthält, die den Status des Versuchs anzeigen, d. h. ob z. B. die Änderung erfolgreich, erfolglos oder teilweise erfolgreich war. Wenn andererseits die Hilfsanfrage erfordert, daß das Zugriffsmodul 12 den Zustand oder die Bedingung des Objekts feststellt, erzeugt es eine Antwort, die den Zustand oder die Bedingung des Objekts angibt. Wenn schließlich die Hilfsanfrage erfordert, daß das Zugriffsmodul 12 beides durchführt, versucht es den Zustand oder die Bedingung des Objekts zu ändern und erzeugt eine Antwort, die den Status des Versuchs sowie den neuen Zustand oder die neue Bedingung des Objekts angibt. In jedem Fall sendet das Zugriffsmodul 12 die Antwort zum Versender 21, der sie zu dem Funktionsmodul 11 überträgt, das die Anfrage erzeugt hat. Das Funktionsmodul 11 verwendet nach Bedarf die Antwort vom Zugriffsmodul 12 bei der Formulierung seiner Antwort auf eine Anfrage vom Versender 16 oder auf eine Hilfsanfrage von einem weiteren Funktionsmodul 11.
Nach dem Empfang einer Hilfsanfrage von weiteren Funktionsmodulen 11 verarbeitet ein Funktionsmodul 11 dieselbe in der gleichen Weise wie sie eine Anfrage vom Versender 21 verarbeitet.

H. VORTEILE

Die in Fig. 1A gezeigte Steueranordnung bietet mehrere Vorteile. Die Steueranordnung bildet im wesentlichen eine Verarbeitungskette, wobei jedes Objekt längs der Kette versucht, eine Anfrage zu verarbeiten, bevor sie diese zum nächsten Objekt weiterleitet Wenn somit der Informationsmanager 15, 20 die Anfrage auf der Grundlage der Inhalte des zugehörigen Datenspeicherobjekts 17, 22 verarbeiten kann, ohne daß eine weitere Verarbeitung durch ein weiteres Objekt weiter unten in der Kette erforderlich ist, tut er dies.
Ferner ist die Steueranordnung erweiterbar, so daß leicht zusätzliche Darstellungsmodule 10, Funktionsmodule 11 und Zugriffsmodule 12 hinzugefügt werden können, wie im folgenden beschrieben wird, ohne die Architektur der Steueranordnung zu ändern. Das Hinzufügen von Funktionsmodulen 11 und Zugriffsmodulen 12 geschieht mittels einer Anmeldeprozedur, die im folgenden in Verbindung mit Fig. 5 beschrieben wird. Hinzufügungen oder Löschungen von Modulen 10, 11 oder 12 können durchgeführt werden, indem lediglich, wie im folgenden beschrieben, die Inhalte bestimmter Datenstrukturen im Datenspeicherobjekt 17, 22 und in anderen Datenstrukturen, die von den Darstellungsmodulen 10 gehalten werden, modifiziert werden, wie in Fig. 5 gezeigt ist.
Außerdem erleichtert die modulare, erweiterbare Eigenschaft der Steueranordnung das Management der Steueranordnung selbst. Die gleichen Versende- und Anfragebeispiele, die zum Ausgeben von Managementdirektiven an das komplexe System verwendet worden sind, können auch zum Ausgeben von Kommandos an die Managementmodule selbst verwendet werden. Dies beseitigt den Bedarf an einer zusätzlichen Managementanwendung, um die Steueranordnung selbst zu managen.
Da ferner die Funktionen der Module in einem Normformat spezifiziert sind und der Steueranordnung insgesamt zur Verfügung stehen, kann die Steueranordnung eine volle Benutzerschnittstellenunterstützung für die Module bieten, wodurch die Modulentwickler von der Last der Unterstützung einer Benutzerschnittstelle für jedes Modul befreit werden. Dieser Typ einer "automatischen" Benutzerschnittstellenunterstützung garantiert ferner ein einheitliches Erscheinungsbild und eine einheitliche Handhabung der Benutzerschnittstelle unabhängig von der Quelle oder der Art der verwendeten Managementmodule.
Es wird angenommen, daß dann, wenn die Steueranordnung verwendet wird, um ein verteiltes digitales Datenverarbeitungssystem zu steuern, diese einschließlich ihrer verschiedenen Objekte mehrere Routinen umfassen kann, die von den verschiedenen Knoten und Computern, die das verteilte digitale Datenverarbeitungssystem enthält, verarbeitet werden können; d. h. es sind keine Computereinrichtungen zusätzlich zu denjenigen, die das gesteuerte verteilte digitale Datenverarbeitungssystem enthält, erforderlich, um die Module zu verarbeiten, die die Steueranordnung enthält, um das verteilte digitale Datenverarbeitungssystem zu steuern. Es können herkömmliche Prozeduraufrufmechanismen, Zwischenprozeßkommunikationsmechanismen und Zwischenknotenkommunikationsmechanismen verwendet werden, um Nachrichten einschließlich Anfragen, Hilfsanfragen und Antworten zwischen den verschiedenen Abschnitten der Steueranordnung zu übertragen, die sich in unterschiedlichen Abschnitten des gleichen Prozesses, in unterschiedlichen Prozessen im gleichen Knoten und in unterschiedlichen Knoten befinden können. Wenn sich die Module in unterschiedlichen Prozessen im gleichen Knoten oder in unterschiedlichen Knoten befinden, werden Zwischenprozeß- und Zwischenknotenkommunikationsmechanismen verwendet, wie in Fig. 6 gezeigt und im folgenden beschrieben, um Anfragen und Hilfsanfragen sowie Antworten zwischen den verschiedenen Prozessen und Knoten zu übertragen.

I. OBJEKTMODELL

Vor einer Fortsetzung ist es nützlich, die Beziehung zwischen der in Fig. 1A gezeigten Steueranordnung und dem gesteuerten komplexen System genauer zu beschreiben. Genauer umfaßt die Steueranordnung, wie in Fig. 2A gezeigt, einen Direktor 35, der alle Darstellungsmodule 10, die Funktionsmodule 11 und die Zugriffsmodule 12 gemeinsam mit dem Kern 13, 14 enthält. Das komplexe System enthält ein oder mehrere Objekte 36. Jedes Objekt 36 enthält ein Dienstelement 31, eine Managementschnittstelle 30 und eine Dienstschnittstelle 33. Die Managementschnittstelle steuert und überwacht das Dienstelement über einen Agenten 34. Das Dienstelement ist der wirklich gemanagte Abschnitt des Objekts 36 und stellt die Primärfunktion oder die Funktion des Objekts zur Verfügung. Das heißt, das Dienstelement 31 führt die Funktion des Objekts durch, die innerhalb des Kontextes des verteilten digitalen Datenverarbeitungssystems benötigt wird. Wenn z. B. das Objekt für einen Knoten die Kommunikation über ein Netz bewerkstelligt, führt das Dienstelement 31 die Kommunikation durch.
Wie oben erwähnt ist, wird das Dienstelement 31 mittels eines Agenten gemanagt, der mit dem Direktor, genauer mit den Zugriffsmodulen 12, über die Managementschnittstelle und die Dienstschnittstelle 33 kommuniziert. Die Kommunikation über die Managementschnittstelle 30 erleichtert das Ein- oder Ausschalten des Dienstelements 31 sowie dessen Initialisierung und ermöglicht ferner, daß der Direktor 35 den Betriebsstatus des Objekts 36 ermittelt. Die Kommunikation über die Dienstschnittstelle 33 ermöglicht dem Direktor 35, das Dienstelement 31 auf andere Weise zu steuern und zu überwachen, indem er z. B. die Bedingungen ausgewählter Attribute einrichtet, wie z. B. der Kommunikationsparameter im Fall eines Objekts 36, das die Kommunikation bewerkstelligt, im Kontext der Steuerung des Objekts 36, oder indem er die Werte von Zählern im Kontext der Überwachung des Objekts 36 ermittelt.
Das Management eines Systems ist gekennzeichnet durch die Direktiven, die es unterstützt, sowie durch seine Attribute, die weitestgehend jene Parameter sind, die sich auf seine Funktion und Steuerung beziehen und die den Direktiven zugeordnet sind. Wenn z. B. das Objekt eine Leitvorrichtung ist, die Datenpakete über ein verteiltes Datenverarbeitungsnetz weiterleitet, können die Attribute der Leitvorrichtung die Anzahl der gesendeten Pakete und die Anzahl der gesendeten Bytes enthalten. Wenn das Objekt ein Modem ist, können die Attribute die Zähler- und Statusregister enthalten, die sich auf die Modemoperation beziehen. Beispiele von Direktiven umfassen SHOW, die Attributwerte wiedergewinnt, sowie SET, die Attributwerte modifiziert.
Die Dienstschnittstelle bezieht sich auf die Funktion des Objekts, während sich die Managementschnittstelle auf die Operation des Agenten bezieht. Die Direktiven und Attribute, auf die über die Dienstschnittstelle zugegriffen wird, charakterisieren die Funktion des Objekts, während die Direktiven und Attribute, auf die über die Managementschnittstelle zugegriffen wird, die Steuerung und Überwachung des Objekts charakterisieren.
Um die Rollen der beiden Schnittstellen zu verdeutlichen und um ein Beispiel zu zeigen, wie das obenerwähnte Modell auf ein bestimmtes Objekt angewendet wird, sei ein steuerbares Objekt betrachtet, das ein Modem ist. Das Modem kann mehrere Funktionsattribute aufweisen, wie z. B. die Baud-Rate, die Leitungsauswahl sowie die Leistungsschaltereinstellung. Außerdem kann das Modem mehrere Managementattribute aufweisen, wie z. B. die prozentuale Ausnutzung seiner Leitungen sowie die Zeitspanne, die seit dem letzten Selbsttest verstrichen ist. Die Baud-Rate, die Leitungsauswahl und die Leistungsschaltereinstellung beziehen sich auf die unmittelbare Operation des Modems, weshalb hierauf über die Dienstschnittstelle zugegriffen wird. Die prozentuale Leitungsausnutzung und die verstrichene Zeitspanne seit dem letzten Selbsttest beziehen sich auf die allgemeine Operation des Modems, weshalb hierauf über die Managementschnittstelle zugegriffen wird.
Um das obige Beispiel weiter zu vertiefen, ist zu beachten, daß die Darstellungsmodule während der Darstellung der Managementinformationen auf einer Darstellungsvorrichtung die Dienstschnittstelle der Darstellungsvorrichtung verwenden, da die Darstellung der Informationen der Hauptdienst der Darstellungsvorrichtung ist. Ein Zugriffsmodul in der Steueranordnung kann jedoch ebenfalls die Darstellungsvorrichtung managen, indem es z. B. diese abruft, um zu ermitteln, ob sie eingeschaltet ist.
Zusätzlich zu den obenbeschriebenen Attributen gibt es andere "Pseudoattribute", die sich auf das Objekt beziehen, jedoch nicht vom Objekt als solches gespeichert werden. Pseudoattribute sind im allgemeinen Attribute, die von der Objektmodellbeschreibung benötigt werden, jedoch nicht vom Objekt geliefert werden. Ein Beispiel ist das Attribut IMPLEMENTATION, das die Synthese aus den Attributen IMPLEMENTATION TYPE und VERSION, die vom Objekt geliefert werden, und der CREATION TIME des Objekts sein kann. Pseudoattribute werden von dem Zugriffsmodul gehalten, das für den Zugriff auf das Objekt verantwortlich ist.
An diesem Punkt ist zu beachten, daß das Objektmodell ein verallgemeinertes Verfahren zur Beschreibung von Direktiven und Attributen eines Objekts ist und keine Struktur innerhalb des Objekts selbst angibt. Das Objektmodell ist ein Werkzeug, das der Steueranordnung ermöglicht, in einer konsistenten Weise auf die Operationen und Attribute irgend eines beliebigen Objekts Bezug zu nehmen. Ein beliebiges Objekt kann in die Steueranordnung der Fig. 1A "einsetzt" und von derselben gemanagt werden, indem (1) es konsistent zum Objektmodell beschrieben wird, (2) ein geeignetes Zugriffsmodul implementiert wird und (3) das Zugriffsmodul in die Steueranordnung eingesetzt (angemeldet) wird.

J. MANAGEMENT DER MANAGEMENTMODULE

Wie oben erwähnt worden ist, werden in einer Steueranordnung, die ein verteiltes digitales Datenverarbeitungssystem steuert, die verschiedenen Darstellungsmodule 10, Funktionsmodule 11, Zugriffsmodule 12 und der Kern 13, 14 von verschiedenen Knoten verarbeitet, die im verteilten digitalen Datenverarbeitungssystem enthalten sind. In diesem Fall bilden die verschiedenen Module 10, 11 und 12 und der Kern 13, 14 Objekte im komplexen System und können in der gleichen Weise gesteuert werden wie andere Objekte, wie oben beschrieben worden ist.
Die Versende- und Anfragebeispiele, die verwendet werden, um Managementdirektiven an das komplexe System auszugeben, werden ebenfalls verwendet, um Kommandos an die Managementmodule selbst auszugeben. Wie aus den folgenden Versendespezifikationen deutlich wird, enthält jedes Modul zusätzlich zu den Managementroutinen zum Managen des komplexen Systems selbst Managementroutinen, die die internen Attribute des Moduls manipulieren. Sowohl auf die externen als auch auf die internen Routinen kann unter Verwendung der Anfragesyntax mittels Anfragen zugegriffen werden. Da die Fähigkeiten zum Management des komplexen Systems durch das Hinzufügen neuer Steuermodule verbessert werden, werden daher die Fähigkeiten zum Management der Steueranordnung in ähnlicher Weise erhöht.

GENAUE BESCHREIBUNG

A. MANAGEMENTMODULSTRUKTUR

1. Überblick

Wie in Fig. 2B gezeigt, umfaßt die Struktur eines Managementmoduls in einer bestimmten Ausführungsform einen ausführbaren Code 38, der die vom Modul zur Verfügung gestellten Managementfunktionen implementiert. Genauer enthält der ausführbare Code für ein Zugriffsmodul die Zugriffsprotokolle für die Objektklassen, die vom Zugriffsmodul bedient werden. Für ein Funktionsmodul enthält der ausführbare Code Befehle zum Berechnen der Funktionen höherer Ebene, die vom Modul zur Verfügung gestellt werden. Für ein Darstellungsmodul enthält der ausführbare Code die Schnittstellenprotokolle für die vom Darstellungsmodul unterstützten Darstellungsvorrichtungen.
Das Modul kann einen Privatspeicher erfordern, um verschiedene Nur-Lese- oder Lese/Schreib-Variablen zu speichern, die sich auf die Funktion des Moduls beziehen. Dieser Speicher wird dem Modul als zugewiesener Bereich 32 zur Verfügung gestellt. Dieser Speicher kann z. B. von einem Darstellungsmodul verwendet werden, um Prüftabellen oder Darstellungsformdaten zu speichern, oder kann von einem Zugriffsmodul verwendet werden, um Paßwort-Informationen in einer Stellvertreterzeichen-Anfrage zu speichern (siehe unten).
Die Zugriffspunkte der verschiedenen von den Zugriffsmodulen zur Verfügung gestellten Prozeduren werden durch Zeiger in den Versendeeinträgen 39A und 39B angegeben. Wie später genauer beschrieben wird, werden die Versendeeinträge in die im Kernspeicher 17, 22 gespeicherte Versendetabelle eingefügt und verwendet, um die verschiedenen Prozeduren zu lokalisieren, die das Modul unterstützt. Wie in Fig. 2B gezeigt, beziehen sich die Versendezeiger 39A auf die Prozeduren im Modul, die Managementdienste für das komplexe System zur Verfügung stellen, während sich die Versendezeiger 39B auf die Prozeduren im Modul beziehen, die Managementdienste für das Modul selbst zur Verfügung stellen. Wie oben beschrieben worden ist, werden dann, wenn das Modul in der Steueranordnung angemeldet wird, beide Sätze von Zeigern in den Kernspeicher geladen, um sie beim Management des komplexen Systems oder der in der Steueranordnung enthaltenen Module zu verwenden.
Zusätzlich zur obenerwähnten Struktur ist dem Modul eine Managementspezifikation 48 zugeordnet, die die Klassen von Objekten und Attributen beschreibt, die vom Modul bedient werden, sowie die Direktive und die Antwortstruktur für anfragende Dienste vom Modul. Die Managementspezifikation spezifiziert ferner das Management des Moduls selbst. Während der Anmeldung eines Moduls wird die zugehörige Managementspezifikation in das Datenverzeichnis geladen.

2. Managementspezifikation

Die Eigenschaften, die Zusammensetzung und die Struktur des Dienstelements 31 und der Dienstschnittstelle 33 der Objekte des von der Steueranordnung (Fig. 1A) gemanagten komplexen Systems sowie die verschiedenen Objekte, die die Steueranordnung enthält, werden definiert durch eine Managementspezifikation und eine Versendespezifikation. Die Fig. 3A bis 3D zeigen die Managementspezifikation für ein Objekt genauer, wobei Fig. 3E eine Versendespezifikation definiert, die beim Einleiten einer bestimmten Operation in Verbindung mit dem Objekt verwendet wird. Wie in Fig. 3A gezeigt, enthält die Managementspezifikation für ein Objekt einen Vorspannabschnitt 40 und einen Hauptabschnitt 45. Der Vorspannabschnitt 40 enthält bestimmte Identifikationsinformationen wie z. B. ein Namensfeld 41, das einen Namen enthält, der das Objekt identifiziert, ein Versionsfeld 42, das eine Versionsidentifikation enthält, ein Vorrichtungsfeld 43, das Lokalisierungsinformationen enthält, die den Ort des Objekts innerhalb des komplexen Systems angeben (z. B. die Identifikation des Knotens, wenn das komplexe System ein verteiltes digitales Datenverarbeitungssystem ist), sowie ein Typdeklarationsfeld 44, das ausgewählte Datentypinformationen angibt.
In einer alternativen Ausführungsform kann der Vorspannabschnitt ferner ein Symbol-Präfixfeld enthalten, das in Verbindung mit dem Symbolfeld 52 verwendet wird, wie im folgenden beschrieben wird.
Der Hauptabschnitt 45 der Managementspezifikation enthält die wirkliche Managementspezifikation für das Objekt. Der Hauptabschnitt 45 ist in Fig. 3A genauer definiert. Vorweggenommen enthält die Steueranordnung zwei allgemeine Typen von Objekten, nämlich ein globales Objekt und ein Hilfsobjekt. Die Steueranordnung erleichtert eine Hierarchie von Objekten, wie oben definiert, wobei das globale Objekt in der Hierarchie ein Objekt der obersten Ebene identifiziert und ein Hilfsobjekt ein Objekt identifiziert, das in der Hierarchie einem weiteren Objekt untergeordnet ist. Der Hauptabschnitt 45 einer Managementspezifikation enthält einen dieser zwei Typen von Objektdefinitionen, d. h. eine Definition 45A für ein globales Objekt oder eine Definition 45C für ein untergeordnetes Objekt.
Ein Managementmodul kann Dienste einer globalen Klasse von Objekten oder einer Klasse von Hilfsobjekten innerhalb einer globalen Objektklasse zur Verfügung stellen. Ein bestimmtes Beispiel tritt in der Decnet-Phase-IV auf, die von der Digital Equipment Corporation, Maynard, Massachusetts, vertrieben wird; in der Decnet-Phase-IV ist Adjacent_Node eine untergeordnete Objektklasse, deren übergeordnete Objektklasse Node4_Circuit ist. Wenn ein Managementmodul Dienste speziell der untergeordneten Objektklasse Adjacent_Node bereitstellt, muß die Managementspezifikation einen Mechanismus bereitstellen, der anzeigt, daß die Managementspezifikation für die globale Klasse in der Managementspezifikation für ein weiteres Modul (das die Klasse Node4_Circuit managt) enthalten ist.
Die Definition 45A und 45C für ein globales bzw. Untergeordnetes Objekt sind in den Fig. 3A bis 3D genauer definiert. Eine Objektdefinition 46 enthält ein Namensfeld 47, das einen Namen und einen Code enthält, mit denen das Objekt identifiziert werden kann. Außerdem identifiziert das Namensfeld 47 das Objekt als ein globales oder untergeordnetes Objekt und identifiziert einen Klassennamen für das Objekt. Wenn die Objektdefinition für ein untergeordnetes Objekt gilt, besitzt sie ein Überordnungsfeld 50, das die übergeordneten Objekte in der Hierarchie identifiziert. Ein Identifiziererfeld 51 enthält eine Liste von Attributnamen für Attribute, die später in einem Objekthauptabschnitt 53 definiert werden. Schließlich enthält ein Symbolfeld 52 ein Symbol, das verwendet wird, um eine spezifische Compilerkonstantendatei zu erzeugen, die konsistente Namen zur Verwendung durch einen Objektentwickler enthält.
In einer alternativen Ausführungsform kann ein DYNAMIC- Feld in der Objektdefinition enthalten sein. Dieses Feld kann die Werte WAHR oder FALSCH enthalten und zeigt an, ob die Managementspezifikation für das Objekt in der Konfigurationsdatenbank gespeichert werden soll (Fig. 1B). Dies bietet dem Managementmodulentwickler eine Möglichkeit, genau anzugeben, welche untergeordneten Objektinstanzen in der Konfigurationdatenbank gespeichert werden sollen. Auf diese Weise müssen Objekte wie z. B. die Verbindungen zwischen Knoten, die sehr dynamisch sind, nicht in der Konfiguration des Systems gespeichert werden. Dies beseitigt den Verwaltungsaufwand, der durch wiederholtes Hinzufügen und Entfernen dynamischer Instanzen verursacht wird. Der boolesche Wert des DYNAMIC- Feldes zeigt an, ob die Objektklasse dynamischer Art ist; falls WAHR, werden die Instanzen der Objektklasse nicht in der Konfiguration gespeichert, falls FALSCH, werden die Instanzen der Objektklasse in der Konfiguration gespeichert.
Wie oben erwähnt ist, enthält eine Objektdefinition 46 für ein Objekt einen Hauptabschnitt 53. Der Hauptabschnitt 53 ist in Fig. 3B genauer definiert. Wie in Fig. 3B gezeigt, enthält der Hauptabschnitt 53 einer Managementspezifikation vier Abschnitte, nämlich eine Attributpartitions-Definitionsliste 54, eine Häufungsdefinitionsliste 55, eine Direktivendefinitionsliste 56 und eine Unterordnungsobjektliste 57, falls die Objektklasse irgendwelche untergeordneten Objekte enthält. Wenn der Hauptabschnitt 53 eine Unterordnungsobjektliste 57 enthält, umfaßt jeder Eintrag in der Unterordnungsobjektliste 57 eine Objektdefinition 46 (Fig. 3A), wobei das Namensfeld 47 "SUBORDINATE" enthält.
Wie oben erwähnt, enthält der Hauptabschnitt eine Attributpartitionsliste 54 und eine Attributhäufungsliste 55. An diesem Punkt ist es nützlich, den Unterschied zwischen diesen Listen zu erläutern. Jede Liste nimmt den vollen Satz von Attributen des Objekts und ordnet jedes Attribut einer oder mehreren Gruppen zu; die von der Partitionsliste 54 angegebenen Gruppierungen sind unabhängig von denjenigen, die von der Häufungsliste angegeben werden - jede Liste ist eine unabhängige Charakterisierung der Attribute des Objekts.
Die Partitionsliste 54 identifiziert und gruppiert alle Attribute mit ähnlicher Form; z. B. kann eine Attributpartition alle Zähler oder alle Statusattribute (Merker) enthalten. Das Wort "partition" wird verwendet, um anzuzeigen, das die von den Attributpartitionen gebildeten Gruppen echte Partitionen der Attribute sind - kein Attribut kann Objekt zweier Partitionen sein und jedes Attribut muß ein Objekt von genau einer Partition sein.
Die Häufungsliste 55 identifiziert und gruppiert alle Attribute mit ähnlicher Funktion. Zum Beispiel kann ein Zugriffsmodul für eine NODE4-Globalobjektklasse eine Attributhäufung mit dem Namen "SQUERGE" definieren. Die Attributhäufung SQUERGE kann alle Attribute enthalten, die sich auf die aktuelle Operationsleistung eines NODE4- Klasse-Objekts beziehen, z. B. ein Zählertypattribut, das die Anzahl der gesendeten Bytes angibt, und ein Charakteristiktyp-Attribut, das die Pipelinequote angibt. In diesem Beispiel kann ein Benutzer anschließend diese Statistiken mit z. B. dem folgenden Kommando betrachten:
SHOW NODE < instance> ALL SQUERGE
Das Wort "Häufung" wird verwendet, um anzuzeigen, daß Häufungen Attribute mit ähnlicher Funktion enthalten, jedoch nicht unbedingt Partitionen der Attribute bilden. Ein Attribut kann ein Objekt mehrerer Häufungen sein, wobei nicht alle Attribute ein Mitglied einer Häufung sein müssen.
Die Attributpartitions-Definitionsliste 54 enthält eine oder mehrere Attributdefinitionen 64, wie sie in Fig. 3B genauer definiert sind. Jede Attributpartitions-Definition 64 enthält ein Art-Feld 56, das das Attribut einem bestimmten Typ zuordnet, einschließlich eines Identifizierertyp-Attributs, eines Statustyp-Attributs, eines Zählertyp-Attributs, eines Charakteristiktyp-Attributs, eines Referenztyp-Attributs oder eines Statistiktyp- Attributs. Für jeden Attributtyp wird der Datentyp mittels eines angehängten Feldes 68 angegeben. Die Attributpartitions-Definition 54 kann ferner Felder 60 und 61 enthalten, die jeweils eine Vorgabe-Abrufrate und eine Maximalabrufrate für das Objekt angeben. Wie oben erwähnt ist, kann ein Historiedatenaufzeichnungs-Funktionsmodul 11 periodisch Status- und Bedingungsinformationen zum Speichern im Datenspeicherobjekt 17, 22 in Verbindung mit den verschiedenen Objekten, die das komplexe System umfaßt, enthalten. Die Inhalte der Abrufratenfelder identifizieren die Vorgaberate und die Maximalrate, mit der die entsprechenden Objekte Status- und Bedingungsinformationen liefern. Zusätzlich enthält eine Attributdefinition ein oder mehrere Attributfelder 62, die jeweils einen Attributnamen 63, der einen Code enthält, mit dem auf das Attribut zugegriffen werden kann, und einen zugehörigen Attributkörper 64 enthalten.
Alle Definitionen für Attribute, die Objekte einer Partition sind, befinden sich innerhalb einer Partitionsdefinition 54, wie sie oben angegeben ist. Die unabhängigen Aspekte der Attribute werden von einer oder mehreren Attributkörperdefinitionen 64 angegeben. Die Fig. 3B beschreibt die in einem Attributkörper 64 in einem Attributfeld in einer Attributpartitionsdefinition 55 enthaltenen Informationen genauer. Ein Attributkörper 64 kann eine Anzahl von Feldern enthalten, einschließlich eines Zugriffsinformationsfeldes 65, das angibt, ob das Attribut gelesen oder geschrieben werden kann, sowie eines Anzeigefeldes 66, das angibt, ob das Attribut einem Operator mittels eines Darstellungsmoduls 10 angezeigt werden soll. Ein Vorgabewertfeld 67 identifiziert eine Vorgabe oder einen Anfangswert für das Attribut. Ein Symbolfeld 70 enthält ein Symbol, das verwendet wird, um eine spezifische Compilerkonstantendatei zu erzeugen, die konsistente Namen für die Verwendung durch einen Objektentwickler enthält.
Ein Attributkörper 64 enthält ferner ein Kategorienfeld 71, das eine oder mehrere Kategorien identifiziert, denen das Attribut zugeordnet werden kann. Wenn das komplexe System ein verteiltes digitales Datenverarbeitungssystem ist, können die Kategorien Kategorien umfassen, die durch die 74-98-4-Open-Systems-Interconnect-(OSI)-Norm definiert sind und die CONFIGURATION, FAULT, PERFORMANCE, SECURITY oder ACCOUNTING enthalten, müssen jedoch nicht hierauf beschränkt sein. Außerdem kann der Attributkörper 64 Abrufrateninformationen in den Feldern 72 und 73 enthalten, wenn sich die Abrufraten für das bestimmte Attribut, die vom Attributkörper 64 definiert werden, von den Abrufraten unterscheiden, die in den Feldern 60 und 61 in der Attributpartitions-Definition 54 definiert sind. Schließlich kann der Attributkörper 64 ein Privatvariablenfeld 74 enthalten, das Privatvariablen identifiziert, die im Managementmodul bei der Verarbeitung in Bezug auf das Attribut verwendet werden.
In einer alternativen Ausführungsform können die Abrufrateninformationen in den Attributdefinitionen aufgrund der implementationsspezifischen Eigenart dieser Daten vollständig weggelassen werden. Außerdem kann in alternativen Ausführungsformen ein UNITS-Feld im Attributkörper 64 enthalten sein. Wenn ein UNITS-Feld enthalten ist, können (und sollten) die Einheiten der numerischen Datentypen definiert sein.
Attribute können gehäuft werden, um das Management des komplexen Systems zu vereinfachen. Der Häufungsdefinitionsabschnitt 55 des Objektkörpers 53 identifiziert eine oder mehrere Häufungen, die das Objekt enthalten. Die Inhalte eines Häufungsdefinitionsabschnitts 55 sind in Fig. 3B genauer definiert. Ein Häufungsdefinitionsabschnitt 55 enthält ein Häufungsnamensfeld 75, das die Häufung identifiziert, sowie eine Attributliste 81, die die in der Häufung enthaltenen Attribute identifiziert. Ein Häufungsdefinitionsabschnitt 55 kann ferner eine Liste von Direktiven enthalten, d. h. Anfragen, die mit Bezug auf die Häufung verarbeitet werden können. Ein Häufungsdefinitionsabschnitt 55 kann ein Symbolfeld 77 ähnlich dem obenbeschriebenen Symbolfeld, ein Kategorienfeld 80, das OSI-Kategorie-Informationen enthalten kann, jedoch nicht darauf beschränkt ist, sowie ein Privatvariablenfeld 82 enthalten, das Privatvariablen definiert, die bei der Verarbeitung bezüglich der Attribute verwendet werden, die in der durch den Häufungsnamen im Feld 75 identifizierten Häufung enthalten sind.
Ein Objekt verarbeitet Direktiven, die von der Steueran ordnung als Antwort auf die Anfragen und Hilfsanfragen von einem Darstellungsmodul 10 bzw. einem Funktionsmodul 11 erzeugt worden sind. Jede Direktive enthält eine Direktivenanfrage, die eine durchzuführende Operation definiert, und kann eine Antwort und eine Ausnahme enthalten, die Antworten definiert, die das Objekt in Verbindung mit der Operation erzeugen kann. Jede Direktive ist durch eine Direktivendefinition 56 definiert. Die Fig. 3C und 3D zeigen die Strukturen einer Direktivendefinition 56 genauer. Wie in Fig. 3C gezeigt, enthält eine Direktivendefinition 56 ein Namensfeld 83, das einen Code enthält, mit dem die Direktive identifiziert werden kann und auf dieselbe zugegriffen werden kann. Eine Direktive enthält ein Anfragedefinitionsfeld 90, das die Struktur einer Anfrage oder Hilfsanfrage identifiziert, ein Antwortdefinitionsfeld 91, das die Struktur einer Antwort definiert, sowie ein Ausnahmedefinitionsfeld 92, das die Struktur einer Ausnahme definiert, die während der Verarbeitung der Direktive erzeugt werden kann. Die Einzelheiten der Felder 90, 91 und 92 werden im folgenden beschrieben.
Eine Direktivendefinition 56 kann ferner ein Feld 84 enthalten, das angibt, ob die Direktive eine Aktionsdirektive ist, d. h. ob sie eine Veränderung der Bedingung oder des Zustands einer oder mehrerer Objekte im komplexen System ermöglicht, oder ob sie lediglich die Rückgabe von Status- oder Bedingungsinformationen einleitet. In einer alternativen Ausführungsform kann das Aktionsfeld 84 durch ein Feld DIREKTIVE_TYPE ersetzt sein, das angibt, ob die Direktive den Typ EXAMINE, MODIFY oder ACTION aufweist. Eine Direktive EXAMINE bearbeitet nur Attribute und modifiziert nichts; Beispiele sind die Direktiven SHOW oder DIRECTORY. Eine Direktive MODIFY bearbeitet nur Attribute und modifiziert nichts; Beispiele sind die Direktiven SET, ADD oder REMOVE. Eine Direktive ACTION bearbeitet keine Attribute, statt dessen bearbeiten die Direktiven ACTION das Objekt selbst; Beispiele sind die Direktiven CREATE und TEST.
Es kann ein Feld 85 vorgesehen sein, um anzuzeigen, ob auf die Direktive durch ein Darstellungsmodul 10 zugegriffen werden kann. Eine Identifizierungstextkette kann in einem Symbolfeld 86 vorgesehen sein. Außerdem kann ein Kategorienfeld 87 ein oder mehrere OSI-Kategorien definieren, muß jedoch nicht hierauf beschränkt sein, wie oben in Verbindung mit Feld 71 definiert ist (Fig. 3B).
Die Struktur des Anfragedefinitionsfeldes 90 in einer Direktivendefinition 56 ist in Fig. 3C definiert. Zusätzlich zum Wort "ANFRAGE", kann das Anfragedefinitionsfeld 90 null oder mehr Argumente 91 enthalten, die jeweils durch ein Namensfeld 92 identifiziert werden, das einen Zugriffscode enthält. Außerdem kann ein Argument ein Anzeigefeld 93 enthalten, das angibt, ob das Objekt mittels eines Darstellungsmoduls 10 einem Operator angezeigt werden soll. Das Argument kann ferner das Feld 94, das angibt, ob ein Operator einen Wert für das Argument angeben muß, ein Vorgabefeld 96, das einen Vorgabewert enthält, ein Symbolfeld 97, das eine Identifizierungstextkette enthält, sowie ein Einheitenfeld 95 enthalten, das die Maßeinheiten der Argumentwerte identifiziert. Außerdem kann das Argument 91 ein Privatvariablenfeld 100 enthalten, das die Privatvariablen identifiziert, die bei der Verarbeitung in Verbindung mit dem Argument verwendet werden.
Die Struktur eines Antwortdefinitionsfeldes 91 und eines Ausnahmedefinitionsfeldes 92 sind in Fig. 3D gezeigt. Wie in Fig. 3D gezeigt, enthält ein Antwortdefinitionsfeld 91 ein Antwortnamensfeld 101, das ferner einen Code enthält, mit dem auf die Antwort zugegriffen werden kann. Ein Gewichtungsfeld gibt an, ob die Antwort ERFOLG bei der Durchführung der durch das Anfragefeld 90 definierten Anfrage anzeigt, oder ob die Antwort INFORMELL ist. Ein Textfeld 103 gibt eine Textkette an, die das Darstellungsmodul 10 einem Operator anzeigen kann, um die Antwort anzuzeigen. Außerdem kann ein Antwortdefinitionsfeld ein oder mehrere Argumentfelder 104 enthalten, die jeweils ein Namensfeld 105, ein Einheitenfeld 106 und ein Symbolfeld 107 umfassen.
In alternativen Ausführungsformen kann das GEWICHTUNGS- Feld 102 durch ein SYMBOL-Feld ersetzt sein, das eine Identifizierungstextkette für die Antwort enthält, wobei das ARGUMENTE-Feld 104 ein boolesches ANZEIGE-Feld enthalten kann, um anzuzeigen, ob die Antwort dem Benutzer angezeigt werden soll.
Die Struktur des Ausnahmedefinitionsfeldes 92 ist derjenigen des Antwortdefinitionsfeldes 91 ähnlich und enthält die Felder 111 bis 117, die den Feldern 101 bis 107 des Antwortdefinitionsfeldes 21 entsprechen. Das Gewichtungsfeld 112 kann jedoch drei Variablen enthalten, einschließlich WARNUNG, FEHLER und FATAL, die die Schwere des Fehlers anzeigen, der die Ausnahme hervorgerufen hat.
Wie in der Antwortdefinition 91 kann in alternativen Ausführungsformen das GEWICHTUNGS-Feld 112 durch ein SYMBOL-Feld ersetzt sein, das eine Identifizierungstextkette für die Antwort enthält, während das ARGUMENTE-Feld 114 ein boolesches ANZEIGE-Feld enthalten kann, um anzuzeigen, ob die Antwort dem Benutzer angezeigt werden soll.

3. Versendespezifikation

Fig. 3E definiert eine Versendespezifikation 39A (Fig. 2B), die beim Definieren der Einleitung bestimmter Operationen durch ein Objekt verwendet wird. Die Informationen in den Versendespezifikationen für ein Objekt werden verwendet, um Zeiger und Prozeduren zur Durchführung der Operationen zu erzeugen. Wie in Fig. 3E gezeigt, enthält die Versendespezifikation einen Vorspann 200, der den Anfang der Versendespezifikation definiert und einen Tabellennamen enthält, sowie eine Fußzeile 201, die das Ende der Versendespezifikation definiert. Zwischen dem Vorspann 200 und der Fußzeile 201 enthält die Versendespezifikation einen oder mehrere Versendeeinträge 202, von denen jeder eine Operation in Verbindung mit einem oder mehreren Objekten und Attributen definiert.
Der Versendeeintrag enthält einen Befehlswortabschnitt 203 und einen Objekteintrag 204, die gemeinsam eine Operation identifizieren. Effektiv entsprechen der Befehlswortabschnitt 203 und der Objektabschnitt 204 des Versendeeintrags einer vom Management definierten Direktive. Direktiven können entweder Objekte oder Attribute, die durch einen Attributabschnitt 205 des durch einen Objekteintrag 204 definierten Objekts definiert sind, bearbeiten. Die Inhalte des Objekteintrags 204 entsprechen einem Objekt oder Unterobjekt, das durch eine Objektklasse und einen Instanzennamen in den Namensfeldern 47 und 50 der Objektdefinition 46 identifiziert ist. In ähnlicher Weise entsprechen die Inhalte des Attributabschnitts 205 den Attributen, die durch das Namensfeld 62 der Attributdefinition 254 des Objektkörpers 53 der Objektdefinition 46 definiert sind.
Der Versendeeintrag 202 enthält ferner einen Prozedurzeigerabschnitt 206, der einen Zeiger auf einen Einsprungpunkt in eine Prozedur in einem Zugriffsmodul, das eine Direktive verarbeitet, in Verbindung mit dem Objekt und den Attributen enthält, die in den Abschnitten 203, 204 und 205 des Versendeeintrags 202 identifiziert sind. Wie im folgenden in Verbindung mit den Fig. 5, 7A und 8B beschrieben wird, wird die Versendespezifikation bei der Formulierung von Datenstrukturen, insbesondere von Versendeeinträgen 134 (Fig. 8B) der Versendetabellen 28 (Fig. 5) verwendet, die vom Kern 13, 14 verwendet werden, um Anfragen an die geeigneten Funktionsmodule 11 oder Zugriffsmodule 12 zur Verarbeitung weiterzuleiten. Eine Anfrage oder Hilfsanfrage definiert unbedingt ein Befehlswort, ein Objekt und eine Attributpartition, während der Kern das Befehlswort, das Objekt und die Attributpartition, die von einer Anfrage definiert werden, mit den Inhalten der Abschnitte der Datenstrukturen vergleicht, die von den Abschnitten 203, 204 bzw. 205 der Versendespezifikation definiert werden. Wenn die entsprechenden Abschnitte des Befehlswortes mit den Inhalten der entsprechenden Abschnitte der Datenstrukturen (Fig. 8B) übereinstimmen, leitet der Kern 13, 14 die Prozedur ein, die im Versendeeintrag 134 definiert ist, der aus dem Abschnitt 206 der Versendespezifikation entnommen wird (Fig. 3E).

B. DATENDATEIEN UND VERWENDUNG

1. Datenverzeichnis

Wenn ein Managementmodul angemeldet wird, kann dessen Managementspezifikation neue globale Objektklassen, Unterobjektklassen oder Attribute, Direktiven oder Ereignisse von globalen Objekten oder Unterobjekten definieren. Die Managementspezifikation (Fig. 3A bis 3D) wird verwendet, um ein Datenverzeichnis zu konstruieren, das seinerseits bei der Konstruktion anderer Datenstrukturen verwendet wird, die im folgenden in Verbindung mit den Fig. 5 und 8A beschrieben werden und wie in Fig. 9 gezeigt verwendet werden. Das Datenverzeichnis umfaßt eine hierarchische Datenbank, die das in Fig. 4 gezeigte allgemeine Schema bzw. Struktur aufweist. Wie in Fig. 4 gezeigt, besitzt das Schema einen relativen Wurzelknoten 220, der einem globalen Objekt zugeordnet ist, wie in der Managementspezifikation (Fig. 3A) definiert ist. Der globale Objektknoten zeigt auf mehrere Unterknoten im hierarchischen Schema, einschließlich eines Unterknotens 221, der alle Attribute auflistet, eines Unterknotens 219, der Attributpartitionen auflistet, eines Unterknotens 222, der Attributhäufungen auflistet, eines Unterknotens 223, der Direktiven auflistet, und eines Unterknotens 224, der Unterobjekte des Objektkörpers 53 in der Objektdefinition 46 der Managementspezifikation enthält.
Jeder untergeordnete Knoten 219 bis 224 zeigt seinerseits auf die entsprechenden im Objektkörper definierten Objekte. Das heißt, der Attributknoten 221 zeigt auf die Attributdefinitionsknoten 225, von denen jeder die Definition eines in einer Attributdefinition 54 im Objektkörper 53 definierten Attributs enthält, während der Attributpartitionsknoten 219 auf Attributpartitionsknoten zeigen, von denen jeder eine Attributpartition enthält, die in einer Partitionsdefinition 56 in der Attributdefinition 54 des Objektkörpers 53 definiert ist, der Häufungsknoten 222 auf Häufungsdefinitionsknoten 226 zeigt, die jeweils die Definition einer Häufung enthalten, die in einer Häufungsdefinition 55 im Objektkörper 53 definiert sind, die Direktivenknoten 223 auf Direktivendefinitionsknoten 227 zeigen, die jeweils die Definition einer Direktive enthalten, die in der Direktivendefinition 56 im Objektkörper 53 definiert ist, und die Unterobjektknoten 224 auf Unterobjektdefinitionsknoten 228 zeigen, die jeweils die Definition eines Unterobjekts enthalten, die in einer Unterobjektdefinition 57 im Objektkörper 53 definiert sind. Jeder Direktivenknoten 227 zeigt seinerseits auf einen Anfrageknoten 230, einen Antwortknoten 231 und einen Ausnahmeknoten 232, von denen jeder seinerseits die Definition einer Anfrage, einer Antwort und einer Ausnahme enthält, die aus der Anfragedefinition 90, der Antwortdefinition 91 und der Ausnahmedefinition 92 (Fig. 3C) der Managementspezifikation entnommen werden. Außerdem bildet jeder Unterobjektknoten 228 den Wurzelknoten eines Unterschemas mit einer Struktur, die der in Fig. 4 gezeigten Struktur für ein globales Objekt ähnlich ist, einschließlich eines Unterknotens 233 für Attribute, eines Unterknotens 234 für Häufungen, eines Unterknotens 235 für Direktiven, eines Unterknotens 237 für Partitionen und eines Unterknotens 236 für Unterobjekte. Das in Fig. 4 gezeigte Schema wird für alle Unterobjekte und deren Unterobjekte wiederholt, wie in der in den Fig. 3A bis 3D gezeigten Managementspezifikation definiert ist.
Die Informationen der Managementspezifikation werden in die entsprechenden Knoten des Datenverzeichnisses eingefügt und verwendet, um die Benutzerschnittstelleninformationsdatei 29 zu erzeugen, die von einem Darstellungsmodul 10 in Verbindung mit der Anzeige der Objektinformationen, die Objektidentifikationsinformationen und Antwortinformationen enthalten, für einen Operator und mit der Erzeugung von Anfragen zur Verarbeitung durch andere Abschnitte der Steueranordnung und durch die Objekte des komplexen Systems verwendet wird, wie im folgenden beschrieben wird. Die verschiedenen Knoten des Datenverzeichnisses empfangen die Informationen von den Objekten der Managementspezifikation, um die vollständige Datenbasis zu bilden, die das Datenverzeichnis enthält. Die Informationen in der Versendespezifikation (Fig. 3E) werden verwendet, um die Versendetabellen 28 zu erzeugen, wie unten in Verbindung mit den Fig. 8B und 9 beschrieben wird.
Mit diesem Hintergrund zeigt Fig. 5 jeweils ein einzelnes Darstellungsmodul 10, Funktionsmodul 11 und Zugriffsmodul 12, den Kern 13, 14, der den Informationsmanager 15, 20 und den Versender 16, 21 enthält. Außerdem zeigt die Fig. 5 verschiedene Abschnitte des Datenspeicherobjekts 17, 22. Genauer enthält das Datenspeicherobjekt 17, 22 eine Konfigurations- und Bereichsdatenbank 23, 25, eine Alarmdatenbank 24, eine Historiedatendatei 26, ein Datenverzeichnis 27 sowie eine Versendetabelle 28.

2. Historiedatendatei

Die Historiedatendatei 26 enthält Informationen, die sich im Fall des Darstellungsfunktions-Merkmals des Kerns 13 auf den Status und die Bedingung von Objekten beziehen, und die sich im Fall des Funktionszugriffs-Merkmals des Kerns 14 auf Objekte beziehen. In der Datei 26 enthalten die Status- und Bedingungsinformationen ferner Zeitinformationen zum Identifizieren des Zeitpunkts, zu dem die Status- oder Bedingungsinformationen erzeugt worden sind. Wenn der Informationsmanager 15, 20 eine Anfrage oder eine Hilfsanfrage empfängt, die den Status oder die Bedingung zu einem bestimmten Zeitpunkt betrifft, ermittelt er, ob die Informationen in der Datei 26 vorhanden sind, wenn der in der Anfrage oder Hilfsanfrage angegebene Zeitpunkt in der Vergangenheit liegt, und antwortet unter Verwendung der Inhalte der Datei.
Wenn andererseits der in der Anfrage oder Hilfsanfrage angegebene Zeitpunkt in der Zukunft liegt, teilt der Informationsmanager 15, 20 die Anfrage effektiv zur Verarbeitung zum angegebenen Zeitpunkt ein. Das heißt, der Informationsmanager hält die Anfrage oder Hilfsanfrage zurück, bis der angegebene Zeitpunkt erreicht ist, wobei er zu diesem Zeitpunkt die Anfrage entweder unter Verwendung von Antworten direkt vom Zugriffsmodul 12 oder Funktionsmodul 11, falls geeignet, oder unter Verwendung der Inhalte der Datei 26, falls geeignet, verarbeitet.
Diese Funktionen werden im folgenden unter der Überschrift "Einteilung" ausführlich beschrieben.

3. Versendetabelle

Die Versendetabelle 28 wird vom Versender 16, 21 verwendet, um zu ermitteln, wie eine Anfrage oder Hilfsanfrage zum entsprechenden Funktionsmodul 11 oder Zugriffsmodul 12 zu übertragen ist. Die Inhalte der Versendetabelle 28 identifizieren die Orte der Einsprungpunkte der Routinen im verteilten digitalen Datenverarbeitungssystem, die alle Funktionsmodule 11 umfassen, die als Antwort auf Anfragen von einem Darstellungsmodul 10 aufgerufen werden können. Genauer enthält die Versendetabelle 28 Aufrufinformationen, die das Einleiten verschiedener Operationen durch die entsprechenden Funktionsmodule 11 erleichtern. In ähnlicher Weise identifizieren die Inhalte der Versendetabelle 28 im verteilten digitalen Datenverarbeitungssystem die Orte der Einsprungpunkte der Routinen in den Zugriffsmodulen 12, die zum Verarbeiten von Hilfsanfragen von einem Funktionsmodul 11 verwendet werden, d. h. die Aufrufinformationen, die die verschiedenen Operationen der entsprechenden Objekte definieren.

4. Benutzerschnittstelleninformationen

Die Steueranordnung enthält ferner eine Benutzerschnittstelleninformationsdatei 29, die Informationen über die verschiedenen Funktionen, die von den Funktionsmodulen 11 angeboten werden, und über die von den Zugriffsmodulen 12 gesteuerten Objekte enthält. Die Benutzerschnittstelleninformationsdatei 29 enthält Informationen, die aus den Managementspezifikationen der entsprechenden Objekte abgeleitet sind. Die Darstellungsmodule 10 verwenden die Inhalte der Benutzerschnittstelleninformationsdatei 29 bei der Anzeige von Menüs und anderen Objekten auf den Endgeräten des Operators, um die Steuerung des komplexen Systems zu erleichtern. Die Informationen in der Benutzerschnittstelleninformationsdatei 29 erleichtern das Anzeigen der verschiedenen Funktionen und Operationen in Verbindung mit den Objekten des komplexen Systems.

5. Konfigurationsdatenbank

Wie oben beschrieben worden ist, kann ein Konfigurationsfunktionsmodul eine Konfigurationsdatenbank erzeugen und halten, die alle Objektinstanzen in der aktuellen Konfiguration des komplexen Systems (sowie bei Bedarf auch frühere Konfigurationen) auflistet. Diese Informationen können z. B. von einem Darstellungsmodul verwendet werden, um Prüftabellen oder Benutzermenüs zu erzeugen, die verfügbare Objektinstanzen auflisten. Die Konfigurationsdatenbank kann ferner eine Bereichsdatenbank zum Begrenzen des Kontrollumfangs eines Benutzers enthalten, um die Verwendung des komplexen Systems wie im folgenden beschrieben zu erleichtern.
Zusätzlich zu den oben genannten Merkmalen kann die Konfigurationsdatenbank in einer Ausführungsform in Verbindung mit Darstellungsmodulen verwendet werden, um die Stellvertreterzeichenverwendung in Benutzerkommandos zu unterstützen. Wenn von einem Darstellungsmodul eine Benutzeranweisung empfangen wird, die ein Stellvertreterzeichen enthält, gibt das Darstellungsmodul eine Anfrage an das Konfigurationsfunktionsmodul aus, die eine Aufzählung aller Objekte in der Konfiguration anfordert, die zur Stellvertreterzeichenanfrage passen. Das Konfigurationsfunktionsmodul verwendet anschließend die Informationen in der Konfigurationsdatenbank (gemeinsam mit Bereichsinformationen) um die Liste zu erzeugen. Nach dem Empfangen der Liste erweitert das Darstellungsmodul die Benutzeranfrage auf alle möglichen Hilfsanfragen, die der Stellvertreterzeichenverwendung entsprechen.
Zum Beispiel wird die Anfrage
SHOW NODE * IN DOMAIN SITE1
(wobei SHOW die Direktive ist, DOMAIN die Bereichsobjektklasse ist, SITE1 eine Bereichsinstanz ist, NODE eine globale Objektklasse ist und * das Stellvertreterzeichen ist) als ein Kommando interpretiert, daß alle Instanzen der Knoten innerhalb des Bereichs mit dem Namen SITE1 gezeigt werden sollen. Das Darstellungsmodul würde daher die Anfrage zu mehreren Anfragen erweitern, die jeweils die Form
SHOW NODE < instance>
aufweisen (wobei < instance> der Instanzennamen ist), von denen eine jeweils einer Instanz der Klasse NODE im Bereich SITE1 entspricht.
Eine teilweise Stellvertreterzeichenverwendung kann ebenfalls unterstützt werden. In diesem Fall werden Direktiven an die Gruppe von Zielobjekten ausgegeben, deren Instanzennamen mit dem durch den teilweise mit Stellvertreterzeichen versehenen Namen übereinstimmen. Zum Beispiel würde "NODE *OO", mit "NODE FOO" und mit "NODE MAGOO", jedoch nicht mit "NODE BAR" übereinstimmen.
Eine teilweise Stellvertreterzeichenverwendung kann nicht in Feldern verwendet werden, die Identifizierer mit bestimmten Datentypen besitzen, z. B. Identifizierer, die keinen Text oder Zeichenketten verwenden.
In bevorzugten Ausführungsformen ist die Stellvertreterzeichenerweiterung im Globalobjektklassenfeld einer Benutzerdirektive nicht zulässig. Globalklassenspezifikationen werden nicht mit Stellvertreterzeichen verwendet, da dies zu einer ungenügenden Kontrolle des Umfangs eines Kommandos führen würde. Dies kann Fehler erzeugen, wenn die von einer Objektklasse unterstützten Direktivennamen von einer weiteren nicht unterstützt werden. Selbst wenn ein Direktivenname von mehreren Klassen unterstützt wird, kann sich der Direktivenname auf nicht verwandte Funktionen in unterschiedlichen Klassen beziehen, was unerwünschte Nebeneffekte verursacht (z. B. eine Direktive "DELETE +") Außerdem kann eine Globalobjekt-Stellvertreterzeichennutzung einfach mehr Informationen hervorrufen, als der Benutzer beabsichtigt (z. B. eine Direktive "SHOW +") Es ist zu beachten, daß die Stellvertreterzeichennutzung in Unterobjektklassen sicher zugelassen werden kann.
Die Ausführungsformen der Stellvertreterzeichennutzung können ferner einige oder alle der Stellvertreterzeichenerweiterungsaufgaben an Zugriffsmodule delegieren. Dies ist insbesondere dann der Fall, wenn kein Konfigurationsfunktionsmodul verwendet wird. Bei Fehlen eines Konfigurationsfunktionsmoduls können die Zugriffsmodule (gewöhnlich begleitet vom Zugreifen auf alle Module einer Klasse oder Unterklasse) Instanzendaten als Teil ihres Privatspeichers 32 (Fig. 2B) speichern. In diesem Fall verwenden die Zugriffsmodule die Instanzendaten zum Erweitern der Stellvertreterzeichen in der empfangenen Anfrage. Wenn die Stellvertreterzeichennutzung von einem bestimmten Zugriffsmodul nicht unterstützt wird, wird dem Benutzer eine Ausgabe zurückgegeben, die diese Bedingung anzeigt.

C. DATENDATEIMANAGEMENT UND ANMELDUNG

Wenn ein Managementmodul zur Steueranordnung hinzugefügt wird oder wenn neue Informationen bezüglich des Managements der Objekte zur Verfügung gestellt werden, muß die Steueranordnung angepaßt werden. Die Steueranordnung ist datengesteuert, so daß das Anpassen des Systems an neue Module oder Informationen die Modifizierung der relevanten Datendateien erfordert. Im allgemeinen ist dieser Prozeß bekannt als Datendateimanagement. Die genaue Prozedur, mit der die Steueranordnung an ein neues Modul angepaßt wird, ist als Anmeldung bekannt.

1. Historiedatendatei-Management

In einer bestimmten Ausführungsform werden die Inhalte der Historiedatendatei 26 von einem Funktionsmodul 11, das als Historiedatenaufzeichnungs-Funktionsmodul dient, erzeugt und teilweise gehalten. In dieser Ausführungsform wird das Historiedatenaufzeichnungs-Funktionsmodul von einem Operator über Anfragen gesteuert, die an ein Darstellungsmodul 10 weitergeleitet werden. Zu Beginn richtet eine solche Anfrage, die ein Objekt und eines oder mehrere Attribute zusammen mit einer Abfragerate identifiziert, einen Datensatz in der Historiedatendatei für das identifizierte Objekt und die Attribute ein und gibt das Historiedatenaufzeichnungs-Funktionsmodul frei, so daß dieses mit der in der Anfrage spezifizierten Abrufrate Hilfsanfragen an das Objekt ausgibt, die diesem ermöglichen, mit Werten zu antworten, die die Bedingungen der Objekte des komplexen Systems darstellen, welche durch das Objekt und die Attribute spezifiziert werden, die in der Anfrage angegeben sind. Außerdem erlauben andere Typen von Anfragen einem Operator, andere Operationen in Verbindung mit dem Historiedatenaufzeichnungs- Funktionsmodul einzuleiten, einschließlich der Änderung der Abrufrate, einer vorübergehenden Freigabe und Sperrung des Abrufs sowie dem Anzeigen des letzten Werts in einer Antwort.

2. Versendetabelle

Die Inhalte der Versendetabelle 28 und der Benutzerschnittstelleninformationsdatei 29 enthalten Anmeldeinformationen und werden während einer Anmeldeprozedur von den verschiedenen Funktionsmodulen 11 und Zugriffsmodulen 12 zur Verfügung gestellt. Während einer Anmeldeprozedur, in der ein Modul sich in der Steueranordnung anmeldet, lädt es die Anzeigeinformationen einschließlich des Namens und der Codeinformationen aus seinem Namensfeld in das Datenverzeichnis. Außerdem lädt das Modul die Codeinformationen und andere Informationen, die von der Managementspezifikation definiert werden, aus dem Datenverzeichnis (Fig. 4) sowie die Versendeinformationen aus seiner Versendespezifikation (Fig. 3E) in die Versendetabelle.

3. Benutzerschnittstelleninformationen

Die Darstellungsmodule 10 verwenden die Anzeigeinformationen in der Benutzerschnittstelleninformationsdatei 29, um zu ermitteln, ob erstens ein Objekt, ein Attribut, eine Direktive usw. anzuzeigen ist, und zweitens, was anzuzeigen ist. Die Benutzerschnittstelleninformationsdatei 29 bildet eine Prüftabelle, die als Antwort auf ein Kommando von einem Operator an einem Endgerät dem Darstellungsmodul 10 ermöglicht, das Kommando zu empfangen, um das Kommando unter Verwendung der Prüftabelle zu prüfen und Codes abzuleiten, die dem Code für die Anfrage, das Objekt und die Attribute entsprechen, die in einer Managementspezifikation definiert sind, welche sie dann als Anfrage zum Kern 13 sendet.
Es ist zu beachten, daß die Funktions- und Zugriffsmodule keinen Benutzerschnittstellencode besitzen müssen. Die gesamte Benutzerschnittstellenunterstützung wird diesen Modulen zur Verfügung gestellt, wobei der Modulentwickler sich selbst nicht mit der Benutzerschnittstelle befassen muß. Dies vereinfacht den Modulentwurf erheblich und garantiert, daß das System ein einheitliches Erscheinungsbild und eine einheitliche Bedienung für den Benutzer aufweist, unabhängig von den momentan verwendeten Modulen.
Nach dem Empfangen einer Anfrage von einem Darstellungsmodul ruft der Versender 16 das Funktionsmodul 11 unter Verwendung der Versendeinformationen in der Versendetabelle 28 auf. Die Versendetabelle 28 bildet ferner eine Prüftabelle, die der Versender 16 verwendet, um an die richtige Prozedur zu versenden, um die Anfrage zu verarbeiten, wie im folgenden in Verbindung mit Fig. 9 beschrieben wird.
Es wird angenommen, daß die Verwendung von Codes in der Prüftabelle und in der Versendetabelle 28 bei gleichzeitiger Verwendung der darstellungsspezifischen Informationen in der Benutzerschnittstelleninformationsdatei 29 die Identifikationen der Objekte, Attribute und dergleichen, die vom Versender 16 verwendet werden, im wesentlichen von den Identifikationen trennt, die mittels der Darstellungsmodule 10 den Operatoren angezeigt werden. Die von den Darstellungsmodulen 10 erzeugte Anzeige kann daher verschiedene Sprachen aufweisen, während die von den Darstellungsmodulen 10 erzeugten Anfragen die gleichen Identifikationen der Objekte, Attribute und dergleichen enthalten.
Außerdem kann die Benutzerschnittstelleninformationsdatei 29 Informationen speichern, die bereits aus der Konfigurationsdatenbank und dem Datenverzeichnis in einem günstigeren Format zur Verfügung stehen.
Zum Beispiel zeigen die Klassendaten im Datenverzeichnis (Fig. 4) alle Direktiven 233 an, die von den Objekten im komplexen System unterstützt werden. Die Direktiven 223 sind jedoch in einem hierarchischem Format gespeichert und sind den Objektklassen 220 untergeordnet. Obwohl dieses Format für die Darstellung der Objektklasseninformationen logisch ist, ist es für eine Prüftabelle weniger nützlich. Eine Benutzeranfrage listet typischerweise zuerst die Direktiven auf (z. B. "SHOW" in SHOW NODE FOO"), so daß eine Prüftabelle die Direktiven als erste Ebene einer hierarchischen Struktur aufweisen sollte. Anhand des obigen Beispiels wird ferner deutlich, daß eine Prüftabelle möglicherweise ein Kommando prüfen muß, wenn Klassennamen (z. B. "NODE") mit Instanzennamen (z. B. der Identifizierer FOO in "NODE FOO") gemischt sind. Daher sollte die Prüftabelle nach einer Auflistung der verfügbaren Direktiven die Klassennamen auflisten, die diese Direktiven unterstützen, und anschließend die Datentypen der Instanzen dieser Klassen. Obwohl die Klassen- und Datentypinformationen aus einer Umordnung des Datenverzeichnisses zur Erweiterung der Stellvertreterzeichen zur Verfügung stehen, können die Instanzendaten aus der Konfigurationsdatenbank erhalten werden. Somit können die Prüftabellen in der Benutzerschnittstelleninformationsdatei die Direktiven- und Objektklassen konsolidieren, wodurch das Prüfen der Benutzereingaben bei der Berechnung effizienter wird.
Das obige Beispiel wird ferner auf eine graphische oder menügesteuerte Schnittstelle angewendet. Bei diesem Schnittstellentyp kann jedoch der Benutzer wünschen, einen Kontext für seine Kommandos zu setzen, indem er graphisch ein bestimmtes Objekt oder einen Bereich von Objekten für die nachfolgenden Operationen sowie die OSI- Kategorie (die im Kategoriefeld 87 der Direktivendefinitionen aufgelistet ist) der auszuführenden Direktiven auswählt. Als nächstes kann ein Menü erzeugt werden, das alle unterstützten Direktiven auflistet. Der Benutzer kann eine Direktive für eine oder mehrere Instanzen (z. B. durch Anklicken der Direktive und der Instanz) oder einen ganzen Bereich oder eine Objektklasse (indem er z. B. auf die Direktive allein klickt) unter Verwendung vorgefertigter Menüs anfordern. Bei einer Direktive des Typs EXAMINE oder CATEGORY können dem Benutzer weitere Menüs angezeigt werden, um Attributpartitionen oder Häufungen auszuwählen.
Um diesen Schnittstellentyp zu implementieren, müssen eine Auflistung aller Bereiche und Objektinstanzen sowie eine Auflistung aller Instanzen in einem Bereich aus der Konfigurationsdatenbank geholt werden. Außerdem kann eine Formulardatenbank die von der Klasse oder dem Bereich unterstützten Direktiven speichern.
Die Benutzerschnittstelleninformationsdatei kann ferner Vorgabewertinformationen speichern. Die Vorgabewerte für die Instanzen oder Klassen können vom Benutzer oder von der Managementspezifikation für die relevante Objektklasse zur Verfügung gestellt werden. Dies erlaubt dem Benutzer, Eingabezeit einzusparen, indem er in einem Kommando einen Vorgabewert spezifiziert. Zum Beispiel kann sich der Benutzer hauptsächlich mit NODE FOO befassen und kann "NODE FOO" als den Vorgabeknoten spezifizieren. Später kann der Benutzer ein Kommando wie z. B. "SHOW ROUTING" eintippen, was interpretiert würde als "SHOW NODE FOO ROUTING". Ähnliche Verwendungen von Vorgabewerten können in einer graphischen Umgebung verwendet werden.
Ein weiteres Beispiel der Benutzerschnittstelleninformationen ist eine Online-Hilfedatei, die dem Benutzer über Darstellungsmodule zugänglich ist. Die Hilfedatei enthält Hilfeinformationen für die Verwendung des bestehenden Satzes von Managementmodulen. In bevorzugten Ausführungsformen ist die Hilfedatei aus Hilfeinformationen konstruiert, die von den Modulen geliefert werden, wenn sie angemeldet werden. Die gelieferten Hilfeinformationen können eine Textbeschreibung der Objekt- und Unterobjektklassen, die vom Modul unterstützt werden, und die Direktiven für diese vom Modul unterstützten Klassen enthalten. Außerdem können Leerinformationen geliefert werden, um einen Benutzer bei der erstmaligen Verwendung des Moduls und seiner Direktiven anzuleiten. Die obigen Informationen können ferner aus der Managementspezifikation für das Modul ermittelt werden, jedoch übersetzt die Hilfeinformationsdatei die Managementspezifikationsinformationen in englische Sätze, was den Aufwand für einen Benutzer zum Erlernen der Syntax der Managementspezifikation reduziert.

4. Historiedatenaufzeichnungsvorrichtung

Das Historiedatenaufzeichnungs-Funktionsmodul 11 kann die Abrufinformationen der Objekte aus seinem Abschnitt des Datenverzeichnisses, das die Abschnitte enthält, die sich auf das Maximalabrufratenfeld und das Vorgabeabrufratenfeld beziehen, verwenden, um das Abrufen in Verbindung mit den verschiedenen Attributen des Objekts, die in den Attributdefinitionen 54 definiert sind, einzuleiten und steuern, wobei die Antworten hierauf vom Historiedaten aufzeichnungs-Funktionsmodul 11 in dessen Historiedaten datei 26 gespeichert werden.

5. Modulanmeldung

Wie in Fig. 5 gezeigt, lädt z. B. ein Zugriffsmodul 12, während es eine Anmeldungsprozedur durchführt, Anzeigeinformationen, die den Namen und die Codeinformationen enthalten, die in der Namen- und Codeinformationen definiert sind, aus seinen Namensfeldern und die Informationen aus dem Abschnitt seines Datenverzeichnisses, die sich auf die Anzeigefelder in seiner Managementspezifikation beziehen, in die Benutzerschnittstelleninformationsdatei 29. In ähnlicher Weise lädt ein Funktionsmodul 11 die Codeinformationen und andere Informationen, die von der Managementspezifikation definiert werden, aus dem Datenverzeichnis (Fig. 4) sowie die Versendeinformationen aus der Versendespezifikation (Fig. 3E) in die Versendetabelle 28.

D. ZWISCHENMODUL- UND ZWISCHENKNOTEN-KOMMUNIKATION

1. Steuerfunktionsmodul

In einer speziellen Ausführungsform kann der Operator ein Zugriffsmodul 12 direkt über ein Steuerfunktionsmodul 11 steuern, das im wesentlichen Hilfsanfragen erzeugt, die Kopien der Anfragen sind, die es vom Versender 16 empfängt. In dieser Ausführungsform prüft das Darstellungsmodul 10, das das Kommando empfängt, das Kommando unter Verwendung der Prüftabelle in der Benutzerschnittstelleninformationsdatei 29, um Codes abzuleiten, die den Code für die Anfrage, das Objekt und die Attribute des Zugriffsmoduls 12 entsprechen, die in einer Managementspezifikation spezifiziert sind, die es dann als Anfrage zum Darstellungsfunktions-Kern 13 sendet. Das Steuerfunk tionsmodul 11 leitet die Anfrage als Hilfsanfrage an den Funktionszugriffs-Kern 14 weiter, wo sie in der gleichen Weise behandelt wird wie jede andere Hilfsanfrage.
Nach dem Empfangen einer Hilfsanfrage von einem Funktionsmodul 11 ruft der Versender 21 das Zugriffsmodul 12 unter Verwendung der Versendeinformationen in der Versendetabelle 28 auf. Die Versendetabelle 28 bildet ferner eine Prüftabelle, die der Versender 21 verwendet, um die geeignete Prozedur zur Verarbeitung der Anfrage zu versenden, wie im folgenden in Verbindung mit den Fig. 9A und 9B beschrieben wird.

2. Zwischenknotenkommunikation

Wenn die Steueranordnung ein komplexes System steuert, das ein verteiltes digitales Datenverarbeitungssystem umfaßt, zeigt die Fig. 5 allgemein die Objekte, einschließlich eines Darstellungsmoduls 10, eines Funktionsmoduls 11 und eines Zugriffsmoduls 12, einschließlich des Kerns 13, 14, der den Informationsmanager 15, 20 und den Versender 16, 21 sowie die zugehörigen Datendateien 23, 24, 25, 26, 27, die Versendetabelle 28 und die Benutzerschnittstelleninformationsdatei 29 umfaßt, die alle in einem einzigen Prozeß in einem einzigen Knoten eines verteilten digitalen Datenverarbeitungssystems enthalten sind. Wenn das verteilte digitale Datenverarbeitungssystem ein Darstellungsmodul 10, ein Funktionsmodul 11 und ein Zugriffsmodul 12 in unterschiedlichen Prozessen oder Knoten enthält, enthält die Steueranordnung einen Versender 16, 21 in allen Prozessen und Knoten. Wie in Fig. 6 gezeigt, sendet ein Versender 16(1) dann, wenn er in einem Prozeß in einem Knoten eine Anfrage von einem Darstellungsmodul 10(1) enthält, das von einem Funktionsmodul 11(2) in einem zweiten Prozeß oder Knoten verarbeitet werden muß, diese Anfrage mittels eines Zwischenprozeßkommunikationsmechanismus, wenn das Funktionsmodul 11(2) sich in einem weiteren Prozeß im gleichen Knoten befindet, oder mittels eines Zwischenknotenkommunikationsmechanismus zu einem Prozeß im anderen Knoten, zu einem Versender 16(2) im anderen Prozeß oder Knoten. Der Versender 16(2) wählt anschließend ein Funktionsmodul 11(2), um die Anfrage zu verarbeiten. Der Versender 16(2) empfängt die vom Funktionsmodul 11(2) erzeugte Antwort und sendet diese mittels des Zwischenprozeßkommunikationsmechanismus oder des Zwischenknotenkommunikationsmechanismus zum Versender 16(1), der seinerseits ein Darstellungsmodul 10(1) frei gibt, um die Antwort dem Operator anzuzeigen.
Wenn in ähnlicher Weise ein Versender 21(2) eine Hilfsanfrage von einem Funktionsmodul 11(2) empfängt, die von einem Zugriffsmodul 12(3) in einem weiteren Prozeß oder Knoten zu verarbeiten ist, sendet er die Hilfsanfrage zu einem Versender 21(3) im anderen Prozeß oder Knoten mittels des Zwischenprozeßkommunikationsmechanismus bzw. des Zwischenknotenkommunikationsmechanismus. Der Versender 21(3) sendet anschließend die Hilfsanfrage zur Verarbeitung zum Zugriffsmodul 12(3). Der Versender 21(3) empfängt die Antwort vom Zugriffsmodul 12(3) und sendet diese mittels des Zwischenprozeßkommunikationsmechanismus oder des Zwischenknotenkommunikationsmechanismus zum Versender 21(2), der diese seinerseits an das Funktionsmodul 11(2) weiterleitet

3. Anfrage- und Hilfsanfragestruktur

Die Struktur einer Hilfsanfrage und insbesondere die Parameter, die in der Hilfsanfrage enthalten sind, sind in Fig. 7A gezeigt. Die Struktur und die Inhalte der Versendetabelle 24 (die der Struktur und den Inhalten der Versendetabelle 26 ähnlich sind), werden in Verbindung mit den Fig. 8A und 8B beschrieben. Anschließend wird der vom Informationsmanager 15, 20 und vom Versender 16, 21 in Verbindung mit der Prüfung einer Anfrage durchgeführte Prozeß in Verbindung mit Fig. 9 beschrieben.
Wie in Fig. 7A gezeigt, enthält eine Anfrage, die von einem Darstellungsmodul 10 als Antwort auf Operationen seitens eines Operators in Verbindung mit den Inhalten der Benutzerschnittstelleninformationsdatei 27 erzeugt worden sein kann oder die vom Informationsmanager 15 während des Abrufs in Verbindung mit den verschiedenen Objekten des gesteuerten komplexen Systems erzeugt worden sein kann, mehrere Parameter. Alle Anfragen weisen die gleiche Struktur auf, die eine Anfangsaufrufidentifikation enthält, die nicht gezeigt ist, gefolgt von Parametern, die in Fig. 7A gezeigt sind. Wie oben beschrieben ist, besitzt der Kern 13, 14 einen einzelnen Versender 16, 21 mit einem Darstellungsfunktionsmerkmal 16 und einem Funktionszugriffsmerkmal 21. Welches dieser Merkmale jeweils durch eine Anfrage aktiviert wird, wird bestimmt durch den Anfangsaufrufidentifizierer. Der Anfangsaufrufidentifizierer kann einen Aufruf an ein Funktionsmodul oder an ein Zugriffsmodul anzeigen und wird entsprechend zum zugehörigen Merkmal des Versenders weitergeleitet. Ein Darstellungs- oder Funktionsmodul kann ein Funktionsmodul aufrufen, während ein Funktionsmodul oder ein Zugriffsmodul ein Zugriffsmodul aufrufen kann, jedoch kann ein Darstellungsmodul ein Zugriffsmodul nur über ein "Steuer"-Funktionsmodul aufrufen, wie oben beschrieben worden ist.
Die Parameter enthalten ein Befehlswortfeld 120, dessen Inhalte den Typ der Anfrage identifizieren, d. h. eine bei der Verarbeitung der Anfrage auszuführende Operation. Wie oben erwähnt worden ist, kann eine Anfrage ein Funktionsmodul 11 oder ein Zugriffsmodul 12 veranlassen, eine Änderung des Status oder der Bedingung eines Objekts im gesteuerten komplexen System auszulösen, wobei sie die Rückgabe von Informationen über den Status oder die Bedingung eines solchen Objekts veranlassen kann, oder beides. Die Inhalte des Befehlswortfeldes 120 zeigen die vom Funktionsmodul 11 oder vom Zugriffsmodul 12 auszuführende Operation an.
Außerdem enthält eine Anfrage ein Eingangsobjektspezifikationsfeld 121, das das Objekt im gesteuerten komplexen System identifiziert. Wenn das Befehlswort z. B. ein aktionsloses Befehlswort ist, enthält die Anfrage dann, wenn es eine Antwort anfordert, die die Werte eines oder mehrerer Attribute anzeigt, ein Attributzeigerfeld 122, das einen Zeiger auf ein oder mehrere Attribute enthält, mit dem die Operation, die durch das Befehlswort und die Objektklasse definiert wird, auszuführen ist. Wenn das Befehlswort ein Aktionsbefehlswort ist, d. h. wenn es eine Änderung im spezifizierten Objekt verursacht, weist die Anfrage kein Attributzeigerfeld 122 auf.
Außerdem enthält eine Anfrage ein Eingabezeitspezifiziererfeld 123, das einen Zeiger enthält, das auf eine Zeitdatenstruktur zeigt, die eine bestimmte Zeitinformation enthält, welche die absolute Systemzeit, eine Zeitintervalldefinition und die Zeitgenauigkeitsspezifikation umfaßt, sowie eine Anzeige des interessierenden Zeitbereichs in der Anfrage für Einteilungszwecke. Ein Eingang/Ausgang-Kontexthantiererfeld 124 enthält einen Wert, der die Anfrage im Kontext einer mehrteiligen Operation identifiziert, von der jeder Teil eine separate Anfrage erfordert. Ein Ausgangsobjektspezifiziererfeld 126 enthält einen Zeiger auf einen Datenpuffer, der vom Versender 15 (oder vom Versender 21, falls die Parameter einen Teil einer Hilfsanfrage bilden) in Verbindung mit der Identifikation des Objekts verwendet werden kann.
Eine Anfrage enthält ferner ein Ausgangszeitspezifikationsfeld 126, das einen Zeiger auf eine Zeitstempelspezifikation enthält, die vom Funktionsmodul 11 (oder im Fall einer Hilfsanfrage vom Zugriffsmodul 12) in Verbindung mit der Ausbildung der Antwort verwendet werden soll. Schließlich enthält ein optionales Datendeskriptorfeld 127 Deskriptoren für Puffer, die Daten enthalten, die bei der Verarbeitung der Anfrage verwendet werden sollen bzw. in welchen das Objekt die Daten, die eine Antwort enthalten, speichern soll. Jeder Deskriptor enthält einen Zeiger auf die Anfangsstelle des entsprechenden Puffers und einen Längenspezifizierer, der die Länge des Puffers angibt.
In alternativen Ausführungsformen der Erfindung kann die Anfrage ferner Qualifiziererfelder als einen separaten Parameter oder als ein zusätzliches Objekt der obenbeschriebenen Parameterfelder enthalten.
Ein Qualifizierer WITH kann dem Objekt-Feld zugeordnet sein, um z. B. die mittels eines Stellvertreterzeichens erzeugte Objektliste zu filtern. Zum Beispiel bezieht sich "BRIDGE * WITH STATUS = 'ON' AND FILTERING = 'OFF'" auf alle Brückenklassenobjekte, deren Statusmerker auf ON und deren Filtermerker auf OFF gesetzt sind. (Dieses Beispiel zeigt ferner die Verwendung der booleschen Funktionen wie z. B. AND, OR, NOT und XOR mit den Quantifizierern.) In bevorzugten Ausführungsformen werden zum Implementieren des Qualifizierers WITH alle Module und der Informationsmanager so konfiguriert, daß sie auf das Vorhandensein einer Klausel WITH auf jeder Ebene (nämlich Globalobjekt, Unterobjekt, Unterunterobjekt) der Objektparameter prüfen.
Andere Qualifizierer können als Unterscheidungsparameter der Anfrage verwendet werden. Zum Beispiel enthalten Kommunikationsqualifizierer: einen Qualifizierer "TO < Dateiname> ", der die Antwort auf eine Anfrage an eine Datei mit der Bezeichnung < Dateiname> sendet; einen Qualifizierer "FROM < Dateiname> , der andere Anfragenparameter aus einer Datei mit der Bezeichnung < Dateiname> wiedergewinnt; einen Qualifizierer "VIA PATH", der eine Serie von "Sprüngen" längs eines Pfades durch eine Hierarchie von Managementmodulen spezifiziert (nützlich bei der Spezifizierung von z. B. einem bestimmten Managementmodul unter mehreren Anordnungen, die die Operation ausführen); sowie einen Qualifizierer "VIA PORT", der einen bestimmten Netzpfad spezifiziert, den ein Managementmodul verwendet, wenn es die Operation ausführt (nützlich um z. B. zu spezifizieren, das ein Zugriffsmodul einen Diagnosetest unter Verwendung eines bestimmten Ethernet-Anschlusses durchführt).
In ähnlicher Weise können Unterscheidungsparameterqualifizierer eine Gruppe von interessierenden Objekten spezifizieren. Der Qualifizierer "IN DOMAIN < domain name> " filtert die Direktive, um sie nur auf die Mitglieder des Bereichs mit der Bezeichnung < domain name> anzuwenden.
Ferner können Unterscheidungsparameterqualifizierer den Anfrager von Managementdiensten, die begrenzte Zugriffsprivilegien aufweisen, authentisieren oder autonsieren. Die Qualifizierer "BY ACCOUNT", "BY PASSWORD" und "BY USER" sind Beispiele, die den Kontonamen, das Paßwort oder die Benutzer-ID des Anfragers für diese Zwecke spezifizieren.
Zusätzlich zum Obenerwähnten spezifizieren die Qualifizierer den Zeitpunkt, zu dem eine Direktive ausgeführt werden soll. Im allgemeinen wird dies mittels einer AT- Klausel bewerkstelligt. Für ein SHOW-Kommando ist die Syntax einer AT-Klausel folgende:
< AT-Klausel> ::= "AT" < time-arg> {"," < time-arg> },
wobei das Zeitargument < time-arg> z. B. den Startzeit punkt ("START = < TIME> "), den Endzeitpunkt ("END = < time> ") oder die Dauer < "DURATION = < timelength> "), die Wiederholungsperiode "REPEAT EVERY [=] < time-length> "), die Zeitgenauigkeit ("CONFIDENCE [=] < time-length> ") oder die Abtastrate ("SAMPLE RATE [=] < time-length") anzeigt. Diese Argumente können miteinander in Wechselwirkung treten, um eine allgemeine Einteilung und einen Interessenumfang für eine Anfrage zu erzeugen. Genauer stehen in einer bestimmten Ausführungsform die drei Zeitargumente START, END und DURATION so miteinander in Beziehung, daß zwei beliebige von diesen eine Periode definieren. Wenn somit eine zeitlich normierte Objektstatistik angezeigt wird, müssen wenigstens zwei dieser Qualifiziererargumente spezifiziert sein.
Ferner können andere Zeitqualifizierer verwendet werden. Zum Beispiel kann ein Zeitqualifizierer AT oder BEFORE < time> als eine Anfrage für eine beliebige Information mit einem Zeitstempel zu oder vor dem Zeitpunkt, der mittels < time> gegeben ist, interpretiert werden. Nach dem Empfangen einer Anfrage mit einem solchen Qualifizierer prüft ein Managementmodul kontinuierlich auf Aktionen, die die angeforderten Informationen erzeugen. Wenn die Informationen z. B. durch die Aktionen einer weiteren Partei erzeugt worden sind, werden sie zum Anfrager zurückgegeben. Ansonsten fährt das Managementmodul mit der Prüfung auf die Informationen fort, bis der Zeitpunkt < time> erreicht worden ist. Wenn die Informationen erzeugt worden sind, werden sie anschließend zum Anfrager zurückgegeben. Ansonsten erzwingt das Managementmodul zum Zeitpunkt < time> einen Abruf der Informationen aus den Zugriffsmodulen oder den Objekten und gibt die Informationen zum Anfrager zurück.
Als Komplement zum Zeitgualifizierer AT oder BEFORE kann ferner ein Zeitqualifizierer NOW implementiert werden. Dieser Qualifizierer erzwingt sofort einen Abruf der angeforderten Informationen.

E. ZEIT

Wie oben beschrieben worden ist, enthält eine Anfragestruktur ein Zeitspezifiziererfeld 123. Außerdem enthält ein Feld 124 einen Hantiererzeiger auf eine Kontextdatenstruktur, die ein zugewiesenes Segment des Speichers zum Speichern von Verarbeitungskontextinformationen ist. Der Hantierer wird als "Notizbuch" für den Austausch von z. B. Kontextinformationen zwischen Modulen und dem Informationsmanager verwendet.

1. Zeitstempel

Jedes Datenobjekt enthält einen Zeitstempelwert. Im Fall der zum Benutzer oder zu einem Managementmodul zurückgegebenen Daten zeigt der Zeitstempel folgendes an: den Zeitpunkt, zu dem ein durch ein Datenobjekt beschriebenes Ereignis aufgetreten ist, den Zeitpunkt, zu dem die Datenwerte für eine Direktive zurückgegeben werden, oder den Zeitpunkt, zu dem eine angeforderte Aktion wirklich ausgeführt wurde. Im Fall der in der Historiedatendatei gespeicherten Historiedaten zeigt der Zeitstempel den Zeitpunkt an, zu dem ein gegebenes Datenobjekt einen bestimmten Wert aufwies. Für die Zwecke der Historiedatendatei kann ein Zeitstempel als Schlüssel oder Index betrachtet werden. Eine Interessenumfangszeitspezifikation 123 kann verwendet werden, um die Wiedergewinnung eines bestimmten Teils der gespeicherten Informationen mit einem gegebenen Schlüssel oder Index anzufordern.

2. Interessenumfang

Interessenumfangszeitspezifikationen werden von Anfragen unter Verwendung des Zeitspezifiziererfeldes 123 geliefert. Unter Verwendung eines Zeitspezifizierers können andere Datenwerte als "der augenblickliche Wert" angezeigt und verarbeitet werden, wobei Statistiken über eine bestimmte Zeitperiode berechnet werden können. In einer bestimmten Ausführungsform wird ein Zeitpunkt- "Interessenumfang" ausgedrückt durch vorangestellte Ausdrücke im Zeitspezifizierer einer Anfrage. Im allgemeinen wird ein Zeitspezifizierer mit einem Kommando SHOW verwendet, jedoch können Zeitkontexte auch auf Anfragen und Aktionen des Typs MODIFY angewendet werden.
Interessenumfangs-Zeitpunkte können entweder durch einen absoluten Zeitpunkt, eine Folge absoluter Zeitpunkte, ein Intervall (Startzeitpunkt "START" und Dauer "DUR"), eine Wiederholung von Zeitpunkten oder eine Wiederholung von Intervallen angegeben werden.
Jedem von diesen kann eine relative Zeitperiode ("EVERY") zugeordnet sein, die die Periodizität spezifiziert, mit der der Zeitpunkt, die Zeitpunkte oder das Intervall wiederholt werden. Wenn eine Periode spezifiziert ist, wird der ursprüngliche Zeitpunkt oder die Folge von Zeitpunkten oder das Intervall als eine Basis behandelt, zu der die Periode wiederholt hinzugefügt wird. Zum Beispiel ist die Zeitspezifikation "5:00 EVERY 0:15" äquivalent zu 5:00, 5:15, 5:30, 5:45, ... . Ein absoluter Zeitpunkt ("UNTIL") kann spezifiziert werden, um anzuzeigen, wann die Wiederholung beendet werden soll. Zum Beispiel ist die Zeitspezifikation "5:00 EVERY 0:15 UNTIL 6:00" äquivalent zu 5:00, 5:15, 5:30, 5:45, 6:00. Wiederholungsintervalle können in der gleichen Weise spezifiziert werden. "START 5:00 DUR :05 EVERY 1:00" ist äquivalent zu den Intervallen 5:00-5:05, 6:00-6:05, 7:00-7:05, ... .

3. Einteilung

Einteilungsinformationen werden ebenfalls mit dem Zeitspezifiziererfeld 123 geliefert. Spezielle Einteilungszeitpunkte können entweder mittels eines absoluten Zeitpunkts oder mit einer Folge von absoluten Zeitpunkten angegeben werden. Anders als bei den Interessenumfängen können Einteilungszeitpunkte kein Intervall enthalten. Intervalle, deren Anfangs- und Endpunkte gleich sind, gehen in Zeitpunkte über (z. B. (TODAY, TODAY)).
Für Intervalle gelten einige Regeln. Intervalle in der Vergangenheit können Anfangszeitpunkte aufweisen, die mit dem Schlüsselwort YESTERDAY oder einem absoluten Zeitpunkt in der Vergangenheit bezeichnet sind. In ähnlicher Weise können Intervalle in der Zukunft einen Anfangspunkt besitzen, der mit dem Schlüsselwort TOMORROW oder mit einem absoluten Zeitpunkt in der Zukunft bezeichnet ist. Ferner muß der Startzeitpunkt eines Intervalls vor dessen Endzeitpunkt liegen.

4. Zeitkontexthantiererstruktur

Wie oben beschrieben worden ist, können die Einteilungsund Interessenumfangsinformationen in einer Anfrage von einem zugehörigen Kontexthantierer begleitet werden. Der Hantierer wird von dem Modul erzeugt, daß die Anfrage ausführt, und wird anschließend bei der Kommunikation mit dem Dienstanbieter verwendet. Wenn ein Aufruf vom Dienstanbieter, z. B. vom Informationsmanager, empfangen wird, wird ein Kontextblock als lokale Referenz auf den Zeitkontext des Anfragers erzeugt.
Im allgemeinen werden Kontextblöcke und Hantierer als Referenzen auf den Status einer Anfrage verwendet. Da die ursprüngliche Anfrage viele Hilfsanfragen erzeugen kann, ist es möglich, daß viele Hantierer und Kontextblöcke von einer einzelnen Anfrage erzeugt werden können. Die Kontextblöcke sind die von einem Dienstanbieter verwendete Referenz, während die Hantierer die vom Dienstanfrager verwendete Referenz sind. Jeder Prozeß (d. h. ein Modul oder ein Informationsmanager) in einer Anfrage/Hilfsanfrage-Kette kennt nur den Kontextblock und die Hantierer, die sich auf seinen lokalen Abschnitt der Kette beziehen.
Wie in Fig. 7B gezeigt, enthält in einer bestimmten Ausführungsform ein Zeitkontexthantierer 172, der von einem Anfrager wie z. B. einem Darstellungsmodul 10 erzeugt worden ist, ein Umfangsfeld 175 und ein Einteilungsfeld 176, die sich auf die Zeitspezifikation 23 der ursprünglichen Anfrage beziehen. Diese Felder ergänzen die Daten im Zeitspezifizierer der Anfrage und werden verwendet, um den aktuellen Status zu ermitteln, wenn für eine einzige Operation mehrere Anfragen und Antworten existieren. Der Hantierer 172 enthält ferner einen Kontextzeiger 177 und eine Zustandsvariable 178. Diese Datenobjekte liefern den Status und die Referenzfunkionen des Hantierers und werden mit den Umfangs- und Einteilungsfeldern 175, 176 erzeugt und gespeichert, wenn die Anfrage erzeugt wird.
Wenn mehrfache Anfragen und Antworten für eine einzelne Operation existieren, enthält das Kontextfeld 177 möglicherweise einen Zeiger auf eine zusätzliche Datenstruktur 174, die als Kontextblock bekannt ist und vom Dienst der Anbieter, z. B. dem Darstellungsfunktionsmerkmal 15 des Informationsmanagers, als Antwort auf eine ursprüngliche Anfrage, die mehrfache Antworten erfordert, erzeugt und gehalten wird (Funktions- oder Zugriffsmodule können ebenfalls Kontextblöcke als Antwort auf Anfragen erzeugen und halten).
Das Zustandsfeld 178 des Hantierers enthält einen von drei Werten: "FIRST", "MORE" oder "CANCEL", die als Merker verwendet werden, um weitere Aktionen anzuzeigen, die ausgeführt werden sollen. Bei der ersten Erzeugung wird der Hantiererzustand auf "FIRST" gesetzt.
Wenn wie oben beschrieben eine Anfrage mittels einer einzigen Antwort befriedigt werden kann, wird die Antwort erzeugt und zum Anfrager zurückgegeben. Im allgemeineren Fall kann der Dienstanbieter, z. B. ein Funktionsmodul, der Informationsmanager oder ein Zugriffsmodul, die Anfrage nicht mit einer Antwort befriedigen. Zum Beispiel kann der Anfrager im Eingangsobjektparameter 121 Stellvertreterzeichen verwendet haben, um eine Gruppe von Objekten zu spezifizieren. Da jede Antwort nur die Informationen aus einem einzelnen Objekt enthalten kann, sind mehrere Antworten erforderlich, eine für jedes Objekt. In einem weiteren Fall kann eine Anfrage an ein einzelnes Objekt einen Zeitspezifizierer mit mehreren unterschiedlichen Zeitwerten aufweisen. Da jede Antwort nur Informationen für einen einzelnen Zeitwert enthalten kann, sind mehrere Antworten erforderlich, eine für jeden Zeitpunkt. Eine Anfrage, die mehrfache Antworten erfordert, kann für jeden beliebigen Operationstyp gelten, auch für das Erhalten von Attributdaten über ein Objekt oder Objekte, das Modifizieren von Attributen mehrerer Objekte und das Modifizieren des Zustands mehrerer Objekte.
Wenn der Dienstanbieter die Anfrage verarbeitet und feststellt, daß er zusätzliche Antworten besitzt, ist er dafür verantwortlich, dies dem Anfrager mitzuteilen. Daher ist der Anfrager dafür verantwortlich, den Dienstanbieter für die zusätzlichen Antworten abzufragen. Um dies zu implementieren müssen zwischenzeitliche Prozesse, z. B. der Informationsmanager, die Informationen sichern, die die Anfrage betreffen, die sie erzeugt haben.
Die letztere Funktion wird bewerkstelligt durch Erzeugen eines Kontextblocks 174, der relevante Privatvariablen 173 enthalten kann, die bei der Beantwortung der Anfrage erzeugt worden sind, wie z. B. einen Zeiger auf den Versendeeintrag des Dienstanbieters (siehe Beschreibung unter Versendetabelle unten) sowie Kontextzeiger 179 auf irgendwelche Hantierer, die sich auf Hilfsanfragen an z. B. ein Funktionsmodul beziehen.
Die Hantierer und Kontextblöcke werden wie folgt verwendet. Der Dienstanbieter benachrichtigt den Anfrager, daß er zusätzliche Antworten besitzt, indem er die geeigneten Hantierermodifikationsroutinen benutzt, um: (1) einen Zeiger 177 auf seinen Kontextblock 174 im Anfragerhantierer 172 zu sichern und (2) das Zustandsfeld 178 im Anfragerhantierer 172 auf einen Wert "MORE" zu setzen. Wenn die Antwort zum Anfrager zurückgegeben wird, sieht der Anfrager den Zustand "MORE" in seinen Hantiererzustandsfeld und erkennt somit, daß der Dienstanbieter zusätzliche Antworten für diese Anfrage besitzt. Wenn der Anfrager diese zusätzlichen Antworten nicht wünscht, muß er die Anfrage löschen (wie folgt). Wenn der Anfrager die zusätzlichen Antworten wünscht, muß die Anfrage wiederholt werden, ohne irgendwelche Parameter zu ändern.
Wenn der Dienstanbieter diese wiederholten Anfragen empfängt (die ein Hantiererzustandsfeld 178 mit dem Wert "MORE" aufweisen), sucht er nach dem Zustand "MORE" unter Verwendung der geeigneten Hantiererzugriffsroutine und detektiert diesen. Anschließend weiß der Dienstanbieter, daß die Aufrufe Teil einer vorher gestellten Anfrage sind. (Es ist zu beachten, daß ein Hantierer mit einem Zustand "FIRST" dem Dienstanbieter anzeigt, daß der zugehörige Aufruf der erste Aufruf der Anfrage ist.) Für jeden Aufruf mit einem Hantiererzustand "MORE" holt sich der Dienstanbieter den Kontextblock 174, auf den das Hantiererkontextfeld 177 zeigt, und verwendet den Kontextblock, um seine Ausführung fortzusetzen und zusätzliche Antworten zu liefern. Für jeden an den Dienstanbieter gestellten Aufruf gibt es nur eine einzige Antwort. Solange der Dienstanbieter den Hantiererparameter im Zustand "MORE" hält, besitzt er weitere Antworten für die Anfrage.
Wenn der Dienstanbieter seine letzte Antwort (die z. B. mittels der Umfangs- und Einteilungsfelder 175, 176 im Anfragerhantierer ermittelt wird) an den Anfrager zurückgibt, wird das Anfragerhantiererzustandsfeld 178 auf einen Wert "FIRST" (den Initialisierungszustand) zurückgesetzt. Wenn diese letzte Antwort dem Anfrager zurückgegeben wird, erkennt der Anfrager, daß sein Hantiererparameterzustand auf "FIRST" zurückgesetzt ist, und erkennt, daß seine Anfrage vollständig befriedigt worden ist. Es ist zu beachten, daß dann, wenn die Anfrage mit einer einzigen Antwort befriedigt ist, der Dienstanbieter keinen Kontext zurückbehält und nie veranlaßt, daß der Zustand des Hantiererparameters den Zustand "MORE" annimmt. Der Anfragerhantierer verharrt in diesem Fall in seinem Initialisierungszustand "FIRST", was dem Anfrager anzeigt, daß die Anfrage abgeschlossen ist.
Wenn ein Dienstanbieter den Hantiererparameter im Zustand "MORE" zurückgibt, muß die Anfrage wiederholt oder gelöscht werden. Wenn die Anfrage auf andere Weise abge schlossen wird, gehen aufgrund des für den Hantierer und den Kontextblock reservierten Speichers Systembetriebsmittel verloren.
Bei der obigen Beschreibung ist zu beachten, daß dann, wenn der Dienstanbieter keine Hilfsanfragen ausgegeben hat, ein einzelner Hantierer für die Kommunikation zwischen dem Dienstanfrager und dem Anbieter ausreicht. Wenn jedoch der Dienstanbieter Hilfsanfragen ausgegeben hat, gibt es mehr als einen separaten Hantierer - den ursprünglichen Anfragerhantierer, der vom Anfrager für den Aufruf erzeugt worden ist, sowie verschiedene Hantierer, die z. B. vom Informationsmanager erzeugt worden sind und z. B. an ein Zugriffsmodul weitergeleitet werden.
Wenn mehrere Anfragen und Antworten für eine einzelne Operation vorhanden sind, wird vom Informationsmanager eine Einteilung der Hilfsanfragen an den Dienstanbieter durchgeführt und mittels der Einteilungszeitkomponente des Zeitspezifizierungsparameters 123 gesteuert. Für jede in der Zeitspezifikation spezifizierte Einteilungszeit erzeugt der Informationsmanager eine Anfrage, die den Dienstanbieter veranlaßt, die angeforderte Operation durchzuführen und Antworten auszugeben.
Wenn der Dienstanbieter die angeforderte Operation abgeschlossen hat, gibt er eine Antwort aus. Wenn der Informationsmanager erkennt, daß der Dienstanbieter die angeforderte Operation abgeschlossen hat, untersucht er anschließend den Einteilungszeitkontext, den er für die ursprüngliche Anfrage hält. Wenn weitere Zeitpunkte vorhanden sind, für die die angeforderte Operation eingeteilt ist, setzt der Informationsmanager den Anfragerhantiererzustand nicht auf "FIRST", sondern läßt ihn im Zustand "MORE". Der Anfrager sieht seinen Hantiererparameter weiterhin im Zustand "MORE" und erkennt, daß die vollständige Anfrage noch nicht abgeschlossen ist, und fragt nach dem Rest. Der Informationsmanager veranlaßt anschließend ein Warten bis zur spezifizierten Einteilungszeit und erlaubt anschließend dem Versender, einen weiteren Aufruf an den Dienstanbieter auszuführen. Es ist zu beachten, daß der Dienstanbieter diesen nächsten Aufruf nicht von demjenigen einer völlig neuen Anfrage unterscheiden kann, da er keinen Kontext zurückbehalten hat, nachdem er seinen Hantiererzustand auf "FIRST" zurückgesetzt hat. Ferner unterscheidet der Anfrager nicht zwischen einem Hantiererzustand "MORE", der vom Dienstanbieter mit mehreren Antworten auf eine Anfrage erzeugt worden ist, und demjenigen, der vom Informationsmanager bei der Vorbereitung eines neuen Einteilungszeitpunktes erzeugt worden ist.
In anderen Ausführungsformen sind die Hantiererzugriffsroutinen verbessert, um dem Chent zu ermöglichen, die Ursache des Zustands "MORE" des Hantiererparameters zu ermitteln.
Wenn während einer Anfrage mit mehreren Antworten oder mehreren Einteilungszeiten der Anfrager entscheidet, daß er keine weiteren Antworten vom Dienstanbieter für diese Anfrage wünscht, muß er die Anfrage löschen. Mögliche Gründe für den Wunsch einer Löschung der Anfrage umfassendes Empfangen einer Ausnahmeantwort, die anzeigt, daß weitere Daten nicht nützlich sind, oder das Empfangen einer Fehlerbedingung, die anzeigt, daß die gewünschte Operation nicht richtig durchgeführt wird. Die Gründe für das Löschen stehen in der Verantwortung des Anfragers. Eine Löschung beendet alle Aktivitäten der Anfrage, einschließlich irgendwelcher Einteilungs- und Interessenumfangsoperationen.
Eine Löschung kann durchgeführt werden, wenn der Dienstanbieter dem Anfrager einen Hantiererparameterzustand "MORE" zurückgibt. Der Anfrager führt das Löschen aus, indem er die geeignete Hantierermodifikationsroutine verwendet, um den Hantiererparameter in einen Wert "CANCEL" zu ändern, und den Aufruf erneut ausgibt. Der Anfrager muß für diesen Aufruf keine anderen Parameter ändern. Wenn der Dienstanbieter diesen Aufruf empfängt, erkennt er den Hantiererparameter mit dem Zustand "CANCEL" statt des erwarteten Zustands "MORE". Er holt seinen Kontext aus dem Hantiererparameter und verwendet diesen Kontext, um irgendwelche erforderlichen Aufräumarbeiten durchzuführen. Diese Aufräumarbeiten umfassen das Löschen von Anfragen niedrigerer Ebene, die er ausgegeben hat, das Beenden jeglicher Verarbeitung und das Zurückgeben aller Systembetriebsmittel. Wenn der Dienstanbieter seine Aufräumarbeiten abgeschlossen hat, verwendet er die entsprechende Hantierermodifikationsroutine, um den Hantiererparameter erneut in den Zustand "FIRST" zurückzusetzen. Anschließend gibt er den speziellen Bedingungswertrückgabecode CANCELED zurück, um ein erfolgreiches Löschen der Anfrage anzuzeigen.
Der Anfrager kann eine Anfrage nicht löschen, nachdem der Dienstanbieter einen Hantiererparameterzustand "FIRST" zurückgegeben hat. Die Anfrage ist bereits abgeschlossen und es existiert kein Dienstanbieterkontext, der zu löschen ist. Die obenbeschriebene Löschroutine gibt daher einen Fehler zurück, wenn der Hantiererzustand nicht gleich "MORE" ist.

F. VERSENDEN

Die Versendetabellen 28 enthalten mehrere Datenstrukturen, von denen eine in Fig. 8A gezeigt ist, sowie eine oder mehrere Versendelisten, die Versendeeinträge enthalten, von denen einer in Fig. 8B dargestellt ist. Der Versendebaum und die Versendelisten bilden im wesentlichen Prüftabellen, die beim Prüfen einer Anfrage verwendet werden, wie im folgenden in Verbindung mit Fig. 9 beschrieben wird. Wie in Fig. 8A gezeigt, enthält ein Versendebaum mehrere Objektknoten 130. Die Objektknoten 130 sind in einer Baumstruktur organisiert, um das Prüfen zu unterstützen, sie können jedoch in anderen Datenstrukturen organisiert sein. Die Objektknoten identifizieren die verschiedenen Objekte im komplexen System, mit welchen eine Anfrage ausgegeben werden kann. Die Objektknoten 130 enthalten Zeiger, die auf Versendeeinträge 134 (Fig. 8B) in den in entsprechenden Versendetabellen 28 gehaltenen Versendelisten zeigen.
Der Ausdruck "Objektknoten" wird verwendet, um die Datenstruktur 130 zu beschreiben, da diese das obenbeschnebene Objektmodell erfüllt. Im allgemeinen erfüllt die Datenstruktur 130 das Objektmodell, da sie eine hierarchische Struktur aufweist und ihre Ablegerstrukturen ähnlich sind. Der Ausdruck "Objektknoten", wie er zur Beschreibung der Datenstruktur 130 verwendet wird, sollte nicht mit dem Ausdruck "Objekt" verwechselt werden, der zur Beschreibung der Objekte des komplexen Systems verwendet wird.
Ein Objektknoten 130 enthält mehrere Felder, einschließlich eines Klassen/Instanzen-Merkerfeldes 140, das anzeigt, ob sich der Objektknoten 130 auf eine Objektklasse oder eine Instanz innerhalb einer Klasse bezieht. Jedes Objekt kann eine Instanz einer Klasse sein, wobei die Klasse durch einen Klassennamen definiert ist, der in der Objektdefinition 46 des Objekts (Fig. 3A) identifiziert ist, während die Versendetabelle 24 separate Objektknoten 130 enthält, die der Klasse und der Instanz zugeordnet sind, wie im folgenden in Verbindung mit Fig. 9 beschrieben wird.
Während die Anfrage geprüft wird, werden die Klassennamen und Instanzennamen eines Objekts und seiner Unterobjekte unter Verwendung der Datenstrukturen des in Fig. 8A gezeigten Typs geprüft, obwohl die Struktur beim Prüfen der Klassennamen oder Instanzennamen anders verwendet wird. Der Fall für die Klassen oder Instanzen wird mittels des Klassen/Instanzen-Merkers angezeigt.
Der Objektknoten 130 enthält ferner Baumverbindungszeiger, die verschiedene andere Objekte in der Versendetabelle 28 identifizieren. Ein Modul, das Anfragen bedient, die sich auf mehrere Objekte derselben Klasse beziehen, kann mittels eines Stellvertreterzeichens oder eines Ellipsenzeichens identifiziert werden. Ist dies der Fall, besitzt ein zugehöriger Objektknoten einen Stellvertreterzeichenzeiger in einem Feld 141 oder einen Ellipsenzeichenzeiger in einem Feld 142. Jeder Stellvertreterzeichenzeiger und Ellipsenzeichenzeiger umfaßt einen Baumverbindungseintrag, wie im folgenden beschrieben wird. Wenn der Objektknoten sich auf eine Klasse bezieht, die keine Instanzen besitzt, ein Beispiel hierfür wird im folgenden in Verbindung mit Fig. 9 beschrieben, enthält ein Feld 143 einen Null-Zeiger, der einen Baumverbindungseintrag auf einen weiteren Objektknoten enthält. Schließlich enthält ein Feld 131 einen codierten Eintrag, der den Code enthält, der die Klasse oder den Namen einer Instanz des Objekts identifiziert, das dem Objektknoten zugeordnet ist, sowie einen Verbindungszeiger.
Das codierte Eintragsfeld 131, das im Objektknoten 130 der Fig. 8A gezeigt ist, ist ein Eintrag in eine codierte Liste. (Der Rest der Liste ist nicht gezeigt.) Die codierte Liste ist eine verkettete Liste, die Namen von Klassen von Objekten enthält, die durch die Managementspezifikationen der Objekte definiert sind (siehe Fig. 3A bis 3D), wenn sie sich auf Klassen oder Namen von Instanzen von Objekten beziehen. Jeder codierte Eintrag 131 enthält einen Zeiger 150 auf den nächsten codierten Eintrag in der Liste, ein Klassencode/Instanzennamen- Wertfeld 151 sowie ein Feld 152, das einen Verbindungseintrag 133 enthält, der einen Zeiger auf einen Objektknoten 130 oder auf einen Versendeeintrag 134 enthält.
Das Klassencode/Instanzenwert-Feld 151 im codierten Eintrag 133 enthält entweder einen Klassencode oder einen Instanzennamen. Die Inhalte des Feldes 151 umfassen einen Klassencode, wenn das Klassen/Instanzen-Merkerfeld 140 des Objektknotens 130 bedingt ist, um den Objektknoten als einer Klasse zugehörig zu identifizieren. Alternativ enthalten die Inhalte des Feldes 151 einen Instanzennamen, wenn das Klassen/Instanzen-Merkerfeld 140 des Objektknotens 130 so beschaffen ist, daß es den Objektknoten als einer Instanz zugehörig identifiziert.
Wie in Fig. 8B gezeigt, werden die Versendeeinträge 134 in einer Versendeliste verwendet, um die bestimmte Prozedur zur Verarbeitung einer Anfrage zu identifizieren. Eine Versendeliste ist eine verkettete Liste eines oder mehrerer Versendeeinträge 134, wobei jeder Eintrag 134 Informationen enthält, die für die Übertragung einer Anfrage oder einer Hilfsanfrage zu einem geeigneten Funktionsmodul 11 oder Zugriffsmodul 12 nützlich sind. Genauer enthält ein Versendeeintrag 134 einen Zeiger 160 auf einen nächsten Versendeeintrag 134 in der Liste. Ein Feld 161 enthält eine Identifikation des Funktionsmoduls 11 oder des Zugriffsmoduls 12, bei dessen Anmeldung der Versendeeintrag 134 erzeugt worden ist. Ein Versendeeintrag 134 enthält ferner eine Reihe von Feldern 162 bis 164, die auf eine Prozedur, einen Prozeß und einen Knoten im komplexen System zur Verarbeitung einer Anfrage zeigen. Ein Feld 165 identifiziert das Befehlswort, dem der Versendeeintrag zugeordnet ist, während ein Attributfeld 166 einen Satz von Attributen identifiziert, wie sie mittels Attributen identifiziert werden, die von einem Attributdefinitionsfeld 54 der Managementspezifikation (Fig. 3B) definiert werden. Schließlich identifiziert ein Zählerfeld 167 die Häufigkeit, mit der der Versender den Versendeeintrag 134 in Verbindung mit der Verarbeitung einer Anfrage oder einer Hilfsanfrage verwendet hat.
Mit diesem Hintergrund wird der vom Versender 16 beim Prüfen und Versenden einer Anfrage von einem Darstellungsmodul 10 ausgeführte Prozeß in Verbindung mit Fig. 9 beschrieben. Es wird angenommen, daß der Versender 21 einen ähnlichen Prozeß in Verbindung mit einer Hilfsanfrage von einem Funktionsmodul 11 durchführt. Wie in Fig. 9 gezeigt, sieht eine Anfrage 180 wie folgt aus:
SHOW
NODE < node name>
ROUTING
CIRCUIT (routing circuit name)
CHARACTERISTICS,
die in Verbindung mit einem verteilten digitalen Datenverarbeitungssystem verwendet wird. Die Anfrage 180 enthält eine Anzahl von Abschnitten, einschließlich eines Befehlswortabschnitts 181, nämlich SHOW, eines Objektabschnitts, der mehrere Objektklassencodes und Instanzennamen 182 bis 186 enthält, sowie eines Attributabschnitt 187, der mehrere Attribute enthält. In diesem Beispiel leitet das Befehlswort SHOW die Erzeugung einer Antwort von dem Objekt, das in der Anfrage genannt ist, bezüglich der genannten Eigenschaften ein.
In der Anfrage 180 enthält der Objektabschnitt, d. h. die Objekte 182 bis 186, mehrere Klassen/Instanzen-Paare. Genauer ist das Objekt 182, NODE, ein Klassencode, während das Objekt 183, nämlich < node name> , mit dem Instanzennamen < node name> eine Instanz der Objektklasse NODE identifiziert. Im verteilen digitalen Datenverarbeitungssystem identifiziert < node name> einen Knoten im verteilen digitalen Datenverarbeitungssystem.
Außerdem enthält die Anfrage 180 im Objektabschnitt einen Objektklassencode 184, ROUTINE, der keine Instanzen besitzt. Zusätzlich besitzt die Anfrage 180 einen weiteren Objektklassencode, CIRCUIT, der eine durch < ROUTING CIRCUIT NAME> identifizierte Instanz besitzt.
Wie in den Fig. 3A bis 3D gezeigt, die eine Managementspezifikation darstellen, sind verschiedene Objekte einer Anfrage in Verbindung mit einem Objekt spezifiziert durch die Managementspezifikation. Genauer werden die Inhalte des Befehlswortabschnitts 181 einer Anfrage aus den Direktiven entnommen, die durch die Direktivendefinitionen 56 definiert sind, während die Objektklassen- und Unterobjektklassennamen 182, 184, 185 aus dem Objektklassencodefeld 47 entnommen werden und der Attributabschnitt 87 aus den Attributdefinitionen 54 der Managementspezifikation für das Objekt entnommen wird.
Die Objekt- und Unterobjektinstanzennamen werden aus den Instanzendaten entnommen, die dem Benutzer bekannt sind (z. B. durch Zugriff auf die Konfigurationsdatenbank oder durch automatisch erzeugte Menüs)
Als Antwort auf das Empfangen einer Anfrage beginnt der Versender 16 zuerst mit dem Prüfen der Anfrage im Objektabschnitt, der mit dem Globalobjektklassencodeobjekt 182 beginnt, unter Verwendung der Objektknoten 130 (Fig. 8A). Genauer beginnt, wie in Fig. 9A gezeigt, der Versender 16 zuerst (Schritt 190) bei einem Wurzelobjektknoten 130, der einen Klassen/Instanzen-Merker 140 besitzt, der angibt, daß dem Objektknoten Klassencodes zugeordnet sind, und sucht nach einem Eintrag seiner codierten Liste 131, die einen codierten Eintrag 131 enthält, der seinerseits ein Klassencodefeld 151 besitzt, das einen Klassencode NODE enthält. Wenn der Versender 16 keinen solchen Eintrag in der Versendetabelle 28 finden kann, sucht er nach einem Stellvertreterzeichen- oder Ellipsenzeichenzeiger (siehe unten). (Wenn keine Stellvertreterzeichen- oder Ellipsenzeichenzeiger gefunden werden, antwortet er dem Modul 10, von dem er die Anfrage empfangen hat, mit einem Fehler.)
Wenn der Versender 16 einen solchen Objektknoten 130 in der Versendetabelle 28 lokalisiert, rückt er zum nächsten Schritt (Schritt 191) in der Prüfoperation vor, indem er versucht, einen Objektknoten 130 zu lokalisieren, dem die Instanz (node name) zugeordnet ist, wie im Objektelement 183 spezifiziert ist. Bei dieser Operation verwendet der Versender 16 die Inhalte des Zeigerfeldes 152 im codierten Eintrag 131, um einen Objektknoten mit einem Klassen/Instanzen-Merker 140 zu lokalisieren, der angibt, daß dem Objektknoten Instanzennamen zugeordnet sind, und dessen codierte Liste einen codierten Eintrag 131 enthält, dessen Instanzennameneintrag 132 dem (node name) im Objektelement 183 der Anfrage 180 entspricht. Wenn der Versender 16 wiederum keinen solchen Knoten 130 in der Versendetabelle 28 lokalisieren kann, sucht er erneut nach einem Stellvertreterzeichen- oder Ellipsenzeichenzeiger (siehe unten).
Wenn der Versender 16 andererseits im Schritt 191 in der Versendetabelle 28 einen dem Element 183 zugeordneten Objektknoten lokalisiert, rückt er zum nächsten Schritt (Schritt 192) vor, in dem er versucht, einen Objektknoten zu lokalisieren, dem der Klassencode 184, ROUTING, zugeordnet ist. Bei dieser Operation verwendet der Versender 16 den Zeiger im Feld 152 des codierten Eintrags 131 und das Objektelement ROUTING aus der Anfrage, um einen Objektknoten 130 zu lokalisieren, der einen Klassen/Instanzen-Merker 140 enthält, der angibt, daß dem Objektknoten Klassencodes zugeordnet sind, und dessen codierte Eintragsliste einen codierten Eintrag 131 enthält, der ein Klassencodefeld 151 besitzt, das ROUTING enthält. Da in dieser Situation die Objektklasse ROUTING eine Objektklasse ohne Instanzen ist, ist das Zeigerfeld 152 im codierten Eintrag 133 gleich Null. In diesem Fall zeigt das Null-Zeigerfeld 143 im Objektknoten 130 auf einen zweiten Objektknoten 130, dem das Klassenobjekt CIRCUIT zugeordnet ist.
Im Schritt 192 verwendet der Versender 16 den Null-Zeiger im Objektknoten 130, der dem im Schritt 192 lokalisierten ROUTING-Klassenobjekt zugeordnet ist, um einen zweiten Objektknoten 130 zu lokalisieren, dessen Klassen/Instanzen-Merker 140 anzeigt, daß diesem Klassencodes zugeordnet sind, sowie eine codierte Liste, die einen codierten Eintrag 131 enthält, dessen Klassencodefeld 151 CIRCUIT enthält (Schritt 193). Wenn der Versender keinen solchen Objektknoten lokalisieren kann, sucht er nach einem Stellvertreterzeichen- oder Ellipsenzeichenzeiger (siehe unten).
Wenn der Versender 16 andererseits im Schritt 193 einen Objektknoten 130 lokalisiert, rückt er zu Schritt 194 vor, in dem er versucht, einen Objektknoten 130 zu lokalisieren, der das Instanzenobjektelement < ROUTING CIRCUIT NAME> identifiziert. Bei dieser Operation verwendet er den Zeiger im Feld 152 des codierten Eintrags 131, um einen Objektknoten 130 zu lokalisieren, dessen Klassen/Instanzen-Merker 140 angibt, daß diesem Instanzenna men zugeordnet sind, und dessen codierte Liste einen codierten Eintrag 132 enthält, dessen Instanzennamensfeld 151 < ROUTING CIRCUIT NAME> enthält, wie im Instanzenobjekt 186 der Anfrage 180 spezifiziert ist. Wenn der Versender 16 keinen solchen Eintrag lokalisieren kann, sucht er nach einem Steilvertreterzeichen- oder Ellipsenzeichenzeiger (siehe unten).
Wenn andererseits der Versender im Schritt 194 einen Instanzenobjektknoten 130 lokalisiert, der das Instanzenobjektelement 186 identifiziert, hat er den Elementabschnitt 182 bis 186 der Anfrage 180 erfolgreich geprüft. Anschließend verwendet der Versender 16 den Zeiger im Feld 152 des im Schritt 94 lokalisierten codierten Eintrags 131, das Befehlswort im Befehlswortelement 181 und die Attribute im Charakteristikelement 187 der Anfrage, um einen Versendeeintrag 134 zu identifizieren (Fig. 8B), der bei der Verarbeitung der Anfrage verwendet werden soll. Genauer verwendet der Versender 16 nach dem Schritt 194 den Zeiger im Feld 152 des codierten Eintrags 131, um eine Liste von Versendeeinträgen 134 zu identifizieren. Anschließend versucht der Versender 16, einen Versendeeintrag 134 zu lokalisieren, dessen Inhalte im Befehlswortfeld 165 dem Befehlswortelement 181 der Anfrage 180, in diesem Fall SHOW, entsprechen und dessen Inhalte im Attributfeld 166 den Attributen im CHARACTERISTIC-Element 187 entsprechen.
Wenn der Versender im Schritt 195 einen solchen Versendeeintrag 134 lokalisiert, verwendet er die Inhalte des Prozeduridentifikationsfeldes 162, des Prozeßidentifikationsfeldes 163 und des Knotenidentifikationsfeldes 164, um die Prozedur zur Verarbeitung der Anfrage aufzurufen. Bei der Operation überträgt der Versender 16 effektiv die Anfrage für die Verarbeitung zum Objekt. Es wird angenommen, daß wie oben in Verbindung mit Fig. 6 beschrieben dann, wenn die Prozeßidentifikation im Feld 163 und die Knotenidentifikation im Feld 164 einen anderen Prozeß oder Knoten identifizieren als der Versender enthält, der Versender die Anfrage zur Verarbeitung zu dem Versender im anderen Prozeß oder Knoten überträgt, der in den entsprechenden Feldern 163 und 164 identifiziert ist.
Oben ist die Verwendung der codierten Einträge der Versendetabelle beschrieben. Die Stellvertreterzeichen- und Ellipsenzeichenzeiger bieten eine zusätzliche Funktion für diese Tabelle. Zum Beispiel kann ein Managementmodul alle Anfragen für Module einer bestimmten globalen oder untergeordneten Objektklasse handhaben. Ohne Stellvertreterzeichen- und Ellipsenzeichenzeiger müßten alle Instanzen der Klassen und Instanzen aller Unterklassen in der Versendetabelle aufgezählt werden. Um dies zu vermeiden, werden Stellvertreterzeichen- und Ellipsenzeichenzeiger vorgesehen, die in einer Versendespezifikation 39A (Fig. 2B) verwendet werden können, um in einer allgemeinen Weise anzugeben, welche Objektklassen und Instanzen ein Managementmodul bedient.
Ein Beispiel einer solchen Versendespezifikation ist:
NODE * ROUTING CIRCUIT ... ,
die angibt, daß das Modul für irgendeine Instanz eines NODE-Klassenglobalobjekts alle Instanzen der Unterobjektklasse CIRCUIT sowie alle Unterobjekte der CIRCUIT-Klassenunterobjekte behandeln kann. Der Asterisk (*) paßt zu einem beliebigen Instanzennamen, während die Ellipse (...) zu irgendwelchen Instanzen des Unterobjekts oder zu Klassen/Instanzen-Paaren der Unterobjekte paßt, die folgen können. Zum Beispiel würde der Ausdruck
NODE foo ROUTING CIRCUIT bar LINK fred
zur Versendespezifikation passen, da "*" zu "foo" paßt und "..." zu "bar LINK fred" paßt.
Um wie in Fig. 9B gezeigt eine Stellvertreterzeichen- Versendespezifikation in die Versendetabelle 28 einzugeben, wird der Objektknoten 130 im Schritt 191 (Fig. 9A) modifiziert, der den Instanzennamen der NODE-Klassenobjekte zugeordnet ist. Der Stellvertreterzeichenzeiger 141 wird verändert, so daß er auf einen neuen Objektknoten (Schritt 196) zeigt, der Klassencodes enthält, von denen einer der Klassencode ROUTING war. Der Ablegerzeiger, der sich auf den Klassencode ROUTING bezieht, wäre gleich Null (wie im Schritt 192, Fig. 9A), während der Null-Zeiger auf einen weiteren neuen Objektknoten 130 zeigt (Schritt 197), der einen Ablegerzeiger besitzt, der dem Klassennamen CIRCUIT entspricht. Dieser Ablegerzeiger würde auf einen weiteren neuen Objektknoten 130 zeigen (Schritt 198), dessen Ellipsenzeichenzeiger auf den Versendeeintrag für das Modul zeigen würde (Schritt 199).
Das Prüfen der modifizierten Tabelle ist bis Schritt 191 dem in Fig. 9A beschriebenen ähnlich. Im Schritt 191 sucht der Versender 16 nach einer Instanz der NODE-Klasse mit einem Namen, z. B. "foo". Wenn dieser Namen in den codierten Einträgen gefunden wird (zu Darstellungszwecken sind drei gezeigt), rückt der Versender entsprechen den Ablegerzeigern in den codierten Einträgen vor. Wenn jedoch der Name "foo" nicht in den codierten Einträgen gefunden wird (durch einen Null-NÄCHSTER-EINTRAG-Zeiger im letzten codierten Eintrag angezeigt), dann sucht der Versender im Schritt 191 nach einem Nicht-Null-Stellvertreterzeichenzeiger. Nach der Lokalisierung des Stellvertreterzeichenzeigers rückt der Versender zum Schritt 196 vor.
Die Schritte 196 und 197 sind den Schritten 192 und 193 der Fig. 9A ähnlich. Der Versender verwendet den Null- Zeiger im Schritt 196 (der dem Klassencode "ROUTING" entspricht), um zum Schritt 197 vorzurücken, und verwendet anschließend den Ablegerzeiger, der dem Klassencode "CIRCUIT" entspricht, um zum Schritt 198 vorzurücken.
Im Schritt 198 durchsucht der Versender die verkettete Liste der codierten Einträge (zu Darstellungszwecken sind drei gezeigt), um einen Instanzennamen "bar" zu lokalisieren. Wenn dieser Name in den codierten Einträgen nicht gefunden wird, sucht der Versender anschließend nach einem Nicht-Null-Stellvertreterzeichenzeiger. Wenn dieser nicht gefunden wird, sucht der Versender nach einem Nicht-Null-Ellipsenzeichenzeiger. Dieser wird lokalisiert und verwendet, um zum Versendeeintrag überzugehen (Schritt 199). Die Inhalte des Versendeeintrags werden anschließend verwendet, um ein geeignetes Modul aufzurufen.
Es ist zu beachten, daß die Stellvertreterzeichen- und Ellipsenzeichenzeiger eine allgemeine Übereinstimmung von Objektklassencodes und Instanzennamen zulassen, jedoch nur nachdem die codierten Einträge der Versendetabelle geprüft worden sind. Auf diese Weise sucht der Versender nach der "besten spezifischen Übereinstimmung" des Objektnamens. Daher kann z. B. ein erstes Modul folgende Versendespezifikation besitzen:
NODE * ROUTING CIRCUIT ... ,
die anzeigt, daß das Modul für alle Instanzen eines NODE- Klassenglobalobjekts alle Instanzen des CIRCUIT-Klassenunterobjekts eines ROUTING-Klassenunterobjekts behandeln kann. Ein zweites Modul kann folgende Versendespezifikation besitzen:
NODE joe ROUTING CIRCUIT ... ,
die anzeigt, daß das Modul für die Instanz "joe" des NODE-Klassenglobalobjekts alle Instanzen des CIRCUIT- Klassenunterobjekts eines ROUTING-Klassenunterobjekts behandeln kann.
Um mit der Regel "beste spezifische Übereinstimmung" konsistent zu sein, sollten alle Direktiven für die NODE- joe-ROUTING-CIRCUIT-Unterobjekte zum zweiten Modul gesendet werden. Dies wird mit dem Versendetabellenschema bewerkstelligt, da der Instanzennamen "joe" in den zweiten Einträgen im Schritt 191 erscheint, weshalb dann, wenn "joe" der Instanzennamen in einer Anfrage an eine ROUTING-CIRCUIT ist, der codierte Eintrag "joe" verwendet wird (da er zuerst geprüft wird) und der Stellvertreterzeichenzeiger nicht verwendet wird.
Um den Versendebaum geeignet zu prüfen, muß vom Versender ferner ein Stapel verwendet werden. Ein einfaches Beispiel erläutert, warum dies erforderlich ist. Es sei ein neues Modul mit der Versendespezifikation
NODE jim DISKDRIVE ...
betrachtet, die anzeigt, daß das Modul für die Instanz "jim" des NODE-Klassenglobalobjekts alle Instanzen der DISKDRIVE-Klassenunterobjekte behandeln kann. Diese Spezifikation wird in den Baum eingegeben, indem im Schritt 191 ein codierter Eintrag mit dem Instanzennamen "jim" hinzugefügt wird und folgende neue Objektknoten in ähnlicher Weise wie in Fig. 9B hinzugefügt werden. Wenn anschließend Anfragen mit Globalobjektklassen- und Instanzennamen versendet werden:
NODE jim ,
geht der Versender zu dem neuen Objektknoten über.
Eine Anfrage jedoch, die einen Objektnamen beginnend mit
NODE jim ROUTING CIRCUIT
beginnt, kann von dem neuen Modul nicht bedient werden, da das neue Modul nur DISKDRIVE-Klassenunterobjekte für die NODE-Instanz "jim" unterstützt. Sobald der Versender feststellt, daß der Klassenname ROUTING-CIRCUIT vom neuen Modul nicht unterstützt wird, muß er daher einen Mechanismus besitzen, um zum Schritt 191 zurückzukehren und möglicherweise andere codierte Einträge oder Stellvertreterzeichen- oder Ellipsenzeichenzeiger verwenden, um ein Modul zu finden, das die Anfrage "NODE jim ROUTING CIRCUIT" bedient. Wenn somit der Versender die Versendetabelle durchläuft, hält er einen Stapel von Zeigern auf alle Objektknoten 130, die er ausgehend vom Wurzelknoten durchlaufen hat. Die Zeiger werden auf diesen Stapel geschoben und von demselben gezogen wenn sich der Versender durch die Versendetabellenbaumstruktur nach oben und nach unten bewegt und versucht den geeigneten Versendeeintrag zu finden.
Wenn kein passender Versendeeintrag gefunden wird, wird dem Anfrager (d. h. dem Darstellungs- oder Funktionsmodul) ein Fehler zurückgegeben.
Wie oben beschrieben worden ist, kann ein Steuerfunktionsmodul als Durchgang von den Darstellungsmodulen direkt zu den Zugriffsmodulen dienen. Um einen solchen Durchgang zu implementieren, sollten die Ellipsenzeichen zeiger für den Wurzelknoten des Darstellungsfunktionsmerkmals der Versendetabelle (der zu irgendeinem Objektnamen in irgendeiner Anfrage paßt) auf den Versendeeintrag für das Steuerfunktionsmodul zeigen. Immer wenn das Steuerfunktionsmodul eine Anfrage empfängt, gibt es einfach eine identische Anfrage an das Funktionszugriffsmerkmal des Versenders aus. Auf diese Weise werden alle Anfragen, die zu keiner Versendespezifikation in der Darstellungsfunktionsversendetabelle passen, ebenfalls zur Prüfung an die Funktionszugriffsversendetabelle weitergeleitet. Dies ermöglicht, daß Darstellungsmodulanfragen auf primitive Funktionen zugreifen, die von den Zugriffsmodulen zur Verfügung gestellt werden.
In einer alternativen Ausführungsform der Versendetabelle kann das Null-Zeigerfeld 143 das erste Element einer verketteten Liste enthalten, die eine ähnliche Struktur besitzt, wie die Liste der codierten Einträge 131, um mehr als einen Klassencode zuzulassen, der keine Instanzen besitzt. Die zweite "Null"-Liste würde Codewerte von Klassencodes enthalten, die keine Instanzen besitzen. Die Null-Liste würde nach der codierten Liste geprüft, jedoch vor der Prüfung auf einen Stellvertreterzeichenzeiger.

G. BEREICHE UND KONFIGURATION

Wie oben beschrieben worden ist, hält ein Konfigurationsfunktionsmodul 11 eine Konfigurationsdatenbank, die die Objekte definiert, die im komplexen System enthalten sind. Mittels geeigneter Kommandos von einem Operator kann das Konfigurationsfunktionsmodul 11 Instanzen von Objekten, die im Datenverzeichnis definiert sind, zur Konfigurationsdatenbank hinzufügen, diese aus der Konfigurationsdatenbank löschen und die Definitionen der Konfigurationsdatenbank ändern. Wie oben ebenfalls beschrieben ist, richtet ein Bereichsfunktionsmodul 11 ein Bereichsobjekt in der Konfigurationsdatenbank ein, daß sich auf eine Teilmenge der bereits in der Konfigurationsdatenbank definierten Objekte bezieht. Ein Operator kann über ein Darstellungsmodul 10 die Objekte, die ein spezifischer Bereich umfaßt, steuern und überwachen, ohne die möglicherweise sehr vielen anderen Objekte, die im komplexen System enthalten sind, zu berücksichtigen. Außerdem kann ein Operator eine Steuer- oder Überwachungsfunktion in Verbindung mit Objekten nur in diesem Bereich einleiten, ohne daß er die Erzeugung einer Anfrage über ein Darstellungsmodul 10 für jedes Objekt einleiten muß, wodurch die Steuerung und Überwachung des komplexen Systems vereinfacht wird.
Das Bereichsfunktionsmodul 11 richtet innerhalb oder zusätzlich zur Konfigurationsdatenbank eine Bereichsdatenbank für jedes Bereichsobjekt ein, die die Objekte identifiziert, die das Bereichsobjekt umfaßt. Nach dem Empfang eine geeigneten Anfrage fügt das Bereichsfunktionsmodul 11 ein Objekt einer Bereichsdatenbank hinzu, wobei das Objekt zum Bereichen zugefügt wird, löscht ein Objekt aus einer Bereichsdatenbank, wodurch das Objekt aus dem Bereich gelöscht wird, erzeugt eine Antwort, die die Objekte identifiziert, die ein Bereich umfaßt, der in der Bereichsdatenbank identifiziert ist, und löscht eine Bereichsdatenbank, wodurch der Bereich effektiv gelöscht wird.
Wie in Fig. 9C gezeigt, enthält das Format der Konfigurations- und Bereichsdatenbanken (die zu einer einzigen Datenbank zusammengefaßt sein können) ein Feld für jede Objektinstanz in der Konfiguration und in ähnlicher Weise für jede Objektinstanz im Bereich.
Die Bereichsdatenbank enthält einen Eintrag 230 für jedes Mitglied eines Bereichs, der den Bereichsnamen und den Instanzennamen des Objekt- oder Unterobjektmitglieds auflistet. Außerdem enthält die Bereichsdatenbank einen Eintrag 232 für jedes Objekt, das ein Mitglied irgendeines Bereichs ist, der den Instanzennamen und die Bereiche auflistet, von denen es ein Mitglied ist. Das Bereichsfunktionsmodul aktualisiert diese Informationen, wenn die Bereiche modifiziert werden, und kann die Informationen verwenden, um schnell die Mitglieder eines Bereichs zu ermitteln oder um alternativ schnell die Bereichsmitgliedschaft eines Objekts zu ermitteln.
In alternativen Ausführungsformen kann ein erster Bereich die Mitglieder eines zweiten Bereichs mit Bezug auf den zweiten Bereich enthalten, wodurch die Größe der Bereichsdatenbank verringert wird. In anderen Ausführungsformen kann die Bereichsdatenbank eine Hierarchie von Bereichen ähnlich der Hierarchie der Objekte und Unterobjekte einrichten, wobei Kommandos in ähnlicher Weise an Bereiche und Unterbereiche gerichtet werden können.
Die Konfigurationsdatenbank enthält einen Eintrag 234 für jedes Objekt und Unterobjekt, die in der Datenbank hierarchisch organisiert sind. Es wird der vollständige Name für jede Objekt- und Unterobjektinstanz geliefert. Diese Informationen können vom Konfigurationsfunktionsmodul verwendet werden, um die Konfiguration schnell zu ermitteln und z. B. (über ein Darstellungsmodul) dem Benutzer eine Karte der Konfiguration oder Menüs der Objektinstanzennamen anzuzeigen.

H. ALARME

Wie oben in Verbindung mit Fig. iB beschrieben worden ist, umfaßt ein Funktionsmodul 11 ein Alarmfunktionsmodul 11, das als Antwort auf Anfragen von einem Darstellungs modul 10 Alarmbedingungen einrichten kann und unter Verwendung der verschiedenen Bedingungen der Objekte des komplexen Systems, die z. B. in der Benutzerschnittstelleninformationsdatei 29 aufgezeichnet sind, das Auftreten einer Alarmbedingung erfaßt.
Die Fig. 10A zeigt die funktionelle Organisation des Alarmfunktionsmoduls 11. Wie in Fig. 10A gezeigt, enthält das Alarmfunktionsmodul 11 ein allgemeines Alarmmodul 200, das Anfragen vom Modul empfängt, diese interpretiert und einem oder mehreren Detektormodulen 201 oder einem oder mehreren Regelaufrechterhaltungsmodulen 202 ermöglicht, als Antwort darauf zu operieren. Wie oben gezeigt, führt das Alarmfunktionsmodul 11 zwei allgemeine Typen von Operationen durch, nämlich das Aufrechterhalten von Alarmbedingungen und das Erfassen von Alarmbedingungen.
Die Aufrechterhaltung der Alarmbedingungsoperation des Alarmfunktionsmoduls 11 wird mittels des Regelaufrechterhaltungsmoduls 202 durchgeführt, das in einer Alarmregelbank 203 Regeln hält, die alle Alarmbedingungen identifizieren. Jede Regel stellt den Satz von Bedingungen dar, der ausgewertet werden muß, um das Vorhandensein einer Alarmbedingung zu ermitteln. Genauer erzeugt das Regelaufrechterhaltungsmodul 202 als Antwort auf Anfragen von einem Darstellungsmodul 10 Regeln, wie im folgenden in Verbindung mit Fig. 10B beschrieben, die in der Alarmregelbank 203 gespeichert werden. Außerdem kann das Regelaufrechterhaltungsmodul 202 als Antwort auf entsprechende Anfragen von einem Darstellungsmodul 10 die Regeln in der Alarmregelbank 202 modifizieren, was somit zu einer Modifikation der Bedingungen führt, unter denen eine Alarmbedingung, die durch die Regel dargestellt wird, besteht.
In ähnlicher Weise wird die Operation der Erfassung von Alarmbedingungen vom Erfassungsmodul 201 durchgeführt, das z. B. die Bedingungsinformationen in der Historiedatendatei (Fig. 5) und die Alarmregeln in der Alarmregelbank 203 verwendet. Wie unten in Verbindung mit Fig. 10B beschrieben, enthält jede Regel einen Bedingungsabschnitt, der die Bedingungen identifiziert. Um eine Alarmbedingung zu erfassen, ermittelt das Erfassungsmodul 201, ob z. B. die Inhalte der Historiedatendatei mit den Bedingungen der verschiedenen Regeln übereinstimmen. Ist dies der Fall, erzeugt das Erfassungsmodul 201 eine Alarmanzeige, die vom allgemeinen Alarmmodul 200 über ein Benachrichtigungsmodul 204 z. B. zur Anzeige für den Operator zum Darstellungsmodul 10 übertragen wird.
Die allgemeine Form einer Alarmregel, die vom Regelaufrechterhaltungsmodul 202 erzeugt wird, ist in Fig. 10B gezeigt. Wie in Fig. 10B gezeigt, enthält eine Alarmregel einen Bedingungsabschnitt 210, der den Satz von Bedingungen darstellt, die für die Anzeige eines Alarms erforderlich sind. Der Bedingungsabschnitt enthält einen Ausdruckabschnitt 212, einen relationalen Operator 213 und einen Ausdruckswertabschnitt 214. Der relationale Operator 213 setzt den Ausdruckabschnitt 212 zum Ausdruckswertabschnitt 214 in Beziehung, so daß der Bedingungsabschnitt 210 bei der Auswertung entweder zu einem logischen WAHR oder zu einem logischen FALSCH kommt. Es wird angenommen, daß dann, wenn der Ausdruckabschnitt 212 selbst mit der Auswertung zum logischen WAHR oder logischen FALSCH kommt, der relationale Operator 213 und der Ausdruckswertabschnitt 214 des Bedingungsabschnitts 210 nicht benötigt werden. In jedem Fall besteht eine Alarmbedingung, wenn der Bedingungsabschnitt bei der Auswertung zu einem logischen WAHR kommt.
Die Regel enthält einen Objekt- und Attributsabschnitt 212 sowie einen Zeitwertabschnitt 216. Der relative Operatorwertabschnitt 213 setzt die Werte eines Attributs zu einem Wertabschnitt 214 in Beziehung. Der Zeitwertabschnitt 216 richtet eine Zeitfunktion ein und kann die Zeitpunkte oder die Zeitintervalle anzeigen, zu denen der Bedingungsabschnitt 210 vom Alarmerfassungsmodul 201 verwendet werden soll.
Das Vorsehen eines Alarmfunktionsmoduls 11 ermöglicht einem Operator, Alarmbedingungen auf einer dynamischen oder bedarfsgerechten Grundlage einzurichten. Da die Alarmbedingungen nicht im voraus in der Steueranordnung eingerichtet sein müssen, kann die Steueranordnung bei der Steuerung und Überwachung einer großen Vielzahl unterschiedlicher komplexer Systeme verwendet werden. Wenn z. B. die Steueranordnung verwendet wird, um verteilte digitale Datenverarbeitungssysteme zu steuern und zu überwachen, die diverse Konfigurationen von Knoten besitzen können, die über ein Netz kommunizieren, können die Alarmbedingungen von einem Operator auf der Grundlage der bestimmten Konfiguration eingerichtet werden. Außerdem können Alarmbedingungen hinzugefügt werden, indem Regeln zur Alarmregelbasis 203 hinzugefügt werden, wenn eine neue Alarmbedingung während einer Operation des komplexen Systems entdeckt wird.

I. ANDERE AUSFÜHRUNGSFORMEN

Die vorangehende Beschreibung war auf eine spezielle Ausführungsform dieser Erfindung beschränkt. Es ist jedoch klar, daß Änderungen und Abwandlungen an der Erfindung vorgenommen werden können, wobei einige oder alle Vorteile der Erfindung erreicht werden.

Claims

1. System zum Steuern und Ausführen von Management- Funktionen für eine Ansammlung von Einheiten (36) eines verteilten digitalen Datenverarbeitungssystems, wobei die Einheiten innerhalb der Ansammlung über Schnittstellen verbunden sind, um primäre Informationshandhabungsfunktionen zu steuern, und die Einheiten ferner mit dem System über Schnittstellen verbunden sind, um die Ausführung der Management-Funktionen zu ermöglichen, gekennzeichnet durch:

gespeicherte Management-Module (10, 11, 12), die so beschaffen sind, daß sie die Management-Funktionen durch unabhängiges Interpretieren und Ausführen ausgewählter managementbezogener Befehle (120) ausführen;

einen Kern (13, 14), der eine Tabelle (28) von Versendezeigern (39a) enthält, um die Befehle (120) an die entsprechenden Module (10, 11, 12) zu leiten, in denen sie interpretiert und ausgeführt werden;

einen Aufnehmer (28, 29) zum Aufnehmen neuer Management-Module in das System durch Hinzufügen weiterer Zeiger zu der Tabelle; und

eine Auflistung (48) von gespeicherten Managementspezifikationsinformationen gemäß einer universellen Spezifikationssprache, die eine gemeinsame Syntax besitzt, um die Attribute und Informationen irgendeines beliebigen, managementfähigen Objekts zu repräsentieren, wobei sich die Attribute auf die Funktionsweise der Objekte beziehen, und um die Management-Funktionen der Objekte zu steuern.

2. System nach Anspruch 1, wobei die Managementspezifikationsinformationen Abrufinformationen in vorgegebenen Feldern der gemeinsamen Syntax umfassen, wobei die Abrufinformationen Felder für die Spezifikation einer voreingestellten Rate und einer maximalen Abrufrate, mit denen die Werte der Attribute von den Einheiten angefordert werden sollen, enthalten.

3. System nach Anspruch 1, wobei die Managementspezifikationsinformationen Informationen für die Unterteilung in vorgegebene Felder der gemeinsamen Syntax enthalten, wobei die Unterteilungsinformationen Gruppen von Attributen mit gemeinsamen Datentypen repräsentieren.

4. System nach Anspruch 1, wobei die Managementspezifikationsinformationen Häufungsinformationen in vorgegebenen Feldern der gemeinsamen Syntax enthalten, wobei die Häufungsinformationen Gruppen von Attributen mit verwandten Funktionen im Management der Einheit repräsentieren.

5. System nach Anspruch 1, wobei die Managementspezifikationsinformationen Befehlsinformationen in vorgegebenen Feldern der gemeinsamen Syntax enthalten, wobei die Befehlsinformationen die Managementfunktionen, die die Einheiten ausführen können, die Struktur der an die Einheiten auszugebenden Befehle sowie die Struktur der zu empfangenden Antworten auflisten.

6. System nach Anspruch 5, wobei die Struktur der auszugebenden Anforderungen Felder für die Auflistung von Argumenten für einen Befehl enthält.

7. System nach Anspruch 5, wobei die Struktur der zu empfangenden Antworten Felder enthält, die für die Angabe des erfolgreichen Abschlusses der angeforderten Operation angefordert werden.

8. System nach Anspruch 51 wobei die Struktur der zu empfangenden Antworten Felder enthält, die für die Angabe von Fehlerzuständen, die einen nicht erfolgreichen Abschluß der angeforderten Operation bewirken, verwendet werden.

9. System nach Anspruch 1, wobei:

jeder der Befehle Felder enthält, die wenigstens ein verwandtes Objekt und eine Operation gemäß einer gemeinsamen Befehlssyntax auflisten; und

die Tabelle des Versendezeigers einen gerichteten Graphen von Datenstrukturen enthält, wobei aufeinanderfolgende Datenstrukturen im Graphen Feldern der Befehle entsprechen.

10. System nach Anspruch 9, wobei:

der Versender einen Parser für die Ausführung einer Parsing-Operation am gerichteten Graphen in Übereinstimmung mit der Einheit und der Operation, die in einem Befehl aufgelistet sind, enthält, um eine Abschlußdatenstruktur mit einem Versendezeiger zu lokalisieren.

11. System nach Anspruch 10, wobei:

der gerichtete Graph Stellvertreterzeichen-Merker und aufeinanderfolgende Datenstrukturen, die irgendeinem Wert in einem besonderen Feld eines Befehls entsprechen können, enthält.

12. System nach Anspruch 10, wobei:

der gerichtete Graph Ellipsen-Merker und aufeinanderfolgende Datenstrukturen, die irgendeiner Anzahl von Werten in Feldern von Befehlen entsprechen können, enthält.

13. System nach Anspruch 11, wobei:

der Parser eine Bestanpassungseinheit für die Bestimmung der exaktesten Anpassung von Feldern eines Befehls enthält, indem sie die exakten Anpassungen für Felder und dann Stellvertreterzeichen-Anpassungen für Felder sucht.

14. System nach Anspruch 12, wobei:

der Parser eine Bestanpassungseinheit enthält, die die exakteste Anpassung von Feldern eines Befehls bestimmt, indem sie zunächst die exakten Anpassungen für Felder und dann die Ellipsen-Anpassungen für Felder sucht.

15. System nach Anspruch 10, wobei:

der gerichtete Graph Stellvertreterzeichen-Merker und aufeinanderfolgende Datenstrukturen, die irgendeinem Wert in einem besonderen Feld eines Befehls entsprechen können, sowie Ellipsen-Merker und aufeinanderfolgende Datenstrukturen, die irgendeiner Anzahl von Werten in Feldern von Befehlen entsprechen können, enthält; und

der Parser eine Bestanpassungseinheit enthält, die die exakteste Anpassung für Felder eines Befehls bestimmt, indem sie die exakten Anpassungen für Felder, dann die Stellvertreterzeichen-Anpassungen für Felder und dann die Ellipsen-Anpassungen für Felder sucht.

16. System nach Anspruch 1, ferner mit:

einer Darstellungsvorrichtung für die Anzeige von Informationen für einen Benutzer und für den Empfang von Befehlen von einem Benutzer, wobei die Befehle und Informationen in spezifischen, vorgegebenen Formaten vorliegen; und

einem Darstellungsmodul für den Empfang von Befehlen von der Darstellungsvorrichtung und zum Weiterleiten von Informationen an die Darstellungsvorrichtung, wobei das Darstellungsmodul einen Umsetzungscode für die Umsetzung von von einer Einheit empfangenen Informationen in ein vorgegebenes Format für die Darstellungsvorrichtung, einen Weiterleitungscode für die Weiterleitung von Befehlen von der Darstellungsvorrichtung an die Versendeeinrichtung sowie Menüerzeugungsroutinen für die Entnahme von Daten aus der Klassen-Datenbank und für die Erzeugung von Menüs gültiger Befehle für die Anzeige für den Benutzer enthält, wobei:

die Menüerzeugungsroutinen so beschaffen sind, daß sie Informationen bestimmen, die sich auf die Konfiguration der Gruppe beziehen, und Menüs verfügbarer Einheiten für die Anzeige für den Benutzer erzeugen.