DE19520744C2 - 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 Betriebszustände 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 gerecht werdende 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 gerad­ linig strukturiert sein. Dies bedeutet zum einen, daß An­ lagenteile mittels des Leitsystems überwachbar und einstell­ bar 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.

Aus net 40 (1986), Heft 9, Seiten 338-342, insbesondere Bild 2, ist ein "Ringnetz mit Token Access" bekannt. Bild 3 zeigt die Möglichkeit, einen zusätzlichen gegenläufigen Ring zu integrieren.

Aus Elektronik 7/31.3.1989, Seiten 52-58, insbesondere Bilder 4 und 5, sind lokale Netze mit "Ringstruktur" und "Dop­ pelringstruktur" bekannt. Als Zugriffsverfahren für lokale Netze sind insbesondere von Seite 53, dritter Absatz, das "Token-Ring-" und das "Token-Bus-Verfahren" bekannt.

Aus Europhysics Conference on Control Systems for Experimen­ tal Physics, Proceedings (CERN 90-08), Villars-sur-Ollon, Switzerland, 28. Sept. - 2. Oct. 1987, Seiten 15-20, published: CERN, Geneva, Switzerland 1990, vergleiche ins­ besondere Fig. 2, ist ein Steuer- und Regelungssystem mit einem "N-zu-N Token Ringnetz" bekannt.

Aus EP 0 604 091 A2, insbesondere Fig. 10, ist ein "Ring­ netz" bekannt. Außerdem ist insbesondere aus Fig. 9 ein "Server" bekannt.

Aus Elektronik 25/1994, Seiten 58-64, vergleiche insbeson­ dere Seite 59, rechte Spalte, ist das "Client-Server-Konzept" bekannt.

In der älteren Anmeldung WO 95/30937 ist ein Leitsystem, ins­ besondere ein rechnergestütztes Leitsystem, vorgeschlagen, 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 Funktionsbausteine umfaßt, die entsprechend ihrer jeweiligen Funktion Eingangswerte ver­ arbeiten 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.

Weitere Probleme treten auf, wenn einzelne Objektmanager-Kom­ ponenten redundant ausgeführt sind. Die Probleme werden durch die Tatsache verursacht, daß der übergeordnete Rechner zu je­ der Zeit Kenntnis davon haben muß, welche Objektmanager-Kom­ ponente prozeßführend und welche Objektmanager-Komponente nicht-prozeßführend ist.

Der Erfindung liegt daher die Aufgabe zugrunde eine Infra­ struktur für ein System von verteilten Objektmanager-Kompo­ nenten anzugeben, mit der jederzeit sichergestellt ist, daß eine störungsfrei vorliegende Information über den Zustand von redundant ausgeführten Objektmanager-Komponenten vor­ liegt.

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, wobei für redundant ausgeführte Objektmanager-Komponenten oder Objektmanager der Zustand "prozeßführend" und entsprechend "nicht-prozeßführend" über­ wachbar und für alle übrigen Objektmanager-Komponenten zu­ gänglich ist.

Hierbei wird unter einer Objektmanager-Komponente beispiels­ weise eine Workstation, ein Personal-Computer, Automatisie­ rungssysteme, wie z. B. die Siemens-Siematic S5 und S7, oder vergleichbare rechnergestützte Einrichtungen verstanden. Un­ ter einem Objektmanager werden insbesondere bei einer Kraft­ werksanlage die folgenden Komponenten verstanden. Es sind dies das Man-Machine-Interface, das Archiv, die Protokolli­ ste, die Verarbeitungseinrichtung für die Bausteintechnik, eine Datenbank für Beschreibungs-, Symptom- und Diagnosetexte und ein sogenannter AS-Repräsentant, der das Automatisie­ rungssystem, also die Schnittstelle zwischen Kraftwerksprozeß und Datenverarbeitung, stützt.

Auf diese Weise ist es möglich, daß jede Objektmanager-Kompo­ nente in Folge der entsprechenden Ausgestaltung der Infra­ struktur Kenntnis über den aktuellen Redundanz-Zustand der am System beteiligten Objektmanager-Komponenten und Objektmana­ ger hat. Fehler, die durch eine übergeordnete Überwachungsin­ stanz auftreten können, sind auf diese Weise eliminiert.

In vorteilhafter Weise kann ein Zustandübergang einer Objekt­ manager-Komponente oder eines Objektmanagers bei Vorliegen eines Ausfallereignisses selbsttätig erfolgen. Dies bedeutet insbesondere, daß die Infrastruktur eine für alle Objektmana­ ger-Komponenten zugängliche Meldung in auf ebensolche Meldun­ gen wartende Schnittstellen der Objektmanager-Komponenten schreibt.

In weiter zweckmäßiger Weise ist die Infrastruktur derart er­ tüchtigt, daß die Übermittlung eines datenlesenden Auftrages an den prozeßführenden Server erfolgt, und/oder das die Über­ mittlung eines datenschreibenden Auftrages an alle zueinander redundanten Objektmanager-Komponenten oder Objektmanager erfolgt. Auf diese Weise ist es gewährleistet, daß ein daten­ lesender Client unverzüglich bedient wird bzw. daß eine red­ undant ausgeführte, aber derzeit nicht-prozeßführende Objekt­ manager-Komponente oder Objektmanager jederzeit in der Lage ist, an die prozeßführende Stelle zu treten.

Eine weitere vorteilhafte Ausgestaltung der Erfindung sieht es vor, daß zum Aufdaten von Objektmanagern auf wiederanlau­ fenden redundanten Objektmanager-Komponenten der führende Server auf Auftrag ein konsistentes Abbild seiner Prozeßdaten erstellt und zum aufrufenden Client überträgt. Auf diese Weise enthält der auf der wiederanlaufenden redundanten Ob­ jektmanager-Komponente installierte Objektmanager nach defi­ nierter Aufforderung zu einem definierten Zeitpunkt alle für den Betrieb des Objektmanagers erforderliche Daten. Es ent­ stehen also keine Datenlücken oder Fehler durch die Übermitt­ lung nicht aktueller Prozeßdaten.

In besonders einfacher Weise läßt sich die Erfindung ausge­ stalten, wenn eine Objektmanager-Komponente oder ein Objekt­ manager in dem jeweiligen Server-Hauptteil eine Schnittstelle aufweist, die eine Änderung des Redundanz-Zustandes der ent­ sprechenden Komponente oder des entsprechenden Objektmanagers erfaßt.

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 bei­ spielsweise 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 auf allen 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 etab­ lierten Objektmanager-Komponente, beispielsweise der Kompo­ nente 8, vor, indem die Objektmanager-Komponente 6 ihre lokal 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 auf al­ 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 von verteilten Objektma­ nager-Komponenten (4 bis 16), insbesondere für ein Leitsystem einer Kraftwerksanlage, mit einer Anzahl von rechnergestütz­ ten Objektmanager-Komponenten, die jeweils mindestens einen Objektmanager ausführen, wobei für redundant ausgeführte Ob­ jektmanager-Komponenten (10a, 10b, 12a, 12b) oder Objektmana­ ger (22a, 22b, 24a, 24b) der Zustand "prozeßführend" und ent­ sprechend "nicht-prozeßführend" überwacht und für alle übri­ gen Objektmanager-Komponenten (4, 6, 8, 14, 16) zugänglich ist.

2. Infrastruktur (2) nach Anspruch 1, dadurch gekennzeichnet, daß ein Zu­ standsübergang einer Objektmanager-Komponente (10a, 10b, 12a, 12b) oder eines Objektmanagers (22a, 22b, 24a, 24b) bei Vor­ liegen eines Ausfallereignisses selbsttätig erfolgt.

3. Infrastruktur (2) nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Über­ mittlung eines datenlesenden Auftrages an den jeweils prozeß­ führenden Server einer Objektmanager-Komponente oder eines Objektmanagers erfolgt.

4. Infrastruktur (2) nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die Über­ mittlung eines datenschreibenden Auftrages an alle zueinander redundanten Objektmanager-Komponenten (10a, 10b, 12a, 12b) oder Objektmanager (22a, 22b, 24a, 24b) erfolgt.

5. Infrastruktur (2) nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß zum Aufda­ ten von Objektmanagern (20, 26) auf wiederanlaufenden redun­ danten Objektmanager-Komponenten der führende Server auf Auf­ trag ein konsistentes Abbild seiner Prozeßdaten erstellt und zum aufrufenden Client überträgt.

6. Infrastruktur (2) nach Anspruch 5, dadurch gekennzeichnet, daß eine Ob­ jektmanager-Komponente (10a, 10b, 12a, 12b) oder ein Objekt­ manager (22a, 22b, 24a, 24b) in einem Server-Hauptteil (38) eine Schnittstelle (36) aufweist, die eine Änderung des Red­ undanz-Zustandes erfaßt.