Beschreibung
Datenverarbeitungsanlage, Ressourcensteuergerät und Verfahren zur Fernverwaltung von Ressourcen
Die Erfindung betrifft eine Datenverarbeitungsanlage für die Fernverwaltung einer Ressource mit einer Netzschnittstelle zu einem Kommunikationsnetz, über das Daten zur Fernverwaltung zwischen der Datenverarbeitungsanlage und einem entfernten Ressourcensteuergerät übertragbar sind, mit einer Ressourcenschnittstelle, über die Daten zwischen der Datenverarbeitungsanlage und der Ressource übertragbar sind, und mit einem in der Datenverarbeitungsanlage eingerichteten, den Datentransfer zwischen der Netzschnittstelle und der Ressourcen- schnittsteile steuernden Anwendungsserver.
Die Erfindung betrifft ferner ein Ressourcensteuergerät für die Fernverwaltung von Ressourcen mit einer Netzschnittstelle zu einem Kommunikationsnetz, über das Daten zur Fernverwal- tung einer Ressource zwischen dem Ressourcensteuergerät und einer entfernten Datenverarbeitungsanlage transferierbar sind.
Die Erfindung betrifft schließlich ein Verfahren zur Fernver- waltung von einer Datenverarbeitungsanlage zugeordneten Ressourcen mit Hilfe eines entfernten Ressourcensteuergeräts mit den Verfahrensschritten:
- Datentransfer zwischen dem Ressourcensteuergerät und einer Netzschnittstelle eines in der Datenverarbeitungsanlage implementierten Anwendungsservers mit Hilfe eines Kommunikationsnetzwerkes ;
- Datentransfer zwischen dem Anwendungsserver und einer Ressource über eine Ressourcenschnittstelle.
Eine derartige Datenverarbeitungsanlage, ein derartiges Ressourcensteuergerät und ein solches Verfahren sind aus der US 6,061,603 bekannt. Bei dem bekannten Verfahren tauscht ein
als Ressourcensteuergerät dienender Computer mit Hilfe eines internetfähigen Browsers über das Internet Daten mit einer entfernten Datenverarbeitungsanlage aus. Die Datenverarbeitungsanlage verfügt über einen Webserver, der über einen Bus mit einem Steuergerät mit programmierbarer Logik (PLC = Pro- gram able Logic Controller) verbunden ist, und ist vom entfernten Computer über das Internet steuerbar. Die Datenverarbeitungsanlage bildet daher ein spezifisches, über das Internet ansprechbares Steuergerät, das dazu dient, ein an der Steuereinheit mit programmierbarer Logik angeschlossenes
Feldgerät zu beobachten. Diese Steuergeräte werden spezifisch entsprechend der vorgesehenen Anwendung konstruiert. Entsprechend spezifisch auf die jeweilige Anwendung zugeschnitten sind die vom Server erzeugten Webseiten, die auf dem Bild- schirm des entfernten Computers dargestellt werden.
Es ist daher ein Nachteil der bekannten Datenverarbeitungsanlage, daß sie jeweils an den zu steuernden Feldgerätetyp angepaßt werden muß und daß auch die Anwendungsprogramme ent- sprechend modifiziert werden müssen.
Es sind daher bereits Konzepte entwickelt worden, um die Anpassung der AnwendungsServer in den bekannten Datenverarbeitungsanlagen zu erleichtern. Aus Augustin, Polzer und Ott, "Electronic Device Description Language - Basis für eine einheitliche und plattformunabhängige Gerätebedienung", in Dietrich (Hrsg.), "Inbetriebnahme und Engineering von Feldgeräten in dezentralen Automatisierungssystemen", Oldenbourg Industrieverlag, München, 2000 ist ein Konzept bekannt, in dem die Parameter von Feldgeräten auf einheitliche Art und
Weise als Variablen im Rahmen einer zu der Programmiersprache C/C++ ähnlichen Programmiersprache definiert werden. Dabei werden den Variablen auch Methoden zugeordnet, um ihren Wert auszulesen, ihren Wert zu ändern oder die Einhaltung be- stimmter Grenzwerte zu erzwingen. Die Gesamtheit dieser einem Feldgerät zugeordneten Variablen bildet die elektronische Beschreibung des jeweiligen Feldgeräts. Da bei der Beschreibung
der Feldgeräte vorgegebene Konventionen zu beachten sind, wird auch von einer "Electronic Device Description Language" (EDDL) gesprochen. Es ist vorgesehen, daß die sogenannte elektronische Beschreibung der Feldgeräte von den Herstellern der Feldgeräte geliefert wird, so daß sich die Aufgabe des Entwicklers des AnwendungsServers lediglich darauf beschränkt, die vordefinierten Variablen mit Hilfe eines Compilers in eine Anwendung zur Steuerung der Feldgeräte einzubinden. Dieses Konzept setzt jedoch eine einheitliche Sprache für die Beschreibung der Feldgeräte und zum Programmieren der Anwendung voraus .
Das gleiche Konzept ist in dem Dokument, International Electrotechnical Commission, Working Group 7, IEC 1804 Part 2: Function Block and Device Description Language, Working Draft (SC65CWG7(WD1) ) , 2000 offenbart.
Ausgehend von diesem Stand der Technik liegt der Erfindung die Aufgabe zugrunde, eine Datenverarbeitungsanlage und ein dazu passendes Ressourcensteuergerät zu schaffen, mit dem sich unterschiedliche Ressourcen auf einfache Weise steuern lassen. Der Erfindung liegt ferner die Aufgabe zugrunde, ein ressourcenunabhängiges Verfahren zur Fernverwaltung von Ressourcen anzugeben.
Diese Aufgabe wird erfindungsgemäß durch die unabhängigen Ansprüche 1, 11 und 14 gelöst.
Der Datenverarbeitungsanlage, dem Ressourcensteuergerät und dem beanspruchten Verfahren ist gemeinsam, daß jeweils auf generisch gekennzeichnete Ressourcenbeschreibungsdaten zurückgegriffen wird.
Für die generische Kennzeichnung wird in der Fachwelt auch die Bezeichnung "generic markup" verwendet. Damit ist das Einfügen von Bezeichnungen einer Metasprache gemeint, durch die der Inhalt der zu kennzeichnenden Textes markiert wird.
Durch die generische Kennzeichnung der Beschreibung kann der AnwendungsServer die Beschreibung der Ressourcen auswerten, sofern der Anwendungsserver nur in der Lage ist, die generi- sehe Kennzeichnung zu interpretieren. Die Funktion der beschriebenen Ressourcen ergeben sich für den Anwendungsserver unmittelbar aus der generischen Kennzeichnung, da diese definitionsgemäß den Inhalt, also die Funktion der Ressourcen kennzeichnet. Gemäß der Erfindung kann daher der Anwendungs- server unabhängig von der Beschaffenheit der Ressource implementiert werden. Insbesondere ist es möglich, einen einzigen Anwendungsserver für eine Vielzahl unterschiedlicher Ressourcen zu verwenden. Für die erfindungsgemäße Fernverwaltung der Ressourcen genügt daher ein einziger Anwendungsserver, der gegebenenfalls auch zur Laufzeit an die jeweiligen zu verwaltenden Ressourcen angepaßt werden kann.
Bei einer bevorzugten Ausführungsform der Erfindung sind die Ressourcenbeschreibungsdaten in einer Dateneinheit abgelegt, die für den Anwendungsserver zur Laufzeit zugänglich ist.
Unter einer Dateneinheit soll in diesem Zusammenhang jede Form von elektronisch dargestellten Daten verstanden werden. Solche Dateneinheiten können in der Form von Dateien abge- speichert sein, als ASCII-, HTML- oder XML-Dokumente vorliegen oder über Streams, eine Schnittstelle für ein Anwendungsprogramm (API) , Pipes oder sonstige Kommunikationsprotokolle zugängliche Daten sein.
Dementsprechend werden bei einer Ausführungsform des Verfahrens gemäß der Erfindung zunächst die generisch gekennzeichneten Ressourcenbeschreibungsdaten in einer für den Anwendungsserver zugänglichen Dateneinheit abgelegt und zur Laufzeit vom AnwendungsServer eingelesen. Der unabhängig von den Ressourcen einsetzbare AnwendungsServer paßt sich daher erst zur Laufzeit an die jeweils vorliegenden Ressourcen an.
Bei einer bevorzugten Ausführungsform der Erfindung wird zur generischen Kennzeichnung der Ressourcenbeschreibungsdaten eine Sprache verwendet, die im jeweiligen Kommunikationsnetz zur generischen Kennzeichnung von Inhalten verwendet wird. Vorgeschlagen werden insbesondere XML und XSL.
Dies hat den Vorteil, daß die zum Erzeugen von Ansichten auf einem Datensichtgerät verwendeten Programmiertechniken auch zum Programmieren des AnwendungsServers verwendet werden kön- nen, da die Arbeitsweise des Anwendungsservers der Arbeitsweise eines herkömmlichen Webservers ähnelt, der aus gene- risch gekennzeichneten Textdokumenten auf dem Datensichtgerät darstellbare Webseiten erzeugt. In analoger Weise erzeugt der Anwendungsserver eine Darstellung der Ressource, die auf einem entfernten Datensichtgerät präsentierbar ist.
Weitere Einzelheiten der Erfindung sind Gegenstand der abhängigen Ansprüche .
Nachfolgend wird die Erfindung im einzelnen anhand der beigefügten Zeichnungen erläutert. Es zeigen:
Figur 1 ein Blockdiagramm mit einer herkömmlichen Datenverarbeitungsanlage für die Verwaltung von Ressourcen;
Figur 2 ein weiteres Blockdiagramm einer herkömmlichen, zur Verwaltung von Ressourcen geeigneten Datenverarbeitungsanlage;
Figur 3 ein Blockdiagramm einer Datenverarbeitungsanlage gemäß der Erfindung;
Figur 4 ein Blockdiagramm eines Anwendungsservers gemäß der Erfindung; und
Figur 5 ein Blockdiagramm mit der im Anwendungsserver verwendeten Daten- und Softwarearchitektur.
In Figur 1 ist eine erste Ressource 1, eine zweite Ressource 2 und eine dritte Ressource 3 einer Datenverarbeitungsanlage 4 zugeordnet. Die Ressourcen 1 bis 3 können in der Datenver- arbeitungsanlage 4 laufende Programme oder an eine physikalische Schnittstelle der Datenverarbeitungsanlage angeschlossene Feldgeräte sein. Derartige auf der Datenverarbeitungsanlage 4 laufende Programme können für das gesamte Internet verfügbare Suchmaschinen, Marketing-Portale oder Überset- zungsdienste sein. Die auf der Datenverarbeitungsanlage 4 laufenden Programme können aber auch lediglich auf Teilnetzen des Internets, sogenannten Intranets, verfügbar sein. Derartige Programme sind beispielsweise Druckdienste, Mailserver, Datenbankserver zur Verwaltung von Unternehmensdaten oder auch komplexe Dienste, wie Software zur Transformation von Anwendungsprogrammen der Automatisierungstechnik zum Zwecke der Migrationsunterstützung.
Wie bereits erwähnt, können die Ressourcen 1 bis 3 auch Feld- gerate sein. Derartige Feldgeräte sind üblicherweise Komponenten von industriellen Anlagen, die in der Lage sind, Prozeßgrößen von verfahrenstechnischen Vorgängen zu erfassen und zu beeinflussen. Derartige Feldgeräte können zum Beispiel aber auch automatisierte Maschinen der Haustechnik sein.
Die hier beschriebenen Ressourcen weisen ein komplexes Verhalten auf und müssen an ihren jeweiligen Einsatzzweck durch eine entsprechende Einstellung von variierbaren Parametern angepaßt werden. Derartige Ressourcen werden nachfolgend als parametrierbar bezeichnet. Gelegentlich sind Ressourcen auch auf die Zusammenarbeit mit anderen Ressourcen angewiesen. Eine derartige Verschaltung von Ressourcen wird nach folgend als Konfiguration bezeichnet. Ressourcen sind daher im allgemeinen parametrierbar und konfigurierbar.
In Figur 1 kann die Ressource 1 zum Beispiel durch ein Parametrierprogramm 5, das über eine Schnittstelle 6 auf die
. <
Ressource 1 zugreift, parametriert werden. Außerdem kann die Ressource 1 aus der Ferne mit Hilfe eines Parametrierpro- gramms 7, der auf einer entfernten Datenverarbeitungsanlage 8 installiert ist, verwaltet werden.
Die Ressource 2 dagegen wird durch Daten parametriert, die in einer Dateneinheit 9 abgelegt sind. Diese Dateneinheit 9 können beispielsweise sogenannte *. INI-Dateien sein, die bei Initialisieren der Ressource 2 geladen werden. Auch gemischte Situationen können auftreten. Die Ressource 3 wird beispielsweise durch Daten aus einer Dateneinheit 10 parametriert. Gleichzeitig können Parameter der Ressource 3 über eine Schnittstelle 11 mit Hilfe eines Parametrierprogramms 12 eingestellt werden.
Figur 2 enthält ein Blockdiagramm einer herkömmlichen Datenverarbeitungsanlage 13 mit einem Parametrierprogramm 14. Das Parametrierprogramm 14 kann über Treiber 15 auf Dienste eines Betriebssystems- 16 zugreifen. Insbesondere ist das Parame- trierprogramm 14 über einen der Treiber 15 in der Lage, eine serielle Schnittstelle 17, beispielsweise eine RS-232- Schnittstelle, anzusteuern, die mit einem ersten Feldgerät 18 verbunden ist. Über einen weiteren Treiber 15 kann das Parametrierprogramm 14 auf einen Feldbusadapter 19 zugreifen, der an einen Feldbus 20 angeschlossen ist. Über den Feldbus 20 können neben dem ersten Feldgerät 18 auch ein zweites Feldgerät 21 und ein drittes Feldgerät 22 angesprochen werden.
Den herkömmlichen Programmen für die Parametrierung und Kon- figuration von Ressourcen ist gemeinsam, daß sie jeweils zur Verwaltung einer speziellen Ressource eingerichtet sind. Auch wenn diese Programme zur Parametrierung und Konfiguration häufig eine ähnliche Architektur aufweisen, so unterscheiden sie sich jedoch im Detail erheblich. Insbesondere werden zur Parametrierung komplexe Datensätze verwendet, welche in einem proprietären Format des Herstellers strukturiert sind. Auch eine Fernanbindung der Ressourcen an ein entferntes Verwal-
tungsprogramm ist wie bei den Ressourcen 2 und 3 nicht möglich. Falls eine Fernwartung durchgeführt werden kann, erfolgt dies in proprietärer Weise, beispielsweise über ein Modem.
Figur 3 zeigt ein Blockdiagramm mit der Architektur einer Datenverarbeitungsanlage 23 gemäß der Erfindung. Diese Datenverarbeitungsanlage 23 verfügt über eine Netzschnittstelle 24, die mit einem Kommunikationsnetz 25 verbunden ist. Bei dem Kommunikationsnetz 25 handelt es sich vorzugsweise um ein TCP/IP-Netzwerk beliebiger Ausdehnung. Bei dem Kommunikationsnetz 25 kann es sich daher um das Internet oder ein lokales Intranet handeln.
Das Kommunikationsnetz 25 ist über eine weitere Netzschnittstelle 26 mit einer entfernten Datenverarbeitungsanlage 27 verbunden, auf dem ein Browser 28 läuft. Grundsätzlich könnte anstelle der entfernten Datenverarbeitungsanlage 27 auch ein mobiles Funktelefon oder ein mobiles Datensichtgerät treten. Ein Wartungstechniker 29 kann den Browser 28 bedienen, indem er beispielsweise auf einem Bildschirm angezeigte Inhalte bearbeitet .
Der Browser 28 tauscht über das Kommunikationsnetz 25 Daten mit einem Webserver 30 aus. Der Webserver liefert dabei mittels HTTP oder WAP in einem Standardformat, wie beispielsweise HTML oder WML, formatierte ASCII-Datensätze. Der Inhalt der vom Webserver 30 transferierten Webseiten wird durch einen unterlagerten Anwendungsserver 31 bestimmt. Der Anwen- dungsserver 31 erhält durch eine darunterliegende Ressourcenzugangsschicht 32 Zugang zu unterlagerten Ressourcen 33 bis 35. Der Zugriff auf die Ressource 33 in Figur 3 ist unmittelbar in der Ressourcenzugangsschicht 32 implementiert. Der Zugriff über die Ressourcen 34 und 35 erfolgt mit Hilfe eines Mediumadapters 36 in Verbindung mit einem weiteren Kommunikationsnetz 37. Bei dem Kommunikationsnetz 37 kann es sich um einen Feldbus handeln, wobei dann der Mediumadapter 36 mit
Hilfe von geeigneten Treibern- aus der Ressourcenzugangs- Schicht 32 heraus angesteuert wird.
Es sei angemerkt, daß die Anzahl der vom Anwendungsserver 31 verwalteten Ressourcen 33 bis 35 grundsätzlich unbeschränkt ist. Außerdem sei angemerkt, daß unter dem Bergriff des AnwendungsServers 31 und des Webservers 30 vorzugsweise logische Softwarekomponenten verstanden werden, die in einer Realisierung auch zu einem Programm zusammengefasst werden können .
Wie bereits im Zusammenhang mit dem Stand der Technik erwähnt, kann es sich bei den Ressourcen 33 bis 35 auch um in Software implementierte Ressourcen handeln. Derartige Res- sourcen sind beispielsweise Datenbanken oder spezielle Netzdienste, wie beispielsweise Übersetzungsprogramme, deren Thesaurus austauschbar ist. Solche in Software implementierten Ressourcen können auch Suchmaschinen, Marketing-Portale oder typischerweise in einem Intranet verfügbare Druckdienste, Mailserver oder diverse Anwendungsprogramme sein. Derartige Ressourcen können auch gemischt in Software und Hardware implementiert werden. Ein Beispiel hierfür ist ein Feldgerät der Verfahrenstechnik, das softwaregesteuert Meßdaten aufnimmt .
Gemeinsam ist den Ressourcen 33 bis 35, daß sie Dienste anbieten, welche über das Kommunikationsnetz 25 aufgerufen werden können. Ferner müssen sie parametrierbar oder konfigurierbar sein.
In Figur 4 ist die Architektur der Datenverarbeitungsanlage 23 mit mehr Einzelheiten dargestellt. Gemäß der in Figur 4 dargestellten Architektur tauscht der Webserver 30 mit dem Anwendungsserver 31 eine Dateneinheit 38 im HTML-Format aus. Die Verwendung des HTML-Formats für die Kommunikation zwischen dem Anwendungsserver 31 und dem Webserver ist nicht unbedingt erforderlich. Allerdings kann dadurch der Webserver
10
30 ohne weitere Umformungen die Dateneinheit an den Browser 28 weiterleiten, wo die Dateneinheit 38 im HTML-Format in eine graphische Anzeige auf einem Bildschirm umgesetzt werden.
Der Anwendungsserver 31 selbst enthält' Darstellungen 39 bis 41 der jeweiligen zu verwaltenden Ressourcen 33 bis 35. Diese Darstellungen 39 bis 41 werden zur Laufzeit vom Anwendungsserver 31 aus einer Ressourcenbeschreibung 42 gewonnen, die in einer Dateneinheit abgelegt ist. Die Ressourcenbeschrei- bung 42 umfaßt insbesondere Ressourcenbeschreibungsdaten 43. Die Ressourcenbeschreibungsdaten 43 sind generisch gekennzeichnet (Generic Markup) . Das bedeutet, daß in den Text der Resourcenbeschreibung 42 Bezeichnungen in einer Metasprache eingefügt sind, die den Inhalt, also die Funktion der Parameter der Ressourcen 33 bis 35 kennzeichnet.
Dies sei anhand eines Stücks Pseudocodes veranschaulicht. Eine generisch gekennzeichnete Beschreibung eines Drehzahl- messers könnte zum Beispiel so aussehen:
<Gerät>
<Typ> Drehzahlmesser </Typ> <Meßgröße>
<Bezeichnung> XTURN </Bezeichnung> <Maximalwert> 2000 </Maximalwert
</Meßgröße> </Gerät>
Im vorliegenden Beispiel wird die Angabe 2000 als Maximalwert für die Meßgröße XTURN durch den Metatext <Maximalwert> und </Maximalwert> gekennzeichnet. Dieser Metatext ist unabhängig von der Programmiersprache, in der der Anwendungsserver 31 programmiert ist. Vielmehr- ist der Anwendungsserver 31 auch
zur Laufzeit in der Lage, auf die Ressourcenbeschreibung 42 in der Art eines generisch gekennzeichneten Webdokuments zuzugreifen und daraus die Darstellungen 39 bis 41 der Ressourcen zu erzeugen.
Für die generische Kennzeichnung der Ressourcenbeschreibungsdaten 43 in der Ressourcenbeschreibung 42 wird zweckmäßigerweise eine in dem Kommunikationsnetz 25 verwendete Sprache zur generischen Kennzeichnung von Inhalten verwendet. Als derartige Sprache bietet sich beispielsweise die auch für die generische Kennzeichnung von Daten im Internet verwendbare Sprache XML an. Die Ressourcenbeschreibung 42 in Fig. 4 enthält daher Ressourcenbeschreibungsdaten 43 im XML-Format.
Die Ressourcenbeschreibung 42 kann auch Darstellungsdaten 44 enthalten, die die Präsentation der Ressourcenbeschreibungsdaten 43 auf dem Bildschirm der entfernten Datenverarbeitungsanlage 27 betreffen. Zur Beschreibung der Darstellungs- daten 44 wird zweckmäßigerweise ebenfalls eine im jeweiligen Ko munikationsnetz 25 verbreitete Sprache verwendet. In Betracht kommt beispielsweise die auch für die Darstellung von Daten im Internet verwendbare Sprache XSL. Die Ressourcenbeschreibung 42 in Fig. 4 enthält daher auch Darstellungsdaten 44 im XSL-Format.
Die Sprachregeln für die Sprachen XML und XSL sind dem Fachmann bekannt und nicht Gegenstand der Anmeldung.
Wie bereits erwähnt, beinhaltet der Anwendungsserver 31 für jede von ihm ansprechbare Ressource 33 bis 35 eine aktuelle Darstellung 39 bis 41. Im AnwendungsServer 31 sind dabei alle Operationen implementiert, welche ein Zugriff auf die Ressourcen 33 bis 35 erfordert.
In der Datenverarbeitungsanlage 23 gemäß Figur 4 werden dynamisch veränderliche Zustandsdaten der Ressourcen 33 bis 35 zwischen der Ressourcenzugangsschicht 32 und dem Anwendungs-
server 31 in beide Richtungen in einem herstellerunabhängigen XML-Format 45 ausgetauscht. Die Umwandlung der Ressourcenzustandsdaten 45 vom XML-Format in die Ressourcenzustandsdaten 46 im ressourcenspezifisches Datenformat erfolgt durch einen vom jeweiligen Hersteller der Ressourcen 33 bis 35 zu liefernden Ressourcenadapter 47, der einen Teil der Ressourcenzugangsschicht 32 bildet. Der Ressourcenadapter 47 stellt dabei zum Anwendungsserver 31 hin eine herstellerunabhängige Schnittstelle bereit. Mit den Ressourcenzustandsdaten 46 im ressourcenspezifischen Format kann der Mediumadapter 36 schließlich einen Datenaustausch, beispielsweise mit der Ressource 34, durchführen.
In Figur 5 sind in einem weiteren Blockdiagramm die Abläufe im Anwendungsserver 31 dargestellt. Eine wichtige Komponente ist dabei die zentrale Ablaufsteuerung, die jedoch in Figur 5 nicht explizit dargestellt ist.
Die Ressourcendarstellung 39 wird über Ladeprogramme 48 und 49 mit der Ressourcenbeschreibung 42, die die Ressourcenbe- schreibungsdaten 43 im XML-Format und die Darstellungsdaten 44 im XSL-Fora t umfaßt, geladen. Danach ist die Ressourcendarstellung 39 in der Lage, über eine Ressourcensynchronisation 50 auf die Ressourcenzustandsdaten 45 zuzugreifen. Aus den Ressourcenzustandsdaten 45, die vom Ressourcenadapter 47 geliefert werden, erzeugt ein Softwarebaustein Präsentationskomponente 51, eine Client-Anwendung 52 in einem für den Browser 28 interpretierbaren Format. Die Client-Anwendungen 52 können neben den Ressourcendaten 53 auch eingebetteten und ablauffähigen Client-Code 54 enthalten. Für das Internet werden die Ressourcendaten 53 zweckmäßigerweise in HTML oder WML formatiert. Bei dem Client-Code 54 kann es sich um einen üblichen in Browsern 28 ausführbaren Code, zum Beispiel Javascript oder Java-Applets, handeln. Die Client-Anwendung 52 wird vom Browser 28 heruntergeladen und auf dem zugeordneten Datensichtgerät angezeigt, während der ablauffähige Client-Code 54 im Browser 28 ausgeführt wird. Durch den
ablauffähigen Client-Code 54 werden Eingaben des Wartungstechnikers 29 validiert und ein Aktualisierungsdatensatz 55 zum Hochladen auf den Anwendungsserver 31 erzeugt. Beim Hochladen des Datensatzes 55 werden diese Daten durch den Softwarebaustein Aktualisierung 56 im Anwendungsserver 31 in die Ressourcendarstellung 39 eingefügt. Von hier aus können geänderte Ressourcenzustandsdaten über die Ressourcensynchronisation 50 und über den Ressourcenadapter 47 auf die jeweilige Ressource geladen werden.
Die anhand der Figuren 3 bis 5 beschriebene Architektur weist eine Reihe von Vorteilen gegenüber der Architektur herkömmlicher Datenverarbeitungsanlagen auf. Zum einen kann mit jedem Standardbrowser 28 von jedem Anschlußpunkt des Kommunikati- onsnetzes 25 auf eine der Ressourcen 33 bis 35 zugegriffen werden. Für den Anwender, im beschriebenen Beispiel also für den Wartungstechniker 29, erübrigt sich dabei die Notwendigkeit, zahlreiche, herstellerspezifische Parametrier- und Konfigurationsprogramme oder lokale auf Seiten des Anwen- dungsservers 31 gespeicherte Parametrier- und Konfigurationsdateien einzusetzen. Der Umfang der von den Herstellern der Ressourcen 33 bis 35 zu erstellenden Software reduziert sich gegenüber dem Stand der Technik deutlich, da die Hersteller lediglich die Ressourcenbeschreibung 42 und den Ressour- cenadapter 47 liefern müssen, da der Kern des Programms zur Parametrierung und Konfiguration der Ressourcen 33 bis 35 ressourcenunabhängig, in allgemeiner Form implementiert ist. Für die Hersteller der Ressourcen 33 bis 35 erübrigt sich damit die Notwendigkeit, ein komplettes Parametrier- und Konfi- gurationsprogram einschließlich Treibern und Benutzeroberfläche zu entwickeln. Dadurch vermindert sich auch der Aufwand bei der Entwicklung und Wartung derartiger Programme zur Parametrierung und Konfiguration der Ressourcen 33 und 35.
Darüber hinaus läßt sich der ressourcenunabhängige Anwendungsserver 31 schneller und kostengünstiger zu stabiler Ein-
satzreife führen als die Vielfalt von hersteiler- und gerätespezifischen Einzelprogrammen.
Die hier beschriebene Architektur der Datenverarbeitungsan- läge 23 gestattet es, mit einer einzigen Implementierung des Anwendungsservers 31 und mit Hilfe von standardmäßig verfügbaren generischen Sprachen, alle diejenigen Ressourcen 33 bis 35 zu parametrieren und konfigurieren, die durch eine generisch kennzeichnende Sprache beschreibbar sind. Als Sprachen eignen sich insbesondere über die Protokolle des jeweiligen Kommunikationsnetzes 25, zum Beispiel Internet, verwendbare Sprachen. Die generisch gekennzeichnete Datenstruktur läßt sich dabei sowohl zur Beschreibung der statischen als auch dynamischen Zustände und Eigenschaften der jeweiligen Res- source 33 bis 35 verwenden. Die generisch kennzeichnenden Sprachen können zur Definition der Formate für die Ressourcenbeschreibung 42, die Gestaltung der ressourcenspezifischen Benutzeroberfläche zur Parametrierung oder Konfiguration, zur Darstellung des Ressourcendaten 53 und zur Darstellung der ressourcenspezifischen Aktualisierungsdatensätze 55 verwendet werden. Dies ermöglicht die Verwendung standardmäßig verfügbarer Softwarebibliotheken, die zur Transformation elektronischer Dokumente verwendet werden, die unter Verwendung einer generisch kennzeichnenden Sprache erstellt worden sind.
Die beschriebene Architektur kann insbesondere zur Implementierung eines Parametrierprogramms für Feldgeräte in der Automatisierung von verfahrenstechnischen Anlagen eingesetzt werden. Feldgeräte dieser Art dienen in der Anlagenautomati- sierung als Schnittstelle zwischen Leitsystem und verfahrenstechnischem Prozeß zur Erfassung und Beeinflussung von Prozeßgrößen. Feldgeräte werden häufig über Feldbusse, wie etwa dem PROFIBUS PA, verbunden. Die Feldgeräte benötigen eine Parametrierung, welche ihr Verhalten spezielle auf den gegebenen Einsatzfall abstimmt. Die Parametrierung wird mit Hilfe von komplexen Datensätzen vorgenommen, welche in einem proprietären Format des Herstellers der Feldgeräte struktu-
riert sind. Diese komplexen Datensätze müssen von dem Parametrierprogramm aus dem Feldgerät geladen, editiert und in das Feldgerät zurückgeladen werden. Bei herkömmlichen Datenverarbeitungsanlagen werden unterschiedliche Parametrierpro- gramme mit herstellerspezifischen Datenformaten und Benutzerschnittstellen verwendet. Häufig sind diese Parametrierpro- gramme für ein einzelnes Feldgerät zugeschnitten. Die dafür verwendeten Parametrierprogramme bauen für die Kommunikation, die graphische Benutzerschnittstelle und die Datenhaltung auf Schnittstellen des Betriebssystems der jeweiligen Datenverarbeitungsanlage auf, zum Beispiel das Win32-API. Die Anbindung des Parametrierprogramms an den Feldbus erfolgt dabei über spezielle Hardware- und Treibersoftware.
Bei Anwendung der hier beschriebenen Architektur der Datenverarbeitungsanlage 23 können die herkömmlichen Parametrierprogramme vom Hersteller durch den ressourcenunabhängigen Anwendungsserver 31 ersetzt werden. Der AnwendungsServer 31 ermöglicht das Parametrieren des Feldgeräts mit dem Webbrowser 28 über das Internet. Der Hersteller des Feldgeräts muß zu diesem Zweck eine elektronische Feldgerätebeschreibung (Electronic Device Description = EDD) im XML/XSL-Format bereitstellen. Diese Ressourcenbeschreibung 42 beschreibt in gene- rischer Weise die für die Parametrierung wichtigen Eigen- schatten des Feldgeräts und die Gestaltung einer Benutzeroberfläche zur Parametrierung des Feldgeräts. Zusätzlich muß der Hersteller den Ressourcenadapter 47 mit den erforderlichen Schnittstellen implementieren. Der Ressourcenadapter 47 führt zur Laufzeit alle erforderlichen Konvertierungen zwischen den Ressourcenzustandsdaten 46 im ressourcenspezifischen Format und den Ressourcenzustandsdaten 45 im generischen Format durch und umgekehrt. Außerdem steuert der Ressourcenadapter 47 sämtliche für das jeweilige Feldgerät spezifischen Protokollabläufe. Die Anbindung an das Kommuni- kationsnetz 37, insbesondere im Feldbus, erfolgt in der
Ressourcenzugangsschicht 32, welche von einem Systemintegra-
16
tor zu implementieren ist. Die Feldbusanbindung nimmt daher konzeptionell die Position des Mediumadapters 36 ein.