DE10151119C2 - Verfahren zum Erfassen von mehreren Feldgeräten in einer Gerätekonfiguration - Google Patents

Description

Die Erfindung liegt auf dem Gebiet des ferngesteuerten Betreibens von Feldgeräten, insbesondere zum Zweck des Beo­ bachtens und Bedienens von Feldgeräten.

Feldgeräte werden im Rahmen der Automatisierung von verschie­ densten technischen Prozessen genutzt, beispielsweise zum Ü­ berwachen eines Produktions- bzw. Herstellungsprozesses oder eines Verarbeitungsprozesses. Bei den Feldgeräten kann es sich um die Produktionsanlagen selbst oder um Geräte zum Ü­ berwachen, vorzugsweise zum Steuern und/oder zum Regeln in Abhängigkeit von erfassten Felddaten, der eingesetzten, tech­ nischen Produktionsmittel bzw. -anlagen handeln.

Die Feldgeräte werden hierbei häufig in Sternkoppler-Konfi­ gurationen angeordnet, in denen Übertragungsprotokolle auf der Basis einer Master-Slave-Architektur genutzt werden. Zum Betreiben der Feldgeräte in der Sternkoppler-Konfiguration müssen die Feldgeräte, welche als Slave-Geräte an eine Mas­ ter-Gerät angeschlossen sind, erkannt werden, so dass die Feldgeräte über eine jeweilige Adresse von dem Master-Gerät elektronisch angesteuert werden können.

Aus der deutschen Offenlegungsschrift DE 197 33 906 A1 ist beispielsweise bekannt, in einem Bussystem eine automatische Adressvergabe an seriell angeordnete Kommunikationsteilnehmer (Slaves) durchzuführen. Dazu wird von einem Mastergerät eine so genannte Präambel ausgesendet, die von den an den Master angeschlossenen Slaves empfangen wird. Jedes Slave-Gerät sen­ det daraufhin eine Antwort aus. Dasjenige Slave-Gerät, das selbst keine Antwort von den übrigen Slave-Geräten empfängt, ist das letzte in der seriellen Anordnung und wird zum Ad­ resserhalt aktiviert. Während darauffolgender, weiterer Adressvergaben nimmt das solchermaßen getaufte Gerät nicht mehr teil.

Ferner ist aus der DE 693 19 059 T2 ein Verfahren zur Adress­ vergabe an Endgeräte, insbesondere Kabelfernsehgeräte, be­ kannt, bei dem von einem Server kontinuierlich eine zu verge­ bende, provisorische Adresse rundgesendet wird. Detektiert ein neu angeschlossenes Endgerät diese provisorische Adresse, sendet es eine Bestätigung an den Server zurück.

Außerdem ist in der japanischen Patentschrift JP 07 231329 A ein Verfahren beschrieben, bei dem ein in einem Sternnetzwerk neu hinzukommender Slave vom Master eine unbesetzte Adresse aus einer Adresstabelle zugewiesen bekommt.

Bei bekannten Sternkoppler-Konfigurationen werden auf der Master-Slave-Architektur basierende Übertragungsprotokolle genutzt. Adresskollisionen sind bei diesen Protokollen ver­ hindert.

Praktisch alle bekannten Protokolle zur seriellen Ankopplung von Schutz- bzw. Feldgeräten basieren auf einer im Norment­ wurf E DIN 19244 festgelegten Linkschicht. Dieser Norment­ wurf wurde zur europäischen Norm IEC 870-5 weiterentwickelt. Die europäische Norm definiert neben der Linkschicht auch die Protokolle zur Feldgeräteankopplung bzw. -erkennung in Verbindung mit einer Stationsleittechnik oder einem Fernwirksys­ tem.

Der Funktionsweise eines Master-Slave-Protokolls entsprechend wird vom Master bzw. Master-Gerät eine Anforderung an ein be­ stimmtes der Slave-Geräte erzeugt. Auf die Anforderung ant­ wortet nur das bestimmte Slave-Gerät. Alle anderen an das Master-Gerät angeschlossenen Slave-Geräte verhalten sich still. Da an den Sternkoppler i. d. R. nur ein Master-Gerät angeschlossen ist, kann auf diese Weise erreicht werden, dass ein serieller Übertragungskanal zwischen dem Sternkoppler und den Slave-Geräten immer nur von einem der Slave-Geräte belegt wird. Zusätzliche Schaltungskomponenten für die Arbitrierung der Verbindung sind nicht erforderlich.

Um das Master-Gerät in die Lage zu versetzen, alle vom Mas­ ter-Gerät zu verwaltenden Slave-Geräte ansprechen zu können, benötigt das Master-Gerät eine Liste der angeschlossenen Sla­ ve-Geräte. Dem Master-Gerät müssen also alle angeschlossenen Slave-Geräte bekannt sein. Nur wenn diese Voraussetzung er­ füllt ist, können die Slave-Geräte über ihre Adresse ange­ sprochen werden. Da die Parametrierung der Fernwirk- bzw. Stationsleittechnik-Master zeitaufwendig und komplex ist, entstehen durch diese Tätigkeiten ein erheblicher Zeitaufwand und Kosten.

Aufgabe der Erfindung ist es, ein verbessertes Verfahren zum Erkennen von angeschlossenen Feldgeräten zu schaffen, welches auch im Zusammenhang mit einer hohen Anzahl von Adressabfra­ gemöglichkeiten ein Zeit- und kostengünstiges Arbeiten ermög­ licht.

Diese Aufgabe wird durch das Verfahren nach Anspruch 1 ge­ löst.

Ein wesentlicher Gedanke der Erfindung besteht darin, Teilbe­ reiche eines Gesamtadressbereichs mit einer einzigen Anfrage nach dem Vorhandensein von Feldgeräten in dem jeweiligen Teilbereich abzufragen. Hierbei ist es zunächst nicht notwen­ dig, die Feldgeräte mit ihrer jeweiligen Adresse anzusprechen. Es können auch mehrere Feldgeräte auf eine Anfrage antworten. Dieses wird bewusst in Kauf genommen. Mit der sukzessiven, gezielten Verminderung der abgefragten Teilbereiche werden dann die Adressen der angeschlossenen Feldgeräte im weiteren Verlauf des Verfahrens automatisch erkannt.

Aus der deutschen Offenlegungsschrift DE 195 44 027 A1 ist zwar ein Bussystem, insbesondere für die Hausinstallation, bekannt, bei dem zur Vereinfachung des Aufbaus bewusst eine Kommunikations-Kollision mehrerer Busteilnehmer in Kauf ge­ nommen wird; allerdings findet hier in keiner Weise eine Ad­ resserkennung oder -zuweisung statt.

Ferner ist aus "Algorithmen und Datenstrukturen mit Modula-2" (Wirth, N.; B. G. Teubner-Verlag, Stuttgart, 4. Auflage, 1986, Seiten 56-58) ein binäres Suchverfahren bekannt, bei dem zur Ermittlung eines Objektes aus einem Suchbereich im optimalen Fall die Mitte des Bereichs gewählt wird und eine Aussage darüber getroffen wird, ob sich das Objekt in der oberen oder unteren Hälfte befindet. Mit diesem Verfahren kann jedoch nur jeweils ein einzelnes Objekt ermittelt werden; eine Erfassung mehrer Adressen in einer Gerätekonfiguration kann mit diesem Verfahren nicht erfolgen.

Bei einer vorteilhaften Weiterbildung der Erfindung ist vor­ gesehen, dass die jeweilige elektronische Adresse der Feldge­ räte eine Binär-Adresse ist, so dass die Hälfte des Adressab­ fragebereichs und die verbleibende Hälfte des Adressabfrage­ bereichs mit Hilfe des Festlegens eines Messbits auf einen Wert 0 bzw. 1 gebildet werden, wodurch die Aufteilung des Ge­ samtadressbereichs auf einfache Weise und mit geringem Zeit­ aufwand möglich ist.

Wenn die Adressen als Binär-Adressen ausgebildet sind, werden beim elektronischen Abfragen jeweils das Messbit und eine Bit-Maske an die Feldgeräte übermittelt werden, wobei die Bit-Maske Bits umfasst, die von den Feldgeräten nicht ausge­ wertet werden, d. h. unbeachtet bleiben.

Zum Auffinden der Adresse der Feldgeräte wird die Bit-Maske beim n-maligen Wiederholen der elektronischen Abfrage in auf­ einanderfolgenden Wiederholungen stets um ein Bit verkürzt. Das n-malige Wiederholen wird abgebrochen, wenn die Bit-Maske keine Bits mehr umfasst, d. h. die elektronische Abfrage um­ fasst die genaue Adresse des angesprochenen Feldgeräts.

Ein zweckmäßige Fortbildung der Erfindung sieht vor, dass die erfassten, elektronischen Antworten bzw. die anderen elektro­ nischen Antworten in dem Zentral-Gerät mittels eines ODER- Gatters elektronisch verarbeitet werden, wodurch mit geringem Schaltungsaufwand erkannt werden kann, ob in einem Abfragead­ ressbereich Feldgeräte anliegen.

Bei einer vorteilhaften Ausführungsform der Erfindung ist vorgesehen, dass elektronische und/oder andere elektronische Antworten erfasst werden, die zeitlich kollidieren, derart, dass sie im wesentlichen gleichzeitig bei dem Zentral-Gerät eingehen. Eine Erkennung der zeitlichen Kollision von Ant­ worten der Feldgeräte ist deshalb nicht notwendig, wodurch der schaltungstechnische Aufwand möglichst gering gehalten werden kann. Es ist ausreichend, zu erkennen, ob überhaupt eine Antwort vorlag.

Um das Verfahren zum Erkennen der angeschlossenen Feldgeräte hinsichtlich der benötigten Zeit möglichst effizient zu ges­ talten, kann bei einer bevorzugten Ausgestaltung der Erfin­ dung vorgesehen sein, dass das Erfassen der elektronischen Antwort von dem wenigstens einen der Feldgeräte aus der Hälf­ te des Adressabfragebereichs und das Erfassen der anderen e­ lektronischen Antwort von dem wenigstens einen anderen der Feldgeräte aus der verbleibenden Hälfte des Adressabfragebe­ reichs mittels des Zentral-Geräts auf einen vorbestimmten Zeitraum nach einem Absenden der einzelnen elektronischen bzw. nach einem Absenden der weiteren einzelnen, elektroni­ schen Anfrage begrenzt werden.

Das Verfahren kann vorteilhaft in Verbindung Steuerungs- /Fernwirksystemen von energietechnischen Anlagen verwendet werden.

Das Verfahren und/oder die Vorrichtung können vorteilhaft zum Überwachen energietechnischer Anlagen verwendet werden.

Die Erfindung wird im folgenden anhand von Ausführungsbei­ spielen unter Bezugnahme auf eine Zeichnung näher erläutert.

Hierbei zeigen:

Fig. 1 eine schematische Darstellung mit einem Gerätenetzwerk und einem Firmen-Intranet, die über einen Proxyserver verbunden sind;

Fig. 2 eine Oberflächengestaltung einer Browser- Einrichtung mit grafischen Darstellungen für mehre­ re Feldgeräte;

Fig. 3 eine andere Oberflächengestaltung der Browser- Einrichtung mit einer grafischen Darstellung einer Frontansicht eines Feldgeräts;

Fig. 4 eine schematische Darstellung eines Feldgeräts und eines Nutzer-Personalcomputers;

Fig. 5 ein. Ablaufdiagramm für ein Herunterladen von HTML- Seiten im Rahmen eines Beobachtungs- und Bediensys­ tems;

Fig. 6 ein Blockdiagramm zum Erläutern eines RPC-Aufrufs;

Fig. 7 eine Darstellung der Anordnung mit dem Gerätenetz­ werk und dem Firmen-Intranet nach Fig. 1, wobei einzelne Elemente des Proxyservers schematisch ge­ zeigt sind;

Fig. 8 eine schematische Blockdarstellung des Proxyser­ vers;

Fig. 9 eine schematische Darstellung zur Erläuterung einer Client/Server-Interaktion;

Fig. 10 eine schematische Darstellung zur Erläuterung einer Geräteerkennung in einer Master/Slave-Anordnung;

Fig. 11 ein Nassi-Schneidermann-Diagramm;

Fig. 12 eine schematische Baumdarstellung eines Verfahrens zur Geräteerkennung;

Fig. 13 eine schematische Darstellung einer Master/Slave- Anordnung zur Erläuterung einer Konfigurationsab­ frage;

Fig. 14 ein schematische Blockdarstellung einer Gerätver­ waltung im Proxyserver;

Fig. 15 eine schematische Blockdarstellung zur Erläuterung der funktionellen Einbindung eines XSL-Parsers in dem Proxyserver (XSL - "EXtended Stylesheet Langua­ ge"), und

Fig. 16 eine schematische Blockdarstellung zur Erläuterung eines XSLT-Prozessors (XSLT - "EXtended Stylesheet Language Transformations").

Im folgenden wird ein in Verbindung mit Feldgeräten nutzbares, sogenanntes Beobachtungs- und Bediensystem (BuB-System) be­ schrieben.

Fig. 1 zeigt eine schematische Architektur von zwei Netzwer­ ken, ein Gerätenetzwerk mit mehreren Feldgeräten FG1 . . . FGN und ein Firmen-Intranet mit mehreren Nutzereinrichtungen N1 . . . NN, vorzugsweise Personalcomputer (PC). Das Gerätenetz­ werk und das Firmen-Intranet sind über einen Proxyserver 1 verbunden. Der Proxyserver 1 ist Bestandteil des Beobach­ tungs- und Bediensystems und dient als ein Gateway zwischen dem Gerätenetzwerk und dem Firmen-Intranet. Mit Hilfe des BuB-Systems werden einerseits Informationen, beispielsweise Mess- und/oder Zustandsdaten, von den Feldgeräten FG1 . . . FGN erfasst und an die Nutzereinrichtungen N1 . . . NN übermittelt, um einen Benutzer der Nutzereinrichtungen N1 . . . NN über den Betriebszustand der Feldgeräte FG1 . . . FGN zu informieren. An­ dererseits dient das BuB-System zum Erfassen von Bedien- bzw. Steuereingaben des Benutzers mit Hilfe der Nutzerein­ richtungen N1 . . . NN und zum Umsetzen der Eingaben des Benut­ zers in den Feldgeräten FG1 . . . FGN. Bei den Feldgeräten FG1 . . . FGN kann es sich um beliebige Geräte zum Beobachten, zum Messen, zum Steuern und/oder zum Regeln verschiedenster physikalischer Größen in unterschiedlichen, technischen Pro­ zessen handeln, beispielsweise zum Überwachen und/oder Steu­ ern energietechnischer Anlagen, beispielsweise eines Umspann­ werks.

Das Gerätenetzwerk umfasst einzelne PPP-Verbindungen 2 (PPP - "Point to Point Protocol"), die über einen Sternkoppler 3 mit dem Proxyserver 1 verbindbar sind, oder ein separates E­ thernet-Segment. Der Proxyserver 1 stellt eine eigene Home­ page in Form von HTML-Daten (HTML - "HyperText Markup-Langua­ ge") zur Verfügung, die eine Übersicht über die in dem Gerä­ tenetzwerk erreichbaren Feldgeräte FG1 . . . FGN zeigt (vgl. Fig. 2); die Homepage kann mit Hilfe eines Standard-Browsers in den Nutzereinrichtungen N1 . . . NN dargestellt werden.

Gemäß Fig. 1 sind die Feldgeräte FG1 . . . FGN nur mit dem Sternkoppler 3 und einem daran angeschlossenen Modem 4 aus­ gestattet. In diesem Fall sind die Feldgeräte FG1 . . . FGN über eine asynchrone, serielle Schnittstelle direkt über den Stern­ koppler 3 mit dem Modem 4 verbunden. Es sind verschiedene Formen der Ankopplung über aktive und passive Sternkoppler möglich. Als Protokoll für den Zugriff auf die Feldgeräte FG1 . . . FGN wird ein IP-Protokoll (IP - "Internet Protocol") über eine PPP-Linkschicht verwendet.

Wenn die Feldgeräte FG1 . . . FGN mit einem Ethernet-Anschluss ausgestattet sind, sind die Ethernet-Anschlüsse mit einem Switch oder einem Hub verbunden. Besitzt dieser Switch oder dieser Hub neben Ethernet-Ports auch einen PPP-Port, dann spricht man von einem Router. Dieser PPP-Port kann dann e­ benfalls direkt mit dem Modem 4 verbunden werden.

Im Firmen-Intranet haben die an das lokale Netz angeschlosse­ nen Nutzereinrichtungen N1 . . . NN Zugang zu einem Modem 5, wel­ ches über ein Telekommunikationsnetz 6, beispielsweise ein Telefonnetz auf Basis eines ISDN- oder eines Mobilfunk- Netzes, mit dem Modem 4 des Gerätenetzwerk verbindbar ist. Wird in den Nutzereinrichtungen N1 . . . NN jeweils eine DFÜ- Verbindung (DFÜ - Datenfernübertragung) eingerichtet, kann von den Nutzereinrichtungen N1 . . . NN aus jeweils ein Zugriff auf die Feldgeräte FG1 . . . FGN erfolgen. Wird nun der Proxy­ server 1 von den Nutzereinrichtungen N1 . . . NN angesprochen, kann von jeder der an das Firmen-Intranet angeschlossenen Nutzereinrichtungen N1 . . . NN auf die Feldgeräte FG1 . . . FGN zum Beobachten und Bedienen zugegriffen werden. Der Proxyserver 1 "spiegelt" alle Feldgeräte FG1 . . . FGN, d. h. Informationen über die Feldgeräte FG1 . . . FGN, ins Firmen-Intranet. Dazu werden vom Proxyserver 1 die folgenden Protokolle verarbei­ tet: HTTP-Protokoll (HTTP - "Hypertext Transfer Protocol" und RPC-Protokoll (RPC - "Remote Procedure Call"). Das HTTP- Protokoll dient zur Übertragung statischer Daten. Hierbei handelt es sich um Daten, die nur einmalig an den Proxyserver 1 übertragen werden und anschließend dort in einem Dateispei­ cher für spätere Abrufe durch die Nutzereinrichtungen N1 . . . NN abgelegt werden. Das RPC-Protokoll, welches ebenfalls ein IP-basiertes Protokoll ist, wird zum Übertragen dynamischer Daten genutzt. Bei den dynamischen Daten handelt es sich insbesondere um in den Feldgeräten FG1 . . . FGN erfasste Mess­ werte und/oder Ereignislisten, betreffend Informationen über Ereignisse in den Feldgeräten FG1 . . . FGN.

Das HTTP-Protokoll gestattet den Nutzereinrichtungen N1 . . . NN den Zugriff auf die Feldgeräte FG1 . . . FGN. Bei einem Zugriff im Rahmen des BuB-Systems werden zunächst mittels der Anwahl der zugehörigen IP-Adresse des zu bedienenden/beobachtenden Feldgeräts HTML-Daten von dem Feldgerät an die in diesem An­ wendungsfall genutzte Nutzereinrichtung übermittelt, wobei die HTML-Daten Daten umfassen, mit deren Hilfe in der Brow­ ser-Einrichtung der abrufenden Nutzereinrichtung eine Darstellung des Feldgeräts erzeugt werden kann, wie dies bei­ spielhaft in Fig. 3 dargestellt ist. Der Abruf der HTML- Daten zum Erzeugen der Darstellung gemäß Fig. 3 kann mit Hilfe einer Auswahl eines der in Fig. 2 in der Übersicht dargestellten Feldgeräte durch den Benutzer ausgelöst werden, beispielsweise mittels der Betätigung einer Maus oder einer Tastatur der Nutzereinrichtung.

Gemäß Fig. 3 sind auf der Oberfläche 20 der Browser- Einrichtung die folgenden Informationen dargestellt (vgl. linke Seite in Fig. 3): Feldgerätefamilie (z. B. SIPROTEC4), Feldgeräteart und Feldgerätetyp 21, ein Bedienbaum 22, die Version des BuB-Tools 23 (Version und Datum) und Angaben zur Verbindung 24 mit dem Feldgerät (MLFB - "Maschinenlesbare Fabrikationsbezeichnung", BF-Nummer, Verbindungsstatus und IP-Adresse). Auf der Oberfläche ist weiterhin die einem Link bzw. Zweig im Bedienbaum 22 zugeordnete HTML-Seite 25 ange­ zeigt. In Abhängigkeit von dem im Bedienbaum 22 ausgewählten Link wird die zugehörige HTML-Seite 25 auf der Oberfläche 20 der Browser-Einrichtung dargestellt.

Die in den Feldgeräten FG1 . . . FGN abgelegten HTML-Seiten, d. h. auch die zur Erzeugung der in Fig. 3 gezeigten Darstellung genutzte HTML-Seite 25, können Java-Code umfassen, der die Browser-Einrichtung der jeweiligen Nutzereinrichtung N1 . . . NN dazu veranlasst, parallel zu der bestehenden HTTP-Verbindung zur Darstellung der aus den Feldgeräten FG1 . . . FGN geladenen HTML-Seite eine weitere Verbindung mit den Feldgeräten FG1 . . . FGN aufzubauen. Diese zweite Verbindung benutzt das RPC-Protokoll, um dynamische Daten, wie Ereignislisten oder Messwerte, aus den Feldgeräten FG1 . . . FGN besonders schnell und effektiv für die Darstellung in den Nutzereinrichtungen N1 . . . NN innerhalb einer angewählten HTML-Seite, beispielswei­ se der in Fig. 3 gezeigten HTML-Seite 25, zu übertragen.

Informationsabruf aus den Feldgeräten

Fig. 4 zeigt eine schematische Darstellung zur näheren Er­ läuterung des Abrufens der Informationen im Rahmen des BuB- Systems von den Feldgeräten FG1 . . . FGN in die Nutzereinrich­ tungen N1 . . . NN.

Gemäß Fig. 4 ist auf einem Nutzer-Personalcomputer 30, der eine beispielhafte Ausbildung der Nutzereinrichtungen N1 . . . NN darstellt, eine Browser-Einrichtung 31 installiert. Der Nut­ zer-Personalcomputer 30 ist über ein IP-Netzwerk 32, welches den Proxyserver 1, den Sternkoppler 3, das Modem 4, das Modem 5 sowie das Telekommunikationsnetzwerk 6 umfassen kann, mit einem Feldgerät 33 verbunden. Das Feldgerät 33 weist einen HTTP-Server 34 auf. In dem Feldgerät 33 sind HTML-Seiten 35 gespeichert, die für dieses Feldgerät 33 spezifische Informa­ tionen umfassen. Die HTML-Seiten 35 enthalten beispielsweise eine HTML-Darstellung der Frontansicht des Feldgeräts 33. Die HTML-Seiten 35 sind speziell auf das Feldgerät 33 abgestimmt und können mittels eines HTTP-Herunterladens vom HTTP-Server 34 des Feldgeräts 33 durch den Nutzer-Personalcomputer 30 ab­ gerufen werden. Die Anforderung der HTML-Seiten 35 aus dem Feldgerät 33 kann mittels der Eingabe einer URL (URL - "Uni­ form Resource Locator") in der Browser-Einrichtung 31 oder mittels der Referenz aus einer anderen HTML-Seite heraus ("Link") ausgelöst werden. Neben den HTML-Seiten 35 werden vom Feldgerät 33 eine Reihe von Rohdaten 36 (Messwerte, Para­ meter, etc.) in Form von Dateien bereitgestellt. In den HTML-Seiten 35 befinden sich Referenzen auf die im Feldgerät 33 verfügbaren Rohdaten 36. Sollen die Rohdaten 36 ausgewer­ tet oder in sonstiger Weise verändert werden, wird ein Pro­ gramm benötigt, welches nach bestimmten Algorithmen hochwer­ tige Datenformate erzeugen kann. Diese Datenformate können dann von dem Programm beispielsweise zur Bildschirmanzeige in Verbindung mit Analysemöglichkeiten verwendet werden. Die hierfür notwendige Rechenleistung steht in dem Feldgerät 33 in der Regel nicht zur Verfügung. Mit Hilfe der Browser- Einrichtung 31 besteht für den Anwender die Möglichkeit, un­ ter Nutzung des IP-Netzwerks 32 über Kommunikationsverbindungen (Modem, Telefonnetze, LAN - "Local Area Network", WAN - "Wide Area Network") auf die HTML-Seiten 35 aus dem Feldgerät 33 und damit auch auf die hierin referenzierten Rohdaten 36 des Feldgeräts 33 zuzugreifen. Gemäß Fig. 5 wird (werden) zu diesem Zweck mit Hilfe der Browser-Einrichtung 31 zunächst die HTML-Seite(n) 35 von dem Nutzer-Personalcomputer 30 ange­ fordert. Nachdem der HTTP-Server 34 des Feldgeräts 33 die HTML-Seite(n) 35, einschließlich der hierin enthaltenen Refe­ renzen auf die Rohdaten 36, bereitgestellt hat, werden die HTML-Seite 35 und die Rohdaten 36 an den Nutzer-Personal­ computer 30 übertragen. Hierbei werden die HTML-Seite 35 und die Rohdaten 36 mittels getrennter Protokolle zwischen dem Feldgerät 33 und dem Nutzer-Personalcomputer 30 übertragen, vorzugsweise HTTP- bzw. RPC-Protokoll. In dem Nutzer- Personalcomputer 30 können die Rohdaten 36 dann mit geeigne­ ten Programmen verarbeitet werden. Zum Ausführen des RPC- Protokolls umfasst das Feldgerät 33 zusätzlich einen RPC- Server 34a.

Beim Herunterladen der HTML-Seite 35 vom HTTP-Server 34 kön­ nen die referenzierten Dateien der Rohdaten 36 automatisch mit geladen werden. Der Aufruf aus der HTML-Seite 35 kann wie folgt aussehen: <EMBED SRC="rawdata.ext"<. Mit dem Para­ meter "SRC" wird die Datei mit den Rohdaten 36 des Feldgeräts 33 referenziert. Außerdem kann das Herunterladen der Rohdaten 36 auch über einen vom Benutzer zu aktivierenden Link auf der HTML-Seite 35 ausgelöst werden. Für diesen Fall könnte der Aufruf in der HTML-Seite 35 wie folgt aussehen:

<a href="rawdata.ext" type="mime type"<link</a<.

Damit die Browser-Einrichtung 31 das richtige Programm zur Weiterverarbeitung der Rohdaten 36 starten kann, muss der Browser-Einrichtung 31 der Inhaltstyp der Rohdaten 36 mitge­ teilt werden. Hierfür gibt es je nach verwendetem Betriebs­ system des Nutzer-Personalcomputers 30 und genutzter Browser- Einrichtung 31 unterschiedliche Vorgehensweisen. Es kann so­ wohl die Dateierweiterung (beispielsweise "*.ext") als auch der vom HTTP-Server 34 mitgelieferte MIME-Typ (MIME - "Multi­ purpose Internet Mail Extension") ausgewertet werden. Das von der Browser-Einrichtung 31 gestartete Programm zur Rohda­ tenverarbeitung übernimmt die Konvertierung der heruntergela­ denen Rohdaten 36. Das Programm zur Rohdatenverarbeitung kann als Browser-PlugIn, als Active X-Komponente oder als ex­ ternes Programm realisiert werden.

Hierbei ist zwischen verschiedenen Typen von Rohdaten zu un­ terscheiden. Die Verarbeitung von sporadisch entstehenden Rohdaten 36 wird vorzugsweise mit Hilfe eines Browser- PlugIn's oder einer Active X-Komponente vorgenommen. In die­ sem Zusammenhang erfolgt der Zugriff auf die Daten mit Hilfe des TCP-Protokolls. Sollen sich ständig aktualisierende Roh­ daten 36 in Form eines Endlos-Datenstroms verarbeitet werden, dann ist es sinnvoll, ein effektiveres Protokoll für die Ü­ bertragung an den Nutzer-Personalcomputer 30 (den Nutzerein­ richtungen N1 . . . NN) zu verwenden. Mit Hilfe des zusätzlichen RPC-Protokolls wird eine Auftrennung der in den Nutzerein­ richtungen N1 . . . NN (bzw. dem Nutzer-Personalcomputer 30) dar­ zustellenden Informationen über das (die) Feldgerät(e) FG1 . . . FGN bzw. 33 in statische und dynamische Informationen ermöglicht. Die statischen Informationen werden mit dem HTTP- Standardprotokoll übertragen, während die dynamischen, also veränderlichen Daten über das effektivere RPC-Protokoll über­ tragen werden. Der Aufwand, der beim Senden der dynamischen Daten mittels des HTTP-Protokolls durch Verbindungsaufbau/- abbau und Verbindungsüberwachung entstehen würde, würde den des ereignisabhängigen, wiederholten Sendens der dynamischen Daten mittels des RPC-Protokolls übersteigen. Da in der Re­ gel nur wenige Daten schnell übermittelt werden sollen (Mess­ werte, Meldelisten, . . .), ist der Einsatz eines verbindungs­ losen Protokolls, insbesondere des RPC-Protokolls, für die dynamischen Daten vorteilhaft. Bei einem Aufruf entfernter Prozeduren (RPC - "Remote Procedure Call") ruft ein lokales Programm eine Prozedur auf einem entfernten System auf. Das Konzept des entfernten Prozeduraufrufs sorgt dafür, dass der gesamte Netzcode in der RPC-Schnittstelle und in den Netzrou­ tinen verborgen bleibt. Damit wird vermieden, dass sich die Applikationsprogramme (Client und Server) um Details, wie z. B. Konvertierung EBCDIC <---< ASCII, Zahlenkonvertierung, Socket, Session etc., kümmern müssen. Ein Ziel von RPC ist die Vereinfachung der Implementierung von verteilten Anwen­ dungen. UDP (UDP - "User Defined Protocol") wird von einigen Anwendungen, die nur kurze Nachrichten senden und diese wie­ derholen können, verwendet. UDP ist daher ein ideales Proto­ koll zur Verteilung von Informationen, die sich ständig än­ dern, wie beispielsweise Börsenkurse. Statt die Daten in einen TCP-Umschlag zu packen und dann in den IP-Umschlag, wandern sie jetzt in einen UDP-Umschlag, bevor sie in den IP-Umschlag kommen. Obwohl UDP in der gleichen Schicht wie das verbin­ dungsorientierte TCP beheimatet ist, handelt es sich um ein verbindungsloses Protokoll. Der Einsatz des UDP-Protokolls erscheint immer dann sinnvoll, wenn nur wenige Daten schnell übermittelt werden sollen. So gibt es in Anwendungsprogrammen zwischen Client und Server einen Austausch von kurzen Anfra­ gen und Antworten. Hier würde der Aufwand der durch Verbin­ dungsaufbau/-abbau und Verbindungsüberwachung entsteht, den des erneuten Sendens der Daten übersteigen. Das getrennte Ü­ bertragen von statischen und dynamischen Daten zwischen den Feldgeräten FG1 . . . FGN im Gerätenetzwerk und den Nutzerein­ richtungen N1 . . . NN im Firmen-Intranet mit Hilfe unterschied­ licher Protokolle wird durch das Vorsehen und die spezifische Ausbildung des später im Detail beschriebenen Proxyservers 1 optimiert.

Im folgenden wird die Nutzung des RPC-Protokolls zum Abrufen der dynamischen Daten in einer Client/Server-Anordnung (Nut­ zereinrichtungen N1 . . . NN/Feldgeräte FG1 . . . FGN) anhand der schematischen Darstellung in Fig. 6 beschrieben.

Ein RPC-Aufruf läuft beispielsweise wie folgt ab:

• a) Ein innerhalb des Browsers 31 (vgl. Fig. 4) ablaufender Client-Prozess 100 ruft eine RPC-Schnittstelle 101 auf. Dieser Client-Prozess 100 kann z. B. ein in eine HTML- Seite eingebettetes Java-Applet sein. Die RPC- Schnittstelle 101 hat die Aufgabe, den Unterprogrammein­ sprung zu spezifizieren. Die Spezifikation enthält den Namen der Funktion sowie Anzahl und Typen der Parameter. Hiermit wird ein logischer Einsprung definiert. Die RPC- Schnittstelle 101 ermöglicht das Starten der entfernt liegenden Prozedur 102.
• b) Die Parameter des Client-Prozesses 100 werden von der RPC-Schnittstelle 101 gelesen. Der Zweck der RPC- Schnittstelle 101 liegt in der Verpackung und Konvertie­ rung der Parameter für das Serverprogramm.
• c) Die Netzroutinen versenden die Nachrichten an einen Ser­ ver-Prozess 103, der im RPC-Server 34a abläuft.
• d) Eine RPC-Schnittstelle 104 des Server-Prozesses 103 baut die Parameter aus den Nachrichtenpaketen wieder auf.
• e) Im nächsten Schritt wird das Serverprogramm aufgerufen. Dazu wird ein Serverstub definiert. Dieser Stub ist der eigentliche Einsprung in die auf dem Server-Prozess 103 liegende Prozedur.
• f) Nach Abarbeitung der Prozedur wird die Kontrolle wieder an die RPC-Schnittstelle 104 gegeben.
• g) Die Schnittstelle 104 verpackt die Rückgabeparameter und transportiert die Daten anschließend zu den Netzroutinen.
• h) Die Netzroutinen transportieren die Daten über netzwerk­ abhängige Aufrufe auf den Client-Prozess 100.
• i) Die RPC-Schnittstelle 101 des Client-Prozesses 100 ent­ packt die Parameter und versorgt die angegebenen Parame­ ter mit den neuen Daten.
• j) Die Kontrolle wird an den Client-Prozess 100 zurückgege­ ben, der die erhaltenen Daten weiterverarbeiten kann.

Das Konzept des entfernten Prozeduraufrufs sorgt dafür, dass der gesamte Netzcode in der RPC-Schnittstelle und in den Netzroutinen verborgen bleibt. Damit wird vermieden, dass sich die Applikationsprogramme (Client und Server) um De­ tails, wie z. B. Konvertierung EBCDIC <---< ASCII, Zahlenkonvertierung, Socket, Session etc., kümmern müssen. Ein Vor­ teil der Nutzung des RPC-Protokolls für die dynamischen Daten ist die Vereinfachung der Implementierung von verteilten An­ wendungen.

Bedienen der Feldgeräte

Der in Verbindung mit Fig. 4 beschriebene Abruf von Informa­ tion von dem Feldgerät 33, welches den HTTP-Server 34 um­ fasst, kann auch in Verbindung mit Handlungen im Rahmen des Beobachtungs- und Bediensystems genutzt werden, die zum Zweck des Bedienens des Feldgeräts 33 ausgeführt werden. Hierdurch ist es ermöglicht, das Feldgerät 33 mit Hilfe der Browser- Einrichtung 31 zu bedienen. Dieses wird im folgenden näher beschrieben.

Das Feldgerät 33 enthält eine Speichereinrichtung 35a, in welcher Bediensoftware in Form von HTML-Seiten 35 gespeichert ist, und ein Java-Archiv oder Daten, aus denen HTML-Seiten erzeugbar sind. Die Bediensoftware ist speziell auf das Feldgerät 33 zugeschnitten. Mittels der Eingabe der URL- Adresse des Feldgeräts 33 durch den Nutzer startet ein HTTP- Herunterladen, was zum Herunterladen der Bediensoftware vom HTTP-Server 34 des Feldgeräts 33 in den Nutzer-Personal­ computer 30 führt. Nach dem Herunterladen der Bediensoftware von dem Feldgerät 33 auf den Benutzer-Personalcomputer 30 in Form der HTML-Seite(n) 35 wird die Vorderansicht des Feldge­ räts 33 mit allen Bedien- und Anzeige-Elementen innerhalb der Browser-Einrichtung dargestellt (vgl. Fig. 3). Der Benutzer kann dann bestimmte Bedienfunktionen des Feldgeräts 33 mit Hilfe eines Mausklicks auf dem Bildschirm des Benutzer- Personalcomputers 30 auslösen. Die Übermittlung der Benut­ zerhandlung zum Feldgerät 33 erfolgt mittels eines schnellen und effektiven Protokolls, das einerseits die genannten Be­ dienanforderungen vom Benutzer-Personalcomputer 30 zum Feld­ gerät 33 überträgt und andererseits Reaktionen des Feldgeräts 33 zurückliest. Zu diesem Zweck werden die internen Bedien- und Anzeigefunktionen des Feldgeräts 33 zur Schnittstelle der Browser-Einrichtung 31 hin veröffentlicht, z. B. Tastaturpuf­ fer, Displaypuffer, LED-Status.

Im Rahmen der Bedienung durch den Benutzer gibt es zwischen Benutzer-Personalcomputer 30 und dem Feldgerät 33 einen Aus­ tausch von kurzen Anfragen und Antworten im Rahmen eines Client-Server-Verhältnisses. Hierbei würde der Aufwand, der im Zusammenhang mit dem Aufbau/Abbau und der Überwachung der HTTP-Verbindung zwischen dem Benutzer-Personalcomputer 30 und dem Feldgerät 33 entsteht, den Aufwand übersteigen, der beim erneuten Senden und Empfangen der Daten gemäß eines verbin­ dungslosen Protokolls entsteht. Da in der Regel nur wenige Daten schnell übermittelt werden sollen (z. B. Tastendruck, Displayinhalt, LED-Status), ist der Einsatz eines schnellen, effektiven, verbindungslosen Protokolls sinnvoll, beispiels­ weise des oben beschriebenen RPC-Protokolls. Zur Reduktion der ausgetauschten Datenmenge (z. B. Displayinhalt) zwischen dem Benutzer-Personalcomputer 30 und dem Feldgerät 33 werden Verfahren zur Komprimierung von Daten eingesetzt.

Internet-Protokolle, wie TCP/IP und HTTP, bieten keinerlei Sicherheitsmechanismen. Es sind zusätzliche Protokolle not­ wendig, um eine sichere Kommunikation zu ermöglichen. Die Mechanismen zum Schutz sicherheitsrelevanter Aktionen am Feldgerät 33 über TCP/IP-Kommunikation sind von besonderer Bedeutung. Hinsichtlich des Schutzes gegen unbefugte Zugriffe lassen sich die Bedienhandlungen am Feldgerät 33 klassifizie­ ren (vgl. Tabelle 1).

Tabelle 1

Missbräuchliche Handlungen beim Bedienen des Feldgeräts 33 können mittels der folgenden Maßnahmen im wesentlichen ausge­ schlossen werden:

• - Mit Hilfe einer Firewall (z. B. Proxyserver) kann das interne Netz (Firmen-Intranet/LAN) eine geschützte Verbindung mit ei­ nem anderen Netz (z. B. Internet) aufnehmen.
• - Das Feldgerät 33 ist im Lieferzustand so eingestellt, dass Tasten, die die vollständige Eingabe von Kundenpasswörtern er­ möglichen, gesperrt sind. Diese Sperre muss vom Kunden am Feldgerät 33 selbst bzw. mit dem Bedienprogramm in der Brow­ ser-Einrichtung 31 auf dem Nutzer-Personalcomputer 30 aufgeho­ ben werden (Passworteingabe erforderlich). Im Lieferzustand sind damit nur einfache Bedienhandlungen über die Browser- Einrichtung 31 möglich: Navigation im Bedienmenü, Anzeige von Messwerten, Parametern und Meldungslisten.
• - Die Parametrierung des Feldgeräts 33 in der Frontansicht- Emulation ist mit Kenntnis der Passwörter wie am Feldgerät 33 möglich, wenn die Sperrung der dazu benötigten Tasten gelöst ist.
• - Sicherheitsrelevante Aktionen am Feldgerät 33 (Schalten, Steuern, Löschen von Puffern, . . .) werden durch Authenti­ fikationsprotokolle geschützt, z. B. mittels Hash-Funktion und eines vom Feldgerät 33 generierten Schlüssels. Damit können aus dem Verbindungsprotokoll keine Rückschlüsse auf eingegebene Passwörter erfolgen. Mit diesem Verfah­ ren wird aus einer beliebig langen Nachricht eine 128 Bit lange Information, der sogenannte "Message Digest", ge­ bildet, der an die originäre Nachricht angehängt wird. Der Empfänger (Feldgerät 33) vergleicht den "Message Di­ gest" mit dem vom Feldgerät 33 aus der Information ermit­ telten. Dadurch werden Feldgerätepasswörter nicht über die Kommunikationsverbindung übertragen.
• - Die im Feldgerät 33 generierten Schlüssel verfallen nach kurzer Zeit und können nur einmal für eine Übertragung verwendet werden. Damit ist die Aufzeichnung von sicher­ heitsrelevanten Protokollen und eine spätere Wiederholung dieser aufgezeichneten Protokolle wirkungslos.

Proxyserver

Ein Element zur optimierten Umsetzung des beschriebenen, funk­ tionellen Zusammenwirkens der Elemente des Beobachtungs- und Bediensystems, beispielsweise der Nutzung des RPC-Protokolls, des Abrufs der Rohdaten aus den Feldgeräten FG1 . . . FGN und der Bedienung der Feldgeräte mittels Browser auf den Nutzerein­ richtungen N1 . . . NN, ist der Proxyserver 1. Bekannte Stan­ dard-HTTP-Proxyserver unterstützen ausschließlich das HTTP- Protokoll und sind somit nicht in der Lage, als Gateway zwi­ schen dem Gerätenetzwerk und dem Firmen-Intranet zu dienen. Aus diesem Grund wurde ein spezifischer, für das BuB-System konzipierter Proxyserver 1 geschaffen, der beide von den Feldgeräten FG1 . . . FGN verwendeten Protokolle (HTTP, RPC) un­ terstützt.

Ein wesentlicher Vorteil, der bei der Nutzung des Proxyser­ vers 1 gegenüber der Ankopplung des Gerätenetzwerks an das Firmen-Intranet mittels Routers oder, wenn keine WAN- Verbindung (WAN - "Wide Area Network") zwischen dem Geräte­ netzwerk und dem Intranet besteht, einer direkten Ankopplung des Geräte-Netzsegments über einen Hub oder einen Switch be­ steht in der Nutzung des sogenannten "Cachings".

Das diesem Verfahren ("Caching") zugrunde liegende Prinzip wird im folgenden allgemein, ohne Bezugnahme auf die oben ge­ nannten Figuren, kurz beschrieben.

Stellt ein Client eine Anfrage nach einem Objekt an eine Ser­ vereinrichtung, so läuft diese Anfrage zunächst über eine so­ genannte Proxy-Einrichtung. Die Proxy-Einrichtung schaut nach, ob sich das betreffende Objekt bereits in einem lokalen Speicher (Cache) der Proxy-Einrichtung befindet, welcher in der Regel auf einer Festplatte ausgebildet ist. Wird hierbei festgestellt, dass das Objekt nicht lokal im Speicher vor­ liegt, reicht die Proxy-Einrichtung die Anfrage weiter zu ei­ ner eigentlichen Zielserver-Einrichtung. Von dort erhält die Proxy-Einrichtung das Objekt und speichert eine Kopie des Ob­ jekts für weitere Anfragen nach diesem Objekt in dem lokalen Speicher, bevor die Proxy-Einrichtung das Objekt an den an­ fragenden Client weitergibt. Wird das Objekt jedoch im loka­ len Speicher der Proxy-Einrichtung gefunden, so wird die An­ frage des Clients nicht an die Zielserver-Einrichtung durch­ gestellt, sondern der Client bekommt das gewünschte Objekt direkt von der Proxy-Einrichtung übermittelt. Voraussetzung für optimales Ausführen des beschriebenen Verfahrens ist ein genügend großer Speicher-Bereich in der Proxy-Einrichtung, d. h. in der Größenordnung von mehreren Hundert MB bis mehre­ ren GByte. Ansonsten läuft der lokale Speicher in der Proxy- Einrichtung über und es muss ein "Garbage Collector" (ein sogenannter Aufräumdienst) gestartet werden, der veraltete Ob­ jekte aus dem Speicher heraus filtert, um dort Platz für neue Objekte zu schaffen.

Vorteile des beschriebenen Verfahrens ("Caching") sind: eine Verbesserung der Leistungsfähigkeit (schnellerer Datentrans­ port als extern); eine Einsparung von externer Bandbreite (mehr Platz für andere Dienste bleibt frei); eine Verminde­ rung der Antwortzeiten; Entlastung der Zielserver-Einrichtung; beim Transport des Ob­ jekts von der Proxy-Einrichtung zum Client entstehen keine bzw. geringere Übertragungskosten, und die Trefferquoten im lokalen Speicher der Proxy-Einrichtung können je nach Nutzung sehr hoch sein.

Der zum Verbinden des Gerätenetzwerks und des Firmen- Intranets (vgl. Fig. 1) genutzte Proxyserver 1 basiert auf dem beschriebenen Grundprinzip und hat aufgrund der spezifi­ schen Ausbildung, welche im Detail später beschrieben wird, darüber hinaus die im folgenden genannten Vorteile.

Durch den Einsatz des Proxyservers 1 (vgl. Fig. 1) ergeben sich deutliche Geschwindigkeitsvorteile beim Zugriff auf das Gerätenetzwerk. Der Proxyserver 1 umfasst einen für die An­ wendung im BuB-System optimierten Dateispeicher bzw. Dateica­ che, der alle aus den Feldgeräten FG1 . . . FGN abgerufenen Da­ teien mit statischen Daten im Proxyserver 1 puffert. Wird auf eine solche Datei das erste Mal zugegriffen, dann muss diese Datei direkt aus einem der Feldgeräte FG1 . . . FGN geholt werden. Bei einem wiederholten Zugriff auf diese Datei kann diese dann jedoch direkt aus dem Dateicache des Proxyservers 1 geliefert werden. Da das lokale Firmen-Intranet im allge­ meinen viel schneller als eine Modemverbindung zu den Feldge­ räten FG1 . . . FGN ist, ergeben sich hier signifikante Geschwin­ digkeitsvorteile beim Zugriff auf das Gerätenetzwerk, da im laufenden Betrieb nur noch die gegenüber den HTML-Seiten und den Java-Archiven deutlich kleineren dynamischen Daten über die langsame Modemverbindung übertragen werden.

Der Proxyserver 1 erhöht darüber hinaus die Sicherheit im Netzwerk. Der Proxyserver 1 schottet die beiden Netzwerke, Gerätenetzwerk und Firmen-Intranet, gegeneinander ab und ü­ berträgt nur die im Proxyserver 1 verarbeiteten Protokolle. Dies bedeutet, dass aus dem Firmen-Intranet nur die von einem Browser auf den Nutzereinrichtungen N1 . . . NN an die Feldgeräte FG1 . . . FGN generierten Anforderungen übertragen werden. In die Gegenrichtung werden nur die von den Feldgeräten FG1 . . . FGN generierten Antworten übertragen. Damit werden al­ le anderen im Firmen-Intranet kursierenden Datenpakete vom Gerätenetzwerk ferngehalten und beeinflussen somit nicht den Durchsatz im Gerätenetzwerk. Des weiteren kann ein im Gerä­ tenetzwerk auftretendes, hohes Datenaufkommen aufgrund von Querkommunikation zwischen den Feldgeräten FG1 . . . FGN die Netzlast im Firmen-Intranet nicht erhöhen.

Die Nutzung des RPC-Protokolls mittels des Proxyservers 1 hat den Vorteil, dass sichergestellt ist, dass die Zugriffs­ möglichkeit auf die Feldgeräte FG1 . . . FGN auf das an den Pro­ xyserver 1 angeschlossene Firmen-Intranet beschränkt bleibt. Ein Firmen-Intranet ist heute üblicherweise über ein HTTP- Gateway mit dem Internet verbunden. Dieses Gateway übernimmt hier eine Firewall-Funktion (vgl. Fig. 7), indem es die Ü­ bertragung des RPC-Protokolls blockiert. Hierdurch kann au­ ßerhalb des Firmen-Intranets nicht mehr auf die Daten der Feldgeräte FG1 . . . FGN zugegriffen werden, da alle dynamischen Daten der Feldgeräte FG1 . . . FGN über das RPC-Protokoll über­ tragen werden.

Der Proxyserver 1 ermöglicht vielfältige Funktionen, die bei dem bisher üblichen, direkten Zugang zu den Feldgeräten FG1 . . . FGN nicht zur Verfügung stehen. Die folgende Zusammen­ stellung listet weitere wesentliche Funktionen auf, die sich in Verbindung mit der nachfolgenden, detaillierten Beschrei­ bung des Proxyservers 1 ergeben:

• - Es wird eine eigene Homepage zur Verfügung gestellt, über die alle angeschlossenen Feldgeräte FG1 . . . FGN erreichbar sind.
• - Die angeschlossenen Feldgeräte FG1 . . . FGN werden automa­ tisch adressiert und erkannt; Darstellung dieser Feldgerä­ te FG1 . . . FGN in der Homepage als Startseite auf den Nut­ zereinrichtungen N1 . . . NN für einen direkten Gerätezugriff.
• - Es wird der Zugriff über Gerätenamen der Feldgeräte FG1 . . . FGN ermöglicht; dies ist gegenüber dem Zugriff über die IP-Adresse nutzerfreundlicher.
• - Der Proxyserver 1 kann mittels Browser auf den Nutzerein­ richtungen N1 . . . NN konfiguriert werden (E-Mail-Adressen, Telefon-Nummern, Gerätenamen, . . .)
• - Der Proxyserver 1 definiert die möglichen Zugriffswege ("Firewall-Funktion").
• - Der Proxyserver 1 kann Daten aus den Feldgeräte FG1 . . . FGN zwischenspeichern. Diese Funktion eignet sich z. B. für die Protokollierung der Störfallinformationen oder der Be­ triebsmesswerte. Diese Daten werden intern in einer XML- Datenbank (XML - "Extended Markup Language") abgelegt.
• - Der Proxyserver kann die aus den Feldgeräten FG1 . . . FGN ü­ ber das RPC-Protokoll übertragenen Daten im XML-Format zur Verfügung stellen. Hierdurch können beispielsweise nut­ zerspezifische Erweiterungen der im Proxyserver 1 verfüg­ baren Darstellungen vorgenommen werden. Hierzu steht ein im Proxyserver 1 integrierter XSL-Parser (XSL - "Extended Stylesheet Language") zur Verfügung.
• - Durch die mit Hilfe des XSL-Parsers realisierbaren Filter auf die XML-Datenbank kann der Proxyserver 1 ebenfalls als Client für weitere Applikationen genutzt werden.
• - Signalisierung von Ereignissen im LAN (LAN - "Local Area Network") via e-mail ist möglich. Der Proxyserver 1 stellt eigene e-mail-Postfächer zu Verfügung, die mittels eines POP3-Clients (POP3 - "Post Office Protocol Stepping 3"), wie z. B. Outlook, abgerufen werden können. Weiterhin ist eine Weiterleitung von e-mails an ein anderes Postfach mittels eines im Proxyserver 1 integrierten SMTP-Servers (STMP - "Simple Message Transfer Protocol") möglich.

Im folgenden wird die Ausbildung des Proxyservers 1 näher be­ schrieben.

Fig. 7 zeigt eine Anordnung mit dem Gerätenetzwerk und dem Firmen-Intranet gemäß Fig. 1, wobei Elemente des Proxyser­ vers 1 schematisch gezeigt sind. Fig. 8 zeigt Funktionsblö­ cke des Proxyservers 1 in einem Blockschaltbild.

Gemäß Fig. 7 weist jedes der Feldgeräte FG1 . . . FGN einen je­ weiligen HTTP-Server HS1 . . . HSN auf, die dem jeweiligen HTTP- Server 34 (vgl. Fig. 4) entsprechen und mit einem Sternkopp­ ler 39 verbunden sind. Der Proxyserver 1 verfügt ebenfalls über einen HTTP-Server 40. Im folgenden wird die Arbeitswei­ se des Proxyservers 1 unter Bezugnahme auf Fig. 8 beschrie­ ben.

Der Zugriff auf den Proxyserver 1 geschieht immer aus dem lo­ kalen Netz des Firmen-Intranets heraus, in dem sich die Nut­ zereinrichtungen N1 . . . NN mit der jeweiligen Modemverbindung in das die Feldgeräte umfassende Gerätenetzwerk befinden, das ein Umspannwerk oder mehreren Unterwerken umfassen kann. Wird eine der Nutzereinrichtungen N1 . . . NN über die zugehörige, lo­ kale IP-Adresse als Server angesprochen, wird dieser Zugriff über einen TCP/IP-Stack 41 (TCP - "Transfer Control Proto­ col") an den HTTP-Server 40 weitergeleitet.

Der HTTP-Server 40 liefert die angeforderten Dateien in das Firmen-Intranet. Zu diesem Zweck wendet sich der HTTP-Server 40 über einen Dateifilter 42 an eine Cacheverwaltung 43. Der Dateifilter 42 leitet die Anforderung normalerweise an die Cacheverwaltung 43 weiter. Nur bestimmte Anforderungen wer­ den anhand des angeforderten Dateityps erkannt und einem an­ deren Verarbeitungsweg zugeführt. Diese Ausnahmen werden später beschrieben. Die Cacheverwaltung 43 versucht als ers­ tes, die angeforderte Datei in den lokalen Dateien 44 oder in einem Dateicache 45 zu finden. Ist die angeforderte Datei weder eine lokale Datei des Proxyservers 1 noch im Dateicache 45 vorhanden, wird die Dateianforderung an einen HTTP-Client 46 weitergeleitet. Dieser baut über einen weiteren TCP/IP- Stack 47 eine Verbindung zum HTTP-Server HS1, . . . bzw. HSN des angesprochenen Feldgeräts FG1, . . . bzw. FGN im Geräte­ netzwerk auf, um die angeforderte Datei von dort zu beziehen.

Als Verbindung zum Gerätenetzwerk wird vorzugsweise eine Mo­ demverbindung mit dem PPP-Protokoll genutzt (vgl. Fig. 1). Da der Proxyserver 1 über diese Modemverbindung jedoch gleichzeitig mehrere Verbindungen zu verschiedenen Feldgerä­ ten FG1 . . . FGN halten kann, ist eine Arbitrierung dieser Modem­ verbindung erforderlich, da das PPP-Protokoll nur eine Punkt- zu-Punkt-Verbindung verwalten kann. Hierzu dient ein Block Slot-Protokoll 48. Dieses Protokoll teilt den einzelnen PPP- Verbindungen Zeitscheiben auf der Modem-Kommunikationsstrecke zu und verhindert so Kollisionen zwischen den einzelnen Ver­ bindungen. Der Block Slot-Protokoll 48 ist weiterhin dafür zuständig, alle im Gerätenetzwerk aktiven Feldgeräte FG1 . . . FGN zu erkennen. Dazu wird das Gerätenetzwerk zyklisch nach aktiven Feldgeräten abgesucht. Die erkannten, aktiven Feldgeräte werden von einer Geräteverwaltung 49 in eine XML- Datenbank 50 des Proxyservers 1 eingetragen.

Bei der XML-Datenbank 50 handelt es sich um einen nach dem standardisierten "Document Object Model" abgelegten Daten­ baum. Enthält nun eine über den HTTP-Server 40 in den Brow­ ser einer mit dem Proxyserver 1 verbundene Nutzungseinrichtung N1, . . . bzw. NN geladene HTML-Seite Java-Code, der eine pa­ rallele UDP-Verbindung (UDP - "User Defined Protocol") für das RPC-Protokoll aufbaut, dann wird über diesen Weg ein RPC-Server 51 aus dem Firmen-Intranet heraus angesprochen. Da das RPC-Protokoll aus Leistungsgründen auf das standardi­ sierte UDP/IP-Protokoll aufsetzt, muss hier im Proxyserver 1 eine Verbindungsverwaltung 52 enthalten sein, da das UDP- Protokoll nicht verbindungsorientiert arbeitet. Die Verbin­ dungsverwaltung 52 stellt sicher, dass für jede Nutzungsein­ richtung N1 . . . NN aus dem Firmen-Intranet ein eigener Kommuni­ kationsport für einen RPC-Client 53 des Proxyservers 1 in das Gerätenetzwerk reserviert wird. Die RPC-Anforderungen aus dem Firmen-Intranet werden dann über den RPC-Client 53 des Proxyservers 1 direkt in das Gerätenetzwerk weitergeleitet.

Die Antworten der Feldgeräte FG1 . . . FGN auf RPC-Anforderungen werden an den RPC-Server 51 weitergeleitet. Dieser gibt die Antwort des jeweiligen Feldgeräts FG1, . . . bzw. FGN an die Nutzereinrichtungen über das Firmen-Intranet weiter. Paral­ lel hierzu werden die aktuell im RPC-Protokoll übertragenen, dynamischen Daten aus dem jeweiligen Feldgerät FG1, . . . bzw. FGN in der XML-Datenbank 50 im Proxyserver 1 abgelegt.

Die in der XML-Datenbank 50 gespeicherten Daten können mit Hilfe eines im Proxyserver 1 integrierten XSL-Parsers 54 in beliebige andere Datenformate konvertiert werden. Die dazu notwendigen Transformationsanweisungen müssen als XSL- Scriptdatei lokal im Proxyserver 1 abgelegt werden. Um einen solchen Transformationsprozess auszulösen, muss am HTTP- Server 40 eine *.XML-Datei angefordert werden. Eine solche Anforderung wird von dem am HTTP-Server 40 angeschlossenen Dateifilter 42 aus dem normalen Zugriffsweg auf die Cachever­ waltung 43 herausgefiltert und an den XSL-Parser 54 weiterge­ leitet. Dieser liest aus den im Proxyserver 1 lokal abgeleg­ ten Dateien neben der angeforderten XML-Datei eine gleichna­ mige XSL-Datei und startet den Transformationsprozess. Das Ergebnis dieser Transformation wird vom HTTP-Server 40 an den anfordernden Nutzer gesendet. Auf diese Weise können z. B. HTML-Dateien dynamisch aus einer XSL-Vorlage mit den aktuel­ len Daten der Feldgeräte FG1 . . . FGN aus der XML-Datenbank 50 erzeugt oder einfach ein Teilbaum der Datenbank als XML-Datei übertragen werden.

Der Dateifilter 42, die Cache-Verwaltung 43, die lokalen Da­ teien 44, der Dateicache 45, der XSL-Parser 54 sowie die XML- Datenbank 50 bilden ein Dateisystem des Proxyservers 1.

Im folgenden werden einzelne Funktionsblöcke des Proxyservers 1 näher beschrieben.

HTTP-Server

Zunächst wird die grundsätzliche Arbeitsweise des im Proxy­ server 1 ausgebildeten HTTP-Servers 40 (vgl. Fig. 8) erläu­ tert, wobei zum besseren Verständnis einige wesentliche Grundlagen des HTTP's beschrieben werden.

Wie bei anderen Applikationsprotokollen im Internet handelt es sich bei HTTP (HTTP - "Hypertext Transfer Protocol") um ein ASCII-Protokoll, das für den Datenaustausch eine abgesi­ cherte TCP-Verbindung zwischen einem Client (Computer des In­ ternetnutzers) und einem Server (Servereinrichtung, auf wel­ cher abrufbare Internetinhalte - Daten - zur Verfügung ste­ hen) benötigt. Als Anknüpfungspunkt ist dabei der Port 80 definiert, d. h., ein HTTP-Server lauscht an diesem Port auf neue Client-Verbindungen. Alternativ kann die überwiegende Anzahl von HTTP-Server-Software über einen entsprechenden Konfigurationsdialog auch angewiesen werden, einen anderen Port für die Kontaktaufnahme heranzuziehen.

Anders als bei anderen Protokollen, z. B. FTP (FTP - "File Transfer Protocol") und POP3, ist eine Verbindung zwischen einem HTTP-Client und einem HTTP-Server sehr kurzlebig. Der HTTP-Client baut eine TCP-Verbindung zum gewünschten HTTP- Server über den Port 80 auf und setzt eine Anfrage nach einem gewünschten Dokument an den HTTP-Server ab. Der HTTP-Server erhält die Anfrage, wertet sie aus und sendet - im Erfolgs­ fall - das gewünschte Dokument an den HTTP-Client zurück. Der HTTP-Server schließt die TCP-Verbindung automatisch, nachdem er dem HTTP-Client das geforderte Dokument oder eine Fehlermeldung als Antwort auf dessen Anfrage zugesandt hat.

Eine wichtige Funktionalität von HTTP ist es, dass der HTTP- Client dem HTTP-Server mitteilen kann, welche Art von Daten dieser verstehen kann. Es muss also bei jeder Anfrage eine Kommunikation zwischen dem HTTP-Client und dem HTTP-Server darüber stattfinden, wie die Daten übertragen werden sollen. Diese Kommunikation erzeugt einen sogenannten Überschuss bzw. Überhang ("overhead"); HTTP wird deshalb auch als statusloses Protokoll ("stateless protocol") bezeichnet, weil die Verbin­ dung nicht mehrere Phasen durchläuft, vom Einloggen, über den Datenaustausch bis hin zum Ausloggen durch den HTTP-Client. Dieses erleichtert einerseits die Entwicklung von HTTP- Client-/HTTP-Server-Software, ist aber im Hinblick auf die Nutzung der zur Verfügung stehenden Bandbreite nicht sehr ef­ fizient.

Das HTTP-Protokoll wird verwendet, um Zugriff auf Quellen im URL-Format (URL - "Uniform Resource Locator") zu erlangen. Der HTTP-Client, meistens ein Web-Browser auf dem Computer des Internet-Benutzers. Er verlangt eine HTML-Seite und gene­ riert danach eine Sequenz von Anfragen bezüglich der Datei­ verweise in dieser HTML-Seite. Danach wird der Benutzer wahrscheinlich einen Link in der angefragten HTML-Seite an­ klicken, und der HTTP-Client schickt eine Anfrage, bezüglich der mit diesem Link verknüpften HTML-Seiten, an den gleichen oder einen weiteren HTTP-Server. Diese weiteren Kommunikati­ onsverbindungen haben keine Informationen mehr über eine vor­ hergegangene Verbindung. Dieses funktioniert bei einfachen Client/Server-Umgebungen. Bei umfangreicheren Kommunikatio­ nen kann diese Arbeitsweise allerdings zum Problem werden, denn für jede noch so kleine Datenmenge, die übertragen wer­ den soll, fällt dieser Überschuss ("Overhead") an, was die Effizienz mindert.

Fig. 9 zeigt eine schematische Darstellung der Syntax einer Anfrage in Verbindung mit einer HTTP-Client/Server- Interaktion.

Die HTTP-Client/Server-Interaktion besteht aus einer einzigen Anfrage/Antwort-Kommunikation. Sie umfasst eine "request li­ ne", ein oder mehrere optionale "request header fields" und einen optionalen "entity body". Von der HTTP-Client-Seite 60, also in der Regel vom Internet-Browser aus, wird eine TCP-Verbindung zum HTTP-Server 61 geöffnet 62. Anschließend sendet der HTTP-Client 60 einen Kommandostring an den HTTP- Server 61. Der HTTP-Server 61 antwortet über die vom HTTP- Client 60 geöffnete TCP-Verbindung mit einem Kopf, der neben der vom HTTP-Server 61 unterstützten HTTP-Version auch den MIME-Type und die Kodierung der angeforderten Datei enthält. An diesen Kopf im ASCII-Format wird vom HTTP-Server 61 der Inhalt der angeforderten Datei angefügt. Nachdem der HTTP- Server 61 die komplette Datei gesendet hat, schließt dieser die vom HTTP-Client 60 geöffnete TCP-Verbindung wieder 63. Dieser Vorgang kann sich beliebig oft wiederholen.

Die folgende Zusammenstellung zeigt den Ablauf eines typi­ schen HTTP-Zugriffs:

• 1. "connection" (Verbindungsaufbau)
  • - WWW-Client baut eine TCP/IP-Verbindung zum WWW-Server auf
• 2. "request" (Anforderung)
  • - Angabe einer Zugriffsmethode (GET, HEADER, POST . . .)
  • - Spezifikation des gewünschten Dokumentes mittels URL
  • - Zusatzinformationen in Form von MIME-Header
  • - Daten (bei POST)
• 3. "response" (Antwort)
  • - Header mit Statuscode
  • - Zusatzinformationen in Form von MIME-Header
  • - Dokument in HTML-Format
  • - Daten in sonstigen Formaten (Bilder, Sound . . .)
• 4. "close" (Verbindungsabbau)
  • - Im Normalfall vom HTTP-Server aus, nach Datenübertra­ gung
  • - Im Spezialfall vom HTTP-Client aus (Übertragungszeit, Speicherplatz)

Hierbei besteht die "request line" aus drei Textfeldern, wel­ che durch Leerzeichen getrennt sind. Das erste Feld spezifi­ ziert die Methode (oder das Kommando). Das zweite Feld spe­ zifiziert den Namen der Quelle (ist die URL ohne die Angabe des Protokolls und des Hosts). Das letzte Feld spezifiziert die verwendete Protokollversion des HTTP-Clients 60, bei­ spielsweise HTTP/1.0. Die "request header fields" übergeben zusätzliche Informationen über die Anfrage und den HTTP- Client 60. Die Felder werden als eine Art RPC-Parameter be­ nutzt. Jedes Feld besteht aus einem Namen, gefolgt von eine Doppelpunkt und dem Feldwert. Die Reihenfolge der "header fields" ist hierbei nicht wichtig. Der "entity body" wird manchmal von HTTP-Clients 60 verwendet, um größere Informati­ onspakete an den HTTP-Server 61 zu senden.

Dateicache

Um eine möglichst effiziente Arbeit der Cacheverwaltung 43 zu ermöglichen, arbeitet der Dateicache 45 nicht wie üblich mit der URL, dem Datum und der Lebensdauer der zu verwaltenden Dateien, sondern nutzt weitere Kriterien zur Identifizierung einer Datei. Würden nur die drei genannten Kriterien für den Entscheid verwendet werden, ob eine lokal im Dateicache vor­ handene Datei mit der im Feldgerät verfügbaren Datei iden­ tisch ist, dann wäre für die Durchführung dieses Tests ein Vergleich der genannten Dateimerkmale erforderlich. Dazu müsste für jede Datei der Kopf aus dem Feldgerät angefordert werden. Da das Dateisystem der Feldgeräte FG1 . . . FGN jedoch nur als Einheit in Form eines KON-Dateien (konvertierte Da­ teien - Format der in die Nutzereinrichtungen N1 . . . NN ladba­ ren Dateien) geladen werden kann, ist ein solcher Vergleich nicht für jede Datei erforderlich. Eine Ausnahme bilden hier die dynamisch in den Feldgeräten FG1 . . . FGN erzeugten Dateien, beispielsweise die Datei MLFB.TXT (MLFB-Maschinenlesbare Fabrikantenbezeichnung), die nicht aus dem Dateisystem der Feldgeräte FG1 . . . FGN ausgelesen, sondern aus der im jeweili­ gen Feldgerät FG1, . . . bzw. FGN eingestellten MLFB generiert wird.

Als Unterscheidungsmerkmal zwischen diesen beiden Dateifor­ men, nämlich den statischen Dateien und den Dateien mit dyna­ mischen Daten, dient ein Eintrag in einer Datei "noca­ che.txt". Alle dynamisch in den Feldgeräten FG1 . . . FGN er­ zeugten Dateien müssen in dieser Datei aufgeführt sein. Sta­ tische Dateien werden vom HTTP-Server HS1 . . . HSN der Feldgerä­ te FG1 . . . FGN mit einer unendlichen Lebensdauer gekennzeich­ net. Im folgenden ist ein Beispiel für den Inhalt der Datei "nocache.txt" gezeigt:

/mlfb.txt: MLFB, BF-Nr., Displaytyp
/textpool.zip: gerätespezifische Texte für Applets (mehrsprachig)
/ver.txt: Version, Datum
/chartab.jar: Gerätezeichensatz

Die Datei "ver.txt" kann hierbei den folgenden Inhalt aufwei­ sen/anzeigen:

V01.01.01
Tue, 24 Oct 2000 07:50:00 GMT

Slot-Protokoll des Proxyservers

Das Slot-Protokoll 48 (vgl. Fig. 8) dient der Anbindung des Proxyservers 1 an die Feldgeräte FG1 . . . FGN in einer Anordnung mit Sternkoppler nach Fig. 7. Das Slot-Protokoll 48 glie­ dert sich in die beiden Bereiche (i) Geräteerkennung und (ii) Arbitrierung der Sternkoppleranordnung. Die Geräteerkennung dient der automatischen Erkennung aller an den Sternkoppler 39 angeschlossenen Feldgeräte FG1 . . . FGN. Die Arbitrierung muss Kollisionen von Datagrammen unterschiedlicher Feldgeräte FG1 . . . FGN auf der Kommunikationsverbindung zwischen dem Pro­ xyserver 1 und den einzelnen Feldgeräten FG1 . . . FGN verhin­ dern.

Im folgenden wird die Geräteerkennung bei Nutzung der Stern­ koppleranordnung 39 beschrieben.

Geräteerkennung

Die Geräteerkennung stellt einen Bestandteil des Slot- Protokolls 48 dar. Dieser Protokollteil belegt die serielle Verbindung exklusiv, d. h. während der Geräteerkennung darf keine andere Kommunikation auf der Modemstrecke aktiv sein. Deshalb wird die Geräteerkennung nur beim Aufbau der Modem­ verbindung aktiviert. Im laufenden Betrieb des Beobachtungs- und Bediensystems ist dieser Protokollteil inaktiv. Die Ge­ räteerkennung kann jedoch bei Bedarf aktiviert werden.

Fig. 10 zeigt eine Master-Slave-Anordnung mit Sternkoppler zur Erläuterung der Geräteerkennung.

Das Slot-Protokoll 48 arbeitet nach dem Master-Slave-Prinzip. Ein Master 70 befindet sich am oberen Anschluss in Fig. 10. Die unteren Anschlüsse eines Sternkopplers 71, welcher dem Sternkoppler 3 in Fig. 1 entspricht, werden von jeweils ei­ nem Slave S1 . . . SN belegt, welche den Feldgeräten FG1 . . . FGN gemäß Fig. 1 entsprechen. Der Master 70 könnte jede mögli­ che Adresse der angeschlossenen Slaves S1 . . . SN abfragen und bei einer Antwort auf diese Anfrage den gefundenen Slave S1, . . . bzw. SN in die Liste der Geräte aufnehmen, die dem Master 70 bekannt sind. Diese Vorgehensweise ist jedoch bei einem Adressbereich von 32 Bits nicht mehr durchführbar. Hier wären 2^{^}32 Abfragen erforderlich. Diese Zahl ist jedoch nicht mehr durchführbar, da hier die für diese Abfrage erforderliche Zeit die Lebensdauer der Anlage überschreiten würde. Um den­ noch die an den Master 70 angeschlossenen Geräte automatisch erkennen zu können, wird das Problem erfindungsgemäß in der folgenden Weise gelöst:
Bei einem Adressierungsschema mit einer Binär kodierten Ad­ resse mit einer fest vorgegebenen Adresslänge wird bei einer Anfrage immer ein Adressbereich abgefragt. Auf diese Anfrage antworten nur die Slaves, die sich in dem abgefragten Adress­ bereich befinden. Da sich hier mehrere Feldgeräte (Slaves) im gleichen abgefragten Adressbereich befinden können, kommt es bei einer gleichzeitigen Antwort von mehreren der Slaves S1 . . . SN in diesem Fall zwangsläufig zu einer Kollision. Die­ se Kollision wird bewusst in Kauf genommen und ist Bestand­ teil des vorgeschlagenen Verfahrens. Aus diesem Grund prüft der Master 70 nur, ob innerhalb eines definierten Zeitraums überhaupt eine Antwort auf seine Anfrage eingegangen ist.

Beträgt der Adressraum der adressierbaren Slaves S1 . . . SN n Bits, sendet der Master 70 jeweils eine Anfrage mit einem feststehenden Bit der Adresse und einer Maske für die anderen Adressbits aus. Mit zwei Abfragen kann getestet werden, ob sich in dem durch das feststehende Bit vorgegebenen Adressbe­ reich Slaves befinden. Wurde auf eine Anfrage für einen Ad­ ressbereich eine Antwort erhalten, dann wird die Maske um ein Bit verkleinert und für das nächste feststehende Bit mit wie­ derum zwei Abfragen getestet, ob sich in dem nun kleineren Adressbereich Slaves befinden. Kommt auf die Anfrage für den nun kleineren Adressbereich eine Antwort, dann ist das nächs­ te Bit des Adressbereichs gefunden, in dem sich Slaves befin­ den. Dieser Vorgang wird so lange wiederholt, bis die Maske für den Adressbereich sich auf 0 Bits reduziert hat. Dann ist einer der Slaves S1 . . . SN am Bus eindeutig identifiziert. Kommen bei einer Abfrage auf beide Zustände des gerade getes­ teten Bits Antworten, dann werden beide Zweige in der nächs­ ten Iteration weiter verfolgt. Da bei einer Maskengröße von 0 Bits nur das Gerät bzw. der Slave mit der angefragten, nun vollständig feststehenden Adresse auf die gestellte Anfrage antworten kann, können bei der letzten Anfrage auch keine Kollisionen mehr auftreten, und das Antworttelegramm der zu detektierenden Slaves kann spontane Informationen über den Zustand der angeschlossenen Slaves enthalten. Fig. 12 erläu­ tert das beschriebene Verfahren noch einmal anhand eines ein­ fachen Adressierungsschemas mit einer 4-Bit-Adresse, also für einen Adressraum vom 0 bis 15. Es wird vorausgesetzt, dass sich die Geräte mit den Adressen 3, 4 und 7 in der Anordnung befinden. Es wird mit der Abfrage vom höchstwertigen Bit be­ gonnen. Es wird also zum einen der Adressraum 0 bis 7 und in einer zweiten Abfrage der Adressraum 8 bis 15 mit einer Ab­ frage getestet. Auf diese zweite Abfrage antwortet kein Ge­ rät. Auf die erste Abfrage erhält der Master eine oder mehre­ re Antworten. Deshalb wird im Adressraum 0 bis 7 die Maske um ein weiteres Bit verkleinert. Es werden also nun die Adress­ bereiche 0 bis 3 mit einer dritten Abfrage und 4 bis 7 mit einer vierten Abfrage geprüft. Dieser Vorgang wiederholt sich entsprechend der Darstellung in Fig. 12 so lange, bis die Ad­ ressen vollständig aufgelöst und damit alle Geräte gefunden sind.

In dem beschriebenen Beispiel werden die Slaves S1 . . . Sn bzw. die Feldgeräte FG1 . . . FGN mittels eines IP-basierten Proto­ kolls an den Master 70 angeschlossen. Beim IP-Protokoll ha­ ben alle Busteilnehmer eine 32-Bit-Adresse. Die Adresse wird in Oktette aufgeteilt und jedes Oktett dezimal dargestellt. Die hexadezimale 32-Bit-Zahl 0×8D8D8000 entspricht also der IP-Adresse 141.141.128.0. Für den eigentlichen Vorgang zur Geräteerkennung/-abfrage wird eine rekursive Variante des im vorhergehenden Absatz beschriebenen Verfahrens verwendet.

Fig. 11 zeigt das Ablaufdiagramm des Verfahrens als Nassi- Schneidermann-Diagramm.

Im Rahmen des beschriebenen Verfahrens wird der Test, ob ein Feldgerät (Slave) im verfügbaren Adressbereich ansprechbar ist, vorzugsweise mit Hilfe eines als solchen bekannten Re­ quest-Datagramms vom Master 70 ausgelöst. Im Unterschied zu herkömmlichen Verfahren wird jedoch bewusst in Kauf genommen, dass auf ein vom Master 70 ausgesandtes Request-Datagramm mehrere der Slaves S1 . . . SN gleichzeitig antworten. Dadurch, dass im Sternkoppler 71 alle von den Slaves S1 . . . SN empfange­ nen Signale über ein logisches ODER-Gatter verknüpft werden und dieses Summensignal an den Master 70 weitergeleitet wird, kann sichergestellt werden, dass im Master 70 eine Antwort eines der Slaves S1 . . . SN in jedem Fall erkannt wird. Wenn sich die Antwort-Datagramme mehrerer der Slaves S1 . . . SN zeit­ lich überlappen, wird im Master 70 ein fehlerhaftes Datagramm empfangen. Auch dieser Fall wird als Antwort erkannt.

Mit Hilfe der Vorgabe einer maximalen Antwortzeit für die Slaves S1 . . . SN auf ein Request-Datagramm des Masters 70 und der Datagramm-Übertragungszeit kann eine Überwachungszeit für den Master 70 definiert werden. Erhält der Master 70 inner­ halb dieser Überwachungszeit eine Antwort, dann befinden sich im angefragten Adressbereich Slaves bzw. Feldgeräte. Im Um­ kehrschluss befinden sich im angefragten Adressbereich keine Feldgeräte, wenn vom Master 70 innerhalb der Überwachungszeit keine Antwort auf den Request empfangen wurde.

Da bei einer vollständigen Auflösung der Adresse im Request des Masters 70 (d. h. die Maske wird leer) nur noch einer der Slaves S1 . . . SN antworten darf, kann in diesem Fall auch keine Kollision mehr auftreten. Damit kann in diesem Fall die Feh­ lersicherung des empfangenen Datagramms benutzt werden, um eine Leitungsstörung und damit eine mögliche Fehlerkennung eines angeschlossenen Slaves auszuschließen. Tritt während der Überwachungszeit nach einem Request des Masters eine Leitungsstörung auf, die einen nicht vorhandenen Slave vor­ täuscht, führt das nur zu einer Verlängerung des Vorgangs zum Abfragen, aber nicht zu einer falschen Erkennung von ange­ schlossenen Slaves, da diese Leitungsstörung spätestens bei der vollständigen Auflösung der Maske erkannt wird.

Der folgende Absatz zeigt anhand eines Beispiels die Funktion des Verfahrens:

Test: 141.141.128.0; Mask: 255.255.128.0;
Test: 141.141.0.0; Mask: 255.255.128.0;
Test: 141.141.64.0; Mask: 255.255.192.0;
Test: 141.141.96.0; Mask: 255.255.224.0;
Test: 141.141.64.0; Mask: 255.255.224.0;
Test: 141.141.80.0; Mask: 255.255.240.0;
Test: 141.141.88.0; Mask: 255.255.248.0;
Test: 141.141.80.0; Mask: 255.255.248.0;
Test: 141.141.84.0; Mask: 255.255.252.0;
Test: 141.141.86.0; Mask: 255.255.254.0;
Test: 141.141.84.0; Mask: 255.255.254.0;
Test: 141.141.85.0; Mask: 255.255.255.0;
Test: 141.141.84.0; Mask: 255.255.255.0;
Test: 141.141.84.128; Mask: 255.255.255.128;
Test: 141.141.84.0; Mask: 255.255.255.128;
Test: 141.141.84.64; Mask: 255.255.255.192;
Test: 141.141.84.0; Mask: 255.255.255.192;
Test: 141.141.84.32; Mask: 255.255.255.224;
Test: 141.141.84.0; Mask: 255.255.255.224;
Test: 141.141.84.16; Mask: 255.255.255.240;
Test: 141.141.84.0; Mask: 255.255.255.240;
Test: 141.141.84.8; Mask: 255.255.255.248;
Test: 141.141.84.0; Mask: 255.255.255.248;
Test: 141.141.84.4; Mask: 255.255.255.252;
Test: 141.141.84.0; Mask: 255.255.255.252;
Test: 141.141.84.2; Mask: 255.255.255.254;
Test: 141.141.84.3; Mask: 255.255.255.255;
Test: 141.141.84.2; Mask: 255.255.255.255;
Found: 141.141.84.2;
Test: 141.141.84.0; Mask: 255.255.255.254;
Test: 141.141.80.0; Mask: 255.255.252.0;
Test: 141.141.82.0; Mask: 255.255.254.0;
Test: 141.141.80.0; Mask: 255.255.254.0;
Test: 141.141.81.0; Mask: 255.255.255.0;
Test: 141.141.80.0; Mask: 255.255.255.0;
Test: 141.141.80.128; Mask: 255.255.255.128;
Test: 141.141.80.192; Mask: 255.255.255.192;
Test: 141.141.80.128; Mask: 255.255.255.192;
Test: 141.141.80.160; Mask: 255.255.255.224;
Test: 141.141.80.176; Mask: 255.255.255.240;
Test: 141.141.80.160; Mask: 255.255.255.240;
Test: 141.141.80.168; Mask: 255.255.255.248;
Test: 141.141.80.160; Mask: 255.255.255.248;
Test: 141.141.80.164; Mask: 255.255.255.252;
Test: 141.141.80.166; Mask: 255.255.255.254;
Test: 141.141.80.164; Mask: 255.255.255.254;
Test: 141.141.80.165; Mask: 255.255.255.255;
Test: 141.141.80.164; Mask: 255.255.255.255;
Found: 141.141.80.164;
Test: 141.141.80.160; Mask: 255.255.255.252;
Test: 141.141.80.162; Mask: 255.255.255.254;
Test: 141.141.80.163; Mask: 255.255.255.255;
Found: 141.141.80.163;
Test: 141.141.80.162; Mask: 255.255.255.255;
Test: 141.141.80.160; Mask: 255.255.255.254;
Test: 141.141.80.161; Mask: 255.255.255.255;
Found: 141.141.80.161;
Test: 141.141.80.160 Mask: 255.255.255.255;
Found: 141.141.80.160;
Test: 141.141.80.128; Mask: 255.255.255.224;
Test: 141.141.80.0; Mask: 255.255.255.128;
Test: 141.141.64.0; Mask: 255.255.240.0;
Test: 141.141.0.0; Mask: 255.255.192.0.
58 Abfragen . . .

Die Abfragen schlossen den Adressraum 141.141.0.0 bis 141.141.255.255 ein. Es wurden die Geräte mit den folgenden Adressen gefunden:

141.141.84.2
141.141.80.164
141.141.80.163
141.141.80.161
141.141.80.160

Fig. 12 illustriert den dargestellten Vorgang in Form einer Baumdarstellung, wobei die fett umrandeten Felder die Abfra­ gen kennzeichnen, die von einem oder mehreren Slaves S1 . . . SN bzw. Feldgeräten beantwortet wurden.

Broadcast-Dienst

Für die Anbindung des Proxyservers 1 an die Feldgeräte FG1 . . . FGN kann anstelle der einfachen Architektur mit Stern­ koppler 39 ein IP-basiertes Netzwerk genutzt werden. In die­ sem Fall ist eine Arbitrierung dieses Netzwerks durch ein Pro­ tokoll, beispielsweise das Slot-Protokoll 48, nicht erforder­ lich. Diese Funktion übernimmt das Netzwerk selbst. Für die Geräteerkennung können bei dieser Ausführungsform ebenfalls Funktionen des Netzwerks genutzt werden. Bei einer Netzwerk­ verbindung zwischen dem Proxyserver 1 und den Feldgeräten FG1 . . . FGN wird zur Selbstkonfigurierung des Beobachtungs- und Bediensystems ein Broadcast-Dienst benutzt.

In beiden Fällen des Erkennens der angeschlossenen Feldgeräte FG1 . . . FGN, d. h. bei der Ausführungsform mit Sternkoppleran­ ordnung und bei Nutzung eines Netzwerks, insbesondere eines LANs, wird das Erkennen bei Inbetriebsetzung des Beobach­ tungs- und Bediensystems automatisch ausgeführt und erfolgt ohne vorherige Parametrierung der am System beteiligten Kom­ ponenten.

Der Broadcast-Dienst dient zum Erkennen der an das IP- basierte Netzwerk (z. B. LAN) angeschlossenen Feldgeräte, die einen Server für ihre eigene Bedienung enthalten. Weiterhin dient der Broadcast-Dienst zum Einsammeln von in den ange­ schlossenen Feldgeräten aufgetretenen, spontanen Ereignissen. Der Broadcast-Dienst ist eine IP-Applikation und basiert so­ mit auf den Funktionen des IP-Stacks und setzt auf dem UDP- Protokoll auf. Für diesen Dienst wird Serverseitig z. B. ein fest vorgegebener Port 0 × D000 reserviert. Clientseitig wird dynamisch ein freier Port ausgewählt. Durch den Einsatz des Standard-UDP/IP-Protokolls kann hier auf den IP-Programmier­ schnittstellen von üblichen Betriebssystemen, wie z. B. MS- Windows oder Linux, aufgesetzt werden. Damit kann der Proxy­ server 1 problemlos auf klassische Büroserver portiert wer­ den.

Der Broadcast-Dienst ist sowohl im Proxyserver 1 als auch in den einzelnen Feldgeräten aktiv. Für den Broadcast-Dienst wird der Proxyserver 1 als Master festgelegt. Eine Konfigu­ rationsabfrage ist ein vom Master abgesendetes UDP-Telegramm. Dieses Telegramm richtet sich je nach Konfiguration an eine Broadcast- oder eine Multicast-IP-Adresse. Eine Beschreibung von Broadcast- oder Multicast-IP-Adressen findet sich bei­ spielsweise in Karanjit S. Siyan: "Inside TCP/IP", Third Editi­ on, New Riders Publishing, Indianapolis, 1997, ISBN 1-56205- 714-6, Seite 187 ff.

Alle Feldgeräte werden anschließend auf die Konfigurationsab­ frage des Masters mit einem UDP-Telegramm antworten, welches die wichtigsten Konfigurationsdaten des Feldgeräts enthält. Da jetzt alle an dem IP-basierten Netzwerk angeschlossenen Feldgeräte theoretisch gleichzeitig Antworten möchten, wird es zunächst zu einigen Kollisionen auf dem genutzten Bus kom­ men, die durch das CSMA/CD-Verfahren (CSAM - "carrier sense, multiple access/collision detect") aufgelöst werden. Eine Beschreibung dieses Verfahrens ist ebenfalls in Karanjit S. Siyan: "Inside TCP/IP", Third Edition, New Riders Publishing, Indianapolis, 1997, ISBN 1-56205-714-6, Seite 97 ff, zu fin­ den. Die UDP-Antworttelegramme aller aktiven Feldgeräte wer­ den also beim abfragenden Master innerhalb einer gewissen Zeit ankommen. Somit ist der Abfragende in der Lage festzu­ stellen, wie viele und welche Feldgeräte sich im Netzwerk be­ finden und kann anschließend von den Feldgeräten weitere In­ formationen über das HTTP-Protokoll oder andere IP-basierte Protokolle anfordern.

Der Broadcast-Dienst hat außerdem noch die Aufgabe, ein spon­ tan in einem der Feldgeräte auflaufendes Ereignis im IP- basierten Netzwerk an die Teilnehmer des Broadcast-Dienstes zu verteilen. Da die Feldgeräte einerseits keine Information darüber besitzen, welcher Master für dieses Signal zuständig ist und es andererseits möglich sein kann, das im IP- basierten Netzwerk mehrere Master mit verteilten Aufgaben e­ xistieren, wird das Ereignistelegramm als Broadcast an alle Netzwerkteilnehmer gesendet. Die Master können dieses Signal je nach Ereignistyp und Sender ignorieren oder eine Aktion auslösen, welche über ein weiteres Protokoll, z. B. HTTP, zu­ sätzliche Informationen von dem Feldgerät abruft. Dieses Ab­ rufen zusätzlicher Informationen am das Ereignis aussendenden Feldgerät durch den zuständigen Master dient gleichzeitig als Empfangsbestätigung des Masters. Wird ein Ereignistelegramm nicht bestätigt, dann wird es so lange in regelmäßigen Abstän­ den (beispielsweise etwa 10 s oder mit einer logarithmisch wachsenden Zeit) wiederholt, bis eine Bestätigung von einem Master stattfindet.

Fig. 13 zeigt eine schematische Darstellung zur Erläuterung des Verfahrens im Rahmen der Konfigurationsabfrage.

Der Proxyserver 1 sendet als Master eine Konfigurationsanfra­ ge 72 als Broadcast an alle Teilnehmer im Netzwerk. Alle Feldgeräte FG1 . . . FGN antworten mit einem UDP-Datagramm an die IP-Adresse des Masters, der die Konfigurationsanfrage ausge­ sandt hat. Dieses UDP-Datagramm enthält, wie bereits dargestellt, die wichtigsten Informationen über die angeschlossenen Geräte.

Geräteverwaltung

Die Verwaltung der mit Hilfe der Geräteerkennung bei Nutzung des Sternkopplers 39 oder des Broadcast-Dienstes erkannten Feldgeräte bzw. Slaves erfolgt im Proxyserver 1 mit Hilfe der Geräteverwaltung 49 (vgl. Fig. 8). Fig. 14 zeigt ein sche­ matisches Blockdiagramm der Anbindung der Geräteverwaltung 49 im Proxyserver 1.

Die Geräteverwaltung 49 stellt der Cacheverwaltung 43 und der XML-Datenbank 50 Informationen über die im Gerätenetzwerk er­ kannten Feldgeräte FG1 . . . FGN zur Verfügung. Dazu bezieht die Geräteverwaltung 49 ihre Informationen über die angeschlosse­ nen Feldgeräte FG1 . . . FGN aus dem im Rahmen des Slot- Protokolls 48 ablaufenden Verfahrens. Auf diese Weise werden die IP-Adressen der angeschlossenen Feldgeräte FG1 . . . FGN be­ reitgestellt. Die Geräteverwaltung 49 wird vom Slot- Protokoll 48 mit den Informationen über die erkannten Feldge­ räte FG1 . . . FGN versorgt. Das Slot-Protokoll 48 liefert der Geräteverwaltung 49 nur die IP-Adressen der erkannten Feldge­ räte FG1 . . . FGN. Alle weiteren Informationen über die Feldge­ räte FG1 . . . FGN, die durch die Geräteverwaltung 49 im Proxy­ server 1 bereitzustellen sind, werden mit dem Herunterladen von HTTP-Daten in festgelegten Dateien aus den Feldgeräten FG1 . . . FGN beschafft. Die Geräteverwaltung 49 stellt mit Hil­ fe der bekannten IP-Adressen aller erkannten Feldgeräte FG1 . . . FGN der Cacheverwaltung 43 die folgenden Informationen über die Feldgeräte FG1 . . . FGN zur Verfügung: Feldgeräte-Typ, Feldgeräte-Version und Version des Dateiblocks für das Beo­ bachtungs- und Bediensystem.

Im Dateicache 45 (vgl. Fig. 8) sind diese Informationen für die dort bereits gespeicherten Dateien ebenfalls vorhanden. Damit kann bei einer Anforderung einer Datei von einem bestimmten der Feldgeräte FG1 . . . FGN anhand dieser Informationen entschieden werden, ob die im Dateicache 45 vorliegende Datei mit der in dem Feldgerät verfügbaren Datei identisch ist, oh­ ne den Dateikopf der angeforderten Datei aus dem bestimmten Feldgerät zu lesen. Es müssen nur die im Dateicache 45 vor­ liegenden Versionsinformationen für die Datei mit den Infor­ mationen aus der Geräteverwaltung 49 für die IP-Adresse des bestimmten Feldgeräts verglichen werden.

Die Anbindung der Geräteverwaltung 49 an die XML-Datenbank 50 dient der Bereitstellung von Informationen aus den Feldgerä­ ten FG1 . . . FGN. Diese Informationen werden in Form einer XML- Datei aus den Feldgeräten FG1 . . . FGN geladen. Die folgende Tabelle zeigt eine Übersicht über die Inhalte dieser Datei:

Alle diese Informationen werden in einer Datei "DevData.xml" gespeichert. Die Geräteverwaltung 49 veranlasst ein HTTP- Herunterladen dieser Datei, wenn eines der Feldgeräte FG1 . . . FGN vom Slot-Protokoll 48 gefunden wurde. Alle weite­ ren Dateien werden von der Geräteverwaltung 49 nur dann aus dem Feldgerät geladen, wenn deren Dateipfad in dieser XML- Datei enthalten ist, d. h. es werden alle mit einem <DEV_PATH<-Tag gekapselten Dateien geladen.

Die Datei "DevData.xml" wird im Proxyserver 1 nach dem Herun­ terladen mit Hilfe des XSL-Parsers 54 in das interne Format des Proxyservers 1 transformiert und anschließend in der XML- Datenbank 50 des Proxyservers 1 eingetragen.

XSL-Parser

Der XSL-Parser 54 (vgl. Fig. 8) dient der Erzeugung von dy­ namisch generierten HTML-Dateien aus der zentralen XML- Datenbank 50 des Proxyservers 1. Dazu werden lokal im Proxy­ server 1 abgelegte XSL-Scripte benutzt. Die XSL-Scripte kön­ nen mit Hilfe einer Admin-Seite in den Proxyserver 1 einge­ spielt werden.

Fig. 15 zeigt die Einbindung des XSL-Parsers 54 in dem Pro­ xyserver 1.

Wird über den HTTP-Server 40 eine XMl-Datei von den Nutzer­ einrichtungen N1 . . . NN aus dem Intranet angefordert, dann wird diese Anforderung vom Datei-Filter 42 ausgefiltert und an das XML-Front-end HTTP 55 weitergeleitet. Dieses Front-end sucht eine zur angeforderten XML-Datei gehöriges XSL- Transformationsscript und startet den XSL-Parser 54 mit die­ sen beiden Dateien.

Da dynamisch generierte HTML-Seiten die verwendeten Daten im­ mer aus der lokal im Proxyserver 1 liegenden XML-Datenbank 50 verwenden, muss der Inhalt dieser Datenbank mit den in den Geräten vorhandenen Daten abgeglichen werden. Dieser Ab­ gleichprozess ist deshalb erforderlich, da viele in der XML- Datenbank 50 abgelegen Daten wie z. B. Messwerte zeitverän­ derlich sind. Diesen Abgleich übernimmt der Block XML-Front- end RPC-Cache 57. Bei einem Zugriff vom XSL-Parser 54 auf die XML-Datenbank 50 wird vom zwischengeschalteten XML-Front-end 57 die Gültigkeitsdauer der angeforderten Information über­ prüft. Ist die angeforderte Information bereits ungültig ge­ worden, dann wird sie von der Verbindungsverwaltung 52 neu aus dem RPC-Client 53 aus dem Gerät angefordert, in der XML- Datenbank 50 aktualisiert und an den XSL-Parser 54 weiterge­ leitet.

Die Geräteverwaltung 49 überwacht fortlaufend den Status der am Gerätenetzwerk angeschlossenen Geräte und aktualisiert diese Informationen mittels des XML-Front-end Gerätedaten 56 in der XML-Datenbank 50.

Der XSL-Parser 54 ist das Hauptbindeglied bei der Darstellung der aktuellen, von den Feldgeräten FG1 . . . FGN empfangenen Da­ ten aus der XML-Datenbank 50. Jedes XSL-Script gibt Trans­ formationsregeln vor, die festlegen, in welcher Weise be­ stimmte Daten aus der XML-Datenbank 50 in Form von HTML- Seiten in den Nutzereinrichtungen N1 . . . NN anzuzeigen sind. Eines der Grundprinzipien von XML ist die Trennung von Inhalt und Präsentation. Ein XML-Dokument enthält nur "Inhalt"; sei­ ne Präsentation muss, in Form eines Stylesheets, gesondert definiert werden. Es gibt verschiedene Möglichkeiten, die Dar­ stellungsinformation zu einem XML-Dokument hinzuzufügen. Die­ se beruhen auf zwei Grundverfahren: Entweder wird das Doku­ ment gemäß eines Stylesheets in eine darstellbare Form ge­ bracht, oder das Stylesheet leitet den Darstellungsmechanismus dabei an, wie die einzelnen Elemente des Dokuments darzustel­ len sind. Diese beiden Grundverfahren können in verschiedener Weise variiert werden:

CSS-Stylesheet + XML-Dokument → XML-fähiger Browser

Der Browser verarbeitet das Dokument und die Darstellungs­ informationen in Form eines CSS-Stylesheets und erzeugt eine Präsentation.

XSL-Stylesheet + XML-Dokument → XSL-fähiges Darstellungs­ programm

Ein Darstellungsprogramm, das XSL-Stylesheets verarbeiten kann, erhält neben dem Dokument die Präsen­ tationsinformation in Form eines XSL-Stylesheets.

XSL-Stylesheet + XML-Dokument → XSL-Transformator → HTML- Dokument

Das XML-Dokument wird entsprechend der Transformationsre­ geln eines XSL-Stylesheets von einem XSL-Transformator in ein (X)HTML-Dokument transformiert, das dann von einem Browser dargestellt werden kann.

Fig. 16 zeigt ein schematisches Blockschaltbild eines XSLT- Prozessors (XSL - "Extended Stylesheet Language Transformati­ on").

Das in Fig. 16 dargestellte Blockschaltbild verdeutlicht noch einmal den Datenfluss, wenn eine XML-Datei angefordert wird. Die vom Client angeforderte Datei Xview.XML wird vom HTTP-Server an den XSLT-Prozessor 54 weitergeleitet. Dieser sucht die zur angeforderten Datei Xview.XSL gehörige Datei Xview.XSL und startet den XSLT-Prozessor 54 mit diesen beiden Dateien. Soll in dem über die angeforderte Datei Xview.XML gestarteten Transformationsprozess Prozessdaten aus der XML- Datenbank 50 des Proxyservers verwendet werden, dann muss das Transformationsscript Xview.XSL einen Verweis auf diese Da­ tenbank enthalten. In dem in Fig. 16 dargestellten Beispiel hat diese XML-Datenbank 50 den Namen Siprogate.XML.

Da alle mit Hilfe der Nutzereinrichtungen N1 . . . NN angezeigten Informationen bei ihrer Anforderung einen XSLT-Prozessor durchlaufen, ist es zweckmäßig, die hierbei angeforderten In­ formationen, wie bereits beschrieben, mit Hilfe des XML-Front- ends RPC-Cache 57 auf ihre Gültigkeit zu prüfen und das Resultat für einen Aktualisierungsmechanismus zu verwenden. Hierzu muss der XSLT-Parser so manipuliert werden, dass fest­ gestellt werden kann, welche Daten aus den einzelnen Daten­ banken bei der Gestaltung der zu erzeugenden HTML-Seite be­ teiligt sind. Anhand dieser Information wird dann in einem zweiten Schritt festgestellt, ob diese Daten aktuell sind. Daraufhin werden die dazu erforderlichen Aktualisierungsme­ chanismen angestoßen, sofern dies notwendig ist, und im An­ schluss der Parservorgang noch einmal gestartet, wobei immer nur jene Daten aktualisiert werden, die gegenwärtig in jegli­ cher Form einem Benutzer mit Hilfe einer oder mehrerer der Nutzereinrichtungen N1 . . . NN angezeigt werden. Das wird da­ durch erreicht, dass nur die angeforderten Daten in der XML- Datenbank aktualisiert werden. Aufgrund der möglicherweise erheblichen Gesamtgröße der XML-Datenbank 50 ergibt sich mit Hilfe dieses Mechanismus eine Reduzierung der zwischen den Feldgeräten FG1 . . . FGN und dem Proxyserver 1 übertragenen Da­ ten, da einerseits nur auf Anforderung und andererseits immer nur die für die jeweilige Darstellung erforderlichen Daten geholt werden.

Claims (8)

1. Verfahren zum Erfassen von mehreren Feldgeräten (FG1, . . ., FGN), die in einer Gerätekonfiguration, insbesonde­ re einer Sternkoppler-Konfiguration, an ein Zentral- Gerät angeschlossen sind, wobei die mehreren Feldgeräte (FG1, . . . , FGN) in der Gerätekonfiguration mit Hilfe ei­ ner jeweiligen elektronischen Adresse aus einem Gesamtad­ ressbereich von dem Zentral-Gerät elektronisch ansprech­ bar sind, das Verfahren die folgenden Verfahrensschritte aufweisend:

• a) elektronisches Abfragen einer Hälfte eines Adressab­ fragebereichs mit Hilfe einer einzelnen, elektroni­ schen Anfrage von dem Zentral-Gerät an die Feldgeräte (FG1, . . ., FGN);
• b) elektronisches Abfragen einer verbleibenden Hälfte des Adressabfragebereichs mit Hilfe einer weiteren einzelnen, elektronischen Anfrage von dem Zentral- Gerät an die Feldgeräte (FG1, . . ., FGN);
• c) Erfassen einer elektronischen Antwort von wenigstens einem der Feldgeräte (FG1, . . ., FGN) aus der Hälfte des Adressabfragebereichs auf die einzelne elektroni­ sche Anfrage und/oder einer anderen elektronischen Antwort von wenigstens einem anderen der Feldgeräte (FG1, . . ., FGN) aus der verbleibenden Hälfte des Ad­ ressabfragebereichs auf die weitere einzelne, elektro­ nische Anfrage mit Hilfe des Zentral-Geräts;
• d) n-maliges (n ≧ 1) Wiederholen der Verfahrensschritte a), b) und c) für die Hälfte des Adressabfragebe­ reichs, wenn im Verfahrensschritt c) eine Antwort aus der Hälfte des Adressabfragebereichs erfasst wird, und/oder für die verbleibende Hälfte des Adressabfra­ gebereichs, wenn im Verfahrensschritt c) eine Antwort aus der verbleibenden Hälfte des Adressabfragebe­ reichs erfasst wird; und
• e) Abbrechen des n-maligen Wiederholens nach Verfahrens­ schritt d), wenn der Adressabfragebereich genau eine elektronische Adresse aus dem Gesamtadressbereich um­ fasst;

wobei der Adressabfragebereich beim elektronischen Ab­ fragen gemäß den Verfahrensschritten a) und b) von dem Gesamtadressbereich und bei einer Wiederholung der Ver­ fahrensschritte a) und b) gemäß dem Verfahrensschritt d) von der Hälfte des Adressabfragebereichs und/oder der verbleibenden Hälfte des Adressabfragebereichs einer vorhergehenden Wiederholung gebildet wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die jeweilige, elektronische Adresse der Feldgeräte (FG1, . . ., FGN) eine Binär-Adresse ist, so dass die Hälfte des Adressabfragebereichs und die verbleibende Hälfte des Adressabfragebereichs mit Hilfe des Festlegens eines Messbits auf einen Wert 0 oder 1 gebildet werden.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass beim elektronischen Abfragen gemäß den Verfahrensschrit­ ten a) und b) jeweils das Messbit und eine Bit-Maske an die Feldgeräte (FG1, . . ., FGN) übermittelt werden.

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass die Bit-Maske beim n-maligen Wiederholen gemäß Verfah­ rensschritt d) in aufeinanderfolgenden Wiederholungen stets um ein Bit verkürzt wird und das n-malige Wieder­ holen abgebrochen wird, wenn die Bit-Maske keine Bits mehr umfasst.

5. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die im Rahmen des Verfahrensschritts c) erfassten, elekt­ ronischen Antworten und/oder die anderen elektronischen Antworten in dem Zentral-Gerät mittels eines ODER-Gatters elektronisch verarbeitet werden.

6. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass elektronische und/oder andere elektronische Antworten erfasst werden, die zeitlich kollidieren, derart, dass sie im wesentlichen gleichzeitig bei dem Zentral-Gerät eingehen.

7. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Erfassen der elektronischen Antwort von dem wenigs­ tens einen der Feldgeräte (FG1, . . ., FGN) aus der Hälfte des Adressabfragebereichs und das Erfassen der anderen elektronischen Antwort von dem wenigstens einen anderen der Feldgeräte (FG1, . . ., FGN) aus der verbleibenden Hälfte des Adressabfragebereichs mittels des Zentral- Geräts auf einen vorbestimmten Zeitraum nach einem Ab­ senden der entsprechenden elektronischen Anfrage be­ grenzt werden.

8. Verwendung eines Verfahrens nach den Ansprüche 1 bis 7 in Steuerungs-/Fernwirksystemen von energietechnischen Anlagen verwendet werden.