DE19520744A1 - Infrastruktur für ein System von verteilten Objektmanager-Komponenten - Google Patents
Infrastruktur für ein System von verteilten Objektmanager-KomponentenInfo
- Publication number
- DE19520744A1 DE19520744A1 DE19520744A DE19520744A DE19520744A1 DE 19520744 A1 DE19520744 A1 DE 19520744A1 DE 19520744 A DE19520744 A DE 19520744A DE 19520744 A DE19520744 A DE 19520744A DE 19520744 A1 DE19520744 A1 DE 19520744A1
- Authority
- DE
- Germany
- Prior art keywords
- object manager
- infrastructure
- components
- 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 19
- 230000008569 process Effects 0.000 claims description 19
- 230000005540 biological transmission Effects 0.000 claims description 10
- 230000008859 change Effects 0.000 claims description 4
- 230000007704 transition Effects 0.000 claims description 3
- 238000012544 monitoring process Methods 0.000 abstract description 18
- 238000012545 processing Methods 0.000 abstract description 6
- 238000012806 monitoring device Methods 0.000 abstract description 2
- 238000004891 communication Methods 0.000 description 13
- 230000007246 mechanism Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 3
- 238000013461 design Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 238000005259 measurement Methods 0.000 description 2
- 238000004886 process control Methods 0.000 description 2
- 230000004913 activation 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
- 238000010327 methods by industry Methods 0.000 description 1
- 230000008092 positive effect Effects 0.000 description 1
- NQLVQOSNDJXLKG-UHFFFAOYSA-N prosulfocarb Chemical compound CCCN(CCC)C(=O)SCC1=CC=CC=C1 NQLVQOSNDJXLKG-UHFFFAOYSA-N 0.000 description 1
- 208000024891 symptom Diseases 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- 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
-
- 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
-
- 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
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/31—From computer integrated manufacturing till monitoring
- G05B2219/31107—Start up of object manager module
-
- 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
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/31—From computer integrated manufacturing till monitoring
- G05B2219/31253—Redundant object manager
-
- 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
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/31—From computer integrated manufacturing till monitoring
- G05B2219/31393—Object oriented engineering data management
-
- 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
- G05B2219/00—Program-control systems
- G05B2219/30—Nc systems
- G05B2219/37—Measurements
- G05B2219/37518—Prediction, estimation of machining parameters from cutting data
-
- 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 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
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.
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 Zustandsü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 Objektmanagerdaten 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 Ini
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 Spezialfall 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
tes 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.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE19520744A DE19520744C2 (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 |
---|---|---|---|
DE19520744A DE19520744C2 (de) | 1995-06-07 | 1995-06-07 | Infrastruktur für ein System von verteilten Objektmanager-Komponenten |
Publications (2)
Publication Number | Publication Date |
---|---|
DE19520744A1 true DE19520744A1 (de) | 1996-12-12 |
DE19520744C2 DE19520744C2 (de) | 1999-09-30 |
Family
ID=7763810
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE19520744A Expired - Fee Related DE19520744C2 (de) | 1995-06-07 | 1995-06-07 | Infrastruktur für ein System von verteilten Objektmanager-Komponenten |
Country Status (1)
Country | Link |
---|---|
DE (1) | DE19520744C2 (de) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE19918270A1 (de) * | 1999-04-22 | 2000-10-26 | Abb Patent Gmbh | Verfahren zur bedarfsabhängigen Berechnung einer Funktion |
WO2000073864A1 (de) * | 1999-05-28 | 2000-12-07 | Dr. Johannes Heidenhain Gmbh | Verfahren zum synchronisierten hochlauf einer numerischen steuerung |
WO2011061394A1 (en) * | 2009-11-20 | 2011-05-26 | Wärtsilä Finland Oy | A control system of a reciprocating engine |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE19958825A1 (de) * | 1999-12-07 | 2001-06-13 | Zeiss Carl Jena Gmbh | Verfahren zur Kontrolle eines Steuerungssystems |
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 DE19520744A patent/DE19520744C2/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)Villars 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 |
---|---|---|---|---|
DE19918270A1 (de) * | 1999-04-22 | 2000-10-26 | Abb Patent Gmbh | Verfahren zur bedarfsabhängigen Berechnung einer Funktion |
WO2000073864A1 (de) * | 1999-05-28 | 2000-12-07 | Dr. Johannes Heidenhain Gmbh | Verfahren zum synchronisierten hochlauf einer numerischen steuerung |
US6988191B1 (en) | 1999-05-28 | 2006-01-17 | Dr. Johannes Heidenhain Gmbh | Method for the synchronized start-up of a numerical control |
WO2011061394A1 (en) * | 2009-11-20 | 2011-05-26 | Wärtsilä Finland Oy | A control system of a reciprocating engine |
Also Published As
Publication number | Publication date |
---|---|
DE19520744C2 (de) | 1999-09-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
DE19836347C2 (de) | Fehlertolerantes Computersystem | |
DE10362379B3 (de) | Simulationssystem für Mehrfachknoten-Prozesssteuerungssysteme | |
DE60004365T2 (de) | System und verfahren zur überwachung von einem verteilten fehlertoleranten rechnersystem | |
EP0807883B1 (de) | Kommunikationssystem mit Mitteln zum Austausch von Softwareprozessen | |
EP2817682B1 (de) | Verfahren zum ausfallsicheren betreiben eines prozesssteuersystems mit redundanten steuereinrichtungen | |
DE10392438T5 (de) | Vorrichtung und Verfahren zur zentralen Überwachung und Steuerung von Anlagen | |
DE112011103443T5 (de) | Intelligente Schnittstelle für ein dezentrales Steuerungssystem | |
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 | |
EP1920299B1 (de) | Verfahren und vorrichtung zur überwachung einer technischen einrichtung | |
EP3523927A1 (de) | Konzept zum steuern einer nachrichtenübermittlung zwischen kommunikationsteilnehmern eines automatisierungssystems | |
EP1358554A1 (de) | Automatische inbetriebnahme eines clustersystems nach einem heilbaren fehler | |
DE69927223T2 (de) | Ausfallsicherheit eines Mehrrechnersystems | |
DE60309012T2 (de) | Verfahren und system zur sicherstellung eines busses und eines steuerservers | |
DE19520744C2 (de) | Infrastruktur für ein System von verteilten Objektmanager-Komponenten | |
DE19520745C2 (de) | Infrastruktur für ein System von verteilten Objektmanager-Komponenten | |
DE19520747C2 (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 | |
EP1019808B1 (de) | Responsives system und verfahren zur digitalen signalverarbeitung sowie verfahren zum betrieb eines responsiven systems | |
EP2204704B1 (de) | Verfahren zum Betrieb eines mehrere vernetzte Rechnereinheiten umfassenden industriellen Automatisierungsystems und industrielles Automatisierungsystem | |
EP1277094B1 (de) | Überwachungsverfahren fur vernetzte datenverarbeitungsanlagen | |
EP1287435B1 (de) | Vorrichtung und verfahren zur synchronisation eines systems von gekoppelten datenverarbeitungsanlagen |
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 |