DE19520740A1 - Infrastruktur für ein System von verteilten Objektmanager-Komponenten - Google Patents

Description

Die Erfindung bezieht sich auf eine Infrastruktur für ein Sy­ stem von verteilten Objektmanager-Komponenten, insbesondere für ein Leitsystem einer Kraftwerksanlage, mit einer Anzahl von rechnergestützten Objektmanager-Komponenten.

In einer Kraftwerksanlage sollen Überwachungseinrichtungen die aktuellen Betriebszustande der Anlage erkennbar machen und Abweichungen von einem Sollzustand melden. Dazu ist eine umfangreiche Meßwerterfassung der Betriebszustände aller An­ lagenteile, eine umfangreiche und der Komplexität der Anlage gerechtwerdende Meßwertbewertung und eine unter hoher Infor­ mationsverdichtung visualisiert aufbereitete Statusanzeige für die Betriebszustände der Anlagenteile erforderlich.

Diese vorstehend genannten Aufgaben soll ein Leitsystem er­ füllen. Bedingt durch die hohe Komplexität solcher techni­ schen Anlagen muß ein solches Leitsystem einfach und geradli­ nig strukturiert sein. Dies bedeutet zum einen, daß Anlagen­ teile mittels des Leitsystems überwachbar und einstellbar sind und zum anderen, daß neue und/oder überarbeitete und ge­ änderte Kontroll-, Einstell- und/oder Auswerteoptionen in einfacher Weise in das bestehende Leitsystem und seine Archi­ tektur integrierbar sind.

In der deutschen Patentanmeldung P 44 16 547.1 ist ein Leit­ system, insbesondere ein rechnergestütztes Leitsystem, vorge­ schlagen, bei dem eine hohe Konfigurierbarkeit einer die Meß­ werte be- und auswertenden Ebene innerhalb des Leitsystems gegeben ist. Dies wird im einzelnen dadurch erreicht, daß die Leitebene modular aufgebaut ist und mehrere Funktionsbaustei­ ne umfaßt, die entsprechend ihrer jeweiligen Funktion Ein­ gangswerte verarbeiten und unter Berücksichtigung einer An­ zahl von zu lösenden technischen Anwendungen untereinander verknüpfbar sind. Aufgrund dieses modularen Aufbaus der Leit­ ebene und ihrer Systeme sind eine nahezu beliebige Struktu­ rierbarkeit und graphische Konfigurierbarkeit des Leitsystems in dieser Ebene gegeben. Es können jederzeit Funktionsbau­ steine modifiziert, ergänzt, weggenommen oder neu verknüpft werden, um eine zu lösende technische Anwendung, wie z. B. die Prozeßführung bestimmter Anlagenteile, die Prozeßinformation, die Kenngrößenberechnung oder die Bilanzierung, durchführen zu können. Die dabei verarbeiteten Eingangswerte können die unmittelbar von der Automatisierungsebene erhaltenen Meßwer­ te, bereits mit einer Zugehörigkeitsfunktion bewertete Meß­ werte, Zwischenresultate anderer Funktionsbausteine und über die Betriebsführungsebene vorgebbare projektierbare Parameter sein.

Bei einem solchen meist rechnergestützten Leitsystem ist es wünschenswert, wenn die Leitebene und die mit der Leitebene verbundenen Ebenen innerhalb einer gemeinsamen Systemumge­ bung, einer sogenannten Infrastruktur, geführt sind. Hierzu ist es bekannt, ein Betriebssystem, vorzugsweise ein handels­ übliches Betriebssystem, wie z. B. UNIX oder OS 2, zu verwen­ den, das die Betriebsführungsebene, die Leitebene und die Au­ tomatisierungsebene sowie einen Datentransfer zwischen diesen Ebenen unterhält. Bei solchen Betriebssystemen ist es darüber hinaus wünschenswert, wenn die freie Verknüpfbarkeit der in der Leitebene angeordneten Funktionsbausteine unterstützt wird, und wenn eine weitgehende Unabhängigkeit des Leitsy­ stems von der Innovationsgeschwindigkeit der Rechner-Hardware erreicht wird.

Derzeit handelsübliche Betriebssysteme, wie z. B. UNIX oder OS 2, sind jedoch überfordert, wenn es im Rahmen einer Infra­ struktur für ein System von verteilten Objektmanager-Kompo­ nenten darum geht, beispielsweise ein aus einer Anzahl von rechnergestützten Objektmanager-Komponenten bestehendes ver­ teiltes System hochzufahren. Eine nicht zufriedenstellende derzeitige Lösung sieht hierzu einen übergeordneten Rechner vor, der zu Beginn des Anlaufs die Informationen über die ge­ samte Konfiguration aller existierenden Objektmanager-Kompo­ nenten kennt. Bedingt durch die Komplexität einer Kraft­ werksanlage kommt es zu Störungen, wenn beispielsweise der übergeordnete Rechner gestört ist, oder wenn die Datenverbin­ dungen zu diesem übergeordneten Rechner gestört sind, oder wenn sich an der Gesamtkonfiguration noch kurzfristig vor dem Anlaufen etwas geändert hat und diese Änderungen noch nicht zu Beginn des Anlaufs berücksichtigt worden sind.

Der Erfindung liegt daher die Aufgabe zugrunde, eine Infra­ struktur für ein System von verteilten Objektmanager-Kompo­ nenten anzugeben, mit der die vorstehend genannten Probleme vermieden werden.

Diese Aufgabe wird erfindungsgemäß dadurch gelöst, daß eine Infrastruktur für ein System von verteilten Objektmanager- Komponenten mit einer Anzahl von rechnergestützten Objektma­ nager-Komponenten, die jeweils mindestens einen Objektmanager ausführen, vorgesehen ist, bei der gemeinsam anlaufende Ob­ jektmanager-Komponenten nach einem allen Komponenten gemein­ samen Algorithmus gegenseitig Kontakt aufnehmen und ihre lo­ kal installierten Objektmanager allen Komponenten zugänglich bekannt geben.

Hierbei wird unter einer Objektmanager-Komponente beispiels­ weise eine Workstation, ein Personal-Computer, ein Automati­ sierungssystem, wie z. B. die Siemens-Siematic S5 und S7, oder eine vergleichbare rechnergestützte Einrichtung verstanden. Unter einem Objektmanager werden insbesondere bei einer Kraftwerksanlage die folgenden Komponenten verstanden. Es sind dies das Man-Machine-Interface, das Archiv, die Proto­ kolliste, die Verarbeitungseinrichtung für die Bausteintech­ nik, eine Datenbank für Beschreibungs-, Symptom- und Diagno­ setexte und ein sogenannter AS-Repräsentant, der das Auto­ matisierungssystem, also die Schnitt stelle zwischen Kraft­ werksprozeß und Datenverarbeitung, stützt.

Auf diese Weise ist es möglich, daß am Beginn des Anlaufs keine ausgezeichnete Komponente vorgesehen ist, die Informa­ tionen über die Gesamtkonfiguration aller existierenden Ob­ jektmanager-Komponenten kennt. Nach der Kontaktaufnahme sind auf jeder Objektmanager-Komponente alle anlaufenden Objektma­ nager-Komponenten und alle dort existierenden Objektmanager bekannt. Auf diese Weise werden auch Änderungen in der Struk­ tur einer Objektmanager-Komponente oder eines darauf instal­ lierten Objektmanagers noch berücksichtigt, selbst wenn diese Änderungen unmittelbar vor dem Anlauf des verteilten Systems projektiert worden sind.

In vorteilhafter Weiterbildung der Erfindung kann es vorgese­ hen sein, daß die lokal installierten Objektmanager nach ei­ ner Prioritätenliste gestartet werden und ihre Verfügbarkeit als Server bekanntgeben. Auf diese Weise kann insbesondere beim Abbruch eines Objektmanagers der neue Zustand zusammen mit detaillierter Adressinformation auf allen Objektmanager- Komponenten aktualisiert werden.

Objektmanager-Komponenten können redundant ausgeführt sein. Bei einer solchen Konstellation ist es zweckmäßig, wenn die Objektmanager einen Anlauf durchführen, bei dem sich der je­ weils prozeßführende Redundanzpartner am gemeinsamen Prozeß aufdatet und sich der oder die nicht prozeßführenden Objekt­ manager beim jeweils führenden Objektmanager aufdaten, insbe­ sondere dann, wenn die Verfügbarkeit des prozeßführenden Ob­ jektmanagers als Server bekanntgegeben ist.

Ein weiterer Vorteil der erfindungsgemäßen Infrastruktur ist es, daß sich ein Ausfall einer Objektmanager-Komponente nicht auf den Anlauf der übrigen Objektmanager-Komponenten aus­ wirkt. Solche angelaufenen Objektmanager-Komponenten bilden ein Teilsystem. Der nachträgliche Anlauf einer ausgefallenen Objektmanager-Komponente erfolgt in vorteilhafter Weise, wenn eine sich in ein etabliertes Teilsystem eingliedernde Objekt­ manager-Komponente bei einer im Teilsystem etablierten Ob­ jektmanager-Komponente vorstellt, ihren lokal installierten Objektmanager mitteilt und die im Teilsystem etablierten Ob­ jektmanager-Komponenten und deren lokal installierten Objekt­ manager von dieser ausgewählte Objektmanager-Komponente mit­ geteilt bekommt.

Bezüglich der Statusinformation über die im System mittels der Infrastruktur geführten Objektmanager-Komponenten und Ob­ jektmanager ist es besonders zweckmäßig, wenn jede Änderung des Status einer Objektmanager-Komponente oder eines Objekt­ managers allen Objektmanager-Komponenten zugänglich ist.

Ausführungsbeispiele der Erfindung werden anhand einer Zeich­ nung näher erläutert. Dabei zeigen:

Fig. 1 in schematischer Darstellung eine Infrastruktur für ein verteiltes System von Objektmanager-Komponen­ ten;

Fig. 2 in schematischer Darstellung einen in die Infra­ struktur eingebetteten Objektmanager;

Fig. 3 in schematischer Darstellung den Überwachungsmecha­ nismus der gemäß Fig. 1 dargestellten Infrastruk­ tur;

Fig. 4 in schematischer Darstellung den Überwachungsmecha­ nismus gemäß Fig. 3 bei dem Ausfall einer Objekt­ manager-Komponente; und

Fig. 5 in schematischer Darstellung den Überwachungsmecha­ nismus in der Infrastruktur gemäß den Fig. 3 und 4 in zwei Überwachungsebenen.

In den Fig. 1 bis 5 haben gleiche Teile die gleichen Be­ zugszeichen.

In der in Fig. 1 gezeigten schematischen Darstellung erkennt man die Infrastruktur 2 für ein verteiltes System 18 von Ob­ jektmanager-Komponenten 4 bis 16 als schraffiert unterlegte Fläche. Das System 18 ist als Leitsystem für eine Kraftwerks­ anlage vorgesehen. Die Objektmanager-Komponenten 4 bis 16 können Datenverarbeitungsanlagen beliebiger Art, wie z. B. Großrechner, Workstations, Personal-Computer und Host-Rechner jeglicher Art, sein. Auf den einzelnen Objektmanager-Kompo­ nenten 4 bis 16, von denen die Komponenten 10a und 10b sowie 12a und 12b redundant ausgeführt sind, werden Objektmanager ausgeführt.

Unter Objekten werden Daten jeglicher Art, wie z. B. binäre Signale, hexadezimale Signale, wie z. B. Real-Werte, Integer- Werte, Boolean-Werte oder String-Ketten, verstanden. Objekt­ manager sind also solche hardwaremäßig oder auch softwaremä­ ßig realisierte Einheiten, die Objekte beliebiger Art verwal­ ten. Objektmanager sind beispielsweise das Man-Machine-Inter­ face (MMI) 20, das Archiv 22 zur Aufzeichnung der Geschichte des Kraftwerks (redundant ausgeführt als 22a und 22b), der Protokollverwalter 24 (ebenfalls redundant ausgeführt als 24a und 24b), der Verwalter 26 für die Datenverarbeitung der in Bausteintechnik vorgesehenen und hier nicht weiter darge­ stellten Leitebene, die Datenbank 28 für Beschreibungsdaten und der Repräsentant 30 des Automatisierungssystems. Wie beispielsweise anhand des Repräsentanten 30 des Automatisie­ rungssystems gezeigt, kann ein Objektmanager auch auf mehre­ ren Objektmanager-Komponenten, hier die Komponenten 4 bis 8 und 16, gleichzeitig ausgeführt werden.

Beim Anlauf des Systems 18 werden von einer dezentral ange­ ordneten Initialisierungsdatei 32 die Anlaufdaten in die In­ frastruktur 2 eingegeben. Jeder der Objektmanager-Komponenten 4 bis 16 hat einen Teil seiner zur Verfügung stehenden Re­ chenleistung reserviert, um die Infrastruktur 2 in hardware­ mäßig verschalteter Form oder auch in softwaremäßig instal­ lierter Form zu betreiben. Die Anlaufdaten der Initialisie­ rungsdatei 32 enthalten einen dezentralen Algorithmus, nach dem in einer ersten Phase des Anlaufs die Objektmanager-Kom­ ponenten 4 bis 16 untereinander Kontakt aufnehmen und der In­ frastruktur 2 und damit allen an der Infrastruktur 2 betei­ ligten Komponenten 4 bis 16 ihre lokal installierten Objekt­ manager 20 bis 30 bekannt. Nach dieser Kontaktaufnahme sind auf jeder Objektmanager-Komponente 4 bis 16 alle anlaufenden Objektmanager-Komponenten und alle dort existierenden Objekt­ manager bekannt.

In einer zweiten Phase werden mittels der Infrastruktur 2 auf den Objektmanager-Komponenten 4 bis 16 die lokal instal­ lierten Objektmanager 20 bis 30 gestartet. Die Infrastruktur 2 wartet ferner darauf, daß die Objektmanager 20 bis 30 ihre Verfügbarkeit als Server bekannt geben, und aktualisiert - auch wenn der Überwachungsmechanismus einen Abbruch eines Ob­ jektmanagers erkannt hat - den neuen Zustand zusammen mit ei­ ner detaillierten Adressinformation aufallen Objektmanager- Komponenten 4 bis 16. In einer dritten Phase werden die Ob­ jektmanager 20 und 26 auf den redundant vorliegenden Objekt­ manager-Komponenten 10a, 10b bzw. 12a, 12b gestartet. Dabei datet sich der jeweils führende Redundanzpartner am allen Objektmanager-Komponenten 4 bis 16 gemeinsamen Anlaufprozeß auf und der oder die nicht führenden Objektmanager daten sich beim jeweils führenden Objektmanager auf.

Die Infrastruktur 2 unterstützt auch eine weitere Anlaufsi­ tuation, bei der sich eine abgebrochene Objektmanager-Kompo­ nente, beispielsweise die Komponente 6, in ein etabliertes Teilsystem, bestehend aus den Komponenten 4, 8 bis 16, wieder eingliedert. Die sich eingliedernde Objektmanager-Komponente 6 stellt sich zunächst bei einer schon im Teilsystem etablierten Objektmanager-Komponente, beispielsweise der Kom­ ponente 8, vor, indem die Objektmanager-Komponente 6 ihre lo­ kal installierten Objektmanager, hier der Repräsentant 30 des Automatisierungssystems, mitteilt. Die lokale Infrastruktur der Objektmanager-Komponente 8, dargestellt durch die schraf­ fierte Fläche innerhalb des Symbols für die Objektmanager- Komponente 8, macht die sich eingliedernde Objektmanager-Kom­ ponente 6 im etablierten Teilsystem bekannt. Die sich ein­ gliedernde Objektmanager-Komponente 6 erhält von der Kompo­ nente 8, bei der sie sich vorgestellt hat, die Informationen über die Zustände und Adressen der Objektmanager-Komponente 4, 8 bis 16 des etablierten Teilsystems und der darauf in­ stallierten Objektmanager. Auf diese Weise wird die Objektma­ nager-Komponente 6 in das etablierte Teilsystem eingegliedert ohne daß eine übergeordnete Instanz, beispielsweise ein Leit­ rechner, vorgesehen ist, der die Konfiguration, Zustände und Adressen der übrigen Objektmanager-Komponenten kennt. Diese Informationen sind vielmehr auf jeder Objektmanager-Kompo­ nente 4 bis 16 im lokalen Teil der Infrastruktur 2 enthalten, so daß auch jede Änderung des Status einer Objektmanager-Kom­ ponente oder eines Objektmanagers allen Objektmanager-Kompo­ nenten unmittelbar zugänglich ist. Dies wirkt sich besonders vorteilhaft auf die Serverfunktionen der Objektmanager und auf die Kenntnis deren Verfügbarkeit im gesamten System 18 aus. In beiden Anlaufsituationen startet die Infrastruktur 2 die lokal installierten Objektmanager, in dem sie deren Ina­ tialisierungsprozesse erzeugt. Objektmanager, die dem System 18 keine Serverleistung zur Verfügung stellen, sind mit die­ sem Schritt sofort verfügbar.

Der Abbruch eines Objektmanagers 20 bis 30 während des An­ laufs wirkt sich abhängig vom Vorhandensein einer Redundanz auf den Zustand der entsprechenden Objektmanager-Komponente 4 bis 16 aus: Bei vorhandener Redundanz werden die schon akti­ ven Objektmanager beendet und die Objektmanager-Komponente wird als "abgebrochen" für alle übrigen Objektmanager-Kompo­ nenten zugänglich markiert. Ohne vorhandene Redundanz wird der Anlauf der Objektmanager-Komponente fortgesetzt. Nur der vom Abbruch betroffene Objektmanager wird als "abgebrochen" markiert.

In Fig. 2 ist in schematischer Darstellung gezeigt, in wel­ cher Weise ein Objektmanager, hier beispielsweise der Objekt­ manager 30, aufgebaut und in die Infrastruktur 2 eingebunden ist. Im vorliegenden Fall weist der Objektmanager 30 zwei Client-Schnittstellen 32, 34, einen Init-Server 36, einen Server-Hauptteil 38, einen Server-Übertragungsteil 40 und ei­ nen Server 42 für Projektierungsdienste auf.

Über die Client-Schnittstellen 32, 34, die auch als Schnitt­ stelle Client-Infrastruktur 2 bezeichnet werden kann, werden Aufträge über die Infrastruktur 2 an Server ausgegeben, und es können Antworten vom Server über die Infrastruktur 2 in der Schnittstelle empfangen werden. Hierbei kann die Schnitt­ stelle als Mehrfachwartestelle ausgeführt sein, so daß es möglich ist, auf die Ergebnisse verschiedener Aufträge unab­ hängig voneinander warten zu können, was sich besonders vor­ teilhaft auf die Synchronisation von Datenaustauschvorgängen auswirkt.

Der Init-Server 36 wird beim Anlauf des Objektmanagers 30 aufgerufen. Dieser Init-Server 36 startet und überwacht alle weiteren Prozesse, die auf dem Objektmanager 30 ausgeführt werden. Der Init-Server 36 teilt allen übrigen Prozessen dar­ über hinaus wichtige Konfigurations- und Adressinformationen mit. Falls der Objektmanager 30 beendet werden soll, wird dies dem Init-Server 36 von der Infrastruktur 2 über ein ent­ sprechendes Signal, beispielsweise ein UNIX-Signal, mitge­ teilt. Das Beenden des Objektmanagers 30 wird der Infrastruk­ tur 2 durch das Beenden des Init-Servers 36 mitgeteilt.

Der Server-Hauptteil 38 stellt dem Server für alle "Nutzfunktionen" des Objektmanagers 30 dar. Im Server-Haupt­ teil 38 ruft das Hauptprogramm nach der eigenen Initialisie­ rung durch den Init-Server 36 eine Überwachungsfunktion auf.

Diese Überwachungsfunktion wartet über die gesamte Lebens­ dauer des Server-Hauptteils 38 auf Client-Aufträge und ruft entsprechend dieser Aufträge Server-Funktionen auf, d. h. der Server-Hauptteil 38 wartet in einer Wartestelle in der Infra­ struktur 2 auf entsprechende Client-Aufträge. Diese Funktion ist daher eine Art vorgeschobener Horchposten aus dem Objekt­ manager 30 heraus in die Infrastruktur 2. Erst wenn der Ser­ ver-Hauptteil 38 beendet wird, verläßt diese Funktion die In­ frastruktur 2 und kehrt in das Hauptprogramm zurück.

Der Server-Übertragungsteil 40 stellt einen in den Prozeß des Objektmanagers 30 eingebundenen Funktionssatz dar, über den Server antworten (z. B. für kontinuierliche Aufträge) abge­ geben werden. Der Server-Übertragungsteil 40 überträgt, falls sich ein Client über den Server-Hauptteil 38 angemeldet hat, die gewünschten Ereignisse oder sonstige Ereignisse von kon­ tinuierlichen Aufträgen.

Der Server 42 für Projektierungsdienste wartet nach seiner Aktivierung auf Projektierungsaufträge und legt die Projek­ tierungsinformation in eine Objektmanager spezifische Daten­ basis ab oder gibt sie an die innerhalb des Objektmanagers 30 betroffenen Prozesse weiter.

Die Infrastruktur 2 überwacht und steuert die gesamte Kommu­ nikation in einer Weise, daß jedes Objekt ein internes Kenn­ zeichen und einen Ausprägungstyp umfaßt, anhand deren der Ob­ jektmanager, beispielsweise Objektmanager 30, ermittelbar ist, der dieses Objekt verwaltet. Hierbei wird unter einem Objekt jede Information verstanden, die in einer Datenverar­ beitungsanlage zur Kommunikation von Prozessen ausgetauscht oder übertragen wird. Mit dem Ausprägungstyp eines Objektes ist beispielsweise zunächst gemeint, ob dieses Objekt der verfahrenstechnischen Welt, der leittechnischen Welt oder der anlagentechnischen Welt zuzuordnen ist. Weiter beinhaltet der Ausprägungstyp eine Klassifizierung des Objekts nach seiner Aufgabenumgebung, beispielsweise kann ein Objekt Alarm- oder Toleranzmeldungen, Hardware-Gerätefehlern, Busfehlern oder Funktionsfehlern zugeordnet sein. Das interne Kennzeichen ist nicht gleichbedeutend mit dem Begriff "Adresse", weil das in­ terne Kennzeichen keinerlei Ortsinformation über die Lage des Objektes besitzt. Darüber hinaus kann dem internen Kennzei­ chen nicht eindeutig eine Adresse zugeordnet werden, denn verschiedene Daten eines Objekts können von verschiedenen Ob­ jektmanagern 20 bis 30 verwaltet werden, die unter Umständen auf verschiedenen Objektmanager-Komponenten 4 bis 16 angesie­ delt sind. Auf diese Weise ist mit besonders vorteilhafter Wirkung eine Adressierung von Objekten anhand ihrer Eigen­ schaften, d. h. eine assoziative Adressierung, möglich. Hier­ durch vereinfacht sich die Projektierung, weil ganze Objekt- Klassen ausgewählt werden können, ohne daß deren Lage im ein­ zelnen einem Objektmanager oder einer Objektmanager-Kompo­ nente bekannt sein müssen. So kann beispielsweise von dem Ob­ jektmanager 4, dem Man-Machine-Interface, das Kommando abge­ setzt werden "Suche Leittechnikfehler". Auf diese Weise sind in dem gesamten System 18 nur solche Objekte angesprochen, die gemäß ihres internen Kennzeichens und des Ausprägungstyps in die Signalklasse "Leittechnikfehler" hineinfallen.

Die Kommunikation im System 18 kann zum einen eine von einem Server-gesteuerte diskontinuierliche Kommunikation und zum anderen eine von einem Client-gesteuerte, kontinuierliche Kommunikation sein. Bei der Server-gesteuerten Kommunikation muß der Client den Umfang der Ergebnisse nicht kennen, Teil­ ergebnisse können übertragen werden, wenn sie anfallen. Durch die Client-gesteuerte Kommunikation wird das gesamte Kommuni­ kationsaufkommen im System 18 verringert, weil keine Auf­ tragswiederholungen notwendig sind. Die Infrastruktur 2 ist hierbei derart konzipiert, daß bei dem Vorliegen eines Kommu­ nikationsauftrages eines Clienten alle an diesem Auftrag be­ teiligten Server unmittelbar und nur einmalig zur Datenaus­ gabe aufgefordert sind. Gleichzeitig kann mit einer solchen Aufforderung eine Synchronisationsaufforderung an alle betei­ ligten Server ergehen. Weiter kann in besonders zweckmäßiger Weise die Meldung des Vollzugs der Synchronisation an den Client erst dann ergehen, wenn die Bereitschaft zur Datenaus­ gabe aller verfügbaren Server vorliegt, so daß auch hier das Kommunikationsaufkommen besonders gering ist, weil keine Nachfragen des Clients nach bestimmten Ergebnissen an einzel­ ne Server ergehen.

Eine weitere vorteilhafte Ausgestaltung der Infrastruktur 2 sieht es vor, daß eine Wiederanmeldung eines noch anstehenden Auftrages eines Clienten bei einem wiederverfügbar gewordenen Server vorgesehen ist. Die Infrastruktur 2 stellt also Res­ sourcen bereit, die alle im System 18 eingegangenen Aufträge erfaßt und speichert, falls ein Server zur Auftragserledigung nicht verfügbar ist. Da die Infrastruktur gleichzeitig jede Zustandsänderung eines Servers bezüglich seiner Verfügbarkeit erfaßt, wird eine Auftragserledigung unmittelbar nach Wieder­ verfügbarkeit eines Servers "angemahnt".

Die Infrastruktur 2 ist weiter in der Lage einen Kommunikati­ onsauftrag bezüglich der Parameterversorgung zu prüfen und den Auftrag bei fehlerhafter Parameterversorgung unter Angabe eines Fehlercodes abzulehnen. Auf diese Weise können bei­ spielsweise Fehler vermieden werden, wenn bei der Suche nach einem Leittechnikfehler in der verfahrenstechnischen oder an­ lagentechnischen Welt gesucht wird. Ein solcher Fehler ist nur in der leittechnischen Welt zu finden, d. h. also bei den Datenquellen und Senken, die vom Ausprägungstyp her mit der Fehlerklasse übereinstimmen.

Hierbei kann das dynamische Verhalten der Erledigung eines Kommunikationsauftrages nachvollziehbar und verifizierbar sein. Eine solche Funktion kann beispielsweise über den Pro­ tokollverwalter 24 an die dem Man-Machine-Interface zugeord­ neten Drucker ausgegeben werden. Dies ist in der Projektie­ rungsphase besonders bedeutsam, wenn man nachvollziehen will, welche Daten woher geladen wurden, und in welcher Weise dar­ aus Ergebnisse berechnet wurden, und wohin die Ergebnisse ge­ sendet wurden.

In Fig. 3 ist der Überwachungsmechanismus der Objektmanager- Komponenten 4 bis 16 in dem System 18 dargestellt. Der Mecha­ nismus wird anhand der Objektmanager-Komponenten 4 bis 8 er­ läutert. Die Objektmanager-Komponente 6 arbeitet bei der Überwachung als Client für die Objektmanager-Komponente 8 und als Server für die Objektmanager-Komponente 4. Die Objektma­ nager-Komponenten 4 bis 16 sind zur Überwachung ihres Zustan­ des in einem logischen Ring angeordnet, so daß keine überge­ ordnete Überwachungskomponente erforderlich ist. Die Überwa­ chung erfolgt nach dem Client-Server Prinzip. Die als Client arbeitende Objektmanager-Komponente 6 sendet in definierten Zeitabständen ein Signal (Objekt) an die entsprechend als Server ausgebildete Objektmanager-Komponente 8. Diese Kompo­ nente 8 sendet daraufhin ein "Lebenszeichen" an die Kompo­ nente 6. In gleicher Weise erhält die Komponente 6 von der Komponente 4 in definierten Zeitabständen eine Aufforderung, ein "Lebenszeichen" zu senden. Zur Serversuche läuft aufal­ len Objektmanager-Komponenten 4 bis 16 der gleiche Algorith­ mus ab, beispielsweise können die Objektmanager-Komponenten 4 bis 16 ihren Überwacher und den zu Überwachenden anhand der alphabetischen Reihenfolge ihrer Benennung ermitteln.

In Fig. 4 ist eine gegenüber Fig. 3 geringfügig modifi­ zierte Konfiguration des Systems 18 dargestellt. Hier sind die Objektmanager-Komponenten 6 und 10a ausgefallen. Der Ser­ ver der ausgefallenen Objektmanager-Komponente 6 kennt die Konfiguration dieser Komponente und teilt über die Infra­ struktur 2 den verbleibenden Objektmanager-Komponenten alle mit der Objektmanager-Komponente ausgefallenen Objektmanager mit. Dies ist im vorliegenden Fall der auf der Objektmanager- Komponente 6 durchgeführte Objektmanager 30. Gemäß der vorge­ gebenen Algorithmus hat die Objektmanager-Komponente 4 nun nicht die Objektmanager-Komponente 6 als Server, sondern die Objektmanager-Komponente 8, so daß die im verbleibenden Sy­ stem aktiven Objektmanager-Komponenten 4, 8 bis 16 wieder ei­ nen logischen Überwachungsring bilden. Will sich die Objekt­ manager-Komponente 6 wieder in das System eingliedern, meldet sie sich bei der Objektmanager-Komponente 8 an, gibt ihre lo­ kal installierten Objektmanager, hier der Objektmanager 30, bekannt und erfährt von der Objektmanager-Komponente 8 die Konfiguration und Zustände aller übrigen Objektmanager-Kompo­ nenten. Dies ist durch die gestrichelten Pfeile 44 symboli­ siert.

Ein weiterer Spezielfall ist für die Objektmanager-Komponen­ ten 10a und 10b dargestellt. Diese Komponente ist redundant ausgeführt. Im gezeigten Fall ist die Komponente 10a ausge­ fallen. Der Server dieser Komponente 10a kennt die Konfigura­ tion dieser Komponente und die auf dieser Komponente lokal installierten Objektmanager, hier das Man-Machine-Interface 20, und teilt den übrigen Objektmanager-Komponenten, die mit der Objektmanager-Komponente ausgefallenen Objektmanager mit. Hierbei ist es die Infrastruktur 2, die ein für alle Objekt­ manager-Komponenten zugängliches Ereignis generiert, das ins­ besondere den verbleibenden Komponenten mitteilt, ob eine Ob­ jektmanager-Komponente "prozeßführend" oder "nicht-prozeßfüh­ rend" ist bei redundanter Ausführung der jeweiligen Kompo­ nente.

Nach dem Ausfall der Komponente 10a erfolgt der Zustandsüber­ gang der Objektmanager-Komponente von "nicht-prozeßführend" nach "prozeßführend" der Komponente 10b selbsttätig. Hierbei kann es weiter vorgesehen sein, daß zum Aufdaten von Objekt­ managern auf wiederanlaufenden redundanten Objektmanager-Kom­ ponenten der prozeßführende Server auf Auftrag ein konsisten­ des Abbild seiner Prozeßdaten erstellt und zum aufrufenden Client, hier der Server der ausgefallenen Objektmanager-Kom­ ponente 10a, überträgt. Um den Redundanz-Zustand einer Ob­ jektmanager-Komponente für die übrigen Komponenten zugänglich zu machen, ist es vorgesehen, daß jede Objektmanager-Kompo­ nente 4 bis 16 oder jeder Objektmanager in dem entsprechenden Server-Hauptteil 38 eine Schnittstelle aufweist, die eine Än­ derung des Redundanz-Zustandes der jeweils anderen Objektma­ nager-Komponenten oder Objektmanager erfaßt.

Insbesondere für die Handhabung einer sicheren Datenübertra­ gung von redundant ausgeführten Objektmanager-Komponenten ist die Infrastruktur 2 derart ausgestaltet, daß die Übermittlung eines datenlesenden Auftrages selbsttätig an den prozeßfüh­ renden Server erfolgt. Hierzu dient beispielsweise der Ein­ trag in der vorstehend genannten Schnittstelle bezüglich des Zustands einer Objektmanager-Komponente oder eines Objektma­ nagers. Gleichzeitig sorgt die Infrastruktur 2 dafür, daß die Übermittlung eines datenschreibenden Auftrages an alle zuein­ ander redundanten Objektmanager-Komponenten oder Objektmana­ ger erfolgt, so daß der nicht prozeßführende Teil jederzeit in der Lage ist, die Prozeßführung zu übernehmen.

Auch der logische Ring zur Überwachung der Objektmanager-Kom­ ponenten 4 bis 16 schließt sich bei dem Ausfall der Objektma­ nager-Komponente 10a selbsttätig, weil die Objektmanager-Kom­ ponenten 4 und 12a, 12b automatisch auf die redundante Ob­ jektmanager-Komponente 10b umschalten, die ihren Zustand von "nicht-prozeßführend" nach "prozeßführend" geändert hat, wie dies die Pfeile 46, 48 symbolisieren.

In Fig. 5 ist nochmals der logische Ring zur Überwachung der Objektmanager-Komponenten 4 bis 16 schematisch dargestellt. Hierbei soll deutlich gemacht werden, daß die Überwachung in zwei Überwachungsebenen erfolgt. In der ersten Überwachungs­ ebene überwachen sich die Objektmanager-Komponenten 4 bis 16 selbsttätig im gemäß Fig. 3 beschriebenen Ring. Dies ist in Fig. 5 durch die Pfeilverbindungen von Objektmanager-Kompo­ nente zu Objektmanager-Komponente symbolisiert.

An der hier ausgewählten Objektmanager-Komponente 14 ist die zweite Überwachungsebene schematisch dargestellt. Innerhalb einer Objektmanager-Komponente werden zyklisch wiederkehrend die Zustände der einzelnen lokal installierten Objektmanager, hier der redundant ausgeführte Protokollverwalter 24a, 24b und die Datenbank 28 für Beschreibungsdaten, überwacht. Auf diese Weise ist eine Entkopplung der Überwachungsprozesse für Objektmanager-Komponenten und Objektmanager erreicht, so daß beispielsweise nach dem Ausfall eines einzelnen Objektmana­ gers nicht die gesamte Objektmanager-Komponente als ausgefal­ len gemeldet werden muß.

Claims (6)

1. Infrastruktur (2) für ein System (18) von verteilten Ob­ jektmanager-Komponenten (4 bis 16), insbesondere für ein Leitsystem einer Kraftwerksanlage, mit einer Anzahl von rechnergestützten Objektmanager-Komponenten (4 bis 16), die jeweils mindestens einen Objektmanager (20 bis 30) ausführen, wobei gemeinsam anlaufende Objektmanager-Komponenten (4 bis 16) nach einem dezentralen Algorithmus gegenseitig Kontakt aufnehmen und ihre lokal installierten Objektmanager (20 bis 30) allen Komponenten bekanntgeben.

2. Infrastruktur (2) nach Anspruch 1, dadurch gekennzeichnet, daß die lokal installierten Objektmanager (20 bis 30) nach einer Prioritä­ tenliste gestartet werden und ihre Verfügbarkeit als Server bekannt geben.

3. Infrastruktur (2) nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß bei Vor­ liegen von redundant ausgeführten Objektmanager-Komponenten (4 bis 16) Objektmanager (20 bis 30) einen Anlauf durchfüh­ ren, wobei sich der jeweils führende Redundanzpartner am al­ len Objektmanager-Komponenten (4 bis 16) gemeinsamen Prozeß aufdatet und sich der oder die nicht führenden Objektmanager (20 bis 30) beim jeweils führenden Objektmanager aufdaten.

4. Infrastruktur (2) nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß eine sich in ein etabliertes Teilsystem eingliedernde Objektmanager- Komponente (6) bei einer im Teilsystem etablierten Objektma­ nager-Komponente (8) vorstellt, ihre lokal installierten Ob­ jektmanager (30) mitteilt und die im Teilsystem etablierten Objektmanager-Komponenten (4, 8 bis 16) und deren lokal in­ stallierten Objektmanager (20 bis 28) mitgeteilt bekommt.

5. Infrastruktur (2) nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß jede Än­ derung des Status einer Objektmanager-Komponente (4 bis 16) oder eines Objektmanagers (20 bis 30) allen Objektmanager- Komponenten (4 bis 16) zugänglich ist.

6. Infrastruktur (2) nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß die An­ laufdaten in mindestens einer Datei (32) gespeichert ist, die dezentral zu den gemeinsam anlaufenden Objektmanager-Kompo­ nenten (4 bis 16) angeordnet ist.