DE19520740A1 - Infrastruktur für ein System von verteilten Objektmanager-Komponenten - Google Patents
Infrastruktur für ein System von verteilten Objektmanager-KomponentenInfo
- Publication number
- DE19520740A1 DE19520740A1 DE19520740A DE19520740A DE19520740A1 DE 19520740 A1 DE19520740 A1 DE 19520740A1 DE 19520740 A DE19520740 A DE 19520740A DE 19520740 A DE19520740 A DE 19520740A DE 19520740 A1 DE19520740 A1 DE 19520740A1
- Authority
- DE
- Germany
- Prior art keywords
- object manager
- components
- infrastructure
- component
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 claims description 15
- 230000008569 process Effects 0.000 claims description 15
- 230000008859 change Effects 0.000 claims description 4
- 238000012544 monitoring process Methods 0.000 abstract description 18
- 238000004891 communication Methods 0.000 abstract description 14
- 238000012545 processing Methods 0.000 abstract description 6
- 238000012806 monitoring device Methods 0.000 abstract description 2
- 230000005540 biological transmission Effects 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 3
- 238000004886 process control Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000003745 diagnosis Methods 0.000 description 1
- 238000010327 methods by industry Methods 0.000 description 1
- 230000008092 positive effect Effects 0.000 description 1
- 208000024891 symptom Diseases 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G05—CONTROLLING; REGULATING
- G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
- G05B19/00—Programme-control systems
- G05B19/02—Programme-control systems electric
- G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
- G05B19/4185—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by the network communication
-
- H—ELECTRICITY
- H02—GENERATION; CONVERSION OR DISTRIBUTION OF ELECTRIC POWER
- H02B—BOARDS, SUBSTATIONS OR SWITCHING ARRANGEMENTS FOR THE SUPPLY OR DISTRIBUTION OF ELECTRIC POWER
- H02B15/00—Supervisory desks or panels for centralised control or display
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
- Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
- Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]
Landscapes
- Engineering & Computer Science (AREA)
- Power Engineering (AREA)
- General Engineering & Computer Science (AREA)
- Manufacturing & Machinery (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Automation & Control Theory (AREA)
- Multi Processors (AREA)
- Hardware Redundancy (AREA)
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.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19520740A DE19520740C2 (de) | 1995-06-07 | 1995-06-07 | Infrastruktur für ein System von verteilten Objektmanager-Komponenten |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19520740A DE19520740C2 (de) | 1995-06-07 | 1995-06-07 | Infrastruktur für ein System von verteilten Objektmanager-Komponenten |
Publications (2)
Publication Number | Publication Date |
---|---|
DE19520740A1 true DE19520740A1 (de) | 1996-12-12 |
DE19520740C2 DE19520740C2 (de) | 1999-08-19 |
Family
ID=7763809
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19520740A Expired - Fee Related DE19520740C2 (de) | 1995-06-07 | 1995-06-07 | Infrastruktur für ein System von verteilten Objektmanager-Komponenten |
Country Status (1)
Country | Link |
---|---|
DE (1) | DE19520740C2 (de) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0893746A2 (de) * | 1997-07-25 | 1999-01-27 | ABBPATENT GmbH | Prozessdiagnosesystem und -Verfahren |
DE102020125860A1 (de) | 2020-10-02 | 2022-04-07 | Elpro Gmbh | Verfahren zum Einbinden einer Anlagenkomponente in ein Anlagensystem |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0604091A2 (de) * | 1992-12-21 | 1994-06-29 | Hitachi, Ltd. | Überwachungs- und Regelungsmethode und zugehöriges System |
WO1995030937A1 (de) * | 1994-05-10 | 1995-11-16 | Siemens Aktiengesellschaft | Leitsystem für eine technische anlage |
-
1995
- 1995-06-07 DE DE19520740A patent/DE19520740C2/de not_active Expired - Fee Related
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0604091A2 (de) * | 1992-12-21 | 1994-06-29 | Hitachi, Ltd. | Überwachungs- und Regelungsmethode und zugehöriges System |
WO1995030937A1 (de) * | 1994-05-10 | 1995-11-16 | Siemens Aktiengesellschaft | Leitsystem für eine technische anlage |
Non-Patent Citations (4)
Title |
---|
CH-Z.: Europhysics Conference on Control Systems for Experimental Physics, Proceedings (CERN 90-08)Villas sur Ollon, Switzerland, 28. Sept.-2. Oct. 1987, S. 15-20, Published: CERN, Geneva, Switzerland * |
Elektronik 25/1994, S. 58-64 * |
Elektronik 7/ 31.3.1989, S. 52-58 * |
net 40, 1986, H. 9, S. 338-342 * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP0893746A2 (de) * | 1997-07-25 | 1999-01-27 | ABBPATENT GmbH | Prozessdiagnosesystem und -Verfahren |
DE19732046A1 (de) * | 1997-07-25 | 1999-01-28 | Abb Patent Gmbh | Prozeßdiagnosesystem und Verfahren zur Diagnose von Vorgängen und Zuständen eines technischen Prozesses |
EP0893746A3 (de) * | 1997-07-25 | 2000-02-02 | ABBPATENT GmbH | Prozessdiagnosesystem und -Verfahren |
DE102020125860A1 (de) | 2020-10-02 | 2022-04-07 | Elpro Gmbh | Verfahren zum Einbinden einer Anlagenkomponente in ein Anlagensystem |
Also Published As
Publication number | Publication date |
---|---|
DE19520740C2 (de) | 1999-08-19 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE69128271T2 (de) | Verfahren und System zur Erhöhung der Betriebsverfügbarkeit eines Systems von Rechnerprogrammen, wirkend in einem verteilten Rechnerssystem | |
DE19836347C2 (de) | Fehlertolerantes Computersystem | |
DE10362379B3 (de) | Simulationssystem für Mehrfachknoten-Prozesssteuerungssysteme | |
DE602004002858T2 (de) | Vorrichtung und Verfahren zur Datenarchivierung in einem Clustersystem | |
EP0807883B1 (de) | Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen | |
DE112011103443T5 (de) | Intelligente Schnittstelle für ein dezentrales Steuerungssystem | |
WO2018091658A1 (de) | Konzept zum steuern einer nachrichtenübermittlung zwischen kommunikationsteilnehmern eines automatisierungssystems | |
WO1994019739A1 (de) | Einrichtung zur automatischen erzeugung einer wissensbasis für ein diagnose-expertensystem | |
EP1296207B1 (de) | HMI Gerät und Verfahren zur Bedienung einer technischen Einrichtung, Automatisierungssystem mit HMI Gerät und Computerprogrammprodukt mit Programm zur Durchführung des Verfahrens in einem HMI Gerät oder Automatisierungssystem | |
EP1231537A1 (de) | Automatische Inbetriebnahme eines Clustersystems nach einem heilbaren Fehler | |
DE19842593C2 (de) | Verfahren zum Betrieb eines Busmasters an einem Feldbus | |
DE19520745C2 (de) | Infrastruktur für ein System von verteilten Objektmanager-Komponenten | |
DE60309012T2 (de) | Verfahren und system zur sicherstellung eines busses und eines steuerservers | |
DE19520747C2 (de) | Infrastruktur für ein System von verteilten Objektmanager-Komponenten | |
DE19520744C2 (de) | Infrastruktur für ein System von verteilten Objektmanager-Komponenten | |
EP1820307B1 (de) | Verfahren zum nachweis der verf]gbarkeit von systemkomponenten eines redundanten kommunikationssystems | |
DE19520740C2 (de) | Infrastruktur für ein System von verteilten Objektmanager-Komponenten | |
DE19731026C2 (de) | Fernwartung eines Bus-Systems auf der Basis des SNMP-Protokolls | |
DE10354938B4 (de) | Datenverarbeitungssystem mit automatisierbarer Verwaltung und Verfahren zur automatisierten Verwaltung eines Datenverarbeitungssystems | |
EP1239369A1 (de) | Fehlertolerante Rechneranordnung und Verfahren zum Betrieb einer derartigen Anordnung | |
EP2204704B1 (de) | Verfahren zum Betrieb eines mehrere vernetzte Rechnereinheiten umfassenden industriellen Automatisierungsystems und industrielles Automatisierungsystem | |
EP1019808B1 (de) | Responsives system und verfahren zur digitalen signalverarbeitung sowie verfahren zum betrieb eines responsiven systems | |
WO2021037378A1 (de) | Verfahren zum automatischen markieren, cluster-arbeitsknoten, cluster, netzwerk, computerprogramm und computerlesbares medium | |
EP1287435B1 (de) | Vorrichtung und verfahren zur synchronisation eines systems von gekoppelten datenverarbeitungsanlagen | |
DE10123822A1 (de) | Einrichtung zur Verwaltung einer Dienstverbindung zwischen einem Clientprozess mit einer Single-Thread-Bibliothek und einem Serverprozess |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
OP8 | Request for examination as to paragraph 44 patent law | ||
D2 | Grant after examination | ||
8364 | No opposition during term of opposition | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee | ||
R119 | Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee |
Effective date: 20150101 |