DE19818714A1

DE19818714A1 - Blockiervorrichtung für bewegliche Anschlüsse von Schalldämpfern an halbautomatischen Waffen

Info

Publication number: DE19818714A1
Application number: DE1998118714
Authority: DE
Inventors: Detlef Joniskeit
Original assignee: Individual
Current assignee: Individual
Priority date: 1998-04-27
Filing date: 1998-04-27
Publication date: 2000-01-13
Anticipated expiration: 2018-04-28
Also published as: DE19818714C2

Description

Die vorliegende Erfindung betrifft ein Verfahren zur Erzeu gung einer Oberfläche zum Bedienen und Beobachten von Leitsy stemen, insbesondere für Prozeß- und Produktionsanlagen. Im Bereich der Leitsystemtechnik werden Oberflächen für die Überwachung und/oder Steuerung von industriellen Anlagen be nötigt. Sie dienen dabei der visuellen Darstellung von Pro zeßvorgängen, Meß- und Regelungsgrößen und/oder Bedieneinhei ten.

So sind unterschiedliche plattformspezifische Visualisie rungs- und Bedienkonzepte bekannt, die aufgrund der verschie denen Hardware- und Software-Plattformen keinen Raum für ei nen systemübergreifenden Informationsaustausch zulassen. Fer ner sind die im Bereich der Leitsystemtechnik anfallenden In formationen, beispielsweise Prozeßabläufe beschreibende Ein gangs-, Zustands- und Ausgangsgrößen sowie deren Beziehungen untereinander, Sollwerte, Sollzustände und dergleichen, wie sie bei verschiedenen Prozeß- und Produktionsanlagen anfal len, beispielsweise in Kraftwerken, Raffinerien, Frachtsyste men und dergleichen, nur lokal verfügbar, das heißt im weite sten Sinne direkt vor Ort.

Es besteht ein Bedarf an einheitlichen Visualisierungs- und Bedienkonzepten, um einerseits dem Bedienpersonal einen ein fachen Umgang mit diesen zu ermöglichen, so daß beispielswei se eine schnelle Einarbeitungszeit in unterschiedliche Syste me aufgrund einer einheitlichen, dem Benutzer vertrauten Grundstruktur gegeben ist, und zum anderen um in möglichst vielen Ebenen des Leitsystems einen modularen Aufbau zu er möglichen, beispielsweise mit standardisierten Komponenten. Um dabei möglichst umfassende Einsatzmöglichkeiten nutzen zu können, ist es erforderlich losgelöst von jeweils gegebenen Hardware- und Softwareumgebungen agieren zu können, also plattformunabhängige Systeme bereitzustellen, die damit gleichzeitig einen systemübergreifenden Informationsaustausch ermöglichen. Ferner ist bei Leitsystemen ein Bedarf hinsicht lich hoher Verfügbarkeit gegeben.

Der vorliegenden Erfindung liegt die Aufgabe zugrunde, ein Verfahren zur Erzeugung einer Oberfläche zum Bedienen und Be obachten von Leitsystemen, insbesondere für Prozeß- und Pro duktionsanlagen, anzugeben, welches eine überaus einfache, bedienerfreundliche und kostengünstige Handhabung von Leitsy stemen, insbesondere für Prozeß- und Produktionsanlagen, er möglicht.

Zur technischen Lösung wird ein Verfahren zur Erzeugung einer Oberfläche zum Bedienen und Beobachten von Leitsystemen, ins besondere für Prozeß- und Produktionsanlagen, bereitgestellt, wobei im Bereich von Leitsystemen anfallende Informationen von einem an wenigstens ein Leitsystem adaptierbaren Server- Rechner über ein Client-Server-Rechner-Netzwerk auf einem Client-Rechner in Eingabe- und Anzeigeelementen viusalisiert werden.

Verfahrensgemäß sind die im Bereich von Leitsystemen anfal lenden Informationen über einen an das jeweilige Leitsystem adaptierbaren Server-Rechner für einen im Client-Server- Rechner-Netzwerk vorhandenen Client-Rechner zugänglich, wobei die Informationen vom Server-Rechner auf dem Client-Rechner in Eingabe- und Anzeigeelementen visualisiert werden. Dabei werden die Informationen erst seitens des Client-Rechners aufbereitet und ausgewertet und in den entsprechenden Einga be- und Anzeigeelementen visualisiert. Die Informationen kön nen so von dem Server-Rechner beispielsweise als reine ASCII- Daten in das Client-Server-Rechner-Netzwerk gegeben und sei tens des Client-Rechners auf diesem entsprechend interpre tiert werden.

Dadurch, daß die Informationen verfahrensgemäß client-seitig in Eingabe- und Anzeigeelementen viusalisiert werden, ist ei ne überaus einfache, bedienerfreundliche und kostengünstige Handhabung von Leitsystemen gegeben.

Vorteilhafterweise sind die Eingabe- und Anzeigeelemente frei parametrierbar und konfigurierbar. Dadurch wird das Einsatz spektrum im Bereich unterschiedlicher Leitsysteme erheblich vergrößert, wobei für den Benutzer gleichzeitig eine hohe In dividualisierung hinsichtlich Gestaltung seiner Oberfläche gegeben ist.

Gemäß einem weiteren besonders vorteilhaften Vorschlag der Erfindung ist das Client-Server-Rechner-Netzwerk ein Intra- und/oder Internet. Dadurch wird zum einen eine hohe Verfüg barkeit erzielt, die der rasch voranschreitenden Vernetzung der Bürowelt zu sogenannten Intranets als auch der weltweiten Vernetzung in sogenannten Internets gerecht wird und eine Nutzung der Netze zum Bedienen und Beobachten von Leitsyste men, insbesondere für Prozeß- und Produktionsanlagen ermög licht. So ist eine globale Bedienung und Beobachtung von Pro zeß- und Produktionsanlagen, beispielsweise zur Darstellung von leittechnischen Informationen wie Protokolle, Meldungen, Datenbestände aus Datenbanken, und dergleichen gegeben.

Gemäß einem weiteren vorteilhaften Vorschlag der Erfindung erfolgt die Visualisierung mittels eines Web-Browsers. Damit wird ein Bedienen und Beobachten von Leitsystemen auf ein fachste Art und Weise mit gängigen Web-Browsern, welche nahezu für alle Hardware- und Software-Plattformen verfügbar sind, ermöglicht. Der Umgang mit dem Leitsystem wird damit dem Be nutzer weiter vereinfacht und bedienerfreundlicher.

Durch die Verwendung der Internet-Technologien wird das Be dienen und Beobachten von Leitsystemen äußerst kostengünstig, da einfache Rechner oder Terminals eingesetzt werden können und nicht erst spezielle und teure Hardware zum Einsatz kom men muß. Die im Bereich von Leitsystemen anfallenden Informa tionen lassen sich dabei auch auf vielen unterschiedlichen Hardware- und Softwareplattformen sogar gleichzeitig darstel len, vorteilhafterweise nach Zugriffsbefugnissen gestaffelt. Durch einen damit verbundenen geringem Administrations- und Pflegeaufwand lassen sich weitere Kosten einsparen. Ferner können die Anwender in ihrer gewohnten Umgebung, also bei spielsweise von zu Hause aus Leitsysteme bedienen und beob achten. Durch einen modularen Software-Aufbau lassen sich darüber hinaus bereits bestehende Leitsysteme nach und nach umrüsten bzw. ausstatten.

Gemäß einem weiteren besonders vorteilhaften Vorschlag der Erfindung werden die Eingabe- und Anzeigeelemente vom Client- Rechner generiert. Dadurch wird das Client-Server-Rechner- Netzwerk weitestgehend entlastet und die Bearbeitungszeit zum Generieten der Eingabe- und Anzeigeelemente ist im wesentli chen nur noch abhängig von der Leistungsfähigkeit des Client- Rechners. Dazu wird beispielsweise ein Datensatz vom Server auf den Client übertragen, dort interpretiert und ausgeführt und nach einer Verarbeitung durch den Benutzer, beispielswei se durch eine Eingabe, zur Endverarbeitung an den Server zu rückgeschickt. Das eigentliche Programm läuft somit auf dem Client-Rechner. Gemäß einem weiteren vorteilhaften Vorschlag der Erfindung werden die Eingabe- und Anzeigeelemente mittels Java-Applets und/oder Java-Beans generiert. Java ist eine von Sun Microsystems entwickelte Interpreter-Sprache, die ähnlich strukturiert ist wie die objektorientierte Programmiersprache C++. Java-Applets sind mit Java erstellte kleine Programme, die in HTML-Seiten eingebaut und dort für interaktive Anwen dungen genutzt werden können. HTML (HyperTextMarkupLanguages) wurde speziell für die Internet-Technologie entwickelt und ist die Basis des World Wide Web (WWW). Das HTML-Format be schreibt die grafische Formatierung von Texten und die Ein bindung von Bildern und Ereignissen. Mit HyperText wird die Möglichkeit verstanden, über in einem Text enthaltene Quer verweise an eine anderen Stelle in einem Text zu springen, im World Wide Web konkret, eine andere Web-Seite im Internet zu laden. Java-Beans sind Java-Komponenten, die noch leistungs fähiger sind als Java-Applets, das heißt andere bzw. weitere Möglichkeiten bieten.

Java selbst eröffnet umfangreiche Vorteile. So ist Java bei spielsweise plattformneutral, einfach, sicher, schnell und dynamisch. Die Schnelligkeit von Java beruht darauf, daß in einem in Java entwickelten Applet zwei Technologien vereinigt sind. Zum einen wird der Quellcode eines Programms zunächst in den sogenannten Java-Byte-Code übersetzt. Anschließend wird das so entstandene Applet von einem in gängigen Web- Browsern vorhandenen Interpreter ausgeführt. Die im Applet eingesetzten Bibliotheken zur Erzeugung von Text-, Grafik- und Grafikkomponenten werden erst bei Ausführung des Pro gramms, also zur Laufzeit ausgeführt, also auf dem jeweiligen Client-Rechner.

Die mit Java und im Internet gegebenen Leistungsmerkmale las sen sich so auf einfache und kostengünstige Art und Weise zum Bedienen und Beobachten von Leitsystemen einsetzen.

Vorteilhafterweise umfassen die Eingabe- und Anzeigeelemente mit einem weiteren Vorschlag der Erfindung Meldungen, Kurven verläufe und/oder Systemgrafiken wie Anlagenbilder und der gleichen.

Weitere Vorteile und Merkmale der Erfindung ergeben sich aus der folgenden Beschreibung anhand von Beispielen. Dabei zei gen:

Fig. 1 eine schematisierte Darstellung für eine Kommunikati onsstruktur zwischen einzelnen Systemteilen;

Fig. 2 eine schematisierte Darstellung für den Aufbau eines Applets, hier zur Visualisierung einer Systemgrafik;

Fig. 3 eine Darstellung eines Ausführungsbeispiels für Meldun gen;

Fig. 4 eine Darstellung eines Ausführungsbeispiels für Kurven verläufe und

Fig. 5 eine Darstellung eines Ausführungsbeispiels für eine Systemgrafik.

Fig. 1 zeigt in einer schematisierten Darstellung die Kommuni kationsstruktur zwischen den einzelnen Teilen des Systems, die über TCP/IP-Verbindungen (Transmission Control Proto col/Internet Protocol) durchgeführt wird. Die dabei verwende ten Telegramme enthalten reine ASCII-Daten, die in den ein zelnen Teilsystemen entsprechend interpretiert werden.

Die Kommunikationsarchitektur 1 umfaßt drei getrennte Schich ten, einen Server 4 zur Anbindung an ein Leitsystem 2, hier beispielsweise an SICALIS PMC WinCC oder SiiX der Firma Sie mens, und andere, mittels entsprechender Adaptionsmodule 3, einen Vermittler (Broker) 4, der seitens des Servers 4 be reitgestellt und im weiteren auch Server genannt wird, sowie einen Client 5 zum Generieren und Visualisieren von Eingabe- und Anzeigeelementen durch Aufruf von sogenannten Methoden, hier in Form von Kurvenbausteinen 6, Meldebausteinen 7 und Systemgrafikbausteinen 8, die hier konkret in Form von Beans vorliegen, so daß der Client 5 zur Appletanbindung dient.

Der Kommunikationsfluß zwischen den einzelnen Schichten wird dabei folgendermaßen durchgeführt:

Von einer Komponente zum Viusalisieren von Eingabe- und An zeigeelementen wird eine sogenannte Methode 9 in dem Client 5 aufgerufen, über die ein entsprechendes Telegramm 10 erzeugt und versendet wird. Für diese Aufgabe stellt der Client 5 verschiedene Methoden zum Absetzen und Empfangen von Tele grammen bereit, die zum Beispiel Anmeldung und Abmeldung ver schiedener Bausteine zum Generieren von Eingabe- und Anzeige elementen umfassen.

Diese Schnittstellen werden nachfolgend noch näher beschrie ben:

Telegramm verschicken

Die Methode sendTelegram versendet ein Telegramm, welches von einer Datenquelle erzeugt wurde. Telegramme die über diese Schnittstelle versandt werden, erwarten stets eine Antwort refuse oder accept.

Telegramm verschicken ohne Rückantwort

Die Methode sendLastTelegram versendet ein Telegramm, auf das keine Antwort von seiten der Datenquelle erwartet wird, z. B. das Telegramm zum Abmelden von Variablen.

Client-Id erzeugen

Die Methode maketJniqueID dient dazu, eine neue Client-ID zu erhalten, die dann bei den einzelnen Aufträgen mit übergeben werden kann. Die Methode benötigt keine Eingabeparameter. Als Rückgabeparameter wird eine Client-ID als String zurückgelie fert.

Zur Darstellung des Kommunikationsflusses wird im weiteren beispielhaft die Variablenanmeldung zur Visualisierung einer Systemgrafik, also beispielsweise eines Prozeßbildes, erläu tert:

Der Client 5 und der Systemgrafikbaustein 8 laufen dabei in einem Java-Applet ab. Dadurch wird hier keine TCP/IP-Ver bindung benötigt. Der Client 5 baut nach Aufruf der entspre chenden Methode 9 das zugehörige Telegramm 10 zusammen. Das Telegramm 10 wird vom Client 5 automatisch um eine sogenannte Client-ID erweitert, die einen String darstellt. Hierüber ist eine eindeutige Kennzeichnung des Anmeldeauftrags über diese TCP/IP-Verbindung gegeben. Die Client-ID wird dabei für spä tere, diesen Anmeldeauftrag betreffende Aktionen verwendet.

Das so generierte Telegramm 10 wird vom Client 5 an den Ser ver 4, über eine TCP/IP-Verbindung verschickt. Der Server 4 überprüft beim Eintreffen des Telegramms 10, ob bereits eine Anmeldung für diesen Baustein 8 vorliegt. Ist dies nicht der Fall, so wird für diesen Auftrag eine neue ID-Nummer im Ser ver 4 vergeben, die sogenannte Broker-ID, über die dann die Anmeldung dieses Bausteins 8 verwaltet wird. In dem eingelau fenen Telegramm 10 wird nun die Client-ID durch die Broker-ID ersetzt und der Auftrag 14 an das entsprechende Adaptionsmo dul 3 weitergeleitet. Falls für diesen Baustein bereits eine Anmeldung von einem anderen Client vorliegt, wird kein Tele gramm an das Adaptionsmodul 3 weitergeleitet, sondern es wird direkt ein Telegramm 12, eine sogenannte positive Quittung an den Client 5 mit der Client-ID zurückgeliefert.

Das Adaptionsmodul 3 bearbeitet die Anmeldung 14 für den BaLt stein 8 und schickt ein positives oder negatives Quittungste legramm 13 an den Server 4 zurück. In diesem Telegramm 13 ist wiederum die Broker-ID enthalten, die im eingelaufenen Tele gramm 14 enthalten war.

Über diese Broker-ID kann der Server 4 den Auftrag einem be stimmten Client beziehungsweise einer bestimmten Client-ID zuordnen. In dem eingelaufenen Antworttelegramm 13 wird nun die Broker-ID durch die Client-ID ersetzt und das Antwortte legramm 12 an den Client 5 weitergeleitet. Je nach positiver oder negativer Quittung wird vom Client 5 die entsprechende Methode in dem jeweiligen Baustein 8 aufgerufen, hier darge stellt durch den mit 15 gekennzeichneten Pfeil, wo dann die eigentliche Bearbeitung stattfindet. Diese Methoden sind oben bereits vorher ausgeführt.

Ferner wird innerhalb des Clients 5 über unterschiedliche Me thoden eine Fehlerbehandlung abgewickelt. Darunter gehört zum einen, daß die TCP/IP-Verbindung zum Server 4 orndungsgemäß geschlossen wurde, zum anderen Fehler die bei der Benutzung der TCP/IP-Verbindung auftreten.

Hierzu werden die beiden folgenden Methoden verwendet, die automatisch vom Client 5 aufgerufen werden:

TCP/IP-Verbindung geschlossen (TCP closed)

Die Methode TCP closed wird beim ordnungsgemäßen Schließen der TCP/IP-Verbindung im Client aufgerufen. Die Methode benö tigt die folgenden Parameter:
TCPConnection: Die TCP/IP-Verbindung, die geschlossen wurde.

TCP/IP-Verbindung fehlerhaft (TCP error)

Die Methode TCP error wird bei einem Fehler der TCP/IP- Verbindung im Client aufgerufen. In der Methode wird die feh lerhafte TCP/IP-Verbindung geschlossen. Die Methode benötigt die folgenden Parameter:
TCPConnection: die TCP/IP-Verbindung, die einen Fehler verursacht hat
TCPException: die erzeugte Exception, die einen Hinweis auf den Fehler enthält.

Desweiteren kann der Client 5 über verschiedene Parameter an spezielle Erfordernisse angepaßt werden, die bestimmte Eigen schaften des Clients 5 berücksichtigen.

Folgende Parameter können verwendet werden:
DebugMode: dient zum Steuern des Debug-Modus im Client. Ist der Debug-Modus eingeschaltet, werden Meldungen auf die Console im Web-Browser ausgegeben.
TCPBuffer: die Größe des TCP/IP-Puffers, die der Client verwendet. Die Größe liegt beispielsweise zwischen 4 Kbyte und 64 Kbyte.

Während der Client 5 einen Zugriff auf verschiedene Methoden durch die Bausteine 6, 7 und 8 ermöglicht, bietet der Server 4 keine öffentlichen Methoden zum Zugriff an, da ein Zugriff nur über den Client 5 und das Adaptionsmodul 3 stattfinden soll. Der Kurvenbaustein 6, der Meldebaustein 7 und der Sy stemgrafikbaustein 8 können somit nicht direkt auf die Metho den des Servers 4 zugreifen.

Ebenso wie der Client 5 kann der Server 4 über verschiedene Parameter und spezielle Erfordernisse angepaßt werden. Die Parameter werden beim Start des Servers 4 beispielsweise über die Kommandozeile eingegeben.

Folgende Parameter können verwendet werden:
Port: dient zur Auswahl des Serversockets.

Eine Fehlerbehandlung wird vom Server 4 selbstständig durch geführt. Dabei können unterschiedliche Fehlerfälle, insbeson dere bezüglich der Verbindungen abgefangen werden.

Folgende Fehler können verwendet werden:

- Verbindungszusammenbruch zu einem Client
Im Falle des Zusammenbruchs der TCP/IP-Verbindung zu einem Client werden vom Server die von diesem Client angemeldeten Variablen bei den zugehörigen Adaptionsmodul abgemeldet.
- Verbindungszusammenbruch zu einem Adaptionsmodul
Bricht die TCP/IP-Verbindung zu einem Adaptionsmodul zusam men, werden alle Clients, die Variablen von diesem Adapt be ziehen, über den Zusammenbruch der Verbindung informiert. Hierzu verschickt der Server an diese Clients ein shutdown- Telegramm. Der Client ist dann für die weitere Bearbeitung dieser Fehlermeldung zuständig.
- Fehlerhafter Verbindungsaufbau zu einem Adaptionsmodul
Tritt ein Fehler bei einem Verbindungsaufbau zu einem Adap tionsmodul auf, so wird zunächst an den anfordernden Client vom Server ein refuse-Telegramm abgesendet. Der Client kann bei Erhalt des refuse-Telegramms geeignete Maßnahmen einlei ten.

Die Adaptionsmodule 3 sind für die Anbindung an ein speziel les Leitsystem 2 verantwortlich. Hierzu muß das Adaptionsmo dul 3 die über eine TCP/IP-Verbindung eintreffenden Telegram me 14 vom Server 4 in entsprechende Befehle an das Leitsystem 2 umsetzen. Die Telegramme 14 die vom Adaptionsmodul 3 zu verarbeiten sind, umfassen dabei beispielsweise eine Fehler behandlung hinsichtlich der Verbindung zum Server 4 bzw. zum Leitsystem 2.

Dabei hat das Adaptionsmodul 3 beispielsweise folgende Fälle zu berücksichtigen:

- Ordnungsgemäßes Herunterfahren des Adaptionsmoduls
Wird das Adaptionsmodul heruntergefahren, so wird ein shut- down-Telegramm an alle angeschlossenen Server verschickt. Die Server können dieses Telegramm an die entsprechenden Clients weiterleiten.
- TCP/IP-Verbindungsabbruch zu einem Server
Die Adaptionsmodule sind dafür zuständig, alle Anmeldungen, die von dem gestörten Server durchgeführt worden sind, über Abmeldungen an das Leitsystem zu beenden. Telegramme, die vom Leitsystem an den gestörten Server verschickt werden, können von den Adaptionsmodulen verworfen werden.
- Fehler bei der Auftragsausführung beim Leitsystem
Die Adaptionsmodule können Telegramme, die von einem Server eintreffen, mit einer negativen Quittung (refuse-Telegramm) zurückschicken.
- Ordnungsgemäßes Herunterfahren des Leitsystems
Wird das Leitsystem heruntergefahren, so wird ein shutdown- Telegramm an alle angeschlossenen Server verschickt. Die Server können dieses Telegramm an die entsprechenden Clients weiterleiten.

Das Adaptionsmodul 3 selbst bietet keine öffentlichen Metho den zum Zugriff an, da ein Zugriff nur über den Server 4 stattfindet. Die Komponenten bzw. Bausteine 6, 7 und 8 zum Visualisieren von Eingabe- und Anzeigeelementen greifen somit nicht direkt auf die Methoden des Servers 4 zu.

Das Adaptionsmodul 3 kann über verschiedene Parameter einge stellt werden, die beispielsweise als Komandozeilenparameter beim Starten des Adaptionsmoduls 3 eingegeben werden. Die Pa rameter sind dabei leitsystemspezifisch.

Über ein Quittungstelegramm 13 bestätigt das Adaptionsmodul 3 dem Server 4 den Methodenaufruf und liefert entsprechende Da ten zurück.

Die vom System verwendeten Telegramme werden aus einzelnen Parametern zusammengesetzt, die beispielsweise alle durch Trennzeichen voneinander getrennt sind. Die Parameter werden grundsätzlich als ASCII-Zeichenketten übertragen. Das Tele gramm muß mit einem Endzeichen, beispielsweise mit einem "\n" enden. Die Telegramme werden zwischen einem Client 5, einem Server 4 und einem Adaptionsmodul 3 ausgetauscht.

Ein Telegramm kann sich dabei wie folgt aufbauen:

version/RQID/IID/data

version:
Telegramm Version "V1.0"
RQID:
Request Identifikator

IID:
Die Auftragskennung spezifiziert den Auftrag, den der Empfänger des Telegramms auszuführen hat.
startVarUpdate: Variablenaktualisierung
starten:
stopVarUpdate: Variablenaktualisierung
stoppen:
startMsgUpdate: Meldungsaktualisierung star ten
stopMsgUpdate: Meldungsaktualisierung stop pen
getVarArchiv: Lesen eines Variablenarchivs
getMsgArchiv: Lesen eines Meldungsarchivs
setVar: Schreiben einer Variablen
getVar: Einmaliges Lesen einer Va riablen
setMsg: Meldungsbedienung
accept: Positive Quittung
refuse: Negative Quittung
shutdown: Das System wurde beendet
newVar: neuer Variablenwert
newMsg: neuer Meldungssatz
stop: Ende einer Telegrammfolge
login: Anmeldung eines Clients beim Server
acceptlogin: Anmeldung abgelehnt
refuselogin: Ablehnung einer Anmel dung

data: Der Aufbau der Daten ist abhängig von der Auf tragskennung. Der genaue Aufbau ist der jeweili gen Auftragsbeschreibung zu entnehmen.

Die Darstellung von Datum bzw. Uhrzeit erfolgt in den Tele grammen als Zeichenkette. Das Datum und die Uhrzeit repräsen tieren die sogenannte GMT-Zeit. Die Darstellung erfolgt bei spielsweise mit folgendem Format:

Tag.Monat.Jahr-Stunde:Minute:Sekunde:Millisekunden

Die einzelnen Aufträge bzw. Auftragstelegramme können dabei wie folgt aufbaut sein.

Variablenaktualisierung starten "startVarUpdate" Beschreibung

Der Auftrag dient dazu, eine Variable zur Aktualisierung an zumelden. Die angemeldete Variable wird aus dem aktuellen Prozeßabbild des angesprochenen Leitsystems gelesen.

Telegrammaufbau version/RQID/IID/host/variable/cycleTime Parameter

version: Telegrammversion
RQID: Request-Id des auslösenden Auftrags
IID: Auftragskennung = startVarUpdate
host: Name des Rechners, auf dem sich das angespro chene Leitsystem befindet. Der Name muß auf dem Rechner des Servers bekannt sein
variable: Name der Variable, die aktualisiert werden soll. Die Syntax des Variablennamens ist sy stemabhängig.
cycletime:
0 spontane Aktualisierung
<0 Zykluszeit in ms

Variablenaktualisierung beenden "stopVarUpdate" Beschreibung

Der Auftrag dient dazu, eine angemeldete Variable wieder von der Aktualisierung abzumelden.

Telegrammaufbau version/RQID/IID Parameter

version: Telegrammversion
RQID: Request-Id des auslösenden Auftrags
IID: Auftragskennung = stopVarUpdate

Meldungsaktualisierung starten "startMsgUpdate" Beschreibung

Der Auftrag dient dazu, sich für den Empfang von aktuellen Meldungen anzumelden.

Telegrammaufbau version/RQID/IID/host/info/cycleTime Parameter

version: Telegrammversion
RQID: Request-Id des auslösenden Auftrags
IID: Auftragskennung = startMsgUpd
host: Name des Rechners, auf dem sich das angesprochene Leitsystem befindet. Der Name muß auf dem Rechner des Servers bekannt sein.
info: Die Zeichenkette beinhaltet systemspezifische Zusatzinformationen, die durch das angespro chene Leitsystem ausgewertet werden. Bei dem Leitsystem besteht dieser Parameter aus dem Formatnamen, mit dem der Meldetext aufberei tet werden soll.
cycleTime: Dieser Parameter ist im Normalfall auf 0 (spontane Aktualisierung) zu setzen. Nur bei Meldesystemen die auf eine Datenbank basie ren, ist es unter Umständen notwendig, die Daten zyklisch abzufragen.
0 spontane Aktualisierung
<0 Zykluszeit in ms

Meldungsaktualisierung beenden "stopMsgUpdate" Beschreibung

Der Auftrag dient dazu, die Meldesystemanmeldung zu beenden.

Telegrammaufbau version/RQID/IID Parameter

version: Telegrammversion
RQID: Request-Id des auslösenden Auftrags
IID: Auftragskennung = stopMsgUpdate

Variable aus dem Archiv lesen "getVarArchiv" Beschreibung

Der Auftrag dient dazu, Variablen aus dem Archiv zu lesen.

Telegrammaufbau

version/RQID/IID/host/variable/archiv/filter

Parameter

version: Telegrammversion
RQID: Request-Id des auslösenden Auftrags
IID: Auftragskennung = getVarArchiv
host: Name des Rechners, auf dem sich das angespro chene Leitsystem befindet. Der Name muß auf dem Rechner des Servers bekannt sein.
variable: Name der Variable, die gelesen werden soll. Die Syntax des Variablennamens ist systemab hängig.
archiv: Der Archivname ist nur bei Datenbankorien tierten Leitsystemen relevant. Der Syntax dE Archivnamens ist Systemabhängig. Wird der P rameter nicht verwendet, so ist dort "unused" einzutragen
filter: SQL Statement zur Filterung von Datensätzen aus dem Archiv. Wird kein Filter verwendet., ist "unused" einzutragen.
Syntax:
where DATE {<, = , <, < = , < = } 'tag.monat.jahr. stunde:minute:sekunde.millisekunde' [AND DATE . . . . . . . .]

Meldungen aus dem Archiv lesen "getMsgArchiv" Beschreibung

Der Auftrag dient dazu, Meldungen aus dem Archiv zu lesen.

Telegrammaufbau

version/RQID/IID/host/variable/archiv/filter

Parameter

version: Telegrammversion
RQID: Request-Id des auslösenden Auftrags
IID: Auftragskennung = getMsgArchiv
host: Name des Rechners, auf dem sich das angespro chene Leitsystem befindet. Der Name muß auf dem Rechner des Servers bekannt sein.
info: Die Zeichenkette beinhaltet systemspezifische Zusatzinformationen, die durch das angespro chene Leitsystem ausgewertet werden. Bei cle Leitsystem besteht dieser Parameter aus dem Formatnamen, mit dem der Meldetext aufberei tet werden soll.
archiv: Der Archivname ist nur bei Datenbankorien tierten Leitsystemen relevant. Der Syntax des Archivnamens ist systemabhängig. Wird der P rameter nicht verwendet, so ist dort "unused einzutragen
filter: SQL Statement zur Filterung von Datensätzen aus dem Archiv

Variablenwert schreiben "setVar" Beschreibung

Dieser Auftrag verändert einen Variablenwert im Prozeßabbild.

Telegrammaufbau

version/RQID/IID/host/variable/value/user

Parameter

version: Telegrammversion
RQID: Request-Id des auslösenden Auftrags
IID: Auftragskennung = setVar
host: Name des Rechners, auf dem sich das angespr chene Leitsystem befindet. Der Name muß auf dem Rechner des Servers bekannt sein.
variable: Name der Variablen die verändert werden soll. Die Syntax des Variablennamens ist systemab hängig.
value: Der Archivname ist nur bei Datenbankorien tierten Leitsystemen relevant. Der Syntax des Archivnamens ist Systemabhängig. Wird der Pa rameter nicht verwendet, so ist dort "unused" einzutragen.
user: Der Name des Benutzers, der die Bedienung durchgeführt hat.

Variablenwert lesen "getVar" Beschreibung

Dieser Auftrag dient dazu, den Wert einer Variablen einmalig zu lesen.

Telegrammaufbau

version/RQID/IID/host/variable

Parameter

version: Telegrammversion
RQID: Request-Id des auslösenden Auftrags
IID: Auftragskennung = getVar
host: Name des Rechners, auf dem sich das angespro chene Leitsystem befindet. Der Name muß auf dem Rechner des Servers bekannt sein.
variable: Name der Variablen die gelesen werden soll. Die Syntax des Variablennamens ist systemab hängig.

Meldung bedienen "setMsg" Beschreibung

Der Auftrag dient zur Bedienung einer Meldung, das heißt es können Meldungen quittiert, gelöscht, und kommentiert werden.

Telegrammaufbau

version/RQID/IID/host/message/function/value/user

Parameter

version: Telegrammversion
RQID: Request-Id des auslösenden Auftrags
IID: Auftragskennung = setMsg
host: Name des Rechners, auf dem sich das angespro chene Leitsystem befindet. Der Name muß auf dem Rechner des Servers bekannt sein.
message: Eindeutige Nummer der Meldung. Wird durch die Leitsysteme unterschiedlich behandelt.
time: Datum/Uhrzeit der Meldungserzeugung
class: Meldungsklasse
state: Meldungsstatus function:
Funktion der Bedienung:
acknowledge (Meldung quittieren)
delete (Meldung löschen)
comment (Meldung kommentieren)
value: Zusatzparameter zur Funktion. Der Parameter ist zur Zeit nur bei der Funktion "Meldung kommentieren" relevant. Hier wird der Kommer tar mit übertragen.
user: Der Name des Benutzers, der die Bedienung durchgeführt hat.

Als Quittungstelegramme können positive, negative als auch Fehlermeldungen und dergleichen verwendet werden.

Folgende Quittungstelegramme können dabei wie folgt aufgebaut sein:

Positive Quittung "accept" Beschreibung

Der Auftrag dient dazu, einen Request positiv zu Quittieren.

Telegrammaufbau

version/RQID/IID

Parameter

version: Telegrammversion
RQID: Spiegelung der Request-Id des auslösenden Auftrags
lID: Auftragskennung = accept

Negative Quittung "refuse" Beschreibung

Der Auftrag dient dazu, einen Request negativ zu Quittieren.

Telegrammaufbau

version/RQID/IID/refuseID/description

Parameter

version: Telegrammversion
RQID: Spiegelung der Request-Id des auslösenden Auftrags
IID: Auftragskennung = refuse
refuseID: Nummer, die den Grund der Ablehnung be schreibt
description: Zusatztext, der den Grund der Ablehnung be schreibt

Neuer Variablenwert "newVar" Beschreibung

Das Telegramm dient zur Übertragung von Variablendatensätzen. Je nach Anmeldung handelt es sich hierbei um aktuelle Werte aus dem Prozeßabbild oder um Archivwerte.

Telegrammaufbau

version/RQID/IID/value/time/state

Parameter

version: Telegrammversion
RQID: Spiegelung der Request-Id des auslösenden Auftrags
IID: Auftragskennung = refuse
value: Neuer Wert der Variablen. Zahlenwerte werden grundsätzlich als konvertierter Double-Wert übertragen.
time: Zeitstempel des zugehörigen Y-Wertes. Der Zeitwert erfolgt in der Darstellung. tag.monat.jahr-stunde:minute:sekunde.milli sekunde
state: Status der Variablen

Neue Meldung "newMsg" Beschreibung

Das Telegramm dient zur Übertragung von Meldungsdatensätzen. Je nach Anmeldung handelt es sich hierbei um aktuelle Meldun gen oder um Archivmeldungen.

Telegrammaufbau

version/RQID/IID/message/time/class/state/string/comment/bgco lor/fgcolor/bold/italic/underline

Parameter

version: Telegrammversion
RQID: Spiegelung der Request-Id des auslösenden Auftrags
IID: Auftragskennung = newMsg
message: Eindeutige Nummer der Meldung. Wird durch die Leitsysteme unterschiedlich behandelt.
time: Datum/Uhrzeit der Meldungserzeugung
class: Meldungsklasse
state: Meldungsstatus
string: Klartext der Meldung
comment: Meldungskommentar
bgcolor: Hintergrundfarbe der Meldung als RGB-Wert (zum Beispiel 255.255.255)
fgcolor: Vordergrundfarbe der Meldung als RGB-Wert (z. B. 0.0.0)
bold: Text fett darstellen. 0 = Nein; 1 = Ja.
italic: Text schräg darstellen. 0 = Nein; 1 = Ja.
underline: Text unterstrichen darstellen. 0 = Nein; 1 = Ja.

Shutdown "shutdown" Beschreibung

Der Auftrag dient dazu, den Client darüber zu informieren, daß sich eine Komponente beendet hat.

Telegrammaufbau

version/RQID/IID/shutdownlD/description

Parameter

version: Telegrammversion
RQID: Spiegelung der Request-Id des auslösenden Auftrags
IID: Auftragskennung = shutdown
shutdownID: Nummer, die den Grund des Shutdowns be schreibt
description: Zusatztext, der den Grund des Shutdowns be schreibt

Stop "stop" Beschreibung

Das "stop" Telegramm kennzeichnet das Ende einer Telegrammse quenz.

Telegrammaufbau

version/RQID/IID

Parameter

version: Telegrammversion
RQID Spiegelung der Request-Id des auslösenden Auftrags
IID: Auftragskennung = stop

Login "login" Beschreibung

Über das "login" Telegram versucht ein Client sich beim Ser ver anzumelden.

Telegrammaufbau

version/RQID/IID

Parameter

version: Telegrammversion
RQID: Login ID = FFFFFFFF IID; Auftragskennung = login

Login aktzeptieren "acceptlogin" Beschreibung

Über das "acceptlogin" Telegram bestätigt der Server die An meldung eines Clients und weist ihm eine ID zu.

Telegrammaufbau

version/RQID/IID/clientid

Parameter

version: Telegrammversion
RQID: unused
IID: Auftragskennung = acceptlogin
clientid; ID, die der Server seinen Clients zuweist

Login ablehnen "refuselogin" Beschreibung

Über das "refuselogin" Telegram meldet der Server, daß eine Anmeldung nicht akzeptiert wurde.

Telegrammaufbau

version/RQID/IID/description

Parameter

version: Telegrammversion
RQID: unused
IID: Auftragskennung = acceptlogin
clientid: ID, die der Server seinen Clients zuweist
description: Beschreibung der Ablehnung

Der Zugriff auf einzelne Bausteine 6, 7 und 8 zum Generieren von Eingabe- und Anzeigeelementen besteht aus drei einzelnen Phasen:

1. Anmeldung für die Prozeßvariable über den Auftrag, bei spielsweise startVarUpdate
2. Information des Clients über neue Werte des Bausteins, beispielsweise mit dem Auftrag newVar
3. Abmeldung für den Baustein, beispielsweise über den Auf trag stopVarUpdate
4. Die einzelnen Phasen können dabei wie folgt dargestellt wer den:

startVarUpdate

Zur Visualisierung von Kurven mit dem Kurvenbaustein 6 erhält dieser Daten über aktuelle oder archtivierte Prozeßdaten. Je nach der Art der Prozeßdaten, also aktuelle oder archivierte, werden unterschiedliche Aufträge verwendet. Die Aufträge zur Anforderung von aktuellen Kurvendaten besteht dabei aus drei einzelnen Phasen:

1. Anmeldung für die Prozeßvariable, beispielsweise über den Auftrag startTagLog.
2. Informationen des Clients über neue Werte der Prozeßvaria ble, beispielsweise mit dem Auftrag newVar.
3. Abmeldung für die Prozeßvariable, beispielsweise über den Auftrag stopTagLog.

Die einzelnen Phasen mit den dazugehörigen Aufträgen sehen dabei wie folgt aus:

Der Zugriff auf Prozeßvariablen zur Visualisierung von Kur venverläufen mit archivierten Daten besteht ebenfalls aus drei Phasen:

1. Die Anmeldung für die Prozeßvariable, beispielsweise über den Auftrag getTagArch.
2. Informationen des Clients über neue Werte der Prozeßvaria ble, beispielsweise mit dem Auftrag newTag.
3. Automatische Abmeldung für die Prozeßvariable, beispiels weise nach stop.

Zur Visualisierung von aktuellen oder archivierten Meldungen werden unterschiedliche Aufträge verwendet.

Der Zugriff auf aktuelle Meldungen einer Prozeßvariable be steht aus drei einzelnen Phasen:

1. Anmeldung für Meldungen der Prozeßvariable, beispielsweise über den Auftrag startMsgLog.
2. Information des Clients über neue Meldungen der Prozeßva riable, beispielsweise mit dem Auftrag newMsg.
3. Abmeldung für Meldungen der Prozeßvariablen, beispielswei se über den Auftrag stopMsgLog.

Der Zugriff auf archivierte Meldungen einer Prozeßvariable besteht aus drei einzelnen Phasen:

1. Anmeldung für die Prozeßvariable, beispielsweise über den Auftrag getMsgArch.
2. Information des Clients über die einzelnen archvierten Meldungen der Prozeßvariable, beispielsweise mit dem Auf trag newMsg.
3. Abmeldung für die Prozeßvariable, beispielsweise über den Auftrag stop.

Die einzelnen Phasen mit den zugehörigen Aufträgen sehen da bei wie folgt aus:

Zur Visualisierung von Meldungen bietet das System zwei un terschiedliche Ausprägungen von sogenannten Meldefenstern an, ein sogenanntes aktuelles Meldefenster und ein sogenanntes selektiertes Meldefenster.

Das aktuelle Meldefenster stellt die aktuell einlaufenden Meldungen in zeitlich richtiger Reihenfolge dar. Das aktuelle Meldefenster kann mit parametrierbaren Filtern auf die jewei lige Anwendung angepaßt werden. Meldungen die ihren Zustand än dern, werden in dem jeweiligen Anzeigeelement aktualisiert bzw. gelöscht.

In dem sogenannten selektierten Meldefenster werden Meldungen aus einem Meldungsarchiv in zeitlich richtiger Reihenfolge dargestellt. Aus dem selektierten Meldefenster können Mel dungsbedienungen durchgeführt werden, beispielsweise Einzel- und Sammelquittierung, Kommentieren von Meldungen, Anzeigen und Ändern von Info-Texten, Bildanwahl, Meldungen löschen, Selektion einstellen. Ein Meldungsaufbau kann dabei wie folgt aussehen, (vgl. auch den in Fig. 3 in den einzelnen Zeilen von links nach rechts dargestellten Meldungsaufbau):

Datum/Zeit Meldungsbeginn, Anlagen kennzeichnen, Meldungs klasse, Meldungszustand, Meldungstext, Meldungsnummer, Mel dungsdauer und Prozeßwert.

Dabei können verschiedene Meldungszustände und Meldungsklas sen farblich gekennzeichnet werden.

Mit dem Kurvenbaustein werden archivierte Prozeßwerte und Prozeßwerte aus Systemgrafiken grafisch in einer Kurvenform dargestellt. Dazu bietet der Kurvenbaustein beispielsweise folgende Funktionalität:

- Darstellung einer beliebigen Anzahl von Kurven
- Kurvendarstellung mit unterschiedlichen Farben, Linienarten und Füllmustern
- Darstellung der Kurven als Polygonzug, Treppenkurve und Einzelpunkte
- Y-Achsen getrennt für jede Kurve oder für mehrere Kurven gleichzeitig mit automatischer oder manueller Skalierung und Beschriftung
- Eine X-Achse mit Skalierung und Beschriftung, wahlweise als Zeit- oder Wertachse
- Scrollen von statischen Kurven, falls deren Umfang den Dar stellungsbereich überschreitet, getrennt für alle Achsen.
- Dynamische Vergabe von Farbwerten für einzelne Kurven, z. B. um bei Grenzwertverletzungen die Kurvenfarbe wechseln zu können.
- Anzeige der Kurvenwerte mittels Lineal.
- Vergrößerung (Zoomen) von Ausschnitten
- Überlagerung des Kurvenbereichs mit einem Raster
- Einblenden einier Legende mit zusätzlicher Information
- Bildung von Summenkurven
- Online Ändern von Parameter.

Der Systemgrafikbaustein 8 dient einerseits zur Anzeige aktu eller Leitsystemdaten, beispielsweise Prozeßdaten aus Prozeß abbildern, und andererseits zur Eingabe von neuen Leitsystem werten. So wird beispielsweise die Visualisierung eines Anla genbilds über ein einzelnes Java-Applet durchgeführt. Das Ja va-Applet enthält visuelle und nichtvisuelle Java-Komponen ten, die über bestimmt Eigenschaften parametriert werden. Ei ne zusätzliche Parametrierung des Java-Applets ist nicht not wendig.

Die visuellen Komponenten des Java-Applets werden zur Dar stellung von grafischen Grundelementen wie Linien, Kreisen, Rechtecken und dergleichen, Grafiken und Bedienelementen wie Schaltflächen und dergleichen verwendet. Die nichtvisuellen Komponenten dienen zur Anbindung an bestimmte im jeweiligen Leitsystem gegebene Prozeßvariable.

Die Kommunikation zwischen den einzelnen Komponenten wird über sogenannte Java-Events gesteuert.

Die Netzwerkanbindung an den Server 4 wird über den Client 5 realisiert. Dabei ist eine entsprechende Client-Komponente in dem jeweilen Applet eingebettet.

Fig. 2 ist die Architektur eines Java-Applets zur Visualisie rung einer Systemgrafik, beispielsweise eines Anlagenbildes dargestellt. Ein Ausführungsbeispiel eines solchen Anlagen bildes zeigt Fig. 5. Die TCP/IP-Verbindung zum Server 4 ist in Fig. 2 durch den mit 11 gekennzeichneten Pfeil dargestellt.

Die nichtvisuellen Komponenten dienen zur Anbindung des Anla genbildes an die Prozeßvariablen eines Leitsystems. Dabei ist zu unterscheiden zwischen Elementen bzw. Komponenten zur Aus gabe von Variablenwerten aus dem Leitsystem und Elementen bzw. Komponenten zur Eingabe von Variablenwerten in das Leit system.

Die einzelnen Elemente bzw. Komponenten verfügen über ein heitliche Schnittstellen, die für die Verkettung von einzel nen nichtvisuellen Komponenten ausgelegt sind. Somit können mehrere nichtvisuelle Ausgabekomponenten zu einer Verarbei tungskette zusammengeschlossen werden. Jede Komponente be sitzt einen internen Zustand, der beispielsweise als Double wert verwaltet wird. Über die einzelnen Methoden kann auf diesen internen Zustand lesend und schreibend zugegriffen werden. Für jede nichtvisuelle Komponente muß der Name der jeweiligen Prozeßvariable und der jeweilige Rechnername, auf dem sich das zugehörige Leitsystem befindet, angegeben wer den. Die nichtvisuellen Komponenten werden beim Starten des Applets durch den Client 5 initialisiert. Hierzu wird vom Client ein sogenannter Event abgesetzt, wodurch in den nicht visuellen Komponenten die entsprechende Methode ausgeführt wird. In diese Methode wird die Anmeldung des Elementes bzw. der Komponente für die eingetragene Prozeßvariable durchge führt.

Die Ausgabeelemente bzw. -komponenten umfassen dabei Komponen ten zur Anbindung an eine Datenquelle, Konverter, die eine Umsetzung des Prozeßwerts in einen anderen Wert vornehmen, beispielsweise einen Zahlenwert in einen String wandeln, und Verknüpfer, die eine Verschmelzung von mehreren Prozeßwerten durchführen.

Dabei müssen die folgenden Schnittstellenmethoden von den je weiligen Komponenten implementiert werden:

Eingabemethoden (newVar)

Um den internen Zustand der Ausgabekomponente zu setzen, wer den mehrere newVar Methoden mit unterschiedlichen Übergabepa rametern angeboten. Die Methode newVar mit folgenden Parame tern wird von der Client Komponente aufgerufen, wenn ein neu er Prozeßwert anliegt:
String: Die zugehörige Client-ID, die bei der Anmel dung für diese Prozeßvariable zurückgeliefert wurde.
String: Der neue Wert der Prozeßvariable als String.

Neben diesen Übergabeparametern gibt es die Methode newVar mit anderen Typen bei der Wertübergabe der Prozeßvariable. Der Prozeßwert kann auch als double, float, int oder long übergeben werden.

Ausgabemethoden (getXxxValue)

Um den internen Zustand der Ausgabekomponente auszulesen, stehen unterschiedliche get-Methoden zur Verfügung. Die fol genden Methoden können verwendet werden:
getDoubleValue: Die Methode liefert den internen Zustand als double zurück.
getFloatValue: Die Methode liefert den internen Zustand als float zurück.
getIntValue: Die Methode liefert den internen Zustand als int zurück.
getLongValue: Die Methode liefert den internen Zustand als long zurück.
getStringValue: Die Methode liefert den internen Zustand als String zurück.

Spezielle Ausgabemethoden

Für die Konverter- und Verknüpfungskomponenten existieren spezielle Methoden, um auf die konvertierten und verknüpften Werte zugreifen zu können. Eine genaue Beschreibung dieser Methoden erfolgt bei der entsprechenden Methodenbeschreibung.

Um vom Benutzer über den Client 5 eingegebene Werte an das Leitsystem 2 weiterzuleiten, wird ein Eingabeelement bzw. ei ne Eingabekomponente benötigt. Das Eingabeelement konvertiert den eingegebenen Wert in einen String und schickt ihn mit den benötigten Informationen an den Client, der daraufhin ein Te legramm 10 an den Server 4 verschickt. Der interne Zustand des Eingabeelementes bzw. der Eingabekomponente wird über verschiedene, Übergabeparameter betreffende Methoden beein flußt.

Beispielsweise

SetDoubleValue: Die Methode erhält als Übergabeparameter ei nen double Wert.
setFloatValue: Die Methode erhält als Übergabeparameter ei nen float Wert.
setIntValue: Die Methode erhält als Übergabeparameter ei nen int Wert.
setLongValue: Die Methode erhält als Übergabeparameter ei nen long Wert.
setStringValue: Die Methode erhält als Übergabeparameter ei nen String Wert.

Zusätzlich wird von jeder Methode über den Client 5 ein ent sprechendes Telegramm zum Setzen von variablen Werten abge setzt.

Über die visuellen Komponenten bzw. Elemente werden die ange bundenen Prozeßwerte grafisch dargestellt. Die Darstellung reicht dabei von der reinen textuellen bis hin zu einer sym bolischen Wertedarstellung. Die einzelnen Elemente umfassen dabei primitive, grafische Komponenten, beispielsweise für Kreise, Linien und dergleichen, komplexe grafische Komponen ten, beispielsweise für Bilder und dergleichen, sowie soge nannte GUI-Elemente, beispielsweise Checkboxen, Buttons und dergleichen.

Jede visuelle Komponente bietet spezifische Zugriffsmethoden an, über die das grafische Aussehen der Komponente beeinflußt werden kann.

Die Kommunikation zwischen den visuellen und den nichtvisuel len Elementen bzw. Komponenten wird, wie bereits erläutert, über sogenannte Events gesteuert. Hierzu melden sich Kompo nenten bei anderen Komponenten an. Die Verschaltung wird da bei rein grafisch, beispielsweise mit den entsprechenden Edi toren durchgeführt.

Ändert sich der Wert einer nichtvisuellen Komponente, so wird nach der Wertänderung ein Event generiert. Bei Auslösen die ses Events wird dann überprüft, welche Komponenten sich für diesen Event der erzeugenden Komponente angemeldet haben. Die angemeldeten Komponenten werden über das Auslösen des Events informiert und daraufhin entsprechende Methoden in den jewei ligen Zielkomponenten aktiviert. Über diesen Mechanismus kön nen so umfangreiche Verarbeitungsketten realisiert werden.

Desweiteren lassen sich über Sonderfunktionen, beispielsweise zur Simulation, Daten an die jeweilige Systemgrafik vorgeben, die zur Simulation und damit auch zur Schulung von Benutzern dienen können.

In den Fig. 3, 4 und 5 ist jeweils ein Ausführungsbeispiel für verschiedene Eingabe- und Anzeigeelemente 17 dargestellt, die mittels eines Web-Browsers, dessen Kopfzeile hier mit 16 gekennzeichnet ist, bedienbar und beobachtbar sind.

Die oben aufgezeigten Ausführungsbeispiele dienen der Erläu terung und sind nicht beschränkend.

Claims

1. Verfahren zur Erzeugung einer Oberfläche zum Bedienen und Beobachten von Leitsystemen (2), insbesondere für Prozeß- und Produktionsanlagen, wobei im Bereich von Leitsystemen (2) an fallende Informationen von einem an wenigstens ein Leitsystem (2) adaptierbaren Server-Rechner (1) über ein Client-Server- Rechner-Netzwerk auf einem Client-Rechner (5) in Eingabe- und Anzeigeelementen (19) viusalisiert werden.

2. Verfahren nach Anspruch 1, dadurch ge kennzeichnet, daß die Eingabe- und Anzeigeele mente (19) frei parametrierbar und konfigurierbar sind.

3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, daß das Client-Server-Rech ner-Netzwerk ein Intra- und/oder Internet ist.

4. Verfahren nach einem oder mehreren der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die Visualisierung mittels eines Web-Browsers (18) erfolgt.

5. Verfahren nach einem oder mehreren der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß die Ein gabe- und Anzeigeelemente (19) vom Client-Rechner (5) gene riert werden.

6. Verfahren nach einem oder mehreren der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß die Ein gabe- und Anzeigeelemente (19) mittels Java-Applets generiert werden.

7. Verfahren nach einem oder mehreren der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß die Ein gabe- und Anzeigeelemente (19) mittels Java-Beans generiert werden.

8. Verfahren nach einem oder mehreren der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß die Ein gabe- und Anzeigeelemente (19) Meldungen, Kurvenverläufe und/ oder Systemgrafiken umfassen.